draft-ietf-webdav-bind-21.txt		draft-ietf-webdav-bind-22.txt
	Network Working Group G. Clemm		Network Working Group G. Clemm
	Internet-Draft IBM		Internet-Draft IBM
	Updates: 4918 (if approved) J. Crawford		Updates: 4918 (if approved) J. Crawford
	Intended status: Standards Track IBM Research		Intended status: Standards Track IBM Research
	Expires: April 6, 2009 J. Reschke, Ed.		Expires: May 1, 2009 J. Reschke, Ed.
	greenbytes		greenbytes
	J. Whitehead		J. Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	October 3, 2008		October 28, 2008
	Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)		Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
	draft-ietf-webdav-bind-21		draft-ietf-webdav-bind-22
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 6, 2009.		This Internet-Draft will expire on May 1, 2009.
	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 insure the integrity of any bindings that		Servers are required to insure 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)		Editorial Note (To be removed by RFC Editor before publication)
	skipping to change at page 3, line 11		skipping to change at page 3, line 11
	6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 29		6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 29
	7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31		7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31
	7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31		7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31
	7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32		7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32
	7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34		7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34
	7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34		7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34
	8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34		8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34
	8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34		8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34
	8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34		8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34
	9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35		9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 35		10. Relationship to Versioning Extensions to WebDAV . . . . . . . 35
	10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 35		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	10.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 35		11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 38
	10.3. Bindings, and Denial of Service . . . . . . . . . . . . . 35		11.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 38
	10.4. Private Locations May Be Revealed . . . . . . . . . . . . 36		11.3. Bindings, and Denial of Service . . . . . . . . . . . . . 38
	10.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 36		11.4. Private Locations May Be Revealed . . . . . . . . . . . . 38
	11. Internationalization Considerations . . . . . . . . . . . . . 36		11.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 38
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		12. Internationalization Considerations . . . . . . . . . . . . . 38
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 37		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	14.2. Informative References . . . . . . . . . . . . . . . . . . 37		15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
			15.2. Informative References . . . . . . . . . . . . . . . . . . 40
	Appendix A. Clarification to RFC2518bis' Usage of the term		Appendix A. Clarification to RFC2518bis' Usage of the term
	'lock root' . . . . . . . . . . . . . . . . . . . . . 37		'lock root' . . . . . . . . . . . . . . . . . . . . . 40
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 38
	B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 38
	B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 38
	B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 38
	B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 39
	B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 39
	B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 39
	B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 39
	B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 39
	B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 39
	B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 40
	B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 40
	B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 40
	B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 40
	B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 41
	B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 41
	B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 41
	B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 41
	B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 41
	B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 41
	Appendix C. Open issues (to be removed by RFC Editor prior to
	publication) . . . . . . . . . . . . . . . . . . . . 41		publication) . . . . . . . . . . . . . . . . . . . . 41
	C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 41
	C.2. status-codes . . . . . . . . . . . . . . . . . . . . . . . 42		B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 41
	C.3. relation-to-deltav . . . . . . . . . . . . . . . . . . . . 42		B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44		B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 41
	Intellectual Property and Copyright Statements . . . . . . . . . . 46		B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 41
			B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 42
			B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 42
			B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 42
			B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 42
			B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 42
			B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 43
			B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 43
			B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 43
			B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 43
			B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 43
			B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 44
			B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 44
			B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 44
			B.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 44
			Appendix C. Resolved issues (to be removed by RFC Editor
			before publication) . . . . . . . . . . . . . . . . . 44
			C.1. status-codes . . . . . . . . . . . . . . . . . . . . . . . 44
			C.2. relation-to-deltav . . . . . . . . . . . . . . . . . . . . 45
			Appendix D. Open issues (to be removed by RFC Editor prior to
			publication) . . . . . . . . . . . . . . . . . . . . 45
			D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
			Intellectual Property and Copyright Statements . . . . . . . . . . 49
	1. Introduction		1. Introduction
	This specification extends the WebDAV Distributed Authoring Protocol		This specification extends the WebDAV Distributed Authoring Protocol
	([RFC4918]) to enable clients to create new access paths to existing		([RFC4918]) to enable clients to create new access paths to existing
	resources. This capability is useful for several reasons:		resources. This capability is useful for several reasons:
	URIs of WebDAV-compliant resources are hierarchical and correspond to		URIs of WebDAV-compliant resources are hierarchical and correspond to
	a hierarchy of collections in resource space. The WebDAV Distributed		a hierarchy of collections in resource space. The WebDAV Distributed
	Authoring Protocol makes it possible to organize these resources into		Authoring Protocol makes it possible to organize these resources into
	skipping to change at page 19, line 32		skipping to change at page 19, line 32
	2.8. Discovering the Bindings to a Resource		2.8. Discovering the Bindings to a Resource
	An OPTIONAL DAV:parent-set property on a resource provides a list of		An OPTIONAL DAV:parent-set property on a resource provides a list of
	the bindings that associate a collection and a URI segment with that		the bindings that associate a collection and a URI segment with that
	resource. If the DAV:parent-set property exists on a given resource,		resource. If the DAV:parent-set property exists on a given resource,
	it MUST contain a complete list of all bindings to that resource that		it MUST contain a complete list of all bindings to that resource that
	the client is authorized to see. When deciding whether to support		the client is authorized to see. When deciding whether to support
	the DAV:parent-set property, server implementers / administrators		the DAV:parent-set property, server implementers / administrators
	should balance the benefits it provides against the cost of		should balance the benefits it provides against the cost of
	maintaining the property and the security risks enumerated in		maintaining the property and the security risks enumerated in
	Sections 10.4 and 10.5.		Sections 11.4 and 11.5.
	3. Properties		3. Properties
	The bind feature introduces the properties defined below.		The bind feature introduces the properties defined below.
	A DAV:allprop PROPFIND request SHOULD NOT return any of the		A DAV:allprop PROPFIND request SHOULD NOT return any of the
	properties defined by this document. This allows a binding server to		properties defined by this document. This allows a binding server to
	perform efficiently when a naive client, which does not understand		perform efficiently when a naive client, which does not understand
	the cost of asking a server to compute all possible live properties,		the cost of asking a server to compute all possible live properties,
	issues a DAV:allprop PROPFIND request.		issues a DAV:allprop PROPFIND request.
	skipping to change at page 22, line 32		skipping to change at page 22, line 32
	Marshalling:		Marshalling:
	The request MAY include an Overwrite header.		The request MAY include an Overwrite header.
	The request body MUST be a DAV:bind XML element.		The request body MUST be a DAV:bind XML element.
	<!ELEMENT bind (segment, href)>		<!ELEMENT bind (segment, href)>
	If the request succeeds, the server MUST return 201 (Created) when		If the request succeeds, the server MUST return 201 (Created) when
	a new binding was created and 200 (OK) when an existing binding		a new binding was created and 200 (OK) or 204 (No Content) when an
	was replaced.		existing binding was replaced.
	If a response body for a successful request is included, it MUST		If a response body for a successful request is included, it MUST
	be a DAV:bind-response XML element. Note that this document does		be a DAV:bind-response XML element. Note that this document does
	not define any elements for the BIND response body, but the DAV:		not define any elements for the BIND response body, but the DAV:
	bind-response element is defined to ensure interoperability		bind-response element is defined to ensure interoperability
	between future extensions that do define elements for the BIND		between future extensions that do define elements for the BIND
	response body.		response body.
	<!ELEMENT bind-response ANY>		<!ELEMENT bind-response ANY>
	skipping to change at page 24, line 12		skipping to change at page 24, line 12
	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: xxx		Content-Length: 172
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:bind xmlns:D="DAV:">		<D:bind xmlns:D="DAV:">
	<D:segment>bar.html</D:segment>		<D:segment>bar.html</D:segment>
	<D:href>http://www.example.com/CollX/foo.html</D:href>		<D:href>http://www.example.com/CollX/foo.html</D:href>
	</D:bind>		</D:bind>
	>> Response:		>> Response:
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
			Location: http://www.example.com/CollY/bar.html
	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-
	skipping to change at page 25, line 4		skipping to change at page 25, line 8
	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
	[RFC2616], Section 9.1).		[RFC2616], Section 9.1).
	Marshalling:		Marshalling:
	The request body MUST be a DAV:unbind XML element.		The request body MUST be a DAV:unbind XML element.
	<!ELEMENT unbind (segment)>		<!ELEMENT unbind (segment)>
	If the request succeeds, the server MUST return 200 (OK) when the
	binding was successfully deleted.		If the request succeeds, the server MUST return 200 (OK) or 204
			(No Content) when the binding was successfully deleted.
	If a response body for a successful request is included, it MUST		If a response body for a successful request is included, it MUST
	be a DAV:unbind-response XML element. Note that this document		be a DAV:unbind-response XML element. Note that this document
	does not define any elements for the UNBIND response body, but the		does not define any elements for the UNBIND response body, but the
	DAV:unbind-response element is defined to ensure interoperability		DAV:unbind-response element is defined to ensure interoperability
	between future extensions that do define elements for the UNBIND		between future extensions that do define elements for the UNBIND
	response body.		response body.
	<!ELEMENT unbind-response ANY>		<!ELEMENT unbind-response ANY>
	skipping to change at page 26, line 12		skipping to change at page 26, line 12
	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: xxx		Content-Length: 117
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:unbind xmlns:D="DAV:">		<D:unbind xmlns:D="DAV:">
	<D:segment>foo.html</D:segment>		<D:segment>foo.html</D:segment>
	</D:unbind>		</D:unbind>
	>> Response:		>> Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	skipping to change at page 26, line 50		skipping to change at page 26, line 50
	Marshalling:		Marshalling:
	The request MAY include an Overwrite header.		The request MAY include an Overwrite header.
	The request body MUST be a DAV:rebind XML element.		The request body MUST be a DAV:rebind XML element.
	<!ELEMENT rebind (segment, href)>		<!ELEMENT rebind (segment, href)>
	If the request succeeds, the server MUST return 201 (Created) when		If the request succeeds, the server MUST return 201 (Created) when
	a new binding was created and 200 (OK) when an existing binding		a new binding was created and 200 (OK) or 204 (No Content) when an
	was replaced.		existing binding was replaced.
	If a response body for a successful request is included, it MUST		If a response body for a successful request is included, it MUST
	be a DAV:rebind-response XML element. Note that this document		be a DAV:rebind-response XML element. Note that this document
	does not define any elements for the REBIND response body, but the		does not define any elements for the REBIND response body, but the
	DAV:rebind-response element is defined to ensure interoperability		DAV:rebind-response element is defined to ensure interoperability
	between future extensions that do define elements for the REBIND		between future extensions that do define elements for the REBIND
	response body.		response body.
	<!ELEMENT rebind-response ANY>		<!ELEMENT rebind-response ANY>
	skipping to change at page 28, line 36		skipping to change at page 28, line 36
	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: xxx		Content-Length: 176
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:rebind xmlns:D="DAV:">		<D:rebind xmlns:D="DAV:">
	<D:segment>foo.html</D:segment>		<D:segment>foo.html</D:segment>
	<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
	skipping to change at page 30, line 14		skipping to change at page 30, line 14
	containment hierarchy. Servers are not required to support such		containment hierarchy. Servers are not required to support such
	loops, though the server in this example does.		loops, though the server in this example does.
	The REBIND request below will remove the segment "CollZ" from C3 and		The REBIND request below will remove the segment "CollZ" from C3 and
	add a new binding from "CollA" to the collection C2.		add a new binding from "CollA" to the collection C2.
	REBIND /CollW/CollX HTTP/1.1		REBIND /CollW/CollX HTTP/1.1
	Host: www.example.com		Host: www.example.com
	If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>)		If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>)
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: 152
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:rebind xmlns:D="DAV:">		<D:rebind xmlns:D="DAV:">
	<D:segment>CollA</D:segment>		<D:segment>CollA</D:segment>
	<D:href>/CollW/CollY/CollZ</D:href>		<D:href>/CollW/CollY/CollZ</D:href>
	</D:rebind>		</D:rebind>
	The outcome of the REBIND operation is:		The outcome of the REBIND operation is:
	+------------------+		+------------------+
	| Root Collection |		| Root Collection |
	skipping to change at page 32, line 37		skipping to change at page 32, line 37
	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).
	>> Request:		>> Request:
	PROPFIND /Coll/ HTTP/1.1		PROPFIND /Coll/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Depth: infinity		Depth: infinity
	DAV: bind		DAV: bind
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: 152
	<?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:prop>
	<D:displayname/>		<D:displayname/>
	<D:resource-id/>		<D:resource-id/>
	</D:prop>		</D:prop>
	</D:propfind>		</D:propfind>
	>> Response:		>> Response:
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: application/xml; charset="utf-8"		Content-Type: application/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: 1241
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/Coll/</D:href>		<D:href>http://www.example.com/Coll/</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:displayname>Loop Demo</D:displayname>		<D:displayname>Loop Demo</D:displayname>
	<D:resource-id>		<D:resource-id>
	<D:href		<D:href
	skipping to change at page 34, line 18		skipping to change at page 34, line 18
	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 506 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: xxx		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 506 Loop Detected
	skipping to change at page 35, line 11		skipping to change at page 35, line 11
	Clients SHOULD signal support for all MUST level requirements and		Clients SHOULD signal support for all MUST level requirements and
	REQUIRED features by submitting a "DAV" request header containing the		REQUIRED features by submitting a "DAV" request header containing the
	compliance class name "bind". In particular, the client MUST		compliance class name "bind". In particular, the client MUST
	understand the 208 status code defined in Section 7.1.		understand the 208 status code defined in Section 7.1.
	9. Relationship to WebDAV Access Control Protocol		9. Relationship to WebDAV Access Control Protocol
	BIND and REBIND behave the same as MOVE with respect to the DAV:acl		BIND and REBIND behave the same as MOVE with respect to the DAV:acl
	property (see [RFC3744], Section 7.3).		property (see [RFC3744], Section 7.3).
	10. Security Considerations		10. Relationship to Versioning Extensions to WebDAV
			Servers that implement Workspaces ([RFC3253], Section 6) and Version
			Controlled Collections ([RFC3253], Section 14) already need to
			implement BIND-like behaviour in order to handle UPDATE and
			UNCHECKOUT semantics.
			Consider a workspace "/ws1/", containing the version-controlled,
			checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
			CollY", and a version-controlled resource R, bound to C1 as "/ws1/
			CollX/test":
			+-------------------------+
			| Workspace |
			| bindings: |
			| CollX CollY |
			+-------------------------+
			| |
			| |
			| |
			+---------------+ +---------------+
			| Collection C1 | | Collection C2 |
			| bindings: | | |
			| test | | |
			+---------------+ +---------------+
			|
			|
			|
			+------------------+
			| Resource R |
			+------------------+
			Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but
			undoing the checkout on C1 will undo part of the MOVE request, thus
			restoring the binding from C1 to R, but keeping the new binding from
			C2 to R:
			>> Request:
			MOVE /ws1/CollX/test HTTP/1.1
			Host: www.example.com
			Destination: /ws1/CollY/test
			>> Response:
			HTTP/1.1 204 No Content
			>> Request:
			CHECKIN /ws1/CollY/ HTTP/1.1
			Host: www.example.com
			>> Response:
			HTTP/1.1 201 Created
			Cache-Control: no-cache
			Location: http://repo.example.com/his/17/ver/42
			>> Request:
			UNCHECKOUT /ws1/CollX/ HTTP/1.1
			Host: www.example.com
			>> Response:
			HTTP/1.1 200 OK
			Cache-Control: no-cache
			As a result, both C1 and C2 would have a binding to R:
			+-------------------------+
			| Workspace |
			| bindings: |
			| CollX CollY |
			+-------------------------+
			| |
			| |
			| |
			+---------------+ +---------------+
			| Collection C1 | | Collection C2 |
			| bindings: | | bindings: |
			| test | | test |
			+---------------+ +---------------+
			| |
			| |
			| |
			+------------------+
			| Resource R |
			+------------------+
			The MOVE semantics defined in Section 3.15 of [RFC3253] already
			require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the
			same version history (as exposed in the DAV:version-history
			property). Furthermore, the UNCHECKOUT semantics (which in this case
			is similar to UPDATE, see Section 14.11 of [RFC3253]) require:
			...If a new version-controlled member is in a workspace that
			already has a version-controlled resource for that version
			history, then the new version-controlled member MUST be just a
			binding (i.e., another name for) that existing version-controlled
			resource...
			Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the
			same resource R, and have identical DAV:resource-id properties.
			11. Security Considerations
	This section is provided to make WebDAV implementors aware of the		This section is provided to make WebDAV implementors aware of the
	security implications of this protocol.		security implications of this protocol.
	All of the security considerations of HTTP/1.1 and the WebDAV		All of the security considerations of HTTP/1.1 and the WebDAV
	Distributed Authoring Protocol specification also apply to this		Distributed Authoring Protocol specification also apply to this
	protocol specification. In addition, bindings introduce several new		protocol specification. In addition, bindings introduce several new
	security concerns and increase the risk of some existing threats.		security concerns and increase the risk of some existing threats.
	These issues are detailed below.		These issues are detailed below.
	10.1. Privacy Concerns		11.1. Privacy Concerns
	In a context where cross-server bindings are supported, creating		In a context where cross-server bindings are supported, creating
	bindings on a trusted server may make it possible for a hostile agent		bindings on a trusted server may make it possible for a hostile agent
	to induce users to send private information to a target on a		to induce users to send private information to a target on a
	different server.		different server.
	10.2. Bind Loops		11.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".
	10.3. Bindings, and Denial of Service		11.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.
	10.4. Private Locations May Be Revealed		11.4. Private Locations May Be Revealed
	If the DAV:parent-set property is maintained on a resource, the		If the DAV:parent-set property is maintained on a resource, the
	owners of the bindings risk revealing private locations. The		owners of the bindings risk revealing private locations. The
	directory structures where bindings are located are available to		directory structures where bindings are located are available to
	anyone who has access to the DAV:parent-set property on the resource.		anyone who has access to the DAV:parent-set property on the resource.
	Moving a binding may reveal its new location to anyone with access to		Moving a binding may reveal its new location to anyone with access to
	DAV:parent-set on its resource.		DAV:parent-set on its resource.
	10.5. DAV:parent-set and Denial of Service		11.5. DAV:parent-set and Denial of Service
	If the server maintains the DAV:parent-set property in response to		If the server maintains the DAV:parent-set property in response to
	bindings created in other administrative domains, it is exposed to		bindings created in other administrative domains, it is exposed to
	hostile attempts to make it devote resources to adding bindings to		hostile attempts to make it devote resources to adding bindings to
	the list.		the list.
	11. Internationalization Considerations		12. Internationalization Considerations
	All internationalization considerations mentioned in [RFC4918] also		All internationalization considerations mentioned in [RFC4918] also
	apply to this document.		apply to this document.
	12. IANA Considerations		13. 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		506 (Loop Detected), to be added to the registry at
	<http://www.iana.org/assignments/http-status-codes>.		<http://www.iana.org/assignments/http-status-codes>.
	13. Acknowledgements		14. 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, Spencer		Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer
	Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa		Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa
	Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe		Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe
	Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris		Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris
	Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel		Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel
	LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra		LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
	Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,		Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,
	John Stracke, John Tigue, John Turner, Kevin Wiggen, and other		John Stracke, John Tigue, John Turner, Kevin Wiggen, and other
	members of the WebDAV working group.		members of the WebDAV working group.
	14. References		15. References
	14.1. Normative References		15.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918, June 2007.		Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
	[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and		[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
	F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth		F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
	Edition)", W3C REC-xml-20060816, August 2006,		Edition)", W3C REC-xml-20060816, August 2006,
	<http://www.w3.org/TR/2006/REC-xml-20060816>.		<http://www.w3.org/TR/2006/REC-xml-20060816>.
	14.2. Informative References		15.2. Informative References
	[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.		[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
	Whitehead, "Versioning Extensions to WebDAV (Web		Whitehead, "Versioning Extensions to WebDAV (Web
	Distributed Authoring and Versioning)", RFC 3253,		Distributed Authoring and Versioning)", RFC 3253,
	March 2002.		March 2002.
	[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web		[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
	Distributed Authoring and Versioning (WebDAV) Access		Distributed Authoring and Versioning (WebDAV) Access
	Control Protocol", RFC 3744, May 2004.		Control Protocol", RFC 3744, May 2004.
	skipping to change at page 41, line 40		skipping to change at page 44, line 22
	creating-cycles", "3.1-clarify-resource-id" and "4-precondition-		creating-cycles", "3.1-clarify-resource-id" and "4-precondition-
	language".		language".
	B.19. Since draft-ietf-webdav-bind-20		B.19. Since draft-ietf-webdav-bind-20
	Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples.		Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples.
	Replace RFC518bis issue link by pointer to RFC Errata Page.		Replace RFC518bis issue link by pointer to RFC Errata Page.
	Add issues "relation-to-deltav" and "status-codes".		Add issues "relation-to-deltav" and "status-codes".
	Appendix C. Open issues (to be removed by RFC Editor prior to		B.20. Since draft-ietf-webdav-bind-21
	publication)
	C.1. edit		Resolve issues "relation-to-deltav" and "status-codes".
	Type: edit		Add correct content length values to examples (no change bars).
	julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for		Appendix C. Resolved issues (to be removed by RFC Editor before
	editorial fixes/enhancements.		publication)
	C.2. status-codes		Issues that were either rejected or resolved in this version of this
			document.
			C.1. status-codes
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/
	0067.html>		0067.html>
	julian.reschke@greenbytes.de (2008-09-26): The spec currently micro-		julian.reschke@greenbytes.de (2008-09-26): The spec currently micro-
	manages HTTP status codes: for instance, for a successful BIND it		manages HTTP status codes: for instance, for a successful BIND it
	requires status codes of 200 or 201, while - from an HTTP point of		requires status codes of 200 or 201, while - from an HTTP point of
	view - a 204 should be acceptable as well. Proposal: rephrase the		view - a 204 should be acceptable as well. Proposal: rephrase the
	text so that other success codes are acceptable as well, or remove		text so that other success codes are acceptable as well, or remove
	the normative language completely, point to RFC2616, and rely on		the normative language completely, point to RFC2616, and rely on
	examples.		examples.
	C.3. relation-to-deltav		Resolution (2008-10-05): Also allow 204 where previously only 200 was
			allowed. Add Location header to example using status 201.
			C.2. relation-to-deltav
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/
	0031.html>		0031.html>
	werner.donne@re.be (2008-08-11): ...When supporting version		werner.donne@re.be (2008-08-11): ...When supporting version
	controlled collections, bindings may be introduced in a server		controlled collections, bindings may be introduced in a server
	without actually issuing the BIND method. When a MOVE is performed		without actually issuing the BIND method. When a MOVE is performed
	of a resource from one collection to another, both collections should		of a resource from one collection to another, both collections should
	be checked out. An additional binding would be the result if one		be checked out. An additional binding would be the result if one
	collection would be subsequently checked in, while the check-out of		collection would be subsequently checked in, while the check-out of
	the other is undone. The resulting situation is meaningless if the		the other is undone. The resulting situation is meaningless if the
	binding model is not supported...		binding model is not supported...
			Resolution (2008-10-04): Add new section containing that example.
			Appendix D. Open issues (to be removed by RFC Editor prior to
			publication)
			D.1. edit
			Type: edit
			julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for
			editorial fixes/enhancements.
	Index		Index
	2		2
	208 Already Reported (status code) 31, 36		208 Already Reported (status code) 31, 39
	5		5
	506 Loop Detected (status code) 34, 36		506 Loop Detected (status code) 34, 39
	B		B
	BIND method 21		BIND method 21
	Marshalling 22		Marshalling 22
	Postconditions 23		Postconditions 23
	Preconditions 22		Preconditions 22
	Binding 7		Binding 7
	C		C
	Collection 7		Collection 7
	skipping to change at page 44, line 27		skipping to change at page 47, line 26
	DAV:resource-id 19		DAV:resource-id 19
	R		R
	REBIND method 26		REBIND method 26
	Marshalling 26		Marshalling 26
	Postconditions 28		Postconditions 28
	Preconditions 27		Preconditions 27
	S		S
	Status Codes		Status Codes
	208 Already Reported 31, 36		208 Already Reported 31, 39
	506 Loop Detected 34, 36		506 Loop Detected 34, 39
	U		U
	UNBIND method 24		UNBIND method 24
	Marshalling 24		Marshalling 24
	Postconditions 25		Postconditions 25
	Preconditions 25		Preconditions 25
	URI Mapping 6		URI Mapping 6
	Authors' Addresses		Authors' Addresses
End of changes. 42 change blocks.
	82 lines changed or deleted		211 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/