draft-ietf-webdav-ordering-protocol-02.txt   draft-ietf-webdav-ordering-protocol-03.txt 
WEBDAV Working Group J. Slein, Xerox
INTERNET DRAFT E.J. Whitehead Jr., UC Irvine
<draft-ietf-webdav-ordering-protocol-02.txt> J. Davis, CourseNet
G. Clemm, Rational
C. Fay, FileNet
J. Crawford, IBM
December 20, 1999
Expires June 20, 2000
WebDAV Ordered Collections Protocol Network Working Group J. Slein
Internet Draft Xerox
Expires: March 2003 J. Whitehead
U.C. Santa Cruz
J. Davis
Intelligent Markets
C. Fay
FileNet
J. Crawford
IBM
J. F. Reschke
greenbytes
September 2002
WebDAV Ordered Collections Protocol
draft-ietf-webdav-ordering-protocol-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute working and its working groups. Note that other groups may also distribute
documents as Internet-Drafts. 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 material time. It is inappropriate to use Internet-Drafts as reference
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://www.ietf.org/ietf/1id-abstracts.txt http://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.
Distribution of this document is unlimited. Please send comments to the This Internet-Draft will expire in March 2003.
Distributed Authoring and Versioning (WebDAV) working group at <w3c-
dist-auth@w3.org>, which may be joined by sending a message with subject
"subscribe" to <w3c-dist-auth-request@w3.org>.
Discussions of the WEBDAV working group are archived at URL: Copyright Notice
<http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This specification extends the WebDAV Distributed Authoring Protocol to This specification extends the WebDAV Distributed Authoring Protocol
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 cannot be achieved using a search protocol's ordering option and
be maintained automatically by the server. Protocol elements are cannot be maintained automatically by the server. Protocol elements
defined to let clients specify the position in the ordering of each are defined to let clients specify the position in the ordering of
collection member, as well as the semantics governing the ordering. each collection 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, which may be joined by sending a message with
subject "subscribe" to w3c-dist-auth-request@w3.org.
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.......................................2 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Introduction.................................................2 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Terminology..................................................3 1 Notational Conventions . . . . . . . . . . . . . . . . . . . . 5
4 Overview of Ordered Collections..............................4 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Creating an Ordered Collection...............................4 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Overview.....................................................4 4 Overview of Ordered Collections . . . . . . . . . . . . . . . . 8
5.2 Example: Creating an Ordered Collection......................5 4.1 Additional Collection properties . . . . . . . . . . . . . 8
6 Setting the Position of a Collection Member..................5 4.1.1 DAV:orderingtype (protected) . . . . . . . . . . . . . 9
6.1 Overview.....................................................5 5 Creating an Ordered Collection . . . . . . . . . . . . . . . . 10
6.2 Status Codes.................................................6 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3 Examples: Setting the Position of a Collection Member........6 5.2 Example: Creating an Ordered Collection . . . . . . . . . . 11
7 Changing a Collection Ordering...............................6 6 Setting the Position of a Collection Member . . . . . . . . . . 12
7.1 ORDERPATCH Method............................................6 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1.1 Status Codes.................................................7 6.2 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12
7.1.2 Example: Changing a Collection Ordering......................7 6.3 Examples: Setting the Position of a Collection Member . . . 12
7.1.3 Example: Failure of an ORDERPATCH Request....................9 7 Changing a Collection Ordering . . . . . . . . . . . . . . . . 14
8 Listing the Members of an Ordered Collection................10 7.1 ORDERPATCH Method . . . . . . . . . . . . . . . . . . . . . 14
8.1 Example: PROPFIND on an Ordered Collection..................11 7.1.1 Status Codes . . . . . . . . . . . . . . . . . . . . . 14
9 Headers.....................................................12 7.1.2 Example: Changing a Collection Ordering . . . . . . . . 15
9.1 Ordered Entity Header.......................................12 7.1.3 Example: Failure of an ORDERPATCH Request . . . . . . . 17
9.2 Position Request Header.....................................13 8 Listing the Members of an Ordered Collection . . . . . . . . . 19
10 Properties..................................................13 8.1 Example: PROPFIND on an Ordered Collection . . . . . . . . 19
10.1 orderingtype Property.......................................13 9 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11 XML Elements................................................14 9.1 Position Request Header . . . . . . . . . . . . . . . . . . 23
11.1 unordered XML Element.......................................14 10 XML Elements . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.2 custom XML Element..........................................14 10.1 order XML Element . . . . . . . . . . . . . . . . . . . . 24
11.3 order XML Element...........................................14 10.2 ordermember XML Element . . . . . . . . . . . . . . . . . 24
11.4 ordermember XML Element.....................................14 10.3 position XML Element . . . . . . . . . . . . . . . . . . . 25
11.5 position XML Element........................................15 10.4 first XML Element . . . . . . . . . . . . . . . . . . . . 25
11.6 first XML Element...........................................15 10.5 last XML Element . . . . . . . . . . . . . . . . . . . . . 25
11.7 last XML Element............................................15 10.6 before XML Element . . . . . . . . . . . . . . . . . . . . 26
11.8 before XML Element..........................................15 10.7 after XML Element . . . . . . . . . . . . . . . . . . . . 26
11.9 after XML Element...........................................15 10.8 segment XML Element . . . . . . . . . . . . . . . . . . . 27
11.10 segment XML Element.........................................16 11 Capability Discovery . . . . . . . . . . . . . . . . . . . . . 28
12 Capability Discovery........................................16 11.1 Example: Using OPTIONS for the Discovery of Support for
12.1 Example: Discovery of Support for Ordering..................16 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13 Security Considerations.....................................17 11.2 Example: Using Live Properties for the Discovery of
13.1 Denial of Service and DAV:orderingtype......................17 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14 Internationalization Considerations.........................17 12 Security Considerations . . . . . . . . . . . . . . . . . . . 31
15 IANA Considerations.........................................18 12.1 Denial of Service and DAV:orderingtype . . . . . . . . . . 31
16 Copyright...................................................18 13 Internationalization Considerations . . . . . . . . . . . . . 32
17 Intellectual Property.......................................18 14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
18 Acknowledgements............................................18 15 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 34
19 References..................................................18 16 Intellectual Property . . . . . . . . . . . . . . . . . . . . 35
20 Authors' Addresses..........................................18 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
21 Appendices..................................................19 Normative References . . . . . . . . . . . . . . . . . . . . . . 37
21.1 Appendix 1: Extensions to the WebDAV Document Type Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Definition..................................................19 A Extensions to the WebDAV Document Type Definition . . . . . . . 39
B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.1 Since draft-ietf-webdav-ordering-protocol dated December
1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . . 40
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 [WebDAV], 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
Since this augmented BNF uses the basic production rules provided in [RFC2616]. Since this augmented BNF uses the basic production rules
Section 2.2 of [HTTP], these rules apply to this document as well. provided in Section 2.2 of HTTP, these rules 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].
2 Introduction 2 Introduction
This specification builds on the collection infrastructure provided by This specification builds on the collection infrastructure provided
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 a There are many scenarios where it is useful to impose an ordering on
collection at the server, such as expressing a recommended access order, a collection at the server, such as expressing a recommended access
or a revision history order. The members of a collection might order, or a revision history order. The members of a collection might
represent the pages of a book, which need to be presented in order if represent the pages of a book, which need to be presented in order if
they are to make sense. Or an instructor might create a collection of they are to make sense. Or an instructor might create a collection of
course readings, which she wants to be displayed in the order they are course readings, which she wants to be displayed in the order they
to be read. 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 can case. The resources in the collection may not have properties that
be used to support the desired ordering. Orderings based on properties can be used to support the desired ordering. Orderings based on
can be obtained using a search protocol's ordering option, but orderings properties can be obtained using a search protocol's ordering option,
not based on properties cannot. These orderings generally need to be but orderings not based on properties cannot. These orderings
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 human-
maintained orderings. Its protocol elements allow clients to specify maintained orderings. Its protocol elements allow clients to specify
the position of each collection member in the collection's ordering, as the position of each collection member in the collection's ordering,
well as the semantics governing the ordering. The protocol is designed as well as the semantics governing the ordering. The protocol is
to allow support to be added in the future for orderings that are designed to allow support to be added in the future for orderings
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 discusses describes how to create an ordered collection, and Section 6
how to set a member's position in the ordering of a collection. Section discusses how to set a member's position in the ordering of a
7 explains how to change a collection ordering. Section 8 discusses collection. Section 7 explains how to change a collection ordering.
listing the members of an ordered collection. Sections 9 through 11 Section 8 discusses listing the members of an ordered collection.
define the headers, properties, and XML elements needed to support Section 9 through Section 10 define the headers, properties, and XML
ordered collections. Section 12 describes capability discovery. elements needed to support ordered collections. Section 11 describes
Sections 13 through 15 discuss security, internationalization, and IANA capability discovery. Section 12 through Section 14 discuss security,
considerations. The remaining sections provide supporting information. internationalization, and IANA considerations. The remaining sections
provide supporting information.
3 Terminology 3 Terminology
The terminology used here follows that in the WebDAV Distributed The terminology used here follows that in the [RFC2518]. Definitions
Authoring Protocol specification [WebDAV]. Definitions of the terms of the terms resource, Uniform Resource Identifier (URI), and Uniform
resource, Uniform Resource Identifier (URI), and Uniform Resource Resource Locator (URL) are provided in [RFC2396].
Locator (URL) are provided in [URI].
Ordered Collection Ordered Collection
A collection for which the results from a PROPFIND request are
guaranteed to be in the order specified for that collection
Unordered Collection A collection for which the results from a PROPFIND request are
A collection for which the client cannot depend on the guaranteed to be in the order specified for that collection
repeatability of the ordering of results from a PROPFIND request
Client-Maintained Ordering Unordered Collection
An ordering of collection members that is maintained on the server
based on client requests specifying the position of each
collection member in the ordering
Server-Maintained Ordering A collection for which the client cannot depend on the
An ordering of collection members that is maintained automatically repeatability of the ordering of results from a PROPFIND request
by the server, based on a client's choice of ordering semantics
Client-Maintained Ordering
An ordering of collection members that is maintained on the server
based on client requests specifying the position of each
collection member in the ordering
Server-Maintained Ordering
An ordering of collection members that is maintained automatically
by the server, based on a client's choice of ordering semantics
This document uses the terms "precondition" as "postcondition" as
defined in [RFC3253]. Servers should report pre-/postcondition
failures as described in section 1.6 of this 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 to specifying an ordering for a collection, a client requires the server
follow that ordering whenever it responds to a PROPFIND request on that to follow that ordering whenever it responds to a PROPFIND request on
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 is position of each of the collection's members, either when the member
added to the collection (using the Position header) or later (using the is added to the collection (using the Position header) or later
ORDERPATCH method). For server-maintained orderings, the server (using the ORDERPATCH method). For server-maintained orderings, the
automatically positions each of the collection's members according to server automatically positions each of the collection's members
the ordering semantics. This specification supports only client- according to the ordering semantics. This specification supports only
maintained orderings, but is designed to allow future extension to client-maintained orderings, but is designed to allow future
server-maintained orderings. extension to server-maintained orderings.
A collection that supports ordering is not required to be ordered. It A collection that supports ordering is not required to be ordered. It
is up to the client to decide whether a given collection is ordered and, is up to the client to decide whether a given collection is ordered
if so, to specify the semantics to be used for ordering its members. and, if so, to specify the semantics to be used for ordering its
members.
If a collection is ordered, each of its internal member URIs MUST be in If a collection is ordered, each of its internal member URIs MUST be
the ordering exactly once, and the ordering MUST NOT include any URI in the ordering exactly once, and the ordering MUST NOT include any
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 removed MUST remove an internal member URI from the ordering when it is
from the collection. The server MUST an internal member URI to the removed from the collection. The server MUST an internal member URI
ordering when it is added to the collection. to the ordering when it is added to the collection.
Only one ordering can be attached to any collection. Multiple orderings Only one ordering can be attached to any collection. Multiple
of the same resources can be achieved by creating multiple collections orderings of the same resources can be achieved by creating multiple
referencing those resources, and attaching a different ordering to each collections referencing those resources, and attaching a different
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 is resource. Consequently, the ordering is the same no matter which URI
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.1 DAV:orderingtype (protected)
Indicates whether the collection is ordered and, if so, uniquely
identifies the semantics of the ordering being used. May also point
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
collection to understand where to position them in the ordering. This
property cannot be set using PROPPATCH. Its value can only be set by
including the Ordered header with a MKCOL request or by submitting an
ORDERPATCH request.
The value DAV:unordered indicates that the collection is not ordered.
That is, the client cannot depend on the repeatability of the
ordering of results from a PROPFIND request.
The value DAV:custom indicates that the collection is ordered, but
the semantics governing the ordering are not being advertised.
If the value is a DAV:href element, it contains a URI that uniquely
identifies the semantics of the collection's ordering.
An ordering-aware client interacting with an ordering-unaware server
(e.g., one that is implemented only according to [RFC2518]) SHOULD
assume that if a collection does not have the DAV:orderingtype
property, the collection is unordered.
<!ELEMENT orderingtype (unordered | custom | href) >
<!ELEMENT custom EMPTY >
<!ELEMENT unordered EMPTY >
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 ordered When a collection is created, the client MAY request that it be
and specify the semantics of the ordering by using the new Ordered ordered and specify the semantics of the ordering by using the new
header (defined in Section 9.1) with a MKCOL request. Ordered 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 Ordered header, although the semantics of the ordering with a URI in the Ordered header, although
client MAY simply set the header value to DAV:custom to indicate that the client MAY simply set the header value to DAV:custom to indicate
the collection is ordered but the semantics of the ordering are not that the collection is ordered but the semantics of the ordering are
being advertised. Setting the value to a URI that identifies the not being advertised. Setting the value to a URI that identifies the
ordering semanticsprovides the information a human user or software ordering semantics provides the information a human user or software
package needs to insert new collection members into the ordering package needs to insert new collection members into the ordering
intelligently. Although the URI in the Ordered header MAY point to a intelligently. Although the URI in the Ordered header MAY point to a
resource that contains a definition of the semantics of the ordering, resource that contains a definition of the semantics of the ordering,
clients SHOULD NOT access that resource, in order to avoid overburdening clients SHOULD NOT access that resource, in order to avoid
its server. A value of DAV:unordered in the Ordering header indicates overburdening its server. A value of DAV:unordered in the Ordering
that the client wants the collection to be unordered. If the Ordered header indicates that the client wants the collection to be
header is not present, the collection will be unordered. unordered. If the Ordered header is not present, the collection will
Every collection that supports ordering MUST have a DAV:orderingtype be unordered.
property (defined in Section 10.1), which indicates whether the
collection is ordered and, if so, identifies the semantics of the Additional Marshalling:
ordering. The server sets the initial value of this property based on
the value of the Ordering header in the MKCOL request, if any. If the Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url)
Ordered header is not present, the server sets the value to
DAV:unordered. An ordering-aware client interacting with an ordering- A value of "DAV:unordered" indicates that the collection is not
unaware server (e.g., one that is implemented only according to ordered. A value of "DAV:custom" indicates that the collection is
[WebDAV]) SHOULD assume that if a collection does not have the to be ordered, but the semantics of the ordering is not being
DAV:orderingtype property, the collection is unordered. advertised. Any other Coded-url value indicates that the
collection is ordered, and identifies the semantics of the
ordering.
Additional Preconditions:
(DAV:ordered-collections-supported): the server must support
ordered collections where the new collection is to be created.
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: www.server.org Host: www.server.org
Ordered: <http://www.server.org/orderings/compass.html> Ordered: <http://www.server.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:orderingtype property has as its value the URI from the Ordered DAV:orderingtype property has as its value the URI from the Ordered
header, http://www.server.org/orderings/compass.html. In this case, the header, http://www.server.org/orderings/compass.html. In this case,
URI identifies the semantics governing a client-maintained ordering. As the URI identifies the semantics governing a client-maintained
new members are added to the collection, clients or end users can use ordering. As new members are added to the collection, clients or end
the semantics to determine where to position the new members in the users can use the semantics to determine where to position the new
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, MKREF, COPY, or MKCOL), its position in ordering (for example, with PUT, COPY, or MKCOL), its position in the
the ordering can be set with the new Position header (defined in Section ordering can be set with the new Position header (defined in Section
9.2). The Position header allows the client to specify that an internal 9.1). The Position header allows the client to specify that an
member URI should be first in the collection's ordering, last in the internal member URI should be first in the collection's ordering,
collection's ordering, immediately before some other internal member URI last in the collection's ordering, immediately before some other
in the collection's ordering, or immediately after some other internal internal member URI in the collection's ordering, or immediately
member URI in the collection's ordering. after some other 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 collection, o If the request is adding a new internal member URI to the
the server MUST append the new member to the end of the ordering. collection, the server MUST append the new member to the end of
the ordering.
6.2 Status Codes 6.2 Status Codes
409 (Conflict): Several conditions may cause this response. The request 409 (Conflict): Several conditions may cause this response. The
may specify a position that is before or after a URI that is not an request may specify a position that is before or after a URI that is
internal member URI of the collection, or before or after itself. The not an internal member URI of the collection, or before or after
request may attempt to specify the new member's position in an unordered itself. The request may attempt to specify the new member's position
collection. in an unordered collection.
6.3 Examples: Setting the Position of a Collection Member 6.3 Examples: Setting the Position of a Collection Member
>> Request: >> Request:
COPY /~whitehead/dav/spec08.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.xerox.com/~slein/dav/spec08.html
Position: after requirements.html
>> Response: COPY /~whitehead/dav/spec08.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.xerox.com/~slein/dav/spec08.html
Position: after requirements.html
>> 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
www.xerox.com/~slein/dav/spec08.html. The Position header in this www.xerox.com/~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-protocol-08.txt HTTP/1.1 MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1
Host: www.ics.uci.edu Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/~whitehead/dav/draft-webdav- Destination: http://www.ics.uci.edu/~whitehead/dav/draft-webdav-
protocol-08.txt protocol-08.txt
Position: first Position: first
>> Response: >> Response:
HTTP/1.1 409 Conflict HTTP/1.1 409 Conflict
In this case, the server returned a 409 (Conflict) status code because In this case, the server returned a 409 (Conflict) status code
the /~whitehead/dav/ collection is an unordered collection. because the /~whitehead/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 7 Changing a Collection Ordering
7.1 ORDERPATCH Method 7.1 ORDERPATCH Method
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
ordering or both.
The ORDERPATCH method changes the ordering semantics of the collection The ORDERPATCH method is used to change the ordering semantics of a
identified by the Request-URI, based on the value of DAV:orderingtype collection or to change the order of the collection's members in the
submitted in the request entity body. ordering or both.
The ORDERPATCH method alters the ordering of internal member URIs in the The ORDERPATCH method changes the ordering semantics of the
collection identified by the Request-URI, based on instructions in the collection identified by the Request-URI, based on the value of
ordermember XML elements in the request entity body. The ordermember XML DAV:orderingtype submitted in the request entity body.
elements identify the internal member URIs whose positions are to be
changed, and describe their new positions in the ordering. Each new
position can be specified as first in the ordering, last in the
ordering, immediately before some other internal member URI, or
immediately after some other internal member URI.
The server MUST apply the changes in the order they appear in the order The ORDERPATCH method alters the ordering of internal member URIs in
XML element. The server MUST either apply all the changes or apply none the collection identified by the Request-URI, based on instructions
of them. If any error occurs during processing, all executed changes in the ordermember XML elements in the request entity body. The
MUST be undone and a proper error result returned. ordermember XML elements identify the internal member URIs whose
positions are to be changed, and describe their new positions in the
ordering. Each new position can be specified as first in the
ordering, last in the ordering, immediately before some other
internal member URI, or immediately after some other internal member
URI.
If an ORDERPATCH request changes the ordering semantics, but does not The server MUST apply the changes in the order they appear in the
completely specify the order of the collection members, the server MUST order XML element. The server MUST either apply all the changes or
assign a position in the ordering to each collection member for which a apply none of them. If any error occurs during processing, all
position was not specified. These server-assigned positions MUST all executed changes MUST be undone and a proper error result returned.
follow the last one specified by the client. The result is that all
members for which the client specified a position are at the beginning
of the ordering, followed by any members for which the server assigned
positions.
If an ORDERPATCH request does not change the ordering semantics, any If an ORDERPATCH request changes the ordering semantics, but does not
member positions not specified in the request MUST remain unchanged. completely specify the order of the collection members, the server
MUST assign a position in the ordering to each collection member for
which a position was not specified. These server-assigned positions
MUST all follow the last one specified by the client. The result is
that all members for which the client specified a position are at the
beginning of the ordering, followed by any members for which the
server assigned positions.
If an ORDERPATCH request does not change the ordering semantics, any
member positions not specified in the request MUST remain unchanged.
7.1.1 Status Codes 7.1.1 Status Codes
Since multiple changes can be requested in a single ORDERPATCH request, Since multiple changes can be requested in a single ORDERPATCH
if any problems are encountered, the server MUST return a 207 (Multi- request, if any problems are encountered, the server MUST return a
Status) response, as defined in [WebDAV]. 207 (Multi-Status) response, as defined in [RFC2518].
The following are examples of response codes one would expect to be used The following are examples of response codes one would expect to be
in a 207 (Multi-Status) response for this method: used in a 207 (Multi-Status) response for this method:
200 (OK): The change in ordering was successfully made. 200 (OK): The change in ordering was successfully made.
409 (Conflict): Several conditions may cause this response. The request 409 (Conflict): Several conditions may cause this response. The
may specify a position that is before or after a URI that is not an request may specify a position that is before or after a URI that is
internal member URI of the collection, or before or after itself. The not an internal member URI of the collection, or before or after
request may attempt to set the positions of members of an unordered itself. The request may attempt to set the positions of members of an
collection. unordered collection.
A request to reposition a collection member at the same place in the A request to reposition a collection member at the same place in the
ordering is not an error. ordering is not an error.
7.1.2 Example: Changing a Collection Ordering 7.1.2 Example: Changing a Collection Ordering
Consider a collection /coll-1/ whose DAV:orderingtype is DAV:whim, with
bindings ordered as follows:
three.html Consider a collection /coll-1/ whose DAV:orderingtype is DAV:whim,
four.html with bindings ordered as follows:
one.html
two.html
>> Request: three.html
four.html
one.html
two.html
ORDERPATCH /coll-1/ HTTP/1.1 >> Request:
Host: www.myserver.com
Content-Type: text/xml
Content-Length: xxx
<?xml version="1.0" ?> ORDERPATCH /coll-1/ HTTP/1.1
<d:order xmlns:d="DAV:"> Host: www.myserver.com
<d:orderingtype> Content-Type: text/xml; charset="utf-8"
<d:href>http://www.myserver.com/inorder.ord</d:href> Content-Length: xxx
</d:orderingtype>
<d:ordermember>
<d:href>two.html</d:href>
<d:position>
<d:first/>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>one.html</d:href>
<d:position>
<d:first/>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>three.html</d:href>
<d:position>
<d:last/>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>four.html</d:href>
<d:position>
<d:last/>
</d:position>
</d:ordermember>
</d:order>
>> Response: <?xml version="1.0" ?>
<d:order xmlns:d="DAV:">
<d:orderingtype>
<d:href>http://www.myserver.com/inorder.ord</d:href>
</d:orderingtype>
<d:ordermember>
<d:href>two.html</d:href>
<d:position>
<d:first/>
</d:position>
HTTP/1.1 200 OK </d:ordermember>
<d:ordermember>
<d:href>one.html</d:href>
<d:position>
<d:first/>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>three.html</d:href>
<d:position>
<d:last/>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>four.html</d:href>
<d:position>
<d:last/>
</d:position>
</d:ordermember>
</d:order>
In this example, after the request has been processed, the collection's >> Response:
ordering semantics are identified by the URI
http://www.myserver.com/inorder.ord. The value of the collection's
DAV:orderingtype property has been set to this URI. The request also
contains instructions for changing the positions of the collection's
internal member URIs in the ordering to comply with the new ordering
semantics. If href elements are relative URIs, as in this example, they
are interpreted relative to the collection whose ordering is being
modified. The DAV:ordermember elements are required to be processed in
the order they appear in the request. Consequently, two.html is moved
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
ordering, and finally four.html is moved to the end of the ordering.
After the request has been processed, the collection's ordering is as
follows:
one.html HTTP/1.1 200 OK
two.html
three.html
four.html
7.1.3 Example: Failure of an ORDERPATCH Request In this example, after the request has been processed, the
collection's ordering semantics are identified by the URI
http://www.myserver.com/inorder.ord. The value of the collection's
DAV:orderingtype property has been set to this URI. The request also
contains instructions for changing the positions of the collection's
internal member URIs in the ordering to comply with the new ordering
semantics. If href elements are relative URIs, as in this example,
they are interpreted relative to the collection whose ordering is
being modified. The DAV:ordermember elements are required to be
processed in the order they appear in the request. Consequently,
two.html is moved 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 ordering, and finally four.html is moved to the end
of the ordering. After the request has been processed, the
collection's ordering is as follows:
Consider a collection /coll-1/ with members ordered as follows: one.html
two.html
three.html
four.html
nunavut.map 7.1.3 Example: Failure of an ORDERPATCH Request
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.img
iqaluit.desc
>> Request: Consider a collection /coll-1/ with members ordered as follows:
ORDERPATCH /coll-1/ HTTP/1.1 nunavut.map
Host: www.nunanet.com nunavut.img
Content-Type: text/xml baffin.map
Content-Length: xxx baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.img
iqaluit.desc
<?xml version="1.0" ?> >> Request:
<d:order xmlns:d="DAV:">
<d:ordermember>
<d:href>nunavut.desc</d:href>
<d:position>
<d:after>
<d:segment>nunavut.map</d:segment>
</d:after>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>iqaluit.map</d:href>
<d:position>
<d:after>
<d:segment>pangnirtung.img</d:segment>
</d:after>
</d:position>
</d:ordermember> ORDERPATCH /coll-1/ HTTP/1.1
</d:order> Host: www.nunanet.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
>> Response: <?xml version="1.0" ?>
<d:order xmlns:d="DAV:">
<d:ordermember>
<d:href>nunavut.desc</d:href>
<d:position>
<d:after>
<d:segment>nunavut.map</d:segment>
</d:after>
</d:position>
</d:ordermember>
<d:ordermember>
<d:href>iqaluit.map</d:href>
<d:position>
<d:after>
<d:segment>pangnirtung.img</d:segment>
</d:after>
</d:position>
</d:ordermember>
</d:order>
HTTP/1.1 207 Multi-Status >> Response:
Content-Type: text/xml
Content-Length: xxx
<?xml version="1.0" ?> HTTP/1.1 207 Multi-Status
<d:multistatus xmlns:d="DAV:"> Content-Type: text/xml; charset="utf-8"
<d:response> Content-Length: xxx
<d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
<d:status>HTTP/1.1 424 Failed Dependency</d:status>
</d:response>
<d:response>
<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
<d:status>HTTP/1.1 409 Conflict</d:status>
<d:responsedescription>pangnirtung.img is not a collection
member.</d:responsedescription>
</d:response>
</d:multistatus>
In this example, the client attempted to position iqaluit.map after a <?xml version="1.0" ?>
URI that is not an internal member of the collection /coll-1/. The <d:multistatus xmlns:d="DAV:">
server responded to this client error with a 409 (Conflict) status code. <d:response>
Because ORDERPATCH is an atomic method, the request to reposition <d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
nunavut.desc (which would otherwise have succeeded) failed with a 424 <d:status>HTTP/1.1 424 Failed Dependency</d:status>
(Failed Dependency) status code. </d:response>
<d:response>
<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
<d:status>HTTP/1.1 409 Conflict</d:status>
<d:responsedescription>pangnirtung.img is not a collection
member.</d:responsedescription>
</d:response>
</d:multistatus>
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
server responded to this client error with a 409 (Conflict) status
code. Because ORDERPATCH is an atomic method, the request to
reposition nunavut.desc (which would otherwise have succeeded) failed
with a 424 (Failed Dependency) status code.
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 different In a response to a PROPFIND with Depth: infinity, members of
collections may be interleaved. That is, the server is not required to different collections may be interleaved. That is, the server is not
do a breadth-first traversal. The only requirement is that the members required to do a breadth-first traversal. The only requirement is
of any ordered collection appear in the order defined for the that the members of any ordered collection appear in the order
collection. Thus for the hierarchy illustrated in the following figure, defined for the collection. Thus for the hierarchy illustrated in the
where collection A is an ordered collection with the ordering B C D, following figure, where collection A is an ordered collection 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 the it would be acceptable for the server to return response elements in
order A B E C F G H D. In this response, B, C, and D appear in the the order A B E C F G H D. In this response, B, C, and D appear in
correct order, separated by members of other collections. Clients can the correct order, separated by members of other collections. Clients
use a series of Depth: 1 PROPFIND requests to avoid the complexity of can use a series of Depth: 1 PROPFIND requests to avoid the
processing Depth: infinity responses based on depth-first traversals. complexity of 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 /MyCollection/, which has its Suppose a PROPFIND request is submitted to /MyCollection/, which has
members ordered as follows. its members ordered as follows.
/MyCollection/
lakehazen.html
siorapaluk.html
iqaluit.html
newyork.html
>> Request: /MyCollection/
lakehazen.html
siorapaluk.html
iqaluit.html
newyork.html
PROPFIND /MyCollection/ HTTP/1.1 >> Request:
Host: www.svr.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?> PROPFIND /MyCollection/ HTTP/1.1
<D:propfind xmlns:D="DAV:"> Host: www.svr.com
<D:prop xmlns:J=http://www.svr.com/jsprops/> Depth: 1
<D:resourcetype/> Content-Type: text/xml; charset="utf-8"
<J:latitude/> Content-Length: xxxx
</D:prop>
</D:propfind>
>> Response: <?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:J="http://www.svr.com/jsprops/">
<D:orderingtype/>
<D:resourcetype/>
<J:latitude/>
</D:prop>
</D:propfind>
HTTP/1.1 207 Multi-Status >> Response:
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?> HTTP/1.1 207 Multi-Status
<D:multistatus xmlns:D="DAV:" Content-Type: text/xml; charset="utf-8"
xmlns:J="http:www.svr.com/jsprops/"> Content-Length: xxxx
<D:response>
<D:href>http://www.svr.com/MyCollection/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<J:latitude/>
</D:prop> <?xml version="1.0" ?>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:multistatus xmlns:D="DAV:"
</D:propstat> xmlns:J="http:www.svr.com/jsprops/">
</D:response> <D:response>
<D:response> <D:href>http://www.svr.com/MyCollection/</D:href>
<D:href>http://www.svr.com/MyCollection/lakehazen.html</D:href> <D:propstat>
<D:propstat> <D:prop>
<D:prop> <D:orderingtype><D:custom/></D:orderingtype>
<D:resourcetype/> <D:resourcetype><D:collection/></D:resourcetype>
<J:latitude>82N</J:latitude> </D:prop>
</D:prop> <D:status>HTTP/1.1 200 OK</D:status>
<D:status>HTTP/1.1 200 OK</D:status> </D:propstat>
</D:propstat> <D:propstat>
</D:response> <D:prop>
<D:response> <J:latitude/>
<D:href>http://www.svr.com/MyCollection/siorapaluk.html</D:href> </D:prop>
<D:propstat> <D:status>HTTP/1.1 404 Not Found</D:status>
<D:prop> </D:propstat>
<D:resourcetype/> </D:response>
<J:latitude>78N</J:latitude> <D:response>
</D:prop> <D:href>http://www.svr.com/MyCollection/lakehazen.html</D:href>
<D:status>HTTP/1.1 200 OK</D:status> <D:propstat>
</D:propstat> <D:prop>
</D:response> <D:resourcetype/>
<D:response> <J:latitude>82N</J:latitude>
<D:href>http://www.svr.com/MyCollection/iqaluit.html</D:href> </D:prop>
<D:propstat> <D:status>HTTP/1.1 200 OK</D:status>
<D:prop> </D:propstat>
<D:resourcetype/> <D:propstat>
<J:latitude>62N</J:latitude> <D:prop>
</D:prop> <D:orderingtype/>
<D:status>HTTP/1.1 200 OK</D:status> </D:prop>
</D:propstat> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:response> </D:propstat>
<D:response> </D:response>
<D:href>http://www.svr.com/MyCollection/newyork.html</D:href> <D:response>
<D:propstat> <D:href
<D:prop> >http://www.svr.com/MyCollection/siorapaluk.html</D:href>
<D:resourcetype/> <D:propstat>
<J:latitude>45N</J:latitude> <D:prop>
</D:prop> <D:resourcetype/>
<D:status>HTTP/1.1 200 OK</D:status> <J:latitude>78N</J:latitude>
</D:propstat> </D:prop>
</D:response> <D:status>HTTP/1.1 200 OK</D:status>
</D:multistatus> </D:propstat>
<D:propstat>
<D:prop>
<D:orderingtype/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.svr.com/MyCollection/iqaluit.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>62N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:orderingtype/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.svr.com/MyCollection/newyork.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>45N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
<D:propstat>
<D:prop>
<D:orderingtype/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:propstat>
</D:response>
</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 Headers 9 Headers
9.1 Ordered Entity Header 9.1 Position Request Header
Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url) Position = "Position" ":" ("first" | "last" |
The Ordered header may be used with MKCOL to request that the new (("before" | "after") segment))
collection be ordered and to specify its ordering semantics. A value of
"DAV:unordered" indicates that the collection is not ordered. A value of
"DAV:custom" indicates that the collection is to be ordered, but the
semantics of the ordering is not being advertised. Any other Coded-url
value indicates that the collection is ordered, and identifies the
semantics of the ordering.
9.2 Position Request Header segment is defined in Section 3.3 of [RFC2396].
Position = "Position" ":" ("first" | "last" | The Position header may be used with any method that adds a member to
(("before" | "after") segment)) an ordered collection, to tell the server where in the collection
segment is defined in Section 3.3 of [URI]. ordering to position the new member being added to the collection.
Examples of methods that add members to collections are BIND, PUT,
COPY, MOVE, etc.
The Position header may be used with any method that adds a member to an The segment is interpreted relative to the collection to which the
ordered collection, to tell the server where in the collection ordering new member is being added.
to position the new member being added to the collection. Examples of
methods that add members to collections are BIND, PUT, COPY, MOVE, etc.
The segment is interpreted relative to the collection to which the new The server MUST insert the new member into the ordering at the
member is being added. location specified in the Position header, if one is present (and if
the collection is ordered).
The server MUST insert the new member into the ordering at the location The "first" keyword indicates the new member is put in the beginning
specified in the Position header, if one is present (and if the position in the collection's ordering, while "last" indicates the new
collection is ordered). member is put in the final position in the collection's ordering. The
"before" keyword indicates the new member is added to the
collection's ordering immediately prior to the position of the member
identified in the segment. Likewise, the "after" keyword indicates
the new member is added to the collection's ordering immediately
following the position of the member identified in the segment.
The "first" keyword indicates the new member is put in the beginning If the request is replacing an existing resource, and the Position
position in the collection's ordering, while "last" indicates the new header is present, the server MUST remove the internal member URI
member is put in the final position in the collection's ordering. The from its previous position, and then insert it at the requested
"before" keyword indicates the new member is added to the collection's position.
ordering immediately prior to the position of the member identified in
the segment. Likewise, the "after" keyword indicates the new member is
added to the collection's ordering immediately following the position of
the member identified in the segment.
If the request is replacing an existing resource, and the Position If an attempt is made to use the Position header on a collection that
header is present, the server MUST remove the internal member URI from is unordered, the server MUST fail the request with a 409 (Conflict)
its previous position, and then insert it at the requested position. status code.
If an attempt is made to use the Position header on a collection that is 10 XML Elements
unordered, the server MUST fail the request with a 409 (Conflict) status
code.
10 Properties 10.1 order XML Element
10.1 orderingtype Property Name: order
Namespace: DAV:
Purpose: For use with the new ORDERPATCH method. Describes a change
to be made in a collection's ordering semantics or in the
positions of its members in the ordering or both.
Value: An optional identifier of an ordering semantics for the
collection, followed by a list of changes to be made in
the positions of the members in the collection's ordering.
Name: orderingtype <!ELEMENT order (orderingtype?, ordermember*) >
Namespace: DAV:
Purpose: Indicates whether the collection is ordered and, if so,
uniquely identifies the semantics of the ordering being
used. May also point 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 collection to
understand where to position them in the ordering. This
property cannot be set using PROPPATCH. Its value can only
be set by including the Ordered header with a MKCOL request
or by submitting an ORDERPATCH request.
Value: The value unordered indicates that the collection is not
ordered. The value custom indicates that the collection is
ordered, but the semantics governing the ordering are not
being advertised. If the value is an href element, it
contains a URI that uniquely identifies the semantics of the
collection's ordering.
<!ELEMENT orderingtype (unordered | custom | href) > 10.2 ordermember XML Element
11 XML Elements Name: ordermember
Namespace: DAV:
Purpose: Occurs in the order XML element, and describes the new
position of a single internal member URI in the
collection's ordering.
Value: An href containing a member's path segment, and a
description of its new position in the ordering. The href
XML element is defined in [RFC2518], Section 11.3.
11.1 unordered XML Element <!ELEMENT ordermember (href, position) >
Name: unordered 10.3 position XML Element
Namespace: DAV:
Purpose: A value of the DAV:orderingtype property that indicates that
the collection is not ordered. That is, the client cannot
depend on the repeatability of the ordering of results from
a PROPFIND request.
<!ELEMENT unordered EMPTY > Name: position
Namespace: DAV:
Purpose: Occurs in the ordermember XML element. Describes the new
position in a collection's ordering of one of the members
it contains.
Value: The new position can be described as first in the
collection's ordering, last in the collection's ordering,
immediately before some other collection member, or
immediately after some other collection member.
11.2 custom XML Element <!ELEMENT position (first | last | before | after)>
Name: custom 10.4 first XML Element
Namespace: DAV:
Purpose: A value of the DAV:orderingtype property that indicates that
the collection is ordered, but the semantics of the ordering
are not being advertised.
<!ELEMENT custom EMPTY > Name: first
Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the
member should be placed first in the collection's
ordering.
11.3 order XML Element <!ELEMENT first EMPTY >
Name: order 10.5 last XML Element
Namespace: DAV: Name: last
Purpose: For use with the new ORDERPATCH method. Describes a change Namespace: DAV:
to be made in a collection's ordering semantics or in the Purpose: Occurs in the position XML element. Specifies that the
positions of its members in the ordering or both. member should be placed last in the collection's ordering.
Value: An optional identifier of an ordering semantics for the
collection, followed by a list of changes to be made in the
positions of the members in the collection's ordering.
<!ELEMENT order (orderingtype?, ordermember*) > <!ELEMENT last EMPTY >
11.4 ordermember XML Element 10.6 before XML Element
Name: ordermember Name: before
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the order XML element, and describes the new Purpose: Occurs in the position XML element. Specifies that the
position of a single internal member URI in the collection's member should be placed immediately before the member in
ordering. the enclosed segment XML element in the collection's
ordering.
Value: URI (relative to the parent collection) of the member it
precedes in the ordering
Value: An href containing a member's path segment, and a <!ELEMENT before segment >
description of its new position in the ordering. The href
XML element is defined in [WebDAV], Section 11.3.
<!ELEMENT ordermember (href, position) > 10.7 after XML Element
11.5 position XML Element Name: after
Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the
member should be placed immediately after the member in
the enclosed segment XML element in the collection's
ordering.
Name: position Value: URI (relative to the parent collection) of the member it
Namespace: DAV: follows in the ordering
Purpose: Occurs in the ordermember XML element. Describes the new
position in a collection's ordering of one of the members it
contains.
Value: The new position can be described as first in the
collection's ordering, last in the collection's ordering,
immediately before some other collection member, or
immediately after some other collection member.
<!ELEMENT position (first | last | before | after)> <!ELEMENT after segment >
11.6 first XML Element 10.8 segment XML Element
Name: first Name: segment
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the Purpose: Identifies a member of a collection, used in the
member should be placed first in the collection's ordering. DAV:before and DAV:after elements, to define one member's
position in a collection ordering relative to another
member of the collection.
Value: segment ; as defined in section 3.3 of [RFC2396].
<!ELEMENT first EMPTY > <!ELEMENT segment (#PCDATA)>
11.7 last XML Element 11 Capability Discovery
Name: last Sections 9.1 and 15 of [RFC2518] describe the use of compliance
Namespace: DAV: classes with the DAV header in responses to OPTIONS, to indicate
Purpose: Occurs in the position XML element. Specifies that the which parts of the Web Distributed Authoring protocols the resource
member should be placed last in the collection's ordering. supports. This specification defines an OPTIONAL extension to
[RFC2518]. It defines a new compliance class, called orderedcoll, for
use with the DAV header in responses to OPTIONS requests. If a
collection resource does support ordering, its response to an OPTIONS
request may indicate that it does, by listing the new ORDERPATCH
method as one it supports, and by listing the new orderedcoll
compliance class in the DAV header.
<!ELEMENT last EMPTY > When responding to an OPTIONS request, only a collection or a null
resource can include orderedcoll in the value of the DAV header. By
including orderedcoll, the resource indicates that its internal
member URIs can be ordered. It implies nothing about whether any
collections identified by its internal member URIs can be ordered.
11.8 before XML Element Furthermore, RFC 3253 [RFC3253] introduces the live properties
DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
property-set (section 3.1.4). Servers MUST support these properties
as defined in RFC 3253.
Name: before 11.1 Example: Using OPTIONS for the Discovery of Support for Ordering
Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the
member should be placed immediately before the member in the
enclosed segment XML element in the collection's ordering.
Value: URI (relative to the parent collection) of the member
it precedes in the ordering
<!ELEMENT before segment > >> Request:
11.9 after XML Element OPTIONS /somecollection/ HTTP/1.1
HOST: somehost.org
Name: after >> Response:
Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the
member should be placed immediately after the member in the
enclosed segment XML element in the collection's ordering.
Value: URI (relative to the parent collection) of the member
it follows in the ordering
<!ELEMENT after segment > HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT
Connection: close
Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
DAV: 1, 2, orderedcoll
The DAV header in the response indicates that the resource
/somecollection/ is level 1 and level 2 compliant, as defined in
[RFC2518]. In addition, /somecollection/ supports ordering. The Allow
header indicates that ORDERPATCH requests can be submitted to
/somecollection/.
11.10 segment XML Element 11.2 Example: Using Live Properties for the Discovery of Ordering
Name: segment >> Request:
Namespace: DAV:
Purpose: Identifies a member of a collection, used in the DAV:before
and DAV:after elements, to define one member's position in
a collection ordering relative to another member of the
collection.
Value: segment ; as defined in section 3.3 of [URI].
<!ELEMENT segment (#PCDATA)> PROPFIND /somecollection HTTP/1.1
Host: somehost.org
Depth: 0
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
12 Capability Discovery <?xml version="1.0" encoding="UTF-8" ?>
<propfind xmlns="DAV:">
<prop>
<supported-live-property-set/>
<supported-method-set/>
</prop>
</propfind>
Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes >> Response:
with the DAV header in responses to OPTIONS, to indicate which parts of
the Web Distributed Authoring protocols the resource supports. This
specification defines an OPTIONAL extension to [WebDAV]. It defines a
new compliance class, called orderedcoll, for use with the DAV header in
responses to OPTIONS requests. If a collection resource does support
ordering, its response to an OPTIONS request may indicate that it does,
by listing the new ORDERPATCH method as one it supports, and by listing
the new orderedcoll compliance class in the DAV header.
When responding to an OPTIONS request, only a collection or a null HTTP/1.1 207 Multi-Status
resource can include orderedcoll in the value of the DAV header. By Content-Type: text/xml; charset="utf-8"
including orderedcoll, the resource indicates that its internal member Content-Length: xxx
URIs can be ordered. It implies nothing about whether any collections
identified by its internal member URIs can be ordered.
12.1 Example: Discovery of Support for Ordering <?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://somehost.org/somecollection</href>
<propstat>
<prop>
<supported-live-property-set>
<supported-live-property>
<prop><orderingtype/></prop>
</supported-live-property>
... other live properties omitted for brevity ...
</supported-live-property-set>
<supported-method-set>
<supported-method name="COPY" />
<supported-method name="DELETE" />
<supported-method name="GET" />
<supported-method name="HEAD" />
<supported-method name="LOCK" />
<supported-method name="MKCOL" />
<supported-method name="MOVE" />
<supported-method name="OPTIONS" />
<supported-method name="ORDERPATCH" />
<supported-method name="POST" />
<supported-method name="PROPFIND" />
<supported-method name="PROPPATCH" />
<supported-method name="PUT" />
<supported-method name="TRACE" />
<supported-method name="UNLOCK" />
</supported-method-set>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
>> Request: Note that actual responses MUST contain a complete list of supported
live properties.
OPTIONS /somecollection/ HTTP/1.1 12 Security Considerations
HOST: somehost.org
>> Response: This section is provided to make WebDAV applications aware of the
security implications of this protocol.
HTTP/1.1 200 OK All of the security considerations of HTTP/1.1 and the WebDAV
Date: Tue, 20 Jan 1998 20:52:29 GMT Distributed Authoring Protocol specification also apply to this
Connection: close protocol specification. In addition, ordered collections introduce a
Accept-Ranges: none new security concern. This issue is detailed here.
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, 2, orderedcoll
The DAV header in the response indicates that the resource
/somecollection/ is level 1 and level 2 compliant, as defined in
[WebDAV]. In addition, /somecollection/ supports ordering. The Allow
header indicates that ORDERPATCH requests can be submitted to
/somecollection/. The Public header shows that other Request-URIs on
the server support additional methods.
13 Security Considerations 12.1 Denial of Service and DAV:orderingtype
This section is provided to make WebDAV applications aware of the There may be some risk of denial of service at sites that are
security implications of this protocol. advertised in the DAV:orderingtype property of collections. However,
it is anticipated that widely-deployed applications will use hard-
coded values for frequently-used ordering semantics rather than
looking up the semantics at the location specified by
DAV:orderingtype. This risk will be further reduced if clients
observe the recommendation of Section 5.1 that they not send requests
to the URI in DAV:orderingtype.
All of the security considerations of HTTP/1.1 and the WebDAV 13 Internationalization Considerations
Distributed Authoring Protocol specification also apply to this protocol
specification. In addition, ordered collections introduce a new
security concern. This issue is detailed here.
13.1 Denial of Service and DAV:orderingtype This specification follows the practices of [RFC2518] in encoding all
human-readable content using [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set
Policy [RFC2277].
There may be some risk of denial of service at sites that are advertised WebDAV applications MUST support the character set tagging, character
in the DAV:orderingtype property of collections. However, it is set encoding, and the language tagging functionality of the XML
anticipated that widely-deployed applications will use hard-coded values specification. This constraint ensures that the human-readable
for frequently-used ordering semantics rather than looking up the content of this specification complies with [RFC2277].
semantics at the location specified by DAV:orderingtype. This risk will
be further reduced if clients observe the recommendation of Section 5.1
that they not send requests to the URI in DAV:orderingtype.
14 Internationalization Considerations As in [RFC2518], names in this specification fall into three
categories: names of protocol elements such as methods and headers,
names of XML elements, and names of properties. Naming of protocol
elements follows the precedent of HTTP, using English names encoded
in USASCII for methods and headers. The names of XML elements used in
this specification are English names encoded in UTF-8.
This specification follows the practices of [WebDAV] in encoding all For error reporting, [RFC2518] follows the convention of HTTP/1.1
human-readable content using XML [XML] and in the treatment of names. status codes, including with each status code a short, English
Consequently, this specification complies with the IETF Character Set description of the code (e.g., 423 Locked). Internationalized
Policy [RFC2277]. applications will ignore this message, and display an appropriate
message in the user's language and character set.
WebDAV applications MUST support the character set tagging, character This specification introduces no new strings that are displayed to
set encoding, and the language tagging functionality of the XML users as part of normal, error-free operation of the protocol.
specification. This constraint ensures that the human-readable content
of this specification complies with [RFC2277].
As in [WebDAV}, names in this specification fall into three categories: For rationales for these decisions and advice for application
names of protocol elements such as methods and headers, names of XML implementors, see [RFC2518].
elements, and names of properties. Naming of protocol elements follows
the precedent of HTTP, using English names encoded in USASCII for
methods and headers. The names of XML elements used in this
specification are English names encoded in UTF-8.
For error reporting, [WebDAV] follows the convention of HTTP/1.1 status 14 IANA Considerations
codes, including with each status code a short, English description of
the code (e.g., 423 Locked). Internationalized applications will ignore
this message, and display an appropriate message in the user's language
and character set.
This specification introduces no new strings that are displayed to users This document uses the namespaces defined by [RFC2518] for properties
as part of normal, error-free operation of the protocol. and XML elements. All other IANA considerations mentioned in
[RFC2518] also apply to this document.
For rationales for these decisions and advice for application 15 Copyright
implementors, see [WebDAV].
15 IANA Considerations To be supplied by the RFC Editor.
This document uses the namespaces defined by [WebDAV] for properties and 16 Intellectual Property
XML elements. All other IANA considerations mentioned in [WebDAV] also
apply to this document.
16 Copyright To be supplied by the RFC Editor.
To be supplied by the RFC Editor. 17 Acknowledgements
17 Intellectual Property This draft has benefited from thoughtful discussion by Jim Amsden,
Steve Carter, Tyson Chihaya, Geoff Clemm, Ken Coar, Ellis Cohen,
Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, Marcus Jager,
Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Lisa
Lippert, 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.
To be supplied by the RFC Editor. Normative References
18 Acknowledgements [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
This draft has benefited from thoughtful discussion by Jim Amsden, Steve [RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and
Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Languages", BCP 18, RFC 2277, January 1998.
Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron
Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj
Kasichainula, Rohit Khare, Daniel LaLiberte, Lisa Lippert, 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.
19 References [RFC2396] Berners-Lee, T., Fielding, R.T. and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2277] H.T. Alvestrand, "IETF Policy on Character Sets and [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S.R. and
Languages." RFC 2277, BCP 18. Uninett. January, 1998. Jensen, D., "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999.
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, Masinter, L., Leach, P. and Berners-Lee, T., "Hypertext
Xerox. August, 1998. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and
Levels." RFC 2119, BCP 14. Harvard University. March, 1997. Whitehead, J., "Versioning Extensions to WebDAV", RFC
3253, March 2002.
[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup [XML] World Wide Web Consortium, "Extensible Markup Language
Language (XML)." World Wide Web Consortium Recommendation REC-xml- (XML) 1.0", W3C XML, February 1998.
19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Author's Addresses
Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC
2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999.
[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Judith Slein
Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. Xerox Corporation
Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. 800 Phillips Road, 105-50C
Webster, NY 14580
20 Authors' Addresses EMail: jslein@crt.xerox.com
J. Slein
Xerox Corporation
800 Phillips Road, 105-50C
Webster, NY 14580
Email: jslein@crt.xerox.com
E. J. Whitehead, Jr. Jim Whitehead
Dept. of Information and Computer Science UC Santa Cruz, Dept. of Computer Science
University of California, Irvine 1156 High Street
Irvine, CA 92697-3425 Santa Cruz, CA 95064
Email: ejw@ics.uci.edu US
J. Davis EMail: ejw@cse.ucsc.edu
CourseNet Systems Jim Davis
170 Capp Street Intelligent Markets
San Francisco, CA 94110 410 Jessie Street 6th floor
Email: jrd3@alum.mit.edu San Francisco, CA 94103
G. Clemm EMail: jrd3@alum.mit.edu
Rational Software Corporation
20 Maguire Road
Lexington, MA 02173-3104
Email: gclemm@rational.com
C. Fay Chuck Fay
FileNet Corporation FileNet Corporation
3565 Harbor Boulevard 3565 Harbor Boulevard
Costa Mesa, CA 92626-1420 Costa Mesa, CA 92626-1420
Email: cfay@filenet.com
J. Crawford EMail: cfay@filenet.com
IBM Research
P.O. Box 704
Yorktown Heights, NY 10598
Email: ccjason@us.ibm.com
21 Appendices Jason Crawford
IBM Research
P.O. Box 704
Yorktown Heights, NY 10598
21.1 Appendix 1: Extensions to the WebDAV Document Type Definition EMail: ccjason@us.ibm.com
<!--============= XML Elements from Section 11 ================--> Julian F. Reschke
<!ELEMENT unordered EMPTY > greenbytes GmbH
<!ELEMENT custom EMPTY > Salzmannstrasse 152
<!ELEMENT order (orderingtype?, ordermember*) > Muenster, NW 48159
<!ELEMENT ordermember (href, position) > Germany
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)>
<!--============= Property Elements from Section 10 =============-->
<!ELEMENT orderingtype (unordered | custom | href) >
Expires June 20, 2000 Phone: +49 251 2807760
Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
A Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 11 ================-->
<!ELEMENT unordered EMPTY >
<!ELEMENT custom EMPTY >
<!ELEMENT order (orderingtype?, ordermember*) >
<!ELEMENT ordermember (href, position) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)>
<!--============= Property Elements from Section 10 =============-->
<!ELEMENT orderingtype (unordered | custom | href) >
B Change Log
B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999
Updated contact information for all previous authors.
Specify charset when using text/xml media type.
Made sure artwork fits into 72 columns.
Removed "Public" header from OPTIONS example.
Added Julian Reschke to list of authors.
Fixed broken XML in PROPFIND example and added DAV:orderingtype to
list of requested properties.
Added support for DAV:supported-live-property-set and DAV:supported-
method-set as mandatory features.
B.2 Since draft-ietf-webdav-ordering-protocol-02
Updated change log to refer to expired draft version as "December
1999" version.
Started rewrite marshalling in RFC3253-style and added precondition
and postcondition definitions.
On his request, removed Geoff Clemm's name from the author list
(moved to Acknowledgments).
Renamed "References" to "Normative References".
Removed reference to "MKREF" method.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
 End of changes. 185 change blocks. 
823 lines changed or deleted 926 lines changed or added

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