draft-ietf-webdav-bind-03.txt		draft-ietf-webdav-bind-04.txt
	Network Working Group G. Clemm		Network Working Group G. Clemm
	Internet-Draft IBM		Internet-Draft IBM
	Expires: June 10, 2004 J. Crawford		Updates: 2518 (if approved) J. Crawford
	IBM Research		Expires: September 8, 2004 IBM Research
	J. Reschke		J. Reschke
	greenbytes		greenbytes
	J. Slein
	Xerox
	J. Whitehead		J. Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	December 11, 2003		March 10, 2004
	Binding Extensions to Web Distributed Authoring and Versioning		Binding Extensions to Web Distributed Authoring and Versioning
	(WebDAV)		(WebDAV)
	draft-ietf-webdav-bind-03		draft-ietf-webdav-bind-04
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3667.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 June 10, 2004.		This Internet-Draft will expire on September 8, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2 Rationale for Distinguishing Bindings from URI Mappings . . . 6		1.2 Rationale for Distinguishing Bindings from URI Mappings . . 6
	1.3 Method Preconditions and Postconditions . . . . . . . . . . . 7		1.3 Method Preconditions and Postconditions . . . . . . . . . . 7
	2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7		2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . 7
	2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . . 8		2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . 8
	2.2 URI Mappings Created by a new Binding . . . . . . . . . . . . 9		2.2 URI Mappings Created by a new Binding . . . . . . . . . . . 9
	2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . . 10		2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . 10
	2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . . 11		2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . 11
	2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . . 12		2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . 12
	2.6 Determining Whether Two Bindings Are to the Same Resource . . 13		2.6 Determining Whether Two Bindings Are to the Same Resource . 13
	2.7 Discovering the Bindings to a Resource . . . . . . . . . . . . 14		2.7 Discovering the Bindings to a Resource . . . . . . . . . . . 14
	3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 14		3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . . 14		3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . 14
	3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . . 14		3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . 14
	4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 15		4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . . 17		4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . 17
	5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 17		5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . . 19		5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . 19
	6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 19		6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . . 21		6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . 21
	7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 21		7. Additional Status Codes . . . . . . . . . . . . . . . . . . 21
	7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . . 21		7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . 21
	7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . . 23		7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . . . . 22
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 24		7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . . . . 23
	8.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . . 24		7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . 24
	8.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . . 24		8. Capability discovery . . . . . . . . . . . . . . . . . . . . 24
	8.3 Bindings, and Denial of Service . . . . . . . . . . . . . . . 24		8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . . 24
	8.4 Private Locations May Be Revealed . . . . . . . . . . . . . . 24		8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . . 24
	8.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . . 25		8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . . . . 24
	9. Internationalization Considerations . . . . . . . . . . . . . 25		8.2.2 Client compliance class 'bind' . . . . . . . . . . . . . . . 25
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		9. Security Considerations . . . . . . . . . . . . . . . . . . 25
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25		9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 25
	Normative References . . . . . . . . . . . . . . . . . . . . . 25		9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26		9.3 Bindings, and Denial of Service . . . . . . . . . . . . . . 25
	A. Change Log (to be removed by RFC Editor before publication) . 27		9.4 Private Locations May Be Revealed . . . . . . . . . . . . . 26
	A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . . 27		9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . 26
			10. Internationalization Considerations . . . . . . . . . . . . 26
			11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
			12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
			Normative References . . . . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
			A. Change Log (to be removed by RFC Editor before
			publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
			A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . 28
			A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . . 28
	B. Resolved issues (to be removed by RFC Editor before		B. Resolved issues (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . . . . . . 27		publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.1 ED_references . . . . . . . . . . . . . . . . . . . . . . . . 27		B.1 ED_updates . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.2 2.3_COPY_SHARED_BINDINGS . . . . . . . . . . . . . . . . . . . 27		B.2 ED_authors . . . . . . . . . . . . . . . . . . . . . . . . . 29
	B.3 2.3_MULTIPLE_COPY . . . . . . . . . . . . . . . . . . . . . . 28		B.3 locking . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	B.4 4_507_status . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.4 5.1_LOOP_STATUS . . . . . . . . . . . . . . . . . . . . . . 29
	C. Open issues (to be removed by RFC Editor before		B.5 5.1_506_STATUS_STREAMING . . . . . . . . . . . . . . . . . . 30
	publication) . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.6 9.2_redirect_loops . . . . . . . . . . . . . . . . . . . . . 30
	C.1 5.1_LOOP_STATUS . . . . . . . . . . . . . . . . . . . . . . . 28		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		Intellectual Property and Copyright Statements . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . . 31
	1. Introduction		1. Introduction
	This specification extends the WebDAV Distributed Authoring Protocol		This specification extends the WebDAV Distributed Authoring Protocol
	to enable clients to create new access paths to existing resources.		to enable clients to create new access paths to existing resources.
	This capability is useful for several reasons:		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 21, line 48		skipping to change at page 21, line 48
	by the URI "http://www.example.com/CollY". Clients can now use the		by the URI "http://www.example.com/CollY". Clients can now use the
	URI "http://www.example.com/CollX/foo.html" to submit requests to		URI "http://www.example.com/CollX/foo.html" to submit requests to
	that resource, and requests on the URI "http://www.example.com/CollY/		that resource, and requests on the URI "http://www.example.com/CollY/
	bar.html" will fail with a 404 (Not Found) response.		bar.html" will fail with a 404 (Not Found) response.
	7. Additional Status Codes		7. Additional Status Codes
	7.1 208 Already Reported		7.1 208 Already Reported
	The 208 (Already Reported) status code can be used inside a		The 208 (Already Reported) status code can be used inside a
	DAV:propstat response element to indicate that information about the		DAV:propstat response element to avoid enumerating the internal
	resource has already been reported in a previous DAV:propstat element		members of multiple bindings to the same collection repeatedly. For
	in that response. The members of the 208 status resource are omitted		each binding to a collection inside the request's scope, only one
	from the response.		will be reported with a 200 status, while subsequent DAV:response
			elements for all other bindings will use the 208 status, and no
			DAV:response elements for their descendants are included.
			Note that the 208 status will only occur for "Depth: infinity"
			requests, and that it is of particular importance when the multiple
			collection bindings cause a bind loop as discussed in Section 2.2.
			A client can request the DAV:resourceid property in a PROPFIND
			request to guarantee that they can accurately reconstruct the binding
			structure of a collection with multiple bindings to a single
			resource.
			For backward compatibility with clients not aware of the 208 status
			code appearing in multistatus response bodies, it SHOULD NOT be used
			unless the client has signalled support for this specification using
			the "DAV" request header (see Section 8.2). Instead, a 506 status
			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
			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 response.
			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).
	>> 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
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<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 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	skipping to change at page 23, line 41		skipping to change at page 23, line 41
	<D:href>http://www.example.com/Coll/Bar</D:href>		<D:href>http://www.example.com/Coll/Bar</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:displayname>Loop Demo</D:displayname>		<D:displayname>Loop Demo</D:displayname>
	</D:prop>		</D:prop>
	<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>
	A client can request the DAV:resourceid property in a PROPFIND		7.1.2 Example: PROPFIND by non-bind-aware client
	request to guarantee that they can accurately reconstruct the binding
	structure of a collection with multiple bindings to a single		In this example, the client isn't aware of the 208 status code
	resource.		introduced by this specification. As the "Depth: infinity" PROPFIND
			request would cause a loop condition, the whole request is rejected
			with a 506 status.
			>> Request:
			PROPFIND /Coll/ HTTP/1.1
			Host: www.example.com
			Depth: infinity
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:prop> <D:displayname/> </D:prop>
			</D:propfind>
			>> Response:
			HTTP/1.1 506 Loop Detected
	7.2 506 Loop Detected		7.2 506 Loop Detected
	The 506 (Loop Detected) status code indicates that the server		The 506 (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. Security Considerations		8. Capability discovery
	This section is provided to make WebDAV applications aware of the		8.1 OPTIONS method
			If the server supports bindings, it MUST return the compliance class
			name "bind" as a field in the "DAV" response header (see [RFC2518],
			section 9.1) from an OPTIONS request on any resource implemented by
			that server. A value of "bind" in the "DAV" header MUST indicate that
			the server supports all MUST level requirements and REQUIRED features
			specified in this document.
			8.2 'DAV' request header
			8.2.1 Generic syntax
			This specification introduces the 'DAV' request header that allows
			clients to signal compliance to specific WebDAV features. It has the
			same syntax as the response header defined in [RFC2518], section 9.1,
			but MAY be used with any method.
			Note that clients MUST NOT submit a specific compliance class name in
			the request header unless the specification defining this compliance
			class specifically defines it's semantics for clients.
			Note that if a server chooses to vary the result of a request based
			on values in the "DAV" header, the response either MUST NOT be
			cacheable or the server MUST mark the response accordingly using the
			"Vary" header (see [RFC2616], section 14.44).
			8.2.2 Client compliance class 'bind'
			Clients SHOULD signal support for all MUST level requirements and
			REQUIRED features by submitting a "DAV" request header containing the
			compliance class name "bind". In particular, the client MUST
			understand the 208 status code defined in Section 7.1.
			9. Security Considerations
			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.
	8.1 Privacy Concerns		9.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.
	8.2 Redirect Loops		9.2 Bind Loops
	Although redirect 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".
	8.3 Bindings, and Denial of Service		9.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.
	8.4 Private Locations May Be Revealed		9.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.
	8.5 DAV:parent-set and Denial of Service		9.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.
	9. Internationalization Considerations		10. Internationalization Considerations
	All internationalization considerations mentioned in [RFC2518] also		All internationalization considerations mentioned in [RFC2518] also
	apply to this document.		apply to this document.
	10. IANA Considerations		11. IANA Considerations
	All IANA considerations mentioned in [RFC2518] also apply to this		All IANA considerations mentioned in [RFC2518] also apply to this
	document.		document.
	11. Acknowledgements		12. Acknowledgements
	This draft is the collaborative product of the authors and Tyson		This draft is the collaborative product of the authors and Tyson
	Chihaya, Jim Davis, and Chuck Fay. This draft has benefited from		Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has
	thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Ken		benefited from thoughtful discussion by Jim Amsden, Peter Carlson,
	Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer Dawkins, Mark		Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun,
	Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred		Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan
	Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj		Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James
	Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry		Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
	Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby,		Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer,
	Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John		Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick
	Turner, Kevin Wiggen, and other members of the WebDAV working group.		Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and
			other members of the WebDAV working group.
	Normative References		Normative References
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[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.
	[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform		[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
	skipping to change at page 26, line 6		skipping to change at page 27, line 17
	August 1998.		August 1998.
	[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.		[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
	Jensen, "HTTP Extensions for Distributed Authoring --		Jensen, "HTTP Extensions for Distributed Authoring --
	WEBDAV", RFC 2518, February 1999.		WEBDAV", RFC 2518, February 1999.
	[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.
	[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,		[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
	"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C		F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
	REC-xml, October 2000, <http://www.w3.org/TR/2000/		Edition)", W3C REC-xml-20040204, February 2004, <http://
	REC-xml-20001006>.		www.w3.org/TR/2004/REC-xml-20040204>.
	Authors' Addresses		Authors' Addresses
	Geoffrey Clemm		Geoffrey Clemm
	IBM		IBM
	20 Maguire Road		20 Maguire Road
	Lexington, MA 02421		Lexington, MA 02421
	EMail: geoffrey.clemm@us.ibm.com		EMail: geoffrey.clemm@us.ibm.com
	skipping to change at page 26, line 34		skipping to change at page 28, line 4
	EMail: ccjason@us.ibm.com		EMail: ccjason@us.ibm.com
	Julian F. Reschke		Julian F. Reschke
	greenbytes GmbH		greenbytes GmbH
	Salzmannstrasse 152		Salzmannstrasse 152
	Muenster, NW 48159		Muenster, NW 48159
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	Judy Slein
	Xerox Corporation
	800 Phillips Road, 105-50C
	Webster, NY 14580
	EMail: jslein@crt.xerox.com
	Jim Whitehead		Jim Whitehead
	UC Santa Cruz, Dept. of Computer Science		UC Santa Cruz, Dept. of Computer Science
	1156 High Street		1156 High Street
	Santa Cruz, CA 95064		Santa Cruz, CA 95064
	EMail: ejw@cse.ucsc.edu		EMail: ejw@cse.ucsc.edu
	Appendix A. Change Log (to be removed by RFC Editor before publication)		Appendix A. Change Log (to be removed by RFC Editor before publication)
	A.1 Since draft-ietf-webdav-bind-02		A.1 Since draft-ietf-webdav-bind-02
	Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and		Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and
	"2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed		"2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed
	resolution, but keep it open. Add issues "ED_references" and		resolution, but keep it open. Add issues "ED_references" and
	"4_507_status". Started work on index. Rename document to "Binding		"4_507_status". Started work on index. Rename document to "Binding
	Extensions to Web Distributed Authoring and Versioning (WebDAV)".		Extensions to Web Distributed Authoring and Versioning (WebDAV)".
	Rename "References" to "Normative References". Close issue		Rename "References" to "Normative References". Close issue
	"ED_references". CLose issue "4_507_status".		"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.
	Appendix B. Resolved issues (to be removed by RFC Editor before		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 ED_references		B.1 ED_updates
	Type: edit		Type: edit
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/		<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/
	0283.html>		0306.html>
	julian.reschke@greenbytes.de (2003-12-09): (1) Distinguish normative
	and informative references, (2) text referring to RFC2119 is missing,
	(3) references to RFC2277, RFC2616 and XML not needed.
	Resolution (2003-12-11): Editorial changes applied.
	B.2 2.3_COPY_SHARED_BINDINGS
	Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/
	0010.html>
	Peter.Nevermann@softwareag.com (2003-07-10): What if a copied		julian.reschke@greenbytes.de (2003-12-30): Shouldn't the BIND spec be
	collection has two bindings to the same resource.		labelled as "updating" RFC2518 and/or RFC3253?
	Resolution (2003-08-21): Recommend that only one resource with		julian.reschke@greenbytes.de (2004-01-05): It seems that there was
	multiple bindings to it be created by the COPY.		consensus to say that BIND does update RFC2518, while there's no
			consensus about the relationship to RFC3253. As this is a minor
			editorial question, I propose to just say "updated 2518" and to close
			the issue.
	B.3 2.3_MULTIPLE_COPY		Resolution (2004-01-09): State "updates 2518".
	Type: change		B.2 ED_authors
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/		Type: edit
	0124.html>
	Peter.Nevermann@softwareag.com (2003-08-17): What two resources are		julian.reschke@greenbytes.de (2004-01-02): Ensure contact information
	copied to the same resource by a single COPY.		for all original authors is still correct, and that the authors in
			fact support the current draft.
	Resolution (2003-08-21): Server decides order of updates.		Resolution (2004-01-05): J. Slein removed as author and added to
			Acknowledgments.
	B.4 4_507_status		B.3 locking
	Type: change		Type: change
	<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/		<http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-03-01.html>
	0282.html>
	julian.reschke@greenbytes.de (2003-12-09): Section 4 refers to a
	definition of a 507 status code in Section 7.1, which doesn't exist.
	Should this text be replaced by a reference to the
	DAV:cross-server-binding precondition?
	Resolution (2003-12-11): Change wording to refer to precondition		lisa@xythos.com (2004-03-02): (concerns about the behaviour of
	name.		multiple bindings to the same resource when the resource was locked
			via WebDAV LOCK on one of it's bindings).
	Appendix C. Open issues (to be removed by RFC Editor before publication)		Resolution (2004-03-06): No issue here: given two URIs "a" and "b"
			mapped to the same resource, and a WebDAV LOCK that was requested for
			"a", attempts to modify the lockable state of "b" will fail unless
			the lock-token is presented. This is because the resource itself is
			locked, not only it's URI "a". See RFC2518, section 6.
	C.1 5.1_LOOP_STATUS		B.4 5.1_LOOP_STATUS
	Type: change		Type: change
	julian.reschke@greenbytes.de (2002-10-11): Should the 506 status in a		julian.reschke@greenbytes.de (2002-10-11): Should the 506 status in a
	PROPFIND be handled differently?		PROPFIND be handled differently?
	geoffrey.clemm@us.ibm.com (2003-08-03): Use new 208 status to report		geoffrey.clemm@us.ibm.com (2003-08-03): Use new 208 status to report
	cycles in PROPFIND.		cycles in PROPFIND.
	julian.reschke@greenbytes.de (2003-11-16): Proposal: a) import DAV		julian.reschke@greenbytes.de (2003-11-16): Proposal: a) import DAV
	request header definition from rfc2518bis (note that the definition		request header definition from rfc2518bis (note that the definition
	in the latest draft probably needs some more work) b) define a DAV		in the latest draft probably needs some more work) b) define a DAV
	compliance class for the BIND spec c) clarify that 208 should only be		compliance class for the BIND spec c) clarify that 208 should only be
	returned when the client specifies compliance to the BIND spec in the		returned when the client specifies compliance to the BIND spec in the
	PROPFIND request (otherwise fail the complete request).		PROPFIND request (otherwise fail the complete request).
			Resolution (2004-01-02): Define DAV compliance class "bind", define
			DAV request header, clarify that 208 must only be used when the
			client signals that it knows about this specification.
			B.5 5.1_506_STATUS_STREAMING
			Type: change
			julian.reschke@greenbytes.de (2004-01-12): Take a server that allows
			Depth: infinity upon PROPFIND. In general, the only way to implement
			this efficiently is to *stream* the multistatus response. However
			this means that the server needs to decide about the HTTP status code
			to return *prior* to actually doing the recursion. Therefore,
			requiring the server to return a 506 status in case there's a bind
			loop somewhere below the request URI will not work. An obvious
			alternative would be to allow the 506 to be returned inside the
			DAV:status element for the resource the server refuses to recurse
			into. Of course that would mean that the client essentially would
			get a partly incorrect picture of the server state. However, I don't
			think there's any way to avoid that (except for rejecting all Depth:
			infinity PROPFINDs, like many servers already do).
			Resolution (2004-03-06): Allow 506 inside multistatus.
			B.6 9.2_redirect_loops
			Type: edit
			julian.reschke@greenbytes.de (2004-01-09): Avoid confusion with
			REDIRECT. Propose rename to "Bind Loops".
			Resolution (2004-01-09): Do the rename.
	Index		Index
	2		2
	208 Already Reported (status code) 21		208 Already Reported (status code) 21
	5		5
	506 Loop Detected (status code) 23		506 Loop Detected (status code) 24
	B		B
	BIND method 15		BIND method 15
	C		C
	Condition Names		Condition Names
	DAV:bind-into-collection (pre) 16		DAV:bind-into-collection (pre) 16
	DAV:bind-source-exists (pre) 16		DAV:bind-source-exists (pre) 16
	DAV:binding-allowed (pre) 16, 20		DAV:binding-allowed (pre) 16, 20
	DAV:binding-deleted (post) 18, 21		DAV:binding-deleted (post) 18, 21
	skipping to change at page 29, line 39		skipping to change at page 31, line 39
	DAV:new-binding (post) 17, 21		DAV:new-binding (post) 17, 21
	DAV:protected-source-url-deletion-allowed (pre) 20		DAV:protected-source-url-deletion-allowed (pre) 20
	DAV:protected-url-deletion-allowed (pre) 18		DAV:protected-url-deletion-allowed (pre) 18
	DAV:protected-url-modification-allowed (pre) 20		DAV:protected-url-modification-allowed (pre) 20
	DAV:rebind-into-collection (pre) 20		DAV:rebind-into-collection (pre) 20
	DAV:rebind-source-exists (pre) 20		DAV:rebind-source-exists (pre) 20
	DAV:unbind-from-collection (pre) 18		DAV:unbind-from-collection (pre) 18
	DAV:unbind-source-exists (pre) 18		DAV:unbind-source-exists (pre) 18
	D		D
			DAV header
			compliance class 'bind' 24
	DAV:bind-into-collection precondition 16		DAV:bind-into-collection precondition 16
	DAV:bind-source-exists precondition 16		DAV:bind-source-exists precondition 16
	DAV:binding-allowed precondition 16, 20		DAV:binding-allowed precondition 16, 20
	DAV:binding-deleted postcondition 18, 21		DAV:binding-deleted postcondition 18, 21
	DAV:can-overwrite precondition 16, 20		DAV:can-overwrite precondition 16, 20
	DAV:cross-server-binding precondition 16, 20		DAV:cross-server-binding precondition 16, 20
	DAV:cycle-allowed precondition 16, 20		DAV:cycle-allowed precondition 16, 20
	DAV:locked-overwrite-allowed precondition 16		DAV:locked-overwrite-allowed precondition 16
	DAV:locked-source-collection-update-allowed precondition 20		DAV:locked-source-collection-update-allowed precondition 20
	DAV:locked-update-allowed precondition 16, 18, 20		DAV:locked-update-allowed precondition 16, 18, 20
	skipping to change at page 30, line 29		skipping to change at page 32, line 31
	Properties		Properties
	DAV:parent-set 14		DAV:parent-set 14
	DAV:resource-id 14		DAV:resource-id 14
	R		R
	REBIND method 19		REBIND method 19
	S		S
	Status Codes		Status Codes
	208 Already Reported 21		208 Already Reported 21
	506 Loop Detected 23		506 Loop Detected 24
	U		U
	UNBIND method 17		UNBIND method 17
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the IETF's procedures with respect to rights in IETF Documents can
	standards-related documentation can be found in BCP-11. Copies of		be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/