--- 1/draft-ietf-webdav-bind-20.txt 2008-10-03 17:12:17.000000000 +0200 +++ 2/draft-ietf-webdav-bind-21.txt 2008-10-03 17:12:17.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group G. Clemm Internet-Draft IBM Updates: 4918 (if approved) J. Crawford Intended status: Standards Track IBM Research -Expires: May 18, 2008 J. Reschke, Ed. +Expires: April 6, 2009 J. Reschke, Ed. greenbytes J. Whitehead U.C. Santa Cruz - November 15, 2007 + October 3, 2008 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) - draft-ietf-webdav-bind-20 + draft-ietf-webdav-bind-21 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,32 +28,27 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 18, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). + This Internet-Draft will expire on April 6, 2009. Abstract This specification defines bindings, and the BIND method for creating 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. - Servers are required to insure the integrity of any bindings that they allow to be created. Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at @@ -62,54 +57,54 @@ lists all registered issues since draft 02. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Method Preconditions and Postconditions . . . . . . . . . 7 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8 - 2.1.1. Bind loops . . . . . . . . . . . . . . . . . . . . . . 9 + 2.1.1. Bind Loops . . . . . . . . . . . . . . . . . . . . . . 9 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 9 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10 - 2.3.1. Example: COPY with 'Depth: infinity' in presence - of bind loops . . . . . . . . . . . . . . . . . . . . 12 - 2.3.2. Example: COPY with 'Depth: infinity' with multiple - bindings to a leaf resource . . . . . . . . . . . . . 14 + 2.3.1. Example: COPY with 'Depth: infinity' in Presence + of Bind Loops . . . . . . . . . . . . . . . . . . . . 12 + 2.3.2. Example: COPY with 'Depth: infinity' with Multiple + Bindings to a Leaf Resource . . . . . . . . . . . . . 14 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 16 - 2.5.2. Example: MOVE request causing a bind loop . . . . . . 16 + 2.5.2. Example: MOVE Request causing a Bind Loop . . . . . . 16 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 18 2.7. Determining Whether Two Bindings Are to the Same Resource . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 19 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 19 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 20 - 3.2.1. Example for DAV:parent-set property . . . . . . . . . 20 + 3.2.1. Example for DAV:parent-set Property . . . . . . . . . 20 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 24 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 26 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 28 - 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.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31 - 7.1.1. Example: PROPFIND by bind-aware client . . . . . . . . 32 - 7.1.2. Example: PROPFIND by non-bind-aware client . . . . . . 34 + 7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32 + 7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34 - 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 34 - 8.1. OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 34 - 8.2. 'DAV' request header . . . . . . . . . . . . . . . . . . . 34 + 8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34 + 8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34 + 8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 35 10.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 35 10.3. Bindings, and Denial of Service . . . . . . . . . . . . . 35 10.4. Private Locations May Be Revealed . . . . . . . . . . . . 36 10.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 36 11. Internationalization Considerations . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 @@ -131,33 +126,29 @@ 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 - Appendix C. Resolved issues (to be removed by RFC Editor - before publication) . . . . . . . . . . . . . . . . . 41 - C.1. 2.1.1-bind-loops . . . . . . . . . . . . . . . . . . . . . 41 - C.2. 2.1.1-cycles . . . . . . . . . . . . . . . . . . . . . . . 42 - C.3. 2.5-move-creating-cycles . . . . . . . . . . . . . . . . . 42 - C.4. 3.1-clarify-resource-id . . . . . . . . . . . . . . . . . 42 - C.5. 4-precondition-language . . . . . . . . . . . . . . . . . 42 - Appendix D. Open issues (to be removed by RFC Editor prior to - publication) . . . . . . . . . . . . . . . . . . . . 43 - D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 - Intellectual Property and Copyright Statements . . . . . . . . . . 47 + B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 41 + Appendix C. Open issues (to be removed by RFC Editor prior to + publication) . . . . . . . . . . . . . . . . . . . . 41 + C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 + C.2. status-codes . . . . . . . . . . . . . . . . . . . . . . . 42 + C.3. relation-to-deltav . . . . . . . . . . . . . . . . . . . . 42 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 + Intellectual Property and Copyright Statements . . . . . . . . . . 46 1. Introduction This specification extends the WebDAV Distributed Authoring Protocol ([RFC4918]) to enable clients to create new access paths to existing resources. This capability is useful for several reasons: URIs of WebDAV-compliant resources are hierarchical and correspond to a hierarchy of collections in resource space. The WebDAV Distributed Authoring Protocol makes it possible to organize these resources into @@ -339,21 +330,21 @@ | bindings: | | x.gif y.jpg | +------------------+ | \ | \ | \ +-------------+ +-------------+ | Resource R1 | | Resource R2 | +-------------+ +-------------+ -2.1.1. Bind loops +2.1.1. Bind Loops Bindings to collections can result in loops ("cycles"), which servers MUST detect when processing "Depth: infinity" requests. It is sometimes possible to complete an operation in spite of the presence of a loop. For instance, a PROPFIND can still succeed if the server uses the new status code 208 (Already Reported) defined in Section 7.1. However, the 506 (Loop Detected) status code is defined in Section 7.2 for use in contexts where an operation is terminated @@ -446,21 +437,21 @@ bindings to a resource, more than one source resource updates a single destination resource, the order of the updates is server defined. If a COPY request would cause a new resource to be created as a copy of an existing resource, and that COPY request has already created a copy of that existing resource, the COPY request instead creates another binding to the previous copy, instead of creating a new resource. -2.3.1. Example: COPY with 'Depth: infinity' in presence of bind loops +2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops As an example of how COPY with Depth infinity would work in the presence of bindings, consider the following collection: +------------------+ | Root Collection | | bindings: | | CollX | +------------------+ | @@ -528,22 +519,22 @@ +-------------+ | bindings: | | | y.gif CollZ | | +-----------------+ | | | | | +-------+ | +-------------+ | Resource R4 | +-------------+ -2.3.2. Example: COPY with 'Depth: infinity' with multiple bindings to a - leaf resource +2.3.2. Example: COPY with 'Depth: infinity' with Multiple Bindings to a + Leaf Resource Given the following collection hierarchy: +------------------+ | Root Collection | | bindings: | | CollX | +------------------+ | | @@ -657,21 +648,21 @@ >> After Request: URI-1 URI-2 URI-X | | | | | | <---- URI Mappings | | | +---------------------+ | Resource R | +---------------------+ -2.5.2. Example: MOVE request causing a bind loop +2.5.2. Example: MOVE Request causing a Bind Loop Note that in the presence of collection bindings, a MOVE request can cause the creating of a bind loop. Consider a the top level collections C1 and C2 with URIs "/CollW/" and "/CollX/". C1 also contains an additional binding named "CollY" to C2: +------------------+ | Root Collection | @@ -815,21 +806,21 @@ A given collection MUST appear only once in the DAV:parent-set for any given binding, even if there are multiple URI mappings to that collection. -3.2.1. Example for DAV:parent-set property +3.2.1. Example for DAV:parent-set Property For example, if collection C1 is mapped to both /CollX and /CollY, and C1 contains a binding named "x.gif" to a resource R1, then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set of R1, but not both. But if C1 also had a binding named "y.gif" to R1, then there would be two entries for C1 in the DAV:binding-set of R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). +-------------------------+ @@ -1195,21 +1186,21 @@ "http://www.example.com/CollX", associating "foo.html" with the resource identified by the URI "http://www.example.com/CollY/bar.html", and removes the binding named "bar.html" from the collection identified 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 that resource, and requests on the URI "http://www.example.com/CollY/bar.html" will fail with a 404 (Not Found) response. -6.2. Example: REBIND in presence of locks and bind loops +6.2. Example: REBIND in Presence of Locks and Bind Loops To illustrate the effects of locks and bind loops on a REBIND operation, consider the following collection: +------------------+ | Root Collection | | bindings: | | CollW | +------------------+ | @@ -1234,32 +1225,32 @@ +-----------------+ +------------------+ | | | | | +-----+ | +---------------------------+ | Resource R2 | | (lock inherited from C1) | | (lock token L1) | +---------------------------+ - (where L1 is "opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). + (where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). Note that the binding between CollZ and C1 creates a loop in the containment hierarchy. Servers are not required to support such loops, though the server in this example does. The REBIND request below will remove the segment "CollZ" from C3 and add a new binding from "CollA" to the collection C2. REBIND /CollW/CollX HTTP/1.1 Host: www.example.com - If: () + If: () Content-Type: application/xml; charset="utf-8" Content-Length: xxx CollA /CollW/CollY/CollZ The outcome of the REBIND operation is: @@ -1320,21 +1311,21 @@ 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 +7.1.1. Example: PROPFIND by Bind-Aware Client For example, consider a PROPFIND request on /Coll (bound to collection C), where the members of /Coll are /Coll/Foo (bound to resource R) and /Coll/Bar (bound to collection C). >> Request: PROPFIND /Coll/ HTTP/1.1 Host: www.example.com Depth: infinity @@ -1392,21 +1383,21 @@ urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 HTTP/1.1 208 Already Reported -7.1.2. Example: PROPFIND by non-bind-aware client +7.1.2. Example: PROPFIND by Non-Bind-Aware Client In this example, the client isn't aware of the 208 status code 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 @@ -1423,32 +1414,32 @@ HTTP/1.1 506 Loop Detected 7.2. 506 Loop Detected The 506 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with "Depth: infinity". This status indicates that the entire operation failed. -8. Capability discovery +8. Capability Discovery -8.1. OPTIONS method +8.1. OPTIONS Method If the server supports bindings, it MUST return the compliance class name "bind" as a field in the "DAV" response header (see [RFC4918], Section 10.1) from an OPTIONS request on any resource implemented by that server. A value of "bind" in the "DAV" header MUST indicate that the server supports all MUST level requirements and REQUIRED features specified in this document. -8.2. 'DAV' request header +8.2. 'DAV' Request Header Clients SHOULD signal support for all MUST level requirements and 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. Relationship to WebDAV Access Control Protocol BIND and REBIND behave the same as MOVE with respect to the DAV:acl property (see [RFC3744], Section 7.3). @@ -1513,25 +1504,25 @@ 12. IANA Considerations Section 7 defines the HTTP status codes 208 (Already Reported) and 506 (Loop Detected), to be added to the registry at . 13. Acknowledgements This document is the collaborative product of the authors and Tyson - Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has - benefited from thoughtful discussion by Jim Amsden, Peter Carlson, - Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, - Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, - Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe + Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited + from thoughtful discussion by Jim Amsden, Peter Carlson, Steve + Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer + Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa + Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and other members of the WebDAV working group. 14. References 14.1. Normative References @@ -1574,24 +1565,24 @@ [RFC4918], Section 9.10.1 claims: A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. This is incorrect in that it implies that the "lock root" is a resource, not a URL - (). - However, should a directly locked resource have multiple bindings, - only the one used in the Request-URI of the LOCK request will be the - protected from changes of clients not supplying the lock token. + (). However, + should a directly locked resource have multiple bindings, only the + one used in the Request-URI of the LOCK request will be the protected + from changes of clients not supplying the lock token. A correct description would be: A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The Request-URI becomes the root of the lock. Note that this change makes the description consistent with the definition of the DAV:lockroot XML element in Section 14.12 of @@ -1741,94 +1732,67 @@ B.17. Since draft-ietf-webdav-bind-18 Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918. B.18. Since draft-ietf-webdav-bind-19 Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move- creating-cycles", "3.1-clarify-resource-id" and "4-precondition- language". -Appendix C. Resolved issues (to be removed by RFC Editor before - publication) - - Issues that were either rejected or resolved in this version of this - document. - -C.1. 2.1.1-bind-loops - - In Section 2.1.1: - - Type: edit +B.19. Since draft-ietf-webdav-bind-20 - julian.reschke@greenbytes.de (2007-07-29): Add a clarification over - here that support for bind loops (= cycles) is optional. + Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples. + Replace RFC518bis issue link by pointer to RFC Errata Page. - Resolution (2007-11-11): Done. + Add issues "relation-to-deltav" and "status-codes". -C.2. 2.1.1-cycles +Appendix C. Open issues (to be removed by RFC Editor prior to + publication) - In Section 2.1.1: +C.1. edit Type: edit - julian.reschke@greenbytes.de (2007-11-11): We never introduce the - term "cycle". - - Resolution (2007-11-11): Fixed. - -C.3. 2.5-move-creating-cycles + julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for + editorial fixes/enhancements. - In Section 2.5: +C.2. status-codes Type: change - julian.reschke@greenbytes.de (2007-11-10): In presence of collection - bindings, a MOVE operation can lead to a bind cycle. Add an example, - and mention the right way to reject the request if that is required. - See thread starting at . + -C.4. 3.1-clarify-resource-id + julian.reschke@greenbytes.de (2008-09-26): The spec currently micro- + manages HTTP status codes: for instance, for a successful BIND it + requires status codes of 200 or 201, while - from an HTTP point of + view - a 204 should be acceptable as well. Proposal: rephrase the + text so that other success codes are acceptable as well, or remove + the normative language completely, point to RFC2616, and rely on + examples. - In Section 3.1: +C.3. relation-to-deltav Type: change - julian.reschke@greenbytes.de (2007-11-11): Clarify that as the - resource-id is a URI, it is effectively an alternate identifier for - the resource. Thus, if it is resolvable, it should be resolved to - the same resource. - - Resolution (2007-11-11): Done. - -C.5. 4-precondition-language - - In Section 4: - - Type: edit - - julian.reschke@greenbytes.de (2007-11-11): Rephrase definitions for - DAV:cross-server-binding and DAV:cycle-allowed so it becomes clear - that support for these features is optional. - - Resolution (2007-11-11): Done. - -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. + werner.donne@re.be (2008-08-11): ...When supporting version + controlled collections, bindings may be introduced in a server + without actually issuing the BIND method. When a MOVE is performed + of a resource from one collection to another, both collections should + be checked out. An additional binding would be the result if one + collection would be subsequently checked in, while the check-out of + the other is undone. The resulting situation is meaningless if the + binding model is not supported... Index 2 208 Already Reported (status code) 31, 36 5 506 Loop Detected (status code) 34, 36 B @@ -1946,21 +1909,21 @@ Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064 Email: ejw@cse.ucsc.edu Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF @@ -1983,15 +1946,10 @@ attempt made to obtain a general license or permission for the use of 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 copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).