draft-ietf-webdav-bind-27.txt		draft-ietf-webdav-bind-latest.txt
	Network Working Group G. Clemm		Network Working Group G. Clemm
	Internet-Draft IBM		Internet-Draft IBM
	Intended status: Experimental J. Crawford		Intended status: Experimental J. Crawford
	Expires: June 18, 2010 IBM Research		Expires: October 3, 2010 IBM Research
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	J. Whitehead		J. Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	December 15, 2009		April 2010
	Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)		Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
	draft-ietf-webdav-bind-27		draft-ietf-webdav-bind-latest
	Abstract		Abstract
	This specification defines bindings, and the BIND method for creating		This specification defines bindings, and the BIND method for creating
	multiple bindings to the same resource. Creating a new binding to a		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.		resource causes at least one new URI to be mapped to that resource.
	Servers are required to ensure the integrity of any bindings that		Servers are required to ensure the integrity of any bindings that
	they allow to be created.		they allow to be created.
	Editorial Note (To be removed by RFC Editor before publication)		Status of This Memo
	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
	all registered issues since draft 02.
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This Internet-Draft will expire on October 3, 2010.
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 18, 2010.
	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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		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 . . . . . . . . . . 10		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 Presence
	of Bind Loops . . . . . . . . . . . . . . . . . . . . 12		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 Multiple
	Bindings to a Leaf Resource . . . . . . . . . . . . . 15		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 . . . . . . . . . . . . . . . . . 19
	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 Locking in WebDAV . . . . . . . . . . . . . . 36		9. Relationship to Locking in WebDAV . . . . . . . . . . . . . . 35
	9.1. Example: Locking and Multiple Bindings . . . . . . . . . . 37		9.1. Example: Locking and Multiple Bindings . . . . . . . . . . 35
	10. Relationship to WebDAV Access Control Protocol . . . . . . . . 38		10. Relationship to WebDAV Access Control Protocol . . . . . . . . 37
	11. Relationship to Versioning Extensions to WebDAV . . . . . . . 38		11. Relationship to Versioning Extensions to WebDAV . . . . . . . 37
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 41		12. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	12.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 41		12.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 40
	12.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 41		12.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 40
	12.3. Bindings, and Denial of Service . . . . . . . . . . . . . 41		12.3. Bindings and Denial of Service . . . . . . . . . . . . . . 40
	12.4. Private Locations May Be Revealed . . . . . . . . . . . . 41		12.4. Private Locations May Be Revealed . . . . . . . . . . . . 40
	12.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 42		12.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 41
	13. Internationalization Considerations . . . . . . . . . . . . . 42		13. Internationalization Considerations . . . . . . . . . . . . . 41
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 42		16.1. Normative References . . . . . . . . . . . . . . . . . . . 41
	16.2. Informative References . . . . . . . . . . . . . . . . . . 43		16.2. Informative References . . . . . . . . . . . . . . . . . . 42
	Appendix A. Change Log (to be removed by RFC Editor before		Appendix A. Resolved issues (to be removed by RFC Editor
	publication) . . . . . . . . . . . . . . . . . . . . 43		before publication) . . . . . . . . . . . . . . . . . 42
	A.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 43		A.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	A.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 43		A.2. auth48 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	A.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 44		A.3. iana.statuscode . . . . . . . . . . . . . . . . . . . . . 42
	A.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 44		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	A.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 44
	A.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 44
	A.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 44
	A.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 44
	A.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 44
	A.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 45
	A.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 45
	A.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 45
	A.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 45
	A.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 46
	A.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 46
	A.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 46
	A.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 46
	A.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 46
	A.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 46
	A.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 46
	A.21. Since draft-ietf-webdav-bind-22 . . . . . . . . . . . . . 47
	A.22. Since draft-ietf-webdav-bind-23 . . . . . . . . . . . . . 47
	A.23. Since draft-ietf-webdav-bind-24 . . . . . . . . . . . . . 47
	A.24. Since draft-ietf-webdav-bind-25 . . . . . . . . . . . . . 47
	A.25. Since draft-ietf-webdav-bind-26 . . . . . . . . . . . . . 47
	Appendix B. Resolved issues (to be removed by RFC Editor
	before publication) . . . . . . . . . . . . . . . . . 47
	B.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	B.2. bind-vs-hierarchy . . . . . . . . . . . . . . . . . . . . 47
	B.3. copying-complex-loops . . . . . . . . . . . . . . . . . . 48
	B.4. locking2 . . . . . . . . . . . . . . . . . . . . . . . . . 49
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
	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		Note: the collection model described herein is not compatible with
	systems in which resources inherit properties based solely on the		systems in which resources inherit properties based solely on the
	access path, as the ability to create additional bindings will		access path, as the ability to create additional bindings will
	skipping to change at page 9, line 7 ¶		skipping to change at page 7, line 50 ¶
	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 41 ¶		skipping to change at page 8, line 35 ¶
	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 to
	C before the BIND request, then for each URI "C-URI" in C-MAP, the		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:
	skipping to change at page 10, line 46 ¶		skipping to change at page 9, line 38 ¶
	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 that a		a destination of /CollA, the outcome of the copy operation is that a
	copy of the tree is replicated to the target /CollA:		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 7 ¶		skipping to change at page 13, line 7 ¶
	+-----------------+ |		+-----------------+ |
	| | |		| | |
	| +-------+		| +-------+
	|		|
	+-------------+		+-------------+
	| Resource R4 |		| Resource R4 |
	+-------------+		+-------------+
	Note that the same would apply for more complex loops.		Note that the same would apply for more complex loops.
	2.3.2. Example: COPY updating multiple Bindings		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 30 ¶		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 39 ¶
	>> 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 35 ¶		skipping to change at page 18, line 35 ¶
	| |		| |
	| |		| |
	+-------------------+		+-------------------+
	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 behavior for each		path submitted to PROPFIND. On the other hand, the behavior for each
	live property depends on its individual definition (for example, see		live property depends on its individual definition (for example, 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 21, line 4 ¶		skipping to change at page 19, line 51 ¶
	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 37 ¶
	<!-- 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 14 ¶
	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 Locking in WebDAV		9. Relationship to Locking in WebDAV
	Locking is an optional feature of WebDAV ([RFC4918]). The base		Locking is an optional feature of WebDAV ([RFC4918]). The base
	WebDAV specification and this protocol extension have been designed		WebDAV specification and this protocol extension have been designed
	in parallel, making sure that all features of WebDAV can be		in parallel, making sure that all features of WebDAV can be
	implemented on a server that implements this protocol as well.		implemented on a server that implements this protocol as well.
	skipping to change at page 36, line 41 ¶		skipping to change at page 35, line 40 ¶
	through which the lock was created, not a resource. This URI, and		through which the lock was created, not a resource. This URI, and
	potential aliases of this URI ([RFC4918], Section 5), are said to be		potential aliases of this URI ([RFC4918], Section 5), are said to be
	"protected" by the lock.		"protected" by the lock.
	As defined in the introduction to Section 7 of [RFC4918], write		As defined in the introduction to Section 7 of [RFC4918], write
	operations that modify the state of a locked resource require that		operations that modify the state of a locked resource require that
	the lock token is submitted with the request. Consistent with		the lock token is submitted with the request. Consistent with
	WebDAV, the state of the resource consists of the content ("any		WebDAV, the state of the resource consists of the content ("any
	variant"), dead properties, lockable live properties (item 1), plus,		variant"), dead properties, lockable live properties (item 1), plus,
	for a collection, all its bindings (item 2). Note that this, by		for a collection, all its bindings (item 2). Note that this, by
	definition, does not depend on the request URI to which the write		definition, does not depend on the Request-URI to which the write
	operation is applied (the locked state is a property of the resource,		operation is applied (the locked state is a property of the resource,
	not its URI).		not its URI).
	However, the lock root is the URI through which the lock was		However, the lock-root is the URI through which the lock was
	requested. Thus, the protection defined in item 3 of the list does		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		not apply to additional URIs that may be mapped to the same resource
	due to the existence of multiple bindings.		due to the existence of multiple bindings.
	9.1. Example: Locking and Multiple Bindings		9.1. Example: Locking and Multiple Bindings
	Consider a root collection "/", containing the two collections C1 and		Consider a root collection "/", containing the two collections C1 and
	C2, named "/CollX" and "/CollY", and a child resource R, bound to C1		C2, named "/CollX" and "/CollY", and a child resource R, bound to C1
	as "/CollX/test" and bound to C2 as "/CollY/test":		as "/CollX/test" and bound to C2 as "/CollY/test":
	skipping to change at page 37, line 35 ¶		skipping to change at page 36, line 30 ¶
	| |		| |
	| |		| |
	+------------------+		+------------------+
	| Resource R |		| Resource R |
	+------------------+		+------------------+
	Given a host name of "www.example.com", applying a depth-zero write		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		lock to "/CollX/test" will lock the resource R, and the lock-root of
	this lock will be "http://www.example.com/CollX/test".		this lock will be "http://www.example.com/CollX/test".
	Thus the following operations will require that the associated lock		Thus, the following operations will require that the associated lock
	token is submitted with the "If" request header ([RFC4918], Section		token is submitted with the "If" request header ([RFC4918], Section
	10.4):		10.4):
	o a PUT or PROPPATCH request modifying the content or lockable		o a PUT or PROPPATCH request modifying the content or lockable
	properties of resource R (as R is locked) -- no matter which URI		properties of resource R (as R is locked) -- no matter which URI
	is used as request target,		is used as request target, and
	o a MOVE, REBIND, UNBIND or DELETE request causing "/CollX/test" not		o a MOVE, REBIND, UNBIND, or DELETE request causing "/CollX/test"
	being mapped to resource R anymore (be it addressed to "/CollX" or		not to be mapped to resource R anymore (be it addressed to
	"/CollX/test").		"/CollX" or "/CollX/test").
	The following operations will not require submission of the lock		The following operations will not require submission of the lock
	token:		token:
	o a DELETE request addressed to "/CollY" or /CollY/test", as it does		o a DELETE request addressed to "/CollY" or "/CollY/test", as it
	not affect the resource R, nor the lock-root,		does not affect the resource R, nor the lock-root,
	o for the same reason, an UNBIND request removing the binding "test"		o for the same reason, an UNBIND request removing the binding "test"
	from collection C2, or the binding "CollY" from the root		from collection C2, or the binding "CollY" from the root
	collection,		collection, and
	o similarly, a MOVE or REBIND request causing "/CollY/test" not		o similarly, a MOVE or REBIND request causing "/CollY/test" not
	being mapped to resource R anymore.		being mapped to resource R anymore.
	Note that despite the lock root being		Note that despite the lock-root being
	"http://www.example.com/CollX/test", an UNLOCK request can be		"http://www.example.com/CollX/test", an UNLOCK request can be
	addressed through any URI mapped to resource R, as UNLOCK operates on		addressed through any URI mapped to resource R, as UNLOCK operates on
	the resource identified by the request URI, not that URI (see		the resource identified by the Request-URI, not that URI (see
	[RFC4918], Section 9.11).		[RFC4918], Section 9.11).
	10. Relationship to WebDAV Access Control Protocol		10. Relationship to WebDAV Access Control Protocol
	Note that the WebDAV Access Control Protocol has been designed for		Note that the WebDAV Access Control Protocol has been designed for
	compatibility with systems that allow multiple URIs to map to the		compatibility with systems that allow multiple URIs to map to the
	same resource (see [RFC3744], Section 5):		same resource (see [RFC3744], Section 5):
	...Access control properties (especially DAV:acl and DAV:		Access control properties (especially DAV:acl and DAV:inherited-
	inherited-acl-set) are defined on the resource identified by the		acl-set) are defined on the resource identified by the Request-URI
	Request-URI of a PROPFIND request. A direct consequence is that		of a PROPFIND request. A direct consequence is that if the
	if the resource is accessible via multiple URI, the value of		resource is accessible via multiple URI, the value of access
	access control properties is the same across these URI. ...		control properties is the same across these URI.
	Furthermore, note that BIND and REBIND behave the same as MOVE with		Furthermore, note that BIND and REBIND behave the same as MOVE with
	respect to the DAV:acl property (see [RFC3744], Section 7.3).		respect to the DAV:acl property (see [RFC3744], Section 7.3).
	11. Relationship to Versioning Extensions to WebDAV		11. Relationship to Versioning Extensions to WebDAV
	Servers that implement Workspaces ([RFC3253], Section 6) and Version		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 behavior in order to handle UPDATE and UNCHECKOUT		implement BIND-like behavior in order to handle UPDATE and 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":
	+-------------------------+		+-------------------------+
	skipping to change at page 40, line 42 ¶		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.
	12. 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 ([RFC2616], Section		All of the security considerations of HTTP/1.1 ([RFC2616], Section
	15) and the WebDAV Distributed Authoring Protocol specification		15) and the WebDAV Distributed Authoring Protocol specification
	([RFC4918], Section 20) also apply to this protocol specification.		([RFC4918], Section 20) also apply to this protocol specification.
	In addition, bindings introduce several new security concerns and		In addition, bindings introduce several new security concerns and
	increase the risk of some existing threats. These issues are		increase the risk of some existing threats. These issues are
	detailed below.		detailed below.
	12.1. Privacy Concerns		12.1. Privacy Concerns
	skipping to change at page 41, line 34 ¶		skipping to change at page 40, line 34 ¶
	12.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".
	12.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.
	12.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.
	skipping to change at page 42, line 20 ¶		skipping to change at page 41, line 20 ¶
	the list.		the list.
	13. Internationalization Considerations		13. Internationalization Considerations
	All internationalization considerations mentioned in Section 19 of		All internationalization considerations mentioned in Section 19 of
	[RFC4918] also apply to this document.		[RFC4918] also apply to this document.
	14. 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.
	15. 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,
	skipping to change at page 43, line 32 ¶		skipping to change at page 42, line 28 ¶
	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. Change Log (to be removed by RFC Editor before publication)		Appendix A. Resolved issues (to be removed by RFC Editor before
	A.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".
	A.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.
	A.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.
	A.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.
	A.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".
	A.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.
	A.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".
	A.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".
	A.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).
	A.10. Since draft-ietf-webdav-bind-11
	Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about
	live properties in Section 2.6.
	A.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>).
	A.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).
	A.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.
	A.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".
	A.15. Since draft-ietf-webdav-bind-16
	Add and resolve issue "iana-vs-http-status".
	A.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).
	A.17. Since draft-ietf-webdav-bind-18
	Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918.
	A.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".
	A.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".
	A.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).
	A.21. Since draft-ietf-webdav-bind-22
	Set "Intended Status" to "Experimental".
	Update XML reference to "Extensible Markup Language (XML) 1.0 (Fifth
	Edition)".
	A.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".
	A.23. Since draft-ietf-webdav-bind-24
	Add and resolve issues "clarify-clarify", "sec-cons-references",
	"should-not-update-4918", "should-update-2616", and "webdav-wg-gone".
	A.24. Since draft-ietf-webdav-bind-25
	Add and resolve issue "locking-example".
	A.25. Since draft-ietf-webdav-bind-26
	Add and resolve issues "bind-vs-hierarchy", "copying-complex-loops"
	and "locking2".
	Appendix B. Resolved issues (to be removed by RFC Editor before
	publication)		publication)
	Issues that were either rejected or resolved in this version of this		Issues that were either rejected or resolved in this version of this
	document.		document.
	B.1. edit		A.1. edit
	Type: edit		Type: edit
	julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for		julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for
	editorial fixes/enhancements.		editorial fixes/enhancements.
	B.2. bind-vs-hierarchy		A.2. auth48
	Type: edit
	julian.reschke@greenbytes.de (2009-11-29): Note that a system based
	on the BIND collection model will be inherently incompatible with a
	system that inherits information based on just the naming hierarchy,
	not taking multiple bindings into account. In particular, Access
	Control implementations based on path inheritance come to mind.
	(This is not a problem of the BIND data model itself, but a known
	issue when an attempt is made to build a hybrid system).
	Resolution (2009-12-12): Add a note to the overview, and also clarify
	the "Relation to WebDAV ACL" section.
	B.3. copying-complex-loops
	In Section 2:
	Type: edit		Type: edit
	rjsparks@nostrum.com (2009-06-03):		julian.reschke@greenbytes.de (2010-02-27): Issues resolved during
			RFC-Editor's AUTH48 phase.
	The document provides some discussion of the ramifications of simple
	loops, but its not immediately obvious that the recommendations for
	handling them are sufficient for dealing with more complex loops.
	Are there additional issues introduced when each added level of depth
	adds an exponentially growing number of elements?
	(view in fixed width)
	+---------+
	| root |
	| |
	| start |
	+---------+
	|
	v
	+---------+ +---------+
	+---->| C1 | | C2 |<---+
	| +->| | | |<-+ |
	| | | a b | | a b | | |
	| | +---------+ +---------+ | |
	| | | | | | | |
	| | | | +----+ | | |
	| | | | | | | |
	| | | +----------c---+ | | |
	| | | | | | | |
	| | | +----------+ | | | |
	| | v v v v | |
	| | +---------+ +---------+ | |
	| | | C3 | | C4 | | |
	| | | | | | | |
	| | | a b | | a b | | |
	| | +---------+ +---------+ | |
	| | | | | | | |
	| +----+ | +----+ +-----+ |
	| | | |
	| +----------c-----------------+
	| |
	+-----------------------+
	Resolution (2009-11-29): The authors discussed this question and came		A.3. iana.statuscode
	to the conclusion that the considerations for complex loops are
	identical to those for simple loops; a COPY operation still
	duplicates the binding graph. A short note pointing this out was
	added to the end of the example.
	B.4. locking2		In Section 7:
	Type: change		Type: change
			julian.reschke@greenbytes.de (2010-01-25): IANA rightfully points out
			that status code 506 is taken by RFC 2295. Let's use 508 instead.
	julian.reschke@greenbytes.de (2009-11-29): We have failed to reach		Resolution (2010-01-25): Done.
	consensus about the RFC 4918 clarification. Thus we'll have to
	accept that it says what it says, and need to clarify how it applies
	to locking, essentially pointing out which behavior we expect. To do
	this, create a new section about locking, which will explain the
	"lock root" as required by a server that supports multiple bindings.
	Also keep the example.
	Resolution (2009-12-12): Added new section specifying the locking
	behavior, removed the appendix.
	Index		Index
	2		2
	208 Already Reported (status code) 32, 42		208 Already Reported (status code) 31, 41
	5		5
	506 Loop Detected (status code) 35, 42		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-source-exists precondition 23		DAV:bind-into-collection precondition 22
	DAV:binding-allowed precondition 24		DAV:bind-source-exists precondition 22
	DAV:binding-deleted postcondition 26, 29		DAV:binding-allowed precondition 23
	DAV:can-overwrite precondition 24, 28		DAV:binding-deleted postcondition 25, 28
	DAV:cross-server-binding precondition 24, 28		DAV:can-overwrite precondition 23, 27
	DAV:cycle-allowed precondition 24, 28		DAV:cross-server-binding precondition 23, 27
	DAV:lock-deleted postcondition 26, 29		DAV:cycle-allowed precondition 23, 27
	DAV:locked-overwrite-allowed precondition 24		DAV:lock-deleted postcondition 25, 28
	DAV:locked-source-collection-update-allowed precondition 29		DAV:locked-overwrite-allowed precondition 23
	DAV:locked-update-allowed precondition 24, 26, 28		DAV:locked-source-collection-update-allowed precondition 28
	DAV:name-allowed precondition 24, 28		DAV:locked-update-allowed precondition 23, 25, 27
	DAV:new-binding postcondition 24, 29		DAV:name-allowed precondition 23, 27
	DAV:parent-set property 21		DAV:new-binding postcondition 23, 28
	DAV:protected-source-url-deletion-allowed precondition 29		DAV:parent-set property 20
	DAV:protected-url-deletion-allowed precondition 26		DAV:protected-source-url-deletion-allowed precondition 28
	DAV:protected-url-modification-allowed precondition 28		DAV:protected-url-deletion-allowed precondition 25
	DAV:rebind-from-collection precondition 28		DAV:protected-url-modification-allowed precondition 27
	DAV:rebind-source-exists precondition 28		DAV:rebind-into-collection precondition 27
	DAV:resource-id property 20		DAV:rebind-source-exists precondition 27
	DAV:unbind-from-collection precondition 26		DAV:resource-id property 19
	DAV:unbind-source-exists precondition 26		DAV:unbind-from-collection precondition 25
			DAV:unbind-source-exists precondition 25
	I		I
	Internal Member URI 7		Internal Member URI 6
	L		L
	Locking 36		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, 42		208 Already Reported 31, 41
	506 Loop Detected 35, 42		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. 119 change blocks.
	579 lines changed or deleted		276 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/