Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.¶

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.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.¶

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.¶

This Internet-Draft will expire in June 2007.¶

Copyright © The IETF Trust (2006). All Rights Reserved.¶

This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. [rfc.comment.1: This document acts as container for issues raised against RFC3648 (and their proposed resolutions discussed on the WebDAV mailing list). --julian.reschke@greenbytes.de] ¶

Since this document describes a set of extensions to the WebDAV Distributed Authoring Protocol [RFC2518], which is itself an extension to the HTTP/1.1 protocol, the augmented BNF used here to describe protocol elements is exactly the same as described in ↑ I ↓Section 2.1 of HTTP [RFC2616]Section 2.1 of [RFC2616]. Since this augmented BNF uses the basic production rules provided in ↑ I ↓Section 2.2 of HTTPSection 2.2 of [RFC2616], 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].¶

This document uses XML DTD fragments as a purely notational convention. WebDAV request and response bodies can not be validated due to the specific extensibility rules defined in Section 23 of [RFC2518] and due to the fact that all XML elements defined by this specification use the XML namespace name "DAV:". In particular: ¶

1. element names use the "DAV:" namespace,
2. element ordering is irrelevant,
3. extension elements (elements not already defined as valid child elements) may be added anywhere, except where explicitly stated otherwise,
4. extension attributes (attributes not already defined as valid for this element) may be added anywhere, except where explicitly stated otherwise.

This specification builds on the collection infrastructure provided by the WebDAV Distributed Authoring Protocol, adding support for the server-side ordering of collection members.¶

There are many scenarios in which it is useful to impose an ordering on a collection at the server, such as expressing a recommended access order, or a revision history order. The members of a collection might represent the pages of a book, which need to be presented in order if they are to make sense, or an instructor might create a collection of course readings that she wants to be displayed in the order they are to be read.¶

Orderings may be based on property values, but this is not always the case. The resources in the collection may not have properties that can be used to support the desired ordering. Orderings based on properties can be obtained using a search protocol's ordering option, but orderings not based on properties cannot. These orderings generally need to be maintained by a human user.¶

The ordering protocol defined here focuses on support for such human-maintained orderings. Its protocol elements allow clients to specify the position of each collection member in the collection's ordering, as well as the semantics governing the order. The protocol is designed to allow additional support in the future for orderings that are maintained automatically by the server.¶

The remainder of this document is structured as follows: Section 3 defines terminology that will be used throughout the specification. Section 4 provides an overview of ordered collections. Section 5 describes how to create an ordered collection, and Section 6 discusses how to set a member's position in the ordering of a collection. Section 7 explains how to change a collection ordering. Section 8 discusses listing the members of an ordered collection. Section 9 discusses the impact on version-controlled collections (as defined in [RFC3253]). Section 10 describes capability discovery. Sections 11 through 13 discuss security, internationalization, and IANA considerations. The remaining sections provide supporting information.¶

The terminology used here follows that in [RFC2518] and [RFC3253]. Definitions of the terms resource, Uniform Resource Identifier (URI), and Uniform Resource Locator (URL) are provided in  I ↓[RFC2396][RFC3986].¶

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 ¶

• 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.

Ordering Semantics ¶

• In general, ordering semantics are the set of structures or meanings applied to the ordering of the member of a specific collection. Within this document, "ordering semantics" refers specifically to the structure specified in the DAV:ordering-type property. See Section 4.1.1 for more information on DAV:ordering-type.

This document uses the terms "precondition", "postcondition" and "protected property" as defined in [RFC3253]. Servers MUST report pre-/postcondition failures as described in ↑ I ↓section 1.6Section 1.6 of this document.¶

If a collection is not ordered, the client cannot depend on the repeatability of the ordering of results from a PROPFIND request. By specifying an ordering for a collection, a client requires the server to follow that ordering whenever it responds to a PROPFIND request on that collection.¶

Server-side orderings may be client-maintained or server-maintained. For client-maintained orderings, a client must specify the ordering position of each of the collection's members, either when the member is added to the collection (using the Position header (Section 6)) or later (using the ORDERPATCH (Section 7) method). For server-maintained orderings, the server automatically positions each of the collection's members according to the ordering semantics. This specification supports only client-maintained orderings, but is designed to allow the future extension with server-maintained orderings.¶

A collection that supports ordering is not required to be ordered.¶

If a collection is ordered, each of its internal member URIs MUST appear in the ordering exactly once, and the ordering MUST NOT include any URIs that are not internal members of the collection. The server is responsible for enforcing these constraints on orderings. The server MUST remove an internal member URI from the ordering when it is removed from the collection. Removing an internal member MUST NOT affect the ordering of the remaining internal members. The server MUST add an internal member URI to the ordering when it is added to 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.¶

An ordering is considered to be part of the state of a collection resource. Consequently, the ordering is the same no matter which URI is used to access the collection and is protected by locks or access control constraints on the collection.¶

The ORDERPATCH method is used to change the ordering semantics of a collection, to change the order of the collection's members in the ordering, or both.¶

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.¶

If an ORDERPATCH request changes the ordering semantics, but does not completely specify the order of the collection members, the server MUST assign a position in the ordering to each collection member for which a position was not specified. These server-assigned positions MUST follow the last position specified by the client. The result is that all members for which the client specified a position are at the beginning of the ordering, followed by any members for which the server assigned positions. Note that the ordering of the server-assigned positions is not defined by this document, therefore servers can use whatever rule seems reasonable (for instance, alphabetically or by creation date).¶

If an ORDERPATCH request does not change the ordering semantics, any member positions not specified in the request MUST remain unchanged.¶

A request to reposition a collection member to the same place in the ordering is not an error.¶

If an ORDERPATCH request fails, the server state preceding the request MUST be restored.¶

Additional Marshalling: ¶

• The request body MUST be DAV:orderpatch element.

•    <!ELEMENT orderpatch (ordering-type?, order-member*) >
  
     <!ELEMENT order-member (segment, position) >
     <!ELEMENT position (first | last | before | after)>
     <!ELEMENT segment (#PCDATA)>↑ I ↓
     <!-- PCDATA value: segment, as defined in Section 3.3 of [RFC3986] -->
     
     <!ELEMENT first EMPTY >
     <!ELEMENT last EMPTY >
     <!ELEMENT before segment >
     <!ELEMENT after segment >
  

• ↑ I ↓PCDATA value: segment, as defined in section 3.3 of [RFC2396].
• The DAV:ordering-type property is modified according to the DAV:ordering-type element.
• The ordering of internal member URIs in the collection identified by the Request-URI is changed based on instructions in the order-member XML elements. Specifically, in in the order that they appear in the request. The order-member XML elements identify the internal member URIs whose positions are to be changed, and describe 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 internal member URI, or immediately after some other internal member URI.
• If a response body for a successful request is included, it MUST be a DAV:orderpatch-response XML element. Note that this document does not define any elements for the ORDERPATCH response body, but the DAV:orderpatch-response element is defined to ensure interoperability between future extensions that do define elements for the ORDERPATCH response body.

     <!ELEMENT orderpatch-response ANY>
  

• Since multiple changes can be requested in a single ORDERPATCH request, the server MUST return a 207 (Multi-Status) response (defined in [RFC2518]), containing DAV:response elements for either the request-URI (when the DAV:ordering-type could not be modified) or URIs of collection members to be repositioned (when an individual positioning request expressed as DAV:order-member could not be fulfilled) if any problems are encountered.

Preconditions: ¶

• (DAV:collection-must-be-ordered): I ↓see Section 6.1 If the request is applied to an unordered collection, and if the request body contains an order-member element, it MUST also specify an ordering-type element, turning the previously unordered collection into an ordered collection (see also Section 6.1).
• (DAV:segment-must-identify-member): see Section 6.1.

Postconditions: ¶

• (DAV:ordering-type-set): if the request body contained a DAV:ordering-type element, the request MUST have set the DAV:ordering-type property of the collection to the value specified in the request.
• (DAV:ordering-modified): if the request body contained DAV:order-member elements, the request MUST have set the ordering of internal member URIs in the collection identified by the request-URI based upon instructions in the DAV:order-member elements.

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.¶

In a response to a PROPFIND with Depth: infinity, members of different collections may be interleaved. That is, the server is not required to do a breadth-first traversal. The only requirement is that the members of any ordered collection appear in the order defined for that collection. Thus, for the hierarchy illustrated in the following figure, where collection A is an ordered collection with the ordering B C D,¶

it would be acceptable for the server to return response elements in the order A B E C F G H D or "A B E C H G F D" as well (if C is unordered). In this response, B, C, and D appear in the correct order, separated by members of other collections. Clients can use a series of Depth: 1 PROPFIND requests to avoid the complexity of processing Depth: infinity responses based on depth-first traversals.¶

The Versioning Extensions to WebDAV [RFC3253] introduce the concept of versioned collections, recording both the dead properties and the set of internal version-controlled bindings. This section defines how this feature interacts with ordered collections.¶

This specification considers both the ordering type (DAV:ordering-type property) and the ordering of collection members to be part of the state of a collection. Therefore, both MUST be recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, UNCHECKOUT or UPDATE (where for compatibility with RFC 3253, only the ordering of version-controlled members needs to be maintained).¶

Sections 9.1 and 15 of [RFC2518] describe the use of compliance classes with the DAV header in responses to OPTIONS, indicating which parts of the Web Distributed Authoring protocols the resource supports. This specification defines an OPTIONAL extension to [RFC2518]. It defines a new compliance class, called ordered-collections, for use with the DAV header in responses to OPTIONS requests. If a collection resource does support ordering, its response to an OPTIONS request may indicate that it does, by listing the new ORDERPATCH method as one it supports, and by listing the new ordered-collections compliance class in the DAV header.¶

When responding to an OPTIONS request, only a collection or a null resource can include ordered-collections in the value of the DAV header. By including ordered-collections, the resource indicates that its internal member URIs can be ordered. It implies nothing about whether any collections identified by its internal member URIs can be ordered.¶

Furthermore, ↑ I ↓RFC 3253[RFC3253] introduces the live properties DAV:supported-method-set (↑ I ↓section 3.1.3Section 3.1.3) and DAV:supported-live-property-set (↑ I section 3.1.4Section 3.1.4). Servers MUST support these properties as defined in RFC 3253.¶

This section is provided to make WebDAV implementers 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.¶

This specification follows the practices of [RFC2518] by encoding all human-readable content using [XML] and in the treatment of names. Consequently, this specification complies with the IETF Character Set Policy [RFC2277].¶

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 [RFC2277].¶

As in [RFC2518], 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. The 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, [RFC2518] 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.¶

This specification introduces no new strings that are displayed to users as part of normal, error-free operation of the protocol.¶

For the rationale of these decisions and advice for application implementers, see [RFC2518].¶

This document uses the namespaces defined by [RFC2518] for properties and XML elements. All other IANA considerations mentioned in [RFC2518] also apply to this document.¶

This document has benefited from significant contributions from Geoff Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein.¶

This document has benefited from thoughtful discussion by Jim Amsden, Mark Baker,Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Dusseault, 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, Kevin Wiggen, and others.¶

16. Normative References

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2277]

Alvestrand, H., “IETF Policy on Character Sets and Languages”, BCP 18, RFC 2277, January 1998.

[RFC2518]

Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, “HTTP Extensions for Distributed Authoring -- WEBDAV”, RFC 2518, February 1999.

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

[RFC3253]

Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, “Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)”, RFC 3253, March 2002.

↑ I ↓ 

[RFC2396]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998.

↑ I ↓ 

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.

↑ I  

[XML]

Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed)”, W3C REC-xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.

↑ I  

[XML]

Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fourth Edition)”, W3C REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.

Copyright © The IETF Trust (2006).¶

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.¶

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.¶

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.¶

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.¶

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.¶