draft-ietf-webdav-ordering-protocol-07.txt   draft-ietf-webdav-ordering-protocol-08.txt 
Network Working Group J. Slein WEBDAV Working Group J. Whitehead
Internet Draft Xerox Internet-Draft U.C. Santa Cruz
Expires: September 2003 J. Whitehead Expires: November 10, 2003 J. Reschke, Ed.
U.C. Santa Cruz
J. Crawford
IBM
J. F. Reschke
greenbytes greenbytes
March 2003 May 12, 2003
WebDAV Ordered Collections Protocol WebDAV Ordered Collections Protocol
draft-ietf-webdav-ordering-protocol-07 draft-ietf-webdav-ordering-protocol-08
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026.
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute Internet-Drafts are working documents of the Internet Engineering
working documents as Internet-Drafts. Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in September 2003. This Internet-Draft will expire on November 10, 2003.
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 WebDAV Distributed Authoring Protocol
to support server-side ordering of collection members. Of particular to support server-side ordering of collection members. Of particular
interest are orderings that are not based on property values, and so interest are orderings that are not based on property values, and so
cannot be achieved using a search protocol's ordering option and cannot be achieved using a search protocol's ordering option and
cannot be maintained automatically by the server. Protocol elements cannot be maintained automatically by the server. Protocol elements
are defined to let clients specify the position in the ordering of are defined to let clients specify the position in the ordering of
each collection member, as well as the semantics governing the each collection member, as well as the semantics governing the
ordering. ordering.
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org, which may be joined by sending a message with w3c-dist-auth@w3.org [1], which may be joined by sending a message
subject "subscribe" to w3c-dist-auth-request@w3.org. with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL: Discussions of the WEBDAV working group are archived at URL: http://
http://lists.w3.org/Archives/Public/w3c-dist-auth/. lists.w3.org/Archives/Public/w3c-dist-auth/.
Table of Contents Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
Table of Contents . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Notational Conventions . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Ordered Collections . . . . . . . . . . . . . . 7
3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Additional Collection properties . . . . . . . . . . . . . . 7
4 Overview of Ordered Collections . . . . . . . . . . . . . . 8 4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 7
4.1 Additional Collection properties . . . . . . . . . . . . 8 5. Creating an Ordered Collection . . . . . . . . . . . . . . . 9
4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . 9 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5 Creating an Ordered Collection . . . . . . . . . . . . . . . 10 5.2 Example: Creating an Ordered Collection . . . . . . . . . . 10
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Setting the Position of a Collection Member . . . . . . . . 11
5.2 Example: Creating an Ordered Collection . . . . . . . . 11 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Setting the Position of a Collection Member . . . . . . . . 12 6.2 Examples: Setting the Position of a Collection Member . . . 12
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Changing a Collection Ordering: ORDERPATCH method . . . . . 14
6.2 Examples: Setting the Position of a Collection Member . 13 7.1 Example: Changing a Collection Ordering . . . . . . . . . . 16
7 Changing a Collection Ordering: ORDERPATCH method . . . . . 15 7.2 Example: Failure of an ORDERPATCH Request . . . . . . . . . 17
7.1 Example: Changing a Collection Ordering . . . . . . . . 17 8. Listing the Members of an Ordered Collection . . . . . . . . 19
7.2 Example: Failure of an ORDERPATCH Request . . . . . . . 18 8.1 Example: PROPFIND on an Ordered Collection . . . . . . . . . 19
8 Listing the Members of an Ordered Collection . . . . . . . . 21 9. Relationship to versioned collections . . . . . . . . . . . 23
8.1 Example: PROPFIND on an Ordered Collection . . . . . . . 21 9.1 Collection Version Properties . . . . . . . . . . . . . . . 23
9 Relationship to versioned collections . . . . . . . . . . . 25 9.1.1 Additional semantics for
9.1 Collection Version Properties . . . . . . . . . . . . . 25 DAV:version-controlled-binding-set (protected) . . . . . . . 23
9.1.1 Additional semantics for DAV:version-controlled- 9.1.2 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 23
binding-set (protected) . . . . . . . . . . . . . . . . . . . 25 9.2 Additional CHECKIN semantics . . . . . . . . . . . . . . . . 23
9.1.2 DAV:ordering-type (protected) . . . . . . . . . . . 25 9.3 Additional CHECKOUT Semantics . . . . . . . . . . . . . . . 24
9.2 Additional CHECKIN semantics . . . . . . . . . . . . . . 25 9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . . . 24
9.3 Additional CHECKOUT Semantics . . . . . . . . . . . . . 26 10. Capability Discovery . . . . . . . . . . . . . . . . . . . . 25
9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . 26
10 Capability Discovery . . . . . . . . . . . . . . . . . . . 27
10.1 Example: Using OPTIONS for the Discovery of Support for 10.1 Example: Using OPTIONS for the Discovery of Support for
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2 Example: Using Live Properties for the Discovery of 10.2 Example: Using Live Properties for the Discovery of
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11 Security Considerations . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . 28
11.1 Denial of Service and DAV:ordering-type . . . . . . . . 30 11.1 Denial of Service and DAV:ordering-type . . . . . . . . . . 28
12 Internationalization Considerations . . . . . . . . . . . . 31 12. Internationalization Considerations . . . . . . . . . . . . 29
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
14 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 31
15 Intellectual Property . . . . . . . . . . . . . . . . . . . 34 15. Intellectual Property . . . . . . . . . . . . . . . . . . . 32
16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 35 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
Normative References . . . . . . . . . . . . . . . . . . . . . 36 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . . 35
A Extensions to the WebDAV Document Type Definition . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 A. Extensions to the WebDAV Document Type Definition . . . . . 37
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.1 Since draft-ietf-webdav-ordering-protocol dated December B.1 Since draft-ietf-webdav-ordering-protocol dated December
1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . 39 B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . . . 38
B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . 39 B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . . . 38
B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . 40 B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . . . 38
B.5 Since draft-ietf-webdav-ordering-protocol-05 . . . . . . 40 B.5 Since draft-ietf-webdav-ordering-protocol-05 . . . . . . . . 39
B.6 Since draft-ietf-webdav-ordering-protocol-06 . . . . . . 40 B.6 Since draft-ietf-webdav-ordering-protocol-06 . . . . . . . . 39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.7 Since draft-ietf-webdav-ordering-protocol-07 . . . . . . . . 39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . 42
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], itself an extension to the
HTTP/1.1 protocol, the augmented BNF used here to describe protocol HTTP/1.1 protocol, the augmented BNF used here to describe protocol
elements is exactly the same as described in Section 2.1 of HTTP elements is exactly the same as described in Section 2.1 of HTTP
[RFC2616]. Since this augmented BNF uses the basic production rules [RFC2616]. Since this augmented BNF uses the basic production rules
provided in Section 2.2 of HTTP, these rules apply to this document provided in Section 2.2 of HTTP, these rules apply to this document
as well. as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line ? skipping to change at page 4, line 34
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 when 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 stated this element) may be added anywhere, except when explicitly
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 where it is useful to impose an ordering on
a collection at the server, such as expressing a recommended access a collection at the server, such as expressing a recommended access
order, or a revision history order. The members of a collection might order, or a revision history order. The members of a collection
represent the pages of a book, which need to be presented in order if might represent the pages of a book, which need to be presented in
they are to make sense. Or an instructor might create a collection of order if they are to make sense. Or an instructor might create a
course readings, which she wants to be displayed in the order they collection of course readings, which she wants to be displayed in the
are to be read. 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 human- The ordering protocol defined here focuses on support for such
maintained orderings. Its protocol elements allow clients to specify human-maintained orderings. Its protocol elements allow clients to
the position of each collection member in the collection's ordering, specify the position of each collection member in the collection's
as well as the semantics governing the ordering. The protocol is ordering, as well as the semantics governing the ordering. The
designed to allow support to be added in the future for orderings protocol is designed to allow support to be added in the future for
that are maintained automatically by the server. orderings 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, Section 11 through Section 13 discuss security, internationalization,
and IANA considerations. The remaining sections provide supporting and 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
skipping to change at page 8, line 5 skipping to change at page 7, line 5
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
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 unordered, 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) or later is added to the collection (using the Position header (Section 6)) or
(using the ORDERPATCH method). For server-maintained orderings, the later (using the ORDERPATCH (Section 7) method). For
server automatically positions each of the collection's members server-maintained orderings, the server automatically positions each
according to the ordering semantics. This specification supports only of the collection's members according to the ordering semantics.
client-maintained orderings, but is designed to allow future This specification supports only client-maintained orderings, but is
extension to server-maintained orderings. designed to allow future extension to 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 be
in the ordering exactly once, and the ordering MUST NOT include any in the ordering exactly once, and the ordering MUST NOT include any
URI that is not an internal member of the collection. The server is URI that is not an internal member of the collection. The server is
responsible for enforcing these constraints on orderings. The server responsible for enforcing these constraints on orderings. The server
MUST remove an internal member URI from the ordering when it is MUST remove an internal member URI from the ordering when it is
removed from the collection. The server MUST add an internal member removed from the collection. Removing an internal member MUST NOT
URI to the ordering when it is added to the collection. affect the ordering of the remaining internal members. The server
MUST add an internal member URI to the 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.
skipping to change at page 9, line 11 skipping to change at page 8, line 7
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 Indicates whether the collection is ordered and, if so, uniquely
identifies the semantics of the ordering being used. May also point identifies the semantics of the ordering being used. May also point
to an explanation of the semantics in human and / or machine-readable to an explanation of the semantics in human and / or machine-readable
form. At a minimum, this allows human users who add members to the form. At a minimum, this allows human users who add members to the
collection to understand where to position them in the ordering. This collection to understand where to position them in the ordering.
property cannot be set using PROPPATCH. Its value can only be set by This property cannot be set using PROPPATCH. Its value can only be
including the Ordering-Type header with a MKCOL request or by set by including the Ordering-Type header with a MKCOL request or by
submitting an ORDERPATCH request. 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 ordered, but the semantics governing the ordering are not being
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 is not ordered. That is, the client cannot depend on the
the repeatability of the ordering of results from a repeatability of the ordering of results from a PROPFIND request.
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 if a collection does not have the DAV:ordering-type
property, the collection is unordered. property, the collection is unordered.
<!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
skipping to change at page 11, line 28 skipping to change at page 10, line 20
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 as its value the URI from the
Ordering-Type header, http://example.org/orderings/compass.html. In Ordering-Type header, http://example.org/orderings/compass.html. In
this case, the URI identifies the semantics governing a client- this case, the URI identifies the semantics governing a
maintained ordering. As new members are added to the collection, client-maintained ordering. As new members are added to the
clients or end users can use the semantics to determine where to collection, clients or end users can use the semantics to determine
position the new members in the ordering. where to position the new 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 header
allows the client to specify that an internal member URI should be allows the client to specify that an internal member URI should be
first in the collection's ordering, last in the collection's first in the collection's ordering, last in the collection's
ordering, immediately before some other internal member URI in the ordering, immediately before some other internal member URI in the
collection's ordering, or immediately after some other internal collection's ordering, or immediately after some other internal
skipping to change at page 12, line 28 skipping to change at page 11, line 28
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
specific implementation of MOVE operations within the same parent
collection. Therefore, servers may either implement this as a
simple rename operation (preserving the collection member's
position), or as a sequence of "remove" and "add" (causing the
semantics of "adding a new member" to apply). Future revisions of
this specification may specify this behaviour more precisely based
on future implementation 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.
skipping to change at page 15, line 5 skipping to change at page 14, line 5
<?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.
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 or 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.
skipping to change at page 16, line 4 skipping to change at page 14, line 47
<!ELEMENT orderpatch (ordering-type?, order-member*) > <!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT order-member (segment, position) > <!ELEMENT order-member (segment, position) >
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
<!ELEMENT before segment > <!ELEMENT before segment >
<!ELEMENT after 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 order- by the Request-URI is changed based on instructions in the
member XML elements in the order they appear in the request. The order-member XML elements in the order they appear in the request.
order-member XML elements identify the internal member URIs whose The order-member XML elements identify the internal member URIs
positions are to be changed, and describe their new positions in whose positions are to be changed, and describe their new
the ordering. Each new position can be specified as first in the positions in the ordering. Each new position can be specified as
ordering, last in the ordering, immediately before some other first in the ordering, last in the ordering, immediately before
internal member URI, or immediately after some other internal some other internal member URI, or immediately after some other
member URI. 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, if any problems are encountered, the server MUST return a
207 (Multi-Status) response (defined in [RFC2518]), containing 207 (Multi-Status) response (defined in [RFC2518]), containing
DAV:response elements for either the request-URI (when the DAV:response elements for either the request-URI (when the
DAV:ordering-type could not be modified) or URIs of collection DAV:ordering-type could not be modified) or URIs of collection
members to be repositioned (when an individual positioning request members to be repositioned (when an individual positioning request
expressed as DAV:order-member could not be fulfilled). expressed as DAV:order-member could not be fulfilled).
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:order- (DAV:ordering-modified): if the request body contained
member elements, the request MUST have set the ordering of DAV:order-member elements, the request MUST have set the ordering
internal member URIs in the collection identified by the request- of internal member URIs in the collection identified by the
URI based on the instructions in the DAV:order-member elements. request-URI based on the instructions in the DAV:order-member
elements.
7.1 Example: Changing a Collection Ordering 7.1 Example: Changing a Collection Ordering
Consider a collection /coll-1/ whose DAV:ordering-type is DAV:whim, Consider a collection /coll-1/ whose DAV:ordering-type is DAV:whim,
with bindings ordered as follows: with bindings ordered as follows:
three.html three.html
four.html four.html
one.html one.html
two.html two.html
skipping to change at page 18, line 19 skipping to change at page 16, line 50
<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 collection's ordering semantics are identified by the URI http://
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 also
contains instructions for changing the positions of the collection's contains instructions for changing the positions of the collection's
internal member URIs in the ordering to comply with the new ordering internal member URIs in the ordering to comply with the new ordering
semantics. As the DAV:order-member elements are required to be semantics. As the DAV:order-member elements are required to be
processed in the order they appear in the request, two.html is moved processed in the order they appear in the request, two.html is moved
to the beginning of the ordering, and then one.html is moved to the to the beginning of the ordering, and then one.html is moved to the
beginning of the ordering. Then three.html is moved to the end of the beginning of the ordering. Then three.html is moved to the end of
ordering, and finally four.html is moved to the end of the ordering. the ordering, and finally four.html is moved to the end of the
After the request has been processed, the collection's ordering is as ordering. After the request has been processed, the collection's
follows: 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:
skipping to change at page 20, line 19 skipping to change at page 18, line 34
<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 DAV:segment-must-identify- code, indicating the failed precondition
member. Because ORDERPATCH is an atomic method, the request to DAV:segment-must-identify-member. Because ORDERPATCH is an atomic
reposition nunavut.desc (which would otherwise have succeeded) failed method, the request to reposition nunavut.desc (which would otherwise
as well, but doesn't need to be expressed in the multistatus response have succeeded) failed as well, but doesn't need to be expressed in
body. the multistatus 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 the defined for the collection. Thus for the hierarchy illustrated in
following figure, where collection A is an ordered collection with the following figure, where collection A is an ordered collection
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. In this response, B, C, and D appear in the order A B E C F G H D. In this response, B, C, and D appear in
the correct order, separated by members of other collections. Clients the correct order, separated by members of other collections.
can use a series of Depth: 1 PROPFIND requests to avoid the Clients can use a series of Depth: 1 PROPFIND requests to avoid the
complexity of processing Depth: infinity responses based on depth- complexity of processing Depth: infinity responses based on
first traversals. 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
skipping to change at page 25, line 5 skipping to change at page 23, line 5
</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 how
this feature interacts with ordered collections. this feature interacts with ordered collections.
This specification considers both the ordering type (DAV:ordering- This specification considers both the ordering type
type property) and the ordering of collection members to be part of (DAV:ordering-type property) and the ordering of collection members
the state of a collection. Therefore both MUST be recorded upon to be part of the state of a collection. Therefore both MUST be
CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored
UNCHECKOUT or UPDATE (where for compatibility with RFC3253, only the upon CHECKOUT, UNCHECKOUT or UPDATE (where for compatibility with
ordering of version-controlled members needs to be maintained). RFC3253, only the ordering of version-controlled members needs to be
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.
skipping to change at page 25, line 39 skipping to change at page 23, line 40
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 DAV:version-controlled- collection, then the child elements of
binding-set of the new collection version MUST appear in the DAV:version-controlled-binding-set of the new collection version
ordering defined for that collection. MUST appear in the ordering defined for that collection.
(DAV:initialize-collection-version-ordering-type): If the request- (DAV:initialize-collection-version-ordering-type): If the
URL identified a both ordered and version-controlled collection, request-URL identified a both ordered and version-controlled
then the DAV:ordering-type property of the new collection version collection, then the DAV:ordering-type property of the new
MUST be a copy of the collection's DAV:ordering-type property. collection version MUST be a copy of the collection's
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.
skipping to change at page 26, line 25 skipping to change at page 24, line 25
(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 version- request modified the DAV:checked-in version of a
controlled collection and the DAV:ordering-type for the checked-in version-controlled collection and the DAV:ordering-type for the
version is not unordered ("DAV:unordered"), the version-controlled checked-in version is not unordered ("DAV:unordered"), the
members MUST be ordered according to the checked-in version's version-controlled members MUST be ordered according to the
DAV:version-controlled-binding-set property. checked-in version's DAV:version-controlled-binding-set property.
The ordering of non-version-controlled members is server-defined."
(DAV:update-version-ordering-type): If the request modified the (DAV: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, to indicate
which parts of the Web Distributed Authoring protocols the resource which 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 ordered- [RFC2518]. It defines a new compliance class, called
collections, for use with the DAV header in responses to OPTIONS ordered-collections, for use with the DAV header in responses to
requests. If a collection resource does support ordering, its OPTIONS requests. If a collection resource does support ordering,
response to an OPTIONS request may indicate that it does, by listing its response to an OPTIONS request may indicate that it does, by
the new ORDERPATCH method as one it supports, and by listing the new listing the new ORDERPATCH method as one it supports, and by listing
ordered-collections compliance class in the DAV header. the new 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 that header. By including ordered-collections, the resource indicates
its internal member URIs can be ordered. It implies nothing about that its internal member URIs can be ordered. It implies nothing
whether any collections identified by its internal member URIs can be about whether any collections identified by its internal member URIs
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-live- DAV:supported-method-set (section 3.1.3) and
property-set (section 3.1.4). Servers MUST support these properties DAV:supported-live-property-set (section 3.1.4). Servers MUST support
as defined in RFC 3253. these properties 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 Allow [RFC2518]. In addition, /somecollection/ supports ordering. The
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>
<supported-live-property-set/> <supported-live-property-set/>
<supported-method-set/> <supported-method-set/>
skipping to change at page 30, line 5 skipping to change at page 28, line 5
</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 applications 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. However, advertised in the DAV:ordering-type property of collections.
it is anticipated that widely-deployed applications will use hard- However, it is anticipated that widely-deployed applications will use
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 DAV:ordering- looking up the semantics at the location specified by
type. This risk will be further reduced if clients observe the DAV:ordering-type. This risk will be further reduced if clients
recommendation of section 5.1 that they not send requests to the URI observe the recommendation of Section 5.1 that they not send requests
in DAV:ordering-type. to the URI in 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] in 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. Naming of protocol
elements follows the precedent of HTTP, using English names encoded elements follows the precedent of HTTP, using English names encoded
in USASCII for methods and headers. The names of XML elements used in in USASCII for methods and headers. The names of XML elements used
this specification are English names encoded in UTF-8. 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 rationales for these decisions and advice for application
implementors, see [RFC2518]. implementors, 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 Copyright 14. Copyright
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
15 Intellectual Property 15. Intellectual Property
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
16 Acknowledgements 16. Contributors
This draft has benefited from thoughtful discussion by Jim Amsden, This document has benefited from significant contributions from Geoff
Steve Carter, Tyson Chihaya, Geoff Clemm, Ken Coar, Ellis Cohen, Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein.
Bruce Cragun, Jim Davis, Spencer Dawkins, Mark Day, Rajiv Dulepet,
David Durand, Lisa Dusseault, Chuck Fay, Roy Fielding, Yaron Goland, 17. Acknowledgements
Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj
Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry This document has benefited from thoughtful discussion by Jim Amsden,
Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun,
Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa
Turner, Kevin Wiggen, and others. Dusseault, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann,
Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,
John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
Normative References Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R.T. and Masinter, L., "Uniform [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S.R. and [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, D., "HTTP Extensions for Distributed Authoring -- Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999. WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and Berners-Lee, T., "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
Whitehead, J., "Versioning Extensions to WebDAV", RFC Whitehead, "Versioning Extensions to WebDAV", RFC 3253,
3253, March 2002. March 2002.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and Maler, E., [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
xml, October 2000. REC-xml, October 2000, <http://www.w3.org/TR/2000/
REC-xml-20001006>.
Author's Addresses [1] <mailto:w3c-dist-auth@w3.org>
Judith Slein [2] <mailto:w3c-dist-auth-request@w3.org?subject=subscribe>
Xerox Corporation
800 Phillips Road, 105-50C
Webster, NY 14580
EMail: jslein@crt.xerox.com Authors' Addresses
Jim Whitehead Jim Whitehead
UC Santa Cruz, Dept. of Computer Science UC Santa Cruz, Dept. of Computer Science
1156 High Street 1156 High Street
Santa Cruz, CA 95064 Santa Cruz, CA 95064
US US
EMail: ejw@cse.ucsc.edu EMail: ejw@cse.ucsc.edu
Jason Crawford Julian F. Reschke (editor)
IBM Research
P.O. Box 704
Yorktown Heights, NY 10598
EMail: ccjason@us.ibm.com
Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Salzmannstrasse 152 Salzmannstrasse 152
Muenster, NW 48159 Muenster, NW 48159
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
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)>
B Change Log Appendix B. Change Log
B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999 B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999
Updated contact information for all previous authors. Updated contact information for all previous authors.
Specify charset when using text/xml media type. Specify charset when using text/xml media type.
Made sure artwork fits into 72 columns. Made sure artwork fits into 72 columns.
Removed "Public" header from OPTIONS example. Removed "Public" header from OPTIONS example.
Added Julian Reschke to list of authors. Added Julian Reschke to list of authors.
Fixed broken XML in PROPFIND example and added DAV:orderingtype to Fixed broken XML in PROPFIND example and added DAV:orderingtype to
list of requested properties. list of requested properties.
Added support for DAV:supported-live-property-set and DAV:supported- Added support for DAV:supported-live-property-set and
method-set as mandatory features. DAV:supported-method-set as mandatory features.
B.2 Since draft-ietf-webdav-ordering-protocol-02 B.2 Since draft-ietf-webdav-ordering-protocol-02
Updated change log to refer to expired draft version as "December Updated change log to refer to expired draft version as "December
1999" version. 1999" version.
Started rewrite marshalling in RFC3253-style and added precondition Started rewrite marshalling in RFC3253-style and added precondition
and postcondition definitions. and postcondition definitions.
On his request, removed Geoff Clemm's name from the author list On his request, removed Geoff Clemm's name from the author list
(moved to Acknowledgments). (moved to Acknowledgments).
Renamed "References" to "Normative References". Renamed "References" to "Normative References".
skipping to change at page 40, line 8 skipping to change at page 39, line 4
Removed header and XML elements section (contents moved to other Removed header and XML elements section (contents moved to other
sections). sections).
Started new section on relation to versioned collections as per Started new section on relation to versioned collections as per
RFC3253. RFC3253.
Do not return 424's for in ORDERPATCH multistatus (it's atomic Do not return 424's for in ORDERPATCH multistatus (it's atomic
anyway). anyway).
B.4 Since draft-ietf-webdav-ordering-protocol-04 B.4 Since draft-ietf-webdav-ordering-protocol-04
Added proper reference to definition of "Coded-URL". Added proper reference to definition of "Coded-URL".
Closed issue ordering-type-values (content model simplified and XML Closed issue ordering-type-values (content model simplified and XML
element / DAV property renamed) and updated examples. element / DAV property renamed) and updated examples.
Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set
(no change tracking). (no change tracking).
Closed issue ordered-header-name (header name changed to "ordering- Closed issue ordered-header-name (header name changed to
type", contents matches live property). "ordering-type", contents matches live property).
Closed issue ordermember-format (now takes segment instead of href). Closed issue ordermember-format (now takes segment instead of href).
Renamed compliance class to "ordered-collections" for consistency Renamed compliance class to "ordered-collections" for consistency
with newer specs, and to allow detection of compliance to final with newer specs, and to allow detection of compliance to final
version of spec. version of spec.
Updated reference to XML spec to 1.0, 2nd edition. Updated reference to XML spec to 1.0, 2nd edition.
B.5 Since draft-ietf-webdav-ordering-protocol-05 B.5 Since draft-ietf-webdav-ordering-protocol-05
Typos fixed. Typos fixed.
Renamed DAV:ordermember to DAV:order-member. Renamed DAV:ordermember to DAV:order-member.
skipping to change at page 41, line 5 skipping to change at page 39, line 32
requirement. requirement.
Reference definition of "protected property" from RFC3253. Reference definition of "protected property" from RFC3253.
Added explanation of role of DTD fragments to Notation section. Added explanation of role of DTD fragments to Notation section.
Clarified semantics for operations on versioned collections and Clarified semantics for operations on versioned collections and
collection versions. collection versions.
B.6 Since draft-ietf-webdav-ordering-protocol-06 B.6 Since draft-ietf-webdav-ordering-protocol-06
Added atomicity statement for ORDERPATCH method. Added atomicity statement for ORDERPATCH method.
B.7 Since draft-ietf-webdav-ordering-protocol-07
Added issues "4.1-DELETE-behaviour", "6.1-safe-update",
"6.1-when-are-members-added" and
"9.4-UPDATE-non-version-controlled-members" and resolved them. Added
new "contributors" section, and mention original authors such as
Judith Slein there.
Index Index
C C
Client-Maintained Ordering 6
Client-Maintained Ordering
3
D D
DAV:collection-must-be-ordered precondition 12
DAV:custom ordering type 8
DAV:initialize-collection-version-ordering-type 23
DAV:initialize-ordering-type 24
DAV:initialize-version-controlled-bindings-ordered postcondition 23
DAV:initialize-version-history-bindings-ordered 24
DAV:ordered-collections-supported precondition 9
DAV:ordering-modified postcondition 15
DAV:ordering-type property 7
DAV:ordering-type-set postcondition 9, 15
DAV:position-set postcondition 12
DAV:segment-must-identify-member precondition 12
DAV:unordered ordering type 8
DAV:update-version-controlled-collection-members-ordered 24
DAV:update-version-ordering-type 24
DAV:collection-must-be-ordered precondition
6.1
DAV:custom ordering type
4.1.1
DAV:initialize-collection-version-ordering-type
9.2
DAV:initialize-ordering-type
9.3
DAV:initialize-version-controlled-bindings-ordered postcondition
9.2
DAV:initialize-version-history-bindings-ordered
9.3
DAV:ordered-collections-supported precondition
5.1
DAV:ordering-modified postcondition
7
DAV:ordering-type property
4.1.1
DAV:ordering-type-set postcondition
5.1, 7
DAV:position-set postcondition
6.1
DAV:segment-must-identify-member precondition
6.1
DAV:unordered ordering type
4.1.1
DAV:update-version-controlled-collection-members-ordered
9.4
DAV:update-version-ordering-type
9.4
H H
Headers Headers
Ordering-Type 5.1 Ordering-Type 9
O O
Ordered Collection 6
Ordered Collection Ordering-Type header 9
3 ORDERPATCH method 14
Ordering-Type header
5.1
ORDERPATCH method
7
P P
Postconditions Postconditions
DAV:ordering-type-set 5.1, 7 DAV:initialize-collection-version-ordering-type 23
DAV:position-set 6.1 DAV:initialize-ordering-type 24
DAV:ordering-type-set 5.1, 7 DAV:initialize-version-controlled-bindings-ordered 23
DAV:ordering-modified 7 DAV:initialize-version-history-bindings-ordered 24
DAV:initialize-version-controlled-bindings-ordered 9.2 DAV:ordering-modified 15
DAV:initialize-collection-version-ordering-type 9.2 DAV:ordering-type-set 9, 15
DAV:initialize-version-history-bindings-ordered 9.3 DAV:position-set 12
DAV:initialize-ordering-type 9.3 DAV:update-version-controlled-collection-members-ordered 24
DAV:update-version-controlled-collection-members-ordered 9.4 DAV:update-version-ordering-type 24
DAV:update-version-ordering-type 9.4
Preconditions Preconditions
DAV:ordered-collections-supported 5.1 DAV:collection-must-be-ordered 12
DAV:collection-must-be-ordered 6.1 DAV:ordered-collections-supported 9
DAV:segment-must-identify-member 6.1 DAV:segment-must-identify-member 12
Protected properties Protected properties
DAV:ordering-type 4.1.1 DAV:ordering-type 7
S
Server-Maintained Ordering S
3 Server-Maintained Ordering 6
U U
Unordered Collection 6
Unordered Collection Intellectual Property Statement
3
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.
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 This document and translations of it may be copied and furnished to
to others, and derivative works that comment on or otherwise others, and derivative works that comment on or otherwise explain it
explain it or assist in its implementation may be prepared, or assist in its implementation may be prepared, copied, published
copied, published and distributed, in whole or in part, without and distributed, in whole or in part, without restriction of any
restriction of any kind, provided that the above copyright notice kind, provided that the above copyright notice and this paragraph are
and this paragraph are included on all such copies and derivative included on all such copies and derivative works. However, this
works. However, this document itself may not be modified in any document itself may not be modified in any way, such as by removing
way, such as by removing the copyright notice or references to the the copyright notice or references to the Internet Society or other
Internet Society or other Internet organizations, except as needed Internet organizations, except as needed for the purpose of
for the purpose of developing Internet standards in which case the developing Internet standards in which case the procedures for
procedures for copyrights defined in the Internet Standards copyrights defined in the Internet Standards process must be
process must be followed, or as required to translate it into followed, or as required to translate it into languages other than
languages other than English. English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not be
be revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on This document and the information contained herein is provided on an
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 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. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/