draft-ietf-webdav-ordering-protocol-03.txt		draft-ietf-webdav-ordering-protocol-04.txt
	Network Working Group J. Slein		Network Working Group J. Slein
	Internet Draft Xerox		Internet Draft Xerox
	Expires: March 2003 J. Whitehead		Expires: July 2003 J. Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	J. Davis
	Intelligent Markets
	C. Fay
	FileNet
	J. Crawford		J. Crawford
	IBM		IBM
	J. F. Reschke		J. F. Reschke
	greenbytes		greenbytes
	September 2002		January 2003
	WebDAV Ordered Collections Protocol		WebDAV Ordered Collections Protocol
	draft-ietf-webdav-ordering-protocol-03		draft-ietf-webdav-ordering-protocol-04
	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 March 2003.		This Internet-Draft will expire in July 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	This specification extends the WebDAV Distributed Authoring Protocol		This specification extends the WebDAV Distributed Authoring Protocol
	to support server-side ordering of collection members. Of particular		to support server-side ordering of collection members. Of particular
	interest are orderings that are not based on property values, and so		interest are orderings that are not based on property values, and so
	cannot be achieved using a search protocol's ordering option and		cannot be achieved using a search protocol's ordering option and
	cannot be maintained automatically by the server. Protocol elements		cannot be maintained automatically by the server. Protocol elements
	are defined to let clients specify the position in the ordering of		are defined to let clients specify the position in the ordering of
	each collection member, as well as the semantics governing the		each collection member, as well as the semantics governing the
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	Distribution of this document is unlimited. Please send comments to		Distribution of this document is unlimited. Please send comments to
	the Distributed Authoring and Versioning (WebDAV) working group at		the Distributed Authoring and Versioning (WebDAV) working group at
	w3c-dist-auth@w3.org, which may be joined by sending a message with		w3c-dist-auth@w3.org, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2		Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
	Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3		Table of Contents . . . . . . . . . . . . . . . . . . . . . . 3
	1 Notational Conventions . . . . . . . . . . . . . . . . . . . . 5		1 Notational Conventions . . . . . . . . . . . . . . . . . . . 4
	2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4 Overview of Ordered Collections . . . . . . . . . . . . . . . . 8		4 Overview of Ordered Collections . . . . . . . . . . . . . . 7
	4.1 Additional Collection properties . . . . . . . . . . . . . 8		4.1 Additional Collection properties . . . . . . . . . . . . 7
	4.1.1 DAV:orderingtype (protected) . . . . . . . . . . . . . 9		4.1.1 DAV:orderingtype (protected) . . . . . . . . . . . . 8
	5 Creating an Ordered Collection . . . . . . . . . . . . . . . . 10		5 Creating an Ordered Collection . . . . . . . . . . . . . . . 9
	5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2 Example: Creating an Ordered Collection . . . . . . . . . . 11		5.2 Example: Creating an Ordered Collection . . . . . . . . 10
	6 Setting the Position of a Collection Member . . . . . . . . . . 12		6 Setting the Position of a Collection Member . . . . . . . . 11
	6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.2 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12		6.2 Examples: Setting the Position of a Collection Member . 12
	6.3 Examples: Setting the Position of a Collection Member . . . 12		7 Changing a Collection Ordering: ORDERPATCH method . . . . . 14
	7 Changing a Collection Ordering . . . . . . . . . . . . . . . . 14		7.1 Example: Changing a Collection Ordering . . . . . . . . 16
	7.1 ORDERPATCH Method . . . . . . . . . . . . . . . . . . . . . 14		7.2 Example: Failure of an ORDERPATCH Request . . . . . . . 18
	7.1.1 Status Codes . . . . . . . . . . . . . . . . . . . . . 14		8 Listing the Members of an Ordered Collection . . . . . . . . 20
	7.1.2 Example: Changing a Collection Ordering . . . . . . . . 15		8.1 Example: PROPFIND on an Ordered Collection . . . . . . . 20
	7.1.3 Example: Failure of an ORDERPATCH Request . . . . . . . 17		9 Relationship to versioned collections . . . . . . . . . . . 24
	8 Listing the Members of an Ordered Collection . . . . . . . . . 19		9.1 Additional semantics for collection version properties . 24
	8.1 Example: PROPFIND on an Ordered Collection . . . . . . . . 19		10 Capability Discovery . . . . . . . . . . . . . . . . . . . 25
	9 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		10.1 Example: Using OPTIONS for the Discovery of Support for
	9.1 Position Request Header . . . . . . . . . . . . . . . . . . 23		Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	10 XML Elements . . . . . . . . . . . . . . . . . . . . . . . . . 24		10.2 Example: Using Live Properties for the Discovery of
	10.1 order XML Element . . . . . . . . . . . . . . . . . . . . 24		Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10.2 ordermember XML Element . . . . . . . . . . . . . . . . . 24		11 Security Considerations . . . . . . . . . . . . . . . . . . 28
	10.3 position XML Element . . . . . . . . . . . . . . . . . . . 25		11.1 Denial of Service and DAV:orderingtype . . . . . . . . 28
	10.4 first XML Element . . . . . . . . . . . . . . . . . . . . 25		12 Internationalization Considerations . . . . . . . . . . . . 29
	10.5 last XML Element . . . . . . . . . . . . . . . . . . . . . 25		13 IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
	10.6 before XML Element . . . . . . . . . . . . . . . . . . . . 26		14 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.7 after XML Element . . . . . . . . . . . . . . . . . . . . 26		15 Intellectual Property . . . . . . . . . . . . . . . . . . . 32
	10.8 segment XML Element . . . . . . . . . . . . . . . . . . . 27		16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33
	11 Capability Discovery . . . . . . . . . . . . . . . . . . . . . 28		Normative References . . . . . . . . . . . . . . . . . . . . . 34
	11.1 Example: Using OPTIONS for the Discovery of Support for		Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 34
	Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		A Extensions to the WebDAV Document Type Definition . . . . . 36
	11.2 Example: Using Live Properties for the Discovery of		B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37
	Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	12 Security Considerations . . . . . . . . . . . . . . . . . . . 31
	12.1 Denial of Service and DAV:orderingtype . . . . . . . . . . 31
	13 Internationalization Considerations . . . . . . . . . . . . . 32
	14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	15 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	16 Intellectual Property . . . . . . . . . . . . . . . . . . . . 35
	17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
	Normative References . . . . . . . . . . . . . . . . . . . . . . 37
	Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	A Extensions to the WebDAV Document Type Definition . . . . . . . 39
	B Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	B.1 Since draft-ietf-webdav-ordering-protocol dated December		B.1 Since draft-ietf-webdav-ordering-protocol dated December
	1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . . 40		B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . 37
			B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . 37
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	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 6, line 33		skipping to change at page 5, line 33
	but orderings not based on properties cannot. These orderings		but orderings not based on properties cannot. These orderings
	generally need to be maintained by a human user.		generally need to be maintained by a human user.
	The ordering protocol defined here focuses on support for such human-		The ordering protocol defined here focuses on support for such human-
	maintained orderings. Its protocol elements allow clients to specify		maintained orderings. Its protocol elements allow clients to specify
	the position of each collection member in the collection's ordering,		the position of each collection member in the collection's ordering,
	as well as the semantics governing the ordering. The protocol is		as well as the semantics governing the ordering. The protocol is
	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 through Section 10 define the headers, properties, and XML		section 9 discusses the impact on version-controlled collections (as
	elements needed to support ordered collections. Section 11 describes		defined in [RFC3253]. Section 10 describes capability discovery.
	capability discovery. Section 12 through Section 14 discuss security,		Section 11 through section 13 discuss security, internationalization,
	internationalization, and IANA considerations. The remaining sections		and IANA considerations. The remaining sections provide supporting
	provide supporting information.		information.
	3 Terminology		3 Terminology
	The terminology used here follows that in the [RFC2518]. Definitions		The terminology used here follows that in [RFC2518]and [RFC3253].
	of the terms resource, Uniform Resource Identifier (URI), and Uniform		Definitions of the terms resource, Uniform Resource Identifier (URI),
	Resource Locator (URL) are provided in [RFC2396].		and Uniform Resource Locator (URL) are provided in [RFC2396].
	Ordered Collection		Ordered Collection
	A collection for which the results from a PROPFIND request are		A collection for which the results from a PROPFIND request are
	guaranteed to be in the order specified for that collection		guaranteed to be in the order specified for that collection
	Unordered Collection		Unordered Collection
	A collection for which the client cannot depend on the		A collection for which the client cannot depend on the
	repeatability of the ordering of results from a PROPFIND request		repeatability of the ordering of results from a PROPFIND request
	skipping to change at page 8, line 23		skipping to change at page 7, line 23
	Server-side orderings may be client-maintained or server-maintained.		Server-side orderings may be client-maintained or server-maintained.
	For client-maintained orderings, a client must specify the ordering		For client-maintained orderings, a client must specify the ordering
	position of each of the collection's members, either when the member		position of each of the collection's members, either when the member
	is added to the collection (using the Position header) or later		is added to the collection (using the Position header) or later
	(using the ORDERPATCH method). For server-maintained orderings, the		(using the ORDERPATCH method). For server-maintained orderings, the
	server automatically positions each of the collection's members		server automatically positions each of the collection's members
	according to the ordering semantics. This specification supports only		according to the ordering semantics. This specification supports only
	client-maintained orderings, but is designed to allow future		client-maintained orderings, but is designed to allow future
	extension to server-maintained orderings.		extension to server-maintained orderings.
	A collection that supports ordering is not required to be ordered. It		A collection that supports ordering is not required to be ordered.
	is up to the client to decide whether a given collection is ordered
	and, if so, to specify the semantics to be used for ordering its
	members.
	If a collection is ordered, each of its internal member URIs MUST be		If a collection is ordered, each of its internal member URIs MUST be
	in the ordering exactly once, and the ordering MUST NOT include any		in the ordering exactly once, and the ordering MUST NOT include any
	URI that is not an internal member of the collection. The server is		URI that is not an internal member of the collection. The server is
	responsible for enforcing these constraints on orderings. The server		responsible for enforcing these constraints on orderings. The server
	MUST remove an internal member URI from the ordering when it is		MUST remove an internal member URI from the ordering when it is
	removed from the collection. The server MUST an internal member URI		removed from the collection. The server MUST add an internal member
	to the ordering when it is added to the collection.		URI to the ordering when it is added to the collection.
	Only one ordering can be attached to any collection. Multiple		Only one ordering can be attached to any collection. Multiple
	orderings of the same resources can be achieved by creating multiple		orderings of the same resources can be achieved by creating multiple
	collections referencing those resources, and attaching a different		collections referencing those resources, and attaching a different
	ordering to each collection.		ordering to each collection.
	An ordering is considered to be part of the state of a collection		An ordering is considered to be part of the state of a collection
	resource. Consequently, the ordering is the same no matter which URI		resource. Consequently, the ordering is the same no matter which URI
	is used to access the collection and is protected by locks or access		is used to access the collection and is protected by locks or access
	control constraints on the collection.		control constraints on the collection.
	4.1 Additional Collection properties		4.1 Additional Collection properties
			A DAV:allprop PROPFIND request SHOULD NOT return any of the
			properties defined in this document.
	4.1.1 DAV:orderingtype (protected)		4.1.1 DAV:orderingtype (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 Ordered header with a MKCOL request or by submitting an
	ORDERPATCH request.		ORDERPATCH request.
	skipping to change at page 11, line 5		skipping to change at page 10, line 5
	to be ordered, but the semantics of the ordering is not being		to be ordered, but the semantics of the ordering is not being
	advertised. Any other Coded-url value indicates that the		advertised. Any other Coded-url value indicates that the
	collection is ordered, and identifies the semantics of the		collection is 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:
			(DAV:orderdingtype-set): the collection was created with the
			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: www.server.org		Host: example.org
	Ordered: <http://www.server.org/orderings/compass.html>		Ordered: <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:orderingtype property has as its value the URI from the Ordered
	header, http://www.server.org/orderings/compass.html. In this case,		header, http://example.org/orderings/compass.html. In this case, the
	the URI identifies the semantics governing a client-maintained		URI identifies the semantics governing a client-maintained ordering.
	ordering. As new members are added to the collection, clients or end		As new members are added to the collection, clients or end users can
	users can use the semantics to determine where to position the new		use the semantics to determine where to position the new members in
	members in the ordering.		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 (defined in Section		ordering can be set with the new Position header. The Position header
	9.1). The Position header allows the client to specify that an		allows the client to specify that an internal member URI should be
	internal member URI should be first in the collection's ordering,		first in the collection's ordering, last in the collection's
	last in the collection's ordering, immediately before some other		ordering, immediately before some other internal member URI in the
	internal member URI in the collection's ordering, or immediately		collection's ordering, or immediately after some other internal
	after some other internal member URI in the collection's ordering.		member URI in the collection's ordering.
	If the Position request header is not used when adding a member to an		If the Position request header is not used when adding a member to an
	ordered collection, then:		ordered collection, then:
	o If the request is replacing an existing resource, the server MUST		o If the request is replacing an existing resource, the server MUST
	preserve the present ordering.		preserve the present ordering.
	o If the request is adding a new internal member URI to the		o If the request is adding a new internal member URI to the
	collection, the server MUST append the new member to the end of		collection, the server MUST append the new member to the end of
	the ordering.		the ordering.
	6.2 Status Codes		Additional Marshalling:
	409 (Conflict): Several conditions may cause this response. The		Position = "Position" ":" ("first" | "last" |
	request may specify a position that is before or after a URI that is		(("before" | "after") segment))
	not an internal member URI of the collection, or before or after
	itself. The request may attempt to specify the new member's position
	in an unordered collection.
	6.3 Examples: Setting the Position of a Collection Member		segment is defined in Section 3.3 of [RFC2396].
			The segment is interpreted relative to the collection to which the
			new member is being added.
			The server MUST insert the new member into the ordering at the
			location specified in the Position header, if one is present (and
			if the collection is ordered).
			The "first" keyword indicates the new member is put in the
			beginning position in the collection's ordering, while "last"
			indicates the new member is put in the final position in the
			collection's ordering. The "before" keyword indicates the new
			member is added to the collection's ordering immediately prior to
			the position of the member identified in the segment. Likewise,
			the "after" keyword indicates the new member is added to the
			collection's ordering immediately following the position of the
			member identified in the segment.
			If the request is replacing an existing resource, and the Position
			header is present, the server MUST remove the internal member URI
			from its previous position, and then insert it at the requested
			position.
			Additional Preconditions:
			(DAV:collection-must-be-ordered): the target collection must be
			ordered.
			(DAV:segment-must-identify-member): the referenced segment must
			identify a resource that exists and is different from the affected
			resource.
			Additional Postconditions:
			(DAV:position-set): the newly created collection member was
			created at the specified position.
			6.2 Examples: Setting the Position of a Collection Member
	>> Request:		>> Request:
	COPY /~whitehead/dav/spec08.html HTTP/1.1		COPY /~user/dav/spec08.html HTTP/1.1
	Host: www.ics.uci.edu		Host: example.org
	Destination: http://www.xerox.com/~slein/dav/spec08.html		Destination: http://example.org/~slein/dav/spec08.html
	Position: after requirements.html		Position: after requirements.html
	>> Response:		>> Response:
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	This request resulted in the creation of a new resource at		This request resulted in the creation of a new resource at
	www.xerox.com/~slein/dav/spec08.html. The Position header in this		example.org/~slein/dav/spec08.html. The Position header in this
	example caused the server to set its position in the ordering of the		example caused the server to set its position in the ordering of the
	/~slein/dav/ collection immediately after requirements.html.		/~slein/dav/ collection immediately after requirements.html.
	>> Request:		>> Request:
	MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1		MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1
	Host: www.ics.uci.edu		Host: example.org
	Destination: http://www.ics.uci.edu/~whitehead/dav/draft-webdav-		Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt
	protocol-08.txt
	Position: first		Position: first
	>> Response:		>> Response:
	HTTP/1.1 409 Conflict		HTTP/1.1 409 Conflict
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:error xmlns:D="DAV:">
			<D:collection-must-be-ordered/>
			</D:error>
	In this case, the server returned a 409 (Conflict) status code		In this case, the server returned a 409 (Conflict) status code
	because the /~whitehead/dav/ collection is an unordered collection.		because the /~user/dav/ collection is an unordered collection.
	Consequently, the server was unable to satisfy the Position header.		Consequently, the server was unable to satisfy the Position header.
	7 Changing a Collection Ordering		7 Changing a Collection Ordering: ORDERPATCH method
	7.1 ORDERPATCH Method
	The ORDERPATCH method is used to change the ordering semantics of a		The ORDERPATCH method is used to change the ordering semantics of a
	collection or to change the order of the collection's members in the		collection or to change the order of the collection's members in the
	ordering or both.		ordering or both.
	The ORDERPATCH method changes the ordering semantics of the
	collection identified by the Request-URI, based on the value of
	DAV:orderingtype submitted in the request entity body.
	The ORDERPATCH method alters the ordering of internal member URIs in
	the collection identified by the Request-URI, based on instructions
	in the ordermember XML elements in the request entity body. The
	ordermember XML elements identify the internal member URIs whose
	positions are to be changed, and describe their new positions in the
	ordering. Each new position can be specified as first in the
	ordering, last in the ordering, immediately before some other
	internal member URI, or immediately after some other internal member
	URI.
	The server MUST apply the changes in the order they appear in the		The server MUST apply the changes in the order they appear in the
	order XML element. The server MUST either apply all the changes or		order XML element. The server MUST either apply all the changes or
	apply none of them. If any error occurs during processing, all		apply none of them. If any error occurs during processing, all
	executed changes MUST be undone and a proper error result returned.		executed changes MUST be undone and a proper error result returned.
	If an ORDERPATCH request changes the ordering semantics, but does not		If an ORDERPATCH request changes the ordering semantics, but does not
	completely specify the order of the collection members, the server		completely specify the order of the collection members, the server
	MUST assign a position in the ordering to each collection member for		MUST assign a position in the ordering to each collection member for
	which a position was not specified. These server-assigned positions		which a position was not specified. These server-assigned positions
	MUST all follow the last one specified by the client. The result is		MUST all follow the last one specified by the client. The result is
	that all members for which the client specified a position are at the		that all members for which the client specified a position are at the
	beginning of the ordering, followed by any members for which the		beginning of the ordering, followed by any members for which the
	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.
	7.1.1 Status Codes		A request to reposition a collection member at the same place in the
			ordering is not an error.
			Additional Marshalling:
			The request body MUST be DAV:order element.
			<!ELEMENT order (orderingtype?, ordermember*) >
			<!ELEMENT ordermember (href, position) >
			<!ELEMENT position (first | last | before | after)>
			<!ELEMENT first EMPTY >
			<!ELEMENT last EMPTY >
			<!ELEMENT before segment >
			<!ELEMENT after segment >
			<!ELEMENT segment (#PCDATA)>
			PCDATA value: segment, as defined in section 3.3 of [RFC2396].
			DAV:href value: segment part of collection member.
			The DAV:orderingtype property is modified according to the
			DAV:orderingtype element.
			The ordering of internal member URIs in the collection identified
			by the Request-URI is changed based on instructions in the
			ordermember XML elements. The ordermember XML elements identify
			the internal member URIs whose positions are to be changed, and
			describe their new positions in the ordering. Each new position
			can be specified as first in the ordering, last in the ordering,
			immediately before some other internal member URI, or immediately
			after some other internal member URI.
			If a response body for a successful request is included, it MUST
			be a DAV:orderpatch-response XML element. Note that this document
			does not define any elements for the ORDERPATCH response body, but
			the DAV:orderpatch-response element is defined to ensure
			interoperability between future extensions that do define elements
			for the ORDERPATCH response body.
			<!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, as defined in [RFC2518].		207 (Multi-Status) response (defined in [RFC2518]), containing
			DAV:response elements for either the request-URI (when the
			DAV:orderingtype could not be modified) or URIs of collection
			members to be repositioned (when an invidual positioning request
			expressed as DAV:ordermember could not be fulfilled).
	The following are examples of response codes one would expect to be		Preconditions:
	used in a 207 (Multi-Status) response for this method:
	200 (OK): The change in ordering was successfully made.		(DAV:collection-must-be-ordered): see section 6.1.
	409 (Conflict): Several conditions may cause this response. The		(DAV:segment-must-identify-member): see section 6.1.
	request may specify a position that is before or after a URI that is
	not an internal member URI of the collection, or before or after
	itself. The request may attempt to set the positions of members of an
	unordered collection.
	A request to reposition a collection member at the same place in the		Postconditions:
	ordering is not an error.
	7.1.2 Example: Changing a Collection Ordering		(DAV:orderdingtype-set): if the request body contained a
			DAV:orderingtype element, the DAV:orderingtype property (see
			section 4.1.1) of the collection identified by the request-URI was
			set accordingly.
			(DAV:orderding-modified): if the request body contained
			DAV:ordermember elements, the ordering of internal member URIs in
			the collection identified by the request-URI has been changed
			based on instructions in the DAV:ordermember elements.
			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:orderingtype 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: www.myserver.com		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:order xmlns:d="DAV:">
	<d:orderingtype>		<d:orderingtype>
	<d:href>http://www.myserver.com/inorder.ord</d:href>		<d:href>http://example.org/inorder.ord</d:href>
	</d:orderingtype>		</d:orderingtype>
	<d:ordermember>		<d:ordermember>
	<d:href>two.html</d:href>		<d:href>two.html</d:href>
	<d:position>		<d:position>
	<d:first/>		<d:first/>
	</d:position>		</d:position>
	</d:ordermember>		</d:ordermember>
	<d:ordermember>		<d:ordermember>
	<d:href>one.html</d:href>		<d:href>one.html</d:href>
	<d:position>		<d:position>
	skipping to change at page 16, line 31		skipping to change at page 17, line 26
	</d:position>		</d:position>
	</d:ordermember>		</d:ordermember>
	</d:order>		</d:order>
	>> 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://www.myserver.com/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:orderingtype 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
	collection's ordering is as follows:		collection's ordering is as follows:
	one.html		one.html
	two.html		two.html
	three.html		three.html
	four.html		four.html
	7.1.3 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:
	nunavut.map		nunavut.map
	nunavut.img		nunavut.img
	baffin.map		baffin.map
	baffin.desc		baffin.desc
	baffin.img		baffin.img
	iqaluit.map		iqaluit.map
	nunavut.desc		nunavut.desc
	skipping to change at page 18, line 10		skipping to change at page 19, line 4
	</d:ordermember>		</d:ordermember>
	<d:ordermember>		<d:ordermember>
	<d:href>iqaluit.map</d:href>		<d:href>iqaluit.map</d:href>
	<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:order>
	>> 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/nunavut.desc</d:href>
	<d:status>HTTP/1.1 424 Failed Dependency</d:status>
	</d:response>
	<d:response>
	<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>		<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
	<d:status>HTTP/1.1 409 Conflict</d:status>		<d:status>HTTP/1.1 403 Forbidden</d:status>
	<d:responsedescription>pangnirtung.img is not a collection		<d:responsedescription>
	member.</d:responsedescription>		<d:error><d:segment-must-identify-member/></d:error>
			pangnirtung.img is not a collection member.
			</d:responsedescription>
	</d:response>		</d:response>
	</d:multistatus>		</d:multistatus>
	In this example, the client attempted to position iqaluit.map after a		In this example, the client attempted to position iqaluit.map after a
	URI that is not an internal member of the collection /coll-1/. The		URI that is not an internal member of the collection /coll-1/. The
	server responded to this client error with a 409 (Conflict) status		server responded to this client error with a 403 (Forbidden) status
	code. Because ORDERPATCH is an atomic method, the request to		code, indicating the failed precondition DAV:segment-must-identify-
			member. Because ORDERPATCH is an atomic method, the request to
	reposition nunavut.desc (which would otherwise have succeeded) failed		reposition nunavut.desc (which would otherwise have succeeded) failed
	with a 424 (Failed Dependency) status code.		as well, but doesn't need to be expressed in the multistatus response
			body.
	8 Listing the Members of an Ordered Collection		8 Listing the Members of an Ordered Collection
	A PROPFIND request is used to retrieve a listing of the members of an		A PROPFIND request is used to retrieve a listing of the members of an
	ordered collection, just as it is used to retrieve a listing of the		ordered collection, just as it is used to retrieve a listing of the
	members of an unordered collection.		members of an unordered collection.
	However, when responding to a PROPFIND on an ordered collection, the		However, when responding to a PROPFIND on an ordered collection, the
	server MUST order the response elements according to the ordering		server MUST order the response elements according to the ordering
	defined on the collection. If a collection is unordered, the client		defined on the collection. If a collection is unordered, the client
	skipping to change at page 19, line 41		skipping to change at page 20, line 41
	it would be acceptable for the server to return response elements in		it would be acceptable for the server to return response elements in
	the order A B E C F G H D. In this response, B, C, and D appear in		the order A B E C F G H D. In this response, B, C, and D appear in
	the correct order, separated by members of other collections. Clients		the correct order, separated by members of other collections. Clients
	can use a series of Depth: 1 PROPFIND requests to avoid the		can use a series of Depth: 1 PROPFIND requests to avoid the
	complexity of processing Depth: infinity responses based on depth-		complexity of processing Depth: infinity responses based on depth-
	first traversals.		first traversals.
	8.1 Example: PROPFIND on an Ordered Collection		8.1 Example: PROPFIND on an Ordered Collection
	Suppose a PROPFIND request is submitted to /MyCollection/, which has		Suppose a PROPFIND request is submitted to /MyColl/, which has its
	its members ordered as follows.		members ordered as follows.
	/MyCollection/		/MyColl/
	lakehazen.html		lakehazen.html
	siorapaluk.html		siorapaluk.html
	iqaluit.html		iqaluit.html
	newyork.html		newyork.html
	>> Request:		>> Request:
	PROPFIND /MyCollection/ HTTP/1.1		PROPFIND /MyColl/ HTTP/1.1
	Host: www.svr.com		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://www.svr.com/jsprops/">		<D:prop xmlns:J="http://example.org/jsprops/">
	<D:orderingtype/>		<D:orderingtype/>
	<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:www.svr.com/jsprops/">		xmlns:J="http://example.org/jsprops/">
	<D:response>		<D:response>
	<D:href>http://www.svr.com/MyCollection/</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:orderingtype><D:custom/></D:orderingtype>
	<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>
	</D:response>		</D:response>
	<D:response>		<D:response>
	<D:href>http://www.svr.com/MyCollection/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:orderingtype/>
	</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://www.svr.com/MyCollection/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:orderingtype/>
	</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://www.svr.com/MyCollection/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:orderingtype/>
	</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://www.svr.com/MyCollection/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:orderingtype/>
	</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 Headers		9 Relationship to versioned collections
	9.1 Position Request Header
	Position = "Position" ":" ("first" | "last" |
	(("before" | "after") segment))
	segment is defined in Section 3.3 of [RFC2396].
	The Position header may be used with any method that adds a member to
	an ordered collection, to tell the server where in the collection
	ordering to position the new member being added to the collection.
	Examples of methods that add members to collections are BIND, PUT,
	COPY, MOVE, etc.
	The segment is interpreted relative to the collection to which the
	new member is being added.
	The server MUST insert the new member into the ordering at the
	location specified in the Position header, if one is present (and if
	the collection is ordered).
	The "first" keyword indicates the new member is put in the beginning
	position in the collection's ordering, while "last" indicates the new
	member is put in the final position in the collection's ordering. The
	"before" keyword indicates the new member is added to the
	collection's ordering immediately prior to the position of the member
	identified in the segment. Likewise, the "after" keyword indicates
	the new member is added to the collection's ordering immediately
	following the position of the member identified in the segment.
	If the request is replacing an existing resource, and the Position
	header is present, the server MUST remove the internal member URI
	from its previous position, and then insert it at the requested
	position.
	If an attempt is made to use the Position header on a collection that
	is unordered, the server MUST fail the request with a 409 (Conflict)
	status code.
	10 XML Elements
	10.1 order XML Element
	Name: order
	Namespace: DAV:
	Purpose: For use with the new ORDERPATCH method. Describes a change
	to be made in a collection's ordering semantics or in the
	positions of its members in the ordering or both.
	Value: An optional identifier of an ordering semantics for the
	collection, followed by a list of changes to be made in
	the positions of the members in the collection's ordering.
	<!ELEMENT order (orderingtype?, ordermember*) >
	10.2 ordermember XML Element
	Name: ordermember
	Namespace: DAV:
	Purpose: Occurs in the order XML element, and describes the new
	position of a single internal member URI in the
	collection's ordering.
	Value: An href containing a member's path segment, and a
	description of its new position in the ordering. The href
	XML element is defined in [RFC2518], Section 11.3.
	<!ELEMENT ordermember (href, position) >
	10.3 position XML Element
	Name: position
	Namespace: DAV:
	Purpose: Occurs in the ordermember XML element. Describes the new
	position in a collection's ordering of one of the members
	it contains.
	Value: The new position can be described as first in the
	collection's ordering, last in the collection's ordering,
	immediately before some other collection member, or
	immediately after some other collection member.
	<!ELEMENT position (first | last | before | after)>
	10.4 first XML Element
	Name: first
	Namespace: DAV:
	Purpose: Occurs in the position XML element. Specifies that the
	member should be placed first in the collection's
	ordering.
	<!ELEMENT first EMPTY >
	10.5 last XML Element
	Name: last
	Namespace: DAV:
	Purpose: Occurs in the position XML element. Specifies that the
	member should be placed last in the collection's ordering.
	<!ELEMENT last EMPTY >
	10.6 before XML Element
	Name: before
	Namespace: DAV:
	Purpose: Occurs in the position XML element. Specifies that the
	member should be placed immediately before the member in
	the enclosed segment XML element in the collection's
	ordering.
	Value: URI (relative to the parent collection) of the member it
	precedes in the ordering
	<!ELEMENT before segment >
	10.7 after XML Element
	Name: after
	Namespace: DAV:
	Purpose: Occurs in the position XML element. Specifies that the
	member should be placed immediately after the member in
	the enclosed segment XML element in the collection's
	ordering.
	Value: URI (relative to the parent collection) of the member it		The Versioning Extensions to WebDAV [RFC3253] introduce the concept
	follows in the ordering		of versioned collections, recording both the dead properties and the
			set of internal version-controlled bindings. This section defines how
			this feature interacts with ordered collections.
	<!ELEMENT after segment >		This specification considers both the ordering type (DAV:orderingtype
			property) and the ordering of collection members to be part of the
			state of a collection. Therefore both MUST be recorded upon CHECKIN
			or VERSION-CONTROL, and both MUST be restored upon CHECKOUT,
			UNCHECKOUT or UPDATE (where for compatibility with RFC3253, only the
			ordering of version-controlled members needs to be maintained).
	10.8 segment XML Element		9.1 Additional semantics for collection version properties
	Name: segment		Although this specification defines the property DAV:orderingtype to
	Namespace: DAV:		be protected, it MUST be recorded in a collection version.
	Purpose: Identifies a member of a collection, used in the
	DAV:before and DAV:after elements, to define one member's
	position in a collection ordering relative to another
	member of the collection.
	Value: segment ; as defined in section 3.3 of [RFC2396].
	<!ELEMENT segment (#PCDATA)>		The property DAV:version-controlled-binding-set ([RFC3253], section
			14.2.1) records the set of version-controlled bindings in the
			collection. For ordered collections, the DAV:version-controlled-
			binding elements MUST appear in the ordering defined for the checked-
			in ordered collection.
	11 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 orderedcoll, for
	use with the DAV header in responses to OPTIONS requests. If a		use with the DAV header in responses to OPTIONS requests. If a
	collection resource does support ordering, its response to an OPTIONS		collection resource does support ordering, its response to an OPTIONS
	request may indicate that it does, by listing the new ORDERPATCH		request may indicate that it does, by listing the new ORDERPATCH
	method as one it supports, and by listing the new orderedcoll		method as one it supports, and by listing the new orderedcoll
	skipping to change at page 28, line 29		skipping to change at page 25, line 29
	resource can include orderedcoll in the value of the DAV header. By		resource can include orderedcoll in the value of the DAV header. By
	including orderedcoll, the resource indicates that its internal		including orderedcoll, the resource indicates that its internal
	member URIs can be ordered. It implies nothing about whether any		member URIs can be ordered. It implies nothing about whether any
	collections identified by its internal member URIs can be ordered.		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.
	11.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: somehost.org		Host: example.org
	>> Response:		>> Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Tue, 20 Jan 1998 20:52:29 GMT		Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
	Connection: close		Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
	Accept-Ranges: none
	Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
	MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH
	DAV: 1, 2, orderedcoll		DAV: 1, 2, orderedcoll
	The DAV header in the response indicates that the resource		The DAV header in the response indicates that the resource
	/somecollection/ is level 1 and level 2 compliant, as defined in		/somecollection/ is level 1 and level 2 compliant, as defined in
	[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/.
	11.2 Example: Using Live Properties for the Discovery of Ordering		10.2 Example: Using Live Properties for the Discovery of Ordering
	>> Request:		>> Request:
	PROPFIND /somecollection HTTP/1.1		PROPFIND /somecollection HTTP/1.1
	Host: somehost.org
	Depth: 0		Depth: 0
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="UTF-8" ?>		<?xml version="1.0" encoding="UTF-8" ?>
	<propfind xmlns="DAV:">		<propfind xmlns="DAV:">
	<prop>		<prop>
	<supported-live-property-set/>		<supported-live-property-set/>
	<supported-method-set/>		<supported-method-set/>
	</prop>		</prop>
	skipping to change at page 29, line 37		skipping to change at page 26, line 33
	>> 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" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<multistatus xmlns="DAV:">		<multistatus xmlns="DAV:">
	<response>		<response>
	<href>http://somehost.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><orderingtype/></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" />
	skipping to change at page 31, line 5		skipping to change at page 28, line 5
	</supported-method-set>		</supported-method-set>
	</prop>		</prop>
	<status>HTTP/1.1 200 OK</status>		<status>HTTP/1.1 200 OK</status>
	</propstat>		</propstat>
	</response>		</response>
	</multistatus>		</multistatus>
	Note that actual responses MUST contain a complete list of supported		Note that actual responses MUST contain a complete list of supported
	live properties.		live properties.
	12 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.
	12.1 Denial of Service and DAV:orderingtype		11.1 Denial of Service and DAV:orderingtype
	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:orderingtype 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:orderingtype. This risk will be further reduced if clients		DAV:orderingtype. This risk will be further reduced if clients
	observe the recommendation of Section 5.1 that they not send requests		observe the recommendation of section 5.1 that they not send requests
	to the URI in DAV:orderingtype.		to the URI in DAV:orderingtype.
	13 Internationalization Considerations		12 Internationalization Considerations
	This specification follows the practices of [RFC2518] in encoding all		This specification follows the practices of [RFC2518] in encoding all
	human-readable content using [XML] and in the treatment of names.		human-readable content using [XML] and in the treatment of names.
	Consequently, this specification complies with the IETF Character Set		Consequently, this specification complies with the IETF Character Set
	Policy [RFC2277].		Policy [RFC2277].
	WebDAV applications MUST support the character set tagging, character		WebDAV applications MUST support the character set tagging, character
	set encoding, and the language tagging functionality of the XML		set encoding, and the language tagging functionality of the XML
	specification. This constraint ensures that the human-readable		specification. This constraint ensures that the human-readable
	content of this specification complies with [RFC2277].		content of this specification complies with [RFC2277].
	skipping to change at page 33, line 5		skipping to change at page 30, line 5
	description of the code (e.g., 423 Locked). Internationalized		description of the code (e.g., 423 Locked). Internationalized
	applications will ignore this message, and display an appropriate		applications will ignore this message, and display an appropriate
	message in the user's language and character set.		message in the user's language and character set.
	This specification introduces no new strings that are displayed to		This specification introduces no new strings that are displayed to
	users as part of normal, error-free operation of the protocol.		users as part of normal, error-free operation of the protocol.
	For rationales for these decisions and advice for application		For rationales for these decisions and advice for application
	implementors, see [RFC2518].		implementors, see [RFC2518].
	14 IANA Considerations		13 IANA Considerations
	This document uses the namespaces defined by [RFC2518] for properties		This document uses the namespaces defined by [RFC2518] for properties
	and XML elements. All other IANA considerations mentioned in		and XML elements. All other IANA considerations mentioned in
	[RFC2518] also apply to this document.		[RFC2518] also apply to this document.
	15 Copyright		14 Copyright
	To be supplied by the RFC Editor.		To be supplied by the RFC Editor.
	16 Intellectual Property		15 Intellectual Property
	To be supplied by the RFC Editor.		To be supplied by the RFC Editor.
	17 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, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,		Bruce Cragun, Jim Davis, Spencer Dawkins, Mark Day, Rajiv Dulepet,
	Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, Marcus Jager,		David Durand, Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex
	Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Lisa		Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
	Lippert, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru		Daniel LaLiberte, Lisa Lippert, Steve Martin, Larry Masinter, Jeff
	Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John		McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley
	Stracke, John Tigue, John Turner, Kevin Wiggen, and others.		Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
			Wiggen, and others.
	Normative References		Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H.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 38, line 4		skipping to change at page 35, line 4
	EMail: jslein@crt.xerox.com		EMail: jslein@crt.xerox.com
	Jim Whitehead		Jim Whitehead
	UC Santa Cruz, Dept. of Computer Science		UC Santa Cruz, Dept. of Computer Science
	1156 High Street		1156 High Street
	Santa Cruz, CA 95064		Santa Cruz, CA 95064
	US		US
	EMail: ejw@cse.ucsc.edu		EMail: ejw@cse.ucsc.edu
	Jim Davis
	Intelligent Markets
	410 Jessie Street 6th floor
	San Francisco, CA 94103
	EMail: jrd3@alum.mit.edu
	Chuck Fay
	FileNet Corporation
	3565 Harbor Boulevard
	Costa Mesa, CA 92626-1420
	EMail: cfay@filenet.com
	Jason Crawford		Jason Crawford
	IBM Research		IBM Research
	P.O. Box 704		P.O. Box 704
	Yorktown Heights, NY 10598		Yorktown Heights, NY 10598
	EMail: ccjason@us.ibm.com		EMail: ccjason@us.ibm.com
	Julian F. Reschke		Julian F. Reschke
	greenbytes GmbH		greenbytes GmbH
	Salzmannstrasse 152		Salzmannstrasse 152
	skipping to change at page 40, line 30		skipping to change at page 37, line 30
	Updated change log to refer to expired draft version as "December		Updated change log to refer to expired draft version as "December
	1999" version.		1999" version.
	Started rewrite marshalling in RFC3253-style and added precondition		Started rewrite marshalling in RFC3253-style and added precondition
	and postcondition definitions.		and postcondition definitions.
	On his request, removed Geoff Clemm's name from the author list		On his request, removed Geoff Clemm's name from the author list
	(moved to Acknowledgments).		(moved to Acknowledgments).
	Renamed "References" to "Normative References".		Renamed "References" to "Normative References".
	Removed reference to "MKREF" method.		Removed reference to "MKREF" method.
			B.3 Since draft-ietf-webdav-ordering-protocol-03
			Added a set of issues regarding marshalling.
			Changed host names to use proper "example" domain names (no change
			tracking). Fixed host/destination header conflicts. Fixed "allow"
			header (multiline). Removed irrelevant response headers. Abbreviated
			some URIs (no change tracking).
			Removed Jim Davis and Chuck Fay from the author list (and added them
			to the Acknowledgements section).
			Updated section on setting the position when adding new members,
			removed old section on Position header.
			Started work on Index section.
			Changed structure for section 7 (no change tracking).
			Removed header and XML elements section (contents moved to other
			sections).
			Started new section on relation to versioned collections as per
			RFC3253.
			Do not return 424's for in ODERPATCH multistatus (it's atomic
			anyway).
			Index
			C O
			Client-Maintained Ordering Ordered Collection
			3 3
			Ordered header
			5.1
			ORDERPATCH method
			D 7
			DAV:collection-must-be-ordered
			precondition P
			6.1
			DAV:custom ordering type
			4.1.1 Postconditions
			DAV:ordered-collections- DAV:orderingtype-set 5.1,7
			supported precondition DAV:position-set 6.1
			5.1 DAV:orderingtype-set 5.1,7
			DAV:ordering-modified DAV:ordering-modified 7
			postcondition
			7 Preconditions
			DAV:orderingtype property DAV:ordered-collections-
			4.1.1 supported 5.1
			DAV:orderingtype-set DAV:collection-must-be-
			postcondition ordered 6.1
			5.1,7 DAV:segment-must-identify-
			DAV:position-set postcondition member 6.1
			6.1
			DAV:segment-must-identify- Protected properties
			member precondition DAV:orderingtype 4.1.1
			6.1
			DAV:unordered ordering type
			4.1.1
			S
			H
			Server-Maintained Ordering
			3
			Headers
			Ordered 5.1
			U
			Unordered Collection
			3
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished
	others, and derivative works that comment on or otherwise explain it		to others, and derivative works that comment on or otherwise
	or assist in its implementation may be prepared, copied, published		explain it or assist in its implementation may be prepared,
	and distributed, in whole or in part, without restriction of any		copied, published and distributed, in whole or in part, without
	kind, provided that the above copyright notice and this paragraph are		restriction of any kind, provided that the above copyright notice
	included on all such copies and derivative works. However, this		and this paragraph are included on all such copies and derivative
	document itself may not be modified in any way, such as by removing		works. However, this document itself may not be modified in any
	the copyright notice or references to the Internet Society or other		way, such as by removing the copyright notice or references to the
	Internet organizations, except as needed for the purpose of		Internet Society or other Internet organizations, except as needed
	developing Internet standards in which case the procedures for		for the purpose of developing Internet standards in which case the
	copyrights defined in the Internet Standards process must be		procedures for copyrights defined in the Internet Standards
	followed, or as required to translate it into languages other than		process must be followed, or as required to translate it into
	English.		languages other than English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not
	revoked by the Internet Society or its successors or assigns.		be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	Funding for the RFC editor function is currently provided by the		Funding for the RFC editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/