Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
Extracted elements (25)
An ordering is considered part of the state of a collection resource, so it is the same regardless of which URI is used to access the collection and is protected by locks and access control constraints on the collection. This design aligns ordering semantics with the existing WebDAV resource-state model.
Only one ordering can be attached to any collection. Multiple orderings of the same resources can be achieved by creating multiple collections referencing those resources with different orderings attached to each. This keeps the model simple while allowing flexibility.
The DAV:orderpatch-response element is defined even though this document defines no child elements for it. This ensures interoperability between future extensions that do define elements for the ORDERPATCH response body, allowing extensibility without breaking existing clients.
The protocol focuses on human-maintained orderings because orderings based on property values can be achieved via search protocol ordering options, but orderings not based on properties (e.g., a book's page order or a reading list) cannot be maintained automatically by the server and generally require human input.
An ordering-aware client interacting with an ordering-unaware server (one implemented only to RFC 2518) SHOULD assume the collection is unordered if the collection does not have the DAV:ordering-type property. This ensures forward compatibility with legacy WebDAV servers.
This specification does not mandate a specific implementation of MOVE operations within the same parent collection. Servers may implement MOVE as a simple rename (preserving position) or as remove-then-add (appending to end). Clients that need to preserve position during rename must explicitly read and re-set the Position header.
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined in this document (specifically DAV:ordering-type).
Both the ordering type (DAV:ordering-type property) and the ordering of collection members MUST be recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, UNCHECKOUT, or UPDATE for version-controlled ordered collections.
Clients SHOULD identify the semantics of the ordering with a URI in the Ordering-Type header when creating an ordered collection, although they MAY use DAV:custom. Clients SHOULD NOT access the resource at the ordering-type URI to avoid overburdening its server.
For ORDERPATCH, when multiple changes are requested and any problem is encountered, the server MUST return a 207 Multi-Status response containing DAV:response elements for either the request-URI (if DAV:ordering-type could not be modified) or URIs of members whose repositioning failed.
If an ORDERPATCH request changes ordering semantics but does not specify positions for all members, the server MUST assign positions for unspecified members following the last client-specified position. If the request does not change ordering semantics, unspecified member positions MUST remain unchanged.
If the Position header is not present when adding a new member to an ordered collection, the server MUST append the new member to the end of the ordering. If the request replaces an existing resource without a Position header, the server MUST preserve the resource's present ordering position.
In an ordered collection, each internal member URI MUST appear in the ordering exactly once, and the ordering MUST NOT include any URIs that are not internal members. The server MUST remove a URI from the ordering when it is removed from the collection, and MUST add a URI when one is added.
WebDAV applications MUST support the character set tagging, character set encoding, and language tagging functionality of the XML specification, ensuring human-readable content complies with IETF character set policy (RFC 2277).
When an ORDERPATCH request is processed, the server MUST apply DAV:order-member changes in the order they appear in the XML element. The server MUST either apply all changes or none; if any error occurs, all executed changes MUST be undone and a proper error returned.
When creating an ordered collection, the Ordering-Type header precondition DAV:ordered-collections-supported requires that the server MUST support ordered collections in the part of the URL namespace identified by the request URL. The postcondition DAV:ordering-type-set requires that the collection MUST be ordered unless the ordering type is DAV:unordered.
When responding to a PROPFIND on an ordered collection, the server MUST order response elements according to the ordering defined on that collection. For Depth: infinity responses, members of different collections may be interleaved, but members of any ordered collection MUST appear in their defined order.
When the Position header is present on a request adding a member, the server MUST insert the new member into the ordering at the specified location. If the request is replacing an existing resource and Position is present, the server MUST remove the URI from its current position and insert it at the newly requested position.
DAV:ordering-type is a protected live property that indicates whether a collection is ordered and, if so, uniquely identifies the semantics of the ordering via a URI. It cannot be set via PROPPATCH; it is set only via the Ordering-Type header on MKCOL or via ORDERPATCH. Two predefined values are DAV:custom (ordered, semantics not advertised) and DAV:unordered (not ordered).
ORDERPATCH is a new HTTP method used to change the ordering semantics of a collection (via a DAV:ordering-type element), change the order of collection members (via DAV:order-member elements), or both. The request body MUST be a DAV:orderpatch XML element. On partial failure the server MUST return 207 Multi-Status.
The ordered-collections compliance class is a new WebDAV compliance class advertised in the DAV header of OPTIONS responses. Only a collection or null resource may include it. Including it signals that the resource's internal member URIs can be ordered, and implies the ORDERPATCH method is supported.
Sites whose URIs appear in DAV:ordering-type properties of widely-deployed collections may be at risk of denial-of-service attacks due to clients fetching those URIs to read ordering semantics. The risk is mitigated if clients use hard-coded values for common ordering semantics and follow the recommendation not to access the ordering-type URI.
The Ordering-Type request header is sent with MKCOL to specify the ordering semantics of the new collection. Its BNF is: `Ordering-Type = "Ordering-Type" ":" absoluteURI`. The value DAV:unordered means unordered; DAV:custom means ordered with unadvertised semantics; any other URI identifies specific ordering semantics.
The ORDERPATCH request body uses the DAV:orderpatch XML element containing an optional DAV:ordering-type child and zero or more DAV:order-member elements, each with a DAV:segment and a DAV:position (first, last, before, or after). The DTD is: `<!ELEMENT orderpatch (ordering-type?, order-member*)>`, `<!ELEMENT order-member (segment, position)>`, `<!ELEMENT position (first | last | before | after)>`.
The Position request header specifies a new collection member's location in an ordered collection's ordering. Its BNF is: `Position = "Position" ":" ("first" | "last" | (("before" | "after") segment))`. The segment is interpreted relative to the collection being modified.