WEBDAV Working Group J. Slein, Xerox INTERNET DRAFT E.J. Whitehead Jr., UC Irvine J. Davis, CourseNet G. Clemm, Rational C. Fay, FileNet J. Crawford, IBM T. Chihaya, DataChannel August 20, 1999 Expires February 20, 2000 WebDAV Ordered Collections Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments 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 WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines a protocol supporting server-side ordering of collection members. The companion specifications [B] and [RR] define two mechanisms for allowing a single resource to appear in more than one collection. Table of Contents 1 Notational Conventions.......................................2 2 Introduction.................................................3 3 Terminology..................................................3 4 Overview of Ordered Collections..............................4 5 Creating an Ordered Collection...............................4 5.1 Overview.....................................................4 Slein et al. Page 1 Internet-Draft WebDAV Ordered Collections August 1999 5.2 Example: Creating an Ordered Collection......................5 6 Setting the Position of a Collection Member..................5 6.1 Overview.....................................................5 6.2 Status Codes.................................................6 6.3 Examples: Setting the Position of a Collection Member........6 7 Changing the Semantics of a Collection Ordering..............6 8 Changing the Position of a Collection Member.................7 8.1 ORDERPATCH Method............................................7 8.1.1 Status Codes.................................................7 8.1.2 Example: Changing Positions in an Ordered Collection.........7 8.1.3 Example: Failure of an ORDERPATCH Request....................9 9 Listing the Members of an Ordered Collection................10 9.1 Example: PROPFIND on an Ordered Collection..................10 10 Headers.....................................................12 10.1 Ordered Entity Header.......................................12 10.2 Position Request Header.....................................12 11 Status Codes................................................13 11.1 425 Unordered Collection....................................13 12 Properties..................................................13 12.1 orderingtype Property.......................................13 13 XML Elements................................................14 13.1 unordered XML Element.......................................14 13.2 custom XML Element..........................................14 13.3 order XML Element...........................................14 13.4 ordermember XML Element.....................................14 13.5 position XML Element........................................15 13.6 first XML Element...........................................15 13.7 last XML Element............................................15 13.8 before XML Element..........................................15 13.9 after XML Element...........................................15 13.10 options XML Element.........................................16 13.11 orderingoptions XML Element.................................16 14 Capability Discovery........................................16 14.1 Example: Discovery of Support for Ordering..................16 14.2 Additional Capabilities.....................................17 14.3 Example: Discovery of Ordering Options......................17 15 Security Considerations.....................................18 15.1 Denial of Service and DAV:orderingtype......................18 16 Internationalization Considerations.........................18 17 IANA Considerations.........................................19 18 Copyright...................................................19 19 Intellectual Property.......................................19 20 Acknowledgements............................................19 21 References..................................................19 22 Authors' Addresses..........................................20 23 Appendices..................................................20 23.1 Appendix 1: Extensions to the WebDAV Document Type Definition..................................................21 1 Notational Conventions Since this document describes a set of extensions to the HTTP/1.1 protocol, the augmented BNF used here to describe protocol elements is exactly the same as described in Section 2.1 of [HTTP]. Since this augmented BNF uses the basic production rules provided in Section 2.2 of Slein et al. Page 2 Internet-Draft WebDAV Ordered Collections August 1999 [HTTP], these rules apply to this document as well. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2 Introduction The simple collections that the WebDAV Distributed Authoring Protocol 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 members to them and removing members 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. This specification is one of a family of three specifications that build on the infrastructure defined in [HTTP] and [WebDAV] to extend the capabilities of collections. The companion specifications [B] and [RR] define mechanisms for allowing the same resource to appear in multiple collections. The present specification defines protocol extensions to support ordered collections. The WebDAV Distributed Authoring Protocol added to the Web the ability to navigate Web resources hierarchically, complementing existing hypertext navigation facilities. In hypertext navigation, links appear in a specific order in a document. By contrast, hierarchical navigation has fewer mechanisms for expressing the ordering of a set of resources. There are many scenarios where it is useful to impose an ordering on a collection, such as expressing a recommended access order, or a revision history order. Orderings may be based on property values, but they may be completely independent of any properties on the resources identified by the collection's internal member URIs. Orderings based on properties can be obtained using a search protocol, but orderings not based on properties need some other mechanism. These orderings generally need to be maintained by a human user. The ordering protocol defined here focuses on support for such human-maintained orderings, but also allows for server-maintained orderings. 3 Terminology The terminology used here follows that in the WebDAV Distributed Authoring Protocol specification [WebDAV]. Definitions of the terms resource, Uniform Resource Identifier (URI), and Uniform Resource Locator (URL) are provided in [URI]. Definitions of the terms URI mapping, path segment, binding, collection, and internal member URI are provided in [B]. Ordered Collection A collection for which the results from a PROPFIND request are guaranteed to be in the order specified for that collection Unordered Collection Slein et al. Page 3 Internet-Draft WebDAV Ordered Collections August 1999 A collection for which the client cannot depend on the repeatability of the ordering of results from a PROPFIND request Client-Maintained Ordering An ordering of collection members that is maintained on the server based on client requests specifying the position of each collection member in the ordering Server-Maintained Ordering An ordering of collection members that is maintained automatically by the server, based on a client's choice of ordering semantics 4 Overview of Ordered Collections When responding to a PROPFIND on a collection, the server orders the response elements according to the ordering defined on the collection. If a collection is unordered, the client cannot depend on the repeatability of the ordering of results from a PROPFIND request. 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 bindings. If a collection is ordered, each of its bindings, and hence internal member URIs, MUST be in the ordering exactly once, and the ordering MUST NOT include any binding that is not contained by the collection. Only one ordering can be attached to any collection. An ordering is considered to be part of the state of a collection resource, and hence is the same across all URI mappings to the 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 binding (and its derived internal member URI) from the ordering when it is removed from the collection. The server MUST add a binding (and its derived internal member URI) to the ordering when it is added to the collection. 5 Creating an Ordered Collection 5.1 Overview When a collection is created, the client MAY request that it be ordered and specify the semantics of the ordering by using the new Ordered header (defined in Section 8.1) with a MKCOL request. For collections that are ordered, the client SHOULD identify the semantics of the ordering with a URI in the Ordered header. This URI may identify a server-maintained ordering. Clients can discover the available server-maintained orderings using the mechanism defined in Section 12.2. The URI may identify a semantics for a client-maintained ordering, providing the information a human user or software package needs to insert new collection members into the ordering intelligently. Although the URI in the Ordered header MAY point to a resource that contains a definition of the semantics of the ordering, clients are Slein et al. Page 4 Internet-Draft WebDAV Ordered Collections August 1999 discouraged from accessing that resource, in order to avoid overburdening its server. The client MAY set the header value to DAV:custom to indicate that the collection is ordered, but the semantics of the ordering are not being advertised. If the client does not want the collection to be ordered, it may omit the Ordered header, or use it with the value DAV:unordered. If the server does not recognize the value of the Ordered header as one of its server-maintained orderings, it MUST assume that a client- maintained ordering is intended. If the value of the Ordered header is one of the server-maintained orderings that the server supports, it MUST maintain the collection's ordering according to that ordering semantics as new members are added. Every collection MUST have a DAV:orderingtype property (defined in Section 10.1), which indicates whether the collection is ordered and, if so, identifies the semantics of the ordering. The server sets the initial value of this property based on the value of the Ordering header in the MKCOL request. If the collection is unordered, the DAV:orderingtype property MUST have the value DAV:unordered. An ordering-aware client interacting with an ordering-unaware server (e.g., one that is implemented only according to [WebDAV]) SHOULD assume that if a collection does not have the DAV:orderingtype property, the collection is unordered. 5.2 Example: Creating an Ordered Collection >>Request: MKCOL /theNorth/ HTTP/1.1 Host: www.server.org Ordered: >>Response: HTTP/1.1 201 Created In this example a new, ordered collection was created. Its DAV:orderingtype property has as its value the URI from the Ordered header, http://www.server.org/orderings/compass.html. In this case, the URI identifies the semantics governing a client-maintained ordering. As new members are added to the collection, clients or end users can use the semantics to determine where to position the new members in the ordering. 6 Setting the Position of a Collection Member 6.1 Overview When a new member is added to a collection with a client-maintained ordering (for example, with PUT, MKREF, or MKCOL), its position in the ordering can be set with the new Position header (defined in Section 8.2). 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, immediately before some other binding in the collection's Slein et al. Page 5 Internet-Draft WebDAV Ordered Collections August 1999 ordering, or immediately after some other binding in the collection's ordering. 6.2 Status Codes 409 (Conflict): The request specifies a position that is before or after a URI that is not an internal member URI of the collection, or before or after itself. 425 (Unordered Collection): The request specifies a collection position in an unordered collection or in a collection with a server-maintained ordering. 6.3 Examples: Setting the Position of a Collection Member >>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 requirements.html. >>Request: MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/~whitehead/dav/draft-webdav- protocol-08.txt Position: first >>Response: HTTP/1.1 425 Unordered Collection In this case, the server returned a 425 (Unordered Collection) status code because the /~whitehead/dav/ collection is an unordered collection. Consequently, the server was unable to satisfy the Position header. 7 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 (defined in Section 10.1). If the new value identifies a client-maintained ordering, the client is then responsible Slein et al. Page 6 Internet-Draft WebDAV Ordered Collections August 1999 for updating the collection's ordering according to the new semantics. If it identifies a server-maintained ordering, the server MUST reorder the collection according to the new semantics. PROPPATCH is defined in [WebDAV], Section 7.2. 8 Changing the Position of a Collection Member 8.1 ORDERPATCH Method The ORDERPATCH method alters the ordering of bindings in the collection identified by the Request-URI, based on instructions in the order XML element. The order XML element identifies the bindings whose positions are to be changed, and describes their new positions in the ordering. Each new position can be specified as first in the ordering, last in the ordering, immediately before some other binding, or immediately after some other binding. The server MUST apply the changes in the order they appear in the order XML element. The server MUST either apply all the changes or apply none of them. If any error occurs during processing, all executed changes MUST be undone and a proper error result returned. 8.1.1 Status Codes Since multiple changes can be requested in a single ORDERPATCH request, the server MUST return a 207 (Multi-Status) response, as defined in [WebDAV]. The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method: 200 (OK): The change in ordering was successfully made. 409 (Conflict): The request specifies a position that is before or after a URI that is not an internal member URI of the collection, or before or after itself. 425 (Unordered Collection): The request specifies a collection position in an unordered collection or in a collection with a server-maintained ordering. A request to reposition a binding at the same place in the ordering is not an error. 8.1.2 Example: Changing Positions in an Ordered Collection Consider a collection /coll-1/ with bindings ordered as follows: nunavut.map nunavut.img baffin.map baffin.desc baffin.img iqaluit.map nunavut.desc Slein et al. Page 7 Internet-Draft WebDAV Ordered Collections August 1999 iqaluit.img iqaluit.desc >> Request: ORDERPATCH /coll-1/ HTTP/1.1 Host: www.nunanet.com Content-Type: text/xml Content-Length: xxx nunavut.desc nunavut.map iqaluit.img >> 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 http://www.nunanet.com/coll-1/iqaluit.img HTTP/1.1 200 OK If the href elements are relative URIs, as in this example, they are interpreted relative to the collection that is being reordered. In this example, after the request has been processed, the collection's ordering is as follows: nunavut.map nunavut.desc nunavut.img baffin.map Slein et al. Page 8 Internet-Draft WebDAV Ordered Collections August 1999 baffin.desc baffin.img iqaluit.map iqaluit.desc iqaluit.img 8.1.3 Example: Failure of an ORDERPATCH Request Consider a collection /coll-1/ with bindings ordered as follows: nunavut.map nunavut.img baffin.map baffin.desc baffin.img iqaluit.map nunavut.desc iqaluit.img iqaluit.desc >> Request: ORDERPATCH /coll-1/ HTTP/1.1 Host: www.nunanet.com Content-Type: text/xml Content-Length: xxx nunavut.desc nunavut.map iqaluit.map pangnirtung.img >> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxx Slein et al. Page 9 Internet-Draft WebDAV Ordered Collections August 1999 http://www.nunanet.com/coll-1/nunavut.desc HTTP/1.1 424 Failed Dependency http://www.nunanet.com/coll-1/iqaluit.map HTTP/1.1 409 Conflict pangnirtung.img is not a collection member. In this example, the client attempted to position iqaluit.map after a binding that is not contained in the collection /coll-1/. The server responded to this client error with a 409 (Conflict) status code. Because ORDERPATCH is an atomic method, the request to reposition nunavut.desc (which would otherwise have succeeded) failed with a 424 (Failed Dependency) status code. 9 Listing the Members of an Ordered Collection A PROPFIND request is used to retrieve a listing of the members of an ordered collection, just as it is used to retrieve a listing of the members of an unordered collection. However, when responding to a PROPFIND on an ordered collection, the server MUST order the response elements according to the ordering defined on the collection. If a collection is unordered, the client cannot depend on the repeatability of the ordering of results from a PROPFIND request. When responding to a PROPFIND on an ordered collection, the server SHOULD include the DAV:orderingtype property in the DAV:response element for the collection, even if the client did not explicitly request it. 9.1 Example: PROPFIND on an Ordered Collection Suppose a PROPFIND request is submitted to the following collection, which has its members ordered according to their distance from the equator. /MyCollection/ lakehazen.html siorapaluk.html iqaluit.html newyork.html >> Request: PROPFIND /MyCollection/ HTTP/1.1 Host: www.svr.com Depth: 1 Content-Type: text/xml Content-Length: xxxx Slein et al. Page 10 Internet-Draft WebDAV Ordered Collections August 1999 >> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.svr.com/MyCollection/ http://www.svr.com/jslatitudedesc HTTP/1.1 200 OK HTTP/1.1 404 Not Found http://www.svr.com/MyCollection/lakehazen.html 82N HTTP/1.1 200 OK http://www.svr.com/MyCollection/siorapaluk.html 78N HTTP/1.1 200 OK Slein et al. Page 11 Internet-Draft WebDAV Ordered Collections August 1999 http://www.svr.com/MyCollection/iqaluit.html 62N HTTP/1.1 200 OK http://www.svr.com/MyCollection/newyork.html 45N HTTP/1.1 200 OK In this example, the server responded with a list of the collection members ordered according to their distance from the equator, as specified by the value of DAV:orderingtype. Although the client did not explicitly ask for the value of DAV:orderingtype, the server provided it as one of the collection properties, allowing the client to tell that the collection is ordered and to identify the ordering semantics. 10 Headers 10.1 Ordered Entity Header Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url) The Ordered header may be used with MKCOL to request that the new collection be ordered and to specify its ordering semantics. A value of "DAV:unordered" indicates that the collection is not ordered. A value of "DAV:custom" indicates that the collection is to be ordered, but the semantics of the ordering is not being advertised. Any other Coded-url value indicates that the collection is ordered, and identifies the semantics of the ordering. 10.2 Position Request Header Position = "Position" ":" ("first" | "last" | (("before" | "after") Generic-Coded-url)) Generic-Coded-url = "<" (absoluteURI | relativeURI) ">" absoluteURI is defined in Section 3 of [URI]. relativeURI is defined in Section 5 of [URI]. The Position header may be used with any method that adds a binding to a collection with a client-maintained ordering, to tell the server where in the collection ordering to position the new binding being added to the collection. Examples of methods that add bindings to collections Slein et al. Page 12 Internet-Draft WebDAV Ordered Collections August 1999 are BIND, PUT, COPY, MOVE, etc. If the Generic-Coded-url is a relative URL, it is interpreted relative to the collection to which the new binding is being added. The server MUST insert the new binding into the ordering at the location specified in the Position header, if one is present (and if the collection has a client-maintained ordering). The "first" keyword indicates the new binding is put in the beginning position in the collection's ordering, while "last" indicates the new binding is put in the final position in the collection's ordering. The "before" keyword indicates the new binding is added to the collection's ordering immediately prior to the position of the binding identified in the Generic-Coded-url. Likewise, the "after" keyword indicates the new binding is added to the collection's ordering immediately following the position of the binding identified in the Generic-Coded-url. If the request is replacing an existing resource, and the Position header is present, the server MUST remove the binding from its previous position, and then insert it at the requested position. If the Position request header is not used when adding a binding to a collection with a client-maintained ordering, then: o If the request is replacing an existing resource, the server MUST preserve the present ordering. o If the request is adding a new binding to the collection, the server MUST append the new binding to the end of the ordering. If an attempt is made to use the Position header on a collection that is unordered or that has a server-maintained ordering, the server MUST fail the request with a 425 (Unordered) status code. 11 Status Codes 11.1 425 Unordered Collection The 425 (Unordered Collection) status code indicates that the client attempted to set the position of an internal collection member in an unordered collection or in a collection with a server-maintained ordering. 12 Properties 12.1 orderingtype Property Name: orderingtype Namespace: DAV: Purpose: Indicates whether the collection is ordered and, if so, uniquely identifies the semantics of the ordering being used. May also point to 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 Slein et al. Page 13 Internet-Draft WebDAV Ordered Collections August 1999 understand where to position them in the ordering. Value: The value unordered indicates that the collection is not ordered. The value custom indicates that the collection is ordered, but the semantics governing the ordering are not being advertised. If the value is an href element, it contains a URI that uniquely identifies the semantics of the collection's ordering. 13 XML Elements 13.1 unordered XML Element Name: unordered 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. 13.2 custom XML Element Name: custom Namespace: DAV: Purpose: A value of the DAV:orderingtype property that indicates that the collection is ordered, but the semantics of the ordering are not being advertised. 13.3 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 positions of the bindings a collection contains in its ordering. 13.4 ordermember XML Element Name: ordermember Namespace: DAV: Purpose: Occurs in the order XML element, and describes the new position of a single binding in the collection's ordering. Value: An href containing a binding's path segment, and a description of its new position in the ordering. The href XML element is defined in [WebDAV], Section 11.3. Slein et al. Page 14 Internet-Draft WebDAV Ordered Collections August 1999 13.5 position XML Element Name: position Namespace: DAV: Purpose: Occurs in the ordermember XML element. Describes the new position in a collection's ordering of one of the bindings it contains. Value: The new position can be described as first in the collection's ordering, last in the collection's ordering, immediately before some other binding, or immediately after some other binding. 13.6 first XML Element Name: first Namespace: DAV: Purpose: Occurs in the position XML element. Specifies that the binding should be placed first in the collection's ordering. 13.7 last XML Element Name: last Namespace: DAV: Purpose: Occurs in the position XML element. Specifies that the binding should be placed last in the collection's ordering. 13.8 before XML Element Name: before Namespace: DAV: Purpose: Occurs in the position XML element. Specifies that the binding should be placed immediately before the binding in the enclosed href XML element in the collection's ordering. Value: href of the member it precedes in the ordering 13.9 after XML Element Name: after Namespace: DAV: Purpose: Occurs in the position XML element. Specifies that the binding should be placed immediately after the binding in the enclosed href XML element in the collection's ordering. Value: href of the member it follows in the ordering Slein et al. Page 15 Internet-Draft WebDAV Ordered Collections August 1999 13.10 options XML Element Name: options Namespace: DAV: Purpose: Used in OPTIONS requests to ask for more detailed information about capabilities than can be provided in the DAV: response header. Used in OPTIONS responses to provide that information. Value: List of elements identifying or providing the additional information desired. 13.11 orderingoptions XML Element Name: orderingoptions Namespace: DAV: Purpose: Used in OPTIONS requests to ask for the list of server- maintained orderings that can be supported at the request- URI. Used in OPTIONS responses to provide that information. These values can be used in the Ordered header or the DAV:orderingtype property to request that a particular server-maintained ordering be applied to the collection. Value: EMPTY on requests. On responses, it is the list of server- maintained orderings available for the request-URI. 14 Capability Discovery Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes with the DAV header in responses to OPTIONS, to indicate which parts of the Web Distributed Authoring protocols the resource supports. This specification defines an OPTIONAL extension to [WebDAV]. It defines a new compliance class, called orderedcoll, for use with the DAV header in responses to OPTIONS requests. If a collection resource does support ordering, its response to an OPTIONS request MUST indicate that it does, by listing the new ORDERPATCH method as one it supports, and by listing the new orderedcoll compliance class in the DAV header. When responding to an OPTIONS request, only a collection or a null resource can include orderedcoll in the value of the DAV header. By including orderedcoll, the resource indicates that its bindings can be ordered. It implies nothing about whether any collections identified by its internal member URIs can be ordered. 14.1 Example: Discovery of Support for Ordering >> Request: OPTIONS /somecollection/ HTTP/1.1 HOST: somehost.org >> Response: Slein et al. Page 16 Internet-Draft WebDAV Ordered Collections August 1999 HTTP/1.1 200 OK Date: Tue, 20 Jan 1998 20:52:29 GMT Connection: close Accept-Ranges: none Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH DAV: 1, 2, orderedcoll The DAV header in the response indicates that the resource /somecollection/ is level 1 and level 2 compliant, as defined in [WebDAV]. In addition, /somecollection/ supports ordering. The Allow header indicates that ORDERPATCH requests can be submitted to /somecollection/. The Public header shows that other Request-URIs on the server support additional methods. 14.2 Additional Capabilities Clients may need detailed information about specific areas of Web Distributed Authoring functionality. This information can be requested by sending an OPTIONS request with an XML body that includes a DAV:options element. The DAV:options element contains a list of empty elements identifying the information the client needs. As described in Section 4, servers may offer a set of server-maintained orderings on collections. Clients can discover the list of server- maintained orderings available for the request-URI by including an empty DAV:orderingoptions element in the DAV:options element. The response will include a DAV:orderingoptions element with the list of supported server-maintained orderings. Servers SHOULD advertise the server- maintained orderings available using this mechanism. 14.3 Example: Discovery of Ordering Options >> Request: OPTIONS /somecollection/ HTTP/1.1 HOST: somehost.org >> Response: HTTP/1.1 200 OK Date: Tue, 20 Jan 1998 20:52:29 GMT Connection: close Accept-Ranges: none Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH Slein et al. Page 17 Internet-Draft WebDAV Ordered Collections August 1999 DAV: 1, sharing, orderedcoll This response indicates that the resource /somecollection/ is level 1 compliant, as defined in [WebDAV]. In addition, /somecollection/ supports ordering. The client also asked for a list of the server- maintained orderings that are supported for /somecollection/. The response indicates that the orderings Xerox:author-ascending, Xerox:title-ascending, and Xerox:date-descending are supported. 15 Security Considerations This section is provided to make WebDAV applications aware of the security implications of this protocol. All of the security considerations of HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification also apply to this protocol specification. In addition, ordered collections introduce a new security concern. This issue is detailed here. 15.1 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. In addition, Section 4 discourages clients from looking up the semantics at that location. 16 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 Slein et al. Page 18 Internet-Draft WebDAV Ordered Collections August 1999 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]. 17 IANA Considerations This document uses the namespaces defined by [WebDAV] for properties and XML elements. All other IANA considerations mentioned in [WebDAV] also apply to this document. 18 Copyright To be supplied by the RFC Editor. 19 Intellectual Property To be supplied by the RFC Editor. 20 Acknowledgements This draft has benefited from thoughtful discussion by Jim Amsden, Steve Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, and others. 21 References [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, Xerox. August, 1998. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 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. [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. Slein et al. Page 19 Internet-Draft WebDAV Ordered Collections August 1999 [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. [RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. 22 Authors' Addresses J. Slein Xerox Corporation 800 Phillips Road, 105-50C Webster, NY 14580 Email: jslein@crt.xerox.com E. J. Whitehead, Jr. Dept. of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 Email: ejw@ics.uci.edu J. Davis CourseNet Systems 170 Capp Street San Francisco, CA 94110 Email: jrd3@alum.mit.edu G. Clemm Rational Software Corporation 20 Maguire Road Lexington, MA 02173-3104 Email: gclemm@rational.com C. Fay FileNet Corporation 3565 Harbor Boulevard Costa Mesa, CA 92626-1420 Email: cfay@filenet.com J. Crawford IBM Email: ccjason@us.ibm.com T. Chihaya DataChannel, Inc. 155 108th Ave. N.E., Suite 400 Bellevue, WA 98004 Email: Tyson@DataChannel.com 23 Appendices Slein et al. Page 20 Internet-Draft WebDAV Ordered Collections August 1999 23.1 Appendix 1: Extensions to the WebDAV Document Type Definition Expires February 20, 2000 Slein et al. Page 21