draft-ietf-webdav-ordering-protocol-10.txt   rfc3648.txt 
WEBDAV Working Group J. Whitehead Network Working Group J. Whitehead
Internet-Draft U.C. Santa Cruz Request for Comments: 3648 U.C. Santa Cruz
Expires: February 6, 2004 J. Reschke, Ed. Category: Standards Track J. Reschke, Ed.
greenbytes greenbytes
August 8, 2003 December 2003
WebDAV Ordered Collections Protocol Web Distributed Authoring and Versioning (WebDAV)
draft-ietf-webdav-ordering-protocol-10 Ordered Collections Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that other and status of this protocol. Distribution of this memo is unlimited.
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 6, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This specification extends the WebDAV Distributed Authoring Protocol This specification extends the Web Distributed Authoring and
to support server-side ordering of collection members. Of particular Versioning (WebDAV) Protocol to support the server-side ordering of
interest are orderings that are not based on property values, and so collection members. Of particular interest are orderings that are
cannot be achieved using a search protocol's ordering option and not based on property values, and so cannot be achieved using a
cannot be maintained automatically by the server. Protocol elements search protocol's ordering option and cannot be maintained
are defined to let clients specify the position in the ordering of automatically by the server. Protocol elements are defined to let
each collection member, as well as the semantics governing the clients specify the position in the ordering of each collection
ordering. member, as well as the semantics governing the ordering.
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org [1], which may be joined by sending a message
with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL: http://
lists.w3.org/Archives/Public/w3c-dist-auth/.
Table of Contents Table of Contents
1. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Ordered Collections . . . . . . . . . . . . . . 7 4. Overview of Ordered Collections . . . . . . . . . . . . . . . 5
4.1 Additional Collection properties . . . . . . . . . . . . . . 7 4.1. Additional Collection properties . . . . . . . . . . . . 6
4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 7 4.1.1. DAV:ordering-type (protected). . . . . . . . . . 6
5. Creating an Ordered Collection . . . . . . . . . . . . . . . 9 5. Creating an Ordered Collection . . . . . . . . . . . . . . . . 7
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Example: Creating an Ordered Collection . . . . . . . . . . 10 5.2. Example: Creating an Ordered Collection. . . . . . . . . 8
6. Setting the Position of a Collection Member . . . . . . . . 11 6. Setting the Position of a Collection Member. . . . . . . . . . 8
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Examples: Setting the Position of a Collection Member . . . 12 6.2. Examples: Setting the Position of a Collection Member. . 10
6.3 Examples: Renaming a member of an ordered collection . . . . 13 6.3. Examples: Renaming a member of an ordered collection . . 10
7. Changing a Collection Ordering: ORDERPATCH method . . . . . 14 7. Changing a Collection Ordering: ORDERPATCH method. . . . . . . 11
7.1 Example: Changing a Collection Ordering . . . . . . . . . . 16 7.1. Example: Changing a Collection Ordering. . . . . . . . . 13
7.2 Example: Failure of an ORDERPATCH Request . . . . . . . . . 17 7.2. Example: Failure of an ORDERPATCH Request. . . . . . . . 14
8. Listing the Members of an Ordered Collection . . . . . . . . 19 8. Listing the Members of an Ordered Collection . . . . . . . . . 16
8.1 Example: PROPFIND on an Ordered Collection . . . . . . . . . 19 8.1. Example: PROPFIND on an Ordered Collection . . . . . . . 17
9. Relationship to versioned collections . . . . . . . . . . . 23 9. Relationship to versioned collections. . . . . . . . . . . . . 19
9.1 Collection Version Properties . . . . . . . . . . . . . . . 23 9.1. Collection Version Properties. . . . . . . . . . . . . . 20
9.1.1 Additional semantics for 9.1.1. Additional semantics for
DAV:version-controlled-binding-set (protected) . . . . . . . 23 DAV:version-controlled-binding-set (protected) . 20
9.1.2 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 23 9.1.2. DAV:ordering-type (protected). . . . . . . . . . 20
9.2 Additional CHECKIN semantics . . . . . . . . . . . . . . . . 23 9.2. Additional CHECKIN semantics . . . . . . . . . . . . . . 20
9.3 Additional CHECKOUT Semantics . . . . . . . . . . . . . . . 24 9.3. Additional CHECKOUT Semantics. . . . . . . . . . . . . . 20
9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . . . 24 9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . 21
10. Capability Discovery . . . . . . . . . . . . . . . . . . . . 25 10. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 21
10.1 Example: Using OPTIONS for the Discovery of Support for 10.1. Example: Using OPTIONS for the Discovery of Support for
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 Example: Using Live Properties for the Discovery of 10.2. Example: Using Live Properties for the Discovery of
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . 28 11. Security Considerations. . . . . . . . . . . . . . . . . . . . 23
11.1 Denial of Service and DAV:ordering-type . . . . . . . . . . 28 11.1. Denial of Service and DAV:ordering-type . . . . . . . . 23
12. Internationalization Considerations . . . . . . . . . . . . 29 12. Internationalization Considerations. . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Intellectual Property Statement. . . . . . . . . . . . . . . . 25
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
Normative References . . . . . . . . . . . . . . . . . . . . 33 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 17. Normative References . . . . . . . . . . . . . . . . . . . . . 26
A. Extensions to the WebDAV Document Type Definition . . . . . 35 A. Extensions to the WebDAV Document Type Definition. . . . . . . 27
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
1. Notational Conventions 1. Notational Conventions
Since this document describes a set of extensions to the WebDAV Since this document describes a set of extensions to the WebDAV
Distributed Authoring Protocol [RFC2518], itself an extension to the Distributed Authoring Protocol [RFC2518], which is itself an
HTTP/1.1 protocol, the augmented BNF used here to describe protocol extension to the HTTP/1.1 protocol, the augmented BNF used here to
elements is exactly the same as described in Section 2.1 of HTTP describe protocol elements is exactly the same as described in
[RFC2616]. Since this augmented BNF uses the basic production rules Section 2.1 of HTTP [RFC2616]. Since this augmented BNF uses the
provided in Section 2.2 of HTTP, these rules apply to this document basic production rules provided in Section 2.2 of HTTP, these rules
as well. apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses XML DTD fragments as a purely notational This document uses XML DTD fragments as a purely notational
convention. WebDAV request and response bodies can not be validated convention. WebDAV request and response bodies can not be validated
due to the specific extensibility rules defined in section 23 of due to the specific extensibility rules defined in section 23 of
[RFC2518] and due to the fact that all XML elements defined by this [RFC2518] and due to the fact that all XML elements defined by this
specification use the XML namespace name "DAV:". In particular: specification use the XML namespace name "DAV:". In particular:
1. element names use the "DAV:" namespace, 1. element names use the "DAV:" namespace,
2. element ordering is irrelevant, 2. element ordering is irrelevant,
3. extension elements (elements not already defined as valid child 3. extension elements (elements not already defined as valid child
elements) may be added anywhere, except when explicitly stated elements) may be added anywhere, except where explicitly stated
otherwise, otherwise,
4. extension attributes (attributes not already defined as valid for 4. extension attributes (attributes not already defined as valid for
this element) may be added anywhere, except when explicitly this element) may be added anywhere, except where explicitly
stated otherwise. stated otherwise.
2. Introduction 2. Introduction
This specification builds on the collection infrastructure provided This specification builds on the collection infrastructure provided
by the WebDAV Distributed Authoring Protocol, adding support for the by the WebDAV Distributed Authoring Protocol, adding support for the
server-side ordering of collection members. server-side ordering of collection members.
There are many scenarios where it is useful to impose an ordering on There are many scenarios in which it is useful to impose an ordering
a collection at the server, such as expressing a recommended access on a collection at the server, such as expressing a recommended
order, or a revision history order. The members of a collection access order, or a revision history order. The members of a
might represent the pages of a book, which need to be presented in collection might represent the pages of a book, which need to be
order if they are to make sense. Or an instructor might create a presented in order if they are to make sense, or an instructor might
collection of course readings, which she wants to be displayed in the create a collection of course readings that she wants to be displayed
order they are to be read. in the order they are to be read.
Orderings may be based on property values, but this is not always the Orderings may be based on property values, but this is not always the
case. The resources in the collection may not have properties that case. The resources in the collection may not have properties that
can be used to support the desired ordering. Orderings based on can be used to support the desired ordering. Orderings based on
properties can be obtained using a search protocol's ordering option, properties can be obtained using a search protocol's ordering option,
but orderings not based on properties cannot. These orderings but orderings not based on properties cannot. These orderings
generally need to be maintained by a human user. generally need to be maintained by a human user.
The ordering protocol defined here focuses on support for such The ordering protocol defined here focuses on support for such
human-maintained orderings. Its protocol elements allow clients to human-maintained orderings. Its protocol elements allow clients to
specify the position of each collection member in the collection's specify the position of each collection member in the collection's
ordering, as well as the semantics governing the ordering. The ordering, as well as the semantics governing the order. The protocol
protocol is designed to allow support to be added in the future for is designed to allow additional support in the future for orderings
orderings that are maintained automatically by the server. that are maintained automatically by the server.
The remainder of this document is structured as follows: Section 3 The remainder of this document is structured as follows: Section 3
defines terminology that will be used throughout the specification. defines terminology that will be used throughout the specification.
Section 4 provides an overview of ordered collections. Section 5 Section 4 provides an overview of ordered collections. Section 5
describes how to create an ordered collection, and Section 6 describes how to create an ordered collection, and Section 6
discusses how to set a member's position in the ordering of a discusses how to set a member's position in the ordering of a
collection. Section 7 explains how to change a collection ordering. collection. Section 7 explains how to change a collection ordering.
Section 8 discusses listing the members of an ordered collection. Section 8 discusses listing the members of an ordered collection.
Section 9 discusses the impact on version-controlled collections (as Section 9 discusses the impact on version-controlled collections (as
defined in [RFC3253]. Section 10 describes capability discovery. defined in [RFC3253]). Section 10 describes capability discovery.
Section 11 through Section 13 discuss security, internationalization, Sections 11 through 13 discuss security, internationalization, and
and IANA considerations. The remaining sections provide supporting IANA considerations. The remaining sections provide supporting
information. information.
3. Terminology 3. Terminology
The terminology used here follows that in [RFC2518] and [RFC3253]. The terminology used here follows that in [RFC2518] and [RFC3253].
Definitions of the terms resource, Uniform Resource Identifier (URI), Definitions of the terms resource, Uniform Resource Identifier (URI),
and Uniform Resource Locator (URL) are provided in [RFC2396]. and Uniform Resource Locator (URL) are provided in [RFC2396].
Ordered Collection Ordered Collection
A collection for which the results from a PROPFIND request are A collection for which the results from a PROPFIND request are
guaranteed to be in the order specified for that collection guaranteed to be in the order specified for that collection.
Unordered Collection Unordered Collection
A collection for which the client cannot depend on the A collection for which the client cannot depend on the
repeatability of the ordering of results from a PROPFIND request repeatability of the ordering of results from a PROPFIND request.
Client-Maintained Ordering Client-Maintained Ordering
An ordering of collection members that is maintained on the server An ordering of collection members that is maintained on the server
based on client requests specifying the position of each based on client requests specifying the position of each
collection member in the ordering collection member in the ordering.
Server-Maintained Ordering Server-Maintained Ordering
An ordering of collection members that is maintained automatically An ordering of collection members that is maintained automatically
by the server, based on a client's choice of ordering semantics by the server, based on a client's choice of ordering semantics.
Ordering Semantics Ordering Semantics
In general, ordering semantics are the set of structures or In general, ordering semantics are the set of structures or
meanings applied to the ordering of the member of a specific meanings applied to the ordering of the member of a specific
collection. Within this document, "ordering semantics" refers collection. Within this document, "ordering semantics" refers
specifically to the structure specified in the DAV:ordering-type specifically to the structure specified in the DAV:ordering-type
property. See Section 4.1.1 for more information on property. See Section 4.1.1 for more information on
DAV:ordering-type. DAV:ordering-type.
This document uses the terms "precondition", "postcondition" and This document uses the terms "precondition", "postcondition" and
"protected property" as defined in [RFC3253]. Servers MUST report "protected property" as defined in [RFC3253]. Servers MUST report
pre-/postcondition failures as described in section 1.6 of this pre-/postcondition failures as described in section 1.6 of this
document. document.
4. Overview of Ordered Collections 4. Overview of Ordered Collections
If a collection is unordered, the client cannot depend on the If a collection is not ordered, the client cannot depend on the
repeatability of the ordering of results from a PROPFIND request. By repeatability of the ordering of results from a PROPFIND request. By
specifying an ordering for a collection, a client requires the server specifying an ordering for a collection, a client requires the server
to follow that ordering whenever it responds to a PROPFIND request on to follow that ordering whenever it responds to a PROPFIND request on
that collection. that collection.
Server-side orderings may be client-maintained or server-maintained. Server-side orderings may be client-maintained or server-maintained.
For client-maintained orderings, a client must specify the ordering For client-maintained orderings, a client must specify the ordering
position of each of the collection's members, either when the member position of each of the collection's members, either when the member
is added to the collection (using the Position header (Section 6)) or is added to the collection (using the Position header (Section 6)) or
later (using the ORDERPATCH (Section 7) method). For later (using the ORDERPATCH (Section 7) method). For server-
server-maintained orderings, the server automatically positions each maintained orderings, the server automatically positions each of the
of the collection's members according to the ordering semantics. collection's members according to the ordering semantics. This
This specification supports only client-maintained orderings, but is specification supports only client-maintained orderings, but is
designed to allow future extension to server-maintained orderings. designed to allow the future extension with server-maintained
orderings.
A collection that supports ordering is not required to be ordered. A collection that supports ordering is not required to be ordered.
If a collection is ordered, each of its internal member URIs MUST be If a collection is ordered, each of its internal member URIs MUST
in the ordering exactly once, and the ordering MUST NOT include any appear in the ordering exactly once, and the ordering MUST NOT
URI that is not an internal member of the collection. The server is include any URIs that are not internal members of the collection.
responsible for enforcing these constraints on orderings. The server The server is responsible for enforcing these constraints on
MUST remove an internal member URI from the ordering when it is orderings. The server MUST remove an internal member URI from the
removed from the collection. Removing an internal member MUST NOT ordering when it is removed from the collection. Removing an
affect the ordering of the remaining internal members. The server internal member MUST NOT affect the ordering of the remaining
MUST add an internal member URI to the ordering when it is added to internal members. The server MUST add an internal member URI to the
the collection. ordering when it is added to the collection.
Only one ordering can be attached to any collection. Multiple Only one ordering can be attached to any collection. Multiple
orderings of the same resources can be achieved by creating multiple orderings of the same resources can be achieved by creating multiple
collections referencing those resources, and attaching a different collections referencing those resources, and attaching a different
ordering to each collection. ordering to each collection.
An ordering is considered to be part of the state of a collection An ordering is considered to be part of the state of a collection
resource. Consequently, the ordering is the same no matter which URI resource. Consequently, the ordering is the same no matter which URI
is used to access the collection and is protected by locks or access is used to access the collection and is protected by locks or access
control constraints on the collection. control constraints on the collection.
4.1 Additional Collection properties 4.1. Additional Collection properties
A DAV:allprop PROPFIND request SHOULD NOT return any of the A DAV:allprop PROPFIND request SHOULD NOT return any of the
properties defined in this document. properties defined in this document.
4.1.1 DAV:ordering-type (protected) 4.1.1. DAV:ordering-type (protected)
Indicates whether the collection is ordered and, if so, uniquely The DAV:ordering-type property indicates whether the collection is
identifies the semantics of the ordering being used. May also point ordered and, if so, uniquely identifies the semantics of the
to an explanation of the semantics in human and / or machine-readable ordering. It may also point to an explanation of the semantics in
form. At a minimum, this allows human users who add members to the human and/or machine-readable form. At a minimum, this allows human
collection to understand where to position them in the ordering. users who add members to the collection to understand where to
This property cannot be set using PROPPATCH. Its value can only be position them in the ordering. This property cannot be set using
set by including the Ordering-Type header with a MKCOL request or by PROPPATCH. Its value can only be set by including the Ordering-Type
submitting an ORDERPATCH request. header with a MKCOL request or by submitting an ORDERPATCH request.
Ordering types are identified by URIs that uniquely identify the Ordering types are identified by URIs that uniquely identify the
semantics of the collection's ordering. The following two URIs are semantics of the collection's ordering. The following two URIs are
predefined: predefined:
DAV:custom The value DAV:custom indicates that the collection is DAV:custom: The value DAV:custom indicates that the collection is
ordered, but the semantics governing the ordering are not being ordered, but the semantics governing the ordering are not being
advertised. advertised.
DAV:unordered The value DAV:unordered indicates that the collection DAV:unordered: The value DAV:unordered indicates that the collection
is not ordered. That is, the client cannot depend on the is not ordered. That is, the client cannot depend on the
repeatability of the ordering of results from a PROPFIND request. repeatability of the ordering of results from a PROPFIND request.
An ordering-aware client interacting with an ordering-unaware server An ordering-aware client interacting with an ordering-unaware server
(e.g., one that is implemented only according to [RFC2518]) SHOULD (e.g., one that is implemented only according to [RFC2518]) SHOULD
assume that if a collection does not have the DAV:ordering-type assume that the collection is unordered if a collection does not have
property, the collection is unordered. the DAV:ordering-type property.
<!ELEMENT ordering-type (href) > <!ELEMENT ordering-type (href) >
5. Creating an Ordered Collection 5. Creating an Ordered Collection
5.1 Overview 5.1. Overview
When a collection is created, the client MAY request that it be When a collection is created, the client MAY request that it be
ordered and specify the semantics of the ordering by using the new ordered and specify the semantics of the ordering by using the new
Ordering-Type header (defined below) with a MKCOL request. Ordering-Type header (defined below) with a MKCOL request.
For collections that are ordered, the client SHOULD identify the For collections that are ordered, the client SHOULD identify the
semantics of the ordering with a URI in the Ordering-Type header, semantics of the ordering with a URI in the Ordering-Type header,
although the client MAY simply set the header value to DAV:custom to although the client MAY simply set the header value to DAV:custom to
indicate that the collection is ordered but the semantics of the indicate that the collection is ordered but the semantics of the
ordering are not being advertised. Setting the value to a URI that ordering are not being advertised. Setting the value to a URI that
identifies the ordering semantics provides the information a human identifies the ordering semantics provides the information a human
user or software package needs to insert new collection members into user or software package needs to insert new collection members into
the ordering intelligently. Although the URI in the Ordering-Type the ordering intelligently. Although the URI in the Ordering-Type
header MAY point to a resource that contains a definition of the header MAY point to a resource that contains a definition of the
semantics of the ordering, clients SHOULD NOT access that resource, semantics of the ordering, clients SHOULD NOT access that resource to
in order to avoid overburdening its server. A value of DAV:unordered avoid overburdening its server. A value of DAV:unordered in the
in the Ordering-Type header indicates that the client wants the Ordering-Type header indicates that the client wants the collection
collection to be unordered. If the Ordering-Type header is not to be unordered. If the Ordering-Type header is not present, the
present, the collection will be unordered. collection will be unordered.
Additional Marshalling: Additional Marshalling:
Ordering-Type = "Ordering-Type" ":" absoluteURI Ordering-Type = "Ordering-Type" ":" absoluteURI
; absoluteURI: see RFC2396, section 3 ; absoluteURI: see RFC2396, section 3
The URI "DAV:unordered" indicates that the collection is not The URI "DAV:unordered" indicates that the collection is not
ordered, while "DAV:custom" indicates that the collection is to be ordered, while "DAV:custom" indicates that the collection is to be
ordered, but the semantics of the ordering is not being ordered, but the semantics of the ordering is not being
advertised. Any other URI value indicates that the collection is advertised. Any other URI value indicates that the collection is
ordered, and identifies the semantics of the ordering. ordered, and identifies the semantics of the ordering.
Additional Preconditions: Additional Preconditions:
(DAV:ordered-collections-supported): the server MUST support (DAV:ordered-collections-supported): the server MUST support
ordered collections in the part of the URL namespace identified by ordered collections in the part of the URL namespace identified by
the request URL. the request URL.
Additional Postconditions: Additional Postconditions:
(DAV:ordering-type-set): if the Ordering-Type header was present, (DAV:ordering-type-set): if the Ordering-Type header was present,
the request MUST have created a new collection resource with the the request MUST have created a new collection resource with the
DAV:ordering-type being set according to the Ordering-Type request DAV:ordering-type being set according to the Ordering-Type request
header. The collection MUST be ordered unless the ordering type header. The collection MUST be ordered unless the ordering type
was "DAV:unordered". is "DAV:unordered".
5.2 Example: Creating an Ordered Collection 5.2. Example: Creating an Ordered Collection
>> Request: >> Request:
MKCOL /theNorth/ HTTP/1.1 MKCOL /theNorth/ HTTP/1.1
Host: example.org Host: example.org
Ordering-Type: http://example.org/orderings/compass.html Ordering-Type: http://example.org/orderings/compass.html
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
In this example a new, ordered collection was created. Its In this example, a new ordered collection was created. Its
DAV:ordering-type property has as its value the URI from the DAV:ordering-type property has the URI from the Ordering-Type header
Ordering-Type header, http://example.org/orderings/compass.html. In as its value http://example.org/orderings/compass.html. In this
this case, the URI identifies the semantics governing a case, the URI identifies the semantics governing a client-maintained
client-maintained ordering. As new members are added to the ordering. As new members are added to the collection, clients or end
collection, clients or end users can use the semantics to determine users can use the semantics to determine where to position the new
where to position the new members in the ordering. members in the ordering.
6. Setting the Position of a Collection Member 6. Setting the Position of a Collection Member
6.1 Overview 6.1. Overview
When a new member is added to a collection with a client-maintained When a new member is added to a collection with a client-maintained
ordering (for example, with PUT, COPY, or MKCOL), its position in the ordering (for example, with PUT, COPY, or MKCOL), its position in the
ordering can be set with the new Position header. The Position header ordering can be set with the new Position header. The Position
allows the client to specify that an internal member URI should be header allows the client to specify that an internal member URI
first in the collection's ordering, last in the collection's should be first in the collection's ordering, last in the
ordering, immediately before some other internal member URI in the collection's ordering, immediately before some other internal member
collection's ordering, or immediately after some other internal URI in the collection's ordering, or immediately after some other
member URI in the collection's ordering. internal member URI in the collection's ordering.
If the Position request header is not used when adding a member to an If the Position request header is not used when adding a member to an
ordered collection, then: ordered collection, then:
o If the request is replacing an existing resource, the server MUST o If the request is replacing an existing resource, the server MUST
preserve the present ordering. preserve the present ordering.
o If the request is adding a new internal member URI to the o If the request is adding a new internal member URI to the
collection, the server MUST append the new member to the end of collection, the server MUST append the new member to the end of
the ordering. the ordering.
Note to implementors: this specification does not mandate a Note to implementers: this specification does not mandate a specific
specific implementation of MOVE operations within the same parent implementation of MOVE operations within the same parent collection.
collection. Therefore, servers may either implement this as a Therefore, servers may either implement this as a simple rename
simple rename operation (preserving the collection member's operation (preserving the collection member's position), or as a
position), or as a sequence of "remove" and "add" (causing the sequence of "remove" and "add" (causing the semantics of "adding a
semantics of "adding a new member" to apply). Future revisions of new member" to apply). Future revisions of this specification may
this specification may specify this behaviour more precisely based specify this behaviour more precisely based on future implementation
on future implementation experience. experience.
Additional Marshalling: Additional Marshalling:
Position = "Position" ":" ("first" | "last" | Position = "Position" ":" ("first" | "last" |
(("before" | "after") segment)) (("before" | "after") segment))
segment is defined in Section 3.3 of [RFC2396]. segment is defined in Section 3.3 of [RFC2396].
The segment is interpreted relative to the collection to which the The segment is interpreted relative to the collection to which the
new member is being added. new member is being added.
When the Position header is present, the server MUST insert the When the Position header is present, the server MUST insert the
new member into the ordering at the specified location. new member into the ordering at the specified location.
The "first" keyword indicates the new member is put in the The "first" keyword indicates that the new member is placed in the
beginning position in the collection's ordering, while "last" beginning position in the collection's ordering, while "last"
indicates the new member is put in the final position in the indicates that the new member is placed in the final position in
collection's ordering. The "before" keyword indicates the new the collection's ordering. The "before" keyword indicates that
member is added to the collection's ordering immediately prior to the new member is added to the collection's ordering immediately
the position of the member identified in the segment. Likewise, prior to the position of the member identified in the segment.
the "after" keyword indicates the new member is added to the Likewise, the "after" keyword indicates that the new member is
collection's ordering immediately following the position of the added to the collection's ordering immediately following the
member identified in the segment. position of the member identified in the segment.
If the request is replacing an existing resource, and the Position If the request is replacing an existing resource and the Position
header is present, the server MUST remove the internal member URI header is present, the server MUST remove the internal member URI
from its previous position, and then insert it at the requested from its current position, and insert it at the newly requested
position. position.
Additional Preconditions: Additional Preconditions:
(DAV:collection-must-be-ordered): the target collection MUST be (DAV:collection-must-be-ordered): the target collection MUST be
ordered. ordered.
(DAV:segment-must-identify-member): the referenced segment MUST (DAV:segment-must-identify-member): the referenced segment MUST
identify a resource that exists and is different from the affected identify a resource that exists and is different from the affected
resource. resource.
Additional Postconditions: Additional Postconditions:
(DAV:position-set): if a Position header was present, the request (DAV:position-set): if a Position header is present, the request
MUST have created the new collection member at the specified MUST create the new collection member at the specified position.
position.
6.2 Examples: Setting the Position of a Collection Member 6.2. Examples: Setting the Position of a Collection Member
>> Request: >> Request:
COPY /~user/dav/spec08.html HTTP/1.1 COPY /~user/dav/spec08.html HTTP/1.1
Host: example.org Host: example.org
Destination: http://example.org/~slein/dav/spec08.html Destination: http://example.org/~slein/dav/spec08.html
Position: after requirements.html Position: after requirements.html
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
This request resulted in the creation of a new resource at This request resulted in the creation of a new resource at
example.org/~slein/dav/spec08.html. The Position header in this example.org/~slein/dav/spec08.html. The Position header in this
example caused the server to set its position in the ordering of the example caused the server to set its position in the ordering of the
/~slein/dav/ collection immediately after requirements.html. /~slein/dav/ collection immediately after requirements.html.
>> Request: >> Request:
MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1 MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1
Host: example.org Host: example.org
Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt
Position: first Position: first
>> Response: >> Response:
HTTP/1.1 409 Conflict HTTP/1.1 409 Conflict
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
skipping to change at page 13, line 25 skipping to change at page 10, line 45
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:"> <D:error xmlns:D="DAV:">
<D:collection-must-be-ordered/> <D:collection-must-be-ordered/>
</D:error> </D:error>
In this case, the server returned a 409 (Conflict) status code In this case, the server returned a 409 (Conflict) status code
because the /~user/dav/ collection is an unordered collection. because the /~user/dav/ collection is an unordered collection.
Consequently, the server was unable to satisfy the Position header. Consequently, the server was unable to satisfy the Position header.
6.3 Examples: Renaming a member of an ordered collection 6.3. Examples: Renaming a member of an ordered collection
The following sequence of requests will rename a collection member The following sequence of requests will rename a collection member
while preserving it's position, independantly of how the server while preserving its position, independently of how the server
implements the MOVE operation: implements the MOVE operation:
1. PROPFIND collection with depth 1, retrieving the 1. PROPFIND collection with depth 1, retrieving the DAV:ordering-type
DAV:ordering-type property (an interactive client likely already property (an interactive client has already likely done this in
has done this in order to display the collection's content) order to display the collection's content).
2. If the DAV:ordering-type property is present and doesn't equal 2. If the DAV:ordering-type property is present and does not equal
"dav:unordered" (thus if the collection is ordered), determine "dav:unordered" (thus if the collection is ordered), determine the
current position (such as "first" or "after x") and setup current position (such as "first" or "after x") and setup the
Position header accordingly. Position header accordingly.
3. Perform the MOVE operation, optionally supplying the Position 3. Perform the MOVE operation, optionally supplying the Position
header computed in the previous step. header computed in the previous step.
7. Changing a Collection Ordering: ORDERPATCH method 7. Changing a Collection Ordering: ORDERPATCH method
The ORDERPATCH method is used to change the ordering semantics of a The ORDERPATCH method is used to change the ordering semantics of a
collection or to change the order of the collection's members in the collection, to change the order of the collection's members in the
ordering or both. ordering, or both.
The server MUST apply the changes in the order they appear in the The server MUST apply the changes in the order they appear in the
order XML element. The server MUST either apply all the changes or order XML element. The server MUST either apply all the changes or
apply none of them. If any error occurs during processing, all apply none of them. If any error occurs during processing, all
executed changes MUST be undone and a proper error result returned. executed changes MUST be undone and a proper error result returned.
If an ORDERPATCH request changes the ordering semantics, but does not If an ORDERPATCH request changes the ordering semantics, but does not
completely specify the order of the collection members, the server completely specify the order of the collection members, the server
MUST assign a position in the ordering to each collection member for MUST assign a position in the ordering to each collection member for
which a position was not specified. These server-assigned positions which a position was not specified. These server-assigned positions
MUST all follow the last one specified by the client. The result is MUST follow the last position specified by the client. The result is
that all members for which the client specified a position are at the that all members for which the client specified a position are at the
beginning of the ordering, followed by any members for which the beginning of the ordering, followed by any members for which the
server assigned positions. Note that the ordering of the server assigned positions. Note that the ordering of the server-
server-assigned positions is not defined by this document, therefore assigned positions is not defined by this document, therefore servers
servers can use whatever rule seems reasonable (for instance, can use whatever rule seems reasonable (for instance, alphabetically
alphabetically or by creation date). or by creation date).
If an ORDERPATCH request does not change the ordering semantics, any If an ORDERPATCH request does not change the ordering semantics, any
member positions not specified in the request MUST remain unchanged. member positions not specified in the request MUST remain unchanged.
A request to reposition a collection member at the same place in the A request to reposition a collection member to the same place in the
ordering is not an error. ordering is not an error.
If an ORDERPATCH request fails, the server state preceding the If an ORDERPATCH request fails, the server state preceding the
request MUST be restored. request MUST be restored.
Additional Marshalling: Additional Marshalling:
The request body MUST be DAV:orderpatch element. The request body MUST be DAV:orderpatch element.
<!ELEMENT orderpatch (ordering-type?, order-member*) > <!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 >
<!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]. PCDATA value: segment, as defined in section 3.3 of [RFC2396].
The DAV:ordering-type property is modified according to the The DAV:ordering-type property is modified according to the
DAV:ordering-type element. DAV:ordering-type element.
The ordering of internal member URIs in the collection identified The ordering of internal member URIs in the collection identified
by the Request-URI is changed based on instructions in the by the Request-URI is changed based on instructions in the order-
order-member XML elements in the order they appear in the request. member XML elements. Specifically, in the order that they appear
The order-member XML elements identify the internal member URIs in the request. The order-member XML elements identify the
whose positions are to be changed, and describe their new internal member URIs whose positions are to be changed, and
positions in the ordering. Each new position can be specified as describe their new positions in the ordering. Each new position
first in the ordering, last in the ordering, immediately before can be specified as first in the ordering, last in the ordering,
some other internal member URI, or immediately after some other immediately before some other internal member URI, or immediately
internal member URI. after some other internal member URI.
If a response body for a successful request is included, it MUST If a response body for a successful request is included, it MUST
be a DAV:orderpatch-response XML element. Note that this document be a DAV:orderpatch-response XML element. Note that this document
does not define any elements for the ORDERPATCH response body, but does not define any elements for the ORDERPATCH response body, but
the DAV:orderpatch-response element is defined to ensure the DAV:orderpatch-response element is defined to ensure
interoperability between future extensions that do define elements interoperability between future extensions that do define elements
for the ORDERPATCH response body. for the ORDERPATCH response body.
<!ELEMENT orderpatch-response ANY> <!ELEMENT orderpatch-response ANY>
Since multiple changes can be requested in a single ORDERPATCH Since multiple changes can be requested in a single ORDERPATCH
request, if any problems are encountered, the server MUST return a request, the server MUST return a 207 (Multi-Status) response
207 (Multi-Status) response (defined in [RFC2518]), containing (defined in [RFC2518]), containing DAV:response elements for
DAV:response elements for either the request-URI (when the either the request-URI (when the DAV:ordering-type could not be
DAV:ordering-type could not be modified) or URIs of collection modified) or URIs of collection members to be repositioned (when
members to be repositioned (when an individual positioning request an individual positioning request expressed as DAV:order-member
expressed as DAV:order-member could not be fulfilled). could not be fulfilled) if any problems are encountered.
Preconditions: Preconditions:
(DAV:collection-must-be-ordered): see Section 6.1. (DAV:collection-must-be-ordered): see Section 6.1.
(DAV:segment-must-identify-member): see Section 6.1. (DAV:segment-must-identify-member): see Section 6.1.
Postconditions: Postconditions:
(DAV:ordering-type-set): if the request body contained a (DAV:ordering-type-set): if the request body contained a
DAV:ordering-type element, the request MUST have set the DAV:ordering-type element, the request MUST have set the
DAV:ordering-type property of the collection to the value DAV:ordering-type property of the collection to the value
specified in the request. specified in the request.
(DAV:ordering-modified): if the request body contained (DAV:ordering-modified): if the request body contained DAV:order-
DAV:order-member elements, the request MUST have set the ordering member elements, the request MUST have set the ordering of
of internal member URIs in the collection identified by the internal member URIs in the collection identified by the request-
request-URI based on the instructions in the DAV:order-member URI based upon the instructions in the DAV:order-member elements.
elements.
7.1 Example: Changing a Collection Ordering 7.1. Example: Changing a Collection Ordering
Consider an ordered collection /coll-1, with bindings ordered as Consider an ordered collection /coll-1, with bindings ordered as
follows: follows:
three.html three.html
four.html four.html
one.html one.html
two.html two.html
>> Request: >> Request:
skipping to change at page 17, line 4 skipping to change at page 14, line 17
</d:order-member> </d:order-member>
<d:order-member> <d:order-member>
<d:segment>four.html</d:segment> <d:segment>four.html</d:segment>
<d:position><d:last/></d:position> <d:position><d:last/></d:position>
</d:order-member> </d:order-member>
</d:orderpatch> </d:orderpatch>
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
In this example, after the request has been processed, the In this example, after the request has been processed, the
collection's ordering semantics are identified by the URI http:// collection's ordering semantics are identified by the URI http://
example.org/inorder.ord. The value of the collection's example.org/inorder.ord. The value of the collection's
DAV:ordering-type property has been set to this URI. The request also DAV:ordering-type property has been set to this URI. The request
contains instructions for changing the positions of the collection's also contains instructions for changing the positions of the
internal member URIs in the ordering to comply with the new ordering collection's internal member URIs in the ordering to comply with the
semantics. As the DAV:order-member elements are required to be new ordering semantics. As the DAV:order-member elements are
processed in the order they appear in the request, two.html is moved required to be processed in the order they appear in the request,
to the beginning of the ordering, and then one.html is moved to the two.html is moved to the beginning of the ordering, and then one.html
beginning of the ordering. Then three.html is moved to the end of is moved to the beginning of the ordering. Then three.html is moved
the ordering, and finally four.html is moved to the end of the to the end of the ordering, and finally four.html is moved to the end
ordering. After the request has been processed, the collection's of the ordering. After the request has been processed, the
ordering is as follows: collection's ordering is as follows:
one.html one.html
two.html two.html
three.html three.html
four.html four.html
7.2 Example: Failure of an ORDERPATCH Request 7.2. Example: Failure of an ORDERPATCH Request
Consider a collection /coll-1/ with members ordered as follows: Consider a collection /coll-1/ with members ordered as follows:
nunavut.map nunavut.map
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
nunavut.desc nunavut.desc
skipping to change at page 18, line 35 skipping to change at page 16, line 4
<d:multistatus xmlns:d="DAV:"> <d:multistatus xmlns:d="DAV:">
<d:response> <d:response>
<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href> <d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
<d:status>HTTP/1.1 403 Forbidden</d:status> <d:status>HTTP/1.1 403 Forbidden</d:status>
<d:responsedescription> <d:responsedescription>
<d:error><d:segment-must-identify-member/></d:error> <d:error><d:segment-must-identify-member/></d:error>
pangnirtung.img is not a collection member. pangnirtung.img is not a collection member.
</d:responsedescription> </d:responsedescription>
</d:response> </d:response>
</d:multistatus> </d:multistatus>
In this example, the client attempted to position iqaluit.map after a In this example, the client attempted to position iqaluit.map after a
URI that is not an internal member of the collection /coll-1/. The URI that is not an internal member of the collection /coll-1/. The
server responded to this client error with a 403 (Forbidden) status server responded to this client error with a 403 (Forbidden) status
code, indicating the failed precondition code, indicating the failed precondition DAV:segment-must-identify-
DAV:segment-must-identify-member. Because ORDERPATCH is an atomic member. Because ORDERPATCH is an atomic method, the request to
method, the request to reposition nunavut.desc (which would otherwise reposition nunavut.desc (which would otherwise have succeeded) failed
have succeeded) failed as well, but doesn't need to be expressed in as well, but does not need to be expressed in the multistatus
the multistatus response body. response body.
8. Listing the Members of an Ordered Collection 8. Listing the Members of an Ordered Collection
A PROPFIND request is used to retrieve a listing of the members of an A PROPFIND request is used to retrieve a listing of the members of an
ordered collection, just as it is used to retrieve a listing of the ordered collection, just as it is used to retrieve a listing of the
members of an unordered collection. members of an unordered collection.
However, when responding to a PROPFIND on an ordered collection, the However, when responding to a PROPFIND on an ordered collection, the
server MUST order the response elements according to the ordering server MUST order the response elements according to the ordering
defined on the collection. If a collection is unordered, the client defined on the collection. If a collection is unordered, the client
cannot depend on the repeatability of the ordering of results from a cannot depend on the repeatability of the ordering of results from a
PROPFIND request. PROPFIND request.
In a response to a PROPFIND with Depth: infinity, members of In a response to a PROPFIND with Depth: infinity, members of
different collections may be interleaved. That is, the server is not different collections may be interleaved. That is, the server is not
required to do a breadth-first traversal. The only requirement is required to do a breadth-first traversal. The only requirement is
that the members of any ordered collection appear in the order that the members of any ordered collection appear in the order
defined for the collection. Thus for the hierarchy illustrated in defined for that collection. Thus, for the hierarchy illustrated in
the following figure, where collection A is an ordered collection the following figure, where collection A is an ordered collection
with the ordering B C D, with the ordering B C D,
A A
/|\ /|\
/ | \ / | \
B C D B C D
/ /|\ / /|\
E F G H E F G H
it would be acceptable for the server to return response elements in it would be acceptable for the server to return response elements in
the order A B E C F G H D or "A B E C H G F D" as well (if C is the order A B E C F G H D or "A B E C H G F D" as well (if C is
unordered).. In this response, B, C, and D appear in the correct unordered). In this response, B, C, and D appear in the correct
order, separated by members of other collections. Clients can use a order, separated by members of other collections. Clients can use a
series of Depth: 1 PROPFIND requests to avoid the complexity of series of Depth: 1 PROPFIND requests to avoid the complexity of
processing Depth: infinity responses based on depth-first traversals. processing Depth: infinity responses based on depth-first traversals.
8.1 Example: PROPFIND on an Ordered Collection 8.1. Example: PROPFIND on an Ordered Collection
Suppose a PROPFIND request is submitted to /MyColl/, which has its Suppose a PROPFIND request is submitted to /MyColl/, which has its
members ordered as follows. members ordered as follows.
/MyColl/ /MyColl/
lakehazen.html lakehazen.html
siorapaluk.html siorapaluk.html
iqaluit.html iqaluit.html
newyork.html newyork.html
skipping to change at page 23, line 5 skipping to change at page 19, line 34
</D:prop> </D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
In this example, the server responded with a list of the collection In this example, the server responded with a list of the collection
members in the order defined for the collection. members in the order defined for the collection.
9. Relationship to versioned collections 9. Relationship to versioned collections
The Versioning Extensions to WebDAV [RFC3253] introduce the concept The Versioning Extensions to WebDAV [RFC3253] introduce the concept
of versioned collections, recording both the dead properties and the of versioned collections, recording both the dead properties and the
set of internal version-controlled bindings. This section defines how set of internal version-controlled bindings. This section defines
this feature interacts with ordered collections. how this feature interacts with ordered collections.
This specification considers both the ordering type This specification considers both the ordering type (DAV:ordering-
(DAV:ordering-type property) and the ordering of collection members type property) and the ordering of collection members to be part of
to be part of the state of a collection. Therefore both MUST be the state of a collection. Therefore, both MUST be recorded upon
recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT,
upon CHECKOUT, UNCHECKOUT or UPDATE (where for compatibility with UNCHECKOUT or UPDATE (where for compatibility with RFC 3253, only the
RFC3253, only the ordering of version-controlled members needs to be ordering of version-controlled members needs to be maintained).
maintained).
9.1 Collection Version Properties 9.1. Collection Version Properties
9.1.1 Additional semantics for DAV:version-controlled-binding-set 9.1.1. Additional semantics for DAV:version-controlled-binding-set
(protected) (protected)
For ordered collections, the DAV:version-controlled-binding elements For ordered collections, the DAV:version-controlled-binding elements
MUST appear in the ordering defined for the checked-in ordered MUST appear in the ordering defined for the checked-in ordered
collection. collection.
9.1.2 DAV:ordering-type (protected) 9.1.2. DAV:ordering-type (protected)
The DAV:ordering-type property records the DAV:ordering-type property The DAV:ordering-type property records the DAV:ordering-type property
of the checked-in ordered collection. of the checked-in ordered collection.
9.2 Additional CHECKIN semantics 9.2. Additional CHECKIN semantics
Additional Postconditions: Additional Postconditions:
(DAV:initialize-version-controlled-bindings-ordered): If the (DAV:initialize-version-controlled-bindings-ordered): If the
request-URL identified a both ordered and version-controlled request-URL identified a both ordered and version-controlled
collection, then the child elements of collection, then the child elements of DAV:version-controlled-
DAV:version-controlled-binding-set of the new collection version binding-set of the new collection version MUST appear in the
MUST appear in the ordering defined for that collection. ordering defined for that collection.
(DAV:initialize-collection-version-ordering-type): If the (DAV:initialize-collection-version-ordering-type): If the
request-URL identified a both ordered and version-controlled request-URL identified a both ordered and version-controlled
collection, then the DAV:ordering-type property of the new collection, then the DAV:ordering-type property of the new
collection version MUST be a copy of the collection's collection version MUST be a copy of the collection's
DAV:ordering-type property. DAV:ordering-type property.
9.3 Additional CHECKOUT Semantics 9.3. Additional CHECKOUT Semantics
Additional Postconditions: Additional Postconditions:
(DAV:initialize-version-history-bindings-ordered): If the request (DAV:initialize-version-history-bindings-ordered): If the request
has been applied to a collection version with a DAV:ordering-type has been applied to a collection version with a DAV:ordering-type
other than "DAV:unordered", the bindings in the new working other than "DAV:unordered", the bindings in the new working
collection MUST be ordered according to the collection version's collection MUST be ordered according to the collection version's
DAV:version-controlled-binding-set property. DAV:version-controlled-binding-set property.
(DAV:initialize-ordering-type): If the request has been applied to (DAV:initialize-ordering-type): If the request has been applied to
a collection version, the DAV:ordering-type property of the new a collection version, the DAV:ordering-type property of the new
working collection MUST be initialized from the collection working collection MUST be initialized from the collection
version's DAV:ordering-type property. version's DAV:ordering-type property.
9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics 9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics
Additional Postconditions: Additional Postconditions:
(DAV:update-version-controlled-collection-members-ordered): If the (DAV:update-version-controlled-collection-members-ordered): If the
request modified the DAV:checked-in version of a request modified the DAV:checked-in version of a version-
version-controlled collection and the DAV:ordering-type for the controlled collection and the DAV:ordering-type for the checked-in
checked-in version is not unordered ("DAV:unordered"), the version is not unordered ("DAV:unordered"), the version-controlled
version-controlled members MUST be ordered according to the members MUST be ordered according to the checked-in version's
checked-in version's DAV:version-controlled-binding-set property. DAV:version-controlled-binding-set property. The ordering of
The ordering of non-version-controlled members is server-defined. non-version-controlled members is server-defined.
(DAV:update-version-ordering-type): If the request modified the (DAV:update-version-ordering-type): If the request modified the
DAV:checked-in version of a version-controlled collection, the DAV:checked-in version of a version-controlled collection, the
DAV:ordering-type property MUST be updated from the checked-in DAV:ordering-type property MUST be updated from the checked-in
version's property. version's property.
10. Capability Discovery 10. Capability Discovery
Sections 9.1 and 15 of [RFC2518] describe the use of compliance Sections 9.1 and 15 of [RFC2518] describe the use of compliance
classes with the DAV header in responses to OPTIONS, to indicate classes with the DAV header in responses to OPTIONS, indicating which
which parts of the Web Distributed Authoring protocols the resource parts of the Web Distributed Authoring protocols the resource
supports. This specification defines an OPTIONAL extension to supports. This specification defines an OPTIONAL extension to
[RFC2518]. It defines a new compliance class, called [RFC2518]. It defines a new compliance class, called ordered-
ordered-collections, for use with the DAV header in responses to collections, for use with the DAV header in responses to OPTIONS
OPTIONS requests. If a collection resource does support ordering, requests. If a collection resource does support ordering, its
its response to an OPTIONS request may indicate that it does, by response to an OPTIONS request may indicate that it does, by listing
listing the new ORDERPATCH method as one it supports, and by listing the new ORDERPATCH method as one it supports, and by listing the new
the new ordered-collections compliance class in the DAV header. ordered-collections compliance class in the DAV header.
When responding to an OPTIONS request, only a collection or a null When responding to an OPTIONS request, only a collection or a null
resource can include ordered-collections in the value of the DAV resource can include ordered-collections in the value of the DAV
header. By including ordered-collections, the resource indicates header. By including ordered-collections, the resource indicates
that its internal member URIs can be ordered. It implies nothing that its internal member URIs can be ordered. It implies nothing
about whether any collections identified by its internal member URIs about whether any collections identified by its internal member URIs
can be ordered. can be ordered.
Furthermore, RFC 3253 [RFC3253] introduces the live properties Furthermore, RFC 3253 [RFC3253] introduces the live properties
DAV:supported-method-set (section 3.1.3) and DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
DAV:supported-live-property-set (section 3.1.4). Servers MUST support property-set (section 3.1.4). Servers MUST support these properties
these properties as defined in RFC 3253. as defined in RFC 3253.
10.1 Example: Using OPTIONS for the Discovery of Support for Ordering 10.1. Example: Using OPTIONS for the Discovery of Support for
Ordering
>> Request: >> Request:
OPTIONS /somecollection/ HTTP/1.1 OPTIONS /somecollection/ HTTP/1.1
Host: example.org Host: example.org
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
DAV: 1, 2, ordered-collections DAV: 1, 2, ordered-collections
The DAV header in the response indicates that the resource / The DAV header in the response indicates that the resource
somecollection/ is level 1 and level 2 compliant, as defined in /somecollection/ is level 1 and level 2 compliant, as defined in
[RFC2518]. In addition, /somecollection/ supports ordering. The [RFC2518]. In addition, /somecollection/ supports ordering. The
Allow header indicates that ORDERPATCH requests can be submitted to / Allow header indicates that ORDERPATCH requests can be submitted to
somecollection/. /somecollection/.
10.2 Example: Using Live Properties for the Discovery of Ordering 10.2. Example: Using Live Properties for the Discovery of Ordering
>> Request: >> Request:
PROPFIND /somecollection HTTP/1.1 PROPFIND /somecollection HTTP/1.1
Depth: 0 Depth: 0
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<propfind xmlns="DAV:"> <propfind xmlns="DAV:">
<prop> <prop>
skipping to change at page 28, line 5 skipping to change at page 23, line 36
</supported-method-set> </supported-method-set>
</prop> </prop>
<status>HTTP/1.1 200 OK</status> <status>HTTP/1.1 200 OK</status>
</propstat> </propstat>
</response> </response>
</multistatus> </multistatus>
Note that actual responses MUST contain a complete list of supported Note that actual responses MUST contain a complete list of supported
live properties. live properties.
11. Security Considerations 11. Security Considerations
This section is provided to make WebDAV applications aware of the This section is provided to make WebDAV implementers aware of the
security implications of this protocol. security implications of this protocol.
All of the security considerations of HTTP/1.1 and the WebDAV All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this Distributed Authoring Protocol specification also apply to this
protocol specification. In addition, ordered collections introduce a protocol specification. In addition, ordered collections introduce a
new security concern. This issue is detailed here. new security concern. This issue is detailed here.
11.1 Denial of Service and DAV:ordering-type 11.1. Denial of Service and DAV:ordering-type
There may be some risk of denial of service at sites that are There may be some risk of denial of service at sites that are
advertised in the DAV:ordering-type property of collections. advertised in the DAV:ordering-type property of collections.
However, it is anticipated that widely-deployed applications will use However, it is anticipated that widely-deployed applications will use
hard-coded values for frequently-used ordering semantics rather than hard-coded values for frequently-used ordering semantics rather than
looking up the semantics at the location specified by looking up the semantics at the location specified by DAV:ordering-
DAV:ordering-type. This risk will be further reduced if clients type. This risk will be further reduced if clients observe the
observe the recommendation of Section 5.1 that they not send requests recommendation of Section 5.1 that requests not be sent to the URI in
to the URI in DAV:ordering-type. DAV:ordering-type.
12. Internationalization Considerations 12. Internationalization Considerations
This specification follows the practices of [RFC2518] in encoding all This specification follows the practices of [RFC2518] by encoding all
human-readable content using [XML] and in the treatment of names. human-readable content using [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set Consequently, this specification complies with the IETF Character Set
Policy [RFC2277]. Policy [RFC2277].
WebDAV applications MUST support the character set tagging, character WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML set encoding, and the language tagging functionality of the XML
specification. This constraint ensures that the human-readable specification. This constraint ensures that the human-readable
content of this specification complies with [RFC2277]. content of this specification complies with [RFC2277].
As in [RFC2518], names in this specification fall into three As in [RFC2518], names in this specification fall into three
categories: names of protocol elements such as methods and headers, categories: names of protocol elements such as methods and headers,
names of XML elements, and names of properties. Naming of protocol names of XML elements, and names of properties. The naming of
elements follows the precedent of HTTP, using English names encoded protocol elements follows the precedent of HTTP using English names
in USASCII for methods and headers. The names of XML elements used encoded in USASCII for methods and headers. The names of XML
in this specification are English names encoded in UTF-8. elements used in this specification are English names encoded in
UTF-8.
For error reporting, [RFC2518] follows the convention of HTTP/1.1 For error reporting, [RFC2518] follows the convention of HTTP/1.1
status codes, including with each status code a short, English status codes, including with each status code a short, English
description of the code (e.g., 423 Locked). Internationalized description of the code (e.g., 423 Locked). Internationalized
applications will ignore this message, and display an appropriate applications will ignore this message, and display an appropriate
message in the user's language and character set. message in the user's language and character set.
This specification introduces no new strings that are displayed to This specification introduces no new strings that are displayed to
users as part of normal, error-free operation of the protocol. users as part of normal, error-free operation of the protocol.
For rationales for these decisions and advice for application For the rationale of these decisions and advice for application
implementors, see [RFC2518]. implementers, see [RFC2518].
13. IANA Considerations 13. IANA Considerations
This document uses the namespaces defined by [RFC2518] for properties This document uses the namespaces defined by [RFC2518] for properties
and XML elements. All other IANA considerations mentioned in and XML elements. All other IANA considerations mentioned in
[RFC2518] also apply to this document. [RFC2518] also apply to this document.
14. Contributors 14. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in 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 made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification 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. Please address the information to the IETF Executive
Director.
15. Contributors
This document has benefited from significant contributions from Geoff This document has benefited from significant contributions from Geoff
Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein. Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein.
15. Acknowledgements 16. Acknowledgements
This document has benefited from thoughtful discussion by Jim Amsden, This document has benefited from thoughtful discussion by Jim Amsden,
Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun,
Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa
Dusseault, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, Dusseault, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann,
Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,
John Stracke, John Tigue, John Turner, Kevin Wiggen, and others. John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
Normative References 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", RFC 3253,
March 2002.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Requirement Levels", BCP 14, RFC 2119, March 1997.
REC-xml, October 2000, <http://www.w3.org/TR/2000/
REC-xml-20001006>.
[1] <mailto:w3c-dist-auth@w3.org> [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[2] <mailto:w3c-dist-auth-request@w3.org?subject=subscribe> [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
Authors' Addresses [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999.
Jim Whitehead [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
UC Santa Cruz, Dept. of Computer Science L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
1156 High Street Protocol -- HTTP/1.1", RFC 2616, June 1999.
Santa Cruz, CA 95064
US
EMail: ejw@cse.ucsc.edu [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
Julian F. Reschke (editor) Whitehead, "Versioning Extensions to WebDAV (Web
greenbytes GmbH Distributed Authoring and Versioning)", RFC 3253, March
Salzmannstrasse 152 2002.
Muenster, NW 48159
Germany
Phone: +49 251 2807760 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
Fax: +49 251 2807761 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
EMail: julian.reschke@greenbytes.de xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-
URI: http://greenbytes.de/tech/webdav/ 20001006>.
Appendix A. Extensions to the WebDAV Document Type Definition Appendix A. Extensions to the WebDAV Document Type Definition
<!ELEMENT orderpatch (ordering-type?, order-member*) > <!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT order-member (segment, position) > <!ELEMENT order-member (segment, position) >
<!ELEMENT ordering-type (href) > <!ELEMENT ordering-type (href) >
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
<!ELEMENT before segment > <!ELEMENT before segment >
<!ELEMENT after segment > <!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
Index Index
C C
Client-Maintained Ordering 6 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 D
DAV:collection-must-be-ordered precondition 12 DAV header
DAV:custom ordering type 8 compliance class 'ordered-collections' 21
DAV:initialize-collection-version-ordering-type 23 DAV:collection-must-be-ordered precondition 9
DAV:initialize-ordering-type 24 DAV:custom ordering type 6
DAV:initialize-version-controlled-bindings-ordered postcondition 23 DAV:initialize-collection-version-ordering-type postcondition 20
DAV:initialize-version-history-bindings-ordered 24 DAV:initialize-ordering-type postcondition 21
DAV:ordered-collections-supported precondition 9 DAV:initialize-version-controlled-bindings-ordered
DAV:ordering-modified postcondition 15 postcondition 20
DAV:ordering-type property 7 DAV:initialize-version-history-bindings-ordered postcondition 20
DAV:ordering-type-set postcondition 9, 15 DAV:ordered-collections-supported precondition 7
DAV:position-set postcondition 12 DAV:ordering-modified postcondition 13
DAV:segment-must-identify-member precondition 12 DAV:ordering-type property 6
DAV:unordered ordering type 8 DAV:ordering-type-set postcondition 7, 13
DAV:update-version-controlled-collection-members-ordered 24 DAV:position-set postcondition 9
DAV:update-version-ordering-type 24 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 H
Headers Headers
Ordering-Type 9 Ordering-Type 7
Position 9
O M
Ordered Collection 6 Methods
Ordering Semantics 6 ORDERPATCH 11
Ordering-Type header 9
ORDERPATCH method 14
P O
Postconditions Ordered Collection 4
DAV:initialize-collection-version-ordering-type 23 Ordering Semantics 5
DAV:initialize-ordering-type 24 Ordering-Type header 7
DAV:initialize-version-controlled-bindings-ordered 23 ORDERPATCH method 11
DAV:initialize-version-history-bindings-ordered 24
DAV:ordering-modified 15
DAV:ordering-type-set 9, 15
DAV:position-set 12
DAV:update-version-controlled-collection-members-ordered 24
DAV:update-version-ordering-type 24
Preconditions
DAV:collection-must-be-ordered 12
DAV:ordered-collections-supported 9
DAV:segment-must-identify-member 12
Protected properties
DAV:ordering-type 7
S P
Server-Maintained Ordering 6 Position header 9
Properties
DAV:ordering-type 6
U S
Unordered Collection 6 Server-Maintained Ordering 5
Intellectual Property Statement U
Unordered Collection 4
The IETF takes no position regarding the validity or scope of any Authors' Addresses
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in 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 made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any Jim Whitehead
copyrights, patents or patent applications, or other proprietary UC Santa Cruz, Dept. of Computer Science
rights which may cover technology that may be required to practice 1156 High Street
this standard. Please address the information to the IETF Executive Santa Cruz, CA 95064
Director. 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/
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 142 change blocks. 
472 lines changed or deleted 460 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/