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/