--- 1/draft-ietf-webdav-bind-07.txt 2006-02-05 02:10:33.000000000 +0100 +++ 2/draft-ietf-webdav-bind-08.txt 2006-02-05 02:10:33.000000000 +0100 @@ -1,24 +1,23 @@ - Network Working Group G. Clemm Internet-Draft IBM Updates: 2518 (if approved) J. Crawford -Expires: March 29, 2005 IBM Research +Expires: May 26, 2005 IBM Research J. Reschke greenbytes J. Whitehead U.C. Santa Cruz - September 28, 2004 + November 25, 2004 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) - draft-ietf-webdav-bind-07 + draft-ietf-webdav-bind-08 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. @@ -31,21 +30,21 @@ 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 March 29, 2005. + This Internet-Draft will expire on May 26, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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. @@ -108,30 +107,33 @@ 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 13. Normative References . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 A. Change Log (to be removed by RFC Editor before publication) . 29 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 29 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 30 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 30 A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 30 A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 30 + A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 30 B. Resolved issues (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30 - B.1 ED_rfc2026_ref . . . . . . . . . . . . . . . . . . . . . . 30 - B.2 specify_safeness_and_idempotence . . . . . . . . . . . . . 30 - B.3 2.6_identical . . . . . . . . . . . . . . . . . . . . . . 31 + B.1 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30 + B.2 bind_vs_ACL . . . . . . . . . . . . . . . . . . . . . . . 31 + B.3 bind_properties . . . . . . . . . . . . . . . . . . . . . 31 + B.4 2.3_copy_to_same . . . . . . . . . . . . . . . . . . . . . 31 + B.5 6_rebind_intro . . . . . . . . . . . . . . . . . . . . . . 32 C. Open issues (to be removed by RFC Editor prior to - publication) . . . . . . . . . . . . . . . . . . . . . . . . . 31 - C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - Intellectual Property and Copyright Statements . . . . . . . . 34 + publication) . . . . . . . . . . . . . . . . . . . . . . . . . 32 + C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . 35 1. Introduction This specification extends the WebDAV Distributed Authoring Protocol 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 @@ -226,21 +228,22 @@ can be thought of as (U => R). Since a resource can represent items that are not network retrievable, as well as those that are, it is possible for a resource to have zero, one, or many URI mappings. Mapping a resource to an "http" scheme URI makes it possible to submit HTTP protocol requests to the resource using the URI. Path Segment Informally, the characters found between slashes ("/") in a URI. - Formally, as defined in section 3.3 of [RFC2396]. + Formally, as defined in section 3.3 of + [draft-fielding-rfc2396bis]. Binding A relation between a single path segment (in a collection) and a resource. A binding is part of the state of a collection. If two different collections contain a binding between the same path segment and the same resource, these are two distinct bindings. So for a collection C, a path segment S, and a resource R, the binding can be thought of as C:(S -> R). Bindings create URI mappings, and hence allow requests to be sent to a single resource @@ -341,22 +345,22 @@ with a binding in that collection accessible via a new URI, and thus creates new URI mappings to those resources but no new bindings. For example, suppose a new binding CollY is created for collection C1 in the figure below. It immediately becomes possible to access resource R1 using the URI /CollY/x.gif and to access resource R2 using the URI /CollY/y.jpg, but no new bindings for these child resources were created. This is because bindings are part of the state of a collection, and associate a URI that is relative to that collection with its target resource. No change to the bindings in - Collection C1 is needed to make its children accessible using /CollY/ - x.gif and /CollY/y.jpg. + Collection C1 is needed to make its children accessible using + /CollY/x.gif and /CollY/y.jpg. +-------------------------+ | Root Collection | | bindings: | | CollX CollY | +-------------------------+ | / | / | / +------------------+ @@ -458,37 +462,37 @@ 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.4 DELETE and Bindings When there are multiple bindings to a resource, a DELETE applied to that resource MUST NOT remove any bindings to that resource other - than the one identified by the request URI. For example, suppose the + than the one identified by the Request-URI. For example, suppose the collection identified by the URI "/a" has a binding named "x" to a resource R, and another collection identified by "/b" has a binding named "y" to the same resource R. Then a DELETE applied to "/a/x" removes the binding named "x" from "/a" but MUST NOT remove the binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues to identify the resource R). In particular, although Section 8.6.1 of [RFC2518] states that during DELETE processing, a server "MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member", a server that supports the binding protocol MUST NOT follow this requirement. When DELETE is applied to a collection, it MUST NOT modify the membership of any other collection that is not itself a member of the - collection being deleted. For example, if both "/a/.../x" and "/b/ - .../y" identify the same collection, C, then applying DELETE to "/a" - MUST NOT delete an internal member from C or from any other + collection being deleted. For example, if both "/a/.../x" and + "/b/.../y" identify the same collection, C, then applying DELETE to + "/a" MUST NOT delete an internal member from C or from any other collection that is a member of C, because that would modify the membership of "/b". If a collection supports the UNBIND method (see Section 5), a DELETE of an internal member of a collection MAY be implemented as an UNBIND request. In this case, applying DELETE to a Request-URI has the effect of removing the binding identified by the final segment of the Request-URI from the collection identified by the Request-URI minus its final segment. Although [RFC2518] allows a DELETE to be a non-atomic operation, when the DELETE operation is implemented as an @@ -626,21 +630,22 @@ 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. either both [/CollX, x.gif] and [/CollX, y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). - PCDATA value: segment, as defined in section 3.3 of [RFC2396] + 4. BIND Method The BIND method modifies the collection identified by the Request-URI, by adding a new binding from the segment specified in the BIND body to the resource identified in the BIND body. If a server cannot guarantee the integrity of the binding, the BIND request MUST fail. Note that it is especially difficult to maintain the integrity of cross-server bindings. Unless the server where the @@ -691,32 +696,32 @@ collection. (DAV:bind-source-exists): The DAV:href element MUST identify a resource. (DAV:binding-allowed): The resource identified by the DAV:href supports multiple bindings to it. (DAV:cross-server-binding): If the resource identified by the DAV:href element in the request body is on another server from the - collection identified by the request-URI, the server MUST support + collection identified by the Request-URI, the server MUST support cross-server bindings. (DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name. (DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T". (DAV:cycle-allowed): If the DAV:href element identifies a - collection, and if the request-URI identifies a collection that is + collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace. (DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in an If request header. (DAV:locked-overwrite-allowed): If the collection already contains a binding with the specified path segment, and if that binding is protected by a write-lock, then the appropriate token MUST be @@ -832,23 +837,25 @@ HTTP/1.1 200 OK The server removed the binding named "foo.html" from the collection, "http://www.example.com/CollX". A request to the resource named "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) response. 6. REBIND Method - The REBIND method removes a binding to a resource from one - collection, and adds a binding to that resource into another - collection. It is effectively an atomic form of a MOVE request. + The REBIND method removes a binding to a resource from the collection + identified by the Request-URI, and adds a binding to that resource + into another collection. The request body specifies the binding to + be removed (segment) and the new binding to be created (href). It is + effectively an atomic form of a MOVE request. This method is unsafe and idempotent (see [RFC2616], section 9.1). Marshalling: The request MAY include an Overwrite header. The request body MUST be a DAV:rebind XML element. @@ -869,32 +876,32 @@ Preconditions: (DAV:rebind-into-collection): The Request-URI MUST identify a collection. (DAV:rebind-source-exists): The DAV:href element MUST identify a resource. (DAV:cross-server-binding): If the resource identified by the DAV:href element in the request body is on another server from the - collection identified by the request-URI, the server MUST support + collection identified by the Request-URI, the server MUST support cross-server bindings. (DAV:name-allowed): The name specified by the DAV:segment is available for use as a new binding name. (DAV:can-overwrite): If the collection already contains a binding with the specified path segment, and if an Overwrite header is included, the value of the Overwrite header MUST be "T". (DAV:cycle-allowed): If the DAV:href element identifies a - collection, and if the request-URI identifies a collection that is + collection, and if the Request-URI identifies a collection that is a member of that collection, the server MUST support cycles in the URI namespace. (DAV:locked-update-allowed): If the collection identified by the Request-URI is write-locked, then the appropriate token MUST be specified in the request. (DAV:protected-url-modification-allowed): If the collection identified by the Request-URI already contains a binding with the specified path segment, and if that binding is protected by a @@ -1188,50 +1195,52 @@ All IANA considerations mentioned in [RFC2518] also apply to this document. 12. 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, Rajiv Dulepet, David Durand, 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. + Spencer Dawkins, Mark Day, 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. 13 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC-xml-20040204, February 2004, . + [draft-fielding-rfc2396bis] + Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", ID + draft-fielding-rfc2396bis-07, September 2004. + Authors' Addresses Geoffrey Clemm IBM 20 Maguire Road Lexington, MA 02421 EMail: geoffrey.clemm@us.ibm.com Jason Crawford @@ -1286,62 +1295,124 @@ Editorial fixes. Add and resolve issues "1.3_error_negotiation", "2.5_language" and "7.1.1_add_resource_id". Add historical issue "4_LOCK_BEHAVIOR" and it's resolution for better tracking. A.5 Since draft-ietf-webdav-bind-06 Rewrite Editorial Note. Open and resolve issues "2.6_identical", "specify_safeness_and_idempotence" and "ED_rfc2026_ref". +A.6 Since draft-ietf-webdav-bind-07 + + Add more index items (no change tracking). Add and resolve issues + "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", + "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML + DTD fragment in section 3.3. Make spelling of "Request-URI" + consistent. + Appendix B. Resolved issues (to be removed by RFC Editor before publication) Issues that were either rejected or resolved in this version of this document. -B.1 ED_rfc2026_ref +B.1 rfc2396bis Type: edit - + julian.reschke@greenbytes.de (2004-10-21): Update references to + RFC2396 with draft-fielding-uri-rfc2396bis-07. - julian.reschke@greenbytes.de (2004-09-27): The reference to RFC2026 - isn't used anywhere in the text. + Resolution (2004-11-06): Done. - Resolution (2004-09-27): Remove it. +B.2 bind_vs_ACL -B.2 specify_safeness_and_idempotence + Type: change - Type: edit + - + lisa@osafoundation.org (2004-03-24): What permissions are required in + order to perform a BIND request? I would think that permissions for + UNBIND and REBIND are identical to permissions for DELETE and MOVE + respectively, but this should be stated. - julian.reschke@greenbytes.de (2004-09-18): Specify safeness and - idempotence of new methods. + Resolution (2004-10-16): BIND and UNBIND are controlled by the + privileges DAV:bind and DAV:unbind. REBIND is an atomic form of + MOVE, those the same privileges apply. The authors feel that this + does not need to be explicitly stated (see + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0150.htm + l). - Resolution (2004-09-19): Done. +B.3 bind_properties -B.3 2.6_identical + Type: change + + + + lisa@osafoundation.org (2004-03-24): (Issues with BIND semantics vs + servers that compute properties based on request-URI, see + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.htm + l and + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0154.htm + l). + + Resolution (2004-10-16): The authors feel that in the WebDAV data + model, properties are part of the state of the resource, thus should + not vary on request URI. A server that implements properties as + state of a binding instead of the resource to which it binds would be + inherently incompatible with both WebDAV and BIND semantics. It's + unclear why this would matter - a server that can't implement BIND + + semantics simply can't support this specification (likely for more + reasons than this one). See also summary at + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0022.htm + l. + +B.4 2.3_copy_to_same Type: change + - + lisa@osafoundation.org (2004-03-24): When a user does a COPY or MOVE + from one binding to another binding to the same resource, this should + be flagged as an error. Since this has to interoperate with existing + clients that won't look at the error body, the status code would have + to stand alone. 409 is already used for non-existent parent + collections, so that can't be reused. Possibly 403 which in 2518 for + COPY means "_ The source and destination URIs are the same." - julian.reschke@greenbytes.de (2004-09-17): Clarify exactly when when - two resource-ids are identical. + Resolution (2004-10-16): Copying/moving to a binding identifying the + same resource is harmless (see explanation in + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0143.htm + l) and does not need to be rejected by the server. - Resolution (2004-09-17): They are identical if and only they are the - same character by character. +B.5 6_rebind_intro + + Type: edit + + + + ejw@cs.ucsc.edu (2004-11-12): I'm reading through the BIND + specification, and the description of the REBIND method's operands is + a bit unclear to me. I'm assuming the intent is similar to BIND and + UNBIND, each of which clearly state in the first sentence what role + the Request-URI, segment, and href fields play. In my reading I just + jumped right into the spec. at this method (typical reference + reading pattern), and hence I didn't initially see the similarity + with the BIND and UNBIND method operands. + + Resolution (2004-11-12): Agreed and fixed. Appendix C. Open issues (to be removed by RFC Editor prior to publication) C.1 edit Type: edit julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for editorial fixes/enhancements. @@ -1349,36 +1420,38 @@ Index 2 208 Already Reported (status code) 23 5 506 Loop Detected (status code) 25 B BIND method 16 + Binding 7 C + Collection 7 Condition Names DAV:bind-into-collection (pre) 17 DAV:bind-source-exists (pre) 17 DAV:binding-allowed (pre) 17 DAV:binding-deleted (post) 19, 22 DAV:can-overwrite (pre) 17, 21 DAV:cross-server-binding (pre) 17, 21 DAV:cycle-allowed (pre) 17, 21 DAV:lock-deleted (post) 19, 22 DAV:locked-overwrite-allowed (pre) 17 DAV:locked-source-collection-update-allowed (pre) 21 DAV:locked-update-allowed (pre) 17, 19, 21 DAV:name-allowed (pre) 17, 21 - DAV:new-binding (post) 17, 22 + DAV:new-binding (post) 18, 22 DAV:protected-source-url-deletion-allowed (pre) 21 DAV:protected-url-deletion-allowed (pre) 19 DAV:protected-url-modification-allowed (pre) 21 DAV:rebind-into-collection (pre) 21 DAV:rebind-source-exists (pre) 21 DAV:unbind-from-collection (pre) 19 DAV:unbind-source-exists (pre) 19 D DAV header @@ -1388,52 +1461,57 @@ DAV:binding-allowed precondition 17 DAV:binding-deleted postcondition 19, 22 DAV:can-overwrite precondition 17, 21 DAV:cross-server-binding precondition 17, 21 DAV:cycle-allowed precondition 17, 21 DAV:lock-deleted postcondition 19, 22 DAV:locked-overwrite-allowed precondition 17 DAV:locked-source-collection-update-allowed precondition 21 DAV:locked-update-allowed precondition 17, 19, 21 DAV:name-allowed precondition 17, 21 - DAV:new-binding postcondition 17, 22 + DAV:new-binding postcondition 18, 22 DAV:parent-set property 15 DAV:protected-source-url-deletion-allowed precondition 21 DAV:protected-url-deletion-allowed precondition 19 DAV:protected-url-modification-allowed precondition 21 DAV:rebind-into-collection precondition 21 DAV:rebind-source-exists precondition 21 DAV:resource-id property 15 DAV:unbind-from-collection precondition 19 DAV:unbind-source-exists precondition 19 +I + Internal Member URI 7 + M Methods BIND 16 REBIND 20 UNBIND 18 P + Path Segment 7 Properties DAV:parent-set 15 DAV:resource-id 15 R REBIND method 20 S Status Codes 208 Already Reported 23 506 Loop Detected 25 U UNBIND method 18 + URI Mapping 6 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be