Summary

  • RFC 3648 makes ordering collection state, but a MOVE within one parent may preserve the member’s position or remove and re-add it, which appends it when no Position is supplied.
  • A defensible automation record must connect the intended sequence, capability and authority, exact request, response, Depth: 1 ordered readback and downstream presentation; a 2xx response proves only part of that chain.

The awkward result begins with a deliberate specification choice. RFC 3648 defines client-maintained ordered WebDAV collections. For a MOVE whose source and destination share the same parent, a server may implement the change as a simple rename and preserve the member’s position. It may instead perform the equivalent of removing the old member and adding a new one. Under the new-member rule, an absent Position means append. Both behaviours fit the frozen standard.

That does not mean the protocol is vague about everything. In an unordered collection, clients receive no guarantee that repeated PROPFIND responses will enumerate members in the same order. In an ordered collection, the server must follow the collection’s order in PROPFIND responses. Every internal member appears exactly once; non-members may not be inserted into the sequence. Removal deletes the member without rearranging the relative order of survivors. These constraints make sequence observable state rather than decorative metadata.

The plain-text specification also makes the scope clear: the RFC defines client-maintained ordering and leaves server-maintained ordering as a future extension. It was published on the Standards Track in December 2003. Its Datatracker record, RFC Editor information page, history and errata record establish the document lineage. They do not identify what any present server does by default.

Ordering belongs to the collection. The same collection resource exposes the same ordering through its access URIs, and its order is subject to the collection’s locks and access controls. It supports only one ordering. If an application needs several sequences over the same underlying resources, RFC 3648’s model uses several collections. RFC 5842 helps separate multiple bindings to one resource from the different state carried by different collections.

The protected DAV:ordering-type property describes the semantics a collection claims. DAV:unordered says a repeatable PROPFIND order must not be assumed. DAV:custom says an order exists without advertising portable meaning for it. A URI can name another ordering type, but the security section warns clients not to fetch that URI automatically: mass dereferencing could be turned toward a denial-of-service target. The URI is a semantic identifier, not an instruction to invoke a service.

The client can narrow the MOVE latitude. The Position request field can ask for first, last, before a named segment or after one. A client that must preserve location can first read the ordered collection, calculate a relative position and send MOVE with Position. The field remains listed in the IANA HTTP Field Name Registry with RFC 3648 as its specification.

Explicit position is still intent, not the final fact. The reference segment must identify a current member and must differ from the member being moved. The collection must be ordered. Locks and permissions must be satisfied. RFC 3648 defines DAV:collection-must-be-ordered and DAV:segment-must-identify-member preconditions for those boundaries. RFC 3744 supplies WebDAV access-control semantics; knowing a URI or segment does not confer authority to change its collection.

ORDERPATCH exposes a different control surface. Its order-member instructions are processed in document order, and the server must apply all changes or none. On failure it restores the previous state. That is meaningful local atomicity. It is not evidence that caches, search indexes, rendered navigation or a reader observed the same result. Multi-change problems can be reported with 207 Multi-Status, while a successful DAV:orderpatch-response carries no RFC-defined success detail.

Omission changes meaning depending on the request. When an ORDERPATCH keeps the existing ordering semantics, members left out retain their positions. When it changes the ordering semantics, the named members come first and every omitted member follows in a relative order chosen by the server. A request may therefore be atomic and successful while leaving part of the final sequence deliberately unspecified. A controller that records only the named members silently turns a partial intention into a false complete order.

The direct protocol readback is a Depth: 1 PROPFIND on the collection. Depth: infinity can interleave descendants while preserving each ordered collection’s local sequence, so it is not a flat global order receipt. The older RFC 2518 supplied the WebDAV base referenced by RFC 3648; RFC 4918 later replaced it. Neither change turns a response code into proof of what a user interface displayed.

Versioning adds another boundary. RFC 3253 provides DeltaV collection versioning. RFC 3648 records the ordering type and the order of version-controlled members in a collection version and restores them on UPDATE or MERGE. The position of non-version-controlled members remains server-defined. “Restored the collection version” is therefore not enough to claim every visible member returned to a single canonical place.

Capability itself must be observed. Ordered collections are optional. OPTIONS can expose the ordered-collections compliance class, while supported-method and live-property discovery can describe a particular resource. Support at one collection says nothing about its children. RFC 5689 extends MKCOL request bodies, but the ability to submit extra properties does not prove that ordered-collection semantics were accepted.

General HTTP validators can strengthen deployment-specific controls without changing the RFC’s claims. RFC 7232 and the current HTTP semantics in RFC 9110 define conditional request machinery. RFC 3648 does not define a dedicated order revision token or state digest. If a deployment exposes a validator useful for ordering, the receipt must name and test that implementation fact rather than attribute it to RFC 3648.

Even the positioning vocabulary has historical limits. RFC 3648 draws on the URI and segment terminology of RFC 2396; RFC 3986 later updated general URI syntax. A segment in before or after is an operand resolved against present membership. It is not a permanent identity, an authorization token or a promise that the reference will still exist when another observer reads the collection.

Heng Lu’s accounts of running-code primacy, minimum initial specification and reality layers provide the right governance lens. The standard establishes a portable minimum and openly preserves implementation latitude. Running code selects an allowed behaviour. Observation establishes the state it actually exposed. Presentation and human use are later layers again.

The operational receipt should retain collection identity and access URI, ordering type, complete before-state, capability discovery, applicable lock and authority decision, exact MOVE or ORDERPATCH bytes, any Position and referenced segment, response, complete Depth: 1 after-state, version or validator when actually available, and the consumer’s rendered sequence. Missing links should remain visible as uncertainty. They should not be filled by promoting the 2xx response into a claim the protocol never made.