--- 1/draft-ietf-webdav-bind-08.txt 2006-02-05 02:10:34.000000000 +0100 +++ 2/draft-ietf-webdav-bind-09.txt 2006-02-05 02:10:34.000000000 +0100 @@ -1,23 +1,24 @@ + Network Working Group G. Clemm Internet-Draft IBM Updates: 2518 (if approved) J. Crawford -Expires: May 26, 2005 IBM Research +Expires: June 9, 2005 IBM Research J. Reschke greenbytes J. Whitehead U.C. Santa Cruz - November 25, 2004 + December 9, 2004 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) - draft-ietf-webdav-bind-08 + draft-ietf-webdav-bind-09 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. @@ -30,21 +31,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 May 26, 2005. + This Internet-Draft will expire on June 9, 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. @@ -64,76 +65,92 @@ all registered issues since draft 02. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Rationale for Distinguishing Bindings from URI Mappings . 7 1.3 Method Preconditions and Postconditions . . . . . . . . . 8 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9 + 2.1.1 Bind loops . . . . . . . . . . . . . . . . . . . . . . 10 2.2 URI Mappings Created by a new Binding . . . . . . . . . . 10 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 11 - 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 12 - 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 13 + 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.6 Determining Whether Two Bindings Are to the Same - Resource . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.7 Discovering the Bindings to a Resource . . . . . . . . . . 14 - 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 15 - 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 15 - 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 18 - 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 20 - 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 22 - 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 23 - 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 23 - 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 23 - 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 25 - 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 25 - 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 26 - 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 26 - 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 26 - 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 26 - 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 26 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 27 - 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 27 - 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 27 - 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 27 - 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 27 - 10. Internationalization Considerations . . . . . . . . . . . . 27 - 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 + Resource . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 2.7 Discovering the Bindings to a Resource . . . . . . . . . . 17 + 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 17 + 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 18 + 3.2.1 Example for DAV:parent-set property . . . . . . . . . 18 + 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 22 + 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 24 + 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 26 + 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 27 + 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 27 + 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 27 + 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 29 + 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 29 + 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 30 + 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 30 + 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 30 + 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 30 + 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 30 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 31 + 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 31 + 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 31 + 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 31 + 10. Internationalization Considerations . . . . . . . . . . . . 31 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 32 + 13.2 Informative References . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 + A. Change Log (to be removed by RFC Editor before publication) . 33 + A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 33 + A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 34 + A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 34 + A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 34 + A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 34 + A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 34 + A.7 Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 34 B. Resolved issues (to be removed by RFC Editor before - publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 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 + publication) . . . . . . . . . . . . . . . . . . . . . . . . . 35 + B.1 2_allow_destroy . . . . . . . . . . . . . . . . . . . . . 35 + B.2 2.1_separate_loop_discussion . . . . . . . . . . . . . . . 35 + B.3 2.1.1_bind_loops_vs_locks . . . . . . . . . . . . . . . . 35 + B.4 2.3_copy_depth_infinity . . . . . . . . . . . . . . . . . 36 + B.5 2.3_copy_vs_loops . . . . . . . . . . . . . . . . . . . . 36 + B.6 2.3_copy_example . . . . . . . . . . . . . . . . . . . . . 37 + B.7 2.6_resource-id_vs_versions . . . . . . . . . . . . . . . 37 + B.8 3.2_example . . . . . . . . . . . . . . . . . . . . . . . 37 + B.9 atomicity . . . . . . . . . . . . . . . . . . . . . . . . 38 + B.10 6_rebind_intro . . . . . . . . . . . . . . . . . . . . . . 38 + B.11 6_rebind_premissions . . . . . . . . . . . . . . . . . . . 38 C. Open issues (to be removed by RFC Editor prior to - publication) . . . . . . . . . . . . . . . . . . . . . . . . . 32 - C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - Intellectual Property and Copyright Statements . . . . . . . . 35 + publication) . . . . . . . . . . . . . . . . . . . . . . . . . 39 + C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + C.2 2.6_when_do_ids_change . . . . . . . . . . . . . . . . . . 39 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + Intellectual Property and Copyright Statements . . . . . . . . 42 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 @@ -323,31 +340,27 @@ There is no difference between an initial binding added by PUT, COPY, or MKCOL, and additional bindings added with BIND. It would be very undesirable if one binding could be destroyed as a side effect of operating on the resource through a different binding. In particular, the removal of one binding to a resource (e.g. with a DELETE or a MOVE) MUST NOT disrupt another binding to that resource, e.g. by turning that binding into a dangling path segment. The server MUST NOT reclaim system resources after removing one binding, while other bindings to the resource remain. In other words, the - server MUST maintain the integrity of a binding. + server MUST maintain the integrity of a binding. It is permissible, + however, for future method definitions (e.g., a DESTROY method) to + have semantics that explicitly remove all bindings and/or immediately + reclaim system resources. 2.1 Bindings to Collections - Bindings to collections can result in loops, 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. - However, the 506 (Loop Detected) status code is defined in Section 7 - for use in contexts where an operation is terminated because a loop - was encountered. - Creating a new binding to a collection makes each resource associated 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 @@ -368,20 +381,32 @@ | bindings: | | x.gif y.jpg | +------------------+ | \ | \ | \ +-------------+ +-------------+ | Resource R1 | | Resource R2 | +-------------+ +-------------+ +2.1.1 Bind loops + + Bindings to collections can result in loops, 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 because a + loop was encountered. + 2.2 URI Mappings Created by a new Binding Suppose a binding from "Binding-Name" to resource R is to be added to a collection, C. Then if C-MAP is the set of URIs that were mapped to C before the BIND request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following the BIND request. For example, if a binding from "foo.html" to R is added to a collection C, and if the following URIs are mapped to C: @@ -458,41 +483,169 @@ 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 + + As an example of how COPY with Depth infinity would work in the + presence of bindings, consider the following collection: + + +------------------+ + | Root Collection | + | bindings: | + | CollX | + +------------------+ + | + | + +-------------------------------+ + | Collection C1 |<-------+ + | bindings: | | + | x.gif CollY | | + +-------------------------------+ | + | \ (creates loop) | + | \ | + +-------------+ +------------------+ | + | Resource R1 | | Collection C2 | | + +-------------+ | bindings: | | + | y.gif CollZ | | + +------------------+ | + | | | + | +--------+ + | + +-------------+ + | Resource R2 | + +-------------+ + + If a COPY with Depth inifinity is submitted to /CollX, with + destination of /CollA, the outcome of the copy operation is: + + +------------------+ + | Root Collection | + | bindings: | + | CollX CollA | + +------------------+ + | | + | +---------------------------+ + | | + +-------------------+ | + | Collection C1 |<------------------+ | + | bindings: | | | + | x.gif CollY | | | + +-------------------+ | | + | \ (creates loop) | | + | \ | | + +-------------+ +-----------------+ | | + | Resource R1 | | Collection C2 | | | + +-------------+ | bindings: | | | + | y.gif CollZ | | | + +-----------------+ | | + | | | | + | +-------+ | + | | + +-------------+ | + | Resource R2 | | + +-------------+ | + | + +-------------------------------+ + | + +-------------------+ + | Collection C3 |<------------------+ + | bindings: | | + | x.gif CollY | | + +-------------------+ | + | \ (creates loop) | + | \ | + +-------------+ +-----------------+ | + | Resource R3 | | Collection C4 | | + +-------------+ | bindings: | | + | y.gif CollZ | | + +-----------------+ | + | | | + | +-------+ + | + +-------------+ + | Resource R4 | + +-------------+ + +2.3.2 Example: COPY with 'Depth: infinity' with multiple bindings to a + leaf resource + + Given the following collection hierarchy: + + +------------------+ + | Root Collection | + | bindings: | + | CollX | + +------------------+ + | + | + | + +----------------+ + | Collection C1 | + | bindings: | + | x.gif y.gif | + +----------------+ + | | + | | + +-------------+ + | Resource R1 | + +-------------+ + + A COPY of /CollX with Depth infinity to /CollY results in the + following collection hierarchy: + + +------------------+ + | Root Collection | + | bindings: | + | CollX CollY | + +------------------+ + | \ + | \ + | \ + +----------------+ +-----------------+ + | Collection C1 | | Collection C2 | + | bindings: | | bindings: | + | x.gif y.gif | | x.gif y.gif | + +----------------+ +-----------------+ + | | | | + | | | | + +-------------+ +-------------+ + | Resource R1 | | Resource R2 | + +-------------+ +-------------+ + 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 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 + "/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 @@ -563,42 +717,43 @@ the client can be assured that the two bindings are to the same resource. The DAV:resource-id property is created, and its value assigned, when the resource is created. The value of DAV:resource-id MUST NOT be changed. Even after the resource is no longer accessible through any URI, that value MUST NOT be reassigned to another resource's DAV:resource-id property. Any method that creates a new resource MUST assign a new, unique - value to its DAV:resource-id property. For example, a PUT or a COPY - that creates a new resource must assign a new, unique value to the - DAV:resource-id property of that new resource. + value to its DAV:resource-id property. For example, a PUT applied to + a null resource, COPY (when not overwriting an existing target) and + CHECKIN (see [RFC3253], section 4.4) must assign a new, unique value + to the DAV:resource-id property of the new resource they create. - On the other hand, any method that affects an existing resource MUST - NOT change the value of its DAV:resource-id property. For example, a - PUT or a COPY that updates an existing resource must not change the - value of its DAV:resource-id property. A MOVE, since it does not + On the other hand, any method that affects an existing resource must + not change the value of its DAV:resource-id property. Specifically, + a PUT or a COPY that updates an existing resource must not change the + value of its DAV:resource-id property. A REBIND, since it does not create a new resource, but only changes the location of an existing resource, must not change the value of the DAV:resource-id property. 2.7 Discovering the Bindings to a Resource An OPTIONAL DAV:parent-set property on a resource provides a list of the bindings that associate a collection and a URI segment with that resource. If the DAV:parent-set property exists on a given resource, it MUST contain a complete list of all bindings to that resource that the client is authorized to see. When deciding whether to support the DAV:parent-set property, server implementers / administrators should balance the benefits it provides against the cost of maintaining the property and the security risks enumerated in - Sections 8.4 and 8.5. + Sections 9.4 and 9.5. 3. Properties The bind feature introduces the following properties for a resource. A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document. This allows a binding server to perform efficiently when a naive client, which does not understand the cost of asking a server to compute all possible live properties, issues a DAV:allprop PROPFIND request. @@ -619,34 +774,72 @@ The DAV:parent-set property is an OPTIONAL property that enables clients to discover what collections contain a binding to this resource (i.e. what collections have that resource as an internal member). It contains an of href/segment pair for each collection that has a binding to the resource. The href identifies the collection, and the segment identifies the binding name of that resource in that collection. 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. 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. either both [/CollX, x.gif] and [/CollX, - y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). + collection. +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]). + + +-------------------------+ + | Root Collection | + | bindings: | + | CollX CollY | + +-------------------------+ + | / + | / + | / + +-----------------+ + | Collection C1 | + | bindings: | + | x.gif y.gif | + +-----------------+ + | | + | | + | | + +--------------+ + | Resource R1 | + +--------------+ + + In this case, one possible value for DAV:parent-set property on + "/CollX/x.gif" would be: + + + + /CollX + x.gif + + + /CollX + y.gif + + + 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 resource resides knows about all bindings on all servers to that @@ -660,21 +853,23 @@ to the resource and destroy the resource while A's binding still exists. The precondition DAV:cross-server-binding is defined below for cases where servers fail cross-server BIND requests because they cannot guarantee the integrity of cross-server bindings. By default, if there already is a binding for the specified segment in the collection, the new binding replaces the existing binding. This default binding replacement behavior can be overridden using the Overwrite header defined in Section 9.6 of [RFC2518]. - This method is unsafe and idempotent (see [RFC2616], section 9.1). + If a BIND request fails, the server state preceding the request MUST + be restored. 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:bind XML element. If the request succeeds, the server MUST return 201 (Created) when @@ -750,43 +945,44 @@ >> Response: HTTP/1.1 201 Created The server added a new binding to the collection, "http://www.example.com/CollY", associating "bar.html" with the resource identified by the URI "http://www.example.com/CollX/foo.html". Clients can now use the URI - "http://www.example.com/CollY/bar.html", to submit requests to that + "http://www.example.com/CollY/bar.html" to submit requests to that resource. 5. UNBIND Method The UNBIND method modifies the collection identified by the Request-URI, by removing the binding identified by the segment specified in the UNBIND body. Once a resource is unreachable by any URI mapping, the server MAY reclaim system resources associated with that resource. If UNBIND removes a binding to a resource, but there remain URI mappings to that resource, the server MUST NOT reclaim system resources associated with the resource. - This method is unsafe and idempotent (see [RFC2616], section 9.1). + If an UNBIND request fails, the server state preceding the request + MUST be restored. This method is unsafe and idempotent (see + [RFC2616], section 9.1). Marshalling: The request body MUST be a DAV:unbind XML element. - If the request succeeds, the server MUST return 200 (OK) when the binding was successfully deleted. If a response body for a successful request is included, it MUST be a DAV:unbind-response XML element. Note that this document does not define any elements for the UNBIND response body, but the DAV:unbind-response element is defined to ensure interoperability between future extensions that do define elements for the UNBIND response body. @@ -837,27 +1033,30 @@ 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 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. + The REBIND method removes a binding to a resource from a collection, + and adds a binding to that resource into the collection identified by + the Request-URI. The request body specifies the binding to be added + (segment) and the old binding to be removed (href). It is + effectively an atomic form of a MOVE request, and MUST be treated the + same way as MOVE for the purpose of determining access permissions. - This method is unsafe and idempotent (see [RFC2616], section 9.1). + If a REBIND request fails, the server state preceding the request + MUST be restored. 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. If the request succeeds, the server MUST return 201 (Created) when @@ -1204,21 +1403,23 @@ Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 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 +13. References + +13.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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 @@ -1227,20 +1428,28 @@ [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. +13.2 Informative References + + [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. + + Whitehead, "Versioning Extensions to WebDAV (Web + Distributed Authoring and Versioning)", RFC 3253, March + 2002. + Authors' Addresses Geoffrey Clemm IBM 20 Maguire Road Lexington, MA 02421 EMail: geoffrey.clemm@us.ibm.com Jason Crawford @@ -1303,214 +1513,338 @@ "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. +A.7 Since draft-ietf-webdav-bind-08 + + Resolved editorial issues raised by Jim Whitehead in + . Add and resolve issues "atomicity", "2_allow_destroy", + "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", + "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", + "2.6_resource-id_vs_versions", "3.2_example" and + "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open + and resolve "6_rebind_intro". + 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 rfc2396bis +B.1 2_allow_destroy + + Type: change + + + + ejw@cs.ucsc.edu (2004-11-29): The language here would preclude the + future definition of a DESTROY method which had the semantics of + removing the state of a resource from a server, irregardless of any + containment relationships that may hold it. Such a method could be + quite useful for records management functionality, in order to + implement a records disposition policy that specified deletion at a + certain time. My recommended tweak to the language of section 2 is + minor: add the following sentence to the end of the paragraph: "It is + permissible, however, for future method definitions (e.g., a DESTROY + method) to have semantics that remove all bindings and/or immediately + reclaim system resources." + + Resolution (2004-11-30): Agreed to add statement about methods that + explicitly have that semantics. + +B.2 2.1_separate_loop_discussion Type: edit - julian.reschke@greenbytes.de (2004-10-21): Update references to - RFC2396 with draft-fielding-uri-rfc2396bis-07. + - Resolution (2004-11-06): Done. + ejw@cs.ucsc.edu (2004-11-29): I think it would be more clear to + separate out the discussion of loops and bindings, and make it a + separate section (say, 2.2) This issue comes up frequently enough + that it would be good to make it easy to find this issue in the TOC. + Also, a mention of the Already Reported status code would be good to + have here, since it also mentions 506. -B.2 bind_vs_ACL + Resolution (2004-11-30): Agreed to move 1st paragraph into separate + subsection. - Type: change +B.3 2.1.1_bind_loops_vs_locks - - 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. + ejw@cs.ucsc.edu (2004-12-03): ...The other is the semantics of the + lock operation in the presence of loopback bindings. I think the + handling of If headers is relatively straightforward. The semantics + of locking are not.... - 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 + Resolution (2004-12-09): After some discussion, the working group + agreed that we don't want to define special semantics for + depth:infinity locks, thus the standard lock sematics apply (see + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0271.htm l). -B.3 bind_properties +B.4 2.3_copy_depth_infinity 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 + ejw@cs.ucsc.edu (2004-11-29): This section doesn't clearly address + the semantics of COPY with Depth infinity. My recommendation is to + add, after paragraph 3, text like this: "As specified in [RFC2518], a + COPY with Depth infinity causes the collection resource to be + duplicated, all of its bound children to be duplicated, and their + children's bound children, and so on, to the bottom of the + containment hierarchy. All of the segments of the bindings of the + destination collection are the same as for the destination + collection. However, the destination resource for all bindings in + the destination collection are different from those of the source + collection, since all resources have been duplicated, creating new + resources with distinct DAV:resource-id properties." + + Resolution (2004-12-02): Example added. + +B.5 2.3_copy_vs_loops + + Type: change + + + + ejw@cs.ucsc.edu (2004-11-29): There should also be some text + addressing COPY depth infinity and loops -- in some instances during + a COPY with Depth infinity, the server really wants to recreate the + binding that causes the loop, rather than continuing to make + duplicate resources. This is somewhat addressed by the final + paragraph in Section 2.3, but not exactly. + + Resolution (2004-12-02): Can be closed after copy/depth:infinity + example was added (see + http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0181.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 +B.6 2.3_copy_example - 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. + Type: change -B.4 2.3_copy_to_same + + + ejw@cs.ucsc.edu (2004-11-29): It might make sense to create an + example covering the situation described in the final paragraph of + Section 2.3. I'm not 100% sure I know what scenario this paragraph + addresses, other reading the spec. for the first time would + presumably have a tougher time. + + Resolution (2004-12-02): Example added. + +B.7 2.6_resource-id_vs_versions 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." + ejw@cs.ucsc.edu (2004-11-29): There needs to be some discussion on + the interactions of DAV:resource-id and versioning. As near as I can + tell, the intent is that every revision will have a unique + DAV:resource-id value. - 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-12-01): Mention in an example. -B.5 6_rebind_intro +B.8 3.2_example + + Type: change + + + + ejw@cs.ucsc.edu (2004-11-29): I think it would be helpful to have an + example of this property. I'd be happy to help develop such an + example. + + Resolution (2004-11-30): Example added, including diagram. + +B.9 atomicity + + Type: change + + + + ejw@cs.ucsc.edu (2004-11-29): The intent of the BIND method is for + its behavior to be atomic. However, this is never actually stated + explicitly in the specification. Seems like it should be. + + Resolution (2004-11-30): Agreed. Steal text from RFC3253 (applies to + all method definitions). + +B.10 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. + Resolution (2004-12-02): Agreed and fixed (fixed again after it was + broken in -08). + +B.11 6_rebind_premissions + + Type: edit + + + + ejw@cs.ucsc.edu (2004-12-03): I agree with Lisa that the access + control implications of REBIND should be made explicit. My + suggestion is to add the following language to Section 6. Change: + "It is effectively an atomic form of a MOVE request." To: "It is + effectively an atomic form of a MOVE request, and MUST be treated as + a MOVE for the purpose of determining access permissions (see RFC + 3744, Appendix B)." + Resolution (2004-12-03): Make that statement, but avoid the + unnecessary normative reference to RFC3744. 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. +C.2 2.6_when_do_ids_change + + Type: change + + + + ejw@cs.ucsc.edu (2004-11-29): Change "must not" to "MUST NOT" (and + eliminate the "For example" at the start of the sentence -- perhaps + change to "Specifically," + + julian.reschke@greenbytes.de (2004-11-30): Fix language, replace MOVE + by REBIND (because MOVE may be implemented as COPY/DELETE). Unclear + whether we need more changes. + Index 2 - 208 Already Reported (status code) 23 + 208 Already Reported (status code) 27 5 - 506 Loop Detected (status code) 25 + 506 Loop Detected (status code) 29 B - BIND method 16 + BIND method 19 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) 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 + DAV:bind-into-collection (pre) 20 + DAV:bind-source-exists (pre) 20 + DAV:binding-allowed (pre) 20 + DAV:binding-deleted (post) 23, 26 + DAV:can-overwrite (pre) 21, 25 + DAV:cross-server-binding (pre) 21, 25 + DAV:cycle-allowed (pre) 21, 25 + DAV:lock-deleted (post) 23, 26 + DAV:locked-overwrite-allowed (pre) 21 + DAV:locked-source-collection-update-allowed (pre) 25 + DAV:locked-update-allowed (pre) 21, 23, 25 + DAV:name-allowed (pre) 21, 25 + DAV:new-binding (post) 21, 26 + DAV:protected-source-url-deletion-allowed (pre) 26 + DAV:protected-url-deletion-allowed (pre) 23 + DAV:protected-url-modification-allowed (pre) 25 + DAV:rebind-from-collection (pre) 25 + DAV:rebind-source-exists (pre) 25 + DAV:unbind-from-collection (pre) 23 + DAV:unbind-source-exists (pre) 23 D DAV header - compliance class 'bind' 26 - DAV:bind-into-collection precondition 17 - DAV:bind-source-exists precondition 17 - 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 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 + compliance class 'bind' 30 + DAV:bind-into-collection precondition 20 + DAV:bind-source-exists precondition 20 + DAV:binding-allowed precondition 20 + DAV:binding-deleted postcondition 23, 26 + DAV:can-overwrite precondition 21, 25 + DAV:cross-server-binding precondition 21, 25 + DAV:cycle-allowed precondition 21, 25 + DAV:lock-deleted postcondition 23, 26 + DAV:locked-overwrite-allowed precondition 21 + DAV:locked-source-collection-update-allowed precondition 25 + DAV:locked-update-allowed precondition 21, 23, 25 + DAV:name-allowed precondition 21, 25 + DAV:new-binding postcondition 21, 26 + DAV:parent-set property 18 + DAV:protected-source-url-deletion-allowed precondition 26 + DAV:protected-url-deletion-allowed precondition 23 + DAV:protected-url-modification-allowed precondition 25 + DAV:rebind-from-collection precondition 25 + DAV:rebind-source-exists precondition 25 + DAV:resource-id property 17 + DAV:unbind-from-collection precondition 23 + DAV:unbind-source-exists precondition 23 I Internal Member URI 7 M Methods - BIND 16 - REBIND 20 - UNBIND 18 + BIND 19 + REBIND 24 + UNBIND 22 P Path Segment 7 Properties - DAV:parent-set 15 - DAV:resource-id 15 + DAV:parent-set 18 + DAV:resource-id 17 R - REBIND method 20 + REBIND method 24 S Status Codes - 208 Already Reported 23 - 506 Loop Detected 25 + 208 Already Reported 27 + 506 Loop Detected 29 U - UNBIND method 18 + UNBIND method 22 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