draft-ietf-webdav-ordering-protocol-05.txt   draft-ietf-webdav-ordering-protocol-06.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet Draft Xerox Internet Draft Xerox
Expires: August 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
February 2003 February 2003
WebDAV Ordered Collections Protocol WebDAV Ordered Collections Protocol
draft-ietf-webdav-ordering-protocol-05 draft-ietf-webdav-ordering-protocol-06
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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
w3c-dist-auth@w3.org, which may be joined by sending a message with w3c-dist-auth@w3.org, which may be joined by sending a message with
subject "subscribe" to w3c-dist-auth-request@w3.org. subject "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/.
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 . . . . . . . . . . . . . . . . . . . 5
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Overview of Ordered Collections . . . . . . . . . . . . . . 7 4 Overview of Ordered Collections . . . . . . . . . . . . . . 8
4.1 Additional Collection properties . . . . . . . . . . . . 7 4.1 Additional Collection properties . . . . . . . . . . . . 8
4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . 8 4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . 9
5 Creating an Ordered Collection . . . . . . . . . . . . . . . 9 5 Creating an Ordered Collection . . . . . . . . . . . . . . . 10
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Example: Creating an Ordered Collection . . . . . . . . 10 5.2 Example: Creating an Ordered Collection . . . . . . . . 11
6 Setting the Position of a Collection Member . . . . . . . . 11 6 Setting the Position of a Collection Member . . . . . . . . 12
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Examples: Setting the Position of a Collection Member . 12 6.2 Examples: Setting the Position of a Collection Member . 13
7 Changing a Collection Ordering: ORDERPATCH method . . . . . 14 7 Changing a Collection Ordering: ORDERPATCH method . . . . . 15
7.1 Example: Changing a Collection Ordering . . . . . . . . 16 7.1 Example: Changing a Collection Ordering . . . . . . . . 17
7.2 Example: Failure of an ORDERPATCH Request . . . . . . . 17 7.2 Example: Failure of an ORDERPATCH Request . . . . . . . 18
8 Listing the Members of an Ordered Collection . . . . . . . . 20 8 Listing the Members of an Ordered Collection . . . . . . . . 21
8.1 Example: PROPFIND on an Ordered Collection . . . . . . . 20 8.1 Example: PROPFIND on an Ordered Collection . . . . . . . 21
9 Relationship to versioned collections . . . . . . . . . . . 24 9 Relationship to versioned collections . . . . . . . . . . . 25
9.1 Additional semantics for collection version properties . 24 9.1 Collection Version Properties . . . . . . . . . . . . . 25
10 Capability Discovery . . . . . . . . . . . . . . . . . . . 25 9.1.1 Additional semantics for DAV:version-controlled-
binding-set (protected) . . . . . . . . . . . . . . . . . . . 25
9.1.2 DAV:ordering-type (protected) . . . . . . . . . . . 25
9.2 Additional CHECKIN semantics . . . . . . . . . . . . . . 25
9.3 Additional CHECKOUT Semantics . . . . . . . . . . . . . 26
9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . 26
10 Capability Discovery . . . . . . . . . . . . . . . . . . . 27
10.1 Example: Using OPTIONS for the Discovery of Support for 10.1 Example: Using OPTIONS for the Discovery of Support for
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2 Example: Using Live Properties for the Discovery of 10.2 Example: Using Live Properties for the Discovery of
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11 Security Considerations . . . . . . . . . . . . . . . . . . 28 11 Security Considerations . . . . . . . . . . . . . . . . . . 30
11.1 Denial of Service and DAV:ordering-type . . . . . . . . 28 11.1 Denial of Service and DAV:ordering-type . . . . . . . . 30
12 Internationalization Considerations . . . . . . . . . . . . 29 12 Internationalization Considerations . . . . . . . . . . . . 31
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
14 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 31 14 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 33
15 Intellectual Property . . . . . . . . . . . . . . . . . . . 32 15 Intellectual Property . . . . . . . . . . . . . . . . . . . 34
16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 35
Normative References . . . . . . . . . . . . . . . . . . . . . 34 Normative References . . . . . . . . . . . . . . . . . . . . . 36
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 34 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 36
A Extensions to the WebDAV Document Type Definition . . . . . 36 A Extensions to the WebDAV Document Type Definition . . . . . 38
B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.1 Since draft-ietf-webdav-ordering-protocol dated December B.1 Since draft-ietf-webdav-ordering-protocol dated December
1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . 37 B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . 39
B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . 37 B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . 39
B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . 38 B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 B.5 Since draft-ietf-webdav-ordering-protocol-05 . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1 Notational Conventions 1 Notational Conventions
Since this document describes a set of extensions to the WebDAV Since this document describes a set of extensions to the WebDAV
Distributed Authoring Protocol [RFC2518], itself an extension to the Distributed Authoring Protocol [RFC2518], itself an extension to the
HTTP/1.1 protocol, the augmented BNF used here to describe protocol HTTP/1.1 protocol, the augmented BNF used here to describe protocol
elements is exactly the same as described in Section 2.1 of HTTP elements is exactly the same as described in Section 2.1 of HTTP
[RFC2616]. Since this augmented BNF uses the basic production rules [RFC2616]. Since this augmented BNF uses the basic production rules
provided in Section 2.2 of HTTP, these rules apply to this document provided in Section 2.2 of HTTP, these rules apply to this document
as well. as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses XML DTD fragments as a purely notational
convention. WebDAV request and response bodies can not be validated
due to the specific extensibility rules defined in section 23 of
[RFC2518] and due to the fact that all XML elements defined by this
specification use the XML namespace name "DAV:". In particular:
1. element names use the "DAV:" namespace,
2. element ordering is irrelevant,
3. extension elements (elements not already defined as valid child
elements) may be added anywhere, except when explicitly stated
otherwise,
4. extension attributes (attributes not already defined as valid for
this element) may be added anywhere, except when explicitly stated
otherwise.
2 Introduction 2 Introduction
This specification builds on the collection infrastructure provided This specification builds on the collection infrastructure provided
by the WebDAV Distributed Authoring Protocol, adding support for the by the WebDAV Distributed Authoring Protocol, adding support for the
server-side ordering of collection members. server-side ordering of collection members.
There are many scenarios where it is useful to impose an ordering on There are many scenarios where it is useful to impose an ordering on
a collection at the server, such as expressing a recommended access a collection at the server, such as expressing a recommended access
order, or a revision history order. The members of a collection might order, or a revision history order. The members of a collection might
represent the pages of a book, which need to be presented in order if represent the pages of a book, which need to be presented in order if
skipping to change at page 6, line 32 skipping to change at page 7, line 32
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
This document uses the terms "precondition" as "postcondition" as This document uses the terms "precondition", "postcondition" and
defined in [RFC3253]. Servers should report pre-/postcondition "protected property" as defined in [RFC3253]. Servers MUST report
failures as described in section 1.6 of this document. pre-/postcondition failures as described in section 1.6 of this
document.
4 Overview of Ordered Collections 4 Overview of Ordered Collections
If a collection is unordered, the client cannot depend on the If a collection is unordered, the client cannot depend on the
repeatability of the ordering of results from a PROPFIND request. By repeatability of the ordering of results from a PROPFIND request. By
specifying an ordering for a collection, a client requires the server specifying an ordering for a collection, a client requires the server
to follow that ordering whenever it responds to a PROPFIND request on to follow that ordering whenever it responds to a PROPFIND request on
that collection. that collection.
Server-side orderings may be client-maintained or server-maintained. Server-side orderings may be client-maintained or server-maintained.
skipping to change at page 8, line 17 skipping to change at page 9, line 17
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 Ordering-Type header with a MKCOL request or by including the Ordering-Type header with a MKCOL request or by
submitting an ORDERPATCH request. submitting an ORDERPATCH request.
Ordering types are identified by URIs that uniquely identify the Ordering types are identified by URIs that uniquely identify the
semantics of the collection's ordering. Two following two URIs are semantics of the collection's ordering. The following two URIs are
predefined: predefined:
DAV:custom The value DAV:custom indicates that the collection is DAV:custom The value DAV:custom indicates that the collection is
ordered, but the semantics governing the ordering are ordered, but the semantics governing the ordering are
not being advertised. not being advertised.
DAV:unordered The value DAV:unordered indicates that the collection DAV:unordered The value DAV:unordered indicates that the collection
is not ordered. That is, the client cannot depend on is not ordered. That is, the client cannot depend on
the repeatability of the ordering of results from a the repeatability of the ordering of results from a
PROPFIND request. PROPFIND request.
skipping to change at page 9, line 41 skipping to change at page 10, line 41
; absoluteURI: see RFC2396, section 3 ; absoluteURI: see RFC2396, section 3
The URI "DAV:unordered" indicates that the collection is not The URI "DAV:unordered" indicates that the collection is not
ordered, while "DAV:custom" indicates that the collection is to be ordered, while "DAV:custom" indicates that the collection is to be
ordered, but the semantics of the ordering is not being ordered, but the semantics of the ordering is not being
advertised. Any other URI value indicates that the collection is advertised. Any other URI value indicates that the collection is
ordered, and identifies the semantics of the ordering. ordered, and identifies the semantics of the ordering.
Additional Preconditions: Additional Preconditions:
(DAV:ordered-collections-supported): the server must support (DAV:ordered-collections-supported): the server MUST support
ordered collections where the new collection is to be created. ordered collections in the part of the URL namespace identified by
the request URL.
Additional Postconditions: Additional Postconditions:
(DAV:ordering-type-set): the collection was created with the (DAV:ordering-type-set): if the Ordering-Type header was present,
specified ordering semantics. the request MUST have created a new collection resource with the
DAV:ordering-type being set according to the Ordering-Type request
header. The collection MUST be ordered unless the ordering type
was "DAV:unordered".
5.2 Example: Creating an Ordered Collection 5.2 Example: Creating an Ordered Collection
>> Request: >> Request:
MKCOL /theNorth/ HTTP/1.1 MKCOL /theNorth/ HTTP/1.1
Host: example.org Host: example.org
Ordering-Type: http://example.org/orderings/compass.html Ordering-Type: http://example.org/orderings/compass.html
>> Response: >> Response:
skipping to change at page 11, line 38 skipping to change at page 12, line 38
Additional Marshalling: Additional Marshalling:
Position = "Position" ":" ("first" | "last" | Position = "Position" ":" ("first" | "last" |
(("before" | "after") segment)) (("before" | "after") segment))
segment is defined in Section 3.3 of [RFC2396]. segment is defined in Section 3.3 of [RFC2396].
The segment is interpreted relative to the collection to which the The segment is interpreted relative to the collection to which the
new member is being added. new member is being added.
The server MUST insert the new member into the ordering at the When the Position header is present, the server MUST insert the
location specified in the Position header, if one is present (and new member into the ordering at the specified location.
if the collection is ordered).
The "first" keyword indicates the new member is put in the The "first" keyword indicates the new member is put in the
beginning position in the collection's ordering, while "last" beginning position in the collection's ordering, while "last"
indicates the new member is put in the final position in the indicates the new member is put in the final position in the
collection's ordering. The "before" keyword indicates the new collection's ordering. The "before" keyword indicates the new
member is added to the collection's ordering immediately prior to member is added to the collection's ordering immediately prior to
the position of the member identified in the segment. Likewise, the position of the member identified in the segment. Likewise,
the "after" keyword indicates the new member is added to the the "after" keyword indicates the new member is added to the
collection's ordering immediately following the position of the collection's ordering immediately following the position of the
member identified in the segment. member identified in the segment.
If the request is replacing an existing resource, and the Position If the request is replacing an existing resource, and the Position
header is present, the server MUST remove the internal member URI header is present, the server MUST remove the internal member URI
from its previous position, and then insert it at the requested from its previous position, and then insert it at the requested
position. position.
Additional Preconditions: Additional Preconditions:
(DAV:collection-must-be-ordered): the target collection must be (DAV:collection-must-be-ordered): the target collection MUST be
ordered. ordered.
(DAV:segment-must-identify-member): the referenced segment must (DAV:segment-must-identify-member): the referenced segment MUST
identify a resource that exists and is different from the affected identify a resource that exists and is different from the affected
resource. resource.
Additional Postconditions: Additional Postconditions:
(DAV:position-set): the newly created collection member was (DAV:position-set): if a Position header was present, the request
created at the specified position. MUST have created the new collection member at the specified
position.
6.2 Examples: Setting the Position of a Collection Member 6.2 Examples: Setting the Position of a Collection Member
>> Request: >> Request:
COPY /~user/dav/spec08.html HTTP/1.1 COPY /~user/dav/spec08.html HTTP/1.1
Host: example.org Host: example.org
Destination: http://example.org/~slein/dav/spec08.html Destination: http://example.org/~slein/dav/spec08.html
Position: after requirements.html Position: after requirements.html
skipping to change at page 14, line 35 skipping to change at page 15, line 35
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:orderpatch element. The request body MUST be DAV:orderpatch element.
<!ELEMENT orderpatch (ordering-type?, ordermember*) > <!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT ordermember (segment, position) > <!ELEMENT order-member (segment, position) >
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
<!ELEMENT before segment > <!ELEMENT before segment >
<!ELEMENT after segment > <!ELEMENT after segment >
PCDATA value: segment, as defined in section 3.3 of [RFC2396]. PCDATA value: segment, as defined in section 3.3 of [RFC2396].
The DAV:ordering-type property is modified according to the The DAV:ordering-type property is modified according to the
DAV:ordering-type element. DAV:ordering-type element.
The ordering of internal member URIs in the collection identified The ordering of internal member URIs in the collection identified
by the Request-URI is changed based on instructions in the by the Request-URI is changed based on instructions in the order-
ordermember XML elements. The ordermember XML elements identify member XML elements in the order they appear in the request. The
the internal member URIs whose positions are to be changed, and order-member XML elements identify the internal member URIs whose
describe their new positions in the ordering. Each new position positions are to be changed, and describe their new positions in
can be specified as first in the ordering, last in the ordering, the ordering. Each new position can be specified as first in the
immediately before some other internal member URI, or immediately ordering, last in the ordering, immediately before some other
after some other internal member URI. internal member URI, or immediately after some other internal
member URI.
If a response body for a successful request is included, it MUST If a response body for a successful request is included, it MUST
be a DAV:orderpatch-response XML element. Note that this document be a DAV:orderpatch-response XML element. Note that this document
does not define any elements for the ORDERPATCH response body, but does not define any elements for the ORDERPATCH response body, but
the DAV:orderpatch-response element is defined to ensure the DAV:orderpatch-response element is defined to ensure
interoperability between future extensions that do define elements interoperability between future extensions that do define elements
for the ORDERPATCH response body. for the ORDERPATCH response body.
<!ELEMENT orderpatch-response ANY> <!ELEMENT orderpatch-response ANY>
Since multiple changes can be requested in a single ORDERPATCH Since multiple changes can be requested in a single ORDERPATCH
request, if any problems are encountered, the server MUST return a request, if any problems are encountered, the server MUST return a
207 (Multi-Status) response (defined in [RFC2518]), containing 207 (Multi-Status) response (defined in [RFC2518]), containing
DAV:response elements for either the request-URI (when the DAV:response elements for either the request-URI (when the
DAV:ordering-type could not be modified) or URIs of collection DAV:ordering-type could not be modified) or URIs of collection
members to be repositioned (when an individual positioning request members to be repositioned (when an individual positioning request
expressed as DAV:ordermember could not be fulfilled). expressed as DAV:order-member could not be fulfilled).
Preconditions: Preconditions:
(DAV:collection-must-be-ordered): see section 6.1. (DAV:collection-must-be-ordered): see section 6.1.
(DAV:segment-must-identify-member): see section 6.1. (DAV:segment-must-identify-member): see section 6.1.
Postconditions: Postconditions:
(DAV:orderding-type-set): if the request body contained a (DAV:ordering-type-set): if the request body contained a
DAV:ordering-type element, the DAV:ordering-type property (see DAV:ordering-type element, the request MUST have set the
section 4.1.1) of the collection identified by the request-URI was DAV:ordering-type property of the collection to the value
set accordingly. specified in the request.
(DAV:orderding-modified): if the request body contained (DAV:ordering-modified): if the request body contained DAV:order-
DAV:ordermember elements, the ordering of internal member URIs in member elements, the request MUST have set the ordering of
the collection identified by the request-URI has been changed internal member URIs in the collection identified by the request-
based on instructions in the DAV:ordermember elements. URI based on the instructions in the DAV:order-member elements.
7.1 Example: Changing a Collection Ordering 7.1 Example: Changing a Collection Ordering
Consider a collection /coll-1/ whose DAV:ordering-type is DAV:whim, Consider a collection /coll-1/ whose DAV:ordering-type is DAV:whim,
with bindings ordered as follows: with bindings ordered as follows:
three.html three.html
four.html four.html
one.html one.html
two.html two.html
skipping to change at page 16, line 34 skipping to change at page 17, line 37
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:orderpatch xmlns:d="DAV:"> <d:orderpatch xmlns:d="DAV:">
<d:ordering-type> <d:ordering-type>
<d:href>http://example.org/inorder.ord</d:href> <d:href>http://example.org/inorder.ord</d:href>
</d:ordering-type> </d:ordering-type>
<d:ordermember> <d:order-member>
<d:segment>two.html</d:segment> <d:segment>two.html</d:segment>
<d:position><d:first/></d:position> <d:position><d:first/></d:position>
</d:ordermember> </d:order-member>
<d:ordermember> <d:order-member>
<d:segment>one.html</d:segment> <d:segment>one.html</d:segment>
<d:position><d:first/></d:position> <d:position><d:first/></d:position>
</d:ordermember> </d:order-member>
<d:ordermember> <d:order-member>
<d:segment>three.html</d:segment> <d:segment>three.html</d:segment>
<d:position><d:last/></d:position> <d:position><d:last/></d:position>
</d:ordermember> </d:order-member>
<d:ordermember> <d:order-member>
<d:segment>four.html</d:segment> <d:segment>four.html</d:segment>
<d:position><d:last/></d:position> <d:position><d:last/></d:position>
</d:ordermember> </d:order-member>
</d:orderpatch> </d:orderpatch>
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
In this example, after the request has been processed, the In this example, after the request has been processed, the
collection's ordering semantics are identified by the URI collection's ordering semantics are identified by the URI
http://example.org/inorder.ord. The value of the collection's http://example.org/inorder.ord. The value of the collection's
DAV:ordering-type property has been set to this URI. The request also DAV:ordering-type property has been set to this URI. The request also
contains instructions for changing the positions of the collection's contains instructions for changing the positions of the collection's
internal member URIs in the ordering to comply with the new ordering internal member URIs in the ordering to comply with the new ordering
semantics. If href elements are relative URIs, as in this example, semantics. As the DAV:order-member elements are required to be
they are interpreted relative to the collection whose ordering is processed in the order they appear in the request, two.html is moved
being modified. The DAV:ordermember elements are required to be to the beginning of the ordering, and then one.html is moved to the
processed in the order they appear in the request. Consequently, beginning of the ordering. Then three.html is moved to the end of the
two.html is moved to the beginning of the ordering, and then one.html ordering, and finally four.html is moved to the end of the ordering.
is moved to the beginning of the ordering. Then three.html is moved After the request has been processed, the collection's ordering is as
to the end of the ordering, and finally four.html is moved to the end follows:
of the ordering. After the request has been processed, the
collection's ordering is as follows:
one.html one.html
two.html two.html
three.html three.html
four.html four.html
7.2 Example: Failure of an ORDERPATCH Request 7.2 Example: Failure of an ORDERPATCH Request
Consider a collection /coll-1/ with members ordered as follows: Consider a collection /coll-1/ with members ordered as follows:
skipping to change at page 18, line 24 skipping to change at page 19, line 24
>> 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:orderpatch xmlns:d="DAV:"> <d:orderpatch xmlns:d="DAV:">
<d:ordermember> <d:order-member>
<d:segment>nunavut.desc</d:segment> <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:order-member>
<d:ordermember> <d:order-member>
<d:segment>iqaluit.map</d:segment> <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:order-member>
</d:orderpatch> </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>
skipping to change at page 24, line 19 skipping to change at page 25, line 19
set of internal version-controlled bindings. This section defines how set of internal version-controlled bindings. This section defines how
this feature interacts with ordered collections. this feature interacts with ordered collections.
This specification considers both the ordering type (DAV:ordering- This specification considers both the ordering type (DAV:ordering-
type property) and the ordering of collection members to be part of type property) and the ordering of collection members to be part of
the state of a collection. Therefore both MUST be recorded upon the state of a collection. Therefore both MUST be recorded upon
CHECKIN 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 Collection Version Properties
Although this specification defines the property DAV:ordering-type to 9.1.1 Additional semantics for DAV:version-controlled-binding-set
be protected, it MUST be recorded in a collection version. (protected)
The property DAV:version-controlled-binding-set ([RFC3253], section For ordered collections, the DAV:version-controlled-binding elements
14.2.1) records the set of version-controlled bindings in the MUST appear in the ordering defined for the checked-in ordered
collection. For ordered collections, the DAV:version-controlled- collection.
binding elements MUST appear in the ordering defined for the checked-
in ordered collection. 9.1.2 DAV:ordering-type (protected)
The DAV:ordering-type property records the DAV:ordering-type property
of the checked-in ordered collection.
9.2 Additional CHECKIN semantics
Additional Postconditions:
(DAV:initialize-version-controlled-bindings-ordered): If the
request-URL identified a both ordered and version-controlled
collection, then the child elements of DAV:version-controlled-
binding-set of the new collection version MUST appear in the
ordering defined for that collection.
(DAV:initialize-collection-version-ordering-type): If the request-
URL identified a both ordered and version-controlled collection,
then the DAV:ordering-type property of the new collection version
MUST be a copy of the collection's DAV:ordering-type property.
9.3 Additional CHECKOUT Semantics
Additional Postconditions:
(DAV:initialize-version-history-bindings-ordered): If the request
has been applied to a collection version with a DAV:ordering-type
other than "DAV:unordered", the bindings in the new working
collection MUST be ordered according to the collection version's
DAV:version-controlled-binding-set property.
(DAV:initialize-ordering-type): If the request has been applied to
a collection version, the DAV:ordering-type property of the new
working collection MUST be initialized from the collection
version's DAV:ordering-type property.
9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics
Additional Postconditions:
(DAV:update-version-controlled-collection-members-ordered): If the
request modified the DAV:checked-in version of a version-
controlled collection and the DAV:ordering-type for the checked-in
version is not unordered ("DAV:unordered"), the version-controlled
members MUST be ordered according to the checked-in version's
DAV:version-controlled-binding-set property.
(DAV:update-version-ordering-type): If the request modified the
DAV:checked-in version of a version-controlled collection, the
DAV:ordering-type property MUST be updated from the checked-in
version's property.
10 Capability Discovery 10 Capability Discovery
Sections 9.1 and 15 of [RFC2518] describe the use of compliance Sections 9.1 and 15 of [RFC2518] describe the use of compliance
classes with the DAV header in responses to OPTIONS, to indicate classes with the DAV header in responses to OPTIONS, to indicate
which parts of the Web Distributed Authoring protocols the resource which parts of the Web Distributed Authoring protocols the resource
supports. This specification defines an OPTIONAL extension to supports. This specification defines an OPTIONAL extension to
[RFC2518]. It defines a new compliance class, called ordered- [RFC2518]. It defines a new compliance class, called ordered-
collections, for use with the DAV header in responses to OPTIONS collections, for use with the DAV header in responses to OPTIONS
requests. If a collection resource does support ordering, its requests. If a collection resource does support ordering, its
skipping to change at page 33, line 10 skipping to change at page 35, line 10
15 Intellectual Property 15 Intellectual Property
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
16 Acknowledgements 16 Acknowledgements
This draft has benefited from thoughtful discussion by Jim Amsden, This draft has benefited from thoughtful discussion by Jim Amsden,
Steve Carter, Tyson Chihaya, Geoff Clemm, Ken Coar, Ellis Cohen, Steve Carter, Tyson Chihaya, Geoff Clemm, Ken Coar, Ellis Cohen,
Bruce Cragun, Jim Davis, Spencer Dawkins, Mark Day, Rajiv Dulepet, Bruce Cragun, Jim Davis, Spencer Dawkins, Mark Day, Rajiv Dulepet,
David Durand, Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex David Durand, Lisa Dusseault, Chuck Fay, Roy Fielding, Yaron Goland,
Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj
Daniel LaLiberte, Lisa Lippert, Steve Martin, Larry Masinter, Jeff Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry
McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby,
Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John
Wiggen, and others. Turner, Kevin Wiggen, and others.
Normative References Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R.T. and Masinter, L., "Uniform [RFC2396] Berners-Lee, T., Fielding, R.T. and Masinter, L., "Uniform
skipping to change at page 36, line 7 skipping to change at page 38, 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
<!ELEMENT orderpatch (ordering-type?, ordermember*) > <!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT ordermember (segment, position) > <!ELEMENT order-member (segment, position) >
<!ELEMENT ordering-type (href) > <!ELEMENT ordering-type (href) >
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
<!ELEMENT before segment > <!ELEMENT before segment >
<!ELEMENT after segment > <!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
B Change Log B Change Log
skipping to change at page 39, line 5 skipping to change at page 40, line 20
Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set
(no change tracking). (no change tracking).
Closed issue ordered-header-name (header name changed to "ordering- Closed issue ordered-header-name (header name changed to "ordering-
type", contents matches live property). type", contents matches live property).
Closed issue ordermember-format (now takes segment instead of href). Closed issue ordermember-format (now takes segment instead of href).
Renamed compliance class to "ordered-collections" for consistency Renamed compliance class to "ordered-collections" for consistency
with newer specs, and to allow detection of compliance to final with newer specs, and to allow detection of compliance to final
version of spec. version of spec.
Updated reference to XML spec to 1.0, 2nd edition. Updated reference to XML spec to 1.0, 2nd edition.
B.5 Since draft-ietf-webdav-ordering-protocol-05
Typos fixed.
Renamed DAV:ordermember to DAV:order-member.
Made RFC3253-compatible pre/postcondition handling a MUST
requirement.
Reference definition of "protected property" from RFC3253.
Added explanation of role of DTD fragments to Notation section.
Clarified semantics for operations on versioned collections and
collection versions.
Index Index
C C
Client-Maintained Ordering Client-Maintained Ordering
3 3
D D
DAV:collection-must-be-ordered precondition DAV:collection-must-be-ordered precondition
6.1 6.1
DAV:custom ordering type DAV:custom ordering type
4.1.1 4.1.1
DAV:initialize-collection-version-ordering-type
9.2
DAV:initialize-ordering-type
9.3
DAV:initialize-version-controlled-bindings-ordered postcondition
9.2
DAV:initialize-version-history-bindings-ordered
9.3
DAV:ordered-collections-supported precondition DAV:ordered-collections-supported precondition
5.1 5.1
DAV:ordering-modified postcondition DAV:ordering-modified postcondition
7 7
DAV:ordering-type property DAV:ordering-type property
4.1.1 4.1.1
DAV:ordering-type-set postcondition DAV:ordering-type-set postcondition
5.1, 7 5.1, 7
DAV:position-set postcondition DAV:position-set postcondition
6.1 6.1
DAV:segment-must-identify-member precondition DAV:segment-must-identify-member precondition
6.1 6.1
DAV:unordered ordering type DAV:unordered ordering type
4.1.1 4.1.1
DAV:update-version-controlled-collection-members-ordered
9.4
DAV:update-version-ordering-type
9.4
H H
Headers Headers
Ordering-Type 5.1 Ordering-Type 5.1
O O
Ordered Collection Ordered Collection
3 3
skipping to change at page 40, line 21 skipping to change at page 42, line 26
ORDERPATCH method ORDERPATCH method
7 7
P P
Postconditions Postconditions
DAV:ordering-type-set 5.1, 7 DAV:ordering-type-set 5.1, 7
DAV:position-set 6.1 DAV:position-set 6.1
DAV:ordering-type-set 5.1, 7 DAV:ordering-type-set 5.1, 7
DAV:ordering-modified 7 DAV:ordering-modified 7
DAV:initialize-version-controlled-bindings-ordered 9.2
DAV:initialize-collection-version-ordering-type 9.2
DAV:initialize-version-history-bindings-ordered 9.3
DAV:initialize-ordering-type 9.3
DAV:update-version-controlled-collection-members-ordered 9.4
DAV:update-version-ordering-type 9.4
Preconditions Preconditions
DAV:ordered-collections-supported 5.1 DAV:ordered-collections-supported 5.1
DAV:collection-must-be-ordered 6.1 DAV:collection-must-be-ordered 6.1
DAV:segment-must-identify-member 6.1 DAV:segment-must-identify-member 6.1
Protected properties Protected properties
DAV:ordering-type 4.1.1 DAV:ordering-type 4.1.1
S S
 End of changes. 38 change blocks. 
109 lines changed or deleted 216 lines changed or added

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