idnits 2.17.1 draft-ietf-webdav-bind-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 627 has weird spacing: '...| x.gif y.g...' == Line 649 has weird spacing: '...| x.gif y.g...' == Line 920 has weird spacing: '...| x.gif y.g...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2009) is 5245 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Clemm 3 Internet-Draft IBM 4 Intended status: Experimental J. Crawford 5 Expires: June 18, 2010 IBM Research 6 J. Reschke, Ed. 7 greenbytes 8 J. Whitehead 9 U.C. Santa Cruz 10 December 15, 2009 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-27 15 Abstract 17 This specification defines bindings, and the BIND method for creating 18 multiple bindings to the same resource. Creating a new binding to a 19 resource causes at least one new URI to be mapped to that resource. 20 Servers are required to ensure the integrity of any bindings that 21 they allow to be created. 23 Editorial Note (To be removed by RFC Editor before publication) 25 Please send comments to the Distributed Authoring and Versioning 26 (WebDAV) working group at , which may be 27 joined by sending a message with subject "subscribe" to 28 . Discussions of the WEBDAV 29 working group are archived at 30 . 32 lists 33 all registered issues since draft 02. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on June 18, 2010. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 88 1.2. Method Preconditions and Postconditions . . . . . . . . . 8 89 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8 90 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8 91 2.1.1. Bind Loops . . . . . . . . . . . . . . . . . . . . . . 9 92 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 10 93 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10 94 2.3.1. Example: COPY with 'Depth: infinity' in Presence 95 of Bind Loops . . . . . . . . . . . . . . . . . . . . 12 96 2.3.2. Example: COPY updating multiple Bindings . . . . . . . 14 97 2.3.3. Example: COPY with 'Depth: infinity' with Multiple 98 Bindings to a Leaf Resource . . . . . . . . . . . . . 15 99 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 16 100 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 16 101 2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 17 102 2.5.2. Example: MOVE Request causing a Bind Loop . . . . . . 17 103 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 19 104 2.7. Determining Whether Two Bindings Are to the Same 105 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 20 107 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 20 109 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 21 110 3.2.1. Example for DAV:parent-set Property . . . . . . . . . 21 111 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 22 112 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 25 113 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 25 114 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 27 115 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 27 116 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 29 117 6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 30 118 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 32 119 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 32 120 7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 33 121 7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 35 122 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 35 123 8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 35 124 8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 35 125 8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 35 126 9. Relationship to Locking in WebDAV . . . . . . . . . . . . . . 36 127 9.1. Example: Locking and Multiple Bindings . . . . . . . . . . 37 128 10. Relationship to WebDAV Access Control Protocol . . . . . . . . 38 129 11. Relationship to Versioning Extensions to WebDAV . . . . . . . 38 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 41 131 12.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 41 132 12.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 41 133 12.3. Bindings, and Denial of Service . . . . . . . . . . . . . 41 134 12.4. Private Locations May Be Revealed . . . . . . . . . . . . 41 135 12.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 42 136 13. Internationalization Considerations . . . . . . . . . . . . . 42 137 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 138 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 139 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 140 16.1. Normative References . . . . . . . . . . . . . . . . . . . 42 141 16.2. Informative References . . . . . . . . . . . . . . . . . . 43 142 Appendix A. Change Log (to be removed by RFC Editor before 143 publication) . . . . . . . . . . . . . . . . . . . . 43 144 A.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 43 145 A.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 43 146 A.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 44 147 A.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 44 148 A.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 44 149 A.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 44 150 A.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 44 151 A.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 44 152 A.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 44 153 A.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 45 154 A.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 45 155 A.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 45 156 A.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 45 157 A.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 46 158 A.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 46 159 A.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 46 160 A.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 46 161 A.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 46 162 A.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 46 163 A.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 46 164 A.21. Since draft-ietf-webdav-bind-22 . . . . . . . . . . . . . 47 165 A.22. Since draft-ietf-webdav-bind-23 . . . . . . . . . . . . . 47 166 A.23. Since draft-ietf-webdav-bind-24 . . . . . . . . . . . . . 47 167 A.24. Since draft-ietf-webdav-bind-25 . . . . . . . . . . . . . 47 168 A.25. Since draft-ietf-webdav-bind-26 . . . . . . . . . . . . . 47 169 Appendix B. Resolved issues (to be removed by RFC Editor 170 before publication) . . . . . . . . . . . . . . . . . 47 171 B.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 172 B.2. bind-vs-hierarchy . . . . . . . . . . . . . . . . . . . . 47 173 B.3. copying-complex-loops . . . . . . . . . . . . . . . . . . 48 174 B.4. locking2 . . . . . . . . . . . . . . . . . . . . . . . . . 49 175 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 178 1. Introduction 180 This specification extends the WebDAV Distributed Authoring Protocol 181 ([RFC4918]) to enable clients to create new access paths to existing 182 resources. This capability is useful for several reasons: 184 URIs of WebDAV-compliant resources are hierarchical and correspond to 185 a hierarchy of collections in resource space. The WebDAV Distributed 186 Authoring Protocol makes it possible to organize these resources into 187 hierarchies, placing them into groupings, known as collections, which 188 are more easily browsed and manipulated than a single flat 189 collection. However, hierarchies require categorization decisions 190 that locate resources at a single location in the hierarchy, a 191 drawback when a resource has multiple valid categories. For example, 192 in a hierarchy of vehicle descriptions containing collections for 193 cars and boats, a description of a combination car/boat vehicle could 194 belong in either collection. Ideally, the description should be 195 accessible from both. Allowing clients to create new URIs that 196 access the existing resource lets them put that resource into 197 multiple collections. 199 Hierarchies also make resource sharing more difficult, since 200 resources that have utility across many collections are still forced 201 into a single collection. For example, the mathematics department at 202 one university might create a collection of information on fractals 203 that contains bindings to some local resources, but also provides 204 access to some resources at other universities. For many reasons, it 205 may be undesirable to make physical copies of the shared resources on 206 the local server: to conserve disk space, to respect copyright 207 constraints, or to make any changes in the shared resources visible 208 automatically. Being able to create new access paths to existing 209 resources in other collections or even on other servers is useful for 210 this sort of case. 212 The BIND method defined here provides a mechanism for allowing 213 clients to create alternative access paths to existing WebDAV 214 resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to 215 work because there are mappings between URIs and resources. A method 216 is addressed to a URI, and the server follows the mapping from that 217 URI to a resource, applying the method to that resource. Multiple 218 URIs may be mapped to the same resource, but until now there has been 219 no way for clients to create additional URIs mapped to existing 220 resources. 222 BIND lets clients associate a new URI with an existing WebDAV 223 resource, and this URI can then be used to submit requests to the 224 resource. Since URIs of WebDAV resources are hierarchical, and 225 correspond to a hierarchy of collections in resource space, the BIND 226 method also has the effect of adding the resource to a collection. 227 As new URIs are associated with the resource, it appears in 228 additional collections. 230 A BIND request does not create a new resource, but simply makes 231 available a new URI for submitting requests to an existing resource. 232 The new URI is indistinguishable from any other URI when submitting a 233 request to a resource. Only one round trip is needed to submit a 234 request to the intended target. Servers are required to enforce the 235 integrity of the relationships between the new URIs and the resources 236 associated with them. Consequently, it may be very costly for 237 servers to support BIND requests that cross server boundaries. 239 This specification is organized as follows. Section 1.1 defines 240 terminology used in the rest of the specification, while Section 2 241 overviews bindings. Section 3 defines the new properties needed to 242 support multiple bindings to the same resource. Section 4 specifies 243 the BIND method, used to create multiple bindings to the same 244 resource. Section 5 specifies the UNBIND method, used to remove a 245 binding to a resource. Section 6 specifies the REBIND method, used 246 to move a binding to another collection. 248 1.1. Terminology 250 The terminology used here follows and extends that in the WebDAV 251 Distributed Authoring Protocol specification [RFC4918]. 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 255 document are to be interpreted as described in [RFC2119]. 257 This document uses XML DTD fragments ([XML]) as a notational 258 convention, using the rules defined in Section 17 of [RFC4918]. 260 URI Mapping 262 A relation between an absolute URI and a resource. For an 263 absolute URI U and the resource it identifies R, the URI mapping 264 can be thought of as (U => R). Since a resource can represent 265 items that are not network retrievable, as well as those that are, 266 it is possible for a resource to have zero, one, or many URI 267 mappings. Mapping a resource to an "http" scheme URI makes it 268 possible to submit HTTP protocol requests to the resource using 269 the URI. 271 Path Segment 273 Informally, the characters found between slashes ("/") in a URI. 274 Formally, as defined in Section 3.3 of [RFC3986]. 276 Binding 278 A relation between a single path segment (in a collection) and a 279 resource. A binding is part of the state of a collection. If two 280 different collections contain a binding between the same path 281 segment and the same resource, these are two distinct bindings. 282 So for a collection C, a path segment S, and a resource R, the 283 binding can be thought of as C:(S -> R). Bindings create URI 284 mappings, and hence allow requests to be sent to a single resource 285 from multiple locations in a URI namespace. For example, given a 286 collection C (accessible through the URI 287 http://www.example.com/CollX), a path segment S (equal to 288 "foo.html"), and a resource R, then creating the binding C: (S -> 289 R) makes it possible to use the URI 290 http://www.example.com/CollX/foo.html to access R. 292 Collection 294 A resource that contains, as part of its state, a set of bindings 295 that identify internal member resources. 297 Internal Member URI 299 The URI that identifies an internal member of a collection, and 300 that consists of the URI for the collection, followed by a slash 301 character ('/'), followed by the path segment of the binding for 302 that internal member. 304 Binding Integrity 306 The property of a binding that says that: 308 * the binding continues to exist, and 310 * the identity of the resource identified by that binding does 311 not change, 313 unless an explicit request is executed that is defined to delete 314 that binding (examples of requests that delete a binding are 315 DELETE, MOVE, and - defined later on - UNBIND, and REBIND). 317 1.2. Method Preconditions and Postconditions 319 See Section 16 of [RFC4918] for the definitions of "precondition" and 320 "postcondition". 322 2. Overview of Bindings 324 Bindings are part of the state of a collection. They define the 325 internal members of the collection, and the names of those internal 326 members. 328 Bindings are added and removed by a variety of existing HTTP methods. 329 A method that creates a new resource, such as PUT, COPY, and MKCOL, 330 adds a binding. A method that deletes a resource, such as DELETE, 331 removes a binding. A method that moves a resource (e.g. MOVE) both 332 adds a binding (in the destination collection) and removes a binding 333 (in the source collection). The BIND method introduced here provides 334 a mechanism for adding a second binding to an existing resource. 335 There is no difference between an initial binding added by PUT, COPY, 336 or MKCOL, and additional bindings added with BIND. 338 It would be very undesirable if one binding could be destroyed as a 339 side effect of operating on the resource through a different binding. 340 In particular, the removal of one binding to a resource (e.g. with a 341 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 342 e.g. by turning that binding into a dangling path segment. The 343 server MUST NOT reclaim system resources after removing one binding, 344 while other bindings to the resource remain. In other words, the 345 server MUST maintain the integrity of a binding. It is permissible, 346 however, for future method definitions (e.g., a DESTROY method) to 347 have semantics that explicitly remove all bindings and/or immediately 348 reclaim system resources. 350 Note: the collection model described herein is not compatible with 351 systems in which resources inherit properties based solely on the 352 access path, as the ability to create additional bindings will 353 cause a single resource to appear as member of several different 354 collections at the same time. 356 2.1. Bindings to Collections 358 Creating a new binding to a collection makes each resource associated 359 with a binding in that collection accessible via a new URI, and thus 360 creates new URI mappings to those resources but no new bindings. 362 For example, suppose a new binding CollY is created for collection C1 363 in the figure below. It immediately becomes possible to access 364 resource R1 using the URI /CollY/x.gif and to access resource R2 365 using the URI /CollY/y.jpg, but no new bindings for these child 366 resources were created. This is because bindings are part of the 367 state of a collection, and associate a URI that is relative to that 368 collection with its target resource. No change to the bindings in 369 Collection C1 is needed to make its children accessible using /CollY/ 370 x.gif and /CollY/y.jpg. 372 +-------------------------+ 373 | Root Collection | 374 | bindings: | 375 | CollX CollY | 376 +-------------------------+ 377 | / 378 | / 379 | / 380 +------------------+ 381 | Collection C1 | 382 | bindings: | 383 | x.gif y.jpg | 384 +------------------+ 385 | \ 386 | \ 387 | \ 388 +-------------+ +-------------+ 389 | Resource R1 | | Resource R2 | 390 +-------------+ +-------------+ 392 2.1.1. Bind Loops 394 Bindings to collections can result in loops ("cycles"), which servers 395 MUST detect when processing "Depth: infinity" requests. It is 396 sometimes possible to complete an operation in spite of the presence 397 of a loop. For instance, a PROPFIND can still succeed if the server 398 uses the new status code 208 (Already Reported) defined in 399 Section 7.1. 401 However, the 506 (Loop Detected) status code is defined in 402 Section 7.2 for use in contexts where an operation is terminated 403 because a loop was encountered. 405 Support for loops is OPTIONAL: servers MAY reject requests that would 406 lead to the creation of a bind loop (see DAV:cycle-allowed 407 precondition defined in Section 4). 409 2.2. URI Mappings Created by a new Binding 411 Suppose a binding from "Binding-Name" to resource R is to be added to 412 a collection, C. Then if C-MAP is the set of URIs that were mapped to 413 C before the BIND request, then for each URI "C-URI" in C-MAP, the 414 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 415 request. 417 For example, if a binding from "foo.html" to R is added to a 418 collection C, and if the following URIs are mapped to C: 420 http://www.example.com/A/1/ 421 http://example.com/A/one/ 423 then the following new mappings to R are introduced: 425 http://www.example.com/A/1/foo.html 426 http://example.com/A/one/foo.html 428 Note that if R is a collection, additional URI mappings are created 429 to the descendents of R. Also, note that if a binding is made in 430 collection C to C itself (or to a parent of C), an infinite number of 431 mappings are introduced. 433 For example, if a binding from "myself" to C is then added to C, the 434 following infinite number of additional mappings to C are introduced: 436 http://www.example.com/A/1/myself 437 http://www.example.com/A/1/myself/myself 438 ... 440 and the following infinite number of additional mappings to R are 441 introduced: 443 http://www.example.com/A/1/myself/foo.html 444 http://www.example.com/A/1/myself/myself/foo.html 445 ... 447 2.3. COPY and Bindings 449 As defined in Section 9.8 of [RFC4918], COPY causes the resource 450 identified by the Request-URI to be duplicated, and makes the new 451 resource accessible using the URI specified in the Destination 452 header. Upon successful completion of a COPY, a new binding is 453 created between the last path segment of the Destination header, and 454 the destination resource. The new binding is added to its parent 455 collection, identified by the Destination header minus its final 456 segment. 458 The following figure shows an example: Suppose that a COPY is issued 459 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 460 with the Destination header set to URI-X. After successful 461 completion of the COPY operation, resource R is duplicated to create 462 resource R', and a new binding has been created which creates at 463 least the URI mapping between URI-X and the new resource (although 464 other URI mappings may also have been created). 466 URI-1 URI-2 URI-3 URI-X 467 | | | | 468 | | | <---- URI Mappings ----> | 469 | | | | 470 +---------------------+ +------------------------+ 471 | Resource R | | Resource R' | 472 +---------------------+ +------------------------+ 474 It might be thought that a COPY request with "Depth: 0" on a 475 collection would duplicate its bindings, since bindings are part of 476 the collection's state. This is not the case, however. The 477 definition of Depth in [RFC4918] makes it clear that a "Depth: 0" 478 request does not apply to a collection's members. Consequently, a 479 COPY with "Depth: 0" does not duplicate the bindings contained by the 480 collection. 482 If a COPY request causes an existing resource to be updated, the 483 bindings to that resource MUST be unaffected by the COPY request. 484 Using the preceding example, suppose that a COPY request is issued to 485 URI-X for resource R', with the Destination header set to URI-2. The 486 content and dead properties of resource R would be updated to be a 487 copy of those of resource R', but the mappings from URI-1, URI-2, and 488 URI-3 to resource R remain unaffected. If because of multiple 489 bindings to a resource, more than one source resource updates a 490 single destination resource, the order of the updates is server 491 defined (see Section 2.3.2 for an example). 493 If a COPY request would cause a new resource to be created as a copy 494 of an existing resource, and that COPY request has already created a 495 copy of that existing resource, the COPY request instead creates 496 another binding to the previous copy, instead of creating a new 497 resource (see Section 2.3.3 for an example). 499 2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops 501 As an example of how COPY with Depth infinity would work in the 502 presence of bindings, consider the following collection: 504 +------------------+ 505 | Root Collection | 506 | bindings: | 507 | CollX | 508 +------------------+ 509 | 510 | 511 +-------------------------------+ 512 | Collection C1 |<-------+ 513 | bindings: | | 514 | x.gif CollY | | 515 +-------------------------------+ | 516 | \ (creates loop) | 517 | \ | 518 +-------------+ +------------------+ | 519 | Resource R1 | | Collection C2 | | 520 +-------------+ | bindings: | | 521 | y.gif CollZ | | 522 +------------------+ | 523 | | | 524 | +--------+ 525 | 526 +-------------+ 527 | Resource R2 | 528 +-------------+ 530 If a COPY with Depth infinity is submitted to /CollX, with 531 destination of /CollA, the outcome of the copy operation is that a 532 copy of the tree is replicated to the target /CollA: 534 +------------------+ 535 | Root Collection | 536 | bindings: | 537 | CollX CollA | 538 +------------------+ 539 | | 540 | +---------------------------+ 541 | | 542 +-------------------+ | 543 | Collection C1 |<------------------+ | 544 | bindings: | | | 545 | x.gif CollY | | | 546 +-------------------+ | | 547 | \ (creates loop) | | 548 | \ | | 549 +-------------+ +-----------------+ | | 550 | Resource R1 | | Collection C2 | | | 551 +-------------+ | bindings: | | | 552 | y.gif CollZ | | | 553 +-----------------+ | | 554 | | | | 555 | +-------+ | 556 | | 557 +-------------+ | 558 | Resource R2 | | 559 +-------------+ | 560 | 561 +-------------------------------+ 562 | 563 +-------------------+ 564 | Collection C3 |<------------------+ 565 | bindings: | | 566 | x.gif CollY | | 567 +-------------------+ | 568 | \ (creates loop) | 569 | \ | 570 +-------------+ +-----------------+ | 571 | Resource R3 | | Collection C4 | | 572 +-------------+ | bindings: | | 573 | y.gif CollZ | | 574 +-----------------+ | 575 | | | 576 | +-------+ 577 | 578 +-------------+ 579 | Resource R4 | 580 +-------------+ 582 Note that the same would apply for more complex loops. 584 2.3.2. Example: COPY updating multiple Bindings 586 Given the following collection hierarchy: 588 +------------------+ 589 | Root Collection | 590 | bindings: | 591 | CollX CollY | 592 +------------------+ 593 / \ 594 / \ 595 / \ 596 +--------------------------+ +-----------------+ 597 | Collection C1 | | Collection C2 | 598 | bindings: | | bindings: | 599 | x.gif y.gif | | x.gif y.gif | 600 +--------------------------+ +-----------------+ 601 | | | | 602 | | | | 603 +-------------+ +-------------+ +-------------+ 604 | Resource R1 | | Resource R2 | | Resource R3 | 605 +-------------+ +-------------+ +-------------+ 607 A COPY of /CollX with Depth infinity to /CollY will not result in a 608 changed hierarchy, and Resource R3 will be updated with the content 609 of either Resource R1 or Resource R2. 611 2.3.3. Example: COPY with 'Depth: infinity' with Multiple Bindings to a 612 Leaf Resource 614 Given the following collection hierarchy: 616 +------------------+ 617 | Root Collection | 618 | bindings: | 619 | CollX | 620 +------------------+ 621 | 622 | 623 | 624 +----------------+ 625 | Collection C1 | 626 | bindings: | 627 | x.gif y.gif | 628 +----------------+ 629 | | 630 | | 631 +-------------+ 632 | Resource R1 | 633 +-------------+ 635 A COPY of /CollX with Depth infinity to /CollY results in the 636 following collection hierarchy: 638 +------------------+ 639 | Root Collection | 640 | bindings: | 641 | CollX CollY | 642 +------------------+ 643 | \ 644 | \ 645 | \ 646 +----------------+ +-----------------+ 647 | Collection C1 | | Collection C2 | 648 | bindings: | | bindings: | 649 | x.gif y.gif | | x.gif y.gif | 650 +----------------+ +-----------------+ 651 | | | | 652 | | | | 653 +-------------+ +-------------+ 654 | Resource R1 | | Resource R2 | 655 +-------------+ +-------------+ 657 2.4. DELETE and Bindings 659 When there are multiple bindings to a resource, a DELETE applied to 660 that resource MUST NOT remove any bindings to that resource other 661 than the one identified by the Request-URI. For example, suppose the 662 collection identified by the URI "/a" has a binding named "x" to a 663 resource R, and another collection identified by "/b" has a binding 664 named "y" to the same resource R. Then a DELETE applied to "/a/x" 665 removes the binding named "x" from "/a" but MUST NOT remove the 666 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 667 to identify the resource R). 669 When DELETE is applied to a collection, it MUST NOT modify the 670 membership of any other collection that is not itself a member of the 671 collection being deleted. For example, if both "/a/.../x" and 672 "/b/.../y" identify the same collection, C, then applying DELETE to 673 "/a" must not delete an internal member from C or from any other 674 collection that is a member of C, because that would modify the 675 membership of "/b". 677 If a collection supports the UNBIND method (see Section 5), a DELETE 678 of an internal member of a collection MAY be implemented as an UNBIND 679 request. In this case, applying DELETE to a Request-URI has the 680 effect of removing the binding identified by the final segment of the 681 Request-URI from the collection identified by the Request-URI minus 682 its final segment. Although [RFC4918] allows a DELETE to be a non- 683 atomic operation, when the DELETE operation is implemented as an 684 UNBIND, the operation is atomic. In particular, a DELETE on a 685 hierarchy of resources is simply the removal of a binding to the 686 collection identified by the Request-URI. 688 2.5. MOVE and Bindings 690 When MOVE is applied to a resource, the other bindings to that 691 resource MUST be unaffected, and if the resource being moved is a 692 collection, the bindings to any members of that collection MUST be 693 unaffected. Also, if MOVE is used with Overwrite:T to delete an 694 existing resource, the constraints specified for DELETE apply. 696 If the destination collection of a MOVE request supports the REBIND 697 method (see Section 6), a MOVE of a resource into that collection MAY 698 be implemented as a REBIND request. Although [RFC4918] allows a MOVE 699 to be a non-atomic operation, when the MOVE operation is implemented 700 as a REBIND, the operation is atomic. In particular, applying a MOVE 701 to a Request-URI and a Destination URI has the effect of removing a 702 binding to a resource (at the Request-URI), and creating a new 703 binding to that resource (at the Destination URI). Even when the 704 Request-URI identifies a collection, the MOVE operation involves only 705 removing one binding to that collection and adding another. 707 2.5.1. Example: Simple MOVE 709 As an example, suppose that a MOVE is issued to URI-3 for resource R 710 below (which is also mapped to URI-1 and URI-2), with the Destination 711 header set to URI-X. After successful completion of the MOVE 712 operation, a new binding has been created which creates the URI 713 mapping between URI-X and resource R. The binding corresponding to 714 the final segment of URI-3 has been removed, which also causes the 715 URI mapping between URI-3 and R to be removed. If resource R were a 716 collection, old URI-3 based mappings to members of R would have been 717 removed, and new URI-X based mappings to members of R would have been 718 created. 720 >> Before Request: 722 URI-1 URI-2 URI-3 723 | | | 724 | | | <---- URI Mappings 725 | | | 726 +---------------------+ 727 | Resource R | 728 +---------------------+ 730 >> After Request: 732 URI-1 URI-2 URI-X 733 | | | 734 | | | <---- URI Mappings 735 | | | 736 +---------------------+ 737 | Resource R | 738 +---------------------+ 740 2.5.2. Example: MOVE Request causing a Bind Loop 742 Note that in the presence of collection bindings, a MOVE request can 743 cause the creating of a bind loop. 745 Consider a the top level collections C1 and C2 with URIs "/CollW/" 746 and "/CollX/". C1 also contains an additional binding named "CollY" 747 to C2: 749 +------------------+ 750 | Root Collection | 751 | bindings: | 752 | CollW CollX | 753 +------------------+ 754 | | 755 | | 756 +------------------+ | 757 | Collection C1 | | 758 | bindings: | | 759 | CollY | | 760 +------------------+ | 761 | | 762 | | 763 +------------------+ 764 | Collection C2 | 765 | | 766 | | 767 +------------------+ 769 In this case, the MOVE request below would cause a bind loop: 771 >> Request: 773 MOVE /CollW HTTP/1.1 774 Host: example.com 775 Destination: /CollX/CollZ 776 If the request succeeded, the resulting state would be: 778 +------------------+ 779 | Root Collection | 780 | bindings: | 781 | CollX | 782 +------------------+ 783 | 784 | 785 +------------------+ | 786 | Collection C1 | | 787 +----> | bindings: | | 788 | | CollY | | 789 | +------------------+ | 790 | | | 791 | | | 792 | +------------------+ 793 | | Collection C2 | 794 | | bindings: | 795 | | CollZ | 796 | +------------------+ 797 | | 798 | | 799 +-------------------+ 801 2.6. PROPFIND and Bindings 803 Consistent with [RFC4918], the value of a dead property MUST be 804 independent of the number of bindings to its host resource or of the 805 path submitted to PROPFIND. On the other hand, the behavior for each 806 live property depends on its individual definition (for example, see 807 [RFC3744], Section 5, paragraph 2 for a case where the value is 808 independent of path and bindings, and [RFC4918], Section 8.8 for a 809 discussion about the live properties DAV:getetag and DAV: 810 getlastmodified, which may behave differently). 812 2.7. Determining Whether Two Bindings Are to the Same Resource 814 It is useful to have some way of determining whether two bindings are 815 to the same resource. Two resources might have identical contents 816 and properties, but not be the same resource (e.g. an update to one 817 resource does not affect the other resource). 819 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 820 resource identifier, which MUST be unique across all resources for 821 all time. If the values of DAV:resource-id returned by PROPFIND 822 requests through two bindings are identical character by character, 823 the client can be assured that the two bindings are to the same 824 resource. 826 The DAV:resource-id property is created, and its value assigned, when 827 the resource is created. The value of DAV:resource-id MUST NOT be 828 changed. Even after the resource is no longer accessible through any 829 URI, that value MUST NOT be reassigned to another resource's DAV: 830 resource-id property. 832 Any method that creates a new resource MUST assign a new, unique 833 value to its DAV:resource-id property. For example, a PUT applied to 834 a null resource, COPY (when not overwriting an existing target) and 835 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 836 to the DAV:resource-id property of the new resource they create. 838 On the other hand, any method that affects an existing resource must 839 not change the value of its DAV:resource-id property. Specifically, 840 a PUT or a COPY that updates an existing resource must not change the 841 value of its DAV:resource-id property. A REBIND, since it does not 842 create a new resource, but only changes the location of an existing 843 resource, must not change the value of the DAV:resource-id property. 845 2.8. Discovering the Bindings to a Resource 847 An OPTIONAL DAV:parent-set property on a resource provides a list of 848 the bindings that associate a collection and a URI segment with that 849 resource. If the DAV:parent-set property exists on a given resource, 850 it MUST contain a complete list of all bindings to that resource that 851 the client is authorized to see. When deciding whether to support 852 the DAV:parent-set property, server implementers / administrators 853 should balance the benefits it provides against the cost of 854 maintaining the property and the security risks enumerated in 855 Sections 12.4 and 12.5. 857 3. Properties 859 The bind feature introduces the properties defined below. 861 A DAV:allprop PROPFIND request SHOULD NOT return any of the 862 properties defined by this document. This allows a binding server to 863 perform efficiently when a naive client, which does not understand 864 the cost of asking a server to compute all possible live properties, 865 issues a DAV:allprop PROPFIND request. 867 3.1. DAV:resource-id Property 869 The DAV:resource-id property is a REQUIRED property that enables 870 clients to determine whether two bindings are to the same resource. 872 The value of DAV:resource-id is a URI, and may use any registered URI 873 scheme that guarantees the uniqueness of the value across all 874 resources for all time (e.g. the urn:uuid: URN namespace defined in 875 [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]). 877 879 3.2. DAV:parent-set Property 881 The DAV:parent-set property is an OPTIONAL property that enables 882 clients to discover what collections contain a binding to this 883 resource (i.e. what collections have that resource as an internal 884 member). It contains an href/segment pair for each collection that 885 has a binding to the resource. The href identifies the collection, 886 and the segment identifies the binding name of that resource in that 887 collection. 889 A given collection MUST appear only once in the DAV:parent-set for 890 any given binding, even if there are multiple URI mappings to that 891 collection. 893 894 895 896 899 3.2.1. Example for DAV:parent-set Property 901 For example, if collection C1 is mapped to both /CollX and /CollY, 902 and C1 contains a binding named "x.gif" to a resource R1, then either 903 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 904 of R1, but not both. But if C1 also had a binding named "y.gif" to 905 R1, then there would be two entries for C1 in the DAV:parent-set of 906 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 907 both [/CollY, x.gif] and [/CollY, y.gif]). 909 +-------------------------+ 910 | Root Collection | 911 | bindings: | 912 | CollX CollY | 913 +-------------------------+ 914 | / 915 | / 916 | / 917 +-----------------+ 918 | Collection C1 | 919 | bindings: | 920 | x.gif y.gif | 921 +-----------------+ 922 | | 923 | | 924 | | 925 +-------------+ 926 | Resource R1 | 927 +-------------+ 929 In this case, one possible value for DAV:parent-set property on 930 "/CollX/x.gif" would be: 932 933 934 /CollX 935 x.gif 936 937 938 /CollX 939 y.gif 940 941 943 4. BIND Method 945 The BIND method modifies the collection identified by the Request- 946 URI, by adding a new binding from the segment specified in the BIND 947 body to the resource identified in the BIND body. 949 If a server cannot guarantee the integrity of the binding, the BIND 950 request MUST fail. Note that it is especially difficult to maintain 951 the integrity of cross-server bindings. Unless the server where the 952 resource resides knows about all bindings on all servers to that 953 resource, it may unwittingly destroy the resource or make it 954 inaccessible without notifying another server that manages a binding 955 to the resource. For example, if server A permits creation of a 956 binding to a resource on server B, server A must notify server B 957 about its binding and must have an agreement with B that B will not 958 destroy the resource while A's binding exists. Otherwise server B 959 may receive a DELETE request that it thinks removes the last binding 960 to the resource and destroy the resource while A's binding still 961 exists. The precondition DAV:cross-server-binding is defined below 962 for cases where servers fail cross-server BIND requests because they 963 cannot guarantee the integrity of cross-server bindings. 965 By default, if there already is a binding for the specified segment 966 in the collection, the new binding replaces the existing binding. 967 This default binding replacement behavior can be overridden using the 968 Overwrite header defined in Section 10.6 of [RFC4918]. 970 If a BIND request fails, the server state preceding the request MUST 971 be restored. This method is unsafe and idempotent (see [RFC2616], 972 Section 9.1). 974 Marshalling: 976 The request MAY include an Overwrite header. 978 The request body MUST be a DAV:bind XML element. 980 982 If the request succeeds, the server MUST return 201 (Created) when 983 a new binding was created and 200 (OK) or 204 (No Content) when an 984 existing binding was replaced. 986 If a response body for a successful request is included, it MUST 987 be a DAV:bind-response XML element. Note that this document does 988 not define any elements for the BIND response body, but the DAV: 989 bind-response element is defined to ensure interoperability 990 between future extensions that do define elements for the BIND 991 response body. 993 995 Preconditions: 997 (DAV:bind-into-collection): The Request-URI MUST identify a 998 collection. 1000 (DAV:bind-source-exists): The DAV:href element MUST identify a 1001 resource. 1003 (DAV:binding-allowed): The resource identified by the DAV:href 1004 supports multiple bindings to it. 1006 (DAV:cross-server-binding): If the resource identified by the DAV: 1007 href element in the request body is on another server from the 1008 collection identified by the Request-URI, the server MUST support 1009 cross-server bindings (servers that do not support cross-server 1010 bindings can use this condition code to signal the client exactly 1011 why the request failed). 1013 (DAV:name-allowed): The name specified by the DAV:segment is 1014 available for use as a new binding name. 1016 (DAV:can-overwrite): If the collection already contains a binding 1017 with the specified path segment, and if an Overwrite header is 1018 included, the value of the Overwrite header MUST be "T". 1020 (DAV:cycle-allowed): If the DAV:href element identifies a 1021 collection, and if the Request-URI identifies a collection that is 1022 a member of that collection, the server MUST support cycles in the 1023 URI namespace (servers that do not support cycles can use this 1024 condition code to signal the client exactly why the request 1025 failed). 1027 (DAV:locked-update-allowed): If the collection identified by the 1028 Request-URI is write-locked, then the appropriate token MUST be 1029 specified in an If request header. 1031 (DAV:locked-overwrite-allowed): If the collection already contains 1032 a binding with the specified path segment, and if that binding is 1033 protected by a write-lock, then the appropriate token MUST be 1034 specified in an If request header. 1036 Postconditions: 1038 (DAV:new-binding): The collection MUST have a binding that maps 1039 the segment specified in the DAV:segment element in the request 1040 body, to the resource identified by the DAV:href element in the 1041 request body. 1043 4.1. Example: BIND 1045 >> Request: 1047 BIND /CollY HTTP/1.1 1048 Host: www.example.com 1049 Content-Type: application/xml; charset="utf-8" 1050 Content-Length: 172 1052 1053 1054 bar.html 1055 http://www.example.com/CollX/foo.html 1056 1058 >> Response: 1060 HTTP/1.1 201 Created 1061 Location: http://www.example.com/CollY/bar.html 1063 The server added a new binding to the collection, 1064 "http://www.example.com/CollY", associating "bar.html" with the 1065 resource identified by the URI 1066 "http://www.example.com/CollX/foo.html". Clients can now use the URI 1067 "http://www.example.com/CollY/bar.html" to submit requests to that 1068 resource. 1070 5. UNBIND Method 1072 The UNBIND method modifies the collection identified by the Request- 1073 URI, by removing the binding identified by the segment specified in 1074 the UNBIND body. 1076 Once a resource is unreachable by any URI mapping, the server MAY 1077 reclaim system resources associated with that resource. If UNBIND 1078 removes a binding to a resource, but there remain URI mappings to 1079 that resource, the server MUST NOT reclaim system resources 1080 associated with the resource. 1082 If an UNBIND request fails, the server state preceding the request 1083 MUST be restored. This method is unsafe and idempotent (see 1084 [RFC2616], Section 9.1). 1086 Marshalling: 1088 The request body MUST be a DAV:unbind XML element. 1090 1092 If the request succeeds, the server MUST return 200 (OK) or 204 1093 (No Content) when the binding was successfully deleted. 1095 If a response body for a successful request is included, it MUST 1096 be a DAV:unbind-response XML element. Note that this document 1097 does not define any elements for the UNBIND response body, but the 1098 DAV:unbind-response element is defined to ensure interoperability 1099 between future extensions that do define elements for the UNBIND 1100 response body. 1102 1104 Preconditions: 1106 (DAV:unbind-from-collection): The Request-URI MUST identify a 1107 collection. 1109 (DAV:unbind-source-exists): The DAV:segment element MUST identify 1110 a binding in the collection identified by the Request-URI. 1112 (DAV:locked-update-allowed): If the collection identified by the 1113 Request-URI is write-locked, then the appropriate token MUST be 1114 specified in the request. 1116 (DAV:protected-url-deletion-allowed): If the binding identified by 1117 the segment is protected by a write-lock, then the appropriate 1118 token MUST be specified in the request. 1120 Postconditions: 1122 (DAV:binding-deleted): The collection MUST NOT have a binding for 1123 the segment specified in the DAV:segment element in the request 1124 body. 1126 (DAV:lock-deleted): If the internal member URI of the binding 1127 specified by the Request-URI and the DAV:segment element in the 1128 request body was protected by a write-lock at the time of the 1129 request, that write-lock must have been deleted by the request. 1131 5.1. Example: UNBIND 1133 >> Request: 1135 UNBIND /CollX HTTP/1.1 1136 Host: www.example.com 1137 Content-Type: application/xml; charset="utf-8" 1138 Content-Length: 117 1140 1141 1142 foo.html 1143 1145 >> Response: 1147 HTTP/1.1 200 OK 1149 The server removed the binding named "foo.html" from the collection, 1150 "http://www.example.com/CollX". A request to the resource named 1151 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1152 response. 1154 6. REBIND Method 1156 The REBIND method removes a binding to a resource from a collection, 1157 and adds a binding to that resource into the collection identified by 1158 the Request-URI. The request body specifies the binding to be added 1159 (segment) and the old binding to be removed (href). It is 1160 effectively an atomic form of a MOVE request, and MUST be treated the 1161 same way as MOVE for the purpose of determining access permissions. 1163 If a REBIND request fails, the server state preceding the request 1164 MUST be restored. This method is unsafe and idempotent (see 1165 [RFC2616], Section 9.1). 1167 Marshalling: 1169 The request MAY include an Overwrite header. 1171 The request body MUST be a DAV:rebind XML element. 1173 1175 If the request succeeds, the server MUST return 201 (Created) when 1176 a new binding was created and 200 (OK) or 204 (No Content) when an 1177 existing binding was replaced. 1179 If a response body for a successful request is included, it MUST 1180 be a DAV:rebind-response XML element. Note that this document 1181 does not define any elements for the REBIND response body, but the 1182 DAV:rebind-response element is defined to ensure interoperability 1183 between future extensions that do define elements for the REBIND 1184 response body. 1186 1188 Preconditions: 1190 (DAV:rebind-into-collection): The Request-URI MUST identify a 1191 collection. 1193 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1194 resource. 1196 (DAV:cross-server-binding): If the resource identified by the DAV: 1197 href element in the request body is on another server from the 1198 collection identified by the Request-URI, the server MUST support 1199 cross-server bindings (servers that do not support cross-server 1200 bindings can use this condition code to signal the client exactly 1201 why the request failed). 1203 (DAV:name-allowed): The name specified by the DAV:segment is 1204 available for use as a new binding name. 1206 (DAV:can-overwrite): If the collection already contains a binding 1207 with the specified path segment, and if an Overwrite header is 1208 included, the value of the Overwrite header MUST be "T". 1210 (DAV:cycle-allowed): If the DAV:href element identifies a 1211 collection, and if the Request-URI identifies a collection that is 1212 a member of that collection, the server MUST support cycles in the 1213 URI namespace (servers that do not support cycles can use this 1214 condition code to signal the client exactly why the request 1215 failed). 1217 (DAV:locked-update-allowed): If the collection identified by the 1218 Request-URI is write-locked, then the appropriate token MUST be 1219 specified in the request. 1221 (DAV:protected-url-modification-allowed): If the collection 1222 identified by the Request-URI already contains a binding with the 1223 specified path segment, and if that binding is protected by a 1224 write-lock, then the appropriate token MUST be specified in the 1225 request. 1227 (DAV:locked-source-collection-update-allowed): If the collection 1228 identified by the parent collection prefix of the DAV:href URI is 1229 write-locked, then the appropriate token MUST be specified in the 1230 request. 1232 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1233 is protected by a write lock, then the appropriate token MUST be 1234 specified in the request. 1236 Postconditions: 1238 (DAV:new-binding): The collection MUST have a binding that maps 1239 the segment specified in the DAV:segment element in the request 1240 body, to the resource that was identified by the DAV:href element 1241 in the request body. 1243 (DAV:binding-deleted): The URL specified in the DAV:href element 1244 in the request body MUST NOT be mapped to a resource. 1246 (DAV:lock-deleted): If the URL specified in the DAV:href element 1247 in the request body was protected by a write-lock at the time of 1248 the request, that write-lock must have been deleted by the 1249 request. 1251 6.1. Example: REBIND 1253 >> Request: 1255 REBIND /CollX HTTP/1.1 1256 Host: www.example.com 1257 Content-Type: application/xml; charset="utf-8" 1258 Content-Length: 176 1260 1261 1262 foo.html 1263 http://www.example.com/CollY/bar.html 1264 1266 >> Response: 1268 HTTP/1.1 200 OK 1270 The server added a new binding to the collection, 1271 "http://www.example.com/CollX", associating "foo.html" with the 1272 resource identified by the URI 1273 "http://www.example.com/CollY/bar.html", and removes the binding 1274 named "bar.html" from the collection identified by the URI 1275 "http://www.example.com/CollY". Clients can now use the URI 1276 "http://www.example.com/CollX/foo.html" to submit requests to that 1277 resource, and requests on the URI 1278 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1279 Found) response. 1281 6.2. Example: REBIND in Presence of Locks and Bind Loops 1283 To illustrate the effects of locks and bind loops on a REBIND 1284 operation, consider the following collection: 1286 +------------------+ 1287 | Root Collection | 1288 | bindings: | 1289 | CollW | 1290 +------------------+ 1291 | 1292 | 1293 | 1294 +-------------------------------+ 1295 | Collection C1 |<--------+ 1296 | LOCKED infinity | | 1297 | (lock token L1) | | 1298 | bindings: | | 1299 | CollX CollY | | 1300 +-------------------------------+ | 1301 | | | 1302 | | (creates loop) | 1303 | | | 1304 +-----------------+ +------------------+ | 1305 | Collection C2 | | Collection C3 | | 1306 | (inherit lock) | | (inherit lock) | | 1307 | (lock token L1) | | (lock token L1) | | 1308 | bindings: | | bindings: | | 1309 | {none} | | y.gif CollZ | | 1310 +-----------------+ +------------------+ | 1311 | | | 1312 | +-----+ 1313 | 1314 +---------------------------+ 1315 | Resource R2 | 1316 | (lock inherited from C1) | 1317 | (lock token L1) | 1318 +---------------------------+ 1320 (where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1322 Note that the binding between CollZ and C1 creates a loop in the 1323 containment hierarchy. Servers are not required to support such 1324 loops, though the server in this example does. 1326 The REBIND request below will remove the segment "CollZ" from C3 and 1327 add a new binding from "CollA" to the collection C2. 1329 REBIND /CollW/CollX HTTP/1.1 1330 Host: www.example.com 1331 If: () 1332 Content-Type: application/xml; charset="utf-8" 1333 Content-Length: 152 1335 1336 1337 CollA 1338 /CollW/CollY/CollZ 1339 1340 The outcome of the REBIND operation is: 1342 +------------------+ 1343 | Root Collection | 1344 | bindings: | 1345 | CollW | 1346 +------------------+ 1347 | 1348 | 1349 | 1350 +-------------------------------+ 1351 | Collection C1 | 1352 | LOCKED infinity | 1353 | (lock token L1) | 1354 | bindings: | 1355 | CollX CollY | 1356 +-------------------------------+ 1357 | ^ | 1358 | | | 1359 +-----------------+ | +------------------+ 1360 | Collection C2 | | | Collection C3 | 1361 |(inherited lock) | | | (inherited lock) | 1362 |(lock token L1) | | | (lock token L1) | 1363 | bindings: | | | bindings: | 1364 | CollA | | | y.gif | 1365 +-----------------+ | +------------------+ 1366 | | | 1367 +---------------+ | 1368 (creates loop) | 1369 +---------------------------+ 1370 | Resource R2 | 1371 | (inherited lock from C1) | 1372 | (lock token L1) | 1373 +---------------------------+ 1375 7. Additional Status Codes 1377 7.1. 208 Already Reported 1379 The 208 (Already Reported) status code can be used inside a DAV: 1380 propstat response element to avoid enumerating the internal members 1381 of multiple bindings to the same collection repeatedly. For each 1382 binding to a collection inside the request's scope, only one will be 1383 reported with a 200 status, while subsequent DAV:response elements 1384 for all other bindings will use the 208 status, and no DAV:response 1385 elements for their descendants are included. 1387 Note that the 208 status will only occur for "Depth: infinity" 1388 requests, and that it is of particular importance when the multiple 1389 collection bindings cause a bind loop as discussed in Section 2.2. 1391 A client can request the DAV:resource-id property in a PROPFIND 1392 request to guarantee that they can accurately reconstruct the binding 1393 structure of a collection with multiple bindings to a single 1394 resource. 1396 For backward compatibility with clients not aware of the 208 status 1397 code appearing in multistatus response bodies, it SHOULD NOT be used 1398 unless the client has signalled support for this specification using 1399 the "DAV" request header (see Section 8.2). Instead, a 506 status 1400 should be returned when a binding loop is discovered. This allows 1401 the server to return the 506 as the top level return status, if it 1402 discovers it before it started the response, or in the middle of a 1403 multistatus, if it discovers it in the middle of streaming out a 1404 multistatus response. 1406 7.1.1. Example: PROPFIND by Bind-Aware Client 1408 For example, consider a PROPFIND request on /Coll (bound to 1409 collection C), where the members of /Coll are /Coll/Foo (bound to 1410 resource R) and /Coll/Bar (bound to collection C). 1412 >> Request: 1414 PROPFIND /Coll/ HTTP/1.1 1415 Host: www.example.com 1416 Depth: infinity 1417 DAV: bind 1418 Content-Type: application/xml; charset="utf-8" 1419 Content-Length: 152 1421 1422 1423 1424 1425 1426 1427 1429 >> Response: 1431 HTTP/1.1 207 Multi-Status 1432 Content-Type: application/xml; charset="utf-8" 1433 Content-Length: 1241 1435 1436 1437 1438 http://www.example.com/Coll/ 1439 1440 1441 Loop Demo 1442 1443 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1445 1446 1447 HTTP/1.1 200 OK 1448 1449 1450 1451 http://www.example.com/Coll/Foo 1452 1453 1454 Bird Inventory 1455 1456 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1458 1459 1460 HTTP/1.1 200 OK 1461 1462 1463 1464 http://www.example.com/Coll/Bar 1465 1466 1467 Loop Demo 1468 1469 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1471 1472 1473 HTTP/1.1 208 Already Reported 1474 1475 1476 1478 7.1.2. Example: PROPFIND by Non-Bind-Aware Client 1480 In this example, the client isn't aware of the 208 status code 1481 introduced by this specification. As the "Depth: infinity" PROPFIND 1482 request would cause a loop condition, the whole request is rejected 1483 with a 506 status. 1485 >> Request: 1487 PROPFIND /Coll/ HTTP/1.1 1488 Host: www.example.com 1489 Depth: infinity 1490 Content-Type: application/xml; charset="utf-8" 1491 Content-Length: 125 1493 1494 1495 1496 1498 >> Response: 1500 HTTP/1.1 506 Loop Detected 1502 7.2. 506 Loop Detected 1504 The 506 (Loop Detected) status code indicates that the server 1505 terminated an operation because it encountered an infinite loop while 1506 processing a request with "Depth: infinity". This status indicates 1507 that the entire operation failed. 1509 8. Capability Discovery 1511 8.1. OPTIONS Method 1513 If the server supports bindings, it MUST return the compliance class 1514 name "bind" as a field in the "DAV" response header (see [RFC4918], 1515 Section 10.1) from an OPTIONS request on any resource implemented by 1516 that server. A value of "bind" in the "DAV" header MUST indicate 1517 that the server supports all MUST level requirements and REQUIRED 1518 features specified in this document. 1520 8.2. 'DAV' Request Header 1522 Clients SHOULD signal support for all MUST level requirements and 1523 REQUIRED features by submitting a "DAV" request header containing the 1524 compliance class name "bind". In particular, the client MUST 1525 understand the 208 status code defined in Section 7.1. 1527 9. Relationship to Locking in WebDAV 1529 Locking is an optional feature of WebDAV ([RFC4918]). The base 1530 WebDAV specification and this protocol extension have been designed 1531 in parallel, making sure that all features of WebDAV can be 1532 implemented on a server that implements this protocol as well. 1534 Unfortunately, WebDAV uses the term "lock-root" inconsistently. It 1535 is introduced in Section 6.1 of [RFC4918], point 2, as: 1537 2. A resource becomes directly locked when a LOCK request to a 1538 URL of that resource creates a new lock. The "lock-root" of the 1539 new lock is that URL. If at the time of the request, the URL is 1540 not mapped to a resource, a new empty resource is created and 1541 directly locked. 1543 On the other hand, [RFC4918], Section 9.10.1 states: 1545 A LOCK request to an existing resource will create a lock on the 1546 resource identified by the Request-URI, provided the resource is 1547 not already locked with a conflicting lock. The resource 1548 identified in the Request-URI becomes the root of the lock. 1550 Servers that implement both WebDAV locking and support for multiple 1551 bindings MUST use the first interpretation: the lock-root is the URI 1552 through which the lock was created, not a resource. This URI, and 1553 potential aliases of this URI ([RFC4918], Section 5), are said to be 1554 "protected" by the lock. 1556 As defined in the introduction to Section 7 of [RFC4918], write 1557 operations that modify the state of a locked resource require that 1558 the lock token is submitted with the request. Consistent with 1559 WebDAV, the state of the resource consists of the content ("any 1560 variant"), dead properties, lockable live properties (item 1), plus, 1561 for a collection, all its bindings (item 2). Note that this, by 1562 definition, does not depend on the request URI to which the write 1563 operation is applied (the locked state is a property of the resource, 1564 not its URI). 1566 However, the lock root is the URI through which the lock was 1567 requested. Thus, the protection defined in item 3 of the list does 1568 not apply to additional URIs that may be mapped to the same resource 1569 due to the existence of multiple bindings. 1571 9.1. Example: Locking and Multiple Bindings 1573 Consider a root collection "/", containing the two collections C1 and 1574 C2, named "/CollX" and "/CollY", and a child resource R, bound to C1 1575 as "/CollX/test" and bound to C2 as "/CollY/test": 1577 +-------------------------+ 1578 | Root Collection | 1579 | bindings: | 1580 | CollX CollY | 1581 +-------------------------+ 1582 | | 1583 | | 1584 | | 1585 +---------------+ +---------------+ 1586 | Collection C1 | | Collection C2 | 1587 | bindings: | | bindings: | 1588 | test | | test | 1589 +---------------+ +---------------+ 1590 | | 1591 | | 1592 | | 1593 +------------------+ 1594 | Resource R | 1595 +------------------+ 1597 Given a host name of "www.example.com", applying a depth-zero write 1598 lock to "/CollX/test" will lock the resource R, and the lock-root of 1599 this lock will be "http://www.example.com/CollX/test". 1601 Thus the following operations will require that the associated lock 1602 token is submitted with the "If" request header ([RFC4918], Section 1603 10.4): 1605 o a PUT or PROPPATCH request modifying the content or lockable 1606 properties of resource R (as R is locked) -- no matter which URI 1607 is used as request target, 1609 o a MOVE, REBIND, UNBIND or DELETE request causing "/CollX/test" not 1610 being mapped to resource R anymore (be it addressed to "/CollX" or 1611 "/CollX/test"). 1613 The following operations will not require submission of the lock 1614 token: 1616 o a DELETE request addressed to "/CollY" or /CollY/test", as it does 1617 not affect the resource R, nor the lock-root, 1619 o for the same reason, an UNBIND request removing the binding "test" 1620 from collection C2, or the binding "CollY" from the root 1621 collection, 1623 o similarly, a MOVE or REBIND request causing "/CollY/test" not 1624 being mapped to resource R anymore. 1626 Note that despite the lock root being 1627 "http://www.example.com/CollX/test", an UNLOCK request can be 1628 addressed through any URI mapped to resource R, as UNLOCK operates on 1629 the resource identified by the request URI, not that URI (see 1630 [RFC4918], Section 9.11). 1632 10. Relationship to WebDAV Access Control Protocol 1634 Note that the WebDAV Access Control Protocol has been designed for 1635 compatibility with systems that allow multiple URIs to map to the 1636 same resource (see [RFC3744], Section 5): 1638 ...Access control properties (especially DAV:acl and DAV: 1639 inherited-acl-set) are defined on the resource identified by the 1640 Request-URI of a PROPFIND request. A direct consequence is that 1641 if the resource is accessible via multiple URI, the value of 1642 access control properties is the same across these URI. ... 1644 Furthermore, note that BIND and REBIND behave the same as MOVE with 1645 respect to the DAV:acl property (see [RFC3744], Section 7.3). 1647 11. Relationship to Versioning Extensions to WebDAV 1649 Servers that implement Workspaces ([RFC3253], Section 6) and Version 1650 Controlled Collections ([RFC3253], Section 14) already need to 1651 implement BIND-like behavior in order to handle UPDATE and UNCHECKOUT 1652 semantics. 1654 Consider a workspace "/ws1/", containing the version-controlled, 1655 checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ 1656 CollY", and a version-controlled resource R, bound to C1 as "/ws1/ 1657 CollX/test": 1659 +-------------------------+ 1660 | Workspace | 1661 | bindings: | 1662 | CollX CollY | 1663 +-------------------------+ 1664 | | 1665 | | 1666 | | 1667 +---------------+ +---------------+ 1668 | Collection C1 | | Collection C2 | 1669 | bindings: | | | 1670 | test | | | 1671 +---------------+ +---------------+ 1672 | 1673 | 1674 | 1675 +------------------+ 1676 | Resource R | 1677 +------------------+ 1679 Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but 1680 undoing the checkout on C1 will undo part of the MOVE request, thus 1681 restoring the binding from C1 to R, but keeping the new binding from 1682 C2 to R: 1684 >> Request: 1686 MOVE /ws1/CollX/test HTTP/1.1 1687 Host: www.example.com 1688 Destination: /ws1/CollY/test 1690 >> Response: 1692 HTTP/1.1 204 No Content 1694 >> Request: 1696 CHECKIN /ws1/CollY/ HTTP/1.1 1697 Host: www.example.com 1699 >> Response: 1701 HTTP/1.1 201 Created 1702 Cache-Control: no-cache 1703 Location: http://repo.example.com/his/17/ver/42 1704 >> Request: 1706 UNCHECKOUT /ws1/CollX/ HTTP/1.1 1707 Host: www.example.com 1709 >> Response: 1711 HTTP/1.1 200 OK 1712 Cache-Control: no-cache 1714 As a result, both C1 and C2 would have a binding to R: 1716 +-------------------------+ 1717 | Workspace | 1718 | bindings: | 1719 | CollX CollY | 1720 +-------------------------+ 1721 | | 1722 | | 1723 | | 1724 +---------------+ +---------------+ 1725 | Collection C1 | | Collection C2 | 1726 | bindings: | | bindings: | 1727 | test | | test | 1728 +---------------+ +---------------+ 1729 | | 1730 | | 1731 | | 1732 +------------------+ 1733 | Resource R | 1734 +------------------+ 1736 The MOVE semantics defined in Section 3.15 of [RFC3253] already 1737 require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the 1738 same version history (as exposed in the DAV:version-history 1739 property). Furthermore, the UNCHECKOUT semantics (which in this case 1740 is similar to UPDATE, see Section 14.11 of [RFC3253]) require: 1742 ...If a new version-controlled member is in a workspace that 1743 already has a version-controlled resource for that version 1744 history, then the new version-controlled member MUST be just a 1745 binding (i.e., another name for) that existing version-controlled 1746 resource... 1748 Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the 1749 same resource R, and have identical DAV:resource-id properties. 1751 12. Security Considerations 1753 This section is provided to make WebDAV implementors aware of the 1754 security implications of this protocol. 1756 All of the security considerations of HTTP/1.1 ([RFC2616], Section 1757 15) and the WebDAV Distributed Authoring Protocol specification 1758 ([RFC4918], Section 20) also apply to this protocol specification. 1759 In addition, bindings introduce several new security concerns and 1760 increase the risk of some existing threats. These issues are 1761 detailed below. 1763 12.1. Privacy Concerns 1765 In a context where cross-server bindings are supported, creating 1766 bindings on a trusted server may make it possible for a hostile agent 1767 to induce users to send private information to a target on a 1768 different server. 1770 12.2. Bind Loops 1772 Although bind loops were already possible in HTTP 1.1, the 1773 introduction of the BIND method creates a new avenue for clients to 1774 create loops accidentally or maliciously. If the binding and its 1775 target are on the same server, the server may be able to detect BIND 1776 requests that would create loops. Servers are required to detect 1777 loops that are caused by bindings to collections during the 1778 processing of any requests with "Depth: infinity". 1780 12.3. Bindings, and Denial of Service 1782 Denial of service attacks were already possible by posting URIs that 1783 were intended for limited use at heavily used Web sites. The 1784 introduction of BIND creates a new avenue for similar denial of 1785 service attacks. If cross-server bindings are supported, clients can 1786 now create bindings at heavily used sites to target locations that 1787 were not designed for heavy usage. 1789 12.4. Private Locations May Be Revealed 1791 If the DAV:parent-set property is maintained on a resource, the 1792 owners of the bindings risk revealing private locations. The 1793 directory structures where bindings are located are available to 1794 anyone who has access to the DAV:parent-set property on the resource. 1795 Moving a binding may reveal its new location to anyone with access to 1796 DAV:parent-set on its resource. 1798 12.5. DAV:parent-set and Denial of Service 1800 If the server maintains the DAV:parent-set property in response to 1801 bindings created in other administrative domains, it is exposed to 1802 hostile attempts to make it devote resources to adding bindings to 1803 the list. 1805 13. Internationalization Considerations 1807 All internationalization considerations mentioned in Section 19 of 1808 [RFC4918] also apply to this document. 1810 14. IANA Considerations 1812 Section 7 defines the HTTP status codes 208 (Already Reported) and 1813 506 (Loop Detected), to be added to the registry at 1814 . 1816 15. Acknowledgements 1818 This document is the collaborative product of the authors and Tyson 1819 Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited 1820 from thoughtful discussion by Jim Amsden, Peter Carlson, Steve 1821 Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus 1822 Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David 1823 Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, 1824 Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, 1825 Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1826 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Alexey 1827 Melnikov, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley 1828 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin 1829 Wiggen, and other members of the concluded WebDAV working group. 1831 16. References 1833 16.1. Normative References 1835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1836 Requirement Levels", BCP 14, RFC 2119, March 1997. 1838 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1839 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1840 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1842 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1843 Resource Identifier (URI): Generic Syntax", STD 66, 1844 RFC 3986, January 2005. 1846 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1847 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1849 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1850 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1851 Edition)", W3C REC-xml-20081126, November 2008, 1852 . 1854 16.2. Informative References 1856 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1857 Whitehead, "Versioning Extensions to WebDAV (Web 1858 Distributed Authoring and Versioning)", RFC 3253, 1859 March 2002. 1861 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1862 Distributed Authoring and Versioning (WebDAV) Access 1863 Control Protocol", RFC 3744, May 2004. 1865 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1866 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1867 July 2005. 1869 Appendix A. Change Log (to be removed by RFC Editor before publication) 1871 A.1. Since draft-ietf-webdav-bind-02 1873 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1874 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1875 resolution, but keep it open. Add issues "ED_references" and 1876 "4_507_status". Started work on index. Rename document to "Binding 1877 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1878 Rename "References" to "Normative References". Close issue 1879 "ED_references". Close issue "4_507_status". 1881 A.2. Since draft-ietf-webdav-bind-03 1883 Add and close issues "9.2_redirect_loops", "ED_authors" and 1884 "ED_updates". Add section about capability discovery (DAV header). 1885 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1886 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1887 "locking" and resolve as invalid. 1889 A.3. Since draft-ietf-webdav-bind-04 1891 Add and close issues "6_precondition_binding_allowed" and 1892 "6_lock_behaviour". Add mailing list and issues list pointers to 1893 front. 1895 A.4. Since draft-ietf-webdav-bind-05 1897 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1898 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1899 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1901 A.5. Since draft-ietf-webdav-bind-06 1903 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1904 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1906 A.6. Since draft-ietf-webdav-bind-07 1908 Add more index items (no change tracking). Add and resolve issues 1909 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1910 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1911 DTD fragment in section 3.3. Make spelling of "Request-URI" 1912 consistent. 1914 A.7. Since draft-ietf-webdav-bind-08 1916 Resolved editorial issues raised by Jim Whitehead in . 1918 Add and resolve issues "atomicity", "2_allow_destroy", 1919 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1920 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1921 "2.6_resource-id_vs_versions", "3.2_example" and 1922 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1923 and resolve "6_rebind_intro". 1925 A.8. Since draft-ietf-webdav-bind-09 1927 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1928 text. Add action item "3.1_uuids". Close issue 1929 "2.6_when_do_ids_change". Add and resolve issues 1930 "2.6_bindings_vs_properties" and "uri_draft_ref". 1932 A.9. Since draft-ietf-webdav-bind-10 1934 Resolve action item "3.1_uuids". Add and resolve issue 1935 "2.7_unlock_vs_bindings". Revisit issue 1936 "2.6_bindings_vs_properties", and remove the part of the sentence 1937 that speaks about live properties. Update "rfc2396bis" references to 1938 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1939 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1941 A.10. Since draft-ietf-webdav-bind-11 1943 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1944 live properties in Section 2.6. 1946 A.11. Since draft-ietf-webdav-bind-12 1948 Updated Author's address. Uppercase "Section" when referring to 1949 other documents. 1951 Updating from RFC2518 to RFC2518bis: 1953 o Remove own explanation of DTD syntax. 1955 o Remove own definition of precondition/postcondition. 1957 o Remove reference to broken RFC2518 language about DELETE and 1958 UNLOCK. 1960 o Remove own definition of DAV: request header. 1962 o Updated "Rationale for Distinguishing Bindings from URI Mappings" 1963 to reflect the changes in [draft-ietf-webdav-rfc2518bis], making 1964 proposals for more changes so that the issue can be closed (see 1965 also 1966 and ). 1969 A.12. Since draft-ietf-webdav-bind-13 1971 Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one 1972 incorrect section reference. Remove Section "Rationale for 1973 Distinguishing Bindings from URI Mappings" as 1974 [draft-ietf-webdav-rfc2518-bis] now uses the proper definition of 1975 collection state. Examples use application/xml instead of text/xml 1976 MIME type. 1978 Fix IANA section (there are no IANA considerations). 1980 A.13. Since draft-ietf-webdav-bind-14 1982 Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to 1983 4th edition. 1985 Markup ASCII art for box recognition (doesn't affect ASCII version). 1987 Identify Julian Reschke as Editor. 1989 A.14. Since draft-ietf-webdav-bind-15 1991 Fix typo in RFC2119 keywords section (sorry!). 1993 Update [draft-ietf-webdav-rfc2518-bis] to draft 17. 1995 Add and resolve issue "rfc2518bis-lock-root". 1997 A.15. Since draft-ietf-webdav-bind-16 1999 Add and resolve issue "iana-vs-http-status". 2001 A.16. Since draft-ietf-webdav-bind-17 2003 Update rfc2518bis reference to draft 18 (note that the bug reported 2004 in 2005 is still present). 2007 A.17. Since draft-ietf-webdav-bind-18 2009 Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918. 2011 A.18. Since draft-ietf-webdav-bind-19 2013 Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move- 2014 creating-cycles", "3.1-clarify-resource-id" and "4-precondition- 2015 language". 2017 A.19. Since draft-ietf-webdav-bind-20 2019 Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples. 2020 Replace RFC2518bis issue link by pointer to RFC Errata Page. 2022 Add issues "relation-to-deltav" and "status-codes". 2024 A.20. Since draft-ietf-webdav-bind-21 2026 Resolve issues "relation-to-deltav" and "status-codes". 2028 Add correct content length values to examples (no change bars). 2030 A.21. Since draft-ietf-webdav-bind-22 2032 Set "Intended Status" to "Experimental". 2034 Update XML reference to "Extensible Markup Language (XML) 1.0 (Fifth 2035 Edition)". 2037 A.22. Since draft-ietf-webdav-bind-23 2039 Remove surplus white space from one example. 2041 Fix typo: "DAV:binding-set" -> "DAV:parent-set". 2043 Add and resolve issues "clarify-alternate-uri", "def-integrity", "ex- 2044 copy-multiple-update", "ex-copy-graph", and "ex-live-property". 2046 A.23. Since draft-ietf-webdav-bind-24 2048 Add and resolve issues "clarify-clarify", "sec-cons-references", 2049 "should-not-update-4918", "should-update-2616", and "webdav-wg-gone". 2051 A.24. Since draft-ietf-webdav-bind-25 2053 Add and resolve issue "locking-example". 2055 A.25. Since draft-ietf-webdav-bind-26 2057 Add and resolve issues "bind-vs-hierarchy", "copying-complex-loops" 2058 and "locking2". 2060 Appendix B. Resolved issues (to be removed by RFC Editor before 2061 publication) 2063 Issues that were either rejected or resolved in this version of this 2064 document. 2066 B.1. edit 2068 Type: edit 2070 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 2071 editorial fixes/enhancements. 2073 B.2. bind-vs-hierarchy 2075 Type: edit 2076 julian.reschke@greenbytes.de (2009-11-29): Note that a system based 2077 on the BIND collection model will be inherently incompatible with a 2078 system that inherits information based on just the naming hierarchy, 2079 not taking multiple bindings into account. In particular, Access 2080 Control implementations based on path inheritance come to mind. 2081 (This is not a problem of the BIND data model itself, but a known 2082 issue when an attempt is made to build a hybrid system). 2084 Resolution (2009-12-12): Add a note to the overview, and also clarify 2085 the "Relation to WebDAV ACL" section. 2087 B.3. copying-complex-loops 2089 In Section 2: 2091 Type: edit 2093 rjsparks@nostrum.com (2009-06-03): 2095 The document provides some discussion of the ramifications of simple 2096 loops, but its not immediately obvious that the recommendations for 2097 handling them are sufficient for dealing with more complex loops. 2098 Are there additional issues introduced when each added level of depth 2099 adds an exponentially growing number of elements? 2100 (view in fixed width) 2101 +---------+ 2102 | root | 2103 | | 2104 | start | 2105 +---------+ 2106 | 2107 v 2108 +---------+ +---------+ 2109 +---->| C1 | | C2 |<---+ 2110 | +->| | | |<-+ | 2111 | | | a b | | a b | | | 2112 | | +---------+ +---------+ | | 2113 | | | | | | | | 2114 | | | | +----+ | | | 2115 | | | | | | | | 2116 | | | +----------c---+ | | | 2117 | | | | | | | | 2118 | | | +----------+ | | | | 2119 | | v v v v | | 2120 | | +---------+ +---------+ | | 2121 | | | C3 | | C4 | | | 2122 | | | | | | | | 2123 | | | a b | | a b | | | 2124 | | +---------+ +---------+ | | 2125 | | | | | | | | 2126 | +----+ | +----+ +-----+ | 2127 | | | | 2128 | +----------c-----------------+ 2129 | | 2130 +-----------------------+ 2132 Resolution (2009-11-29): The authors discussed this question and came 2133 to the conclusion that the considerations for complex loops are 2134 identical to those for simple loops; a COPY operation still 2135 duplicates the binding graph. A short note pointing this out was 2136 added to the end of the example. 2138 B.4. locking2 2140 Type: change 2142 julian.reschke@greenbytes.de (2009-11-29): We have failed to reach 2143 consensus about the RFC 4918 clarification. Thus we'll have to 2144 accept that it says what it says, and need to clarify how it applies 2145 to locking, essentially pointing out which behavior we expect. To do 2146 this, create a new section about locking, which will explain the 2147 "lock root" as required by a server that supports multiple bindings. 2149 Also keep the example. 2151 Resolution (2009-12-12): Added new section specifying the locking 2152 behavior, removed the appendix. 2154 Index 2156 2 2157 208 Already Reported (status code) 32, 42 2159 5 2160 506 Loop Detected (status code) 35, 42 2162 B 2163 BIND method 22 2164 Marshalling 23 2165 Postconditions 24 2166 Preconditions 23 2167 Binding 7 2168 Binding Integrity 7-8, 22 2170 C 2171 Collection 7 2172 Condition Names 2173 DAV:bind-into-collection (pre) 23 2174 DAV:bind-source-exists (pre) 23 2175 DAV:binding-allowed (pre) 24 2176 DAV:binding-deleted (post) 26, 29 2177 DAV:can-overwrite (pre) 24, 28 2178 DAV:cross-server-binding (pre) 24, 28 2179 DAV:cycle-allowed (pre) 24, 28 2180 DAV:lock-deleted (post) 26, 29 2181 DAV:locked-overwrite-allowed (pre) 24 2182 DAV:locked-source-collection-update-allowed (pre) 29 2183 DAV:locked-update-allowed (pre) 24, 26, 28 2184 DAV:name-allowed (pre) 24, 28 2185 DAV:new-binding (post) 24, 29 2186 DAV:protected-source-url-deletion-allowed (pre) 29 2187 DAV:protected-url-deletion-allowed (pre) 26 2188 DAV:protected-url-modification-allowed (pre) 28 2189 DAV:rebind-from-collection (pre) 28 2190 DAV:rebind-source-exists (pre) 28 2191 DAV:unbind-from-collection (pre) 26 2192 DAV:unbind-source-exists (pre) 26 2194 D 2195 DAV header 2196 compliance class 'bind' 35 2197 DAV:bind-into-collection precondition 23 2198 DAV:bind-source-exists precondition 23 2199 DAV:binding-allowed precondition 24 2200 DAV:binding-deleted postcondition 26, 29 2201 DAV:can-overwrite precondition 24, 28 2202 DAV:cross-server-binding precondition 24, 28 2203 DAV:cycle-allowed precondition 24, 28 2204 DAV:lock-deleted postcondition 26, 29 2205 DAV:locked-overwrite-allowed precondition 24 2206 DAV:locked-source-collection-update-allowed precondition 29 2207 DAV:locked-update-allowed precondition 24, 26, 28 2208 DAV:name-allowed precondition 24, 28 2209 DAV:new-binding postcondition 24, 29 2210 DAV:parent-set property 21 2211 DAV:protected-source-url-deletion-allowed precondition 29 2212 DAV:protected-url-deletion-allowed precondition 26 2213 DAV:protected-url-modification-allowed precondition 28 2214 DAV:rebind-from-collection precondition 28 2215 DAV:rebind-source-exists precondition 28 2216 DAV:resource-id property 20 2217 DAV:unbind-from-collection precondition 26 2218 DAV:unbind-source-exists precondition 26 2220 I 2221 Internal Member URI 7 2223 L 2224 Locking 36 2226 M 2227 Methods 2228 BIND 22 2229 REBIND 27 2230 UNBIND 25 2232 P 2233 Path Segment 6 2234 Properties 2235 DAV:parent-set 21 2236 DAV:resource-id 20 2238 R 2239 REBIND method 27 2240 Marshalling 27 2241 Postconditions 29 2242 Preconditions 28 2244 S 2245 Status Codes 2246 208 Already Reported 32, 42 2247 506 Loop Detected 35, 42 2249 U 2250 UNBIND method 25 2251 Marshalling 25 2252 Postconditions 26 2253 Preconditions 26 2254 URI Mapping 6 2256 Authors' Addresses 2258 Geoffrey Clemm 2259 IBM 2260 20 Maguire Road 2261 Lexington, MA 02421 2263 Email: geoffrey.clemm@us.ibm.com 2265 Jason Crawford 2266 IBM Research 2267 P.O. Box 704 2268 Yorktown Heights, NY 10598 2270 Email: ccjason@us.ibm.com 2272 Julian F. Reschke (editor) 2273 greenbytes GmbH 2274 Hafenweg 16 2275 Muenster, NW 48155 2276 Germany 2278 Email: julian.reschke@greenbytes.de 2280 Jim Whitehead 2281 UC Santa Cruz, Dept. of Computer Science 2282 1156 High Street 2283 Santa Cruz, CA 95064 2285 Email: ejw@cse.ucsc.edu