7Network Working Group J. Whitehead
8Request for Comments: 3648 U.C. Santa Cruz
9Category: Standards Track J. Reschke, Ed.
14 Web Distributed Authoring and Versioning (WebDAV)
15 Ordered Collections Protocol
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The Internet Society (2003). All Rights Reserved.
31 This specification extends the Web Distributed Authoring and
32 Versioning (WebDAV) Protocol to support the server-side ordering of
33 collection members. Of particular interest are orderings that are
34 not based on property values, and so cannot be achieved using a
35 search protocol's ordering option and cannot be maintained
36 automatically by the server. Protocol elements are defined to let
37 clients specify the position in the ordering of each collection
38 member, as well as the semantics governing the ordering.
58Whitehead & Reschke Standards Track [Page 1]
60RFC 3648 WebDAV Ordered Collections Protocol December 2003
65 1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 4. Overview of Ordered Collections . . . . . . . . . . . . . . . 5
69 4.1. Additional Collection properties . . . . . . . . . . . . 6
70 4.1.1. DAV:ordering-type (protected). . . . . . . . . . 6
71 5. Creating an Ordered Collection . . . . . . . . . . . . . . . . 7
72 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
73 5.2. Example: Creating an Ordered Collection. . . . . . . . . 8
74 6. Setting the Position of a Collection Member. . . . . . . . . . 8
75 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
76 6.2. Examples: Setting the Position of a Collection Member. . 10
77 6.3. Examples: Renaming a member of an ordered collection . . 10
78 7. Changing a Collection Ordering: ORDERPATCH method. . . . . . . 11
79 7.1. Example: Changing a Collection Ordering. . . . . . . . . 13
80 7.2. Example: Failure of an ORDERPATCH Request. . . . . . . . 14
81 8. Listing the Members of an Ordered Collection . . . . . . . . . 16
82 8.1. Example: PROPFIND on an Ordered Collection . . . . . . . 17
83 9. Relationship to versioned collections. . . . . . . . . . . . . 19
84 9.1. Collection Version Properties. . . . . . . . . . . . . . 20
85 9.1.1. Additional semantics for
86 DAV:version-controlled-binding-set (protected) . 20
87 9.1.2. DAV:ordering-type (protected). . . . . . . . . . 20
88 9.2. Additional CHECKIN semantics . . . . . . . . . . . . . . 20
89 9.3. Additional CHECKOUT Semantics. . . . . . . . . . . . . . 20
90 9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . 21
91 10. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 21
92 10.1. Example: Using OPTIONS for the Discovery of Support for
93 Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
94 10.2. Example: Using Live Properties for the Discovery of
95 Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
96 11. Security Considerations. . . . . . . . . . . . . . . . . . . . 23
97 11.1. Denial of Service and DAV:ordering-type . . . . . . . . 23
98 12. Internationalization Considerations. . . . . . . . . . . . . . 24
99 13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
100 14. Intellectual Property Statement. . . . . . . . . . . . . . . . 25
101 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
102 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
103 17. Normative References . . . . . . . . . . . . . . . . . . . . . 26
104 A. Extensions to the WebDAV Document Type Definition. . . . . . . 27
105 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
107 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
114Whitehead & Reschke Standards Track [Page 2]
116RFC 3648 WebDAV Ordered Collections Protocol December 2003
1191. Notational Conventions
121 Since this document describes a set of extensions to the WebDAV
122 Distributed Authoring Protocol [RFC2518], which is itself an
123 extension to the HTTP/1.1 protocol, the augmented BNF used here to
124 describe protocol elements is exactly the same as described in
125 Section 2.1 of HTTP [RFC2616]. Since this augmented BNF uses the
126 basic production rules provided in Section 2.2 of HTTP, these rules
127 apply to this document as well.
129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
131 document are to be interpreted as described in [RFC2119].
133 This document uses XML DTD fragments as a purely notational
134 convention. WebDAV request and response bodies can not be validated
135 due to the specific extensibility rules defined in section 23 of
136 [RFC2518] and due to the fact that all XML elements defined by this
137 specification use the XML namespace name "DAV:". In particular:
139 1. element names use the "DAV:" namespace,
141 2. element ordering is irrelevant,
143 3. extension elements (elements not already defined as valid child
144 elements) may be added anywhere, except where explicitly stated
147 4. extension attributes (attributes not already defined as valid for
148 this element) may be added anywhere, except where explicitly
153 This specification builds on the collection infrastructure provided
154 by the WebDAV Distributed Authoring Protocol, adding support for the
155 server-side ordering of collection members.
157 There are many scenarios in which it is useful to impose an ordering
158 on a collection at the server, such as expressing a recommended
159 access order, or a revision history order. The members of a
160 collection might represent the pages of a book, which need to be
161 presented in order if they are to make sense, or an instructor might
162 create a collection of course readings that she wants to be displayed
163 in the order they are to be read.
165 Orderings may be based on property values, but this is not always the
166 case. The resources in the collection may not have properties that
170Whitehead & Reschke Standards Track [Page 3]
172RFC 3648 WebDAV Ordered Collections Protocol December 2003
175 can be used to support the desired ordering. Orderings based on
176 properties can be obtained using a search protocol's ordering option,
177 but orderings not based on properties cannot. These orderings
178 generally need to be maintained by a human user.
180 The ordering protocol defined here focuses on support for such
181 human-maintained orderings. Its protocol elements allow clients to
182 specify the position of each collection member in the collection's
183 ordering, as well as the semantics governing the order. The protocol
184 is designed to allow additional support in the future for orderings
185 that are maintained automatically by the server.
187 The remainder of this document is structured as follows: Section 3
188 defines terminology that will be used throughout the specification.
189 Section 4 provides an overview of ordered collections. Section 5
190 describes how to create an ordered collection, and Section 6
191 discusses how to set a member's position in the ordering of a
192 collection. Section 7 explains how to change a collection ordering.
193 Section 8 discusses listing the members of an ordered collection.
194 Section 9 discusses the impact on version-controlled collections (as
195 defined in [RFC3253]). Section 10 describes capability discovery.
196 Sections 11 through 13 discuss security, internationalization, and
197 IANA considerations. The remaining sections provide supporting
202 The terminology used here follows that in [RFC2518] and [RFC3253].
203 Definitions of the terms resource, Uniform Resource Identifier (URI),
204 and Uniform Resource Locator (URL) are provided in [RFC2396].
208 A collection for which the results from a PROPFIND request are
209 guaranteed to be in the order specified for that collection.
213 A collection for which the client cannot depend on the
214 repeatability of the ordering of results from a PROPFIND request.
216 Client-Maintained Ordering
218 An ordering of collection members that is maintained on the server
219 based on client requests specifying the position of each
220 collection member in the ordering.
226Whitehead & Reschke Standards Track [Page 4]
228RFC 3648 WebDAV Ordered Collections Protocol December 2003
231 Server-Maintained Ordering
233 An ordering of collection members that is maintained automatically
234 by the server, based on a client's choice of ordering semantics.
238 In general, ordering semantics are the set of structures or
239 meanings applied to the ordering of the member of a specific
240 collection. Within this document, "ordering semantics" refers
241 specifically to the structure specified in the DAV:ordering-type
242 property. See Section 4.1.1 for more information on
245 This document uses the terms "precondition", "postcondition" and
246 "protected property" as defined in [RFC3253]. Servers MUST report
247 pre-/postcondition failures as described in section 1.6 of this
2504. Overview of Ordered Collections
252 If a collection is not ordered, the client cannot depend on the
253 repeatability of the ordering of results from a PROPFIND request. By
254 specifying an ordering for a collection, a client requires the server
255 to follow that ordering whenever it responds to a PROPFIND request on
258 Server-side orderings may be client-maintained or server-maintained.
259 For client-maintained orderings, a client must specify the ordering
260 position of each of the collection's members, either when the member
261 is added to the collection (using the Position header (Section 6)) or
262 later (using the ORDERPATCH (Section 7) method). For server-
263 maintained orderings, the server automatically positions each of the
264 collection's members according to the ordering semantics. This
265 specification supports only client-maintained orderings, but is
266 designed to allow the future extension with server-maintained
269 A collection that supports ordering is not required to be ordered.
271 If a collection is ordered, each of its internal member URIs MUST
272 appear in the ordering exactly once, and the ordering MUST NOT
273 include any URIs that are not internal members of the collection.
274 The server is responsible for enforcing these constraints on
275 orderings. The server MUST remove an internal member URI from the
276 ordering when it is removed from the collection. Removing an
277 internal member MUST NOT affect the ordering of the remaining
282Whitehead & Reschke Standards Track [Page 5]
284RFC 3648 WebDAV Ordered Collections Protocol December 2003
287 internal members. The server MUST add an internal member URI to the
288 ordering when it is added to the collection.
290 Only one ordering can be attached to any collection. Multiple
291 orderings of the same resources can be achieved by creating multiple
292 collections referencing those resources, and attaching a different
293 ordering to each collection.
295 An ordering is considered to be part of the state of a collection
296 resource. Consequently, the ordering is the same no matter which URI
297 is used to access the collection and is protected by locks or access
298 control constraints on the collection.
3004.1. Additional Collection properties
302 A DAV:allprop PROPFIND request SHOULD NOT return any of the
303 properties defined in this document.
3054.1.1. DAV:ordering-type (protected)
307 The DAV:ordering-type property indicates whether the collection is
308 ordered and, if so, uniquely identifies the semantics of the
309 ordering. It may also point to an explanation of the semantics in
310 human and/or machine-readable form. At a minimum, this allows human
311 users who add members to the collection to understand where to
312 position them in the ordering. This property cannot be set using
313 PROPPATCH. Its value can only be set by including the Ordering-Type
314 header with a MKCOL request or by submitting an ORDERPATCH request.
316 Ordering types are identified by URIs that uniquely identify the
317 semantics of the collection's ordering. The following two URIs are
320 DAV:custom: The value DAV:custom indicates that the collection is
321 ordered, but the semantics governing the ordering are not being
324 DAV:unordered: The value DAV:unordered indicates that the collection
325 is not ordered. That is, the client cannot depend on the
326 repeatability of the ordering of results from a PROPFIND request.
328 An ordering-aware client interacting with an ordering-unaware server
329 (e.g., one that is implemented only according to [RFC2518]) SHOULD
330 assume that the collection is unordered if a collection does not have
331 the DAV:ordering-type property.
333 <!ELEMENT ordering-type (href) >
338Whitehead & Reschke Standards Track [Page 6]
340RFC 3648 WebDAV Ordered Collections Protocol December 2003
3435. Creating an Ordered Collection
347 When a collection is created, the client MAY request that it be
348 ordered and specify the semantics of the ordering by using the new
349 Ordering-Type header (defined below) with a MKCOL request.
351 For collections that are ordered, the client SHOULD identify the
352 semantics of the ordering with a URI in the Ordering-Type header,
353 although the client MAY simply set the header value to DAV:custom to
354 indicate that the collection is ordered but the semantics of the
355 ordering are not being advertised. Setting the value to a URI that
356 identifies the ordering semantics provides the information a human
357 user or software package needs to insert new collection members into
358 the ordering intelligently. Although the URI in the Ordering-Type
359 header MAY point to a resource that contains a definition of the
360 semantics of the ordering, clients SHOULD NOT access that resource to
361 avoid overburdening its server. A value of DAV:unordered in the
362 Ordering-Type header indicates that the client wants the collection
363 to be unordered. If the Ordering-Type header is not present, the
364 collection will be unordered.
366 Additional Marshalling:
368 Ordering-Type = "Ordering-Type" ":" absoluteURI
369 ; absoluteURI: see RFC2396, section 3
371 The URI "DAV:unordered" indicates that the collection is not
372 ordered, while "DAV:custom" indicates that the collection is to be
373 ordered, but the semantics of the ordering is not being
374 advertised. Any other URI value indicates that the collection is
375 ordered, and identifies the semantics of the ordering.
377 Additional Preconditions:
379 (DAV:ordered-collections-supported): the server MUST support
380 ordered collections in the part of the URL namespace identified by
383 Additional Postconditions:
385 (DAV:ordering-type-set): if the Ordering-Type header was present,
386 the request MUST have created a new collection resource with the
387 DAV:ordering-type being set according to the Ordering-Type request
388 header. The collection MUST be ordered unless the ordering type
394Whitehead & Reschke Standards Track [Page 7]
396RFC 3648 WebDAV Ordered Collections Protocol December 2003
3995.2. Example: Creating an Ordered Collection
403 MKCOL /theNorth/ HTTP/1.1
405 Ordering-Type: http://example.org/orderings/compass.html
411 In this example, a new ordered collection was created. Its
412 DAV:ordering-type property has the URI from the Ordering-Type header
413 as its value http://example.org/orderings/compass.html. In this
414 case, the URI identifies the semantics governing a client-maintained
415 ordering. As new members are added to the collection, clients or end
416 users can use the semantics to determine where to position the new
417 members in the ordering.
4196. Setting the Position of a Collection Member
423 When a new member is added to a collection with a client-maintained
424 ordering (for example, with PUT, COPY, or MKCOL), its position in the
425 ordering can be set with the new Position header. The Position
426 header allows the client to specify that an internal member URI
427 should be first in the collection's ordering, last in the
428 collection's ordering, immediately before some other internal member
429 URI in the collection's ordering, or immediately after some other
430 internal member URI in the collection's ordering.
432 If the Position request header is not used when adding a member to an
433 ordered collection, then:
435 o If the request is replacing an existing resource, the server MUST
436 preserve the present ordering.
438 o If the request is adding a new internal member URI to the
439 collection, the server MUST append the new member to the end of
442 Note to implementers: this specification does not mandate a specific
443 implementation of MOVE operations within the same parent collection.
444 Therefore, servers may either implement this as a simple rename
445 operation (preserving the collection member's position), or as a
446 sequence of "remove" and "add" (causing the semantics of "adding a
450Whitehead & Reschke Standards Track [Page 8]
452RFC 3648 WebDAV Ordered Collections Protocol December 2003
455 new member" to apply). Future revisions of this specification may
456 specify this behaviour more precisely based on future implementation
459 Additional Marshalling:
461 Position = "Position" ":" ("first" | "last" |
462 (("before" | "after") segment))
464 segment is defined in Section 3.3 of [RFC2396].
466 The segment is interpreted relative to the collection to which the
467 new member is being added.
469 When the Position header is present, the server MUST insert the
470 new member into the ordering at the specified location.
472 The "first" keyword indicates that the new member is placed in the
473 beginning position in the collection's ordering, while "last"
474 indicates that the new member is placed in the final position in
475 the collection's ordering. The "before" keyword indicates that
476 the new member is added to the collection's ordering immediately
477 prior to the position of the member identified in the segment.
478 Likewise, the "after" keyword indicates that the new member is
479 added to the collection's ordering immediately following the
480 position of the member identified in the segment.
482 If the request is replacing an existing resource and the Position
483 header is present, the server MUST remove the internal member URI
484 from its current position, and insert it at the newly requested
487 Additional Preconditions:
489 (DAV:collection-must-be-ordered): the target collection MUST be
492 (DAV:segment-must-identify-member): the referenced segment MUST
493 identify a resource that exists and is different from the affected
496 Additional Postconditions:
498 (DAV:position-set): if a Position header is present, the request
499 MUST create the new collection member at the specified position.
506Whitehead & Reschke Standards Track [Page 9]
508RFC 3648 WebDAV Ordered Collections Protocol December 2003
5116.2. Examples: Setting the Position of a Collection Member
515 COPY /~user/dav/spec08.html HTTP/1.1
517 Destination: http://example.org/~slein/dav/spec08.html
518 Position: after requirements.html
524 This request resulted in the creation of a new resource at
525 example.org/~slein/dav/spec08.html. The Position header in this
526 example caused the server to set its position in the ordering of the
527 /~slein/dav/ collection immediately after requirements.html.
531 MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1
533 Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt
538 HTTP/1.1 409 Conflict
539 Content-Type: text/xml; charset="utf-8"
542 <?xml version="1.0" encoding="utf-8" ?>
543 <D:error xmlns:D="DAV:">
544 <D:collection-must-be-ordered/>
547 In this case, the server returned a 409 (Conflict) status code
548 because the /~user/dav/ collection is an unordered collection.
549 Consequently, the server was unable to satisfy the Position header.
5516.3. Examples: Renaming a member of an ordered collection
553 The following sequence of requests will rename a collection member
554 while preserving its position, independently of how the server
555 implements the MOVE operation:
562Whitehead & Reschke Standards Track [Page 10]
564RFC 3648 WebDAV Ordered Collections Protocol December 2003
567 1. PROPFIND collection with depth 1, retrieving the DAV:ordering-type
568 property (an interactive client has already likely done this in
569 order to display the collection's content).
571 2. If the DAV:ordering-type property is present and does not equal
572 "dav:unordered" (thus if the collection is ordered), determine the
573 current position (such as "first" or "after x") and setup the
574 Position header accordingly.
576 3. Perform the MOVE operation, optionally supplying the Position
577 header computed in the previous step.
5797. Changing a Collection Ordering: ORDERPATCH method
581 The ORDERPATCH method is used to change the ordering semantics of a
582 collection, to change the order of the collection's members in the
585 The server MUST apply the changes in the order they appear in the
586 order XML element. The server MUST either apply all the changes or
587 apply none of them. If any error occurs during processing, all
588 executed changes MUST be undone and a proper error result returned.
590 If an ORDERPATCH request changes the ordering semantics, but does not
591 completely specify the order of the collection members, the server
592 MUST assign a position in the ordering to each collection member for
593 which a position was not specified. These server-assigned positions
594 MUST follow the last position specified by the client. The result is
595 that all members for which the client specified a position are at the
596 beginning of the ordering, followed by any members for which the
597 server assigned positions. Note that the ordering of the server-
598 assigned positions is not defined by this document, therefore servers
599 can use whatever rule seems reasonable (for instance, alphabetically
600 or by creation date).
602 If an ORDERPATCH request does not change the ordering semantics, any
603 member positions not specified in the request MUST remain unchanged.
605 A request to reposition a collection member to the same place in the
606 ordering is not an error.
608 If an ORDERPATCH request fails, the server state preceding the
609 request MUST be restored.
618Whitehead & Reschke Standards Track [Page 11]
620RFC 3648 WebDAV Ordered Collections Protocol December 2003
623 Additional Marshalling:
625 The request body MUST be DAV:orderpatch element.
627 <!ELEMENT orderpatch (ordering-type?, order-member*) >
629 <!ELEMENT order-member (segment, position) >
630 <!ELEMENT position (first | last | before | after)>
631 <!ELEMENT segment (#PCDATA)>
632 <!ELEMENT first EMPTY >
633 <!ELEMENT last EMPTY >
634 <!ELEMENT before segment >
635 <!ELEMENT after segment >
637 PCDATA value: segment, as defined in section 3.3 of [RFC2396].
639 The DAV:ordering-type property is modified according to the
640 DAV:ordering-type element.
642 The ordering of internal member URIs in the collection identified
643 by the Request-URI is changed based on instructions in the order-
644 member XML elements. Specifically, in the order that they appear
645 in the request. The order-member XML elements identify the
646 internal member URIs whose positions are to be changed, and
647 describe their new positions in the ordering. Each new position
648 can be specified as first in the ordering, last in the ordering,
649 immediately before some other internal member URI, or immediately
650 after some other internal member URI.
652 If a response body for a successful request is included, it MUST
653 be a DAV:orderpatch-response XML element. Note that this document
654 does not define any elements for the ORDERPATCH response body, but
655 the DAV:orderpatch-response element is defined to ensure
656 interoperability between future extensions that do define elements
657 for the ORDERPATCH response body.
659 <!ELEMENT orderpatch-response ANY>
661 Since multiple changes can be requested in a single ORDERPATCH
662 request, the server MUST return a 207 (Multi-Status) response
663 (defined in [RFC2518]), containing DAV:response elements for
664 either the request-URI (when the DAV:ordering-type could not be
665 modified) or URIs of collection members to be repositioned (when
666 an individual positioning request expressed as DAV:order-member
667 could not be fulfilled) if any problems are encountered.
674Whitehead & Reschke Standards Track [Page 12]
676RFC 3648 WebDAV Ordered Collections Protocol December 2003
681 (DAV:collection-must-be-ordered): see Section 6.1.
683 (DAV:segment-must-identify-member): see Section 6.1.
687 (DAV:ordering-type-set): if the request body contained a
688 DAV:ordering-type element, the request MUST have set the
689 DAV:ordering-type property of the collection to the value
690 specified in the request.
692 (DAV:ordering-modified): if the request body contained DAV:order-
693 member elements, the request MUST have set the ordering of
694 internal member URIs in the collection identified by the request-
695 URI based upon the instructions in the DAV:order-member elements.
6977.1. Example: Changing a Collection Ordering
699 Consider an ordered collection /coll-1, with bindings ordered as
709 ORDERPATCH /coll-1/ HTTP/1.1
711 Content-Type: text/xml; charset="utf-8"
714 <?xml version="1.0" ?>
715 <d:orderpatch xmlns:d="DAV:">
717 <d:href>http://example.org/inorder.ord</d:href>
720 <d:segment>two.html</d:segment>
721 <d:position><d:first/></d:position>
724 <d:segment>one.html</d:segment>
725 <d:position><d:first/></d:position>
730Whitehead & Reschke Standards Track [Page 13]
732RFC 3648 WebDAV Ordered Collections Protocol December 2003
736 <d:segment>three.html</d:segment>
737 <d:position><d:last/></d:position>
740 <d:segment>four.html</d:segment>
741 <d:position><d:last/></d:position>
749 In this example, after the request has been processed, the
750 collection's ordering semantics are identified by the URI http://
751 example.org/inorder.ord. The value of the collection's
752 DAV:ordering-type property has been set to this URI. The request
753 also contains instructions for changing the positions of the
754 collection's internal member URIs in the ordering to comply with the
755 new ordering semantics. As the DAV:order-member elements are
756 required to be processed in the order they appear in the request,
757 two.html is moved to the beginning of the ordering, and then one.html
758 is moved to the beginning of the ordering. Then three.html is moved
759 to the end of the ordering, and finally four.html is moved to the end
760 of the ordering. After the request has been processed, the
761 collection's ordering is as follows:
7687.2. Example: Failure of an ORDERPATCH Request
770 Consider a collection /coll-1/ with members ordered as follows:
786Whitehead & Reschke Standards Track [Page 14]
788RFC 3648 WebDAV Ordered Collections Protocol December 2003
793 ORDERPATCH /coll-1/ HTTP/1.1
794 Host: www.nunanet.com
795 Content-Type: text/xml; charset="utf-8"
798 <?xml version="1.0" ?>
799 <d:orderpatch xmlns:d="DAV:">
801 <d:segment>nunavut.desc</d:segment>
804 <d:segment>nunavut.map</d:segment>
809 <d:segment>iqaluit.map</d:segment>
812 <d:segment>pangnirtung.img</d:segment>
820 HTTP/1.1 207 Multi-Status
821 Content-Type: text/xml; charset="utf-8"
824 <?xml version="1.0" ?>
825 <d:multistatus xmlns:d="DAV:">
827 <d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
828 <d:status>HTTP/1.1 403 Forbidden</d:status>
829 <d:responsedescription>
830 <d:error><d:segment-must-identify-member/></d:error>
831 pangnirtung.img is not a collection member.
832 </d:responsedescription>
842Whitehead & Reschke Standards Track [Page 15]
844RFC 3648 WebDAV Ordered Collections Protocol December 2003
847 In this example, the client attempted to position iqaluit.map after a
848 URI that is not an internal member of the collection /coll-1/. The
849 server responded to this client error with a 403 (Forbidden) status
850 code, indicating the failed precondition DAV:segment-must-identify-
851 member. Because ORDERPATCH is an atomic method, the request to
852 reposition nunavut.desc (which would otherwise have succeeded) failed
853 as well, but does not need to be expressed in the multistatus
8568. Listing the Members of an Ordered Collection
858 A PROPFIND request is used to retrieve a listing of the members of an
859 ordered collection, just as it is used to retrieve a listing of the
860 members of an unordered collection.
862 However, when responding to a PROPFIND on an ordered collection, the
863 server MUST order the response elements according to the ordering
864 defined on the collection. If a collection is unordered, the client
865 cannot depend on the repeatability of the ordering of results from a
868 In a response to a PROPFIND with Depth: infinity, members of
869 different collections may be interleaved. That is, the server is not
870 required to do a breadth-first traversal. The only requirement is
871 that the members of any ordered collection appear in the order
872 defined for that collection. Thus, for the hierarchy illustrated in
873 the following figure, where collection A is an ordered collection
874 with the ordering B C D,
883 it would be acceptable for the server to return response elements in
884 the order A B E C F G H D or "A B E C H G F D" as well (if C is
885 unordered). In this response, B, C, and D appear in the correct
886 order, separated by members of other collections. Clients can use a
887 series of Depth: 1 PROPFIND requests to avoid the complexity of
888 processing Depth: infinity responses based on depth-first traversals.
898Whitehead & Reschke Standards Track [Page 16]
900RFC 3648 WebDAV Ordered Collections Protocol December 2003
9038.1. Example: PROPFIND on an Ordered Collection
905 Suppose a PROPFIND request is submitted to /MyColl/, which has its
906 members ordered as follows.
916 PROPFIND /MyColl/ HTTP/1.1
920 Content-Type: text/xml; charset="utf-8"
923 <?xml version="1.0" ?>
924 <D:propfind xmlns:D="DAV:">
925 <D:prop xmlns:J="http://example.org/jsprops/">
934 HTTP/1.1 207 Multi-Status
935 Content-Type: text/xml; charset="utf-8"
938 <?xml version="1.0" ?>
939 <D:multistatus xmlns:D="DAV:"
940 xmlns:J="http://example.org/jsprops/">
942 <D:href>http://example.org/MyColl/</D:href>
946 <D:href>DAV:custom</D:href>
948 <D:resourcetype><D:collection/></D:resourcetype>
950 <D:status>HTTP/1.1 200 OK</D:status>
954Whitehead & Reschke Standards Track [Page 17]
956RFC 3648 WebDAV Ordered Collections Protocol December 2003
964 <D:status>HTTP/1.1 404 Not Found</D:status>
968 <D:href>http://example.org/MyColl/lakehazen.html</D:href>
972 <J:latitude>82N</J:latitude>
974 <D:status>HTTP/1.1 200 OK</D:status>
980 <D:status>HTTP/1.1 404 Not Found</D:status>
985 >http://example.org/MyColl/siorapaluk.html</D:href>
989 <J:latitude>78N</J:latitude>
991 <D:status>HTTP/1.1 200 OK</D:status>
997 <D:status>HTTP/1.1 404 Not Found</D:status>
1001 <D:href>http://example.org/MyColl/iqaluit.html</D:href>
1005 <J:latitude>62N</J:latitude>
1010Whitehead & Reschke Standards Track [Page 18]
1012RFC 3648 WebDAV Ordered Collections Protocol December 2003
1015 <D:status>HTTP/1.1 200 OK</D:status>
1021 <D:status>HTTP/1.1 404 Not Found</D:status>
1025 <D:href>http://example.org/MyColl/newyork.html</D:href>
1029 <J:latitude>45N</J:latitude>
1031 <D:status>HTTP/1.1 200 OK</D:status>
1036 <D:status>HTTP/1.1 404 Not Found</D:status>
1042 In this example, the server responded with a list of the collection
1043 members in the order defined for the collection.
10459. Relationship to versioned collections
1047 The Versioning Extensions to WebDAV [RFC3253] introduce the concept
1048 of versioned collections, recording both the dead properties and the
1049 set of internal version-controlled bindings. This section defines
1050 how this feature interacts with ordered collections.
1052 This specification considers both the ordering type (DAV:ordering-
1053 type property) and the ordering of collection members to be part of
1054 the state of a collection. Therefore, both MUST be recorded upon
1055 CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT,
1056 UNCHECKOUT or UPDATE (where for compatibility with RFC 3253, only the
1057 ordering of version-controlled members needs to be maintained).
1066Whitehead & Reschke Standards Track [Page 19]
1068RFC 3648 WebDAV Ordered Collections Protocol December 2003
10719.1. Collection Version Properties
10739.1.1. Additional semantics for DAV:version-controlled-binding-set
1076 For ordered collections, the DAV:version-controlled-binding elements
1077 MUST appear in the ordering defined for the checked-in ordered
10809.1.2. DAV:ordering-type (protected)
1082 The DAV:ordering-type property records the DAV:ordering-type property
1083 of the checked-in ordered collection.
10859.2. Additional CHECKIN semantics
1087 Additional Postconditions:
1089 (DAV:initialize-version-controlled-bindings-ordered): If the
1090 request-URL identified a both ordered and version-controlled
1091 collection, then the child elements of DAV:version-controlled-
1092 binding-set of the new collection version MUST appear in the
1093 ordering defined for that collection.
1095 (DAV:initialize-collection-version-ordering-type): If the
1096 request-URL identified a both ordered and version-controlled
1097 collection, then the DAV:ordering-type property of the new
1098 collection version MUST be a copy of the collection's
1099 DAV:ordering-type property.
11019.3. Additional CHECKOUT Semantics
1103 Additional Postconditions:
1105 (DAV:initialize-version-history-bindings-ordered): If the request
1106 has been applied to a collection version with a DAV:ordering-type
1107 other than "DAV:unordered", the bindings in the new working
1108 collection MUST be ordered according to the collection version's
1109 DAV:version-controlled-binding-set property.
1111 (DAV:initialize-ordering-type): If the request has been applied to
1112 a collection version, the DAV:ordering-type property of the new
1113 working collection MUST be initialized from the collection
1114 version's DAV:ordering-type property.
1122Whitehead & Reschke Standards Track [Page 20]
1124RFC 3648 WebDAV Ordered Collections Protocol December 2003
11279.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics
1129 Additional Postconditions:
1131 (DAV:update-version-controlled-collection-members-ordered): If the
1132 request modified the DAV:checked-in version of a version-
1133 controlled collection and the DAV:ordering-type for the checked-in
1134 version is not unordered ("DAV:unordered"), the version-controlled
1135 members MUST be ordered according to the checked-in version's
1136 DAV:version-controlled-binding-set property. The ordering of
1137 non-version-controlled members is server-defined.
1139 (DAV:update-version-ordering-type): If the request modified the
1140 DAV:checked-in version of a version-controlled collection, the
1141 DAV:ordering-type property MUST be updated from the checked-in
114410. Capability Discovery
1146 Sections 9.1 and 15 of [RFC2518] describe the use of compliance
1147 classes with the DAV header in responses to OPTIONS, indicating which
1148 parts of the Web Distributed Authoring protocols the resource
1149 supports. This specification defines an OPTIONAL extension to
1150 [RFC2518]. It defines a new compliance class, called ordered-
1151 collections, for use with the DAV header in responses to OPTIONS
1152 requests. If a collection resource does support ordering, its
1153 response to an OPTIONS request may indicate that it does, by listing
1154 the new ORDERPATCH method as one it supports, and by listing the new
1155 ordered-collections compliance class in the DAV header.
1157 When responding to an OPTIONS request, only a collection or a null
1158 resource can include ordered-collections in the value of the DAV
1159 header. By including ordered-collections, the resource indicates
1160 that its internal member URIs can be ordered. It implies nothing
1161 about whether any collections identified by its internal member URIs
1164 Furthermore, RFC 3253 [RFC3253] introduces the live properties
1165 DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
1166 property-set (section 3.1.4). Servers MUST support these properties
1167 as defined in RFC 3253.
1178Whitehead & Reschke Standards Track [Page 21]
1180RFC 3648 WebDAV Ordered Collections Protocol December 2003
118310.1. Example: Using OPTIONS for the Discovery of Support for
1188 OPTIONS /somecollection/ HTTP/1.1
1194 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
1195 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
1196 DAV: 1, 2, ordered-collections
1198 The DAV header in the response indicates that the resource
1199 /somecollection/ is level 1 and level 2 compliant, as defined in
1200 [RFC2518]. In addition, /somecollection/ supports ordering. The
1201 Allow header indicates that ORDERPATCH requests can be submitted to
120410.2. Example: Using Live Properties for the Discovery of Ordering
1207 PROPFIND /somecollection HTTP/1.1
1209 Content-Type: text/xml; charset="utf-8"
1212 <?xml version="1.0" encoding="UTF-8" ?>
1213 <propfind xmlns="DAV:">
1215 <supported-live-property-set/>
1216 <supported-method-set/>
1221 HTTP/1.1 207 Multi-Status
1222 Content-Type: text/xml; charset="utf-8"
1225 <?xml version="1.0" encoding="utf-8" ?>
1226 <multistatus xmlns="DAV:">
1228 <href>http://example.org/somecollection</href>
1234Whitehead & Reschke Standards Track [Page 22]
1236RFC 3648 WebDAV Ordered Collections Protocol December 2003
1239 <supported-live-property-set>
1240 <supported-live-property>
1241 <prop><ordering-type/></prop>
1242 </supported-live-property>
1243 <!-- ... other live properties omitted for brevity ... -->
1244 </supported-live-property-set>
1245 <supported-method-set>
1246 <supported-method name="COPY" />
1247 <supported-method name="DELETE" />
1248 <supported-method name="GET" />
1249 <supported-method name="HEAD" />
1250 <supported-method name="LOCK" />
1251 <supported-method name="MKCOL" />
1252 <supported-method name="MOVE" />
1253 <supported-method name="OPTIONS" />
1254 <supported-method name="ORDERPATCH" />
1255 <supported-method name="POST" />
1256 <supported-method name="PROPFIND" />
1257 <supported-method name="PROPPATCH" />
1258 <supported-method name="PUT" />
1259 <supported-method name="TRACE" />
1260 <supported-method name="UNLOCK" />
1261 </supported-method-set>
1263 <status>HTTP/1.1 200 OK</status>
1268 Note that actual responses MUST contain a complete list of supported
127111. Security Considerations
1273 This section is provided to make WebDAV implementers aware of the
1274 security implications of this protocol.
1276 All of the security considerations of HTTP/1.1 and the WebDAV
1277 Distributed Authoring Protocol specification also apply to this
1278 protocol specification. In addition, ordered collections introduce a
1279 new security concern. This issue is detailed here.
128111.1. Denial of Service and DAV:ordering-type
1283 There may be some risk of denial of service at sites that are
1284 advertised in the DAV:ordering-type property of collections.
1285 However, it is anticipated that widely-deployed applications will use
1286 hard-coded values for frequently-used ordering semantics rather than
1290Whitehead & Reschke Standards Track [Page 23]
1292RFC 3648 WebDAV Ordered Collections Protocol December 2003
1295 looking up the semantics at the location specified by DAV:ordering-
1296 type. This risk will be further reduced if clients observe the
1297 recommendation of Section 5.1 that requests not be sent to the URI in
130012. Internationalization Considerations
1302 This specification follows the practices of [RFC2518] by encoding all
1303 human-readable content using [XML] and in the treatment of names.
1304 Consequently, this specification complies with the IETF Character Set
1307 WebDAV applications MUST support the character set tagging, character
1308 set encoding, and the language tagging functionality of the XML
1309 specification. This constraint ensures that the human-readable
1310 content of this specification complies with [RFC2277].
1312 As in [RFC2518], names in this specification fall into three
1313 categories: names of protocol elements such as methods and headers,
1314 names of XML elements, and names of properties. The naming of
1315 protocol elements follows the precedent of HTTP using English names
1316 encoded in USASCII for methods and headers. The names of XML
1317 elements used in this specification are English names encoded in
1320 For error reporting, [RFC2518] follows the convention of HTTP/1.1
1321 status codes, including with each status code a short, English
1322 description of the code (e.g., 423 Locked). Internationalized
1323 applications will ignore this message, and display an appropriate
1324 message in the user's language and character set.
1326 This specification introduces no new strings that are displayed to
1327 users as part of normal, error-free operation of the protocol.
1329 For the rationale of these decisions and advice for application
1330 implementers, see [RFC2518].
133213. IANA Considerations
1334 This document uses the namespaces defined by [RFC2518] for properties
1335 and XML elements. All other IANA considerations mentioned in
1336 [RFC2518] also apply to this document.
1346Whitehead & Reschke Standards Track [Page 24]
1348RFC 3648 WebDAV Ordered Collections Protocol December 2003
135114. Intellectual Property Statement
1353 The IETF takes no position regarding the validity or scope of any
1354 intellectual property or other rights that might be claimed to
1355 pertain to the implementation or use of the technology described in
1356 this document or the extent to which any license under such rights
1357 might or might not be available; neither does it represent that it
1358 has made any effort to identify any such rights. Information on the
1359 IETF's procedures with respect to rights in standards-track and
1360 standards-related documentation can be found in BCP-11. Copies of
1361 claims of rights made available for publication and any assurances of
1362 licenses to be made available, or the result of an attempt made to
1363 obtain a general license or permission for the use of such
1364 proprietary rights by implementors or users of this specification can
1365 be obtained from the IETF Secretariat.
1367 The IETF invites any interested party to bring to its attention any
1368 copyrights, patents or patent applications, or other proprietary
1369 rights which may cover technology that may be required to practice
1370 this standard. Please address the information to the IETF Executive
1375 This document has benefited from significant contributions from Geoff
1376 Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein.
1380 This document has benefited from thoughtful discussion by Jim Amsden,
1381 Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun,
1382 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa
1383 Dusseault, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann,
1384 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
1385 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
1386 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,
1387 John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
1402Whitehead & Reschke Standards Track [Page 25]
1404RFC 3648 WebDAV Ordered Collections Protocol December 2003
140717. Normative References
1409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1410 Requirement Levels", BCP 14, RFC 2119, March 1997.
1412 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
1413 Languages", BCP 18, RFC 2277, January 1998.
1415 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1416 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1419 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1420 Jensen, "HTTP Extensions for Distributed Authoring --
1421 WEBDAV", RFC 2518, February 1999.
1423 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
1424 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
1425 Protocol -- HTTP/1.1", RFC 2616, June 1999.
1427 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
1428 Whitehead, "Versioning Extensions to WebDAV (Web
1429 Distributed Authoring and Versioning)", RFC 3253, March
1432 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1433 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
1434 xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-
1458Whitehead & Reschke Standards Track [Page 26]
1460RFC 3648 WebDAV Ordered Collections Protocol December 2003
1463Appendix A. Extensions to the WebDAV Document Type Definition
1465 <!ELEMENT orderpatch (ordering-type?, order-member*) >
1466 <!ELEMENT order-member (segment, position) >
1467 <!ELEMENT ordering-type (href) >
1468 <!ELEMENT position (first | last | before | after)>
1469 <!ELEMENT first EMPTY >
1470 <!ELEMENT last EMPTY >
1471 <!ELEMENT before segment >
1472 <!ELEMENT after segment >
1473 <!ELEMENT segment (#PCDATA)>
1478 Client-Maintained Ordering 4
1480 DAV:collection-must-be-ordered (pre) 9
1481 DAV:initialize-collection-version-ordering-type (post) 20
1482 DAV:initialize-ordering-type (post) 21
1483 DAV:initialize-version-controlled-bindings-ordered (post) 20
1484 DAV:initialize-version-history-bindings-ordered (post) 20
1485 DAV:ordered-collections-supported (pre) 7
1486 DAV:ordering-modified (post) 13
1487 DAV:ordering-type-set (post) 7, 13
1488 DAV:position-set (post) 9
1489 DAV:segment-must-identify-member (pre) 9
1490 DAV:update-version-controlled-collection-members-ordered
1492 DAV:update-version-ordering-type (post) 21
1496 compliance class 'ordered-collections' 21
1497 DAV:collection-must-be-ordered precondition 9
1498 DAV:custom ordering type 6
1499 DAV:initialize-collection-version-ordering-type postcondition 20
1500 DAV:initialize-ordering-type postcondition 21
1501 DAV:initialize-version-controlled-bindings-ordered
1503 DAV:initialize-version-history-bindings-ordered postcondition 20
1504 DAV:ordered-collections-supported precondition 7
1505 DAV:ordering-modified postcondition 13
1506 DAV:ordering-type property 6
1507 DAV:ordering-type-set postcondition 7, 13
1508 DAV:position-set postcondition 9
1509 DAV:segment-must-identify-member precondition 9
1510 DAV:unordered ordering type 6
1514Whitehead & Reschke Standards Track [Page 27]
1516RFC 3648 WebDAV Ordered Collections Protocol December 2003
1519 DAV:update-version-controlled-collection-members-ordered
1521 DAV:update-version-ordering-type postcondition 21
1533 Ordered Collection 4
1534 Ordering Semantics 5
1535 Ordering-Type header 7
1536 ORDERPATCH method 11
1544 Server-Maintained Ordering 5
1547 Unordered Collection 4
1570Whitehead & Reschke Standards Track [Page 28]
1572RFC 3648 WebDAV Ordered Collections Protocol December 2003
1578 UC Santa Cruz, Dept. of Computer Science
1580 Santa Cruz, CA 95064
1583 EMail: ejw@cse.ucsc.edu
1586 Julian F. Reschke, Ed.
1592 Phone: +49 251 2807760
1593 Fax: +49 251 2807761
1594 EMail: julian.reschke@greenbytes.de
1595 URI: http://greenbytes.de/tech/webdav/
1626Whitehead & Reschke Standards Track [Page 29]
1628RFC 3648 WebDAV Ordered Collections Protocol December 2003
1631Full Copyright Statement
1633 Copyright (C) The Internet Society (2003). All Rights Reserved.
1635 This document and translations of it may be copied and furnished to
1636 others, and derivative works that comment on or otherwise explain it
1637 or assist in its implementation may be prepared, copied, published
1638 and distributed, in whole or in part, without restriction of any
1639 kind, provided that the above copyright notice and this paragraph are
1640 included on all such copies and derivative works. However, this
1641 document itself may not be modified in any way, such as by removing
1642 the copyright notice or references to the Internet Society or other
1643 Internet organizations, except as needed for the purpose of
1644 developing Internet standards in which case the procedures for
1645 copyrights defined in the Internet Standards process must be
1646 followed, or as required to translate it into languages other than
1649 The limited permissions granted above are perpetual and will not be
1650 revoked by the Internet Society or its successors or assignees.
1652 This document and the information contained herein is provided on an
1653 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1654 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1655 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1656 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1657 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1661 Funding for the RFC Editor function is currently provided by the
1682Whitehead & Reschke Standards Track [Page 30]