--- 1/draft-ietf-webdav-ordering-protocol-08.txt 2006-02-05 02:11:00.000000000 +0100 +++ 2/draft-ietf-webdav-ordering-protocol-09.txt 2006-02-05 02:11:00.000000000 +0100 @@ -1,19 +1,19 @@ WEBDAV Working Group J. Whitehead Internet-Draft U.C. Santa Cruz -Expires: November 10, 2003 J. Reschke, Ed. +Expires: December 19, 2003 J. Reschke, Ed. greenbytes - May 12, 2003 + June 20, 2003 WebDAV Ordered Collections Protocol - draft-ietf-webdav-ordering-protocol-08 + draft-ietf-webdav-ordering-protocol-09 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. @@ -21,21 +21,21 @@ 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 on November 10, 2003. + This Internet-Draft will expire on December 19, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so @@ -60,20 +60,21 @@ 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Ordered Collections . . . . . . . . . . . . . . 7 4.1 Additional Collection properties . . . . . . . . . . . . . . 7 4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 7 5. Creating an Ordered Collection . . . . . . . . . . . . . . . 9 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Example: Creating an Ordered Collection . . . . . . . . . . 10 6. Setting the Position of a Collection Member . . . . . . . . 11 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Examples: Setting the Position of a Collection Member . . . 12 + 6.3 Examples: Renaming a member of an ordered collection . . . . 13 7. Changing a Collection Ordering: ORDERPATCH method . . . . . 14 7.1 Example: Changing a Collection Ordering . . . . . . . . . . 16 7.2 Example: Failure of an ORDERPATCH Request . . . . . . . . . 17 8. Listing the Members of an Ordered Collection . . . . . . . . 19 8.1 Example: PROPFIND on an Ordered Collection . . . . . . . . . 19 9. Relationship to versioned collections . . . . . . . . . . . 23 9.1 Collection Version Properties . . . . . . . . . . . . . . . 23 9.1.1 Additional semantics for DAV:version-controlled-binding-set (protected) . . . . . . . 23 9.1.2 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 23 @@ -98,20 +99,21 @@ A. Extensions to the WebDAV Document Type Definition . . . . . 37 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . . . 38 B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . . . 38 B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . . . 38 B.5 Since draft-ietf-webdav-ordering-protocol-05 . . . . . . . . 39 B.6 Since draft-ietf-webdav-ordering-protocol-06 . . . . . . . . 39 B.7 Since draft-ietf-webdav-ordering-protocol-07 . . . . . . . . 39 + B.8 Since draft-ietf-webdav-ordering-protocol-08 . . . . . . . . 39 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . 42 1. Notational Conventions Since this document describes a set of extensions to the WebDAV Distributed Authoring Protocol [RFC2518], 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 Section 2.1 of HTTP [RFC2616]. Since this augmented BNF uses the basic production rules @@ -464,39 +466,60 @@ In this case, the server returned a 409 (Conflict) status code because the /~user/dav/ collection is an unordered collection. Consequently, the server was unable to satisfy the Position header. +6.3 Examples: Renaming a member of an ordered collection + + The following sequence of requests will rename a collection member + while preserving it's position, independantly of how the server + implements the MOVE operation: + + 1. PROPFIND collection with depth 1, retrieving the + DAV:ordering-type property (an interactive client likely already + has done this in order to display the collection's content) + + 2. If the DAV:ordering-type property is present and doesn't equal + "dav:unordered" (thus if the collection is ordered), determine + current position (such as "first" or "after x") and setup + Position header accordingly. + + 3. Perform the MOVE operation, optionally supplying the Position + header computed in the previous step. + 7. Changing a Collection Ordering: ORDERPATCH method The ORDERPATCH method is used to change the ordering semantics of a collection or 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 all follow the last one 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. + 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 at the same place in the ordering is not an error. If an ORDERPATCH request fails, the server state preceding the request MUST be restored. @@ -560,22 +582,22 @@ 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 on the instructions in the DAV:order-member elements. 7.1 Example: Changing a Collection Ordering - Consider a collection /coll-1/ whose DAV:ordering-type is DAV:whim, - with bindings ordered as follows: + Consider an ordered collection /coll-1, with bindings ordered as + follows: three.html four.html one.html two.html >> Request: ORDERPATCH /coll-1/ HTTP/1.1 Host: example.org @@ -717,25 +738,25 @@ with the ordering B C D, A /|\ / | \ B C D / /|\ E F G H it would be acceptable for the server to return response elements in - the order A B E C F G H D. 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 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. 8.1 Example: PROPFIND on an Ordered Collection Suppose a PROPFIND request is submitted to /MyColl/, which has its members ordered as follows. /MyColl/ lakehazen.html siorapaluk.html iqaluit.html @@ -918,21 +939,21 @@ 9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics Additional Postconditions: (DAV:update-version-controlled-collection-members-ordered): If the request modified the DAV:checked-in version of a version-controlled collection and the DAV:ordering-type for the checked-in version is not unordered ("DAV:unordered"), the version-controlled members MUST be ordered according to the checked-in version's DAV:version-controlled-binding-set property. - The ordering of non-version-controlled members is server-defined." + The ordering of non-version-controlled members is server-defined. (DAV:update-version-ordering-type): If the request modified the DAV:checked-in version of a version-controlled collection, the DAV:ordering-type property MUST be updated from the checked-in version's property. 10. Capability Discovery Sections 9.1 and 15 of [RFC2518] describe the use of compliance classes with the DAV header in responses to OPTIONS, to indicate @@ -1260,20 +1281,28 @@ Added atomicity statement for ORDERPATCH method. B.7 Since draft-ietf-webdav-ordering-protocol-07 Added issues "4.1-DELETE-behaviour", "6.1-safe-update", "6.1-when-are-members-added" and "9.4-UPDATE-non-version-controlled-members" and resolved them. Added new "contributors" section, and mention original authors such as Judith Slein there. +B.8 Since draft-ietf-webdav-ordering-protocol-08 + + Typos fixed. Added and resolved issues + "6-position-preserving-rename", + "7-clarify-positions-for-not-explicitly-mentioned-members", + "7.1-surprising-ordering-type-in-DAV-ns" and + "8-order-for-unordered-subcollections". + Index C Client-Maintained Ordering 6 D DAV:collection-must-be-ordered precondition 12 DAV:custom ordering type 8 DAV:initialize-collection-version-ordering-type 23 DAV:initialize-ordering-type 24 @@ -1365,14 +1394,14 @@ The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. -Acknowledgement +Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.