draft-ietf-webdav-ordering-protocol-00.txt   draft-ietf-webdav-ordering-protocol-01.txt 
WEBDAV Working Group J. Slein, Xerox WEBDAV Working Group J. Slein, Xerox
INTERNET DRAFT E.J. Whitehead Jr., UC Irvine INTERNET DRAFT E.J. Whitehead Jr., UC Irvine
<draft-ietf-webdav-ordering-protocol-00.txt> J. Davis, CourseNet <draft-ietf-webdav-ordering-protocol-01.txt> J. Davis, CourseNet
G. Clemm, Rational G. Clemm, Rational
C. Fay, FileNet C. Fay, FileNet
J. Crawford, IBM J. Crawford, IBM
T. Chihaya, DataChannel T. Chihaya, DataChannel
August 20, 1999 October 15, 1999
Expires February 20, 2000 Expires April 15, 2000
WebDAV Ordered Collections Protocol WebDAV Ordered Collections Protocol
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 all
provisions of Section 10 of RFC2026. Internet-Drafts are working 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, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/ietf/1id-abstracts.txt and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of Internet-Draft Shadow Directories can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to the Distribution of this document is unlimited. Please send comments to the
Distributed Authoring and Versioning (WebDAV) working group at <w3c- Distributed Authoring and Versioning (WebDAV) working group at <w3c-
dist-auth@w3.org>, which may be joined by sending a message with subject dist-auth@w3.org>, which may be joined by sending a message with subject
"subscribe" to <w3c-dist-auth-request@w3.org>. "subscribe" to <w3c-dist-auth-request@w3.org>.
Discussions of the WEBDAV working group are archived at URL: Discussions of the WEBDAV working group are archived at URL:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/>. <http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
Abstract Abstract
The WebDAV Distributed Authoring Protocol provides basic support for The WebDAV Distributed Authoring Protocol provides basic support for
collections, offering the ability to create and list unordered collections, offering the ability to create and list unordered
collections. collections.
This specification is one of a group of three specifications that This specification is one of a group of three specifications that
supplement the WebDAV Distributed Authoring Protocol to increase the supplement the WebDAV Distributed Authoring Protocol to increase the
power of WebDAV collections. This specification defines a protocol power of WebDAV collections. This specification defines a protocol
supporting server-side ordering of collection members. The companion supporting server-side ordering of collection members. The companion
specifications [B] and [RR] define two mechanisms for allowing a single specifications "WebDAV Bindings"[B] and "WebDAV Redirect Reference
resource to appear in more than one collection. Resources"[RR] define two mechanisms for allowing a single resource to
appear in more than one collection.
Table of Contents Table of Contents
1 Notational Conventions.......................................2 1 Notational Conventions......................................2
2 Introduction.................................................3 2 Introduction................................................3
3 Terminology..................................................3 3 Terminology.................................................3
4 Overview of Ordered Collections..............................4 4 Overview of Ordered Collections.............................4
5 Creating an Ordered Collection...............................4 5 Creating an Ordered Collection..............................5
5.1 Overview.....................................................4
5.2 Example: Creating an Ordered Collection......................5 5.1 Overview....................................................5
6 Setting the Position of a Collection Member..................5 5.2 Example: Creating an Ordered Collection.....................5
6.1 Overview.....................................................5 6 Setting the Position of a Collection Member.................6
6.2 Status Codes.................................................6 6.1 Overview....................................................6
6.3 Examples: Setting the Position of a Collection Member........6 6.2 Status Codes................................................6
7 Changing the Semantics of a Collection Ordering..............6 6.3 Examples: Setting the Position of a Collection Member.......6
8 Changing the Position of a Collection Member.................7 7 Changing a Collection Ordering..............................7
8.1 ORDERPATCH Method............................................7 7.1 ORDERPATCH Method...........................................7
8.1.1 Status Codes.................................................7 7.1.1 Status Codes................................................7
8.1.2 Example: Changing Positions in an Ordered Collection.........7 7.1.2 Example: Changing a Collection Ordering.....................8
8.1.3 Example: Failure of an ORDERPATCH Request....................9 7.1.3 Example: Failure of an ORDERPATCH Request...................9
9 Listing the Members of an Ordered Collection................10 8 Listing the Members of an Ordered Collection...............10
9.1 Example: PROPFIND on an Ordered Collection..................10 8.1 Example: PROPFIND on an Ordered Collection.................11
10 Headers.....................................................12 9 Status Codes...............................................13
10.1 Ordered Entity Header.......................................12 9.1 418 Unordered Collection...................................13
10.2 Position Request Header.....................................12 10 Headers....................................................13
11 Status Codes................................................13 10.1 Ordered Entity Header......................................13
11.1 425 Unordered Collection....................................13 10.2 Position Request Header....................................13
12 Properties..................................................13 11 Properties.................................................14
12.1 orderingtype Property.......................................13 11.1 orderingtype Property......................................14
13 XML Elements................................................14 12 XML Elements...............................................14
13.1 unordered XML Element.......................................14 12.1 unordered XML Element......................................14
13.2 custom XML Element..........................................14 12.2 custom XML Element.........................................15
13.3 order XML Element...........................................14 12.3 order XML Element..........................................15
13.4 ordermember XML Element.....................................14 12.4 ordermember XML Element....................................15
13.5 position XML Element........................................15 12.5 position XML Element.......................................15
13.6 first XML Element...........................................15 12.6 first XML Element..........................................15
13.7 last XML Element............................................15 12.7 last XML Element...........................................16
13.8 before XML Element..........................................15 12.8 before XML Element.........................................16
13.9 after XML Element...........................................15 12.9 after XML Element..........................................16
13.10 options XML Element.........................................16 12.10 options XML Element........................................16
13.11 orderingoptions XML Element.................................16 12.11 orderingoptions XML Element................................16
14 Capability Discovery........................................16 13 Capability Discovery.......................................17
14.1 Example: Discovery of Support for Ordering..................16 13.1 Example: Discovery of Support for Ordering.................17
14.2 Additional Capabilities.....................................17 13.2 Additional Capabilities....................................18
14.3 Example: Discovery of Ordering Options......................17 13.3 Example: Discovery of Ordering Options.....................18
15 Security Considerations.....................................18 14 Security Considerations....................................19
15.1 Denial of Service and DAV:orderingtype......................18 14.1 Denial of Service and DAV:orderingtype.....................19
16 Internationalization Considerations.........................18 15 Internationalization Considerations........................19
17 IANA Considerations.........................................19 16 IANA Considerations........................................19
18 Copyright...................................................19 17 Copyright..................................................20
19 Intellectual Property.......................................19 18 Intellectual Property......................................20
20 Acknowledgements............................................19 19 Acknowledgements...........................................20
21 References..................................................19 20 References.................................................20
22 Authors' Addresses..........................................20 21 Authors' Addresses.........................................20
23 Appendices..................................................20 22 Appendices.................................................21
23.1 Appendix 1: Extensions to the WebDAV Document Type 22.1 Appendix 1: Extensions to the WebDAV Document Type
Definition..................................................21 Definition.................................................21
1 Notational Conventions 1 Notational Conventions
Since this document describes a set of extensions to the HTTP/1.1 Since this document describes a set of extensions to the WebDAV
protocol, the augmented BNF used here to describe protocol elements is Distributed Authoring Protocol [WebDAV], itself an extension to the
exactly the same as described in Section 2.1 of [HTTP]. Since this HTTP/1.1 protocol, the augmented BNF used here to describe protocol
augmented BNF uses the basic production rules provided in Section 2.2 of elements is exactly the same as described in Section 2.1 of [HTTP].
[HTTP], these rules apply to this document as well. Since this augmented BNF uses the basic production rules 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
The simple collections that the WebDAV Distributed Authoring Protocol The simple collections that the WebDAV Distributed Authoring Protocol
specification supports are powerful enough to be widely useful. They specification supports are powerful enough to be widely useful. They
provide for the hierarchical organization of resources, with mechanisms provide for the hierarchical organization of resources, with mechanisms
for creating and deleting collections, copying and moving them, locking for creating and deleting collections, copying and moving them, locking
them, adding members to them and removing members from them, and getting them, adding members to them and removing members from them, and getting
listings of their members. Delete, copy, move, list, and lock listings of their members. Delete, copy, move, list, and lock
operations can be applied recursively, so that a client can operate on operations can be applied recursively, so that a client can operate on
whole hierarchies with a single request. whole hierarchies with a single request.
This specification is one of a family of three specifications that build This specification is one of a family of three specifications that build
on the infrastructure defined in [HTTP] and [WebDAV] to extend the on the infrastructure defined in [HTTP] and [WebDAV] to extend the
capabilities of collections. The companion specifications [B] and [RR] capabilities of collections. The companion specifications "WebDAV
define mechanisms for allowing the same resource to appear in multiple Bindings"[B] and "WebDAV Redirect Reference Resources"[RR] define
mechanisms for allowing the same resource to appear in multiple
collections. The present specification defines protocol extensions to collections. The present specification defines protocol extensions to
support ordered collections. support ordered collections.
The WebDAV Distributed Authoring Protocol added to the Web the ability
to navigate Web resources hierarchically, complementing existing
hypertext navigation facilities. In hypertext navigation, links appear
in a specific order in a document. By contrast, hierarchical navigation
has fewer mechanisms for expressing the ordering of a set of resources.
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 a
collection, such as expressing a recommended access order, or a revision collection at the server, such as expressing a recommended access order,
history order. Orderings may be based on property values, but they may or a revision history order. Orderings may be based on property values,
be completely independent of any properties on the resources identified but they may be completely independent of any properties on the
by the collection's internal member URIs. Orderings based on properties resources identified by the collection's internal member URIs.
can be obtained using a search protocol, but orderings not based on Orderings based on properties can be obtained using a search protocol,
properties need some other mechanism. These orderings generally need to but orderings not based on properties need some other mechanism. These
be maintained by a human user. The ordering protocol defined here orderings generally need to be maintained by a human user. The ordering
focuses on support for such human-maintained orderings, but also allows protocol defined here focuses on support for such human-maintained
for server-maintained orderings. orderings, but also allows for server-maintained orderings.
The remainder of this document is structured as follows: Section 3
defines terminology that will be used throughout the specification.
Section 4 provides an overview of ordered collections. Section 5
describes how to create an ordered collection, and Section 6 discusses
how to set a member's position in the ordering of a collection. Section
7 explains how to change a collection ordering. Section 8 discusses
listing the members of an ordered collection. Sections 9 through 12
define the status codes, headers, properties, and XML elements needed to
support ordered collections. Section 13 describes capability discovery.
Sections 14 through 16 discuss security, 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 WebDAV Distributed
Authoring Protocol specification [WebDAV]. Definitions of the terms Authoring Protocol specification [WebDAV]. Definitions of the terms
resource, Uniform Resource Identifier (URI), and Uniform Resource resource, Uniform Resource Identifier (URI), and Uniform Resource
Locator (URL) are provided in [URI]. Definitions of the terms URI Locator (URL) are provided in [URI]. Definitions of the terms URI
mapping, path segment, binding, collection, and internal member URI are mapping, path segment, binding, collection, and internal member URI are
provided in [B]. provided in [B].
Ordered Collection Ordered Collection
A collection for which the results from a PROPFIND request are A collection for which the results from a PROPFIND request are
guaranteed to be in the order specified for that collection guaranteed to be in the order specified for that collection
Unordered Collection Unordered Collection
A collection for which the client cannot depend on the A collection for which the client cannot depend on the
repeatability of the ordering of results from a PROPFIND request repeatability of the ordering of results from a PROPFIND request
skipping to change at line 182 skipping to change at line 193
An ordering of collection members that is maintained on the server An ordering of collection members that is maintained on the server
based on client requests specifying the position of each based on client requests specifying the position of each
collection member in the ordering collection member in the ordering
Server-Maintained Ordering Server-Maintained Ordering
An ordering of collection members that is maintained automatically An ordering of collection members that is maintained automatically
by the server, based on a client's choice of ordering semantics by the server, based on a client's choice of ordering semantics
4 Overview of Ordered Collections 4 Overview of Ordered Collections
When responding to a PROPFIND on a collection, the server orders the
response elements according to the ordering defined on the collection.
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. repeatability of the ordering of results from a PROPFIND request. By
specifying an ordering for a collection, a client requires the server to
follow that ordering whenever it responds to a PROPFIND request on that
collection.
Collections on a compliant server may be ordered, but need not be. It These server-side orderings may be client-maintained or server-
is up to the client to decide whether a given collection is ordered and, maintained. For client-maintained orderings, a client must specify the
if so, to specify the semantics to be used for ordering its bindings. position of each of the collection's bindings in the ordering, either
If a collection is ordered, each of its bindings, and hence internal when the binding is added to the collection (using the Position header)
member URIs, MUST be in the ordering exactly once, and the ordering MUST or later (using the ORDERPATCH method). For server-maintained
NOT include any binding that is not contained by the collection. Only orderings, the server automatically positions each of the collection's
one ordering can be attached to any collection. An ordering is bindings according to the ordering semantics.
considered to be part of the state of a collection resource, and hence
is the same across all URI mappings to the collection. Multiple A collection that supports ordering may be ordered, but is not required
orderings of the same resources can be achieved by creating multiple to be. It is up to the client to decide whether a given collection is
collections referencing those resources, and attaching a different ordered and, if so, to specify the semantics to be used for ordering its
ordering to each collection. bindings. If a collection is ordered, each of its bindings, and hence
internal member URIs, MUST be in the ordering exactly once, and the
ordering MUST NOT include any binding that is not contained by the
collection. Only one ordering can be attached to any collection. An
ordering is considered to be part of the state of a collection resource,
and hence is the same across all URI mappings to the collection.
Multiple orderings of the same resources can be achieved by creating
multiple collections referencing those resources, and attaching a
different ordering to each collection.
The server is responsible for enforcing these constraints on orderings. The server is responsible for enforcing these constraints on orderings.
The server MUST remove a binding (and its derived internal member URI) The server MUST remove a binding (and its derived internal member URI)
from the ordering when it is removed from the collection. The server from the ordering when it is removed from the collection. The server
MUST add a binding (and its derived internal member URI) to the ordering MUST add a binding (and its derived internal member URI) to the ordering
when it is added to the collection. when it is added to the collection.
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 ordered
and specify the semantics of the ordering by using the new Ordered and specify the semantics of the ordering by using the new Ordered
header (defined in Section 8.1) with a MKCOL request. header (defined in Section 10.1) 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. This URI semantics of the ordering with a URI in the Ordered header. This URI
may identify a server-maintained ordering. Clients can discover the may identify a server-maintained ordering. Clients can discover the
available server-maintained orderings using the mechanism defined in available server-maintained orderings using the mechanism defined in
Section 12.2. The URI may identify a semantics for a client-maintained Section 13.2. The URI may identify a semantics for a client-maintained
ordering, providing the information a human user or software package ordering, providing the information a human user or software package
needs to insert new collection members into the ordering intelligently. needs to insert new collection members into the ordering intelligently.
Although the URI in the Ordered header MAY point to a resource that Although the URI in the Ordered header MAY point to a resource that
contains a definition of the semantics of the ordering, clients are contains a definition of the semantics of the ordering, clients are
discouraged from accessing that resource, in order to avoid discouraged from accessing that resource, in order to avoid
overburdening its server. The client MAY set the header value to overburdening its server. The client MAY set the header value to
DAV:custom to indicate that the collection is ordered, but the semantics DAV:custom to indicate that the collection is ordered, but the semantics
of the ordering are not being advertised. If the client does not want of the ordering are not being advertised. If the client does not want
the collection to be ordered, it may omit the Ordered header, or use it the collection to be ordered, it may omit the Ordered header, or use it
with the value DAV:unordered. with the value DAV:unordered.
If the server does not recognize the value of the Ordered header as one If the server does not recognize the value of the Ordered header as one
of its server-maintained orderings, it MUST assume that a client- of its server-maintained orderings, it MUST assume that a client-
maintained ordering is intended. If the value of the Ordered header is maintained ordering is intended. If the value of the Ordered header is
skipping to change at line 239 skipping to change at line 258
with the value DAV:unordered. with the value DAV:unordered.
If the server does not recognize the value of the Ordered header as one If the server does not recognize the value of the Ordered header as one
of its server-maintained orderings, it MUST assume that a client- of its server-maintained orderings, it MUST assume that a client-
maintained ordering is intended. If the value of the Ordered header is maintained ordering is intended. If the value of the Ordered header is
one of the server-maintained orderings that the server supports, it MUST one of the server-maintained orderings that the server supports, it MUST
maintain the collection's ordering according to that ordering semantics maintain the collection's ordering according to that ordering semantics
as new members are added. as new members are added.
Every collection MUST have a DAV:orderingtype property (defined in Every collection MUST have a DAV:orderingtype property (defined in
Section 10.1), which indicates whether the collection is ordered and, if Section 11.1), which indicates whether the collection is ordered and, if
so, identifies the semantics of the ordering. The server sets the so, identifies the semantics of the ordering. The server sets the
initial value of this property based on the value of the Ordering header initial value of this property based on the value of the Ordering header
in the MKCOL request. If the collection is unordered, the in the MKCOL request. If the collection is unordered, the
DAV:orderingtype property MUST have the value DAV:unordered. An DAV:orderingtype property MUST have the value DAV:unordered. An
ordering-aware client interacting with an ordering-unaware server (e.g., ordering-aware client interacting with an ordering-unaware server (e.g.,
one that is implemented only according to [WebDAV]) SHOULD assume that one that is implemented only according to [WebDAV]) SHOULD assume that
if a collection does not have the DAV:orderingtype property, the if a collection does not have the DAV:orderingtype property, the
collection is unordered. collection is unordered.
5.2 Example: Creating an Ordered Collection 5.2 Example: Creating an Ordered Collection
skipping to change at line 276 skipping to change at line 296
the semantics to determine where to position the new members in the the semantics to determine where to position the new members in the
ordering. 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, or MKCOL), its position in the ordering (for example, with PUT, MKREF, or MKCOL), its position in 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
8.2). The Position header allows the client to specify that the member 10.2). The Position header allows the client to specify that the member
should be first in the collection's ordering, last in the collection's should be first in the collection's ordering, last in the collection's
ordering, immediately before some other binding in the collection's ordering, immediately before some other binding in the collection's
ordering, or immediately after some other binding in the collection's ordering, or immediately after some other binding in the collection's
ordering. ordering.
6.2 Status Codes 6.2 Status Codes
409 (Conflict): The request specifies a position that is before or after 409 (Conflict): The request specifies a position that is before or after
a URI that is not an internal member URI of the collection, or before or a URI that is not an internal member URI of the collection, or before or
after itself. after itself.
425 (Unordered Collection): The request specifies a collection position 418 (Unordered Collection): The request specifies a collection position
in an unordered collection or in a collection with a server-maintained in an unordered collection or in a collection with a server-maintained
ordering. ordering.
6.3 Examples: Setting the Position of a Collection Member 6.3 Examples: Setting the Position of a Collection Member
>>Request: >>Request:
MKREF /~whitehead/dav/spec08.ref HTTP/1.1 MKREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu HOST: www.ics.uci.edu
Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt> Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt>
skipping to change at line 318 skipping to change at line 337
identified by the Ref-Target header. The Position header in this identified by the Ref-Target header. 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
/~whitehead/dav/ collection immediately after requirements.html. /~whitehead/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 425 Unordered Collection HTTP/1.1 418 Unordered Collection
In this case, the server returned a 425 (Unordered Collection) status In this case, the server returned a 418 (Unordered Collection) status
code because the /~whitehead/dav/ collection is an unordered collection. code 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 the Semantics of a Collection Ordering 7 Changing a Collection Ordering
After a collection has been created, a client can change its ordering
semantics, or change an ordered collection to an unordered collection or
vice versa, by using PROPPATCH to change the value of its
DAV:orderingtype property (defined in Section 10.1). If the new value
identifies a client-maintained ordering, the client is then responsible
for updating the collection's ordering according to the new semantics. 7.1 ORDERPATCH Method
If it identifies a server-maintained ordering, the server MUST reorder
the collection according to the new semantics. PROPPATCH is defined in
[WebDAV], Section 7.2.
8 Changing the Position of a Collection Member The ORDERPATCH method is used to change the ordering semantics of a
collection or to change the order of bindings in a client-maintained
ordering or both.
8.1 ORDERPATCH Method The ORDERPATCH method changes the ordering semantics of the collection
identified by the Request-URI, based on the value of DAV:orderingtype
submitted in the request entity body. If the new value identifies a
client-maintained ordering, the client is responsible for updating the
collection's ordering according to the new semantics. If it identifies
a server-maintained ordering, the server MUST reorder the collection
according to the new semantics.
The ORDERPATCH method alters the ordering of bindings in the collection The ORDERPATCH method alters the ordering of bindings in the collection
identified by the Request-URI, based on instructions in the order XML identified by the Request-URI, based on instructions in the ordermember
element. The order XML element identifies the bindings whose positions XML elements in the request entity body. The ordermember XML elements
are to be changed, and describes their new positions in the ordering. identify the bindings whose positions are to be changed, and describes
Each new position can be specified as first in the ordering, last in the their new positions in the ordering. Each new position can be specified
ordering, immediately before some other binding, or immediately after as first in the ordering, last in the ordering, immediately before some
some other binding. other binding, or immediately after some other binding.
The server MUST apply the changes in the order they appear in the order 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 apply none XML element. The server MUST either apply all the changes or apply none
of them. If any error occurs during processing, all executed changes of them. If any error occurs during processing, all executed changes
MUST be undone and a proper error result returned. MUST be undone and a proper error result returned.
8.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 request,
the server MUST return a 207 (Multi-Status) response, as defined in the server MUST return a 207 (Multi-Status) response, as defined in
[WebDAV]. [WebDAV].
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 used
in a 207 (Multi-Status) response for this method: 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): The request specifies a position that is before or after 409 (Conflict): The request specifies a position that is before or after
a URI that is not an internal member URI of the collection, or before or a URI that is not an internal member URI of the collection, or before or
after itself. after itself.
425 (Unordered Collection): The request specifies a collection position 418 (Unordered Collection): The request specifies a collection position
in an unordered collection or in a collection with a server-maintained in an unordered collection or in a collection with a server-maintained
ordering. ordering.
A request to reposition a binding at the same place in the ordering is A request to reposition a binding at the same place in the ordering is
not an error. not an error.
8.1.2 Example: Changing Positions in an Ordered Collection 7.1.2 Example: Changing a Collection Ordering
Consider a collection /coll-1/ with bindings ordered as follows: Consider a collection /coll-1/ whose DAV:orderingtype is DAV:unordered,
with bindings ordered as follows:
nunavut.map nunavut.map
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
nunavut.desc nunavut.desc
iqaluit.img iqaluit.img
iqaluit.desc iqaluit.desc
>> Request: >> Request:
ORDERPATCH /coll-1/ HTTP/1.1 ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com Host: www.nunanet.com
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxx Content-Length: xxx
skipping to change at line 404 skipping to change at line 424
>> Request: >> Request:
ORDERPATCH /coll-1/ HTTP/1.1 ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com Host: www.nunanet.com
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<d:order xmlns:d="DAV:"> <d:order xmlns:d="DAV:">
<d:orderingtype>
<d:href>http://www.nunanet.com/geog.ord</d:href>
</d:orderingtype>
<d:ordermember> <d:ordermember>
<d:href>nunavut.desc</d:href> <d:href>nunavut.desc</d:href>
<d:position> <d:position>
<d:after> <d:after>
<d:href>nunavut.map</d:href> <d:href>nunavut.map</d:href>
</d:after> </d:after>
</d:position> </d:position>
</d:ordermember> </d:ordermember>
<d:ordermember> <d:ordermember>
<d:href>iqaluit.img</d:href> <d:href>iqaluit.img</d:href>
skipping to change at line 429 skipping to change at line 452
>> Response: >> Response:
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:"> <d:multistatus xmlns:d="DAV:">
<d:response> <d:response>
<d:href>http://www.nunanet.com/coll-1/</d:href>
<d:propstat>
<d:prop><d:orderingtype/></d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
<d:response>
<d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href> <d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
<d:status>HTTP/1.1 200 OK</d:status> <d:status>HTTP/1.1 200 OK</d:status>
</d:response> </d:response>
<d:response> <d:response>
<d:href>http://www.nunanet.com/coll-1/iqaluit.img</d:href> <d:href>http://www.nunanet.com/coll-1/iqaluit.img</d:href>
<d:status>HTTP/1.1 200 OK</d:status> <d:status>HTTP/1.1 200 OK</d:status>
</d:response> </d:response>
</d:multistatus> </d:multistatus>
If the href elements are relative URIs, as in this example, they are In this example, after the request has been processed, the previously
interpreted relative to the collection that is being reordered. In this unordered collection has become an ordered collection whose ordering
example, after the request has been processed, the collection's ordering semantics are identified by the URI http://www.nunanet.com/geog.ord. The
is as follows: value of the collection's DAV:orderingtype property has been set to this
URI. Since this is a client-maintained ordering, the request also
contained instructions for changing the positions of the bindings 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. After the request has been
processed, the collection's ordering is as follows:
nunavut.map nunavut.map
nunavut.desc nunavut.desc
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
iqaluit.desc iqaluit.desc
iqaluit.img iqaluit.img
8.1.3 Example: Failure of an ORDERPATCH Request 7.1.3 Example: Failure of an ORDERPATCH Request
Consider a collection /coll-1/ with bindings ordered as follows: Consider a collection /coll-1/ with bindings ordered as follows:
nunavut.map nunavut.map
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
nunavut.desc nunavut.desc
skipping to change at line 522 skipping to change at line 557
</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
binding that is not contained in the collection /coll-1/. The server binding that is not contained in the collection /coll-1/. The server
responded to this client error with a 409 (Conflict) status code. responded to this client error with a 409 (Conflict) status code.
Because ORDERPATCH is an atomic method, the request to reposition Because ORDERPATCH is an atomic method, the request to reposition
nunavut.desc (which would otherwise have succeeded) failed with a 424 nunavut.desc (which would otherwise have succeeded) failed with a 424
(Failed Dependency) status code. (Failed Dependency) status code.
9 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.
When responding to a PROPFIND on an ordered collection, the server When responding to a PROPFIND on an ordered collection, the server
SHOULD include the DAV:orderingtype property in the DAV:response element SHOULD include the DAV:orderingtype property in the DAV:response element
for the collection, even if the client did not explicitly request it. for the collection, even if the client did not explicitly request it.
9.1 Example: PROPFIND on an Ordered Collection 8.1 Example: PROPFIND on an Ordered Collection
Suppose a PROPFIND request is submitted to the following collection, Suppose a PROPFIND request is submitted to the following collection,
which has its members ordered according to their distance from the which has its members ordered according to their distance from the
equator. equator.
/MyCollection/ /MyCollection/
lakehazen.html lakehazen.html
siorapaluk.html siorapaluk.html
iqaluit.html iqaluit.html
newyork.html newyork.html
skipping to change at line 642 skipping to change at line 677
</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 ordered according to their distance from the equator, as members ordered according to their distance from the equator, as
specified by the value of DAV:orderingtype. Although the client did not specified by the value of DAV:orderingtype. Although the client did not
explicitly ask for the value of DAV:orderingtype, the server provided it explicitly ask for the value of DAV:orderingtype, the server provided it
as one of the collection properties, allowing the client to tell that as one of the collection properties, allowing the client to tell that
the collection is ordered and to identify the ordering semantics. the collection is ordered and to identify the ordering semantics.
9 Status Codes
9.1 418 Unordered Collection
The 418 (Unordered Collection) status code indicates that the client
attempted to set the position of an internal collection member in an
unordered collection or in a collection with a server-maintained
ordering.
10 Headers 10 Headers
10.1 Ordered Entity Header 10.1 Ordered Entity Header
Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url) Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url)
The Ordered header may be used with MKCOL to request that the new The Ordered header may be used with MKCOL to request that the new
collection be ordered and to specify its ordering semantics. A value of 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:unordered" indicates that the collection is not ordered. A value of
"DAV:custom" indicates that the collection is to be ordered, but the "DAV:custom" indicates that the collection is to be ordered, but the
skipping to change at line 702 skipping to change at line 746
collection with a client-maintained ordering, then: collection with a client-maintained ordering, 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 binding to the collection, the server o If the request is adding a new binding to the collection, the server
MUST append the new binding to the end of the ordering. MUST append the new binding to the end of the ordering.
If an attempt is made to use the Position header on a collection that is If an attempt is made to use the Position header on a collection that is
unordered or that has a server-maintained ordering, the server MUST fail unordered or that has a server-maintained ordering, the server MUST fail
the request with a 425 (Unordered) status code. the request with a 418 (Unordered) status code.
11 Status Codes
11.1 425 Unordered Collection
The 425 (Unordered Collection) status code indicates that the client
attempted to set the position of an internal collection member in an
unordered collection or in a collection with a server-maintained
ordering.
12 Properties 11 Properties
12.1 orderingtype Property 11.1 orderingtype Property
Name: orderingtype Name: orderingtype
Namespace: DAV: Namespace: DAV:
Purpose: Indicates whether the collection is ordered and, if so, Purpose: Indicates whether the collection is ordered and, if so,
uniquely identifies the semantics of the ordering being uniquely identifies the semantics of the ordering being
used. May also point to an explanation of the semantics in used. May also point to an explanation of the semantics in
human and / or machine-readable form. At a minimum, this human and / or machine-readable form. At a minimum, this
allows human users who add members to the collection to allows human users who add members to the collection to
understand where to position them in the ordering. 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 Value: The value unordered indicates that the collection is not
ordered. The value custom indicates that the collection is ordered. The value custom indicates that the collection is
ordered, but the semantics governing the ordering are not ordered, but the semantics governing the ordering are not
being advertised. If the value is an href element, it being advertised. If the value is an href element, it
contains a URI that uniquely identifies the semantics of the contains a URI that uniquely identifies the semantics of the
collection's ordering. collection's ordering.
<!ELEMENT orderingtype (unordered | custom | href) > <!ELEMENT orderingtype (unordered | custom | href) >
13 XML Elements 12 XML Elements
13.1 unordered XML Element 12.1 unordered XML Element
Name: unordered Name: unordered
Namespace: DAV: Namespace: DAV:
Purpose: A value of the DAV:orderingtype property that indicates that Purpose: A value of the DAV:orderingtype property that indicates that
the collection is not ordered. That is, the client cannot the collection is not ordered. That is, the client cannot
depend on the repeatability of the ordering of results from depend on the repeatability of the ordering of results from
a PROPFIND request. a PROPFIND request.
<!ELEMENT unordered EMPTY > <!ELEMENT unordered EMPTY >
13.2 custom XML Element 12.2 custom XML Element
Name: custom Name: custom
Namespace: DAV: Namespace: DAV:
Purpose: A value of the DAV:orderingtype property that indicates that Purpose: A value of the DAV:orderingtype property that indicates that
the collection is ordered, but the semantics of the ordering the collection is ordered, but the semantics of the ordering
are not being advertised. are not being advertised.
<!ELEMENT custom EMPTY > <!ELEMENT custom EMPTY >
13.3 order XML Element 12.3 order XML Element
Name: order Name: order
Namespace: DAV: Namespace: DAV:
Purpose: For use with the new ORDERPATCH method. Describes a change Purpose: For use with the new ORDERPATCH method. Describes a change
to be made in a collection ordering. to be made in a collection's ordering semantics or in the
Value: A description of the new positions of the bindings a positions of its bindings in the ordering or both.
collection contains in its 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 bindings in the collection's ordering.
<!ELEMENT order (ordermember+) > <!ELEMENT order (orderingtype?, ordermember*) >
13.4 ordermember XML Element 12.4 ordermember XML Element
Name: ordermember Name: ordermember
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the order XML element, and describes the new Purpose: Occurs in the order XML element, and describes the new
position of a single binding in the collection's ordering. position of a single binding in the collection's ordering.
Value: An href containing a binding's path segment, and a Value: An href containing a binding's path segment, and a
description of its new position in the ordering. The href description of its new position in the ordering. The href
XML element is defined in [WebDAV], Section 11.3. XML element is defined in [WebDAV], Section 11.3.
<!ELEMENT ordermember (href, position) > <!ELEMENT ordermember (href, position) >
13.5 position XML Element 12.5 position XML Element
Name: position Name: position
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the ordermember XML element. Describes the new Purpose: Occurs in the ordermember XML element. Describes the new
position in a collection's ordering of one of the bindings position in a collection's ordering of one of the bindings
it contains. it contains.
Value: The new position can be described as first in the Value: The new position can be described as first in the
collection's ordering, last in the collection's ordering, collection's ordering, last in the collection's ordering,
immediately before some other binding, or immediately after immediately before some other binding, or immediately after
some other binding. some other binding.
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
13.6 first XML Element 12.6 first XML Element
Name: first Name: first
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the Purpose: Occurs in the position XML element. Specifies that the
binding should be placed first in the collection's ordering. binding should be placed first in the collection's ordering.
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
13.7 last XML Element 12.7 last XML Element
Name: last Name: last
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the Purpose: Occurs in the position XML element. Specifies that the
binding should be placed last in the collection's ordering. binding should be placed last in the collection's ordering.
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
13.8 before XML Element 12.8 before XML Element
Name: before Name: before
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the Purpose: Occurs in the position XML element. Specifies that the
binding should be placed immediately before the binding in binding should be placed immediately before the binding in
the enclosed href XML element in the collection's ordering. the enclosed href XML element in the collection's ordering.
Value: href of the member it precedes in the ordering Value: href of the member it precedes in the ordering
<!ELEMENT before href > <!ELEMENT before href >
13.9 after XML Element 12.9 after XML Element
Name: after Name: after
Namespace: DAV: Namespace: DAV:
Purpose: Occurs in the position XML element. Specifies that the Purpose: Occurs in the position XML element. Specifies that the
binding should be placed immediately after the binding in binding should be placed immediately after the binding in
the enclosed href XML element in the collection's ordering. the enclosed href XML element in the collection's ordering.
Value: href of the member it follows in the ordering Value: href of the member it follows in the ordering
<!ELEMENT after href > <!ELEMENT after href >
13.10 options XML Element 12.10 options XML Element
Name: options Name: options
Namespace: DAV: Namespace: DAV:
Purpose: Used in OPTIONS requests to ask for more detailed Purpose: Used in OPTIONS requests to ask for more detailed
information about capabilities than can be provided in the information about capabilities than can be provided in the
DAV: response header. Used in OPTIONS responses to provide DAV: response header. Used in OPTIONS responses to provide
that information. that information.
Value: List of elements identifying or providing the additional Value: List of elements identifying or providing the additional
information desired. information desired.
<!ELEMENT options (orderingoptions | ANY)+ > <!ELEMENT options (orderingoptions | ANY)+ >
13.11 orderingoptions XML Element 12.11 orderingoptions XML Element
Name: orderingoptions Name: orderingoptions
Namespace: DAV: Namespace: DAV:
Purpose: Used in OPTIONS requests to ask for the list of server- Purpose: Used in OPTIONS requests to ask for the list of server-
maintained orderings that can be supported at the request- maintained orderings that can be supported at the request-
URI. Used in OPTIONS responses to provide that information. URI. Used in OPTIONS responses to provide that information.
These values can be used in the Ordered header or the These values can be used in the Ordered header or the
DAV:orderingtype property to request that a particular DAV:orderingtype property to request that a particular
server-maintained ordering be applied to the collection. server-maintained ordering be applied to the collection.
Value: EMPTY on requests. On responses, it is the list of server- Value: EMPTY on requests. On responses, it is the list of server-
maintained orderings available for the request-URI. maintained orderings available for the request-URI.
skipping to change at line 862 skipping to change at line 903
maintained orderings that can be supported at the request- maintained orderings that can be supported at the request-
URI. Used in OPTIONS responses to provide that information. URI. Used in OPTIONS responses to provide that information.
These values can be used in the Ordered header or the These values can be used in the Ordered header or the
DAV:orderingtype property to request that a particular DAV:orderingtype property to request that a particular
server-maintained ordering be applied to the collection. server-maintained ordering be applied to the collection.
Value: EMPTY on requests. On responses, it is the list of server- Value: EMPTY on requests. On responses, it is the list of server-
maintained orderings available for the request-URI. maintained orderings available for the request-URI.
<!ELEMENT orderingoptions ( (#PCDATA)+ | EMPTY) > <!ELEMENT orderingoptions ( (#PCDATA)+ | EMPTY) >
14 Capability Discovery 13 Capability Discovery
Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes
with the DAV header in responses to OPTIONS, to indicate which parts of with the DAV header in responses to OPTIONS, to indicate which parts of
the Web Distributed Authoring protocols the resource supports. This the Web Distributed Authoring protocols the resource supports. This
specification defines an OPTIONAL extension to [WebDAV]. It defines a specification defines an OPTIONAL extension to [WebDAV]. It defines a
new compliance class, called orderedcoll, for use with the DAV header in new compliance class, called orderedcoll, for use with the DAV header in
responses to OPTIONS requests. If a collection resource does support responses to OPTIONS requests. If a collection resource does support
ordering, its response to an OPTIONS request MUST indicate that it does, ordering, its response to an OPTIONS request MUST indicate that it does,
by listing the new ORDERPATCH method as one it supports, and by listing by listing the new ORDERPATCH method as one it supports, and by listing
the new orderedcoll compliance class in the DAV header. the new orderedcoll 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 orderedcoll in the value of the DAV header. By resource can include orderedcoll in the value of the DAV header. By
including orderedcoll, the resource indicates that its bindings can be including orderedcoll, the resource indicates that its bindings can be
ordered. It implies nothing about whether any collections identified by ordered. It implies nothing about whether any collections identified by
its internal member URIs can be ordered. its internal member URIs can be ordered.
14.1 Example: Discovery of Support for Ordering 13.1 Example: Discovery of Support for Ordering
>> Request: >> Request:
OPTIONS /somecollection/ HTTP/1.1 OPTIONS /somecollection/ HTTP/1.1
HOST: somehost.org HOST: somehost.org
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT Date: Tue, 20 Jan 1998 20:52:29 GMT
skipping to change at line 906 skipping to change at line 947
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, 2, orderedcoll DAV: 1, 2, orderedcoll
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
[WebDAV]. In addition, /somecollection/ supports ordering. The Allow [WebDAV]. In addition, /somecollection/ supports ordering. The Allow
header indicates that ORDERPATCH requests can be submitted to header indicates that ORDERPATCH requests can be submitted to
/somecollection/. The Public header shows that other Request-URIs on /somecollection/. The Public header shows that other Request-URIs on
the server support additional methods. the server support additional methods.
14.2 Additional Capabilities 13.2 Additional Capabilities
Clients may need detailed information about specific areas of Web Clients may need detailed information about specific areas of Web
Distributed Authoring functionality. This information can be requested Distributed Authoring functionality. This information can be requested
by sending an OPTIONS request with an XML body that includes a by sending an OPTIONS request with an XML body that includes a
DAV:options element. The DAV:options element contains a list of empty DAV:options element. The DAV:options element contains a list of empty
elements identifying the information the client needs. elements identifying the information the client needs.
As described in Section 4, servers may offer a set of server-maintained As described in Section 3, servers may offer a set of server-maintained
orderings on collections. Clients can discover the list of server- orderings on collections. Clients can discover the list of server-
maintained orderings available for the request-URI by including an empty maintained orderings available for the request-URI by including an empty
DAV:orderingoptions element in the DAV:options element. The response DAV:orderingoptions element in the DAV:options element. The response
will include a DAV:orderingoptions element with the list of supported will include a DAV:orderingoptions element with the list of supported
server-maintained orderings. Servers SHOULD advertise the server- server-maintained orderings. Servers SHOULD advertise the server-
maintained orderings available using this mechanism. maintained orderings available using this mechanism.
14.3 Example: Discovery of Ordering Options 13.3 Example: Discovery of Ordering Options
>> Request: >> Request:
OPTIONS /somecollection/ HTTP/1.1 OPTIONS /somecollection/ HTTP/1.1
HOST: somehost.org HOST: somehost.org
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:options xmlns:D="DAV:"> <D:options xmlns:D="DAV:">
<D:orderingoptions/> <D:orderingoptions/>
</D:options> </D:options>
skipping to change at line 961 skipping to change at line 1001
<X:title-ascending/> <X:title-ascending/>
<X:date-descending/> <X:date-descending/>
</D:orderingoptions> </D:orderingoptions>
</D:options> </D:options>
This response indicates that the resource /somecollection/ is level 1 This response indicates that the resource /somecollection/ is level 1
compliant, as defined in [WebDAV]. In addition, /somecollection/ compliant, as defined in [WebDAV]. In addition, /somecollection/
supports ordering. The client also asked for a list of the server- supports ordering. The client also asked for a list of the server-
maintained orderings that are supported for /somecollection/. The maintained orderings that are supported for /somecollection/. The
response indicates that the orderings Xerox:author-ascending, response indicates that the orderings Xerox:author-ascending,
Xerox:title-ascending, and Xerox:date-descending are supported. Xerox:title-ascending, and Xerox:date-descending are supported.
15 Security Considerations 14 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 protocol Distributed Authoring Protocol specification also apply to this protocol
specification. In addition, ordered collections introduce a new specification. In addition, ordered collections introduce a new
security concern. This issue is detailed here. security concern. This issue is detailed here.
15.1 Denial of Service and DAV:orderingtype 14.1 Denial of Service and DAV:orderingtype
There may be some risk of denial of service at sites that are advertised There may be some risk of denial of service at sites that are advertised
in the DAV:orderingtype property of collections. However, it is in the DAV:orderingtype property of collections. However, it is
anticipated that widely-deployed applications will use hard-coded values anticipated that widely-deployed applications will use hard-coded values
for frequently-used ordering semantics rather than looking up the for frequently-used ordering semantics rather than looking up the
semantics at the location specified by DAV:orderingtype. In addition, semantics at the location specified by DAV:orderingtype. In addition,
Section 4 discourages clients from looking up the semantics at that Section 3 discourages clients from looking up the semantics at that
location. location.
16 Internationalization Considerations 15 Internationalization Considerations
This specification follows the practices of [WebDAV] in encoding all This specification follows the practices of [WebDAV] in encoding all
human-readable content using XML [XML] and in the treatment of names. human-readable content using XML [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 [Alvestrand]. Policy [Alvestrand].
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 content specification. This constraint ensures that the human-readable content
of this specification complies with [Alvestrand]. of this specification complies with [Alvestrand].
skipping to change at line 1012 skipping to change at line 1052
For error reporting, [WebDAV] follows the convention of HTTP/1.1 status For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
codes, including with each status code a short, English description of codes, including with each status code a short, English description of
the code (e.g., 423 Locked). Internationalized applications will ignore the code (e.g., 423 Locked). Internationalized applications will ignore
this message, and display an appropriate message in the user's language this message, and display an appropriate message in the user's language
and character set. and character set.
For rationales for these decisions and advice for application For rationales for these decisions and advice for application
implementors, see [WebDAV]. implementors, see [WebDAV].
17 IANA Considerations 16 IANA Considerations
This document uses the namespaces defined by [WebDAV] for properties and This document uses the namespaces defined by [WebDAV] for properties and
XML elements. All other IANA considerations mentioned in [WebDAV] also XML elements. All other IANA considerations mentioned in [WebDAV] also
apply to this document. apply to this document.
18 Copyright In addition, this document defines a new HTTP/1.1 status code, 418
(Unordered Collection) defined in Section 9.1.
17 Copyright
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
19 Intellectual Property 18 Intellectual Property
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
20 Acknowledgements 19 Acknowledgements
This draft has benefited from thoughtful discussion by Jim Amsden, Steve This draft has benefited from thoughtful discussion by Jim Amsden, Steve
Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day,
Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex
Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John
Stracke, John Tigue, John Turner, and others. Stracke, John Tigue, John Turner, and others.
21 References 20 References
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,
Xerox. August, 1998. Xerox. August, 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, BCP 14. Harvard University. March, 1997. Levels." RFC 2119, BCP 14. Harvard University. March, 1997.
[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)." World Wide Web Consortium Recommendation REC-xml- Language (XML)." World Wide Web Consortium Recommendation REC-xml-
skipping to change at line 1067 skipping to change at line 1110
[B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in
progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine, progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine,
CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
[RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. [RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work
in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC
Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
22 Authors' Addresses 21 Authors' Addresses
J. Slein J. Slein
Xerox Corporation Xerox Corporation
800 Phillips Road, 105-50C 800 Phillips Road, 105-50C
Webster, NY 14580 Webster, NY 14580
Email: jslein@crt.xerox.com Email: jslein@crt.xerox.com
E. J. Whitehead, Jr. E. J. Whitehead, Jr.
Dept. of Information and Computer Science Dept. of Information and Computer Science
University of California, Irvine University of California, Irvine
skipping to change at line 1109 skipping to change at line 1152
J. Crawford J. Crawford
IBM IBM
Email: ccjason@us.ibm.com Email: ccjason@us.ibm.com
T. Chihaya T. Chihaya
DataChannel, Inc. DataChannel, Inc.
155 108th Ave. N.E., Suite 400 155 108th Ave. N.E., Suite 400
Bellevue, WA 98004 Bellevue, WA 98004
Email: Tyson@DataChannel.com Email: Tyson@DataChannel.com
23 Appendices 22 Appendices
23.1 Appendix 1: Extensions to the WebDAV Document Type Definition 22.1 Appendix 1: Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 11 ================--> <!--============= XML Elements from Section 12 ================-->
<!ELEMENT unordered EMPTY > <!ELEMENT unordered EMPTY >
<!ELEMENT custom EMPTY > <!ELEMENT custom EMPTY >
<!ELEMENT order (ordermember+) > <!ELEMENT order (orderingtype?, ordermember*) >
<!ELEMENT ordermember (href, position) > <!ELEMENT ordermember (href, position) >
<!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 href > <!ELEMENT before href >
<!ELEMENT after href > <!ELEMENT after href >
<!ELEMENT options (refintegrityoptions | orderingoptions)+ > <!ELEMENT options (refintegrityoptions | orderingoptions)+ >
<!ELEMENT orderingoptions ( (#PCDATA)+ | EMPTY) > <!ELEMENT orderingoptions ( (#PCDATA)+ | EMPTY) >
<!--============= Property Elements from Section 9 ==================--> <!--============= Property Elements from Section 0 ==================-->
<!ELEMENT orderingtype (arbitrary | custom | href) > <!ELEMENT orderingtype (unordered | custom | href) >
Expires February 20, 2000 Expires April 15, 2000
 End of changes. 

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