draft-ietf-webdav-bind-24.txt		rfc5842.txt
	Network Working Group G. Clemm		Internet Engineering Task Force (IETF) G. Clemm
	Internet-Draft IBM		Request for Comments: 5842 IBM
	Updates: 4918 (if approved) J. Crawford		Category: Experimental J. Crawford
	Intended status: Experimental IBM Research		ISSN: 2070-1721 IBM Research
	Expires: November 30, 2009 J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	J. Whitehead		J. Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	May 29, 2009		April 2010
	Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
	draft-ietf-webdav-bind-24
	Status of this Memo		Binding Extensions to
			Web Distributed Authoring and Versioning (WebDAV)
	This Internet-Draft is submitted to IETF in full conformance with the		Abstract
	provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering		This specification defines bindings, and the BIND method for creating
	Task Force (IETF), its areas, and its working groups. Note that		multiple bindings to the same resource. Creating a new binding to a
	other groups may also distribute working documents as Internet-		resource causes at least one new URI to be mapped to that resource.
	Drafts.		Servers are required to ensure the integrity of any bindings that
			they allow to be created.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This document is not an Internet Standards Track specification; it is
	http://www.ietf.org/ietf/1id-abstracts.txt.		published for examination, experimental implementation, and
			evaluation.
	The list of Internet-Draft Shadow Directories can be accessed at		This document defines an Experimental Protocol for the Internet
	http://www.ietf.org/shadow.html.		community. This document is a product of the Internet Engineering
			Task Force (IETF). It represents the consensus of the IETF
			community. It has received public review and has been approved for
			publication by the Internet Engineering Steering Group (IESG). Not
			all documents approved by the IESG are a candidate for any level of
			Internet Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on November 30, 2009.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc5842.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the
			Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This specification defines bindings, and the BIND method for creating		described in the Simplified BSD License.
	multiple bindings to the same resource. Creating a new binding to a
	resource causes at least one new URI to be mapped to that resource.
	Servers are required to ensure the integrity of any bindings that
	they allow to be created.
	Editorial Note (To be removed by RFC Editor before publication)
	Please send comments to the Distributed Authoring and Versioning
	(WebDAV) working group at <mailto:w3c-dist-auth@w3.org>, which may be
	joined by sending a message with subject "subscribe" to
	<mailto:w3c-dist-auth-request@w3.org>. Discussions of the WEBDAV
	working group are archived at
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
	<http://www.webdav.org/bind/draft-ietf-webdav-bind-issues.html> lists		This document may contain material from IETF Documents or IETF
	all registered issues since draft 02.		Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction ....................................................4
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Terminology ................................................5
	1.2. Method Preconditions and Postconditions . . . . . . . . . 8		1.2. Method Preconditions and Postconditions ....................6
	2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8		2. Overview of Bindings ............................................7
	2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8		2.1. Bindings to Collections ....................................7
	2.1.1. Bind Loops . . . . . . . . . . . . . . . . . . . . . . 9		2.1.1. Bind Loops ..........................................8
	2.2. URI Mappings Created by a new Binding . . . . . . . . . . 9		2.2. URI Mappings Created by a New Binding ......................8
	2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10		2.3. COPY and Bindings ..........................................9
	2.3.1. Example: COPY with 'Depth: infinity' in Presence		2.3.1. Example: COPY with "Depth: infinity" in
	of Bind Loops . . . . . . . . . . . . . . . . . . . . 12		Presence of Bind Loops .............................11
	2.3.2. Example: COPY updating multiple Bindings . . . . . . . 14		2.3.2. Example: COPY Updating Multiple Bindings ...........13
	2.3.3. Example: COPY with 'Depth: infinity' with Multiple		2.3.3. Example: COPY with "Depth: infinity" with
	Bindings to a Leaf Resource . . . . . . . . . . . . . 15		Multiple Bindings to a Leaf Resource ...............14
	2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 16		2.4. DELETE and Bindings .......................................15
	2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 16		2.5. MOVE and Bindings .........................................15
	2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 17		2.5.1. Example: Simple MOVE ...............................16
	2.5.2. Example: MOVE Request causing a Bind Loop . . . . . . 17		2.5.2. Example: MOVE Request Causing a Bind Loop ..........16
	2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 19		2.6. PROPFIND and Bindings .....................................18
	2.7. Determining Whether Two Bindings Are to the Same		2.7. Determining Whether Two Bindings Are to the Same
	Resource . . . . . . . . . . . . . . . . . . . . . . . . . 19		Resource ..................................................18
	2.8. Discovering the Bindings to a Resource . . . . . . . . . . 20		2.8. Discovering the Bindings to a Resource ....................19
	3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 20		3. Properties .....................................................19
	3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 20		3.1. DAV:resource-id Property ..................................20
	3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 21		3.2. DAV:parent-set Property ...................................20
	3.2.1. Example for DAV:parent-set Property . . . . . . . . . 21		3.2.1. Example for DAV:parent-set Property ................20
	4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 22		4. BIND Method ....................................................21
	4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 25		4.1. Example: BIND .............................................24
	5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 25		5. UNBIND Method ..................................................24
	5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 27		5.1. Example: UNBIND ...........................................26
	6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 27		6. REBIND Method ..................................................26
	6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 29		6.1. Example: REBIND ...........................................28
	6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 30		6.2. Example: REBIND in Presence of Locks and Bind Loops .......29
	7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 32		7. Additional Status Codes ........................................31
	7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 32		7.1. 208 Already Reported ......................................31
	7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 33		7.1.1. Example: PROPFIND by Bind-Aware Client .............32
	7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 35		7.1.2. Example: PROPFIND by Non-Bind-Aware Client .........34
	7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 35		7.2. 508 Loop Detected .........................................34
	8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 35		8. Capability Discovery ...........................................34
	8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 35		8.1. OPTIONS Method ............................................34
	8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 35		8.2. 'DAV' Request Header ......................................34
	9. Relationship to WebDAV Access Control Protocol . . . . . . . . 36		9. Relationship to Locking in WebDAV ..............................35
	10. Relationship to Versioning Extensions to WebDAV . . . . . . . 36		9.1. Example: Locking and Multiple Bindings ....................36
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 38		10. Relationship to WebDAV Access Control Protocol ................37
	11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 39		11. Relationship to Versioning Extensions to WebDAV ...............37
	11.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 39		12. Security Considerations .......................................40
	11.3. Bindings, and Denial of Service . . . . . . . . . . . . . 39		12.1. Privacy Concerns .........................................40
	11.4. Private Locations May Be Revealed . . . . . . . . . . . . 39		12.2. Bind Loops ...............................................40
	11.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 39		12.3. Bindings and Denial of Service ...........................40
	12. Internationalization Considerations . . . . . . . . . . . . . 39		12.4. Private Locations May Be Revealed ........................40
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		12.5. DAV:parent-set and Denial of Service .....................41
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40		13. Internationalization Considerations ...........................41
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40		14. IANA Considerations ...........................................41
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 40		15. Acknowledgements ..............................................41
	15.2. Informative References . . . . . . . . . . . . . . . . . . 41		16. References ....................................................41
	Appendix A. Clarification to RFC2518bis' Usage of the term		16.1. Normative References .....................................41
	'lock root' . . . . . . . . . . . . . . . . . . . . . 41		16.2. Informative References ...................................42
	Appendix B. Change Log (to be removed by RFC Editor before		Index .............................................................42
	publication) . . . . . . . . . . . . . . . . . . . . 42
	B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 42
	B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 42
	B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 42
	B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 42
	B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 42
	B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 42
	B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 43
	B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 43
	B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 43
	B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 43
	B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 43
	B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 44
	B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 44
	B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 44
	B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 44
	B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 44
	B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 45
	B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 45
	B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 45
	B.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 45
	B.21. Since draft-ietf-webdav-bind-22 . . . . . . . . . . . . . 45
	B.22. Since draft-ietf-webdav-bind-23 . . . . . . . . . . . . . 45
	Appendix C. Resolved issues (to be removed by RFC Editor
	before publication) . . . . . . . . . . . . . . . . . 45
	C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	C.2. def-integrity . . . . . . . . . . . . . . . . . . . . . . 46
	C.3. ex-copy-multiple-update . . . . . . . . . . . . . . . . . 46
	C.4. ex-copy-graph . . . . . . . . . . . . . . . . . . . . . . 46
	C.5. ex-live-property . . . . . . . . . . . . . . . . . . . . . 47
	C.6. clarify-alternate-uri . . . . . . . . . . . . . . . . . . 47
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	This specification extends the WebDAV Distributed Authoring Protocol		This specification extends the WebDAV Distributed Authoring Protocol
	([RFC4918]) to enable clients to create new access paths to existing		([RFC4918]) to enable clients to create new access paths to existing
	resources. This capability is useful for several reasons:		resources. This capability is useful for several reasons:
	URIs of WebDAV-compliant resources are hierarchical and correspond to		URIs of WebDAV-compliant resources are hierarchical and correspond to
	a hierarchy of collections in resource space. The WebDAV Distributed		a hierarchy of collections in resource space. The WebDAV Distributed
	Authoring Protocol makes it possible to organize these resources into		Authoring Protocol makes it possible to organize these resources into
	skipping to change at page 5, line 30		skipping to change at page 4, line 30
	cars and boats, a description of a combination car/boat vehicle could		cars and boats, a description of a combination car/boat vehicle could
	belong in either collection. Ideally, the description should be		belong in either collection. Ideally, the description should be
	accessible from both. Allowing clients to create new URIs that		accessible from both. Allowing clients to create new URIs that
	access the existing resource lets them put that resource into		access the existing resource lets them put that resource into
	multiple collections.		multiple collections.
	Hierarchies also make resource sharing more difficult, since		Hierarchies also make resource sharing more difficult, since
	resources that have utility across many collections are still forced		resources that have utility across many collections are still forced
	into a single collection. For example, the mathematics department at		into a single collection. For example, the mathematics department at
	one university might create a collection of information on fractals		one university might create a collection of information on fractals
	that contains bindings to some local resources, but also provides		that contains bindings to some local resources but also provides
	access to some resources at other universities. For many reasons, it		access to some resources at other universities. For many reasons, it
	may be undesirable to make physical copies of the shared resources on		may be undesirable to make physical copies of the shared resources on
	the local server: to conserve disk space, to respect copyright		the local server, for example, to conserve disk space, to respect
	constraints, or to make any changes in the shared resources visible		copyright constraints, or to make any changes in the shared resources
	automatically. Being able to create new access paths to existing		visible automatically. Being able to create new access paths to
	resources in other collections or even on other servers is useful for		existing resources in other collections or even on other servers is
	this sort of case.		useful for this sort of case.
	The BIND method defined here provides a mechanism for allowing		The BIND method, defined here, provides a mechanism for allowing
	clients to create alternative access paths to existing WebDAV		clients to create alternative access paths to existing WebDAV
	resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to		resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to
	work because there are mappings between URIs and resources. A method		work because there are mappings between URIs and resources. A method
	is addressed to a URI, and the server follows the mapping from that		is addressed to a URI, and the server follows the mapping from that
	URI to a resource, applying the method to that resource. Multiple		URI to a resource, applying the method to that resource. Multiple
	URIs may be mapped to the same resource, but until now there has been		URIs may be mapped to the same resource, but until now, there has
	no way for clients to create additional URIs mapped to existing		been no way for clients to create additional URIs mapped to existing
	resources.		resources.
	BIND lets clients associate a new URI with an existing WebDAV		BIND lets clients associate a new URI with an existing WebDAV
	resource, and this URI can then be used to submit requests to the		resource, and this URI can then be used to submit requests to the
	resource. Since URIs of WebDAV resources are hierarchical, and		resource. Since URIs of WebDAV resources are hierarchical, and
	correspond to a hierarchy of collections in resource space, the BIND		correspond to a hierarchy of collections in resource space, the BIND
	method also has the effect of adding the resource to a collection.		method also has the effect of adding the resource to a collection.
	As new URIs are associated with the resource, it appears in		As new URIs are associated with the resource, it appears in
	additional collections.		additional collections.
	A BIND request does not create a new resource, but simply makes		A BIND request does not create a new resource, but simply makes a new
	available a new URI for submitting requests to an existing resource.		URI for submitting requests to an existing resource available. The
	The new URI is indistinguishable from any other URI when submitting a		new URI is indistinguishable from any other URI when submitting a
	request to a resource. Only one round trip is needed to submit a		request to a resource. Only one round trip is needed to submit a
	request to the intended target. Servers are required to enforce the		request to the intended target. Servers are required to enforce the
	integrity of the relationships between the new URIs and the resources		integrity of the relationships between the new URIs and the resources
	associated with them. Consequently, it may be very costly for		associated with them. Consequently, it may be very costly for
	servers to support BIND requests that cross server boundaries.		servers to support BIND requests that cross server boundaries.
	This specification is organized as follows. Section 1.1 defines		This specification is organized as follows. Section 1.1 defines
	terminology used in the rest of the specification, while Section 2		terminology used in the rest of the specification, while Section 2
	overviews bindings. Section 3 defines the new properties needed to		overviews bindings. Section 3 defines the new properties needed to
	support multiple bindings to the same resource. Section 4 specifies		support multiple bindings to the same resource. Section 4 specifies
	skipping to change at page 6, line 43		skipping to change at page 5, line 43
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document uses XML DTD fragments ([XML]) as a notational		This document uses XML DTD fragments ([XML]) as a notational
	convention, using the rules defined in Section 17 of [RFC4918].		convention, using the rules defined in Section 17 of [RFC4918].
	URI Mapping		URI Mapping
	A relation between an absolute URI and a resource. For an		A relation between an absolute URI and a resource. For an
	absolute URI U and the resource it identifies R, the URI mapping		absolute URI U and the resource it identifies R, the URI mapping
	can be thought of as (U => R). Since a resource can represent		can be thought of as (U => R). Since a resource can represent
	items that are not network retrievable, as well as those that are,		items that are not network retrievable as well as those that are,
	it is possible for a resource to have zero, one, or many URI		it is possible for a resource to have zero, one, or many URI
	mappings. Mapping a resource to an "http" scheme URI makes it		mappings. Mapping a resource to an "http"-scheme URI makes it
	possible to submit HTTP protocol requests to the resource using		possible to submit HTTP requests to the resource using the URI.
	the URI.
	Path Segment		Path Segment
	Informally, the characters found between slashes ("/") in a URI.		Informally, the characters found between slashes ("/") in a URI.
	Formally, as defined in Section 3.3 of [RFC3986].		Formally, as defined in Section 3.3 of [RFC3986].
	Binding		Binding
	A relation between a single path segment (in a collection) and a		A relation between a single path segment (in a collection) and a
	resource. A binding is part of the state of a collection. If two		resource. A binding is part of the state of a collection. If two
	skipping to change at page 7, line 33		skipping to change at page 6, line 28
	R) makes it possible to use the URI		R) makes it possible to use the URI
	http://www.example.com/CollX/foo.html to access R.		http://www.example.com/CollX/foo.html to access R.
	Collection		Collection
	A resource that contains, as part of its state, a set of bindings		A resource that contains, as part of its state, a set of bindings
	that identify internal member resources.		that identify internal member resources.
	Internal Member URI		Internal Member URI
	The URI that identifies an internal member of a collection, and		The URI that identifies an internal member of a collection and
	that consists of the URI for the collection, followed by a slash		that consists of the URI for the collection, followed by a slash
	character ('/'), followed by the path segment of the binding for		character ('/'), followed by the path segment of the binding for
	that internal member.		that internal member.
	Binding Integrity		Binding Integrity
	The property of a binding that says that:		The property of a binding that says that:
	* the binding continues to exist, and		* the binding continues to exist, and
	* the identity of the resource identified by that binding does		* the identity of the resource identified by that binding does
	not change		not change,
	unless an explicit request is executed that is defined to delete		unless an explicit request is executed that is defined to delete
	that binding (examples of requests that delete a binding are		that binding (examples of requests that delete a binding are
	DELETE, MOVE, and - defined later on - UNBIND, and REBIND).		DELETE, MOVE, and -- defined later on -- UNBIND and REBIND).
	1.2. Method Preconditions and Postconditions		1.2. Method Preconditions and Postconditions
	See Section 16 of [RFC4918] for the definitions of "precondition" and		See Section 16 of [RFC4918] for the definitions of "precondition" and
	"postcondition".		"postcondition".
	2. Overview of Bindings		2. Overview of Bindings
	Bindings are part of the state of a collection. They define the		Bindings are part of the state of a collection. They define the
	internal members of the collection, and the names of those internal		internal members of the collection and the names of those internal
	members.		members.
	Bindings are added and removed by a variety of existing HTTP methods.		Bindings are added and removed by a variety of existing HTTP methods.
	A method that creates a new resource, such as PUT, COPY, and MKCOL,		A method that creates a new resource, such as PUT, COPY, and MKCOL,
	adds a binding. A method that deletes a resource, such as DELETE,		adds a binding. A method that deletes a resource, such as DELETE,
	removes a binding. A method that moves a resource (e.g. MOVE) both		removes a binding. A method that moves a resource (e.g., MOVE) both
	adds a binding (in the destination collection) and removes a binding		adds a binding (in the destination collection) and removes a binding
	(in the source collection). The BIND method introduced here provides		(in the source collection). The BIND method introduced here provides
	a mechanism for adding a second binding to an existing resource.		a mechanism for adding a second binding to an existing resource.
	There is no difference between an initial binding added by PUT, COPY,		There is no difference between an initial binding added by PUT, COPY,
	or MKCOL, and additional bindings added with BIND.		or MKCOL and additional bindings added with BIND.
	It would be very undesirable if one binding could be destroyed as a		It would be very undesirable if one binding could be destroyed as a
	side effect of operating on the resource through a different binding.		side effect of operating on the resource through a different binding.
	In particular, the removal of one binding to a resource (e.g. with a		In particular, the removal of one binding to a resource (e.g., with a
	DELETE or a MOVE) MUST NOT disrupt another binding to that resource,		DELETE or a MOVE) MUST NOT disrupt another binding to that resource,
	e.g. by turning that binding into a dangling path segment. The		e.g., by turning that binding into a dangling path segment. The
	server MUST NOT reclaim system resources after removing one binding,		server MUST NOT reclaim system resources after removing one binding,
	while other bindings to the resource remain. In other words, the		while other bindings to the resource remain. In other words, the
	server MUST maintain the integrity of a binding. It is permissible,		server MUST maintain the integrity of a binding. It is permissible,
	however, for future method definitions (e.g., a DESTROY method) to		however, for future method definitions (e.g., a DESTROY method) to
	have semantics that explicitly remove all bindings and/or immediately		have semantics that explicitly remove all bindings and/or immediately
	reclaim system resources.		reclaim system resources.
			Note: the collection model described herein is not compatible with
			systems in which resources inherit properties based solely on the
			access path, as the ability to create additional bindings will
			cause a single resource to appear as member of several different
			collections at the same time.
	2.1. Bindings to Collections		2.1. Bindings to Collections
	Creating a new binding to a collection makes each resource associated		Creating a new binding to a collection makes each resource associated
	with a binding in that collection accessible via a new URI, and thus		with a binding in that collection accessible via a new URI, and thus
	creates new URI mappings to those resources but no new bindings.		creates new URI mappings to those resources but no new bindings.
	For example, suppose a new binding CollY is created for collection C1		For example, suppose a new binding CollY is created for collection C1
	in the figure below. It immediately becomes possible to access		in the figure below. It immediately becomes possible to access
	resource R1 using the URI /CollY/x.gif and to access resource R2		resource R1 using the URI /CollY/x.gif and to access resource R2
	using the URI /CollY/y.jpg, but no new bindings for these child		using the URI /CollY/y.jpg, but no new bindings for these child
	resources were created. This is because bindings are part of the		resources were created. This is because bindings are part of the
	state of a collection, and associate a URI that is relative to that		state of a collection, and they associate a URI that is relative to
	collection with its target resource. No change to the bindings in		that collection with its target resource. No change to the bindings
	Collection C1 is needed to make its children accessible using /CollY/		in Collection C1 is needed to make its children accessible using
	x.gif and /CollY/y.jpg.		/CollY/x.gif and /CollY/y.jpg.
	+-------------------------+		+-------------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX CollY |		| CollX CollY |
	+-------------------------+		+-------------------------+
	| /		| /
	| /		| /
	| /		| /
	+------------------+		+------------------+
	skipping to change at page 9, line 35		skipping to change at page 8, line 37
	2.1.1. Bind Loops		2.1.1. Bind Loops
	Bindings to collections can result in loops ("cycles"), which servers		Bindings to collections can result in loops ("cycles"), which servers
	MUST detect when processing "Depth: infinity" requests. It is		MUST detect when processing "Depth: infinity" requests. It is
	sometimes possible to complete an operation in spite of the presence		sometimes possible to complete an operation in spite of the presence
	of a loop. For instance, a PROPFIND can still succeed if the server		of a loop. For instance, a PROPFIND can still succeed if the server
	uses the new status code 208 (Already Reported) defined in		uses the new status code 208 (Already Reported) defined in
	Section 7.1.		Section 7.1.
	However, the 506 (Loop Detected) status code is defined in		However, the 508 (Loop Detected) status code is defined in
	Section 7.2 for use in contexts where an operation is terminated		Section 7.2 for use in contexts where an operation is terminated
	because a loop was encountered.		because a loop was encountered.
	Support for loops is OPTIONAL: servers MAY reject requests that would		Support for loops is OPTIONAL: servers MAY reject requests that would
	lead to the creation of a bind loop (see DAV:cycle-allowed		lead to the creation of a bind loop (see DAV:cycle-allowed
	precondition defined in Section 4).		precondition defined in Section 4).
	2.2. URI Mappings Created by a new Binding		2.2. URI Mappings Created by a New Binding
	Suppose a binding from "Binding-Name" to resource R is to be added to		Suppose a binding from "Binding-Name" to resource R is to be added to
	a collection, C. Then if C-MAP is the set of URIs that were mapped to		a collection, C. Then if C-MAP is the set of URIs that were mapped
	C before the BIND request, then for each URI "C-URI" in C-MAP, the		to C before the BIND request, then for each URI "C-URI" in C-MAP, the
	URI "C-URI/Binding-Name" is mapped to resource R following the BIND		URI "C-URI/Binding-Name" is mapped to resource R following the BIND
	request.		request.
	For example, if a binding from "foo.html" to R is added to a		For example, if a binding from "foo.html" to R is added to a
	collection C, and if the following URIs are mapped to C:		collection C, and if the following URIs are mapped to C:
	http://www.example.com/A/1/		http://www.example.com/A/1/
	http://example.com/A/one/		http://example.com/A/one/
	then the following new mappings to R are introduced:		then the following new mappings to R are introduced:
	http://www.example.com/A/1/foo.html		http://www.example.com/A/1/foo.html
	http://example.com/A/one/foo.html		http://example.com/A/one/foo.html
	Note that if R is a collection, additional URI mappings are created		Note that if R is a collection, additional URI mappings are created
	to the descendents of R. Also, note that if a binding is made in		to the descendents of R. Also, note that if a binding is made in
	collection C to C itself (or to a parent of C), an infinite number of		collection C to C itself (or to a parent of C), an infinite number of
	mappings are introduced.		mappings are introduced.
	For example, if a binding from "myself" to C is then added to C, the		For example, if a binding from "myself" to C is then added to C, the
	following infinite number of additional mappings to C are introduced:		following infinite number of additional mappings to C are introduced:
	http://www.example.com/A/1/myself		http://www.example.com/A/1/myself
	http://www.example.com/A/1/myself/myself		http://www.example.com/A/1/myself/myself
	...		...
	and the following infinite number of additional mappings to R are		and the following infinite number of additional mappings to R are
	introduced:		introduced:
	http://www.example.com/A/1/myself/foo.html		http://www.example.com/A/1/myself/foo.html
	http://www.example.com/A/1/myself/myself/foo.html		http://www.example.com/A/1/myself/myself/foo.html
	...		...
	2.3. COPY and Bindings		2.3. COPY and Bindings
	As defined in Section 9.8 of [RFC4918], COPY causes the resource		As defined in Section 9.8 of [RFC4918], COPY causes the resource
	identified by the Request-URI to be duplicated, and makes the new		identified by the Request-URI to be duplicated and makes the new
	resource accessible using the URI specified in the Destination		resource accessible using the URI specified in the Destination
	header. Upon successful completion of a COPY, a new binding is		header. Upon successful completion of a COPY, a new binding is
	created between the last path segment of the Destination header, and		created between the last path segment of the Destination header and
	the destination resource. The new binding is added to its parent		the destination resource. The new binding is added to its parent
	collection, identified by the Destination header minus its final		collection, identified by the Destination header minus its final
	segment.		segment.
	The following figure shows an example: Suppose that a COPY is issued		The following figure shows an example: suppose that a COPY is issued
	to URI-3 for resource R (which is also mapped to URI-1 and URI-2),		to URI-3 for resource R (which is also mapped to URI-1 and URI-2),
	with the Destination header set to URI-X. After successful		with the Destination header set to URI-X. After successful
	completion of the COPY operation, resource R is duplicated to create		completion of the COPY operation, resource R is duplicated to create
	resource R', and a new binding has been created which creates at		resource R', and a new binding has been created that creates at least
	least the URI mapping between URI-X and the new resource (although		the URI mapping between URI-X and the new resource (although other
	other URI mappings may also have been created).		URI mappings may also have been created).
	URI-1 URI-2 URI-3 URI-X		URI-1 URI-2 URI-3 URI-X
	| | | |		| | | |
	| | | <---- URI Mappings ----> |		| | | <---- URI Mappings ----> |
	| | | |		| | | |
	+---------------------+ +------------------------+		+---------------------+ +------------------------+
	| Resource R | | Resource R' |		| Resource R | | Resource R' |
	+---------------------+ +------------------------+		+---------------------+ +------------------------+
	It might be thought that a COPY request with "Depth: 0" on a		It might be thought that a COPY request with "Depth: 0" on a
	skipping to change at page 11, line 35		skipping to change at page 10, line 35
	request does not apply to a collection's members. Consequently, a		request does not apply to a collection's members. Consequently, a
	COPY with "Depth: 0" does not duplicate the bindings contained by the		COPY with "Depth: 0" does not duplicate the bindings contained by the
	collection.		collection.
	If a COPY request causes an existing resource to be updated, the		If a COPY request causes an existing resource to be updated, the
	bindings to that resource MUST be unaffected by the COPY request.		bindings to that resource MUST be unaffected by the COPY request.
	Using the preceding example, suppose that a COPY request is issued to		Using the preceding example, suppose that a COPY request is issued to
	URI-X for resource R', with the Destination header set to URI-2. The		URI-X for resource R', with the Destination header set to URI-2. The
	content and dead properties of resource R would be updated to be a		content and dead properties of resource R would be updated to be a
	copy of those of resource R', but the mappings from URI-1, URI-2, and		copy of those of resource R', but the mappings from URI-1, URI-2, and
	URI-3 to resource R remain unaffected. If because of multiple		URI-3 to resource R remain unaffected. If, because of multiple
	bindings to a resource, more than one source resource updates a		bindings to a resource, more than one source resource updates a
	single destination resource, the order of the updates is server		single destination resource, the order of the updates is server
	defined (see Section 2.3.2 for an example).		defined (see Section 2.3.2 for an example).
	If a COPY request would cause a new resource to be created as a copy		If a COPY request would cause a new resource to be created as a copy
	of an existing resource, and that COPY request has already created a		of an existing resource, and that COPY request has already created a
	copy of that existing resource, the COPY request instead creates		copy of that existing resource, the COPY request instead creates
	another binding to the previous copy, instead of creating a new		another binding to the previous copy, instead of creating a new
	resource (see Section 2.3.3 for an example).		resource (see Section 2.3.3 for an example).
	2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops		2.3.1. Example: COPY with "Depth: infinity" in Presence of Bind Loops
	As an example of how COPY with Depth infinity would work in the		As an example of how COPY with "Depth: infinity" would work in the
	presence of bindings, consider the following collection:		presence of bindings, consider the following collection:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX |		| CollX |
	+------------------+		+------------------+
	|		|
	|		|
	+-------------------------------+		+-------------------------------+
	skipping to change at page 12, line 36		skipping to change at page 11, line 36
	+-------------+ | bindings: | |		+-------------+ | bindings: | |
	| y.gif CollZ | |		| y.gif CollZ | |
	+------------------+ |		+------------------+ |
	| | |		| | |
	| +--------+		| +--------+
	|		|
	+-------------+		+-------------+
	| Resource R2 |		| Resource R2 |
	+-------------+		+-------------+
	If a COPY with Depth infinity is submitted to /CollX, with		If a COPY request with "Depth: infinity" is submitted to /CollX, with
	destination of /CollA, the outcome of the copy operation is:		a destination of /CollA, the outcome of the copy operation is that a
			copy of the tree is replicated to the target /CollA:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX CollA |		| CollX CollA |
	+------------------+		+------------------+
	| |		| |
	| +---------------------------+		| +---------------------------+
	| |		| |
	+-------------------+ |		+-------------------+ |
	skipping to change at page 14, line 5		skipping to change at page 13, line 5
	+-------------+ | bindings: | |		+-------------+ | bindings: | |
	| y.gif CollZ | |		| y.gif CollZ | |
	+-----------------+ |		+-----------------+ |
	| | |		| | |
	| +-------+		| +-------+
	|		|
	+-------------+		+-------------+
	| Resource R4 |		| Resource R4 |
	+-------------+		+-------------+
	2.3.2. Example: COPY updating multiple Bindings		Note that the same would apply for more complex loops.
			2.3.2. Example: COPY Updating Multiple Bindings
	Given the following collection hierarchy:		Given the following collection hierarchy:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX CollY |		| CollX CollY |
	+------------------+		+------------------+
	/ \		/ \
	/ \		/ \
	skipping to change at page 14, line 28		skipping to change at page 13, line 30
	| Collection C1 | | Collection C2 |		| Collection C1 | | Collection C2 |
	| bindings: | | bindings: |		| bindings: | | bindings: |
	| x.gif y.gif | | x.gif y.gif |		| x.gif y.gif | | x.gif y.gif |
	+--------------------------+ +-----------------+		+--------------------------+ +-----------------+
	| | | |		| | | |
	| | | |		| | | |
	+-------------+ +-------------+ +-------------+		+-------------+ +-------------+ +-------------+
	| Resource R1 | | Resource R2 | | Resource R3 |		| Resource R1 | | Resource R2 | | Resource R3 |
	+-------------+ +-------------+ +-------------+		+-------------+ +-------------+ +-------------+
	A COPY of /CollX with Depth infinity to /CollY will not result in a		A COPY of /CollX with "Depth: infinity" to /CollY will not result in
	changed hierarchy, and Resource R3 will be updated with the content		a changed hierarchy, and Resource R3 will be updated with the content
	of either Resource R1 or Resource R2.		of either Resource R1 or Resource R2.
	2.3.3. Example: COPY with 'Depth: infinity' with Multiple Bindings to a		2.3.3. Example: COPY with "Depth: infinity" with Multiple Bindings to a
	Leaf Resource		Leaf Resource
	Given the following collection hierarchy:		Given the following collection hierarchy:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX |		| CollX |
	+------------------+		+------------------+
	|		|
	skipping to change at page 15, line 29		skipping to change at page 14, line 29
	| Collection C1 |		| Collection C1 |
	| bindings: |		| bindings: |
	| x.gif y.gif |		| x.gif y.gif |
	+----------------+		+----------------+
	| |		| |
	| |		| |
	+-------------+		+-------------+
	| Resource R1 |		| Resource R1 |
	+-------------+		+-------------+
	A COPY of /CollX with Depth infinity to /CollY results in the		A COPY of /CollX with "Depth: infinity" to /CollY results in the
	following collection hierarchy:		following collection hierarchy:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX CollY |		| CollX CollY |
	+------------------+		+------------------+
	| \		| \
	| \		| \
	| \		| \
	skipping to change at page 16, line 12		skipping to change at page 15, line 12
	| Resource R1 | | Resource R2 |		| Resource R1 | | Resource R2 |
	+-------------+ +-------------+		+-------------+ +-------------+
	2.4. DELETE and Bindings		2.4. DELETE and Bindings
	When there are multiple bindings to a resource, a DELETE applied to		When there are multiple bindings to a resource, a DELETE applied to
	that resource MUST NOT remove any bindings to that resource other		that resource MUST NOT remove any bindings to that resource other
	than the one identified by the Request-URI. For example, suppose the		than the one identified by the Request-URI. For example, suppose the
	collection identified by the URI "/a" has a binding named "x" to a		collection identified by the URI "/a" has a binding named "x" to a
	resource R, and another collection identified by "/b" has a binding		resource R, and another collection identified by "/b" has a binding
	named "y" to the same resource R. Then a DELETE applied to "/a/x"		named "y" to the same resource R. Then, a DELETE applied to "/a/x"
	removes the binding named "x" from "/a" but MUST NOT remove the		removes the binding named "x" from "/a" but MUST NOT remove the
	binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues		binding named "y" from "/b" (i.e., after the DELETE, "/y/b" continues
	to identify the resource R).		to identify the resource R).
	When DELETE is applied to a collection, it MUST NOT modify the		When DELETE is applied to a collection, it MUST NOT modify the
	membership of any other collection that is not itself a member of the		membership of any other collection that is not itself a member of the
	collection being deleted. For example, if both "/a/.../x" and		collection being deleted. For example, if both "/a/.../x" and
	"/b/.../y" identify the same collection, C, then applying DELETE to		"/b/.../y" identify the same collection, C, then applying DELETE to
	"/a" must not delete an internal member from C or from any other		"/a" must not delete an internal member from C or from any other
	collection that is a member of C, because that would modify the		collection that is a member of C, because that would modify the
	membership of "/b".		membership of "/b".
	skipping to change at page 16, line 39		skipping to change at page 15, line 39
	Request-URI from the collection identified by the Request-URI minus		Request-URI from the collection identified by the Request-URI minus
	its final segment. Although [RFC4918] allows a DELETE to be a non-		its final segment. Although [RFC4918] allows a DELETE to be a non-
	atomic operation, when the DELETE operation is implemented as an		atomic operation, when the DELETE operation is implemented as an
	UNBIND, the operation is atomic. In particular, a DELETE on a		UNBIND, the operation is atomic. In particular, a DELETE on a
	hierarchy of resources is simply the removal of a binding to the		hierarchy of resources is simply the removal of a binding to the
	collection identified by the Request-URI.		collection identified by the Request-URI.
	2.5. MOVE and Bindings		2.5. MOVE and Bindings
	When MOVE is applied to a resource, the other bindings to that		When MOVE is applied to a resource, the other bindings to that
	resource MUST be unaffected, and if the resource being moved is a		resource MUST be unaffected; and if the resource being moved is a
	collection, the bindings to any members of that collection MUST be		collection, the bindings to any members of that collection MUST be
	unaffected. Also, if MOVE is used with Overwrite:T to delete an		unaffected. Also, if MOVE is used with Overwrite:T to delete an
	existing resource, the constraints specified for DELETE apply.		existing resource, the constraints specified for DELETE apply.
	If the destination collection of a MOVE request supports the REBIND		If the destination collection of a MOVE request supports the REBIND
	method (see Section 6), a MOVE of a resource into that collection MAY		method (see Section 6), a MOVE of a resource into that collection MAY
	be implemented as a REBIND request. Although [RFC4918] allows a MOVE		be implemented as a REBIND request. Although [RFC4918] allows a MOVE
	to be a non-atomic operation, when the MOVE operation is implemented		to be a non-atomic operation, when the MOVE operation is implemented
	as a REBIND, the operation is atomic. In particular, applying a MOVE		as a REBIND, the operation is atomic. In particular, applying a MOVE
	to a Request-URI and a Destination URI has the effect of removing a		to a Request-URI and a Destination URI has the effect of removing a
	binding to a resource (at the Request-URI), and creating a new		binding to a resource (at the Request-URI) and creating a new binding
	binding to that resource (at the Destination URI). Even when the		to that resource (at the Destination URI). Even when the Request-URI
	Request-URI identifies a collection, the MOVE operation involves only		identifies a collection, the MOVE operation involves only removing
	removing one binding to that collection and adding another.		one binding to that collection and adding another.
	2.5.1. Example: Simple MOVE		2.5.1. Example: Simple MOVE
	As an example, suppose that a MOVE is issued to URI-3 for resource R		As an example, suppose that a MOVE is issued to URI-3 for resource R
	below (which is also mapped to URI-1 and URI-2), with the Destination		below (which is also mapped to URI-1 and URI-2), with the Destination
	header set to URI-X. After successful completion of the MOVE		header set to URI-X. After successful completion of the MOVE
	operation, a new binding has been created which creates the URI		operation, a new binding has been created that creates the URI
	mapping between URI-X and resource R. The binding corresponding to		mapping between URI-X and resource R. The binding corresponding to
	the final segment of URI-3 has been removed, which also causes the		the final segment of URI-3 has been removed, which also causes the
	URI mapping between URI-3 and R to be removed. If resource R were a		URI mapping between URI-3 and R to be removed. If resource R were a
	collection, old URI-3 based mappings to members of R would have been		collection, old URI-3-based mappings to members of R would have been
	removed, and new URI-X based mappings to members of R would have been		removed, and new URI-X-based mappings to members of R would have been
	created.		created.
	>> Before Request:		>> Before Request:
	URI-1 URI-2 URI-3		URI-1 URI-2 URI-3
	| | |		| | |
	| | | <---- URI Mappings		| | | <---- URI Mappings
	| | |		| | |
	+---------------------+		+---------------------+
	| Resource R |		| Resource R |
	skipping to change at page 17, line 39		skipping to change at page 16, line 41
	>> After Request:		>> After Request:
	URI-1 URI-2 URI-X		URI-1 URI-2 URI-X
	| | |		| | |
	| | | <---- URI Mappings		| | | <---- URI Mappings
	| | |		| | |
	+---------------------+		+---------------------+
	| Resource R |		| Resource R |
	+---------------------+		+---------------------+
	2.5.2. Example: MOVE Request causing a Bind Loop		2.5.2. Example: MOVE Request Causing a Bind Loop
	Note that in the presence of collection bindings, a MOVE request can		Note that in the presence of collection bindings, a MOVE request can
	cause the creating of a bind loop.		cause the creation of a bind loop.
	Consider a the top level collections C1 and C2 with URIs "/CollW/"		Consider the top-level collections C1 and C2 with URIs "/CollW/" and
	and "/CollX/". C1 also contains an additional binding named "CollY"		"/CollX/". C1 also contains an additional binding named "CollY" to
	to C2:		C2:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollW CollX |		| CollW CollX |
	+------------------+		+------------------+
	| |		| |
	| |		| |
	+------------------+ |		+------------------+ |
	| Collection C1 | |		| Collection C1 | |
	skipping to change at page 19, line 33		skipping to change at page 18, line 33
	| | CollZ |		| | CollZ |
	| +------------------+		| +------------------+
	| |		| |
	| |		| |
	+-------------------+		+-------------------+
	2.6. PROPFIND and Bindings		2.6. PROPFIND and Bindings
	Consistent with [RFC4918], the value of a dead property MUST be		Consistent with [RFC4918], the value of a dead property MUST be
	independent of the number of bindings to its host resource or of the		independent of the number of bindings to its host resource or of the
	path submitted to PROPFIND. On the other hand, the behaviour for		path submitted to PROPFIND. On the other hand, the behavior for each
	each live property depends on its individual definition (for example,		live property depends on its individual definition (for example, see
	see [RFC3744], Section 5, paragraph 2 for a case where the value is		[RFC3744], Section 5, Paragraph 2 for a case where the value is
	independent of path and bindings, and [RFC4918], Section 8.8 for a		independent of its path and bindings, and [RFC4918], Section 8.8 for
	discussion about the live properties DAV:getetag and DAV:		a discussion about the live properties DAV:getetag and DAV:
	getlastmodified, which may behave differently).		getlastmodified, which may behave differently).
	2.7. Determining Whether Two Bindings Are to the Same Resource		2.7. Determining Whether Two Bindings Are to the Same Resource
	It is useful to have some way of determining whether two bindings are		It is useful to have some way of determining whether two bindings are
	to the same resource. Two resources might have identical contents		to the same resource. Two resources might have identical contents
	and properties, but not be the same resource (e.g. an update to one		and properties, but not be the same resource (e.g., an update to one
	resource does not affect the other resource).		resource does not affect the other resource).
	The REQUIRED DAV:resource-id property defined in Section 3.1 is a		The REQUIRED DAV:resource-id property defined in Section 3.1 is a
	resource identifier, which MUST be unique across all resources for		resource identifier, which MUST be unique across all resources for
	all time. If the values of DAV:resource-id returned by PROPFIND		all time. If the values of DAV:resource-id returned by PROPFIND
	requests through two bindings are identical character by character,		requests through two bindings are identical character by character,
	the client can be assured that the two bindings are to the same		the client can be assured that the two bindings are to the same
	resource.		resource.
	The DAV:resource-id property is created, and its value assigned, when		The DAV:resource-id property is created, and its value assigned, when
	skipping to change at page 20, line 35		skipping to change at page 19, line 37
	2.8. Discovering the Bindings to a Resource		2.8. Discovering the Bindings to a Resource
	An OPTIONAL DAV:parent-set property on a resource provides a list of		An OPTIONAL DAV:parent-set property on a resource provides a list of
	the bindings that associate a collection and a URI segment with that		the bindings that associate a collection and a URI segment with that
	resource. If the DAV:parent-set property exists on a given resource,		resource. If the DAV:parent-set property exists on a given resource,
	it MUST contain a complete list of all bindings to that resource that		it MUST contain a complete list of all bindings to that resource that
	the client is authorized to see. When deciding whether to support		the client is authorized to see. When deciding whether to support
	the DAV:parent-set property, server implementers / administrators		the DAV:parent-set property, server implementers / administrators
	should balance the benefits it provides against the cost of		should balance the benefits it provides against the cost of
	maintaining the property and the security risks enumerated in		maintaining the property and the security risks enumerated in
	Sections 11.4 and 11.5.		Sections 12.4 and 12.5.
	3. Properties		3. Properties
	The bind feature introduces the properties defined below.		The bind feature introduces the properties defined below.
	A DAV:allprop PROPFIND request SHOULD NOT return any of the		A DAV:allprop PROPFIND request SHOULD NOT return any of the
	properties defined by this document. This allows a binding server to		properties defined by this document. This allows a binding server to
	perform efficiently when a naive client, which does not understand		perform efficiently when a naive client, which does not understand
	the cost of asking a server to compute all possible live properties,		the cost of asking a server to compute all possible live properties,
	issues a DAV:allprop PROPFIND request.		issues a DAV:allprop PROPFIND request.
	skipping to change at page 21, line 4		skipping to change at page 20, line 9
	A DAV:allprop PROPFIND request SHOULD NOT return any of the		A DAV:allprop PROPFIND request SHOULD NOT return any of the
	properties defined by this document. This allows a binding server to		properties defined by this document. This allows a binding server to
	perform efficiently when a naive client, which does not understand		perform efficiently when a naive client, which does not understand
	the cost of asking a server to compute all possible live properties,		the cost of asking a server to compute all possible live properties,
	issues a DAV:allprop PROPFIND request.		issues a DAV:allprop PROPFIND request.
	3.1. DAV:resource-id Property		3.1. DAV:resource-id Property
	The DAV:resource-id property is a REQUIRED property that enables		The DAV:resource-id property is a REQUIRED property that enables
	clients to determine whether two bindings are to the same resource.		clients to determine whether two bindings are to the same resource.
	The value of DAV:resource-id is a URI, and may use any registered URI		The value of DAV:resource-id is a URI, and may use any registered URI
	scheme that guarantees the uniqueness of the value across all		scheme that guarantees the uniqueness of the value across all
	resources for all time (e.g. the urn:uuid: URN namespace defined in		resources for all time (e.g., the urn:uuid: URN namespace defined in
	[RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]).		[RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]).
	<!ELEMENT resource-id (href)>		<!ELEMENT resource-id (href)>
	3.2. DAV:parent-set Property		3.2. DAV:parent-set Property
	The DAV:parent-set property is an OPTIONAL property that enables		The DAV:parent-set property is an OPTIONAL property that enables
	clients to discover what collections contain a binding to this		clients to discover what collections contain a binding to this
	resource (i.e. what collections have that resource as an internal		resource (i.e., what collections have that resource as an internal
	member). It contains an href/segment pair for each collection that		member). It contains an href/segment pair for each collection that
	has a binding to the resource. The href identifies the collection,		has a binding to the resource. The href identifies the collection,
	and the segment identifies the binding name of that resource in that		and the segment identifies the binding name of that resource in that
	collection.		collection.
	A given collection MUST appear only once in the DAV:parent-set for		A given collection MUST appear only once in the DAV:parent-set for
	any given binding, even if there are multiple URI mappings to that		any given binding, even if there are multiple URI mappings to that
	collection.		collection.
	<!ELEMENT parent-set (parent)*>		<!ELEMENT parent-set (parent)*>
	skipping to change at page 21, line 39		skipping to change at page 20, line 43
	<!-- PCDATA value: segment, as defined in Section 3.3 of		<!-- PCDATA value: segment, as defined in Section 3.3 of
	[RFC3986] -->		[RFC3986] -->
	3.2.1. Example for DAV:parent-set Property		3.2.1. Example for DAV:parent-set Property
	For example, if collection C1 is mapped to both /CollX and /CollY,		For example, if collection C1 is mapped to both /CollX and /CollY,
	and C1 contains a binding named "x.gif" to a resource R1, then either		and C1 contains a binding named "x.gif" to a resource R1, then either
	[/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set		[/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set
	of R1, but not both. But if C1 also had a binding named "y.gif" to		of R1, but not both. But if C1 also had a binding named "y.gif" to
	R1, then there would be two entries for C1 in the DAV:parent-set of		R1, then there would be two entries for C1 in the DAV:parent-set of
	R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively,		R1 (i.e., both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively,
	both [/CollY, x.gif] and [/CollY, y.gif]).		both [/CollY, x.gif] and [/CollY, y.gif]).
	+-------------------------+		+-------------------------+
	| Root Collection |		| Root Collection |
	| bindings: |		| bindings: |
	| CollX CollY |		| CollX CollY |
	+-------------------------+		+-------------------------+
	| /		| /
	| /		| /
	| /		| /
	skipping to change at page 22, line 25		skipping to change at page 21, line 25
	| bindings: |		| bindings: |
	| x.gif y.gif |		| x.gif y.gif |
	+-----------------+		+-----------------+
	| |		| |
	| |		| |
	| |		| |
	+-------------+		+-------------+
	| Resource R1 |		| Resource R1 |
	+-------------+		+-------------+
	In this case, one possible value for DAV:parent-set property on		In this case, one possible value for the DAV:parent-set property on
	"/CollX/x.gif" would be:		"/CollX/x.gif" would be:
	<parent-set xmlns="DAV:">		<parent-set xmlns="DAV:">
	<parent>		<parent>
	<href>/CollX</href>		<href>/CollX</href>
	<segment>x.gif</segment>		<segment>x.gif</segment>
	</parent>		</parent>
	<parent>		<parent>
	<href>/CollX</href>		<href>/CollX</href>
	<segment>y.gif</segment>		<segment>y.gif</segment>
	skipping to change at page 23, line 4		skipping to change at page 21, line 51
	The BIND method modifies the collection identified by the Request-		The BIND method modifies the collection identified by the Request-
	URI, by adding a new binding from the segment specified in the BIND		URI, by adding a new binding from the segment specified in the BIND
	body to the resource identified in the BIND body.		body to the resource identified in the BIND body.
	If a server cannot guarantee the integrity of the binding, the BIND		If a server cannot guarantee the integrity of the binding, the BIND
	request MUST fail. Note that it is especially difficult to maintain		request MUST fail. Note that it is especially difficult to maintain
	the integrity of cross-server bindings. Unless the server where the		the integrity of cross-server bindings. Unless the server where the
	resource resides knows about all bindings on all servers to that		resource resides knows about all bindings on all servers to that
	resource, it may unwittingly destroy the resource or make it		resource, it may unwittingly destroy the resource or make it
	inaccessible without notifying another server that manages a binding		inaccessible without notifying another server that manages a binding
	to the resource. For example, if server A permits creation of a		to the resource. For example, if server A permits the creation of a
	binding to a resource on server B, server A must notify server B		binding to a resource on server B, server A must notify server B
	about its binding and must have an agreement with B that B will not		about its binding and must have an agreement with B that B will not
	destroy the resource while A's binding exists. Otherwise server B		destroy the resource while A's binding exists. Otherwise, server B
	may receive a DELETE request that it thinks removes the last binding		may receive a DELETE request that it thinks removes the last binding
	to the resource and destroy the resource while A's binding still		to the resource and destroy the resource while A's binding still
	exists. The precondition DAV:cross-server-binding is defined below		exists. The precondition DAV:cross-server-binding is defined below
	for cases where servers fail cross-server BIND requests because they		for cases where servers fail cross-server BIND requests because they
	cannot guarantee the integrity of cross-server bindings.		cannot guarantee the integrity of cross-server bindings.
	By default, if there already is a binding for the specified segment		By default, if there already is a binding for the specified segment
	in the collection, the new binding replaces the existing binding.		in the collection, the new binding replaces the existing binding.
	This default binding replacement behavior can be overridden using the		This default binding replacement behavior can be overridden using the
	Overwrite header defined in Section 10.6 of [RFC4918].		Overwrite header defined in Section 10.6 of [RFC4918].
	skipping to change at page 24, line 35		skipping to change at page 23, line 35
	URI namespace (servers that do not support cycles can use this		URI namespace (servers that do not support cycles can use this
	condition code to signal the client exactly why the request		condition code to signal the client exactly why the request
	failed).		failed).
	(DAV:locked-update-allowed): If the collection identified by the		(DAV:locked-update-allowed): If the collection identified by the
	Request-URI is write-locked, then the appropriate token MUST be		Request-URI is write-locked, then the appropriate token MUST be
	specified in an If request header.		specified in an If request header.
	(DAV:locked-overwrite-allowed): If the collection already contains		(DAV:locked-overwrite-allowed): If the collection already contains
	a binding with the specified path segment, and if that binding is		a binding with the specified path segment, and if that binding is
	protected by a write-lock, then the appropriate token MUST be		protected by a write lock, then the appropriate token MUST be
	specified in an If request header.		specified in an If request header.
	Postconditions:		Postconditions:
	(DAV:new-binding): The collection MUST have a binding that maps		(DAV:new-binding): The collection MUST have a binding that maps
	the segment specified in the DAV:segment element in the request		the segment specified in the DAV:segment element in the request
	body, to the resource identified by the DAV:href element in the		body to the resource identified by the DAV:href element in the
	request body.		request body.
	4.1. Example: BIND		4.1. Example: BIND
	>> Request:		>> Request:
	BIND /CollY HTTP/1.1		BIND /CollY HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: 172		Content-Length: 172
	skipping to change at page 25, line 35		skipping to change at page 24, line 35
	The server added a new binding to the collection,		The server added a new binding to the collection,
	"http://www.example.com/CollY", associating "bar.html" with the		"http://www.example.com/CollY", associating "bar.html" with the
	resource identified by the URI		resource identified by the URI
	"http://www.example.com/CollX/foo.html". Clients can now use the URI		"http://www.example.com/CollX/foo.html". Clients can now use the URI
	"http://www.example.com/CollY/bar.html" to submit requests to that		"http://www.example.com/CollY/bar.html" to submit requests to that
	resource.		resource.
	5. UNBIND Method		5. UNBIND Method
	The UNBIND method modifies the collection identified by the Request-		The UNBIND method modifies the collection identified by the Request-
	URI, by removing the binding identified by the segment specified in		URI by removing the binding identified by the segment specified in
	the UNBIND body.		the UNBIND body.
	Once a resource is unreachable by any URI mapping, the server MAY		Once a resource is unreachable by any URI mapping, the server MAY
	reclaim system resources associated with that resource. If UNBIND		reclaim system resources associated with that resource. If UNBIND
	removes a binding to a resource, but there remain URI mappings to		removes a binding to a resource, but there remain URI mappings to
	that resource, the server MUST NOT reclaim system resources		that resource, the server MUST NOT reclaim system resources
	associated with the resource.		associated with the resource.
	If an UNBIND request fails, the server state preceding the request		If an UNBIND request fails, the server state preceding the request
	MUST be restored. This method is unsafe and idempotent (see		MUST be restored. This method is unsafe and idempotent (see
	skipping to change at page 26, line 32		skipping to change at page 25, line 29
	collection.		collection.
	(DAV:unbind-source-exists): The DAV:segment element MUST identify		(DAV:unbind-source-exists): The DAV:segment element MUST identify
	a binding in the collection identified by the Request-URI.		a binding in the collection identified by the Request-URI.
	(DAV:locked-update-allowed): If the collection identified by the		(DAV:locked-update-allowed): If the collection identified by the
	Request-URI is write-locked, then the appropriate token MUST be		Request-URI is write-locked, then the appropriate token MUST be
	specified in the request.		specified in the request.
	(DAV:protected-url-deletion-allowed): If the binding identified by		(DAV:protected-url-deletion-allowed): If the binding identified by
	the segment is protected by a write-lock, then the appropriate		the segment is protected by a write lock, then the appropriate
	token MUST be specified in the request.		token MUST be specified in the request.
	Postconditions:		Postconditions:
	(DAV:binding-deleted): The collection MUST NOT have a binding for		(DAV:binding-deleted): The collection MUST NOT have a binding for
	the segment specified in the DAV:segment element in the request		the segment specified in the DAV:segment element in the request
	body.		body.
	(DAV:lock-deleted): If the internal member URI of the binding		(DAV:lock-deleted): If the internal member URI of the binding
	specified by the Request-URI and the DAV:segment element in the		specified by the Request-URI and the DAV:segment element in the
	request body was protected by a write-lock at the time of the		request body was protected by a write lock at the time of the
	request, that write-lock must have been deleted by the request.		request, that write lock must have been deleted by the request.
	5.1. Example: UNBIND		5.1. Example: UNBIND
	>> Request:		>> Request:
	UNBIND /CollX HTTP/1.1		UNBIND /CollX HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: 117		Content-Length: 117
	skipping to change at page 28, line 50		skipping to change at page 27, line 50
	condition code to signal the client exactly why the request		condition code to signal the client exactly why the request
	failed).		failed).
	(DAV:locked-update-allowed): If the collection identified by the		(DAV:locked-update-allowed): If the collection identified by the
	Request-URI is write-locked, then the appropriate token MUST be		Request-URI is write-locked, then the appropriate token MUST be
	specified in the request.		specified in the request.
	(DAV:protected-url-modification-allowed): If the collection		(DAV:protected-url-modification-allowed): If the collection
	identified by the Request-URI already contains a binding with the		identified by the Request-URI already contains a binding with the
	specified path segment, and if that binding is protected by a		specified path segment, and if that binding is protected by a
	write-lock, then the appropriate token MUST be specified in the		write lock, then the appropriate token MUST be specified in the
	request.		request.
	(DAV:locked-source-collection-update-allowed): If the collection		(DAV:locked-source-collection-update-allowed): If the collection
	identified by the parent collection prefix of the DAV:href URI is		identified by the parent collection prefix of the DAV:href URI is
	write-locked, then the appropriate token MUST be specified in the		write-locked, then the appropriate token MUST be specified in the
	request.		request.
	(DAV:protected-source-url-deletion-allowed): If the DAV:href URI		(DAV:protected-source-url-deletion-allowed): If the DAV:href URI
	is protected by a write lock, then the appropriate token MUST be		is protected by a write lock, then the appropriate token MUST be
	specified in the request.		specified in the request.
	skipping to change at page 29, line 25		skipping to change at page 28, line 25
	(DAV:new-binding): The collection MUST have a binding that maps		(DAV:new-binding): The collection MUST have a binding that maps
	the segment specified in the DAV:segment element in the request		the segment specified in the DAV:segment element in the request
	body, to the resource that was identified by the DAV:href element		body, to the resource that was identified by the DAV:href element
	in the request body.		in the request body.
	(DAV:binding-deleted): The URL specified in the DAV:href element		(DAV:binding-deleted): The URL specified in the DAV:href element
	in the request body MUST NOT be mapped to a resource.		in the request body MUST NOT be mapped to a resource.
	(DAV:lock-deleted): If the URL specified in the DAV:href element		(DAV:lock-deleted): If the URL specified in the DAV:href element
	in the request body was protected by a write-lock at the time of		in the request body was protected by a write lock at the time of
	the request, that write-lock must have been deleted by the		the request, that write lock must have been deleted by the
	request.		request.
	6.1. Example: REBIND		6.1. Example: REBIND
	>> Request:		>> Request:
	REBIND /CollX HTTP/1.1		REBIND /CollX HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: 176		Content-Length: 176
	skipping to change at page 29, line 51		skipping to change at page 28, line 51
	<D:href>http://www.example.com/CollY/bar.html</D:href>		<D:href>http://www.example.com/CollY/bar.html</D:href>
	</D:rebind>		</D:rebind>
	>> Response:		>> Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	The server added a new binding to the collection,		The server added a new binding to the collection,
	"http://www.example.com/CollX", associating "foo.html" with the		"http://www.example.com/CollX", associating "foo.html" with the
	resource identified by the URI		resource identified by the URI
	"http://www.example.com/CollY/bar.html", and removes the binding		"http://www.example.com/CollY/bar.html" and removes the binding named
	named "bar.html" from the collection identified by the URI		"bar.html" from the collection identified by the URI
	"http://www.example.com/CollY". Clients can now use the URI		"http://www.example.com/CollY". Clients can now use the URI
	"http://www.example.com/CollX/foo.html" to submit requests to that		"http://www.example.com/CollX/foo.html" to submit requests to that
	resource, and requests on the URI		resource, and requests on the URI
	"http://www.example.com/CollY/bar.html" will fail with a 404 (Not		"http://www.example.com/CollY/bar.html" will fail with a 404 (Not
	Found) response.		Found) response.
	6.2. Example: REBIND in Presence of Locks and Bind Loops		6.2. Example: REBIND in Presence of Locks and Bind Loops
	To illustrate the effects of locks and bind loops on a REBIND		To illustrate the effects of locks and bind loops on a REBIND
	operation, consider the following collection:		operation, consider the following collection:
	skipping to change at page 33, line 16		skipping to change at page 32, line 16
	requests, and that it is of particular importance when the multiple		requests, and that it is of particular importance when the multiple
	collection bindings cause a bind loop as discussed in Section 2.2.		collection bindings cause a bind loop as discussed in Section 2.2.
	A client can request the DAV:resource-id property in a PROPFIND		A client can request the DAV:resource-id property in a PROPFIND
	request to guarantee that they can accurately reconstruct the binding		request to guarantee that they can accurately reconstruct the binding
	structure of a collection with multiple bindings to a single		structure of a collection with multiple bindings to a single
	resource.		resource.
	For backward compatibility with clients not aware of the 208 status		For backward compatibility with clients not aware of the 208 status
	code appearing in multistatus response bodies, it SHOULD NOT be used		code appearing in multistatus response bodies, it SHOULD NOT be used
	unless the client has signalled support for this specification using		unless the client has signaled support for this specification using
	the "DAV" request header (see Section 8.2). Instead, a 506 status		the "DAV" request header (see Section 8.2). Instead, a 508 status
	should be returned when a binding loop is discovered. This allows		should be returned when a binding loop is discovered. This allows
	the server to return the 506 as the top level return status, if it		the server to return the 508 as the top-level return status, if it
	discovers it before it started the response, or in the middle of a		discovers it before it started the response, or in the middle of a
	multistatus, if it discovers it in the middle of streaming out a		multistatus, if it discovers it in the middle of streaming out a
	multistatus response.		multistatus response.
	7.1.1. Example: PROPFIND by Bind-Aware Client		7.1.1. Example: PROPFIND by Bind-Aware Client
	For example, consider a PROPFIND request on /Coll (bound to		For example, consider a PROPFIND request on /Coll (bound to
	collection C), where the members of /Coll are /Coll/Foo (bound to		collection C), where the members of /Coll are /Coll/Foo (bound to
	resource R) and /Coll/Bar (bound to collection C).		resource R) and /Coll/Bar (bound to collection C).
	skipping to change at page 35, line 10		skipping to change at page 34, line 10
	<D:status>HTTP/1.1 208 Already Reported</D:status>		<D:status>HTTP/1.1 208 Already Reported</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	7.1.2. Example: PROPFIND by Non-Bind-Aware Client		7.1.2. Example: PROPFIND by Non-Bind-Aware Client
	In this example, the client isn't aware of the 208 status code		In this example, the client isn't aware of the 208 status code
	introduced by this specification. As the "Depth: infinity" PROPFIND		introduced by this specification. As the "Depth: infinity" PROPFIND
	request would cause a loop condition, the whole request is rejected		request would cause a loop condition, the whole request is rejected
	with a 506 status.		with a 508 status.
	>> Request:		>> Request:
	PROPFIND /Coll/ HTTP/1.1		PROPFIND /Coll/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Depth: infinity		Depth: infinity
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: 125		Content-Length: 125
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:propfind xmlns:D="DAV:">		<D:propfind xmlns:D="DAV:">
	<D:prop> <D:displayname/> </D:prop>		<D:prop> <D:displayname/> </D:prop>
	</D:propfind>		</D:propfind>
	>> Response:		>> Response:
	HTTP/1.1 506 Loop Detected		HTTP/1.1 508 Loop Detected
	7.2. 506 Loop Detected		7.2. 508 Loop Detected
	The 506 (Loop Detected) status code indicates that the server		The 508 (Loop Detected) status code indicates that the server
	terminated an operation because it encountered an infinite loop while		terminated an operation because it encountered an infinite loop while
	processing a request with "Depth: infinity". This status indicates		processing a request with "Depth: infinity". This status indicates
	that the entire operation failed.		that the entire operation failed.
	8. Capability Discovery		8. Capability Discovery
	8.1. OPTIONS Method		8.1. OPTIONS Method
	If the server supports bindings, it MUST return the compliance class		If the server supports bindings, it MUST return the compliance class
	name "bind" as a field in the "DAV" response header (see [RFC4918],		name "bind" as a field in the "DAV" response header (see [RFC4918],
	Section 10.1) from an OPTIONS request on any resource implemented by		Section 10.1) from an OPTIONS request on any resource implemented by
	that server. A value of "bind" in the "DAV" header MUST indicate		that server. A value of "bind" in the "DAV" header MUST indicate
	that the server supports all MUST level requirements and REQUIRED		that the server supports all MUST-level requirements and REQUIRED
	features specified in this document.		features specified in this document.
	8.2. 'DAV' Request Header		8.2. 'DAV' Request Header
	Clients SHOULD signal support for all MUST level requirements and		Clients SHOULD signal support for all MUST-level requirements and
	REQUIRED features by submitting a "DAV" request header containing the		REQUIRED features by submitting a "DAV" request header containing the
	compliance class name "bind". In particular, the client MUST		compliance class name "bind". In particular, the client MUST
	understand the 208 status code defined in Section 7.1.		understand the 208 status code defined in Section 7.1.
	9. Relationship to WebDAV Access Control Protocol		9. Relationship to Locking in WebDAV
	BIND and REBIND behave the same as MOVE with respect to the DAV:acl		Locking is an optional feature of WebDAV ([RFC4918]). The base
	property (see [RFC3744], Section 7.3).		WebDAV specification and this protocol extension have been designed
			in parallel, making sure that all features of WebDAV can be
			implemented on a server that implements this protocol as well.
	10. Relationship to Versioning Extensions to WebDAV		Unfortunately, WebDAV uses the term "lock-root" inconsistently. It
			is introduced in Section 6.1 of [RFC4918], point 2, as:
	Servers that implement Workspaces ([RFC3253], Section 6) and Version		2. A resource becomes directly locked when a LOCK request to a
			URL of that resource creates a new lock. The "lock-root" of the
			new lock is that URL. If at the time of the request, the URL is
			not mapped to a resource, a new empty resource is created and
			directly locked.
			On the other hand, [RFC4918], Section 9.10.1 states:
			A LOCK request to an existing resource will create a lock on the
			resource identified by the Request-URI, provided the resource is
			not already locked with a conflicting lock. The resource
			identified in the Request-URI becomes the root of the lock.
			Servers that implement both WebDAV locking and support for multiple
			bindings MUST use the first interpretation: the lock-root is the URI
			through which the lock was created, not a resource. This URI, and
			potential aliases of this URI ([RFC4918], Section 5), are said to be
			"protected" by the lock.
			As defined in the introduction to Section 7 of [RFC4918], write
			operations that modify the state of a locked resource require that
			the lock token is submitted with the request. Consistent with
			WebDAV, the state of the resource consists of the content ("any
			variant"), dead properties, lockable live properties (item 1), plus,
			for a collection, all its bindings (item 2). Note that this, by
			definition, does not depend on the Request-URI to which the write
			operation is applied (the locked state is a property of the resource,
			not its URI).
			However, the lock-root is the URI through which the lock was
			requested. Thus, the protection defined in item 3 of the list does
			not apply to additional URIs that may be mapped to the same resource
			due to the existence of multiple bindings.
			9.1. Example: Locking and Multiple Bindings
			Consider a root collection "/", containing the two collections C1 and
			C2, named "/CollX" and "/CollY", and a child resource R, bound to C1
			as "/CollX/test" and bound to C2 as "/CollY/test":
			+-------------------------+
			| Root Collection |
			| bindings: |
			| CollX CollY |
			+-------------------------+
			| |
			| |
			| |
			+---------------+ +---------------+
			| Collection C1 | | Collection C2 |
			| bindings: | | bindings: |
			| test | | test |
			+---------------+ +---------------+
			| |
			| |
			| |
			+------------------+
			| Resource R |
			+------------------+
			Given a host name of "www.example.com", applying a depth-zero write
			lock to "/CollX/test" will lock the resource R, and the lock-root of
			this lock will be "http://www.example.com/CollX/test".
			Thus, the following operations will require that the associated lock
			token is submitted with the "If" request header ([RFC4918], Section
			10.4):
			o a PUT or PROPPATCH request modifying the content or lockable
			properties of resource R (as R is locked) -- no matter which URI
			is used as request target, and
			o a MOVE, REBIND, UNBIND, or DELETE request causing "/CollX/test"
			not to be mapped to resource R anymore (be it addressed to
			"/CollX" or "/CollX/test").
			The following operations will not require submission of the lock
			token:
			o a DELETE request addressed to "/CollY" or "/CollY/test", as it
			does not affect the resource R, nor the lock-root,
			o for the same reason, an UNBIND request removing the binding "test"
			from collection C2, or the binding "CollY" from the root
			collection, and
			o similarly, a MOVE or REBIND request causing "/CollY/test" not
			being mapped to resource R anymore.
			Note that despite the lock-root being
			"http://www.example.com/CollX/test", an UNLOCK request can be
			addressed through any URI mapped to resource R, as UNLOCK operates on
			the resource identified by the Request-URI, not that URI (see
			[RFC4918], Section 9.11).
			10. Relationship to WebDAV Access Control Protocol
			Note that the WebDAV Access Control Protocol has been designed for
			compatibility with systems that allow multiple URIs to map to the
			same resource (see [RFC3744], Section 5):
			Access control properties (especially DAV:acl and DAV:inherited-
			acl-set) are defined on the resource identified by the Request-URI
			of a PROPFIND request. A direct consequence is that if the
			resource is accessible via multiple URI, the value of access
			control properties is the same across these URI.
			Furthermore, note that BIND and REBIND behave the same as MOVE with
			respect to the DAV:acl property (see [RFC3744], Section 7.3).
			11. Relationship to Versioning Extensions to WebDAV
			Servers that implement Workspaces ([RFC3253], Section 6) and Version-
	Controlled Collections ([RFC3253], Section 14) already need to		Controlled Collections ([RFC3253], Section 14) already need to
	implement BIND-like behaviour in order to handle UPDATE and		implement BIND-like behavior in order to handle UPDATE and UNCHECKOUT
	UNCHECKOUT semantics.		semantics.
	Consider a workspace "/ws1/", containing the version-controlled,		Consider a workspace "/ws1/", containing the version-controlled,
	checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/		checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
	CollY", and a version-controlled resource R, bound to C1 as "/ws1/		CollY", and a version-controlled resource R, bound to C1 as "/ws1/
	CollX/test":		CollX/test":
	+-------------------------+		+-------------------------+
	| Workspace |		| Workspace |
	| bindings: |		| bindings: |
	| CollX CollY |		| CollX CollY |
	skipping to change at page 38, line 31		skipping to change at page 39, line 42
	+------------------+		+------------------+
	| Resource R |		| Resource R |
	+------------------+		+------------------+
	The MOVE semantics defined in Section 3.15 of [RFC3253] already		The MOVE semantics defined in Section 3.15 of [RFC3253] already
	require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the		require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the
	same version history (as exposed in the DAV:version-history		same version history (as exposed in the DAV:version-history
	property). Furthermore, the UNCHECKOUT semantics (which in this case		property). Furthermore, the UNCHECKOUT semantics (which in this case
	is similar to UPDATE, see Section 14.11 of [RFC3253]) require:		is similar to UPDATE, see Section 14.11 of [RFC3253]) require:
	...If a new version-controlled member is in a workspace that		If a new version-controlled member is in a workspace that already
	already has a version-controlled resource for that version		has a version-controlled resource for that version history, then
	history, then the new version-controlled member MUST be just a		the new version-controlled member MUST be just a binding (i.e.,
	binding (i.e., another name for) that existing version-controlled		another name for) that existing version-controlled resource.
	resource...
	Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the		Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the
	same resource R, and have identical DAV:resource-id properties.		same resource R, and have identical DAV:resource-id properties.
	11. Security Considerations		12. Security Considerations
	This section is provided to make WebDAV implementors aware of the		This section is provided to make WebDAV implementers 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 ([RFC2616], Section
	Distributed Authoring Protocol specification also apply to this		15) and the WebDAV Distributed Authoring Protocol specification
	protocol specification. In addition, bindings introduce several new		([RFC4918], Section 20) also apply to this protocol specification.
	security concerns and increase the risk of some existing threats.		In addition, bindings introduce several new security concerns and
	These issues are detailed below.		increase the risk of some existing threats. These issues are
			detailed below.
	11.1. Privacy Concerns		12.1. Privacy Concerns
	In a context where cross-server bindings are supported, creating		In a context where cross-server bindings are supported, creating
	bindings on a trusted server may make it possible for a hostile agent		bindings on a trusted server may make it possible for a hostile agent
	to induce users to send private information to a target on a		to induce users to send private information to a target on a
	different server.		different server.
	11.2. Bind Loops		12.2. Bind Loops
	Although bind loops were already possible in HTTP 1.1, the		Although bind loops were already possible in HTTP 1.1, the
	introduction of the BIND method creates a new avenue for clients to		introduction of the BIND method creates a new avenue for clients to
	create loops accidentally or maliciously. If the binding and its		create loops accidentally or maliciously. If the binding and its
	target are on the same server, the server may be able to detect BIND		target are on the same server, the server may be able to detect BIND
	requests that would create loops. Servers are required to detect		requests that would create loops. Servers are required to detect
	loops that are caused by bindings to collections during the		loops that are caused by bindings to collections during the
	processing of any requests with "Depth: infinity".		processing of any requests with "Depth: infinity".
	11.3. Bindings, and Denial of Service		12.3. Bindings and Denial of Service
	Denial of service attacks were already possible by posting URIs that		Denial-of-service attacks were already possible by posting URIs that
	were intended for limited use at heavily used Web sites. The		were intended for limited use at heavily used Web sites. The
	introduction of BIND creates a new avenue for similar denial of		introduction of BIND creates a new avenue for similar denial-of-
	service attacks. If cross-server bindings are supported, clients can		service attacks. If cross-server bindings are supported, clients can
	now create bindings at heavily used sites to target locations that		now create bindings at heavily used sites to target locations that
	were not designed for heavy usage.		were not designed for heavy usage.
	11.4. Private Locations May Be Revealed		12.4. Private Locations May Be Revealed
	If the DAV:parent-set property is maintained on a resource, the		If the DAV:parent-set property is maintained on a resource, the
	owners of the bindings risk revealing private locations. The		owners of the bindings risk revealing private locations. The
	directory structures where bindings are located are available to		directory structures where bindings are located are available to
	anyone who has access to the DAV:parent-set property on the resource.		anyone who has access to the DAV:parent-set property on the resource.
	Moving a binding may reveal its new location to anyone with access to		Moving a binding may reveal its new location to anyone with access to
	DAV:parent-set on its resource.		DAV:parent-set on its resource.
	11.5. DAV:parent-set and Denial of Service		12.5. DAV:parent-set and Denial of Service
	If the server maintains the DAV:parent-set property in response to		If the server maintains the DAV:parent-set property in response to
	bindings created in other administrative domains, it is exposed to		bindings created in other administrative domains, it is exposed to
	hostile attempts to make it devote resources to adding bindings to		hostile attempts to make it devote resources to adding bindings to
	the list.		the list.
	12. Internationalization Considerations		13. Internationalization Considerations
	All internationalization considerations mentioned in [RFC4918] also		All internationalization considerations mentioned in Section 19 of
	apply to this document.		[RFC4918] also apply to this document.
	13. IANA Considerations		14. IANA Considerations
	Section 7 defines the HTTP status codes 208 (Already Reported) and		Section 7 defines the HTTP status codes 208 (Already Reported) and
	506 (Loop Detected), to be added to the registry at		508 (Loop Detected), which have been added to the HTTP Status Code
	<http://www.iana.org/assignments/http-status-codes>.		Registry.
	14. Acknowledgements		15. Acknowledgements
	This document is the collaborative product of the authors and Tyson		This document is the collaborative product of the authors and Tyson
	Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited		Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited
	from thoughtful discussion by Jim Amsden, Peter Carlson, Steve		from thoughtful discussion by Jim Amsden, Peter Carlson, Steve
	Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus		Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus
	Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David		Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David
	Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland,		Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland,
	Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager,		Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager,
	Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel		Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel
	LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Alexey		LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Alexey
	Melnikov, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley		Melnikov, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley
	Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin		Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
	Wiggen, and other members of the WebDAV working group.		Wiggen, and other members of the concluded WebDAV working group.
	15. References		16. References
	15.1. Normative References		16.1. 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.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918, June 2007.		Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
	[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and		[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
	F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth		F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
	Edition)", W3C REC-xml-20081126, November 2008,		Edition)", W3C REC-xml-20081126, November 2008,
	<http://www.w3.org/TR/2008/REC-xml-20081126/>.		<http://www.w3.org/TR/2008/REC-xml-20081126/>.
	15.2. Informative References		16.2. Informative References
	[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.		[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
	Whitehead, "Versioning Extensions to WebDAV (Web		Whitehead, "Versioning Extensions to WebDAV (Web
	Distributed Authoring and Versioning)", RFC 3253,		Distributed Authoring and Versioning)", RFC 3253,
	March 2002.		March 2002.
	[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web		[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
	Distributed Authoring and Versioning (WebDAV) Access		Distributed Authoring and Versioning (WebDAV) Access
	Control Protocol", RFC 3744, May 2004.		Control Protocol", RFC 3744, May 2004.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	July 2005.		July 2005.
	Appendix A. Clarification to RFC2518bis' Usage of the term 'lock root'
	[RFC4918], Section 9.10.1 claims:
	A LOCK request to an existing resource will create a lock on the
	resource identified by the Request-URI, provided the resource is
	not already locked with a conflicting lock. The resource
	identified in the Request-URI becomes the root of the lock.
	This is incorrect in that it implies that the "lock root" is a
	resource, not a URL
	(<http://www.rfc-editor.org/errata_search.php?eid=1207>). However,
	should a directly locked resource have multiple bindings, only the
	one used in the Request-URI of the LOCK request will be the protected
	from changes of clients not supplying the lock token.
	A correct description would be:
	A LOCK request to an existing resource will create a lock on the
	resource identified by the Request-URI, provided the resource is
	not already locked with a conflicting lock. The Request-URI
	becomes the root of the lock.
	Note that this change makes the description consistent with the
	definition of the DAV:lockroot XML element in Section 14.12 of
	[RFC4918].
	The authors of this specification recommend that future revisions of
	[RFC4918] will update the description as suggested above.
	Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1. Since draft-ietf-webdav-bind-02
	Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and
	"2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed
	resolution, but keep it open. Add issues "ED_references" and
	"4_507_status". Started work on index. Rename document to "Binding
	Extensions to Web Distributed Authoring and Versioning (WebDAV)".
	Rename "References" to "Normative References". Close issue
	"ED_references". Close issue "4_507_status".
	B.2. Since draft-ietf-webdav-bind-03
	Add and close issues "9.2_redirect_loops", "ED_authors" and
	"ED_updates". Add section about capability discovery (DAV header).
	Close issues "5.1_LOOP_STATUS". Add and resolve new issue
	"5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue
	"locking" and resolve as invalid.
	B.3. Since draft-ietf-webdav-bind-04
	Add and close issues "6_precondition_binding_allowed" and
	"6_lock_behaviour". Add mailing list and issues list pointers to
	front.
	B.4. Since draft-ietf-webdav-bind-05
	Editorial fixes. Add and resolve issues "1.3_error_negotiation",
	"2.5_language" and "7.1.1_add_resource_id". Add historical issue
	"4_LOCK_BEHAVIOR" and it's resolution for better tracking.
	B.5. Since draft-ietf-webdav-bind-06
	Rewrite Editorial Note. Open and resolve issues "2.6_identical",
	"specify_safeness_and_idempotence" and "ED_rfc2026_ref".
	B.6. Since draft-ietf-webdav-bind-07
	Add more index items (no change tracking). Add and resolve issues
	"2.3_copy_to_same", "bind_properties", "bind_vs_ACL",
	"6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML
	DTD fragment in section 3.3. Make spelling of "Request-URI"
	consistent.
	B.7. Since draft-ietf-webdav-bind-08
	Resolved editorial issues raised by Jim Whitehead in <http://
	lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html>.
	Add and resolve issues "atomicity", "2_allow_destroy",
	"2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks",
	"2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops",
	"2.6_resource-id_vs_versions", "3.2_example" and
	"6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open
	and resolve "6_rebind_intro".
	B.8. Since draft-ietf-webdav-bind-09
	Add and resolve issue "6.1_rebind_vs_locks", adding proposed example
	text. Add action item "3.1_uuids". Close issue
	"2.6_when_do_ids_change". Add and resolve issues
	"2.6_bindings_vs_properties" and "uri_draft_ref".
	B.9. Since draft-ietf-webdav-bind-10
	Resolve action item "3.1_uuids". Add and resolve issue
	"2.7_unlock_vs_bindings". Revisit issue
	"2.6_bindings_vs_properties", and remove the part of the sentence
	that speaks about live properties. Update "rfc2396bis" references to
	"RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution.
	Align artwork where applicable (new xml2rfc1.29rc2 feature).
	B.10. Since draft-ietf-webdav-bind-11
	Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about
	live properties in Section 2.6.
	B.11. Since draft-ietf-webdav-bind-12
	Updated Author's address. Uppercase "Section" when referring to
	other documents.
	Updating from RFC2518 to RFC2518bis:
	o Remove own explanation of DTD syntax.
	o Remove own definition of precondition/postcondition.
	o Remove reference to broken RFC2518 language about DELETE and
	UNLOCK.
	o Remove own definition of DAV: request header.
	o Updated "Rationale for Distinguishing Bindings from URI Mappings"
	to reflect the changes in [draft-ietf-webdav-rfc2518bis], making
	proposals for more changes so that the issue can be closed (see
	also <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227>
	and <http://greenbytes.de/tech/webdav/
	draft-ietf-webdav-rfc2518bis-12.html#rfc.section.5.2>).
	B.12. Since draft-ietf-webdav-bind-13
	Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one
	incorrect section reference. Remove Section "Rationale for
	Distinguishing Bindings from URI Mappings" as
	[draft-ietf-webdav-rfc2518-bis] now uses the proper definition of
	collection state. Examples use application/xml instead of text/xml
	MIME type.
	Fix IANA section (there are no IANA considerations).
	B.13. Since draft-ietf-webdav-bind-14
	Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to
	4th edition.
	Markup ASCII art for box recognition (doesn't affect ASCII version).
	Identify Julian Reschke as Editor.
	B.14. Since draft-ietf-webdav-bind-15
	Fix typo in RFC2119 keywords section (sorry!).
	Update [draft-ietf-webdav-rfc2518-bis] to draft 17.
	Add and resolve issue "rfc2518bis-lock-root".
	B.15. Since draft-ietf-webdav-bind-16
	Add and resolve issue "iana-vs-http-status".
	B.16. Since draft-ietf-webdav-bind-17
	Update rfc2518bis reference to draft 18 (note that the bug reported
	in <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251>
	is still present).
	B.17. Since draft-ietf-webdav-bind-18
	Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918.
	B.18. Since draft-ietf-webdav-bind-19
	Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move-
	creating-cycles", "3.1-clarify-resource-id" and "4-precondition-
	language".
	B.19. Since draft-ietf-webdav-bind-20
	Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples.
	Replace RFC2518bis issue link by pointer to RFC Errata Page.
	Add issues "relation-to-deltav" and "status-codes".
	B.20. Since draft-ietf-webdav-bind-21
	Resolve issues "relation-to-deltav" and "status-codes".
	Add correct content length values to examples (no change bars).
	B.21. Since draft-ietf-webdav-bind-22
	Set "Intended Status" to "Experimental".
	Update XML reference to "Extensible Markup Language (XML) 1.0 (Fifth
	Edition)".
	B.22. Since draft-ietf-webdav-bind-23
	Remove surplus white space from one example.
	Fix typo: "DAV:binding-set" -> "DAV:parent-set".
	Add and resolve issues "clarify-alternate-uri", "def-integrity", "ex-
	copy-multiple-update", "ex-copy-graph", and "ex-live-property".
	Appendix C. Resolved issues (to be removed by RFC Editor before
	publication)
	Issues that were either rejected or resolved in this version of this
	document.
	C.1. edit
	Type: edit
	julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for
	editorial fixes/enhancements.
	C.2. def-integrity
	In Section 1:
	Type: change
	alexey.melnikov@isode.com (2009-05-15): Define the term "integrity".
	Resolution (2009-05-28): Add definition to Terminology Section.
	C.3. ex-copy-multiple-update
	In Section 2.3:
	Type: edit
	alexey.melnikov@isode.com (2009-05-15): Add example for the case: "If
	because of multiple bindings to a resource, more than one source
	resource updates a single destination resource, the order of the
	updates is server defined."
	Resolution (2009-05-25): Example added.
	C.4. ex-copy-graph
	In Section 2.3:
	Type: edit
	alexey.melnikov@isode.com (2009-05-15): Add example for the case
	discussed below: "If a COPY request would cause a new resource to be
	created as a copy of an existing resource, and that COPY request has
	already created a copy of that existing resource, ..."
	julian.reschke@greenbytes.de (2009-05-18): It seems that we already
	have that example, see "2.3.2. Example: COPY with 'Depth: infinity'
	with Multiple Bindings to a Leaf Resource".
	Resolution (2009-05-25): Added forward reference to example.
	C.5. ex-live-property
	In Section 2.6:
	Type: edit
	alexey.melnikov@isode.com (2009-05-15): Give an example of a live
	property where the value depends on the path.
	julian.reschke@greenbytes.de (2009-05-19): Thread in which the latest
	version of this paragraph was discussed: <http://lists.w3.org/
	Archives/Public/w3c-dist-auth/2005JulSep/0023.html>.
	C.6. clarify-alternate-uri
	In Section 3.1:
	Type: change
	alexey.melnikov@isode.com (2009-05-15): The note about resource-id
	being an alternate URI is confusing.
	julian.reschke@greenbytes.de (2009-05-25): This was added in draft
	19, dealing with issue "3.1-clarify-resource-id" (<http://
	greenbytes.de/tech/webdav/
	draft-ietf-webdav-bind-issues.html#issue.3.1-clarify-resource-id>).
	See also <http://lists.w3.org/Archives/Public/w3c-dist-auth/
	2007OctDec/0029.html>. Proposal: either clarify (expand) or remove
	it.
	Resolution (2009-05-25): Statement removed.
	Index		Index
	2		2
	208 Already Reported (status code) 32, 40		208 Already Reported (status code) 31, 41
	5		5
	506 Loop Detected (status code) 35, 40		508 Loop Detected (status code) 34, 41
	B		B
	BIND method 22		BIND method 21
	Marshalling 23		Marshalling 22
	Postconditions 24		Postconditions 23
	Preconditions 23		Preconditions 22
	Binding 7		Binding 6
	Binding Integrity 7-8, 22		Binding Integrity 6-7, 21
	C		C
	Collection 7		Collection 6
	Condition Names		Condition Names
	DAV:bind-into-collection (pre) 23		DAV:bind-into-collection (pre) 22
	DAV:bind-source-exists (pre) 23		DAV:bind-source-exists (pre) 22
	DAV:binding-allowed (pre) 24		DAV:binding-allowed (pre) 23
	DAV:binding-deleted (post) 26, 29		DAV:binding-deleted (post) 25, 28
	DAV:can-overwrite (pre) 24, 28		DAV:can-overwrite (pre) 23, 27
	DAV:cross-server-binding (pre) 24, 28		DAV:cross-server-binding (pre) 23, 27
	DAV:cycle-allowed (pre) 24, 28		DAV:cycle-allowed (pre) 23, 27
	DAV:lock-deleted (post) 26, 29		DAV:lock-deleted (post) 25, 28
	DAV:locked-overwrite-allowed (pre) 24		DAV:locked-overwrite-allowed (pre) 23
	DAV:locked-source-collection-update-allowed (pre) 29		DAV:locked-source-collection-update-allowed (pre) 28
	DAV:locked-update-allowed (pre) 24, 26, 28		DAV:locked-update-allowed (pre) 23, 25, 27
	DAV:name-allowed (pre) 24, 28		DAV:name-allowed (pre) 23, 27
	DAV:new-binding (post) 24, 29		DAV:new-binding (post) 23, 28
	DAV:protected-source-url-deletion-allowed (pre) 29		DAV:protected-source-url-deletion-allowed (pre) 28
	DAV:protected-url-deletion-allowed (pre) 26		DAV:protected-url-deletion-allowed (pre) 25
	DAV:protected-url-modification-allowed (pre) 28		DAV:protected-url-modification-allowed (pre) 27
	DAV:rebind-from-collection (pre) 28		DAV:rebind-into-collection (pre) 27
	DAV:rebind-source-exists (pre) 28		DAV:rebind-source-exists (pre) 27
	DAV:unbind-from-collection (pre) 26		DAV:unbind-from-collection (pre) 25
	DAV:unbind-source-exists (pre) 26		DAV:unbind-source-exists (pre) 25
	D		D
	DAV header		DAV header
	compliance class 'bind' 35		compliance class 'bind' 34
	DAV:bind-into-collection precondition 23		DAV:bind-into-collection precondition 22
	DAV:bind-source-exists precondition 23		DAV:bind-source-exists precondition 22
	DAV:binding-allowed precondition 24		DAV:binding-allowed precondition 23
	DAV:binding-deleted postcondition 26, 29		DAV:binding-deleted postcondition 25, 28
	DAV:can-overwrite precondition 24, 28		DAV:can-overwrite precondition 23, 27
	DAV:cross-server-binding precondition 24, 28		DAV:cross-server-binding precondition 23, 27
	DAV:cycle-allowed precondition 24, 28		DAV:cycle-allowed precondition 23, 27
	DAV:lock-deleted postcondition 26, 29		DAV:lock-deleted postcondition 25, 28
	DAV:locked-overwrite-allowed precondition 24		DAV:locked-overwrite-allowed precondition 23
	DAV:locked-source-collection-update-allowed precondition 29		DAV:locked-source-collection-update-allowed precondition 28
	DAV:locked-update-allowed precondition 24, 26, 28		DAV:locked-update-allowed precondition 23, 25, 27
	DAV:name-allowed precondition 24, 28		DAV:name-allowed precondition 23, 27
	DAV:new-binding postcondition 24, 29		DAV:new-binding postcondition 23, 28
	DAV:parent-set property 21		DAV:parent-set property 20
	DAV:protected-source-url-deletion-allowed precondition 29		DAV:protected-source-url-deletion-allowed precondition 28
	DAV:protected-url-deletion-allowed precondition 26		DAV:protected-url-deletion-allowed precondition 25
	DAV:protected-url-modification-allowed precondition 28		DAV:protected-url-modification-allowed precondition 27
	DAV:rebind-from-collection precondition 28		DAV:rebind-into-collection precondition 27
	DAV:rebind-source-exists precondition 28		DAV:rebind-source-exists precondition 27
	DAV:resource-id property 20		DAV:resource-id property 19
	DAV:unbind-from-collection precondition 26		DAV:unbind-from-collection precondition 25
	DAV:unbind-source-exists precondition 26		DAV:unbind-source-exists precondition 25
	I		I
	Internal Member URI 7		Internal Member URI 6
			L
			Locking 35
	M		M
	Methods		Methods
	BIND 22		BIND 21
	REBIND 27		REBIND 26
	UNBIND 25		UNBIND 24
	P		P
	Path Segment 6		Path Segment 5
	Properties		Properties
	DAV:parent-set 21		DAV:parent-set 20
	DAV:resource-id 20		DAV:resource-id 19
	R		R
	REBIND method 27		REBIND method 26
	Marshalling 27		Marshalling 26
	Postconditions 29		Postconditions 28
	Preconditions 28		Preconditions 27
	S		S
	Status Codes		Status Codes
	208 Already Reported 32, 40		208 Already Reported 31, 41
	506 Loop Detected 35, 40		508 Loop Detected 34, 41
	U		U
	UNBIND method 25		UNBIND method 24
	Marshalling 25		Marshalling 24
	Postconditions 26		Postconditions 25
	Preconditions 26		Preconditions 25
	URI Mapping 6		URI Mapping 5
	Authors' Addresses		Authors' Addresses
	Geoffrey Clemm		Geoffrey Clemm
	IBM		IBM
	20 Maguire Road		550 King Street
	Lexington, MA 02421		Littleton, MA 01460
			EMail: geoffrey.clemm@us.ibm.com
	Email: geoffrey.clemm@us.ibm.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 (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	Email: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	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
	Email: ejw@cse.ucsc.edu		EMail: ejw@cse.ucsc.edu
End of changes. 125 change blocks.
	652 lines changed or deleted		443 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/