draft-ietf-webdav-ordering-protocol-04.txt   draft-ietf-webdav-ordering-protocol-05.txt 
Network Working Group J. Slein Network Working Group J. Slein
Internet Draft Xerox Internet Draft Xerox
Expires: July 2003 J. Whitehead Expires: August 2003 J. Whitehead
U.C. Santa Cruz U.C. Santa Cruz
J. Crawford J. Crawford
IBM IBM
J. F. Reschke J. F. Reschke
greenbytes greenbytes
January 2003 February 2003
WebDAV Ordered Collections Protocol WebDAV Ordered Collections Protocol
draft-ietf-webdav-ordering-protocol-04 draft-ietf-webdav-ordering-protocol-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working 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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://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.
This Internet-Draft will expire in July 2003. This Internet-Draft will expire in August 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This specification extends the WebDAV Distributed Authoring Protocol This specification extends the WebDAV Distributed Authoring Protocol
to support server-side ordering of collection members. Of particular to support server-side ordering of collection members. Of particular
interest are orderings that are not based on property values, and so interest are orderings that are not based on property values, and so
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . 3 Table of Contents . . . . . . . . . . . . . . . . . . . . . . 3
1 Notational Conventions . . . . . . . . . . . . . . . . . . . 4 1 Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Overview of Ordered Collections . . . . . . . . . . . . . . 7 4 Overview of Ordered Collections . . . . . . . . . . . . . . 7
4.1 Additional Collection properties . . . . . . . . . . . . 7 4.1 Additional Collection properties . . . . . . . . . . . . 7
4.1.1 DAV:orderingtype (protected) . . . . . . . . . . . . 8 4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . 8
5 Creating an Ordered Collection . . . . . . . . . . . . . . . 9 5 Creating an Ordered Collection . . . . . . . . . . . . . . . 9
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Example: Creating an Ordered Collection . . . . . . . . 10 5.2 Example: Creating an Ordered Collection . . . . . . . . 10
6 Setting the Position of a Collection Member . . . . . . . . 11 6 Setting the Position of a Collection Member . . . . . . . . 11
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Examples: Setting the Position of a Collection Member . 12 6.2 Examples: Setting the Position of a Collection Member . 12
7 Changing a Collection Ordering: ORDERPATCH method . . . . . 14 7 Changing a Collection Ordering: ORDERPATCH method . . . . . 14
7.1 Example: Changing a Collection Ordering . . . . . . . . 16 7.1 Example: Changing a Collection Ordering . . . . . . . . 16
7.2 Example: Failure of an ORDERPATCH Request . . . . . . . 18 7.2 Example: Failure of an ORDERPATCH Request . . . . . . . 17
8 Listing the Members of an Ordered Collection . . . . . . . . 20 8 Listing the Members of an Ordered Collection . . . . . . . . 20
8.1 Example: PROPFIND on an Ordered Collection . . . . . . . 20 8.1 Example: PROPFIND on an Ordered Collection . . . . . . . 20
9 Relationship to versioned collections . . . . . . . . . . . 24 9 Relationship to versioned collections . . . . . . . . . . . 24
9.1 Additional semantics for collection version properties . 24 9.1 Additional semantics for collection version properties . 24
10 Capability Discovery . . . . . . . . . . . . . . . . . . . 25 10 Capability Discovery . . . . . . . . . . . . . . . . . . . 25
10.1 Example: Using OPTIONS for the Discovery of Support for 10.1 Example: Using OPTIONS for the Discovery of Support for
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2 Example: Using Live Properties for the Discovery of 10.2 Example: Using Live Properties for the Discovery of
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11 Security Considerations . . . . . . . . . . . . . . . . . . 28 11 Security Considerations . . . . . . . . . . . . . . . . . . 28
11.1 Denial of Service and DAV:orderingtype . . . . . . . . 28 11.1 Denial of Service and DAV:ordering-type . . . . . . . . 28
12 Internationalization Considerations . . . . . . . . . . . . 29 12 Internationalization Considerations . . . . . . . . . . . . 29
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
14 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 31 14 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 31
15 Intellectual Property . . . . . . . . . . . . . . . . . . . 32 15 Intellectual Property . . . . . . . . . . . . . . . . . . . 32
16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33
Normative References . . . . . . . . . . . . . . . . . . . . . 34 Normative References . . . . . . . . . . . . . . . . . . . . . 34
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 34 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 34
A Extensions to the WebDAV Document Type Definition . . . . . 36 A Extensions to the WebDAV Document Type Definition . . . . . 36
B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.1 Since draft-ietf-webdav-ordering-protocol dated December B.1 Since draft-ietf-webdav-ordering-protocol dated December
1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . 37 B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . 37
B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . 37 B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . 37
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . 38
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1 Notational Conventions 1 Notational Conventions
Since this document describes a set of extensions to the WebDAV Since this document describes a set of extensions to the WebDAV
Distributed Authoring Protocol [RFC2518], itself an extension to the Distributed Authoring Protocol [RFC2518], itself an extension to the
HTTP/1.1 protocol, the augmented BNF used here to describe protocol HTTP/1.1 protocol, the augmented BNF used here to describe protocol
elements is exactly the same as described in Section 2.1 of HTTP elements is exactly the same as described in Section 2.1 of HTTP
[RFC2616]. Since this augmented BNF uses the basic production rules [RFC2616]. Since this augmented BNF uses the basic production rules
provided in Section 2.2 of HTTP, these rules apply to this document provided in Section 2.2 of HTTP, these rules apply to this document
as well. as well.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
designed to allow support to be added in the future for orderings designed to allow support to be added in the future for orderings
that are maintained automatically by the server. that are maintained automatically by the server.
The remainder of this document is structured as follows: section 3 The remainder of this document is structured as follows: section 3
defines terminology that will be used throughout the specification. defines terminology that will be used throughout the specification.
Section 4 provides an overview of ordered collections. Section 5 Section 4 provides an overview of ordered collections. Section 5
describes how to create an ordered collection, and section 6 describes how to create an ordered collection, and section 6
discusses how to set a member's position in the ordering of a discusses how to set a member's position in the ordering of a
collection. Section 7 explains how to change a collection ordering. collection. Section 7 explains how to change a collection ordering.
Section 8 discusses listing the members of an ordered collection. Section 8 discusses listing the members of an ordered collection.
section 9 discusses the impact on version-controlled collections (as Section 9 discusses the impact on version-controlled collections (as
defined in [RFC3253]. Section 10 describes capability discovery. defined in [RFC3253]. Section 10 describes capability discovery.
Section 11 through section 13 discuss security, internationalization, Section 11 through section 13 discuss security, internationalization,
and IANA considerations. The remaining sections provide supporting and IANA considerations. The remaining sections provide supporting
information. information.
3 Terminology 3 Terminology
The terminology used here follows that in [RFC2518]and [RFC3253]. The terminology used here follows that in [RFC2518]and [RFC3253].
Definitions of the terms resource, Uniform Resource Identifier (URI), Definitions of the terms resource, Uniform Resource Identifier (URI),
and Uniform Resource Locator (URL) are provided in [RFC2396]. and Uniform Resource Locator (URL) are provided in [RFC2396].
skipping to change at page 8, line 5 skipping to change at page 8, line 5
An ordering is considered to be part of the state of a collection An ordering is considered to be part of the state of a collection
resource. Consequently, the ordering is the same no matter which URI resource. Consequently, the ordering is the same no matter which URI
is used to access the collection and is protected by locks or access is used to access the collection and is protected by locks or access
control constraints on the collection. control constraints on the collection.
4.1 Additional Collection properties 4.1 Additional Collection properties
A DAV:allprop PROPFIND request SHOULD NOT return any of the A DAV:allprop PROPFIND request SHOULD NOT return any of the
properties defined in this document. properties defined in this document.
4.1.1 DAV:orderingtype (protected) 4.1.1 DAV:ordering-type (protected)
Indicates whether the collection is ordered and, if so, uniquely Indicates whether the collection is ordered and, if so, uniquely
identifies the semantics of the ordering being used. May also point identifies the semantics of the ordering being used. May also point
to an explanation of the semantics in human and / or machine-readable to an explanation of the semantics in human and / or machine-readable
form. At a minimum, this allows human users who add members to the form. At a minimum, this allows human users who add members to the
collection to understand where to position them in the ordering. This collection to understand where to position them in the ordering. This
property cannot be set using PROPPATCH. Its value can only be set by 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 including the Ordering-Type header with a MKCOL request or by
ORDERPATCH request. 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 Ordering types are identified by URIs that uniquely identify the
the semantics governing the ordering are not being advertised. semantics of the collection's ordering. Two following two URIs are
predefined:
If the value is a DAV:href element, it contains a URI that uniquely DAV:custom The value DAV:custom indicates that the collection is
identifies the semantics of the collection's ordering. ordered, but the semantics governing the ordering are
not being advertised.
DAV:unordered 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.
An ordering-aware client interacting with an ordering-unaware server An ordering-aware client interacting with an ordering-unaware server
(e.g., one that is implemented only according to [RFC2518]) SHOULD (e.g., one that is implemented only according to [RFC2518]) SHOULD
assume that if a collection does not have the DAV:orderingtype assume that if a collection does not have the DAV:ordering-type
property, the collection is unordered. property, the collection is unordered.
<!ELEMENT orderingtype (unordered | custom | href) > <!ELEMENT ordering-type (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 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 below) with a MKCOL request. Ordering-Type header (defined below) with a MKCOL request.
For collections that are ordered, the client SHOULD identify the For collections that are ordered, the client SHOULD identify the
semantics of the ordering with a URI in the Ordered header, although semantics of the ordering with a URI in the Ordering-Type header,
the client MAY simply set the header value to DAV:custom to indicate although the client MAY simply set the header value to DAV:custom to
that the collection is ordered but the semantics of the ordering are indicate that the collection is ordered but the semantics of the
not being advertised. Setting the value to a URI that identifies the ordering are not being advertised. Setting the value to a URI that
ordering semantics provides the information a human user or software identifies the ordering semantics provides the information a human
package needs to insert new collection members into the ordering user or software package needs to insert new collection members into
intelligently. Although the URI in the Ordered header MAY point to a the ordering intelligently. Although the URI in the Ordering-Type
resource that contains a definition of the semantics of the ordering, header MAY point to a resource that contains a definition of the
clients SHOULD NOT access that resource, in order to avoid semantics of the ordering, clients SHOULD NOT access that resource,
overburdening its server. A value of DAV:unordered in the Ordering in order to avoid overburdening its server. A value of DAV:unordered
header indicates that the client wants the collection to be in the Ordering-Type header indicates that the client wants the
unordered. If the Ordered header is not present, the collection will collection to be unordered. If the Ordering-Type header is not
be unordered. present, the collection will be unordered.
Additional Marshalling: Additional Marshalling:
Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url) Ordering-Type = "Ordering-Type" ":" absoluteURI
; absoluteURI: see RFC2396, section 3
A value of "DAV:unordered" indicates that the collection is not The URI "DAV:unordered" indicates that the collection is not
ordered. A value of "DAV:custom" indicates that the collection is ordered, while "DAV:custom" indicates that the collection is to be
to be ordered, but the semantics of the ordering is not being ordered, but the semantics of the ordering is not being
advertised. Any other Coded-url value indicates that the advertised. Any other URI value indicates that the collection is
collection is ordered, and identifies the semantics of the ordered, and identifies the semantics of the ordering.
ordering.
Additional Preconditions: Additional Preconditions:
(DAV:ordered-collections-supported): the server must support (DAV:ordered-collections-supported): the server must support
ordered collections where the new collection is to be created. ordered collections where the new collection is to be created.
Additional Postconditions: Additional Postconditions:
(DAV:orderdingtype-set): the collection was created with the (DAV:ordering-type-set): the collection was created with the
specified ordering semantics. specified ordering semantics.
5.2 Example: Creating an Ordered Collection 5.2 Example: Creating an Ordered Collection
>> Request: >> Request:
MKCOL /theNorth/ HTTP/1.1 MKCOL /theNorth/ HTTP/1.1
Host: example.org Host: example.org
Ordered: <http://example.org/orderings/compass.html> Ordering-Type: http://example.org/orderings/compass.html
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
In this example a new, ordered collection was created. Its In this example a new, ordered collection was created. Its
DAV:orderingtype property has as its value the URI from the Ordered DAV:ordering-type property has as its value the URI from the
header, http://example.org/orderings/compass.html. In this case, the Ordering-Type header, http://example.org/orderings/compass.html. In
URI identifies the semantics governing a client-maintained ordering. this case, the URI identifies the semantics governing a client-
As new members are added to the collection, clients or end users can maintained ordering. As new members are added to the collection,
use the semantics to determine where to position the new members in clients or end users can use the semantics to determine where to
the ordering. position the new members in the ordering.
6 Setting the Position of a Collection Member 6 Setting the Position of a Collection Member
6.1 Overview 6.1 Overview
When a new member is added to a collection with a client-maintained When a new member is added to a collection with a client-maintained
ordering (for example, with PUT, COPY, or MKCOL), its position in the ordering (for example, with PUT, COPY, or MKCOL), its position in the
ordering can be set with the new Position header. The Position header ordering can be set with the new Position header. The Position header
allows the client to specify that an internal member URI should be allows the client to specify that an internal member URI should be
first in the collection's ordering, last in the collection's first in the collection's ordering, last in the collection's
skipping to change at page 14, line 33 skipping to change at page 14, line 33
server assigned positions. server assigned positions.
If an ORDERPATCH request does not change the ordering semantics, any If an ORDERPATCH request does not change the ordering semantics, any
member positions not specified in the request MUST remain unchanged. member positions not specified in the request MUST remain unchanged.
A request to reposition a collection member at the same place in the A request to reposition a collection member at the same place in the
ordering is not an error. ordering is not an error.
Additional Marshalling: Additional Marshalling:
The request body MUST be DAV:order element. The request body MUST be DAV:orderpatch element.
<!ELEMENT order (orderingtype?, ordermember*) > <!ELEMENT orderpatch (ordering-type?, ordermember*) >
<!ELEMENT ordermember (href, position) > <!ELEMENT ordermember (segment, position) >
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
<!ELEMENT segment (#PCDATA)>
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
<!ELEMENT before segment > <!ELEMENT before segment >
<!ELEMENT after segment > <!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)>
PCDATA value: segment, as defined in section 3.3 of [RFC2396]. PCDATA value: segment, as defined in section 3.3 of [RFC2396].
DAV:href value: segment part of collection member. The DAV:ordering-type property is modified according to the
DAV:ordering-type element.
The DAV:orderingtype property is modified according to the
DAV:orderingtype element.
The ordering of internal member URIs in the collection identified The ordering of internal member URIs in the collection identified
by the Request-URI is changed based on instructions in the by the Request-URI is changed based on instructions in the
ordermember XML elements. The ordermember XML elements identify ordermember XML elements. The ordermember XML elements identify
the internal member URIs whose positions are to be changed, and the internal member URIs whose positions are to be changed, and
describe their new positions in the ordering. Each new position describe their new positions in the ordering. Each new position
can be specified as first in the ordering, last in the ordering, can be specified as first in the ordering, last in the ordering,
immediately before some other internal member URI, or immediately immediately before some other internal member URI, or immediately
after some other internal member URI. after some other internal member URI.
skipping to change at page 15, line 32 skipping to change at page 15, line 31
the DAV:orderpatch-response element is defined to ensure the DAV:orderpatch-response element is defined to ensure
interoperability between future extensions that do define elements interoperability between future extensions that do define elements
for the ORDERPATCH response body. for the ORDERPATCH response body.
<!ELEMENT orderpatch-response ANY> <!ELEMENT orderpatch-response ANY>
Since multiple changes can be requested in a single ORDERPATCH Since multiple changes can be requested in a single ORDERPATCH
request, if any problems are encountered, the server MUST return a request, if any problems are encountered, the server MUST return a
207 (Multi-Status) response (defined in [RFC2518]), containing 207 (Multi-Status) response (defined in [RFC2518]), containing
DAV:response elements for either the request-URI (when the DAV:response elements for either the request-URI (when the
DAV:orderingtype could not be modified) or URIs of collection DAV:ordering-type could not be modified) or URIs of collection
members to be repositioned (when an invidual positioning request members to be repositioned (when an individual positioning request
expressed as DAV:ordermember could not be fulfilled). expressed as DAV:ordermember could not be fulfilled).
Preconditions: Preconditions:
(DAV:collection-must-be-ordered): see section 6.1. (DAV:collection-must-be-ordered): see section 6.1.
(DAV:segment-must-identify-member): see section 6.1. (DAV:segment-must-identify-member): see section 6.1.
Postconditions: Postconditions:
(DAV:orderdingtype-set): if the request body contained a (DAV:orderding-type-set): if the request body contained a
DAV:orderingtype element, the DAV:orderingtype property (see DAV:ordering-type element, the DAV:ordering-type property (see
section 4.1.1) of the collection identified by the request-URI was section 4.1.1) of the collection identified by the request-URI was
set accordingly. set accordingly.
(DAV:orderding-modified): if the request body contained (DAV:orderding-modified): if the request body contained
DAV:ordermember elements, the ordering of internal member URIs in DAV:ordermember elements, the ordering of internal member URIs in
the collection identified by the request-URI has been changed the collection identified by the request-URI has been changed
based on instructions in the DAV:ordermember elements. based on instructions in the DAV:ordermember elements.
7.1 Example: Changing a Collection Ordering 7.1 Example: Changing a Collection Ordering
Consider a collection /coll-1/ whose DAV:orderingtype is DAV:whim, Consider a collection /coll-1/ whose DAV:ordering-type is DAV:whim,
with bindings ordered as follows: with bindings ordered as follows:
three.html three.html
four.html four.html
one.html one.html
two.html two.html
>> Request: >> Request:
ORDERPATCH /coll-1/ HTTP/1.1 ORDERPATCH /coll-1/ HTTP/1.1
Host: example.org Host: example.org
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<d:order xmlns:d="DAV:"> <d:orderpatch xmlns:d="DAV:">
<d:orderingtype> <d:ordering-type>
<d:href>http://example.org/inorder.ord</d:href> <d:href>http://example.org/inorder.ord</d:href>
</d:orderingtype> </d:ordering-type>
<d:ordermember> <d:ordermember>
<d:href>two.html</d:href> <d:segment>two.html</d:segment>
<d:position> <d:position><d:first/></d:position>
<d:first/>
</d:position>
</d:ordermember> </d:ordermember>
<d:ordermember> <d:ordermember>
<d:href>one.html</d:href> <d:segment>one.html</d:segment>
<d:position> <d:position><d:first/></d:position>
<d:first/>
</d:position>
</d:ordermember> </d:ordermember>
<d:ordermember> <d:ordermember>
<d:href>three.html</d:href> <d:segment>three.html</d:segment>
<d:position> <d:position><d:last/></d:position>
<d:last/>
</d:position>
</d:ordermember> </d:ordermember>
<d:ordermember> <d:ordermember>
<d:href>four.html</d:href> <d:segment>four.html</d:segment>
<d:position> <d:position><d:last/></d:position>
<d:last/>
</d:position>
</d:ordermember> </d:ordermember>
</d:order> </d:orderpatch>
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
In this example, after the request has been processed, the In this example, after the request has been processed, the
collection's ordering semantics are identified by the URI collection's ordering semantics are identified by the URI
http://example.org/inorder.ord. The value of the collection's http://example.org/inorder.ord. The value of the collection's
DAV:orderingtype property has been set to this URI. The request also DAV:ordering-type property has been set to this URI. The request also
contains instructions for changing the positions of the collection's contains instructions for changing the positions of the collection's
internal member URIs in the ordering to comply with the new ordering internal member URIs in the ordering to comply with the new ordering
semantics. If href elements are relative URIs, as in this example, semantics. If href elements are relative URIs, as in this example,
they are interpreted relative to the collection whose ordering is they are interpreted relative to the collection whose ordering is
being modified. The DAV:ordermember elements are required to be being modified. The DAV:ordermember elements are required to be
processed in the order they appear in the request. Consequently, processed in the order they appear in the request. Consequently,
two.html is moved to the beginning of the ordering, and then one.html 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 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 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 of the ordering. After the request has been processed, the
skipping to change at page 18, line 27 skipping to change at page 18, line 23
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; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<d:order xmlns:d="DAV:"> <d:orderpatch xmlns:d="DAV:">
<d:ordermember> <d:ordermember>
<d:href>nunavut.desc</d:href> <d:segment>nunavut.desc</d:segment>
<d:position> <d:position>
<d:after> <d:after>
<d:segment>nunavut.map</d:segment> <d:segment>nunavut.map</d:segment>
</d:after> </d:after>
</d:position> </d:position>
</d:ordermember> </d:ordermember>
<d:ordermember> <d:ordermember>
<d:href>iqaluit.map</d:href> <d:segment>iqaluit.map</d:segment>
<d:position> <d:position>
<d:after> <d:after>
<d:segment>pangnirtung.img</d:segment> <d:segment>pangnirtung.img</d:segment>
</d:after> </d:after>
</d:position> </d:position>
</d:ordermember> </d:ordermember>
</d:order> </d:orderpatch>
>> Response: >> Response:
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
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/iqaluit.map</d:href> <d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
<d:status>HTTP/1.1 403 Forbidden</d:status> <d:status>HTTP/1.1 403 Forbidden</d:status>
<d:responsedescription> <d:responsedescription>
<d:error><d:segment-must-identify-member/></d:error> <d:error><d:segment-must-identify-member/></d:error>
pangnirtung.img is not a collection member. pangnirtung.img is not a collection member.
</d:responsedescription> </d:responsedescription>
</d:response> </d:response>
skipping to change at page 21, line 22 skipping to change at page 21, line 22
PROPFIND /MyColl/ HTTP/1.1 PROPFIND /MyColl/ HTTP/1.1
Host: example.org Host: example.org
Depth: 1 Depth: 1
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop xmlns:J="http://example.org/jsprops/"> <D:prop xmlns:J="http://example.org/jsprops/">
<D:orderingtype/> <D:ordering-type/>
<D:resourcetype/> <D:resourcetype/>
<J:latitude/> <J:latitude/>
</D:prop> </D:prop>
</D:propfind> </D:propfind>
>> Response: >> Response:
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:" <D:multistatus xmlns:D="DAV:"
xmlns:J="http://example.org/jsprops/"> xmlns:J="http://example.org/jsprops/">
<D:response> <D:response>
<D:href>http://example.org/MyColl/</D:href> <D:href>http://example.org/MyColl/</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:orderingtype><D:custom/></D:orderingtype> <D:ordering-type>
<D:href>DAV:custom</D:href>
</D:ordering-type>
<D:resourcetype><D:collection/></D:resourcetype> <D:resourcetype><D:collection/></D:resourcetype>
</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:propstat>
<D:prop> <D:prop>
<J:latitude/> <J:latitude/>
</D:prop> </D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
skipping to change at page 22, line 21 skipping to change at page 22, line 23
<D:href>http://example.org/MyColl/lakehazen.html</D:href> <D:href>http://example.org/MyColl/lakehazen.html</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<J:latitude>82N</J:latitude> <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:propstat>
<D:prop> <D:prop>
<D:orderingtype/> <D:ordering-type/>
</D:prop> </D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href <D:href
>http://example.org/MyColl/siorapaluk.html</D:href> >http://example.org/MyColl/siorapaluk.html</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<J:latitude>78N</J:latitude> <J:latitude>78N</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:propstat>
<D:prop> <D:prop>
<D:orderingtype/> <D:ordering-type/>
</D:prop> </D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://example.org/MyColl/iqaluit.html</D:href> <D:href>http://example.org/MyColl/iqaluit.html</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<J:latitude>62N</J:latitude> <J:latitude>62N</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:propstat>
<D:prop> <D:prop>
<D:orderingtype/> <D:ordering-type/>
</D:prop> </D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://example.org/MyColl/newyork.html</D:href> <D:href>http://example.org/MyColl/newyork.html</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<J:latitude>45N</J:latitude> <J:latitude>45N</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:prop> <D:prop>
<D:orderingtype/> <D:ordering-type/>
</D:prop> </D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
In this example, the server responded with a list of the collection In this example, the server responded with a list of the collection
members in the order defined for the collection. members in the order defined for the collection.
9 Relationship to versioned collections 9 Relationship to versioned collections
The Versioning Extensions to WebDAV [RFC3253] introduce the concept The Versioning Extensions to WebDAV [RFC3253] introduce the concept
of versioned collections, recording both the dead properties and the of versioned collections, recording both the dead properties and the
set of internal version-controlled bindings. This section defines how set of internal version-controlled bindings. This section defines how
this feature interacts with ordered collections. this feature interacts with ordered collections.
This specification considers both the ordering type (DAV:orderingtype This specification considers both the ordering type (DAV:ordering-
property) and the ordering of collection members to be part of the type property) and the ordering of collection members to be part of
state of a collection. Therefore both MUST be recorded upon CHECKIN the state of a collection. Therefore both MUST be recorded upon
or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT,
UNCHECKOUT or UPDATE (where for compatibility with RFC3253, only the UNCHECKOUT or UPDATE (where for compatibility with RFC3253, only the
ordering of version-controlled members needs to be maintained). ordering of version-controlled members needs to be maintained).
9.1 Additional semantics for collection version properties 9.1 Additional semantics for collection version properties
Although this specification defines the property DAV:orderingtype to Although this specification defines the property DAV:ordering-type to
be protected, it MUST be recorded in a collection version. be protected, it MUST be recorded in a collection version.
The property DAV:version-controlled-binding-set ([RFC3253], section The property DAV:version-controlled-binding-set ([RFC3253], section
14.2.1) records the set of version-controlled bindings in the 14.2.1) records the set of version-controlled bindings in the
collection. For ordered collections, the DAV:version-controlled- collection. For ordered collections, the DAV:version-controlled-
binding elements MUST appear in the ordering defined for the checked- binding elements MUST appear in the ordering defined for the checked-
in ordered collection. in ordered collection.
10 Capability Discovery 10 Capability Discovery
Sections 9.1 and 15 of [RFC2518] describe the use of compliance Sections 9.1 and 15 of [RFC2518] describe the use of compliance
classes with the DAV header in responses to OPTIONS, to indicate classes with the DAV header in responses to OPTIONS, to indicate
which parts of the Web Distributed Authoring protocols the resource which parts of the Web Distributed Authoring protocols the resource
supports. This specification defines an OPTIONAL extension to supports. This specification defines an OPTIONAL extension to
[RFC2518]. It defines a new compliance class, called orderedcoll, for [RFC2518]. It defines a new compliance class, called ordered-
use with the DAV header in responses to OPTIONS requests. If a collections, for use with the DAV header in responses to OPTIONS
collection resource does support ordering, its response to an OPTIONS requests. If a collection resource does support ordering, its
request may indicate that it does, by listing the new ORDERPATCH response to an OPTIONS request may indicate that it does, by listing
method as one it supports, and by listing the new orderedcoll the new ORDERPATCH method as one it supports, and by listing the new
compliance class in the DAV header. ordered-collections compliance class in the DAV header.
When responding to an OPTIONS request, only a collection or a null When responding to an OPTIONS request, only a collection or a null
resource can include orderedcoll in the value of the DAV header. By resource can include ordered-collections in the value of the DAV
including orderedcoll, the resource indicates that its internal header. By including ordered-collections, the resource indicates that
member URIs can be ordered. It implies nothing about whether any its internal member URIs can be ordered. It implies nothing about
collections identified by its internal member URIs can be ordered. whether any collections identified by its internal member URIs can be
ordered.
Furthermore, RFC 3253 [RFC3253] introduces the live properties Furthermore, RFC 3253 [RFC3253] introduces the live properties
DAV:supported-method-set (section 3.1.3) and DAV:supported-live- DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
property-set (section 3.1.4). Servers MUST support these properties property-set (section 3.1.4). Servers MUST support these properties
as defined in RFC 3253. as defined in RFC 3253.
10.1 Example: Using OPTIONS for the Discovery of Support for Ordering 10.1 Example: Using OPTIONS for the Discovery of Support for Ordering
>> Request: >> Request:
OPTIONS /somecollection/ HTTP/1.1 OPTIONS /somecollection/ HTTP/1.1
Host: example.org Host: example.org
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
DAV: 1, 2, orderedcoll DAV: 1, 2, ordered-collections
The DAV header in the response indicates that the resource The DAV header in the response indicates that the resource
/somecollection/ is level 1 and level 2 compliant, as defined in /somecollection/ is level 1 and level 2 compliant, as defined in
[RFC2518]. In addition, /somecollection/ supports ordering. The Allow [RFC2518]. In addition, /somecollection/ supports ordering. The Allow
header indicates that ORDERPATCH requests can be submitted to header indicates that ORDERPATCH requests can be submitted to
/somecollection/. /somecollection/.
10.2 Example: Using Live Properties for the Discovery of Ordering 10.2 Example: Using Live Properties for the Discovery of Ordering
>> Request: >> Request:
skipping to change at page 26, line 38 skipping to change at page 26, line 39
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:"> <multistatus xmlns="DAV:">
<response> <response>
<href>http://example.org/somecollection</href> <href>http://example.org/somecollection</href>
<propstat> <propstat>
<prop> <prop>
<supported-live-property-set> <supported-live-property-set>
<supported-live-property> <supported-live-property>
<prop><orderingtype/></prop> <prop><ordering-type/></prop>
</supported-live-property> </supported-live-property>
... other live properties omitted for brevity ... <!-- ... other live properties omitted for brevity ... -->
</supported-live-property-set> </supported-live-property-set>
<supported-method-set> <supported-method-set>
<supported-method name="COPY" /> <supported-method name="COPY" />
<supported-method name="DELETE" /> <supported-method name="DELETE" />
<supported-method name="GET" /> <supported-method name="GET" />
<supported-method name="HEAD" /> <supported-method name="HEAD" />
<supported-method name="LOCK" /> <supported-method name="LOCK" />
<supported-method name="MKCOL" /> <supported-method name="MKCOL" />
<supported-method name="MOVE" /> <supported-method name="MOVE" />
<supported-method name="OPTIONS" /> <supported-method name="OPTIONS" />
skipping to change at page 28, line 15 skipping to change at page 28, line 15
11 Security Considerations 11 Security Considerations
This section is provided to make WebDAV applications aware of the This section is provided to make WebDAV applications aware of the
security implications of this protocol. security implications of this protocol.
All of the security considerations of HTTP/1.1 and the WebDAV All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this Distributed Authoring Protocol specification also apply to this
protocol specification. In addition, ordered collections introduce a protocol specification. In addition, ordered collections introduce a
new security concern. This issue is detailed here. new security concern. This issue is detailed here.
11.1 Denial of Service and DAV:orderingtype 11.1 Denial of Service and DAV:ordering-type
There may be some risk of denial of service at sites that are There may be some risk of denial of service at sites that are
advertised in the DAV:orderingtype property of collections. However, advertised in the DAV:ordering-type property of collections. However,
it is anticipated that widely-deployed applications will use hard- it is anticipated that widely-deployed applications will use hard-
coded values for frequently-used ordering semantics rather than coded values for frequently-used ordering semantics rather than
looking up the semantics at the location specified by looking up the semantics at the location specified by DAV:ordering-
DAV:orderingtype. This risk will be further reduced if clients type. This risk will be further reduced if clients observe the
observe the recommendation of section 5.1 that they not send requests recommendation of section 5.1 that they not send requests to the URI
to the URI in DAV:orderingtype. in DAV:ordering-type.
12 Internationalization Considerations 12 Internationalization Considerations
This specification follows the practices of [RFC2518] in encoding all This specification follows the practices of [RFC2518] in encoding all
human-readable content using [XML] and in the treatment of names. human-readable content using [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set Consequently, this specification complies with the IETF Character Set
Policy [RFC2277]. Policy [RFC2277].
WebDAV applications MUST support the character set tagging, character WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML set encoding, and the language tagging functionality of the XML
skipping to change at page 34, line 29 skipping to change at page 34, line 29
WEBDAV", RFC 2518, February 1999. WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and Berners-Lee, T., "Hypertext Masinter, L., Leach, P. and Berners-Lee, T., "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and
Whitehead, J., "Versioning Extensions to WebDAV", RFC Whitehead, J., "Versioning Extensions to WebDAV", RFC
3253, March 2002. 3253, March 2002.
[XML] World Wide Web Consortium, "Extensible Markup Language [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and Maler, E.,
(XML) 1.0", W3C XML, February 1998. "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
xml, October 2000.
Author's Addresses Author's Addresses
Judith Slein Judith 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
skipping to change at page 36, line 7 skipping to change at page 36, line 7
Muenster, NW 48159 Muenster, NW 48159
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
A Extensions to the WebDAV Document Type Definition A Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 11 ================--> <!ELEMENT orderpatch (ordering-type?, ordermember*) >
<!ELEMENT unordered EMPTY > <!ELEMENT ordermember (segment, position) >
<!ELEMENT custom EMPTY > <!ELEMENT ordering-type (href) >
<!ELEMENT order (orderingtype?, ordermember*) >
<!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 segment > <!ELEMENT before segment >
<!ELEMENT after segment > <!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
<!--============= Property Elements from Section 10 =============-->
<!ELEMENT orderingtype (unordered | custom | href) >
B Change Log B Change Log
B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999 B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999
Updated contact information for all previous authors. Updated contact information for all previous authors.
Specify charset when using text/xml media type. Specify charset when using text/xml media type.
Made sure artwork fits into 72 columns. Made sure artwork fits into 72 columns.
Removed "Public" header from OPTIONS example. Removed "Public" header from OPTIONS example.
Added Julian Reschke to list of authors. Added Julian Reschke to list of authors.
skipping to change at page 37, line 47 skipping to change at page 37, line 47
Removed Jim Davis and Chuck Fay from the author list (and added them Removed Jim Davis and Chuck Fay from the author list (and added them
to the Acknowledgements section). to the Acknowledgements section).
Updated section on setting the position when adding new members, Updated section on setting the position when adding new members,
removed old section on Position header. removed old section on Position header.
Started work on Index section. Started work on Index section.
Changed structure for section 7 (no change tracking). Changed structure for section 7 (no change tracking).
Removed header and XML elements section (contents moved to other Removed header and XML elements section (contents moved to other
sections). sections).
Started new section on relation to versioned collections as per Started new section on relation to versioned collections as per
RFC3253. RFC3253.
Do not return 424's for in ODERPATCH multistatus (it's atomic Do not return 424's for in ORDERPATCH multistatus (it's atomic
anyway). anyway).
B.4 Since draft-ietf-webdav-ordering-protocol-04
Added proper reference to definition of "Coded-URL".
Closed issue ordering-type-values (content model simplified and XML
element / DAV property renamed) and updated examples.
Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set
(no change tracking).
Closed issue ordered-header-name (header name changed to "ordering-
type", contents matches live property).
Closed issue ordermember-format (now takes segment instead of href).
Renamed compliance class to "ordered-collections" for consistency
with newer specs, and to allow detection of compliance to final
version of spec.
Updated reference to XML spec to 1.0, 2nd edition.
Index Index
C O C
Client-Maintained Ordering Ordered Collection Client-Maintained Ordering
3 3 3
Ordered header
5.1
ORDERPATCH method
D 7
DAV:collection-must-be-ordered D
precondition P
DAV:collection-must-be-ordered precondition
6.1 6.1
DAV:custom ordering type DAV:custom ordering type
4.1.1 Postconditions 4.1.1
DAV:ordered-collections- DAV:orderingtype-set 5.1,7 DAV:ordered-collections-supported precondition
supported precondition DAV:position-set 6.1 5.1
5.1 DAV:orderingtype-set 5.1,7 DAV:ordering-modified postcondition
DAV:ordering-modified DAV:ordering-modified 7 7
postcondition DAV:ordering-type property
7 Preconditions 4.1.1
DAV:orderingtype property DAV:ordered-collections- DAV:ordering-type-set postcondition
4.1.1 supported 5.1 5.1, 7
DAV:orderingtype-set DAV:collection-must-be- DAV:position-set postcondition
postcondition ordered 6.1
5.1,7 DAV:segment-must-identify-
DAV:position-set postcondition member 6.1
6.1 6.1
DAV:segment-must-identify- Protected properties DAV:segment-must-identify-member precondition
member precondition DAV:orderingtype 4.1.1
6.1 6.1
DAV:unordered ordering type DAV:unordered ordering type
4.1.1 4.1.1
H
Headers
Ordering-Type 5.1
O
Ordered Collection
3
Ordering-Type header
5.1
ORDERPATCH method
7
P
Postconditions
DAV:ordering-type-set 5.1, 7
DAV:position-set 6.1
DAV:ordering-type-set 5.1, 7
DAV:ordering-modified 7
Preconditions
DAV:ordered-collections-supported 5.1
DAV:collection-must-be-ordered 6.1
DAV:segment-must-identify-member 6.1
Protected properties
DAV:ordering-type 4.1.1
S S
H
Server-Maintained Ordering Server-Maintained Ordering
3 3
Headers
Ordered 5.1
U U
Unordered Collection Unordered Collection
3 3
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
 End of changes. 

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