--- 1/draft-ietf-webdav-collection-protocol-00.txt 2006-02-05 02:10:40.000000000 +0100 +++ 2/draft-ietf-webdav-collection-protocol-01.txt 2006-02-05 02:10:40.000000000 +0100 @@ -1,14 +1,17 @@ - WEBDAV Working Group J. Slein - INTERNET DRAFT Xerox Corporation - June 5, 1998 - Expires December 5, 1998 + + WEBDAV Working Group J. Slein, Xerox + INTERNET DRAFT J. Davis, Xerox + A. Babich, FileNet + E.J. Whitehead Jr., UC Irvine + July 31, 1998 + Expires January 31, 1999 WebDAV Advanced Collections Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -29,550 +32,1315 @@ to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at URL: . Abstract - The base WebDAV protocol [Goland et al., 1998] provides basic - support for collections. It defines a MKCOL method for creating - collections and specifies how other HTTP and WebDAV methods - interact with collections. It supports only internal members of - collections, which it defines as members whose URIs are - immediately relative to the URI of the collection. + The base WebDAV protocol [WebDAV] provides basic support for + collections. It defines a MKCOL method for creating collections + and specifies how other HTTP and WebDAV methods interact with + collections. It supports internal members of collections, which it + defines as members whose URIs are immediately relative to the URI + of the collection. Many applications, however, need more powerful collections. There are two areas in particular where more powerful functionality is - often needed: referential members and ordering. + often needed: referential resources and ordering. This draft specifies extensions to the base WebDAV protocol to support these more powerful collections. + Table of Contents + + 1 Terminology 3 + 2 Introduction 4 + 3 Referential Resources 4 + 3.1 Scope 4 + 3.2 Overview 6 + 3.3 Creating Referential Resources 6 + 3.3.1 The MKREF Method 6 + 3.3.2 Status Codes 7 + 3.3.3 Example 8 + 3.4 Deleting Referential Resources 8 + 3.4.1 The DELREF Method 8 + 3.4.2 Status Codes 8 + 3.4.3 Example 8 + 3.4.4 Design Rationale 8 + 3.5 Listing Referential Members of a Collection 9 + 3.6 Other WebDAV Operations on Indirect References 9 + 3.7 HTTP Operations on Indirect References 10 + 3.8 Operations on Targets of References 11 + 4 Ordered Collections 11 + 4.1 Overview 11 + 4.2 Creating an Ordered Collection 11 + 4.2.1 Overview 11 + 4.2.2 Status Codes 12 + 4.2.3 Example 12 + 4.3 Setting the Position of a Collection Member 12 + 4.3.1 Overview 12 + 4.3.2 Status Codes 13 + 4.3.3 Examples 13 + 4.4 Changing the Semantics of a Collection Ordering 14 + 4.5 Changing the Position of a Collection Member 14 + 4.5.1 The ORDERPATCH Method 14 + 4.5.2 Status Codes 14 + 4.5.3 Example 14 + 4.5.4 Design Rationale 15 + 5 New Headers 16 + 5.1 Ref-Target Request Header 16 + 5.2 Ref-Integrity Request Header 16 + 5.3 Pass-Through Request Header 17 + 5.4 Resource-Type Response Header 17 + 5.5 Ordered Request Header 17 + 5.6 Position Request Header 18 + 6 New Properties 18 + 6.1 reftarget Property 18 + 6.2 refintegrity Property 18 + 6.3 passthrough Property 19 + 6.4 orderingtype Property 19 + 7 New XML Elements 20 + 7.1 reference XML Element 20 + 7.2 weak XML Element 20 + 7.3 arbitrary XML Element 20 + 7.4 order XML Element 20 + 7.5 member XML Element 20 + 7.6 position XML Element 21 + 7.7 first XML Element 21 + 7.8 last XML Element 21 + 7.9 before XML Element 21 + 7.10 after XML Element 22 + 8 Compliance 22 + 8.1 Class 3 22 + 8.2 Class 4 22 + 9 Dependencies on Other Specifications 22 + 10 Security Considerations 22 + 10.1 Redirect Loops 23 + 10.2 References and Denial of Service 23 + 10.3 Malicious Modifications of Ordering 23 + 10.4 Denial of Service and DAV:orderingtype 23 + 11 Internationalization Considerations 23 + 12 IANA Considerations 24 + 13 Copyright 24 + 14 Intellectual Property 24 + 15 Acknowledgements 24 + 16 References 24 + 17 Authors' Addresses 25 + 1 Terminology - The terminology used here differs from that in the base WebDAV - protocol specification [Goland et al., 1998], particularly in its - definition of internal member resource. + The terminology used here follows and extends that in the base + WebDAV protocol specification [WebDAV]. Collection A resource that contains member resources Member Resource A resource contained by a collection - Referential Member Resource - A member resource that has no content of its own, but rather is + Referential Resource (or Reference) + A resource that has no content of its own, but rather is a reference to another resource + Ordinary Resource + A member resource that is not a reference to another resource + + Target Resource + The resource referenced by a referential member of a collection + + Direct Reference + A reference that has the property that operations on it are + passed through to its target + + Indirect Reference + A reference that has the property that operations on it do + not affect its target + Strong Reference A reference whose referential integrity is guaranteed by the server Weak Reference A reference whose referential integrity is not guaranteed by the server - - Internal Member Resource - A member resource that either has content of its own or is - empty, but is not a reference to another resource - - Target Resource - The resource referenced by a referential member of a collection + Referential Integrity + A server guarantees the integrity of a reference if it ensures + that the reference will not be broken, or enables the + reference's owner to ensure that the reference will not be + broken. 2 Introduction The simple collections that the base WebDAV specification supports are powerful enough to be widely useful. They provide for the hierarchical organization of resources, with mechanisms for creating and deleting collections, copying and moving them, locking them, adding resources to them and deleting resources from them, and getting listings of their members. Delete, copy, move, list, and lock operations can be applied recursively, so that a client can operate on whole hierarchies with a single request. Many applications, however, need more powerful collections. There are two areas in particular where more powerful functionality is - often needed: referential members and ordering. + often needed: referential resources and ordering. - Referential members make it possible for many collections, on the + Referential resources make it possible for many collections, on the same or different servers, to share the same resource. Because the collections share the resource by referencing it, only one physical copy of the resource need exist, and any changes made in the resource are visible from all the collections that reference it. It is useful for many applications to be able to impose an ordering on a collection. Orderings may be based on property values, but they may be completely independent of any properties on the collection's member resources. Orderings based on properties can be obtained using a search protocol [DASL], but orderings not based on properties need some other mechanism. Since these two areas are independent of each other, servers may - elect to comply with the Referential Members section of this + elect to comply with the Referential Resources section of this specification or with the Ordered Collections section or both. A server MUST advertise its compliance through its response to - an OPTIONS request, as specified in [Goland et al., 1998]. New - values for the DAV header are defined in Section 8 below to - support this requirement. + an OPTIONS request, as specified in [WebDAV]. New values for the + DAV header are defined in Section 8 below to support this + requirement. - 3 Referential Members +3 Referential Resources - 3.1 Overview +3.1 Scope - A referential member of a collection is a resource that has no - content of its own, but instead references another resource. The - resource it references may be in the same collection or anywhere - else. This target resource may be a collection or a simple - resource or another referential member of a collection, or any - other sort of resource that may be defined in the future. A - resource may be referenced by any number of referential members of - collections. (Req 3.1.1 - 3.1.3, 3.1.6, 3.1.15) + [WebDAVReq] distinguishes between "weak" references and "strong" + references, and also between "indirect" references and "direct" + references. This specification supports only weak references and + indirect references, but is designed so that it can be extended + to support strong references and direct references in the future. - Since a referential member of a collection is a resource, it can - have properties just like any other resource. These properties are - completely independent of the properties on its target resource - (Req 3.1.9). A new DAV:reftarget property has as its value the - URI of the target resource (3.1.6). + Strong references are references whose integrity is guaranteed by + the server; weak references are those whose integrity is not + guaranteed. Strong references and weak references are both useful + in different contexts. Some applications cannot tolerate broken + links. A software development application, for example, must be + able to rely on the integrity of references to component modules. + Such applications must be able to request strong references. Other + applications may want to reference target resources on multiple + servers, where referential integrity cannot be guaranteed, and may + be less concerned about possible broken references. - 3.2 Creating Referential Members of a Collection (Req 3.1.7) + Several considerations led to the decision not to support strong + references in the current specification. First, there are many + possible policies that applications and services might use to + enforce referential integrity. -(Add justification for using the extension mechanisms specified in -[Nielsen et al., 1998] "Mandatory Extensions in HTTP".) + o Delete strong references when their targets are deleted. - Clients MUST use the M-PUT method to create a referential member - of a collection. (Clients MUST NOT use a plain PUT to create a - referential member of a collection. A PUT request with a - request-URI of an existing collection will fail.) The - request-URI of the M-PUT request identifies the collection to which - the new member is to be added. The server recognizes a request to - create a referential member, rather than an internal member, by the - presence of the Referential-Member header. This header identifies - the referential member being added. The Ref-Target header contains + o Decline to delete targets of strong references. + + o Notify strong references when their targets have been + deleted. + + o Let owners of resources decide whether strong references to + them are allowed. + + There appears to be no common practice in this area. Moreover, + some of the policies have significant security risks. + + o Moving a target of strong references could be a security + risk to the owner of the target by revealing secret + locations on the target's server. + + o A strong reference could be a security risk to the owner of + the reference by revealing secret locations on his server. + + o The presence of strong references to resources on a server + could make it impossible to reclaim space on that server + by moving or deleting those target resources. + + These considerations together led to the decision not to support + strong references in the short term. + + Operations on indirect references do not affect their target + resources, whereas operations on direct references are passed + through to their targets. Both indirect and direct references may + be useful. Each of these types of references is implemented in + existing systems. Existing HTTP servers are capable of supporting + both types of references. In effect, indirect references give + clients access to the reference itself, and allow the reference to + bear properties. Direct references, once created, simplify access + to the target resource by hiding from clients the fact that there + is a reference mediating between the client and the target + resource. They also make access to the target more efficient, + eliminating a round trip required by indirect references to get the + URI of the target resource. + + Again, it was believed that supporting direct references would be + too difficult in the short term. Although convenient, they add no + functionality beyond what is available through indirect references. + Existing systems often implement hybrids of direct and indirect + references, for which some operations are passed through to the + target while others are not. This fact muddies the issue of what + exactly WebDAV should support. It also suggests that the + definition of direct references as those for which operations are + passed through to their targets may not really capture a class of + references that are useful. [what else?] + + Consequently, it was decided not to support direct references in + the short term. + +3.2 Overview + + A referential resource is a resource that has no content of its + own, but instead references another resource. The resource it + references may be in the same collection or anywhere else. This + target resource may be a collection or a simple resource or another + reference, or any other sort of resource that may be defined in the + future. A resource may be the target of any number of referential + resources. + + Since a referential resource is a resource, it can have properties + just like any other resource. These properties are completely + independent of the properties on its target resource. A new + DAV:reftarget property of referential resources has as its value the URI of the target resource. - An optional Ref-Integrity request header can be used to tell the - server not to create the referential member unless it can guarantee - referential integrity (Req 3.1.11). + To make it possible to distinguish referential resources from + ordinary resources, a new value of the DAV:resourcetype property + is defined here. The DAV:resourcetype property of all referential + resources MUST have the value reference. - An optional Position request header supports ordering by allowing - the client to specify where the new referential member is to be - placed in the collection's ordering. (This header can also be used - with M-PUT to create an internal collection member at a specific - position in the ordering.) + Although only weak, indirect references are currently supported, + two new DAV properties are defined in anticipation of future + support for strong references and direct references. These + properties, DAV:refintegrity and DAV:passthrough, will allow + clients to distinguish between weak and strong references, and + between indirect and direct references. All referential resources + MUST have these properties. Although the only value currently + defined for DAV:refintegrity is weak, other values may be defined + in the future. Although the only value currently defined for + DAV:passthrough is none, other values may be defined in the future. - When a server processes an M-PUT request with the - Referential-Member header, it MUST set the DAV:resourcetype - property [defined in Goland et al, 1998] of the new resource to be - refmember (Req 3.1.12). +3.3 Creating Referential Resources - When a server processes an M-PUT request with the - Referential-Member header, it MUST set the DAV:reftarget property - to the URI of the target resource (Req 3.1.6). +3.3.1 The MKREF Method - When a server processes an M-PUT request with the - Referential-Member header, it MUST set the DAV:refintegrity - property (Req 3.1.13). + Referential resources are created using the MKREF method. The + request-URI of the MKREF request identifies the resource to be + created. The required Ref-Target header contains the URI of the + target resource. - If DAV:refintegrity is T, the server MUST insure that the target - resource's DAV:refsource property reflects the new, strong - reference to that resource (Req 3.1.14). + An optional Ref-Integrity request header is defined below, + primarily for future support for strong references. The only value + currently defined for this header is "DAV:weak",although other + values may be used by private agreement. "DAV:weak" is the default + value if the header is not present. - The server SHOULD ignore any content submitted with a request to - create a referential member in a collection. + An optional Pass-Through request header is defined below, primarily + for future support for direct references. Currently, its value is + always empty, although other values may be used by private + agreement. The default value is empty if the header is not + present. - If an M-PUT request is submitted for an existing collection - member, the existing member's content and properties will be - overwritten. This behavior is analogous to the behavior of a plain - HTTP PUT method. If the Position header is absent in this case, - the server MUST leave the member at its previous position in the - collection ordering. If the Position header is present, the server - MUST remove it from its previous position, and then insert it at - the requested position. (Req 3.2.4) If the updated referential - member changes from weak to strong or from strong to weak, the - server MUST update the target's DAV:refsource property to reflect - the change. + An optional Position request header supports ordered collections by + allowing the client to specify where the new referential member is + to be placed in the collection's ordering. (This header can also + be used with PUT to create an ordinary collection member at a + specific position in the ordering.) - Example: + When a server processes a MKREF request, it MUST set the + DAV:resourcetype property (defined in [WebDAV]) of the new resource + to be DAV:reference. + + When a server processes a MKREF request, it MUST set the + DAV:reftarget property to the URI of the target resource. + + When a server processes a MKREF request, it MUST set the + DAV:refintegrity property and the DAV:passthrough property. + + The client MUST NOT send any content with the MKREF request, and so + MUST NOT use the Content-Length or Transfer-Encoding headers. (See + [HTTP].) + + If a MKREF request is submitted for an existing resource, the + existing resource's content and headers will be overwritten. This + behavior is analogous to the behavior of the HTTP PUT method. Live + properties may get new values at the server's discretion; dead + properties will retain their existing values. If the Position + header is absent in this case and the collection is ordered, the + server MUST leave the member at its previous position in the + collection ordering. If the Position header is present and the + collection is ordered, the server MUST remove it from its previous + position, and then insert it at the requested position. + +3.3.2 Status Codes + + 201 Created + 200 OK: modified an existing resource + 409 Conflict: no resource at Ref-Target + unrecognized / unsupported value for Ref-Integrity + unrecognized / unsupported value for Pass-Through + 400 Bad Request: content not allowed + 409 Conflict: Position Before / After a URI that is not in this + collection + 400 Bad Request: Position Before / After self + 409 Conflict: Position header, but not an ordered collection + 425 Insufficient Space on Resource + 409 Conflict: Parent collection does not exist + +3.3.3 Example Request: - M-PUT /~whitehead/dav/ HTTP/1.1 + MKREF /~whitehead/dav/spec08.ref HTTP/1.1 HOST: www.ics.uci.edu - Man: "DAV:Coll-headers" - Referential-Member: spec08.ref - Ref-Target: http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt - Ref-Integrity: T - Position: After requirements.html - Content-Length: 0 + Ref-Target: Response: - HTTP/1.1 200 OK + HTTP/1.1 201 Created - 3.3 Deleting Referential Members of a Collection (Req 3.1.8) + This request resulted in the creation of a new referential resource + at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the + resource identified by the Ref-Target header. Its DAV:resourcetype + property is set to DAV:reference. Its DAV:reftarget property is + set to the URI of its target resource. Its DAV:refintegrity + property is set to the default value of DAV:weak. Its + DAV:passthrough property is set to the default value of EMPTY. - DELETE is the appropriate method to use to remove a referential - member from a collection. DELETE on a referential member has no - affect on its target resource unless the referential member is a - strong reference. In this case, the server MUST insure that the - DAV:refsource property of its target resource reflects this change. +3.4 Deleting Referential Resources - Example: +3.4.1 The DELREF Method + + The new DELREF method is used to delete referential resources. + DELREF on a referential resource has no effect on its target + resource. + +3.4.2 Status Codes + + 200 OK + 405 Method Not Allowed: Request-URI is not a reference + 404 Not Found: No resource at Request-URI + +3.4.3 Example Request: - DELETE /~whitehead/dav/spec08.ref HTTP/1.1 + DELREF /~whitehead/dav/spec08.ref HTTP/1.1 HOST: www.ics.uci.edu Response: HTTP/1.1 200 OK - The referential member spec08.ref of collection /~whitehead/dav/ - has been deleted, but its target resource on www.ietf.org still - exists. The DAV:refsource property of http://www.ics.uci.edu/ - i-d/draft-webdav-protocol-08.txt has been updated - so that it no longer shows a reference from spec08.ref. + The referential resource /~whitehead/dav/spec08.ref has been + deleted, but its target resource still exists. - 3.4 Listing Referential Members of a Collection (Req 3.1.10) +3.4.4 Design Rationale + + The HTTP DELETE method can be used to delete indirect references, + since by definition these references do not pass operations through + to their targets. + + If direct references are supported in the future, however, a method + distinct from the HTTP DELETE method will be needed for deleting + the reference itself. Since direct references do pass operations + through to their targets, DELETE would delete the target resource + rather than the reference itself. + + DELREF is being introduced now in anticipation of future needs, + and can be used in all cases where a reference is to be deleted. + +3.5 Listing Referential Members of a Collection Since a referential member of a collection is just a resource in the collection, a listing of members of the collection shows - referential members along with internal members. That is, a - PROPFIND on a collection resource with Depth = 1 or infinity MUST - return a response XML element for each internal member and for each - referential member. + referential members along with ordinary members. That is, a WebDAV + PROPFIND request on a collection resource with Depth = 1 or + infinity MUST return a response XML element for each ordinary + member and for each referential member. - If Depth = infinity in the PROPFIND request, the server SHOULD NOT - follow references into any collections to which they may refer. + If Depth = infinity in the PROPFIND request, the server MUST NOT + follow indirect references into any collections to which they may + refer. - 3.5 Other Operations on Referential Members of a Collection +3.6 Other WebDAV Operations on Indirect Referential Resources - In general, operations that modify resources, when applied to a - referential member of a collection, affect the referential member, - not its target resource (Req 3.1.4). There is only one exception - to this general rule: For strong references, operations on the - referential member may cause changes to the refsource property - of its target resource. + By definition, operations on an indirect reference affect only the + reference, and not its target resource. Since only indirect + references are supported by this specification, WebDAV operations + that are applied to them affect only the referential resource, not + its target resource. - A LOCK operation on a referential member of a collection locks the - referential member, not its target. A LOCK on the collection with + A LOCK operation on an indirect reference locks the referential + resource, not its target. A LOCK on the collection with Depth = 1 or infinity locks the referential members along with all the other members of the collection, but not the targets of the - referential members. + indirect referential members. - A PROPPATCH on a referential member of a collection modifies the - properties of the referential member, not the properties of its + A PROPPATCH on an indirect referential resource modifies the + properties of the referential resource, not the properties of its target resource. - A MOVE operation on a referential member of a collection moves the - referential member to a different collection, but has no effect on - the location of its target. If the referential member was a strong - reference at its old location, the server MUST remove its old URI - from the list in the target's refsource property. If the client - wants the referential member at its new location to be a strong - reference, it must use the M-MOVE method with the Ref-Integrity - header to perform the move. If the server is able to comply with - the request, it MUST add the referential member's new URI to the - list in the refsource property of its target. + A PROPFIND on an indirect referential resource returns the + properties of the referential resource, not the properties of its + target resource. - A COPY operation on a referential member copies the referential - member, not its target resource, to another collection. If the - client wants the referential member in the new location to be a - strong reference, it must use the M-COPY method with the - Ref-Integrity header to perform the copy. If the server is able - to comply with the request, it MUST add the URI of the new copy to - the list in the refsource property of its target. + A MOVE operation on an indirect referential resource moves the + referential resource to a different location, but has no effect on + the location of its target. The DAV:reftarget property is unchanged + after a MOVE unless the Ref-Target header is used to change it. - A PUT operation (or an M-PUT without a Referential-Member header) - creates an internal collection member, not a referential member. - If a strong reference is replaced by an internal member as a result - of a PUT or M-PUT, the server MUST remove the URI of the - referential member from the DAV:refsource property of its target. + A COPY operation on an indirect referential resource copies the + referential resource, not its target resource, to another location. + The DAV:reftarget property of the destination resource is the same + as the DAV:reftarget of the source resource, unless the Ref-Target + header is used to change it. - Similarly, operations that retrieve information, when applied to a - referential member of a collection, retrieve information relating - to the referential member, not its target resource. A PROPFIND on - a referential member returns the properties of the referential - member, not the properties of its target resource. A GET on a - referential member of a collection returns its own content, which - is the URI of its target resource, not the content of its target - resource. +3.7 HTTP Operations on Indirect Referential Resources - 3.6 Operations on Targets of Referential Collection Members + Although existing HTTP clients cannot create referential resources, + they should be able to read collections created by Class 3 WebDAV + clients. They should be able to follow any references in those + collections to their targets. To make this possible, a server that + receives a GET or HEAD on an indirect reference MUST return a 302 + (Moved Temporarily) status code. The server MUST follow [HTTP] + Section 10.3.3 "302 Moved Temporarily," but with these additional + rules: - Operations on targets of referential collection members have no - effect on the referential member unless the referential member is - a strong reference. When the target of a strong reference is - MOVEd, the server MUST update the DAV:reftarget property of the - referential member to reflect its new location. When a client - attempts to delete a target of a strong reference, the server - MUST maintain referential integrity, either by deleting the - strong reference at the same time, or by failing the request to - delete the target. + o The Location header MUST contain the target URI of the + reference. -(Provide an error code and response type to tell the client the value of -the refsource property) + o The response MUST include a Resource-Type header with the + value "Reference". This header allows Class 3 WebDAV clients + to recognize the resource as a reference and understand the + reason for the redirection. + + o The response MUST also include those HTTP headers that make + sense for referential resources, at a minimum: Cache-Control, + Age, ETag, Expires, and Last-Modified. + + POST cannot be applied to an indirect reference. A reference + cannot accept another entity as its subordinate. Depending upon + the nature of the target resource, however, it might make sense to + apply POST to the target. A server that receives a POST request + on an indirect reference MUST return a 302 (Moved Temporarily). + The rules for constructing and using the response are the same as + for GET and HEAD, except that there is no requirement to return + Cache-Control, Age, ETag, Expires, or Last-Modified. + + PUT cannot be applied to an indirect reference. To replace one + indirect reference with another, MKREF MUST be used. To replace an + indirect reference with an ordinary resource, the reference MUST + first be deleted with DELREF, after which a PUT MUST be used to + create the ordinary resource. + + Existing HTTP clients that do not understand referential resources + need to be accommodated, however. To enable these clients to + operate reasonably on indirect references, a server that receives a + PUT request on an indirect reference MUST return a 302 (Moved + Temporarily). The client and server MUST follow [HTTP] Section + 10.3.3 "302 Moved Temporarily," but with these additional rules: + + o The Location response header MUST contain the target URI of + the reference. + + o The response MUST include a Resource-Type header, defined in + Section 5.n below, with the value "Reference". This header + allows Class 3 WebDAV clients to recognize the resource as a + reference and understand the reason for the redirection. + + o The response MUST include an entity body for display to users. + The entity body explains that the requested resource is a + reference to another resource, and allows the user to choose + whether to replace the target resource or to replace the + reference. + + This last rule is needed for PUT, but not for GET, HEAD, or + POST. Only for PUT does it make sense for the user to confirm + that the operation is to be performed at the request-URI. GET or + HEAD will already have returned all useful information about the + request-URI. POST makes no sense for the indirect reference at the + request-URI. But the user might really want to replace the + indirect reference with the entity in the PUT request. + + Although the new DELREF method has been defined for deleting + references, DELETE can be used to delete an indirect reference. + Since by definition operations on an indirect reference affect the + reference, and not its target, DELETE will delete the indirect + reference and leave its target untouched. + +3.8 Operations on Targets of Referential Resources + + Operations on targets of weak, indirect referential resources have + no effect on the referential resource. 4 Ordered Collections - A new optional property DAV:ordering is defined to support ordered - collections. (Req 3.2.1) It is a property only of collections, - and is not required to be present on a collection. That is, even - compliant servers may have a mix of ordered and unordered - collections. The client decides whether a particular collection - is ordered or not. (Req 3.2.2) The value DAV:ordering is an - ordering-type (Req 3.2.3) followed by a list of the URIs of the - collection's members. Each collection member, whether internal or - referential, must be in the list exactly once (Req 3.2.4, 3.2.8), - and the list must not include any resource that is not a member of - the collection (Req 3.2.5). Only one ordering can be attached to - any collection (Req 3.2.5a). Multiple orderings of the same - resources can be achieved by creating multiple collections - referencing those resources, and attaching a different ordering to - each collection. +4.1 Overview - The ordering-type, represented by the new DAV:orderingtype XML - element,is an href identifying the semantics of the ordering. The - href SHOULD point to a resource that contains a definition of the - semantics of the ordering, allowing a human user or software + Collections on a compliant server may be ordered, but need not be. + It is up to the client to decide whether a given collection is + ordered and, if so, to specify the semantics to be used for + ordering its members. If a collection is ordered, each of its + members must be in the ordering exactly once, and the ordering must + not include any resource that is not a member of the collection. + Only one ordering can be attached to any collection. Multiple + orderings of the same resources can be achieved by creating + multiple collections referencing those resources, and attaching a + different ordering to each collection. + + The server is responsible for enforcing these constraints on + orderings. The server MUST remove a resource from the ordering + when it is removed from the collection. The server MUST add a + resource to the ordering when it is added to the collection. + + When responding to a PROPFIND on a collection, the server MUST + order the response elements according to the ordering defined + on the collection. + +4.2 Creating an Ordered Collection + +4.2.1 Overview + + When a collection is created, the client can request that it be + ordered and specify the semantics of the ordering by using the + new Ordered header in the MKCOL request, setting its value to the + URI of the semantics to be used. If the client does not want the + collection to be ordered, it may omit the Ordered header, or use + it with the value "DAV:arbitrary". + + Every collection MUST have the new DAV:orderingtype property, + which indicates whether the collection is ordered and, if so, + identifies the semantics of the ordering. A value of DAV:arbitrary + indicates that that collection is not ordered. That is, the client + cannot depend on the repeatability of the ordering of results from + a PROPFIND request. Otherwise the value of DAV:orderingtype is an + href that SHOULD point to a resource that contains a definition of + the semantics of the ordering, allowing a human user or software package to insert new collection members into the ordering - intelligently. (Req 3.2.3) + intelligently. - A client may order the members of a collection with the - DAV:ordering property of the collection. The client may use - PROPFIND to discover the current ordering of the collection, and - PROPPATCH on the ordering property to modify the ordering. It is - also possible to insert an internal or referential collection - member into the ordering at the time the member is is added to the - collection, by using the Position header with the M-PUT, M-COPY, - or M-MOVE request. (Req 3.2.9) + If the Ordered header is present on a MKCOL request, the server + MUST set the collection's DAV:orderingtype property to the value of + the Ordered header. If the Ordered header is not present, the + server MUST treat the request as if it had an Ordered header with + the value "DAV:arbitrary", meaning that the collection is not + ordered. If the collection is ordered, the server MUST respond to + PROPFIND requests on the collection using the specified ordering. - The DAV:ordering property is live only to the extent that the - server MUST remove an href from the ordering when a member is - removed from the collection, and the server MUST add the href to - the ordering whenever a member is added to the collection. It MUST - insert the new member at the location specified in the Position - header, if present in the M-PUT request; otherwise, it MUST append - the new member to the end of the ordering. If a PUT or M-Put causes - an existing resource to be replaced, and if the Position header - is absent, the server MUST leave the member at its previous - position in the collection ordering. If the Position header is - present, the server MUST remove the member from its previous - position, and then insert it at the requested position. Whenever - the server receives a PROPPATCH request on the DAV:ordering - property, it MUST verify that each member of the collection appears - in the ordering exactly once. (Reqs 3.2.4, 3.2.5) +4.2.2 Status Codes - When responding to a PROPFIND on a collection, the server MUST - order the response elements according to the DAV:ordering property - on the collection. (Req 3.2.6) + No new error conditions are introduced. - 5 New Headers +4.2.3 Example - 5.1 Referential-Member Request Header + Request: - Referential-Member = "Referential-Member" ":" relative URI + MKCOL /theNorth/ HTTP/1.1 + Host: www.server.org + Ordered: - The Referential-Member request header is used with the M-PUT method - to identify the new referential member to be added to the - collection. The URI is relative to the collection identified by - the request-URI. It is a required header in requests to add a - referential member to a collection. + Response: - 5.2 Ref-Target Request Header + HTTP/1.1 201 Created - Ref-Target = "Ref-Target" ":" URI + In this example, a new, ordered collection was created. Its + DAV:orderingtype property has as its value the URI from the + Ordered header. In this case, the URI points to a description of + the semantics governing the ordering. As new members are added to + the collection, clients or end users can consult the semantics to + determine how to position the new members in the ordering. - The Ref-Target request header is used with the M-PUT method to - identify the target resource of the new referential member being - added to a collection. It is a required header in requests to add - a referential member to a collection. +4.3 Setting the Position of a Collection Member + +4.3.1 Overview + + When a new member is added to a collection with MKREF, PUT, COPY, + or MOVE, its position in the ordering can be set with the new + Position header. The Position header allows the client to specify + that the member should be first in the collection's ordering, last + in the collection's ordering, before some other collection member + in the collection's ordering, or after some other collection member + in the collection's ordering. + + The server MUST insert the new member into the ordering at the + location specified in the Position header, if one is present (and + if the collection is ordered); otherwise, it MUST append the new + member to the end of the ordering (if the collection is ordered). + If a PUT or MKREF causes an existing resource to be replaced, and + if the Position header is absent, the server MUST leave the member + at its previous position in the collection ordering. If the + Position header is present, the server MUST remove the member from + its previous position, and then insert it at the requested + position. + +4.3.2 Status Codes + + 201 Created + 409 Conflict: Before / After a URI that is not in this collection + 400 Bad Request: Before / After self + 405 Method Not Allowed: Not an ordered collection + +4.3.3 Examples + + Request: + + MKREF /~whitehead/dav/spec08.ref HTTP/1.1 + HOST: www.ics.uci.edu + Ref-Target: + Position: After + + Response: + + HTTP/1.1 201 Created + + This request resulted in the creation of a new referential resource + at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the + resource identified by the Ref-Target header. The Position header + in this example caused the server to set its position in the + ordering of the /~whitehead/dav/ collection immediately after the + requirements.html resource. + + Request: + + MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1 + Host: www.ics.uci.edu + Destination: + Position: First + + Response: + + HTTP/1.1 409 Conflict + + In this case, the server returned a 409 Conflict status code + because the /~whitehead/dav/ collection is an unordered collection. + + Consequently, the server was unable to satisfy the Position + header. + +4.4 Changing the Semantics of a Collection Ordering + + After a collection has been created, a client can change its + ordering semantics, or change an ordered collection to an unordered + collection or vice versa, by using PROPPATCH to change the value of + its DAV:orderingtype property. The client is then responsible for + updating the ordering of the collection members according to the + new semantics. PROPPATCH is defined in [WebDAV], Section 7.2. + +4.5 Changing the Position of a Collection Member + +4.5.1 The ORDERPATCH Method + + To change the position of a collection member in the collection's + ordering, the client MUST use an ORDERPATCH request with a request + body containing an order XML element. The request-URI of an + ORDERPATCH request is the URI of the collection whose ordering is + to be updated. The order XML element identifies the member + resource whose position is to be changed, and describes its new + position in the ordering. The new position can be specified as + first in the ordering, last in the ordering, before some other + collection member in the ordering, or after some other collection + member in the ordering. + +4.5.2 Status Codes + + Although the protocol currently allows only a single change to be + requested with ORDERPATCH, it is anticipated that this may change + in the future. Consequently, the server MUST return a 207 + Multi-Status response, as defined in [WebDAV]. + + Within the 207 Multi-Status response, the following status codes + are possible: + + 200 OK + 409 Conflict: Before / After a URI that is not in this collection + 409 Conflict: href doesn't point to a member of this collection + 400 Bad Request: only one change allowed + 400 Bad Request: Before / After self + 405 Method Not Allowed: Not an ordered collection + 405 Method Not Allowed: Not a collection + (It's ok to reposition to the same position) + +4.5.3 Example + + Consider a collection /coll-1/ with members ordered as follows: + + nunavut.map + nunavut.img + baffin.map + baffin.desc + baffin.img + iqaluit.map + nunavut.desc + iqaluit.desc + iqaluit.img + + Request: + + ORDERPATCH /coll-1/ HTTP/1.1 + Host: www.nunanet.com + Content-Type: text/xml + Content-Length: xxx + + + + + + nunavut.desc + + + nunavut.map + + + + + + Response: + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml + Content-Length: xxx + + + + + + http://www.nunanet.com/coll-1/nunavut.desc + HTTP/1.1 200 OK + + + + In this example, after the request has been processed, the + map of nunavut is the first member in the collection's ordering: + + nunavut.map + nunavut.desc + nunavut.img + baffin.map + baffin.desc + baffin.img + iqaluit.map + iqaluit.desc + iqaluit.img + +4.5.4 Design Rationale + The decision to introduce the new ORDERPATCH method was made after + investigating the possibility of using the existing MOVE method + with a Position header. The use of MOVE initially looked + appealingly simple: + + MOVE /root/coll-1/foo HTTP/1.1 + Host: www.somehost.com + Destination: + Position: First + + Unfortunately, several features of the semantics of MOVE make it + unsuitable for changing the position of a collection member in the + collection's ordering. First, [WebDAV] defines MOVE as logically + equivalent to a copy followed by a delete of the source resource. + This definition makes it impossible to MOVE a resource to a + destination URL that is the same as the source URL. The resource + would be deleted rather than moved. Second, [WebDAV] states that + when moving a resource to a destination where a resource already + exists, the Overwrite header must be "T", and in this case the + server must DELETE the resource at the destination before + performing the MOVE. Again, this makes it impossible to MOVE + a resource to the same location. Finally, [WebDAV] states that + locks are lost on a MOVE, an outcome that seems undesirable in this + case. + + The decision to allow only a single change to be described in a + PROPPATCH request was made in order to accommodate many existing + systems that do not allow multiple changes to be requested at once. + However, the protocol design is extensible to support multiple + requests in the future. + + In particular, the decision to define a new order XML element for + ORDERPATCH was made for the sake of extensibility. Although the + current definition of the order XML element allows only a single + change in the ordering per ORDERPATCH request, using an XML element + keeps open the option of later allowing multiple changes to be + described in a single ORDERPATCH request. Similarly, a + Multi-Status response is used in order to keep open the option of + multiple changes in a single request in the future. + +5 New Headers + +5.1 Ref-Target Request Header + + Ref-Target = "Ref-Target" ":" Coded-url + + Coded-url is defined in [WebDAV], Section 8.4. + + The Ref-Target request header is used with the MKREF method to + identify the target resource of the new referential resource being + created. It is a required header in MKREF requests. This header + may also be used with COPY and MOVE requests to change the target + of the destination reference. 5.2 Ref-Integrity Request Header + Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak") - Ref-Integrity = "Ref-Integrity" ":" ("T" | "F") + The Ref-Integrity header is defined to allow future support for + strong references. It specifies whether the server should + enforce referential integrity for a referential resource being + created with MKREF. The only value currently defined for the + Ref-Integrity header is "DAV:weak", which means that the server + need not [should not? must not?] enforce referential integrity for + the newly created reference. Other values may be used by private + agreement between the client and server. If the header is not + present on a MKREF request, the server MUST treat the request as + if it has a Ref-Integrity header set to "DAV:weak". This header + may also be used with COPY and MOVE requests. If this header is + not present on a COPY or MOVE request, the DAV:refintegrity + property MUST be treated like any other live property, as + specified in [WebDAV] sections 7.8.2 and 7.9.1. - The Ref-Integrity header specifies whether the server should - enforce referential integrity for a referential member of a - collection being created with M-PUT. If the value of the header is - "T", the server MUST fail the request unless it can guarantee - referential integrity. If the header is not used, the server MUST - treat the request as if it has a Ref-Integrity header set to "F". +5.3 Pass-Through Request Header - 5.3 Position Request Header + Pass-Through = "Pass-Through" ":" "" - Position = "Position" ":" ("First" | "Last" | ("At" index) | - (("Before" | "After") URI)) - index = integer + The Pass-Through header is defined to allow future support for + direct references. Indirect references do not pass operations + through to their target resources, so for them the value of + the Pass-Through header is empty. Direct references pass all + operations through to their target resources. Other types of + references may pass certain operations through, while others may + affect the reference itself. Since only indirect references are + supported today, the only value currently defined for Pass-Through + is empty. Other values may be used by private agreement between + the client and server. If the header is not present on a MKREF + request, the server MUST treat the request as if it has a + Pass-Through header with the value empty. This header may also be + used with a COPY or MOVE request on a reference. If this header is + not present on a COPY or MOVE request, the DAV:passthrough + property MUST be treated like any other live property, as + specified in [WebDAV] sections 7.8.2 and 7.9.1. - The Position header may be used with M-PUT to tell the server - where in the collection ordering to position the collection member - being added. It may be used for both internal and referential - members. +5.4 Resource-Type Response Header + + Resource-Type = "Resource-Type" ":" ["DAV:collection" | + "DAV:reference" | ""] + + The Resource-Type response header contains the value of the + DAV:resourcetype property. It is used with 302 responses to PUT, + POST, GET, or HEAD requests on referential resources to indicate to + the client that the reason for the redirection is that the + request-URI pointed to a referential resource. + +5.5 Ordered Request Header + + Ordered = "Ordered" ":" ("DAV:arbitrary" | Coded-url) + + The Ordered request header may be used with MKCOL to request that + the new collection be ordered and to specify its ordering + semantics. A value of "DAV:arbitrary" indicates that the + collection is not ordered. That is, the client cannot depend on + the repeatability of the ordering of results from a PROPFIND + request. A Coded-url value indicates that the collection is + ordered, and identifies the semantics of the ordering. The + Coded-url SHOULD point to a resource that contains a definition of + the semantics of the ordering, allowing a human user or software + package to insert new collection members into the ordering + intelligently. + + If the Ordered header is not present on a MKCOL request, the + server MUST treat the request as if it had an Ordered header with + the value "DAV:arbitrary". + +5.6 Position Request Header + + Position = "Position" ":" ("First" | "Last" | + (("Before" | "After") Coded-url)) + + The Position header may be used with MKREF, PUT, COPY, or MOVE to + tell the server where in the collection ordering to position the + resource being added to the collection. It may be used for both + ordinary and referential members. + + If the Coded-url is a relative URL, it is interpreted relative to + the collection in which the resource is being created. If the Position request header is not used, then: If the request is replacing an existing resource, the server MUST preserve the present ordering. If the request is adding a new member to the collection, the - server MUST append the new member to the end of the list in the - DAV:ordering property (if the collection is ordered). + server MUST append the new member to the end of the ordering + (if the collection is ordered). 6 New Properties 6.1 reftarget Property Name: reftarget Namespace: DAV: - Purpose: A property of referential collection members that + Purpose: A required property of referential resources that provides an efficient way for clients to discover - the URI of the target resource. + the URI of the target resource. This is a readonly + property, whose value can only be set by using the + Ref-Target header with a MKREF, COPY, or MOVE + request. Value: URI of the target resource. - 6.2 refsource Property - Name: refsource +6.2 refintegrity Property + Name: refintegrity Namespace: DAV: - Purpose: A property of targets of strong referential - collection members that provides a list of all - strong referential collection members that - reference the resource. Aids the server in - maintaining referential integrity, and allows - clients to discover which strong referential - members reference the target resource. - Value: List of URIs of strong referential collection - members that reference the resource. + Purpose: A required property of a referential resource that + indicates whether the server guarantees referential + integrity for that reference. The refintegrity + property is defined to allow future support for + strong references. The only value currently + defined for refintegrity is weak, which means that + the server need not [does not?] enforce referential + integrity for the reference. Other values may be + used by private agreement between the client and + server. This is a readonly property, whose value + can only be set by using the Ref-Integrity header + with a MKREF, COPY, or MOVE request. + Value: weak - + - 6.3 refintegrity Property +6.3 passthrough Property - Name: refintegrity - Namespace: DAV: - Purpose: A property of referential collection members that - indicates whether the server guarantees referential - integrity for that reference. - Value: "T" for strong references, "F" for weak references. + Name: passthrough + Namespace: DAV + Purpose: A required property of a referential resource that + indicates what operations are passed through to its + target resource. The passthrough property is + defined to allow future support for direct + references, which pass all operations through to + their targets. This specification currently + supports only indirect references, which do not + pass any operations through to their targets. The + only value currently defined for passthrough is + EMPTY. Other values may be used by private + agreement between the client and server. This is + a read-only property, whose value can only be set + by using the Pass-Through header with a MKREF, + COPY, or MOVE request. + Value: EMPTY - + - 6.4 ordering Property +6.4 orderingtype Property - Name: ordering + Name: orderingtype Namespace: DAV: - Purpose: A property of a collection, specifying the order - of the members of the collection. - Value: A typed list of URIs of the members of the - collection. Each member of the collection, whether - internal or referential, must be in the list - exactly once. + Purpose: Indicates whether the collection is ordered and, if + so, uniquely identifies the semantics of the + ordering being used. SHOULD also provide an + explanation of the semantics in human and / or + machine-readable form. At a minimum, this allows + human users who add members to the collection to + understand where to position them in the ordering. + Value: arbitrary for an unordered collection, or a URI + that uniquely identifies the semantics of the + collection's ordering. The URI SHOULD point to + a definition of the ordering semantics. - + 7 New XML Elements - 7.1 orderingtype XML Element +7.1 reference XML Element - Name: orderingtype + Name: reference Namespace: DAV: - Purpose: Uniquely identifies the semantics of the ordering - being used. SHOULD also provide an explanation of - the semantics in human and / or machine-readable - form. At a minimum, this allows human users who - add members to the collection to understand where - to position them in the ordering. - Value: URI that uniquely identifies the semantics of the - ordering and that SHOULD point to an definition of - the ordering semantics. + Purpose: A new value of the DAV:resourcetype property that + identifies its resource as a referential resource. + The DAV:resourcetype property of a referential + resource MUST have this value. + Value: EMPTY - - 7.2 refmember XML Element + - Name: refmember +7.2 weak XML Element + + Name: weak Namespace: DAV: - Purpose: A new value of the DAV:resourcetype property that - identifies its resource as a referential member of - a collection. The DAV:resourcetype property of a - referential member of a collection MUST have this - value. + Purpose: The only value currently defined for the + DAV:refintegrity property. It means that the + server need not [does not?] enforce referential + integrity for the reference to which the property + belongs. Value: EMPTY - + + +7.3 arbitrary XML Element + + Name: arbitrary + Namespace: DAV: + Purpose: A value of the DAV:orderingtype property that + indicates that the collection is not ordered. That + is, the client cannot depend on the repeatability + of the ordering of results from a PROPFIND request. + Value: EMPTY + + + +7.4 order XML Element + + Name: order + Namespace: DAV + Purpose: For use with the new ORDERPATCH method. Describes + a change to be made in a collection ordering. + Value: A description of the new position of a collection + member in the collection's ordering. + + + +7.5 member XML Element + Name: member + Namespace: DAV + Purpose: Occurs in the order XML Element, and describes the + new position of a single collection member in the + collection's ordering. + Value: An href containing the relative URI of the + collection member, and a description of its new + position in the ordering. The href XML element is + defined in [WebDAV], Section 11.3. + + + +7.6 position XML Element + + Name: position + Namespace: DAV + Purpose: Occurs in the member XML element. Describes the + new position in a collection's ordering of one of + the collection's members. + Value: The new position can be described as first in the + collection's ordering, last in the collection's + ordering, before some other member of the + collection, or after some other member of the + collection. + + + +7.7 first XML Element + + Name: first + Namespace: DAV + Purpose: Occurs in the position XML element. Describes the + collection member's position as first in the + collection's ordering. + Value: EMPTY + + + +7.8 last XML Element + + Name: last + Namespace: DAV + Purpose: Occurs in the position XML element. Describes the + collection member's position as last in the + collection's ordering. + Value: EMPTY + + + +7.9 before XML Element + + Name: before + Namespace: DAV + Purpose: Occurs in the position XML element. Describes the + collection member's position as coming before some + other collection member in the collection's + ordering. + Value: href of the member it precedes in the ordering + + + +7.10 after XML Element + + Name: after + Namespace: DAV + Purpose: Occurs in the position XML element. Describes the + collection member's position as coming after some + other collection member in the collection's + ordering. + Value: href of the member it follows in the ordering + + 8 Compliance Section 14 of [Goland et al, 1998] defined a DAV header for use when responding to OPTIONS requests. This header provides a way for clients to discover which parts of WebDAV a resource supports. The WebDAV specifications define numbered compliance classes corresponding to collections of related functions that resources may support. When the server receives an OPTIONS request, it lists the classes that the request-URI supports in the DAV response header. Since this specification defines two independent sets of functionality, it defines two new compliance classes. A WebDAV server may support neither, one or the other, or both for any resource. 8.1 Class 3 This new compliance class indicates compliance with Section 3 - "Referential Members" of this specification. Servers that comply + "Referential Resources" of this specification. Servers that comply with Section 3 MUST list this class in the DAV response header when they respond to an OPTIONS request. 8.2 Class 4 This new compliance class indicates compliance with Section 4 "Ordered Collections" of this specification. Servers that comply with Section 4 MUST list this class in the DAV response header when they respond to an OPTIONS request. 9 Dependencies on Other Specifications - [Nielsen et al., 1998] "Mandatory Extensions in HTTP." + TBD 10 Security Considerations + This section is provided to detail issues concerning security + implications of which WebDAV applications need to be aware. + + All of the security considerations of HTTP/1.1 and the base WebDAV + protocol also apply to WebDAV collections. In addition, + referential resources and ordered collections introduce several + new security concerns and increase the risk of some existing + threats. These issues are detailed below. + +10.1 Redirect Loops + + Although redirect loops were already possible in HTTP 1.1, the + introduction of referential resources creates a new avenue for + clients to create loops accidentally or maliciously. If the + referential resource and its target are on the same server, the + server may be able to detect MKREF requests that would create + loops. See also [HTTP], Section 10.3 "Redirection 3xx." + +10.2 References and Denial of Service + + The introduction of referential resources creates a new avenue + for denial of service attacks. Clients can create heavily used + references to target locations that were not designed for heavy + usage. + +10.3 Malicious Modifications of Ordering + + Particularly in large collections, moving a collection member to + a different position in the ordering can make it very difficult + for users to find. + +10.4 Denial of Service and DAV:orderingtype + + There may be some risk of denial of service at sites that are + advertised in the DAV:orderingtype property of collections. + However, it is anticipated that widely-deployed applications will + use hard-coded values for frequently-used ordering semantics + rather than looking up the semantics at the location specified by + DAV:orderingtype. + 11 Internationalization Considerations + This specification follows the practices of [WebDAV] in encoding + all human-readable content using XML [XML] and in the treatment + of names. Consequently, this specification complies with the + IETF Character Set Policy [Alvestrand]. + + WebDAV applications MUST support the character set tagging, + character set encoding, and the language tagging functionality of + the XML specification. This constraint ensures that the human- + readable content of this specification complies with [Alvestrand]. + + As in [WebDAV}, names in this specification fall into three + categories: names of protocol elements such as methods and + headers, names of XML elements, and names of properties. Naming + of protocol elements follows the precedent of HTTP, using English + names encoded in USASCII for methods and headers. The names of + XML elements used in this specification are English names encoded + in UTF-8. + + For error reporting, [WebDAV] follows the convention of HTTP/1.1 + status codes, including with each status code a short, English + description of the code (e.g., 423 Locked). Internationalized + applications will ignore this message, and display an appropriate + message in the user's language and character set. + + For rationales for these decisions and advice for application + implementors, see [WebDAV]. + 12 IANA Considerations + TBD + 13 Copyright 14 Intellectual Property 15 Acknowledgements + This draft has benefited from thoughtful discussion by + Steve Carter, Ellis Cohen, Spencer Dawkins, Rajiv Dulepet, + Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, + Marcus Jager, Rohit Khare, Daniel LaLiberte, Steve Martin, + Surendra Koduru Reddy, Sam Ruby, Bradley Sergeant, Nick Shelness, + John Stracke, John Tigue, John Turner, and others. + 16 References - [Goland et al., 1998] Y. Y. Goland, E. J. Whitehead, Jr., A. + [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav- protocol-08. Internet Draft, work in progress. Microsoft, U.C. Irvine, Netscape, Novell. April, 1998. - [Slein, 1998] J. Slein, "Requirements for Advanced Collection - Functionality in WebDAV." Draft-ietf-webdav-collection-reqts-01. - Internet Draft, work in progress. Xerox, 1998. + [DASL] Saveen Reddy, D. Jensen, Surendra Reddy, + R. Henderson, J. Davis, A. Babich, "DAV Searching & Locating." + Draft-reddy-dasl-protocol-02. Internet Draft, work in progress. + Microsoft, Novell, Oracle, Netscape, Xerox, Filenet. June, 1998. - [Nielsen et al., 1998] H. F. Nielsen, P. Leach, S. Lawrence, - "Mandatory Extensions in HTTP." Draft-ietf-http-ext-mandatory-00. - Internet Draft, work in progress. W3C, Microsoft, Agranat, 1998. + [WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced + Collection Functionality in WebDAV." Draft-ietf-webdav-collection- + reqts-02. Internet Draft, work in progress. Xerox, 1998. + + [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, + T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." + RFC 2068. UC Irvine, DEC, MIT/LCS. January, 1997. + + [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup + Language (XML)." World Wide Web Consortium Recommendation + REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 17 Authors' Addresses J. Slein Xerox Corporation 800 Phillips Road, 105-50C Webster, NY 14580 Email: slein@wrc.xerox.com - Expires December 5, 1998 + J. Davis + Xerox Corporation + 3333 Coyote Hill Road + Palo Alto, CA 94304 + Email: jdavis@parc.xerox.com + + A. Babich + FileNet Corporation + 3565 Harbor Boulevard + Costa Mesa, CA 92626-1420 + Email: ababich@filenet.com + + E.J. Whitehead Jr. + Dept. of Information and Computer Science + University of California, Irvine + Irvine, CA 92697-3425 + Email: ejw@ics.uci.edu + + Expires January 31, 1999