RFC 3648

Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol

📅 published December 2003, from ietf

Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol 🎀

RFC 3648 is a Standards Track spec from December 2003 that adds ordering to WebDAV collections, so the server can keep the members of a folder in a specific order. It's by J. Whitehead (U.C. Santa Cruz) and J. Reschke, Ed. (greenbytes). Its header doesn't list any RFCs it obsoletes or updates. 💖

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and the authors want feedback and suggestions for improvements. To find the current standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright Notice 💅

Abstract 🦋

Okay so this spec extends WebDAV so the server can handle the ordering of collection members. The big deal is orderings that aren't based on property values, which means a search protocol's ordering option can't get you there, and the server can't keep them up on its own either. 😭 The spec defines protocol elements so clients can set each member's position in the ordering, plus the semantics that govern that ordering. ✨

Table of Contents 📑

1.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
4.  Overview of Ordered Collections  . . . . . . . . . . . . . . .  5
    4.1.  Additional Collection properties . . . . . . . . . . . .  6
          4.1.1.  DAV:ordering-type (protected). . . . . . . . . .  6
5.  Creating an Ordered Collection . . . . . . . . . . . . . . . .  7
    5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  7
    5.2.  Example: Creating an Ordered Collection. . . . . . . . .  8
6.  Setting the Position of a Collection Member. . . . . . . . . .  8
    6.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  8
    6.2.  Examples: Setting the Position of a Collection Member. . 10
    6.3.  Examples: Renaming a member of an ordered collection . . 10
7.  Changing a Collection Ordering: ORDERPATCH method. . . . . . . 11
    7.1.  Example: Changing a Collection Ordering. . . . . . . . . 13
    7.2.  Example: Failure of an ORDERPATCH Request. . . . . . . . 14
8.  Listing the Members of an Ordered Collection . . . . . . . . . 16
    8.1.  Example: PROPFIND on an Ordered Collection . . . . . . . 17
9.  Relationship to versioned collections. . . . . . . . . . . . . 19
    9.1.  Collection Version Properties. . . . . . . . . . . . . . 20
          9.1.1.  Additional semantics for
                  DAV:version-controlled-binding-set (protected) . 20
          9.1.2.  DAV:ordering-type (protected). . . . . . . . . . 20
    9.2.  Additional CHECKIN semantics . . . . . . . . . . . . . . 20
    9.3.  Additional CHECKOUT Semantics. . . . . . . . . . . . . . 20
    9.4.  Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . 21
10. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 21
    10.1. Example: Using OPTIONS for the Discovery of Support for
          Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
    10.2. Example: Using Live Properties for the Discovery of
          Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 23
    11.1.  Denial of Service and DAV:ordering-type . . . . . . . . 23
12. Internationalization Considerations. . . . . . . . . . . . . . 24
13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
14. Intellectual Property Statement. . . . . . . . . . . . . . . . 25
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
17. Normative References . . . . . . . . . . . . . . . . . . . . . 26
A.  Extensions to the WebDAV Document Type Definition. . . . . . . 27
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30

1. Notational Conventions ✨

This spec describes extensions to the WebDAV Distributed Authoring Protocol [RFC2518], and WebDAV is itself an extension to HTTP/1.1. So the augmented BNF used here to describe protocol elements is exactly the same as the one in Section 2.1 of HTTP [RFC2616]. That augmented BNF uses the basic production rules from Section 2.2 of HTTP, so those rules apply to this document too. 🧠

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 purely as a notation thing. WebDAV request and response bodies can not be validated, because of the extensibility rules in section 23 of [RFC2518] and because every XML element defined in this spec uses the XML namespace name "DAV:". Specifically: 🙈

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

2. Introduction 🎀

This spec builds on the collection infrastructure from the WebDAV Distributed Authoring Protocol, and adds support for the server-side ordering of collection members. 🧚

Why would you want that? Lots of reasons! A server might need to show a recommended access order, or a revision history order. Think about the pages of a book, which have to be presented in order or they make zero sense. 📖 Or an instructor might build a collection of course readings and want them displayed in the order they should be read. 🍓

Orderings can be based on property values, but they don't have to be. The resources in a collection might not have any properties that could support the ordering you want. Property-based orderings can come from a search protocol's ordering option, but orderings that aren't based on properties can't, and those usually have to be kept up by a human. 😭

The ordering protocol here is built for those human-maintained orderings. Its protocol elements let clients set the position of each collection member in the collection's ordering, and set the semantics that govern the order. The protocol is also designed so that orderings the server maintains automatically can be supported in the future. 🔮

Here's how the rest of the doc is laid out. Section 3 defines the terminology used throughout. Section 4 gives an overview of ordered collections, and Section 5 explains how to create one. Section 6 covers how to set a member's position in a collection's ordering, and Section 7 explains how to change a collection ordering. Section 8 talks about listing the members of an ordered collection. Section 9 covers the impact on version-controlled collections (as defined in [RFC3253]), and Section 10 describes capability discovery. Sections 11 through 13 cover security, internationalization, and IANA considerations. The remaining sections are supporting info. 💅

3. Terminology 💖

The terminology here follows [RFC2518] and [RFC3253]. The definitions of resource, Uniform Resource Identifier (URI), and Uniform Resource Locator (URL) are in [RFC2396]. 📚

Ordered Collection: A collection where the results of a PROPFIND request are guaranteed to be in the order specified for that collection.
Unordered Collection: A collection where the client can't depend on the results of a PROPFIND request coming back in the same order every time.
Client-Maintained Ordering: An ordering of collection members that's maintained on the server, based on client requests that specify the position of each collection member in the ordering.
Server-Maintained Ordering: An ordering of collection members that's maintained automatically by the server, based on a client's choice of ordering semantics.
Ordering Semantics: In general, the set of structures or meanings applied to the ordering of the members of a specific collection. In this document, "ordering semantics" refers specifically to the structure in the DAV:ordering-type property. See Section 4.1.1 for more 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 section 1.6 of this document. 🚨

4. Overview of Ordered Collections 🌈

If a collection isn't ordered, the client can't depend on the results of a PROPFIND request coming back in a repeatable order. ✨ When a client specifies an ordering for a collection, it's basically telling the server to follow that ordering every time it answers a PROPFIND on that collection. 👑

Server-side orderings can be client-maintained or server-maintained. With client-maintained orderings, a client must specify the ordering position of each of the collection's members. It can do that when the member is added (using the Position header (Section 6)) or later (using the ORDERPATCH (Section 7) method). With server-maintained orderings, the server positions each member automatically according to the ordering semantics. This spec only supports client-maintained orderings, but it's designed so server-maintained ones can be added later. 🧩

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 aren't 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's removed from the collection. Removing an internal member MUST NOT affect the ordering of the remaining internal members. And the server MUST add an internal member URI to the ordering when it's added to the collection. 💜

Only one ordering can be attached to any collection. If you want multiple orderings of the same resources, make multiple collections that reference those resources, and attach a different ordering to each one. 🦋

An ordering is considered part of the state of a collection resource. That means the ordering is the same no matter which URI you use to access the collection, and it's protected by locks or access control constraints on the collection. Iconic, honestly. 👑💅

4.1. Additional Collection properties ✨

okay so first things first, bestie: a DAV:allprop PROPFIND request SHOULD NOT hand back any of the properties defined in this document 🙈 these are special, not everything-bagel props 💅

4.1.1. DAV:ordering-type (protected) 🎀

okay this one is the star of the show 🌟 DAV:ordering-type tells you whether a collection is ordered and, if it is, gives you a unique ID for what the ordering actually means 🔥 it can also link to an explanation, in human-readable and/or machine-readable form. at the very least, a human adding members can see where to put them in the order, which is literally the whole point 🫶 you can't set this one with PROPPATCH, though 🙅‍♀️ the only ways to set it are the Ordering-Type header on a MKCOL request or an ORDERPATCH request.

ordering types are identified by URIs that pin down the semantics of the collection's ordering 🧚 two are predefined:

DAV:custom: the collection is ordered, but the rules behind the ordering aren't being advertised 🤷‍♀️
DAV:unordered: the collection isn't ordered at all. so the client can't count on PROPFIND results coming back in the same order every time 💀

an ordering-aware client talking to an ordering-unaware server (one that only follows [RFC2518], say) SHOULD assume the collection is unordered whenever the DAV:ordering-type property is missing 🌸

<!ELEMENT ordering-type (href) >

5. Creating an Ordered Collection 🍓

5.1. Overview 💖

okay so when you make a new collection, the client MAY ask for it to be ordered, and it can spell out the ordering semantics with the brand new Ordering-Type header (more on that below) on a MKCOL request 🧚

for ordered collections, the client SHOULD name the ordering semantics with a URI in the Ordering-Type header 🎯 but if that's too much, the client MAY just set the value to DAV:custom, which means "yep, it's ordered, but I'm not spilling the semantics" 🤐 giving a real URI is the move because it tells a human or a software package exactly how to slot new members in 🔥 the URI in Ordering-Type MAY point at a resource that defines the ordering, BUT clients SHOULD NOT go poking at that resource just to avoid overburdening its server 🙏 a value of DAV:unordered in the header means the client wants a collection that isn't ordered 🌈 and if the header isn't there at all, the collection ends up unordered ✨

Additional Marshalling:

Ordering-Type = "Ordering-Type" ":" absoluteURI
; absoluteURI: see RFC2396, section 3

the URI DAV:unordered means the collection isn't ordered, while DAV:custom means it IS ordered but the semantics aren't being advertised 💅 any other URI means the collection is ordered AND tells you what the ordering means 🫶

Additional Preconditions:

(DAV:ordered-collections-supported): the server MUST support ordered collections in the part of the URL namespace that the request URL points to 🏠

Additional Postconditions:

(DAV:ordering-type-set): if the Ordering-Type header was there, the request MUST have created a new collection resource whose DAV:ordering-type matches the Ordering-Type request header 🎀 the collection MUST be ordered unless the ordering type is DAV:unordered 👑

5.2. Example: Creating an Ordered Collection 🦋

Request:

MKCOL /theNorth/ HTTP/1.1
Host: example.org
Ordering-Type: http://example.org/orderings/compass.html

Response:

HTTP/1.1 201 Created

in this example, a brand new ordered collection gets made 🎉 its DAV:ordering-type property is set to http://example.org/orderings/compass.html, which is the URI from the Ordering-Type header 🧭 that URI names the semantics of an ordering that the client keeps track of itself 💜 as new members come in, clients or end users can check those semantics to figure out where each new member goes 🌟

6. Setting the Position of a Collection Member 🧚‍♀️

6.1. Overview 🌸

okay so when a new member lands in a collection with a client-maintained ordering (think PUT, COPY, or MKCOL), you can decide where it sits with the brand new Position header 🎯 with it, the client can say the member goes first, goes last, goes right before some other internal member URI, or goes right after one 🫶

if the Position request header isn't used when a member is added to an ordered collection, then:

if the request is replacing an existing resource, the server MUST preserve the present ordering 🔒
if the request is adding a new internal member URI to the collection, the server MUST append the new member to the end of the ordering 🚪

note to implementers: this specification does not mandate a specific implementation of MOVE operations within the same parent collection. so servers can either treat it as a simple rename (keeping the member's position), or as a "remove" followed by an "add" (which makes the "adding a new member" rules kick in) 🤸‍♀️ future revisions might get more specific about this once there's more implementation experience 🔮

Additional Marshalling:

Position = "Position" ":" ("first" | "last" |
                          (("before" | "after") segment))

segment is defined in Section 3.3 of [RFC2396] 📖

the segment is read relative to the collection the new member is being added to 🧐

when the Position header is there, the server MUST insert the new member into the ordering at the spot that was asked for 🎯

"first" puts the new member at the very beginning of the collection's ordering 🥇, while "last" puts it at the very end 🏁. "before" slots the new member in right ahead of the member named in the segment, and "after" slots it in right behind that member 🫶

if the request is replacing an existing resource and the Position header is present, the server MUST pull the internal member URI out of its current spot and insert it at the newly requested position 🔄

Additional Preconditions:

(DAV:collection-must-be-ordered): the target collection MUST be ordered 🔢
(DAV:segment-must-identify-member): the referenced segment MUST identify a resource that exists and is different from the affected resource 🕵️‍♀️

Additional Postconditions:

(DAV:position-set): if a Position header is present, the request MUST create the new collection member at the specified position 📍

6.2. Examples: Setting the Position of a Collection Member 🦋

Request:

COPY /~user/dav/spec08.html HTTP/1.1
Host: example.org
Destination: http://example.org/~slein/dav/spec08.html
Position: after requirements.html

Response:

HTTP/1.1 201 Created

this request made a new resource at example.org/~slein/dav/spec08.html ✨ the Position header told the server to slot it into the ordering of the /~slein/dav/ collection right after requirements.html 🎀

Request:

MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1
Host: example.org
Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt
Position: first

Response:

HTTP/1.1 409 Conflict
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
  <D:collection-must-be-ordered/>
</D:error>

and this one got a 409 (Conflict) 🙃 why? because the /~user/dav/ collection is unordered, so the server couldn't make the Position header happen 🤷‍♀️

6.3. Examples: Renaming a member of an ordered collection 🌈

okay so here's the sequence that renames a collection member while keeping its position, no matter how the server does its MOVE stuff 💅

PROPFIND the collection with depth 1, asking for the DAV:ordering-type property (an interactive client has probably already done this to show you the collection's contents 👀)
if the DAV:ordering-type property is there and isn't equal to "dav:unordered" (so the collection is ordered), work out the current position (like "first" or "after x") and set up the Position header to match 🧠
do the MOVE operation, optionally including the Position header you worked out in the previous step 🦋

7. Changing a Collection Ordering: ORDERPATCH method ✨

Okay bestie, the ORDERPATCH method is the one that lets you change a collection's ordering rules, shuffle its members around inside that ordering, or literally both 🦋

The server MUST apply the changes in the order they show up in the order XML element 💅 It MUST either apply all of the changes or apply none of them 🫶 If anything goes wrong during processing, every change that already ran MUST be undone, and the server returns a proper error result 😭

If an ORDERPATCH request changes the ordering semantics but doesn't fully spell out the order of every member, the server MUST give a position in the ordering to each member the client left out 🌸 Those server-assigned positions MUST come after the last position the client specified. So the members the client positioned sit at the front, and the server-assigned ones follow behind 🧚 This document doesn't define how the server-assigned positions get ordered, so servers can use whatever rule seems reasonable, like alphabetical or by creation date 🍓

If an ORDERPATCH request doesn't change the ordering semantics, any member positions it doesn't mention MUST stay exactly where they are 💜

Asking to move a member to the place it already is? Not an error, periodt ✨

If an ORDERPATCH request fails, the server state from before the request MUST be restored 🔥

Additional Marshalling:

The request body MUST be a DAV:orderpatch element 🎀

<!ELEMENT orderpatch (ordering-type?, order-member*) >

<!ELEMENT order-member (segment, position) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT segment (#PCDATA)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >

PCDATA value: segment, as defined in section 3.3 of [RFC2396].

The DAV:ordering-type property gets updated based on the DAV:ordering-type element 💖

The ordering of internal member URIs in the collection at the Request-URI changes based on the instructions in the order-member XML elements, and those get processed in the order they appear in the request 🦋 Each order-member element names an internal member URI whose position should change, and says where it goes. A new position can be 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 successful request includes a response body, it MUST be a DAV:orderpatch-response XML element 🌈 This document doesn't define any elements for the ORDERPATCH response body, but DAV:orderpatch-response is defined so future extensions that do define response elements stay interoperable 🫶

<!ELEMENT orderpatch-response ANY>

Since one ORDERPATCH request can ask for multiple changes, the server MUST return a 207 (Multi-Status) response (defined in [RFC2518]) 🎀 That response contains DAV:response elements for either the Request-URI (when the DAV:ordering-type couldn't be changed) or the URIs of the members being repositioned (when a DAV:order-member positioning request couldn't be fulfilled), if any problems come up 😭

Preconditions:

(DAV:collection-must-be-ordered): see Section 6.1.

(DAV:segment-must-identify-member): see Section 6.1.

Postconditions:

(DAV:ordering-type-set): if the request body had a DAV:ordering-type element, the request MUST have set the collection's DAV:ordering-type property to the value given in the request 🔥

(DAV:ordering-modified): if the request body had DAV:order-member elements, the request MUST have set the ordering of internal member URIs in the collection at the request-URI based on the instructions in those DAV:order-member elements 💅

7.1. Example: Changing a Collection Ordering

Picture an ordered collection /coll-1 with its bindings ordered like this:

three.html
four.html
one.html
two.html

Request:

ORDERPATCH /coll-1/ HTTP/1.1
Host: example.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" ?>
<d:orderpatch xmlns:d="DAV:">
   <d:ordering-type>
      <d:href>http://example.org/inorder.ord</d:href>
   </d:ordering-type>
   <d:order-member>
      <d:segment>two.html</d:segment>
      <d:position><d:first/></d:position>
   </d:order-member>
   <d:order-member>
      <d:segment>one.html</d:segment>
      <d:position><d:first/></d:position>
   </d:order-member>
   <d:order-member>
      <d:segment>three.html</d:segment>
      <d:position><d:last/></d:position>
   </d:order-member>
   <d:order-member>
      <d:segment>four.html</d:segment>
      <d:position><d:last/></d:position>
   </d:order-member>
</d:orderpatch>

Response:

HTTP/1.1 200 OK

Okay so after this request goes through, the collection's ordering semantics are identified by the URI http://example.org/inorder.ord 💖 The collection's DAV:ordering-type property has been set to that URI. The request also includes instructions for moving the collection's internal member URIs around so they match the new ordering semantics 🦋 Because the DAV:order-member elements have to be processed in the order they appear, two.html goes to the front first, then one.html goes to the front, then three.html goes to the end, and finally four.html goes to the end ✨ Once the request is processed, the collection's ordering looks like this:

one.html
two.html
three.html
four.html

7.2. Example: Failure of an ORDERPATCH Request

Now picture a collection /coll-1/ with members ordered like this:

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; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" ?>
<d:orderpatch xmlns:d="DAV:">
   <d:order-member>
      <d:segment>nunavut.desc</d:segment>
      <d:position>
         <d:after>
            <d:segment>nunavut.map</d:segment>
         </d:after>
      </d:position>
   </d:order-member>
   <d:order-member>
      <d:segment>iqaluit.map</d:segment>
      <d:position>
         <d:after>
            <d:segment>pangnirtung.img</d:segment>
         </d:after>
      </d:position>
   </d:order-member>
</d:orderpatch>

Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:">
  <d:response>
    <d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
    <d:status>HTTP/1.1 403 Forbidden</d:status>
    <d:responsedescription>
      <d:error><d:segment-must-identify-member/></d:error>
      pangnirtung.img is not a collection member.
    </d:responsedescription>
  </d:response>
</d:multistatus>

In this one, the client tried to put iqaluit.map after a URI that isn't an internal member of /coll-1/ 😭 The server answered with a 403 (Forbidden) status code to flag the failed precondition DAV:segment-must-identify-member. ORDERPATCH is atomic, so the request to reposition nunavut.desc, which would otherwise have worked, failed too 💀 It doesn't need to show up in the multistatus response body, though.

8. Listing the Members of an Ordered Collection 🍓

Getting a listing of the members of an ordered collection works with a PROPFIND request, the same way it does for an unordered collection 🦋

The big difference is that when the server answers a PROPFIND on an ordered collection, it MUST order the response elements by the collection's ordering 💅 If a collection is unordered, the client can't count on PROPFIND results coming back in the same order every time ✨

With a PROPFIND at Depth: infinity, members of different collections can get interleaved. The server doesn't have to do a breadth-first traversal. The only real rule is that the members of any ordered collection show up in the order defined for that collection 🧚 Check out this hierarchy, where collection A is an ordered collection with the ordering B C D:

So the server could return the response elements as A B E C F G H D, or even A B E C H G F D (if C is unordered) 🌈 In both, B, C, and D stay in the correct order, just separated by members of other collections. If you'd rather skip the complexity of depth-first traversal in Depth: infinity responses, clients can use a series of Depth: 1 PROPFIND requests instead 🫶

8.1. Example: PROPFIND on an Ordered Collection

okay so picture this 💅 a PROPFIND request hits /MyColl/, and its members are already in a specific order:

/MyColl/
   lakehazen.html
   siorapaluk.html
   iqaluit.html
   newyork.html

Request:

PROPFIND /MyColl/ HTTP/1.1

Host: example.org
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
  <D:prop xmlns:J="http://example.org/jsprops/">
    <D:ordering-type/>
    <D:resourcetype/>
    <J:latitude/>
 </D:prop>
</D:propfind>

Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:"
               xmlns:J="http://example.org/jsprops/">
   <D:response>
      <D:href>http://example.org/MyColl/</D:href>
      <D:propstat>
         <D:prop>
            <D:ordering-type>
               <D:href>DAV:custom</D:href>
            </D:ordering-type>
            <D:resourcetype><D:collection/></D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>

      </D:propstat>
      <D:propstat>
         <D:prop>
            <J:latitude/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://example.org/MyColl/lakehazen.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype/>
            <J:latitude>82N</J:latitude>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop>
            <D:ordering-type/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href
      >http://example.org/MyColl/siorapaluk.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype/>
            <J:latitude>78N</J:latitude>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop>
            <D:ordering-type/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://example.org/MyColl/iqaluit.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype/>
            <J:latitude>62N</J:latitude>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop>
            <D:ordering-type/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://example.org/MyColl/newyork.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype/>
            <J:latitude>45N</J:latitude>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      <D:propstat>
         <D:prop>
            <D:ordering-type/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
      </D:propstat>
   </D:response>
</D:multistatus>

the server sends back the member list in the order the collection is defined to have. 🦋 no shuffling, no drama, just vibes in the right order ✨

9. Relationship to versioned collections ✨

okay this part is about how ordering plays with versioned collections 🎀 the Versioning Extensions to WebDAV [RFC3253] introduced versioned collections, which record both the dead properties and the set of internal version-controlled bindings. this section spells out how ordered collections fit into that whole situation 💖

here's the big idea: this spec treats BOTH the ordering type (the DAV:ordering-type property) AND the ordering of collection members as part of a collection's state 🧠 so both MUST be recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, UNCHECKOUT or UPDATE. the only tiny exception is that for compatibility with RFC 3253, just the ordering of version-controlled members needs to be kept 🌸

9.1. Collection Version Properties

9.1.1. Additional semantics for DAV:version-controlled-binding-set (protected)

for ordered collections, the DAV:version-controlled-binding elements MUST appear in the ordering defined for the checked-in ordered collection 🍓

9.1.2. DAV:ordering-type (protected)

the DAV:ordering-type property records the DAV:ordering-type property of the checked-in ordered collection 💜

9.2. Additional CHECKIN semantics

okay so here are the extra postconditions for CHECKIN 👑 (these are the labels, verbatim)

DAV:initialize-version-controlled-bindings-ordered: if the request-URL identified a both ordered and version-controlled collection, then the child elements of DAV:version-controlled-binding-set of the new collection version MUST appear in the ordering defined for that collection.
DAV:initialize-collection-version-ordering-type: if the request-URL identified a both ordered and version-controlled collection, then the DAV:ordering-type property of the new collection version MUST be a copy of the collection's DAV:ordering-type property.

9.3. Additional CHECKOUT Semantics

more postconditions, this time for CHECKOUT 🦋

DAV:initialize-version-history-bindings-ordered: if the request has been applied to a collection version with a DAV:ordering-type other than "DAV:unordered", the bindings in the new working collection MUST be ordered according to the collection version's DAV:version-controlled-binding-set property.
DAV:initialize-ordering-type: if the request has been applied to a collection version, the DAV:ordering-type property of the new working collection MUST be initialized from the collection version's DAV:ordering-type property.

9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics

and the last set of postconditions, for UNCHECKOUT, UPDATE and MERGE 🌈

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 🫶
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 🔍

how does a client find out whether a server can do ordering? 🤔 sections 9.1 and 15 of [RFC2518] describe using compliance classes in the DAV header on OPTIONS responses, to show which parts of the Web Distributed Authoring protocols a resource supports. this spec adds an OPTIONAL extension to [RFC2518] 💅 it defines a new compliance class called ordered-collections, which goes in the DAV header on OPTIONS responses.

if a collection supports ordering, its OPTIONS response can show that by listing the new ORDERPATCH method as supported, and by listing the 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 DAV header value 🎀 including it means the resource's internal member URIs can be ordered. it says nothing about whether collections identified by those internal member URIs can be ordered 🙈

on top of that, RFC 3253 [RFC3253] introduces the live properties DAV:supported-method-set (section 3.1.3) and DAV:supported-live-property-set (section 3.1.4). servers MUST support these properties as defined in RFC 3253 🫶

10.1. Example: Using OPTIONS for the Discovery of Support for Ordering

Request:

OPTIONS /somecollection/ HTTP/1.1
Host: example.org

Response:

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
DAV: 1, 2, ordered-collections

so the DAV header says /somecollection/ is level 1 and level 2 compliant, as defined in [RFC2518] 💖 plus, it supports ordering! and the Allow header shows that ORDERPATCH requests can be sent to /somecollection/ 🍓

10.2. Example: Using Live Properties for the Discovery of Ordering

Request:

PROPFIND /somecollection HTTP/1.1
Depth: 0
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="UTF-8" ?>
<propfind xmlns="DAV:">
  <prop>
    <supported-live-property-set/>
    <supported-method-set/>
  </prop>
</propfind>

Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
  <response>
    <href>http://example.org/somecollection</href>
    <propstat>
      <prop>

        <supported-live-property-set>
          <supported-live-property>
            <prop><ordering-type/></prop>
          </supported-live-property>
          <!-- ... other live properties omitted for brevity ... -->
        </supported-live-property-set>
        <supported-method-set>
          <supported-method name="COPY" />
          <supported-method name="DELETE" />
          <supported-method name="GET" />
          <supported-method name="HEAD" />
          <supported-method name="LOCK" />
          <supported-method name="MKCOL" />
          <supported-method name="MOVE" />
          <supported-method name="OPTIONS" />
          <supported-method name="ORDERPATCH" />
          <supported-method name="POST" />
          <supported-method name="PROPFIND" />
          <supported-method name="PROPPATCH" />
          <supported-method name="PUT" />
          <supported-method name="TRACE" />
          <supported-method name="UNLOCK" />
        </supported-method-set>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>

note that actual responses MUST contain a complete list of supported live properties 📝 no skipping allowed, bestie 💅

11. Security Considerations 🔐

this section is here to make WebDAV implementers aware of the security implications of this protocol 🚨 seriously, read this part

all of the security considerations of HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification also apply to this protocol specification 💀 on top of that, ordered collections bring a brand new security concern, and it's detailed right here 👇

11.1. Denial of Service and DAV:ordering-type

okay, real talk 😭 there may be some risk of denial of service at sites that are advertised in the DAV:ordering-type property of collections. BUT it's 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:ordering-type 🙌 and this risk gets smaller if clients follow the recommendation of Section 5.1 not to send requests to the URI in DAV:ordering-type 🫶

12. Internationalization Considerations 🌍

okay so this bit is about languages and characters 🌸 This spec copies what [RFC2518] does by encoding all the human-readable stuff with [XML] and handling names the same way. So it 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 is the rule that makes sure all the human-readable content in this spec follows [RFC2277] 🫶

Like in [RFC2518], names in this spec come in three flavors: names of protocol elements (like methods and headers), names of XML elements, and names of properties 💅 Protocol element names follow HTTP's lead and use English names in USASCII for methods and headers. The XML element names here are English names encoded in UTF-8 🦋

For error reporting, [RFC2518] copies the HTTP/1.1 status code vibe, pairing each code with a short English description, like 423 Locked 🔒 Internationalized apps will just ignore that message and show a proper message in the user's own language and character set. Iconic behavior honestly 👑

This spec introduces no new strings that get shown to users during normal, error-free operation of the protocol 🎀

For the reasoning behind all of this and tips for app builders, check out [RFC2518] 📚

13. IANA Considerations 🧚

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 💜

14. Intellectual Property Statement ⚖️

The IETF takes no position on whether any intellectual property or other rights that someone claims about the tech in this document are valid, or how far they reach. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim it has tried to find any such rights 🙈 If you want info on how the IETF handles rights for standards-track and standards-related docs, look at BCP-11. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementors or users to use such proprietary rights, can be obtained from the IETF Secretariat 📬

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Send that info to the IETF Executive Director 💌

15. Contributors 🌷

This document got some seriously big help from Geoff Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 🫶💖

16. Acknowledgements 🍓

This document benefited from thoughtful discussion by a whole squad of people: Jim Amsden, 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 🌈 iykyk, the whole group chat was involved 😭

17. 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.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 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.
[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.

Appendix A. Extensions to the WebDAV Document Type Definition 🎀

Here's the DTD for all the extra WebDAV bits, copied exactly as written 💅

<!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT order-member (segment, position) >
<!ELEMENT ordering-type (href) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)>

Index 📇

C
   Client-Maintained Ordering  4
   Condition Names
      DAV:collection-must-be-ordered (pre)  9
      DAV:initialize-collection-version-ordering-type (post)  20
      DAV:initialize-ordering-type (post)  21
      DAV:initialize-version-controlled-bindings-ordered (post)  20
      DAV:initialize-version-history-bindings-ordered (post)  20
      DAV:ordered-collections-supported (pre)  7
      DAV:ordering-modified (post)  13
      DAV:ordering-type-set (post)  7, 13
      DAV:position-set (post)  9
      DAV:segment-must-identify-member (pre)  9
      DAV:update-version-controlled-collection-members-ordered
          (post) 21
      DAV:update-version-ordering-type (post)  21

D
   DAV header
      compliance class 'ordered-collections'  21
   DAV:collection-must-be-ordered precondition  9
   DAV:custom ordering type  6
   DAV:initialize-collection-version-ordering-type postcondition  20
   DAV:initialize-ordering-type postcondition  21
   DAV:initialize-version-controlled-bindings-ordered
       postcondition 20
   DAV:initialize-version-history-bindings-ordered postcondition  20
   DAV:ordered-collections-supported precondition  7
   DAV:ordering-modified postcondition  13
   DAV:ordering-type property  6
   DAV:ordering-type-set postcondition  7, 13
   DAV:position-set postcondition  9
   DAV:segment-must-identify-member precondition  9
   DAV:unordered ordering type  6
   DAV:update-version-controlled-collection-members-ordered
       postcondition  21
   DAV:update-version-ordering-type postcondition  21

H
   Headers
      Ordering-Type  7
      Position  9

M
   Methods
      ORDERPATCH  11

O
   Ordered Collection  4
   Ordering Semantics  5
   Ordering-Type header  7
   ORDERPATCH method  11

P
   Position header  9
   Properties
      DAV:ordering-type  6

S
   Server-Maintained Ordering  5

U
   Unordered Collection  4

Authors' Addresses 📮

Jim Whitehead
UC Santa Cruz, Dept. of Computer Science
1156 High Street
Santa Cruz, CA  95064
US

EMail: ejw@cse.ucsc.edu


Julian F. Reschke, Ed.
greenbytes GmbH
Salzmannstrasse 152
Muenster, NW  48159
Germany

Phone: +49 251 2807760
Fax:   +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI:   http://greenbytes.de/tech/webdav/

Here's the legal stuff, kept word for word so nothing gets lost 🫶

Copyright (C) The Internet Society (2003).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

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 🌸

Funding for the RFC Editor function is currently provided by the Internet Society ✨ And that's a wrap on RFC 3648, bestie 🦋💖

📦 where this page comes from

ietf: rfc3648 2003-12
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 3648

Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol 🎀

Status of This Memo ✨

Copyright Notice 💅

Abstract 🦋

Table of Contents 📑

1. Notational Conventions ✨

2. Introduction 🎀

3. Terminology 💖

4. Overview of Ordered Collections 🌈

4.1. Additional Collection properties ✨

4.1.1. DAV:ordering-type (protected) 🎀

5. Creating an Ordered Collection 🍓

5.1. Overview 💖

5.2. Example: Creating an Ordered Collection 🦋

6. Setting the Position of a Collection Member 🧚‍♀️

6.1. Overview 🌸

6.2. Examples: Setting the Position of a Collection Member 🦋

6.3. Examples: Renaming a member of an ordered collection 🌈

7. Changing a Collection Ordering: ORDERPATCH method ✨

7.1. Example: Changing a Collection Ordering

7.2. Example: Failure of an ORDERPATCH Request

8. Listing the Members of an Ordered Collection 🍓

8.1. Example: PROPFIND on an Ordered Collection

9. Relationship to versioned collections ✨

9.1. Collection Version Properties

9.1.1. Additional semantics for DAV:version-controlled-binding-set (protected)

9.1.2. DAV:ordering-type (protected)

9.2. Additional CHECKIN semantics

9.3. Additional CHECKOUT Semantics

9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics

10. Capability Discovery 🔍

10.1. Example: Using OPTIONS for the Discovery of Support for Ordering

10.2. Example: Using Live Properties for the Discovery of Ordering

11. Security Considerations 🔐

11.1. Denial of Service and DAV:ordering-type

12. Internationalization Considerations 🌍

13. IANA Considerations 🧚

14. Intellectual Property Statement ⚖️

15. Contributors 🌷

16. Acknowledgements 🍓

17. Normative References 📖

Appendix A. Extensions to the WebDAV Document Type Definition 🎀

Index 📇

Authors' Addresses 📮

Full Copyright Statement ©️

Acknowledgement 🌸