draft-ietf-webdav-depth-00.txt		draft-ietf-webdav-depth-01.txt
	INTERNET-DRAFT Yaron Y. Goland		INTERNET-DRAFT Yaron Y. Goland
	Expires: March 1998 Saveen Reddy		Expires: April 1998 Saveen Reddy
	Microsoft Corporation		Microsoft Corporation
	Oct. 8, 1997		November 6, 1997
	WebDAV Tree Operations		WebDAV Tree Operations
	draft-ietf-webdav-depth-00.txt		draft-ietf-webdav-depth-01.txt
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are		This document is an Internet-Draft. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	skipping to change at page 4, line 32		skipping to change at page 4, line 33
	9.1. Request		9.1. Request
	The DELETE-TREE method is only meaningful on a collection. If used		The DELETE-TREE method is only meaningful on a collection. If used
	on a non-collection the DELETE-TREE MUST be treated as a DELETE.		on a non-collection the DELETE-TREE MUST be treated as a DELETE.
	DELETE-TREE instructs that the collection specified in the request-		DELETE-TREE instructs that the collection specified in the request-
	URI, the records of its external member resources, and all its		URI, the records of its external member resources, and all its
	internal member resources, are to be deleted.		internal member resources, are to be deleted.
			If any member can not be deleted then all of the member's progeny
			MUST NOT be deleted, so as to maintain the namespace.
	Any headers included with DELETE-TREE MUST be applied in processing		Any headers included with DELETE-TREE MUST be applied in processing
	every resource to be deleted. In this case, a header of special		every resource to be deleted. In this case, a header of special
	interest is the DESTROY header which specifies the method to be used		interest is the DESTROY header which specifies the method to be used
	to delete all resources in the scope of the DELETE-TREE.		to delete all resources in the scope of the DELETE-TREE.
	When the DELETE-TREE method has completed processing it MUST return		When the DELETE-TREE method has completed processing it MUST return
	a consistent namespace. Please refer to [Goland et al., 1997] for a		a consistent namespace. Please refer to [Goland et al., 1997] for a
	full definition of a consistent namespace.		full definition of a consistent namespace.
	9.2. Response		9.2. Response
	skipping to change at page 5, line 23		skipping to change at page 5, line 23
	9.4. Example		9.4. Example
	DELETE-TREE /container/ HTTP/1.1		DELETE-TREE /container/ HTTP/1.1
	Host: www.foo.bar		Host: www.foo.bar
	Destroy: <http://www.ietf.org/standards/dav/NoUndelete>		Destroy: <http://www.ietf.org/standards/dav/NoUndelete>
	HTTP/1.1 207 Multi-Response		HTTP/1.1 207 Multi-Response
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: xxxxx		Content-Length: xxxxx
	<?XML:Namespace href =		<?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
	"http://www.ietf.org/standards/dav/" As = "D"/>		<d:multiresponse>
	<D:MultiResponse>		<d:response>
	<Response>		<d:href>http://www.foo.bar/container/resource1</d:href>
	<HREF>http://www.foo.bar/container/resource1</HREF>		<d:href>http://www.foo.bar/container/resource2</d:href>
	<HREF>http://www.foo.bar/container/resource2</HREF>		<d:status>HTTP/1.1 200 Success</d:status>
	<HREF>http://www.foo.bar/container/</HREF>		</d:response>
	<Status>HTTP/1.1 200 Success</Status>		<d:response>
	</Response>		<d:href>http://www.foo.bar/container/</d:href>
	<Response>		<d:status>HTTP/1.1 418 Method Failure</d:status>
	<HREF>http://www.foo.bar/container/resource3</HREF>		</d:response>
	<Status>HTTP/1.1 412 Precondition Failed</Status>		<d:response>
	</Response>		<d:href>http://www.foo.bar/container/resource3</d:href>
	</D:MultiResponse>		<d:status>HTTP/1.1 412 Precondition Failed</d:status>
			</d:response>
			</d:multiresponse>
	In this example the attempt to delete		In this example the attempt to delete
	http://www.foo.bar/container/resource3 failed. Given that there is		http://www.foo.bar/container/resource3 failed. Given that there is
	only one precondition, one can figure out that the failure was		only one precondition, one can figure out that the failure was
	caused the inability of the system to meet the requirement of the		caused the inability of the system to meet the requirement of the
	Destroy header. Normally however, the client will not know exactly		Destroy header. Normally however, the client will not know exactly
	what precondition caused the failure.		what precondition caused the failure.
	The result is that www.foo.bar/container/ is created in order to		The result is that container wasn't deleted because of the failure
	maintain namespace integrity.		to delete container/resource3.
	[Ed-Note: To state the obvious, do we want to provide information on		[Ed-Note: To state the obvious, do we want to provide information on
	which precondition actually failed? This is not the panacea it might		which precondition actually failed? This is not the panacea it might
	seem as the failure may have occurred for multiple reasons and		seem as the failure may have occurred for multiple reasons and
	listing a bunch of headers may or may not be useful. Besides, the		listing a bunch of headers may or may not be useful. Besides, the
	reality is, nobody every pays attention to error codes. There are		reality is, nobody every pays attention to error codes. There are
	really only two error codes in the world "It worked" or "Something		really only two error codes in the world "It worked" or "Something
	Went Wrong."]		Went Wrong."]
	10. COPY-TREE Method		10. COPY-TREE Method
	skipping to change at page 6, line 43		skipping to change at page 6, line 45
	Please refer to the definition of COPY in section XYZ of [Goland et		Please refer to the definition of COPY in section XYZ of [Goland et
	Al., 1997] for the rules on merging members and properties of source		Al., 1997] for the rules on merging members and properties of source
	collections with pre-existing collections at the destination.		collections with pre-existing collections at the destination.
	10.2. Response		10.2. Response
	The response is a multi-status response that describes the result of		The response is a multi-status response that describes the result of
	the COPY-TREE on each effected resource. The response is given for		the COPY-TREE on each effected resource. The response is given for
	the resource that was to be copied, not the resource that was		the resource that was to be copied, not the resource that was
	created as a result of the copy. In other words, each entry		created as a result of the copy. In other words, each entry
	indicates if the copy on the resource specified in the HREF		indicates if the copy on the resource specified in the href
	succeeded or failed and why.		succeeded or failed and why.
	The exception to this rule is for errors that occurred on the		The exception to this rule is for errors that occurred on the
	destination. For example, if the destination was locked the response		destination. For example, if the destination was locked the response
	would indicate the destination URL and a 416 "Locked" error.		would indicate the destination URL and a 416 "Locked" error.
	10.3. Example		10.3. Example
	COPY-TREE /container/ HTTP/1.1		COPY-TREE /container/ HTTP/1.1
	Host: www.foo.bar		Host: www.foo.bar
	Destination: http://www.foo.bar/othercontainer/		Destination: http://www.foo.bar/othercontainer/
	Enforce-Live-Properties: *		Enforce-Live-Properties: *
	HTTP/1.1 207 Multiresponse		HTTP/1.1 207 Multiresponse
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: xxxxx		Content-Length: xxxxx
	<?XML:Namespace href =		<?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
	"http://www.ietf.org/standards/dav/" As = "D"/>		<d:multiresponse>
	<D:MultiResponse>		<d:response>
	<Response>		<d:href>http://www.foo.bar/container/resource1</d:href>
	<HREF>http://www.foo.bar/container/resource1</HREF>		<d:href>http://www.foo.bar/container/resource2</d:href>
	<HREF>http://www.foo.bar/container/resource2</HREF>		<d:href>http://www.foo.bar/container/</d:href>
	<HREF>http://www.foo.bar/container/</HREF>		<d:href>http://www.foo.bar/container/R2/D2</d:href>
	<HREF>http://www.foo.bar/container/R2/D2</HREF>		<d:status>HTTP/1.1 201 Created</d:status>
	<Status>HTTP/1.1 201 Created</Status>		</d:response>
	</Response>		<d:response>
	<Response>		<d:href>http://www.foo.bar/container/R2/</d:href>
	<HREF>http://www.foo.bar/container/R2/</HREF>		<d:status>HTTP/1.1 415 Precondition Failed</d:status>
	<Status>HTTP/1.1 415 Precondition Failed</Status>		</d:response>
	</Response>		</d:multiresponse>
	</D:MultiResponse>
	In this example most of the resources, along with the container,		In this example most of the resources, along with the container,
	were copied successfully. However the container R2 failed, most		were copied successfully. However the container R2 failed, most
	likely due to a problem with enforcing live properties. R2's member		likely due to a problem with enforcing live properties. R2's member
	D3 was successfully copied. As a result a collection was created at		D3 was successfully copied. As a result a collection was created at
	www.foo.bar/othercontainer/R2 to contain D2.		www.foo.bar/othercontainer/R2 to contain D2.
	11. MOVE-TREE Method		11. MOVE-TREE Method
	11.1. Request		11.1. Request
	skipping to change at page 8, line 19		skipping to change at page 8, line 19
	As specified in the definition of MOVE, a MOVE of a collection over		As specified in the definition of MOVE, a MOVE of a collection over
	another collection causes the destination collection and all its		another collection causes the destination collection and all its
	members to be deleted.		members to be deleted.
	11.2. Response		11.2. Response
	The response is a multi-status response that describes the result of		The response is a multi-status response that describes the result of
	the MOVE-TREE on each effected resource. The response is given for		the MOVE-TREE on each effected resource. The response is given for
	the resource that was to be moved, not the resource that was created		the resource that was to be moved, not the resource that was created
	as a result of the move. In other words, each entry indicates if the		as a result of the move. In other words, each entry indicates if the
	move on the resource specified in the HREF succeeded or failed and		move on the resource specified in the href succeeded or failed and
	why.		why.
	The exception to this rule is for errors that occurred on the		The exception to this rule is for errors that occurred on the
	destination. For example, if the destination was locked the response		destination. For example, if the destination was locked the response
	would indicate the destination URL and a 416 "Locked" error.		would indicate the destination URL and a 416 "Locked" error.
	11.3. Example		11.3. Example
	MOVE-TREE /container/ HTTP/1.1		MOVE-TREE /container/ HTTP/1.1
	Host: www.foo.bar		Host: www.foo.bar
	Destination: http://www.foo.bar/othercontainer/		Destination: http://www.foo.bar/othercontainer/
	Enforce-Live-Properties: *		Enforce-Live-Properties: *
	Overwrite: False		Overwrite: False
	State-Token: <OpaqueLockToken:xxxx> <OpaqueLockToken:xxxx>		State-Token: <OpaqueLockToken:xxxx> <OpaqueLockToken:xxxx>
	HTTP/1.1 207 Multiresponse		HTTP/1.1 207 Multiresponse
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: xxxxx		Content-Length: xxxxx
	<?XML:Namespace href =		<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
	"http://www.ietf.org/standards/dav/" As = "D"/>		<d:multiresponse>
	<D:MultiResponse>		<d:response>
	<Response>		<d:href>http://www.foo.bar/container/resource1</d:href>
	<HREF>http://www.foo.bar/container/resource1</HREF>		<d:href>http://www.foo.bar/container/resource2</d:href>
	<HREF>http://www.foo.bar/container/resource2</HREF>		<d:href>http://www.foo.bar/container/</d:href>
	<HREF>http://www.foo.bar/container/</HREF>		<d:href>http://www.foo.bar/container/C2/R2</d:href>
	<HREF>http://www.foo.bar/container/C2/R2</HREF>		<d:status>HTTP/1.1 201 Created</d:status>
	<Status>HTTP/1.1 201 Created</Status>		</d:response>
	</Response>		<d:response>
			<d:href>http://www.foo.bar/container/C2</d:href>
	<Response>		<d:status>HTTP/1.1 418 Method Failure</d:status>
	<HREF>http://www.foo.bar/othercontainer/C2</HREF>		<d:response>
	<Status>HTTP/1.1 416 Locked</Status>		<d:href>http://www.foo.bar/othercontainer/C2</d:href>
	</Response>		<d:status>HTTP/1.1 416 Locked</d:status>
	</D:MultiResponse>		</d:response>
			</d:multiresponse>
	In this example the client has submitted a number of lock tokens		In this example the client has submitted a number of lock tokens
	with the request. A lock token will need to be submitted for every		with the request. A lock token will need to be submitted for every
	resource, both source and destination, anywhere in the scope of the		resource, both source and destination, anywhere in the scope of the
	method, that is locked. In this case the proper lock token was not		method, that is locked. In this case the proper lock token was not
	submitted for the destination http://www.foo.bar/othercontainer/C2.		submitted for the destination http://www.foo.bar/othercontainer/C2.
	However C2's child, R2, was successfully copied.		This means that the resource continer/c2 could not be copied,
			although its child container/C2/R2 could be copied.
	12. 102 "Processing" Response Code		12. 102 "Processing" Response Code
	The *-Tree methods can potentially take a long period of time to		The *-Tree methods can potentially take a long period of time to
	process. In such cases the client may time-out the connection while		process. In such cases the client may time-out the connection while
	waiting for a response. To prevent this the server MAY return a 102		waiting for a response. To prevent this the server MAY return a 102
	response code to indicate to the client that the server is still		response code to indicate to the client that the server is still
	processing the method.		processing the method.
	If a method is taking longer than [INSERT NUMBER HERE] seconds to		If a method is taking longer than [INSERT NUMBER HERE] seconds to
	process the server SHOULD return a 102 "Processing" response.		process the server SHOULD return a 102 "Processing" response.
	13. Status-URI Response Header		13. Status-URI Response Header
	skipping to change at page 10, line 22		skipping to change at page 10, line 22
	USA		USA
	e-mail: {yarong, saveenr}@microsoft.com		e-mail: {yarong, saveenr}@microsoft.com
	15. Bibliography		15. Bibliography
	[Goland et al., 1997] Y. Goland, E. J. Whitehead, Jr., Asad Faizi,		[Goland et al., 1997] Y. Goland, E. J. Whitehead, Jr., Asad Faizi,
	Stephen R. Carter, Del Jensen 'Extensions for Distributed Authoring		Stephen R. Carter, Del Jensen 'Extensions for Distributed Authoring
	and Versioning on the World Wide Web -- WEBDAV', March 1997, <URL:		and Versioning on the World Wide Web -- WEBDAV', March 1997, <URL:
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-webdav-protocol-		ftp://ftp.ietf.org/internet-drafts/draft-ietf-webdav-protocol-
	03.txt>		04.txt>
	[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-		[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
	Lee, 'Hypertext Transfer Protocol -- HTTP/1.1', RFC 2068, January		Lee, 'Hypertext Transfer Protocol -- HTTP/1.1', RFC 2068, January
	1997, <URL:ftp://ds.internic.net/rfc/rfc2068.txt>		1997, <URL:ftp://ds.internic.net/rfc/rfc2068.txt>
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/