idnits 2.17.1 draft-ietf-webdav-bind-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4918, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 563 has weird spacing: '...| x.gif y.g...' == Line 585 has weird spacing: '...| x.gif y.g...' == Line 856 has weird spacing: '...| x.gif y.g...' (Using the creation date from RFC4918, updated by this document, for RFC5378 checks: 2002-02-20) -- 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 (February 25, 2009) is 5532 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 (==), 3 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 Updates: 4918 (if approved) J. Crawford 5 Intended status: Experimental IBM Research 6 Expires: August 29, 2009 J. Reschke, Ed. 7 greenbytes 8 J. Whitehead 9 U.C. Santa Cruz 10 February 25, 2009 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-23 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 29, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This specification defines bindings, and the BIND method for creating 61 multiple bindings to the same resource. Creating a new binding to a 62 resource causes at least one new URI to be mapped to that resource. 63 Servers are required to insure the integrity of any bindings that 64 they allow to be created. 66 Editorial Note (To be removed by RFC Editor before publication) 68 Please send comments to the Distributed Authoring and Versioning 69 (WebDAV) working group at , which may be 70 joined by sending a message with subject "subscribe" to 71 . Discussions of the WEBDAV 72 working group are archived at 73 . 75 lists 76 all registered issues since draft 02. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 82 1.2. Method Preconditions and Postconditions . . . . . . . . . 7 83 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 84 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8 85 2.1.1. Bind Loops . . . . . . . . . . . . . . . . . . . . . . 9 86 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 9 87 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10 88 2.3.1. Example: COPY with 'Depth: infinity' in Presence 89 of Bind Loops . . . . . . . . . . . . . . . . . . . . 12 90 2.3.2. Example: COPY with 'Depth: infinity' with Multiple 91 Bindings to a Leaf Resource . . . . . . . . . . . . . 14 92 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15 93 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15 94 2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 16 95 2.5.2. Example: MOVE Request causing a Bind Loop . . . . . . 16 96 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 18 97 2.7. Determining Whether Two Bindings Are to the Same 98 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 19 100 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 19 102 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 20 103 3.2.1. Example for DAV:parent-set Property . . . . . . . . . 20 104 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 24 106 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 107 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 26 108 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 26 109 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 28 110 6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 29 111 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31 112 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31 113 7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32 114 7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34 115 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34 116 8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34 117 8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34 118 8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34 119 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35 120 10. Relationship to Versioning Extensions to WebDAV . . . . . . . 35 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 122 11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 38 123 11.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 38 124 11.3. Bindings, and Denial of Service . . . . . . . . . . . . . 38 125 11.4. Private Locations May Be Revealed . . . . . . . . . . . . 38 126 11.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 38 127 12. Internationalization Considerations . . . . . . . . . . . . . 38 128 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 129 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 130 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 131 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 132 15.2. Informative References . . . . . . . . . . . . . . . . . . 40 133 Appendix A. Clarification to RFC2518bis' Usage of the term 134 'lock root' . . . . . . . . . . . . . . . . . . . . . 40 135 Appendix B. Change Log (to be removed by RFC Editor before 136 publication) . . . . . . . . . . . . . . . . . . . . 41 137 B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 41 138 B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 41 139 B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 41 140 B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 41 141 B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 41 142 B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 41 143 B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 42 144 B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 42 145 B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 42 146 B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 42 147 B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 42 148 B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 43 149 B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 43 150 B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 43 151 B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 43 152 B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 43 153 B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 44 154 B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 44 155 B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 44 156 B.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 44 157 B.21. Since draft-ietf-webdav-bind-22 . . . . . . . . . . . . . 44 158 Appendix C. Open issues (to be removed by RFC Editor prior to 159 publication) . . . . . . . . . . . . . . . . . . . . 44 160 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 161 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 164 1. Introduction 166 This specification extends the WebDAV Distributed Authoring Protocol 167 ([RFC4918]) to enable clients to create new access paths to existing 168 resources. This capability is useful for several reasons: 170 URIs of WebDAV-compliant resources are hierarchical and correspond to 171 a hierarchy of collections in resource space. The WebDAV Distributed 172 Authoring Protocol makes it possible to organize these resources into 173 hierarchies, placing them into groupings, known as collections, which 174 are more easily browsed and manipulated than a single flat 175 collection. However, hierarchies require categorization decisions 176 that locate resources at a single location in the hierarchy, a 177 drawback when a resource has multiple valid categories. For example, 178 in a hierarchy of vehicle descriptions containing collections for 179 cars and boats, a description of a combination car/boat vehicle could 180 belong in either collection. Ideally, the description should be 181 accessible from both. Allowing clients to create new URIs that 182 access the existing resource lets them put that resource into 183 multiple collections. 185 Hierarchies also make resource sharing more difficult, since 186 resources that have utility across many collections are still forced 187 into a single collection. For example, the mathematics department at 188 one university might create a collection of information on fractals 189 that contains bindings to some local resources, but also provides 190 access to some resources at other universities. For many reasons, it 191 may be undesirable to make physical copies of the shared resources on 192 the local server: to conserve disk space, to respect copyright 193 constraints, or to make any changes in the shared resources visible 194 automatically. Being able to create new access paths to existing 195 resources in other collections or even on other servers is useful for 196 this sort of case. 198 The BIND method defined here provides a mechanism for allowing 199 clients to create alternative access paths to existing WebDAV 200 resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to 201 work because there are mappings between URIs and resources. A method 202 is addressed to a URI, and the server follows the mapping from that 203 URI to a resource, applying the method to that resource. Multiple 204 URIs may be mapped to the same resource, but until now there has been 205 no way for clients to create additional URIs mapped to existing 206 resources. 208 BIND lets clients associate a new URI with an existing WebDAV 209 resource, and this URI can then be used to submit requests to the 210 resource. Since URIs of WebDAV resources are hierarchical, and 211 correspond to a hierarchy of collections in resource space, the BIND 212 method also has the effect of adding the resource to a collection. 213 As new URIs are associated with the resource, it appears in 214 additional collections. 216 A BIND request does not create a new resource, but simply makes 217 available a new URI for submitting requests to an existing resource. 218 The new URI is indistinguishable from any other URI when submitting a 219 request to a resource. Only one round trip is needed to submit a 220 request to the intended target. Servers are required to enforce the 221 integrity of the relationships between the new URIs and the resources 222 associated with them. Consequently, it may be very costly for 223 servers to support BIND requests that cross server boundaries. 225 This specification is organized as follows. Section 1.1 defines 226 terminology used in the rest of the specification, while Section 2 227 overviews bindings. Section 3 defines the new properties needed to 228 support multiple bindings to the same resource. Section 4 specifies 229 the BIND method, used to create multiple bindings to the same 230 resource. Section 5 specifies the UNBIND method, used to remove a 231 binding to a resource. Section 6 specifies the REBIND method, used 232 to move a binding to another collection. 234 1.1. Terminology 236 The terminology used here follows and extends that in the WebDAV 237 Distributed Authoring Protocol specification [RFC4918]. 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [RFC2119]. 243 This document uses XML DTD fragments ([XML]) as a notational 244 convention, using the rules defined in Section 17 of [RFC4918]. 246 URI Mapping 248 A relation between an absolute URI and a resource. For an 249 absolute URI U and the resource it identifies R, the URI mapping 250 can be thought of as (U => R). Since a resource can represent 251 items that are not network retrievable, as well as those that are, 252 it is possible for a resource to have zero, one, or many URI 253 mappings. Mapping a resource to an "http" scheme URI makes it 254 possible to submit HTTP protocol requests to the resource using 255 the URI. 257 Path Segment 258 Informally, the characters found between slashes ("/") in a URI. 259 Formally, as defined in Section 3.3 of [RFC3986]. 261 Binding 263 A relation between a single path segment (in a collection) and a 264 resource. A binding is part of the state of a collection. If two 265 different collections contain a binding between the same path 266 segment and the same resource, these are two distinct bindings. 267 So for a collection C, a path segment S, and a resource R, the 268 binding can be thought of as C:(S -> R). Bindings create URI 269 mappings, and hence allow requests to be sent to a single resource 270 from multiple locations in a URI namespace. For example, given a 271 collection C (accessible through the URI 272 http://www.example.com/CollX), a path segment S (equal to 273 "foo.html"), and a resource R, then creating the binding C: (S -> 274 R) makes it possible to use the URI 275 http://www.example.com/CollX/foo.html to access R. 277 Collection 279 A resource that contains, as part of its state, a set of bindings 280 that identify internal member resources. 282 Internal Member URI 284 The URI that identifies an internal member of a collection, and 285 that consists of the URI for the collection, followed by a slash 286 character ('/'), followed by the path segment of the binding for 287 that internal member. 289 1.2. Method Preconditions and Postconditions 291 See Section 16 of [RFC4918] for the definitions of "precondition" and 292 "postcondition". 294 2. Overview of Bindings 296 Bindings are part of the state of a collection. They define the 297 internal members of the collection, and the names of those internal 298 members. 300 Bindings are added and removed by a variety of existing HTTP methods. 301 A method that creates a new resource, such as PUT, COPY, and MKCOL, 302 adds a binding. A method that deletes a resource, such as DELETE, 303 removes a binding. A method that moves a resource (e.g. MOVE) both 304 adds a binding (in the destination collection) and removes a binding 305 (in the source collection). The BIND method introduced here provides 306 a mechanism for adding a second binding to an existing resource. 307 There is no difference between an initial binding added by PUT, COPY, 308 or MKCOL, and additional bindings added with BIND. 310 It would be very undesirable if one binding could be destroyed as a 311 side effect of operating on the resource through a different binding. 312 In particular, the removal of one binding to a resource (e.g. with a 313 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 314 e.g. by turning that binding into a dangling path segment. The 315 server MUST NOT reclaim system resources after removing one binding, 316 while other bindings to the resource remain. In other words, the 317 server MUST maintain the integrity of a binding. It is permissible, 318 however, for future method definitions (e.g., a DESTROY method) to 319 have semantics that explicitly remove all bindings and/or immediately 320 reclaim system resources. 322 2.1. Bindings to Collections 324 Creating a new binding to a collection makes each resource associated 325 with a binding in that collection accessible via a new URI, and thus 326 creates new URI mappings to those resources but no new bindings. 328 For example, suppose a new binding CollY is created for collection C1 329 in the figure below. It immediately becomes possible to access 330 resource R1 using the URI /CollY/x.gif and to access resource R2 331 using the URI /CollY/y.jpg, but no new bindings for these child 332 resources were created. This is because bindings are part of the 333 state of a collection, and associate a URI that is relative to that 334 collection with its target resource. No change to the bindings in 335 Collection C1 is needed to make its children accessible using /CollY/ 336 x.gif and /CollY/y.jpg. 338 +-------------------------+ 339 | Root Collection | 340 | bindings: | 341 | CollX CollY | 342 +-------------------------+ 343 | / 344 | / 345 | / 346 +------------------+ 347 | Collection C1 | 348 | bindings: | 349 | x.gif y.jpg | 350 +------------------+ 351 | \ 352 | \ 353 | \ 354 +-------------+ +-------------+ 355 | Resource R1 | | Resource R2 | 356 +-------------+ +-------------+ 358 2.1.1. Bind Loops 360 Bindings to collections can result in loops ("cycles"), which servers 361 MUST detect when processing "Depth: infinity" requests. It is 362 sometimes possible to complete an operation in spite of the presence 363 of a loop. For instance, a PROPFIND can still succeed if the server 364 uses the new status code 208 (Already Reported) defined in 365 Section 7.1. 367 However, the 506 (Loop Detected) status code is defined in 368 Section 7.2 for use in contexts where an operation is terminated 369 because a loop was encountered. 371 Support for loops is OPTIONAL: servers MAY reject requests that would 372 lead to the creation of a bind loop (see DAV:cycle-allowed 373 precondition defined in Section 4). 375 2.2. URI Mappings Created by a new Binding 377 Suppose a binding from "Binding-Name" to resource R is to be added to 378 a collection, C. Then if C-MAP is the set of URIs that were mapped to 379 C before the BIND request, then for each URI "C-URI" in C-MAP, the 380 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 381 request. 383 For example, if a binding from "foo.html" to R is added to a 384 collection C, and if the following URIs are mapped to C: 386 http://www.example.com/A/1/ 387 http://example.com/A/one/ 389 then the following new mappings to R are introduced: 391 http://www.example.com/A/1/foo.html 392 http://example.com/A/one/foo.html 394 Note that if R is a collection, additional URI mappings are created 395 to the descendents of R. Also, note that if a binding is made in 396 collection C to C itself (or to a parent of C), an infinite number of 397 mappings are introduced. 399 For example, if a binding from "myself" to C is then added to C, the 400 following infinite number of additional mappings to C are introduced: 402 http://www.example.com/A/1/myself 403 http://www.example.com/A/1/myself/myself 404 ... 406 and the following infinite number of additional mappings to R are 407 introduced: 409 http://www.example.com/A/1/myself/foo.html 410 http://www.example.com/A/1/myself/myself/foo.html 411 ... 413 2.3. COPY and Bindings 415 As defined in Section 9.8 of [RFC4918], COPY causes the resource 416 identified by the Request-URI to be duplicated, and makes the new 417 resource accessible using the URI specified in the Destination 418 header. Upon successful completion of a COPY, a new binding is 419 created between the last path segment of the Destination header, and 420 the destination resource. The new binding is added to its parent 421 collection, identified by the Destination header minus its final 422 segment. 424 The following figure shows an example: Suppose that a COPY is issued 425 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 426 with the Destination header set to URI-X. After successful 427 completion of the COPY operation, resource R is duplicated to create 428 resource R', and a new binding has been created which creates at 429 least the URI mapping between URI-X and the new resource (although 430 other URI mappings may also have been created). 432 URI-1 URI-2 URI-3 URI-X 433 | | | | 434 | | | <---- URI Mappings ----> | 435 | | | | 436 +---------------------+ +------------------------+ 437 | Resource R | | Resource R' | 438 +---------------------+ +------------------------+ 440 It might be thought that a COPY request with "Depth: 0" on a 441 collection would duplicate its bindings, since bindings are part of 442 the collection's state. This is not the case, however. The 443 definition of Depth in [RFC4918] makes it clear that a "Depth: 0" 444 request does not apply to a collection's members. Consequently, a 445 COPY with "Depth: 0" does not duplicate the bindings contained by the 446 collection. 448 If a COPY request causes an existing resource to be updated, the 449 bindings to that resource MUST be unaffected by the COPY request. 450 Using the preceding example, suppose that a COPY request is issued to 451 URI-X for resource R', with the Destination header set to URI-2. The 452 content and dead properties of resource R would be updated to be a 453 copy of those of resource R', but the mappings from URI-1, URI-2, and 454 URI-3 to resource R remain unaffected. If because of multiple 455 bindings to a resource, more than one source resource updates a 456 single destination resource, the order of the updates is server 457 defined. 459 If a COPY request would cause a new resource to be created as a copy 460 of an existing resource, and that COPY request has already created a 461 copy of that existing resource, the COPY request instead creates 462 another binding to the previous copy, instead of creating a new 463 resource. 465 2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops 467 As an example of how COPY with Depth infinity would work in the 468 presence of bindings, consider the following collection: 470 +------------------+ 471 | Root Collection | 472 | bindings: | 473 | CollX | 474 +------------------+ 475 | 476 | 477 +-------------------------------+ 478 | Collection C1 |<-------+ 479 | bindings: | | 480 | x.gif CollY | | 481 +-------------------------------+ | 482 | \ (creates loop) | 483 | \ | 484 +-------------+ +------------------+ | 485 | Resource R1 | | Collection C2 | | 486 +-------------+ | bindings: | | 487 | y.gif CollZ | | 488 +------------------+ | 489 | | | 490 | +--------+ 491 | 492 +-------------+ 493 | Resource R2 | 494 +-------------+ 496 If a COPY with Depth infinity is submitted to /CollX, with 497 destination of /CollA, the outcome of the copy operation is: 499 +------------------+ 500 | Root Collection | 501 | bindings: | 502 | CollX CollA | 503 +------------------+ 504 | | 505 | +---------------------------+ 506 | | 507 +-------------------+ | 508 | Collection C1 |<------------------+ | 509 | bindings: | | | 510 | x.gif CollY | | | 511 +-------------------+ | | 512 | \ (creates loop) | | 513 | \ | | 514 +-------------+ +-----------------+ | | 515 | Resource R1 | | Collection C2 | | | 516 +-------------+ | bindings: | | | 517 | y.gif CollZ | | | 518 +-----------------+ | | 519 | | | | 520 | +-------+ | 521 | | 522 +-------------+ | 523 | Resource R2 | | 524 +-------------+ | 525 | 526 +-------------------------------+ 527 | 528 +-------------------+ 529 | Collection C3 |<------------------+ 530 | bindings: | | 531 | x.gif CollY | | 532 +-------------------+ | 533 | \ (creates loop) | 534 | \ | 535 +-------------+ +-----------------+ | 536 | Resource R3 | | Collection C4 | | 537 +-------------+ | bindings: | | 538 | y.gif CollZ | | 539 +-----------------+ | 540 | | | 541 | +-------+ 542 | 543 +-------------+ 544 | Resource R4 | 545 +-------------+ 547 2.3.2. Example: COPY with 'Depth: infinity' with Multiple Bindings to a 548 Leaf Resource 550 Given the following collection hierarchy: 552 +------------------+ 553 | Root Collection | 554 | bindings: | 555 | CollX | 556 +------------------+ 557 | 558 | 559 | 560 +----------------+ 561 | Collection C1 | 562 | bindings: | 563 | x.gif y.gif | 564 +----------------+ 565 | | 566 | | 567 +-------------+ 568 | Resource R1 | 569 +-------------+ 571 A COPY of /CollX with Depth infinity to /CollY results in the 572 following collection hierarchy: 574 +------------------+ 575 | Root Collection | 576 | bindings: | 577 | CollX CollY | 578 +------------------+ 579 | \ 580 | \ 581 | \ 582 +----------------+ +-----------------+ 583 | Collection C1 | | Collection C2 | 584 | bindings: | | bindings: | 585 | x.gif y.gif | | x.gif y.gif | 586 +----------------+ +-----------------+ 587 | | | | 588 | | | | 589 +-------------+ +-------------+ 590 | Resource R1 | | Resource R2 | 591 +-------------+ +-------------+ 593 2.4. DELETE and Bindings 595 When there are multiple bindings to a resource, a DELETE applied to 596 that resource MUST NOT remove any bindings to that resource other 597 than the one identified by the Request-URI. For example, suppose the 598 collection identified by the URI "/a" has a binding named "x" to a 599 resource R, and another collection identified by "/b" has a binding 600 named "y" to the same resource R. Then a DELETE applied to "/a/x" 601 removes the binding named "x" from "/a" but MUST NOT remove the 602 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 603 to identify the resource R). 605 When DELETE is applied to a collection, it MUST NOT modify the 606 membership of any other collection that is not itself a member of the 607 collection being deleted. For example, if both "/a/.../x" and 608 "/b/.../y" identify the same collection, C, then applying DELETE to 609 "/a" must not delete an internal member from C or from any other 610 collection that is a member of C, because that would modify the 611 membership of "/b". 613 If a collection supports the UNBIND method (see Section 5), a DELETE 614 of an internal member of a collection MAY be implemented as an UNBIND 615 request. In this case, applying DELETE to a Request-URI has the 616 effect of removing the binding identified by the final segment of the 617 Request-URI from the collection identified by the Request-URI minus 618 its final segment. Although [RFC4918] allows a DELETE to be a non- 619 atomic operation, when the DELETE operation is implemented as an 620 UNBIND, the operation is atomic. In particular, a DELETE on a 621 hierarchy of resources is simply the removal of a binding to the 622 collection identified by the Request-URI. 624 2.5. MOVE and Bindings 626 When MOVE is applied to a resource, the other bindings to that 627 resource MUST be unaffected, and if the resource being moved is a 628 collection, the bindings to any members of that collection MUST be 629 unaffected. Also, if MOVE is used with Overwrite:T to delete an 630 existing resource, the constraints specified for DELETE apply. 632 If the destination collection of a MOVE request supports the REBIND 633 method (see Section 6), a MOVE of a resource into that collection MAY 634 be implemented as a REBIND request. Although [RFC4918] allows a MOVE 635 to be a non-atomic operation, when the MOVE operation is implemented 636 as a REBIND, the operation is atomic. In particular, applying a MOVE 637 to a Request-URI and a Destination URI has the effect of removing a 638 binding to a resource (at the Request-URI), and creating a new 639 binding to that resource (at the Destination URI). Even when the 640 Request-URI identifies a collection, the MOVE operation involves only 641 removing one binding to that collection and adding another. 643 2.5.1. Example: Simple MOVE 645 As an example, suppose that a MOVE is issued to URI-3 for resource R 646 below (which is also mapped to URI-1 and URI-2), with the Destination 647 header set to URI-X. After successful completion of the MOVE 648 operation, a new binding has been created which creates the URI 649 mapping between URI-X and resource R. The binding corresponding to 650 the final segment of URI-3 has been removed, which also causes the 651 URI mapping between URI-3 and R to be removed. If resource R were a 652 collection, old URI-3 based mappings to members of R would have been 653 removed, and new URI-X based mappings to members of R would have been 654 created. 656 >> Before Request: 658 URI-1 URI-2 URI-3 659 | | | 660 | | | <---- URI Mappings 661 | | | 662 +---------------------+ 663 | Resource R | 664 +---------------------+ 666 >> After Request: 668 URI-1 URI-2 URI-X 669 | | | 670 | | | <---- URI Mappings 671 | | | 672 +---------------------+ 673 | Resource R | 674 +---------------------+ 676 2.5.2. Example: MOVE Request causing a Bind Loop 678 Note that in the presence of collection bindings, a MOVE request can 679 cause the creating of a bind loop. 681 Consider a the top level collections C1 and C2 with URIs "/CollW/" 682 and "/CollX/". C1 also contains an additional binding named "CollY" 683 to C2: 685 +------------------+ 686 | Root Collection | 687 | bindings: | 688 | CollW CollX | 689 +------------------+ 690 | | 691 | | 692 +------------------+ | 693 | Collection C1 | | 694 | bindings: | | 695 | CollY | | 696 +------------------+ | 697 | | 698 | | 699 +------------------+ 700 | Collection C2 | 701 | | 702 | | 703 +------------------+ 705 In this case, the MOVE request below would cause a bind loop: 707 >> Request: 709 MOVE /CollW HTTP/1.1 710 Host: example.com 711 Destination: /CollX/CollZ 712 If the request succeeded, the resulting state would be: 714 +------------------+ 715 | Root Collection | 716 | bindings: | 717 | CollX | 718 +------------------+ 719 | 720 | 721 +------------------+ | 722 | Collection C1 | | 723 +----> | bindings: | | 724 | | CollY | | 725 | +------------------+ | 726 | | | 727 | | | 728 | +------------------+ 729 | | Collection C2 | 730 | | bindings: | 731 | | CollZ | 732 | +------------------+ 733 | | 734 | | 735 +-------------------+ 737 2.6. PROPFIND and Bindings 739 Consistent with [RFC4918], the value of a dead property MUST be 740 independent of the number of bindings to its host resource or of the 741 path submitted to PROPFIND. On the other hand, the behaviour for 742 each live property depends on its individual definition (for example, 743 see [RFC3744], Section 5, paragraph 2). 745 2.7. Determining Whether Two Bindings Are to the Same Resource 747 It is useful to have some way of determining whether two bindings are 748 to the same resource. Two resources might have identical contents 749 and properties, but not be the same resource (e.g. an update to one 750 resource does not affect the other resource). 752 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 753 resource identifier, which MUST be unique across all resources for 754 all time. If the values of DAV:resource-id returned by PROPFIND 755 requests through two bindings are identical character by character, 756 the client can be assured that the two bindings are to the same 757 resource. 759 The DAV:resource-id property is created, and its value assigned, when 760 the resource is created. The value of DAV:resource-id MUST NOT be 761 changed. Even after the resource is no longer accessible through any 762 URI, that value MUST NOT be reassigned to another resource's DAV: 763 resource-id property. 765 Any method that creates a new resource MUST assign a new, unique 766 value to its DAV:resource-id property. For example, a PUT applied to 767 a null resource, COPY (when not overwriting an existing target) and 768 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 769 to the DAV:resource-id property of the new resource they create. 771 On the other hand, any method that affects an existing resource must 772 not change the value of its DAV:resource-id property. Specifically, 773 a PUT or a COPY that updates an existing resource must not change the 774 value of its DAV:resource-id property. A REBIND, since it does not 775 create a new resource, but only changes the location of an existing 776 resource, must not change the value of the DAV:resource-id property. 778 2.8. Discovering the Bindings to a Resource 780 An OPTIONAL DAV:parent-set property on a resource provides a list of 781 the bindings that associate a collection and a URI segment with that 782 resource. If the DAV:parent-set property exists on a given resource, 783 it MUST contain a complete list of all bindings to that resource that 784 the client is authorized to see. When deciding whether to support 785 the DAV:parent-set property, server implementers / administrators 786 should balance the benefits it provides against the cost of 787 maintaining the property and the security risks enumerated in 788 Sections 11.4 and 11.5. 790 3. Properties 792 The bind feature introduces the properties defined below. 794 A DAV:allprop PROPFIND request SHOULD NOT return any of the 795 properties defined by this document. This allows a binding server to 796 perform efficiently when a naive client, which does not understand 797 the cost of asking a server to compute all possible live properties, 798 issues a DAV:allprop PROPFIND request. 800 3.1. DAV:resource-id Property 802 The DAV:resource-id property is a REQUIRED property that enables 803 clients to determine whether two bindings are to the same resource. 804 The value of DAV:resource-id is a URI, and may use any registered URI 805 scheme that guarantees the uniqueness of the value across all 806 resources for all time (e.g. the urn:uuid: URN namespace defined in 808 [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]). 810 812 Note: by definition, the URI specified in the DAV:resource-id 813 property always is an alternate URI for that resource. 815 3.2. DAV:parent-set Property 817 The DAV:parent-set property is an OPTIONAL property that enables 818 clients to discover what collections contain a binding to this 819 resource (i.e. what collections have that resource as an internal 820 member). It contains an href/segment pair for each collection that 821 has a binding to the resource. The href identifies the collection, 822 and the segment identifies the binding name of that resource in that 823 collection. 825 A given collection MUST appear only once in the DAV:parent-set for 826 any given binding, even if there are multiple URI mappings to that 827 collection. 829 830 831 832 835 3.2.1. Example for DAV:parent-set Property 837 For example, if collection C1 is mapped to both /CollX and /CollY, 838 and C1 contains a binding named "x.gif" to a resource R1, then either 839 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 840 of R1, but not both. But if C1 also had a binding named "y.gif" to 841 R1, then there would be two entries for C1 in the DAV:binding-set of 842 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 843 both [/CollY, x.gif] and [/CollY, y.gif]). 845 +-------------------------+ 846 | Root Collection | 847 | bindings: | 848 | CollX CollY | 849 +-------------------------+ 850 | / 851 | / 852 | / 853 +-----------------+ 854 | Collection C1 | 855 | bindings: | 856 | x.gif y.gif | 857 +-----------------+ 858 | | 859 | | 860 | | 861 +--------------+ 862 | Resource R1 | 863 +--------------+ 865 In this case, one possible value for DAV:parent-set property on 866 "/CollX/x.gif" would be: 868 869 870 /CollX 871 x.gif 872 873 874 /CollX 875 y.gif 876 877 879 4. BIND Method 881 The BIND method modifies the collection identified by the Request- 882 URI, by adding a new binding from the segment specified in the BIND 883 body to the resource identified in the BIND body. 885 If a server cannot guarantee the integrity of the binding, the BIND 886 request MUST fail. Note that it is especially difficult to maintain 887 the integrity of cross-server bindings. Unless the server where the 888 resource resides knows about all bindings on all servers to that 889 resource, it may unwittingly destroy the resource or make it 890 inaccessible without notifying another server that manages a binding 891 to the resource. For example, if server A permits creation of a 892 binding to a resource on server B, server A must notify server B 893 about its binding and must have an agreement with B that B will not 894 destroy the resource while A's binding exists. Otherwise server B 895 may receive a DELETE request that it thinks removes the last binding 896 to the resource and destroy the resource while A's binding still 897 exists. The precondition DAV:cross-server-binding is defined below 898 for cases where servers fail cross-server BIND requests because they 899 cannot guarantee the integrity of cross-server bindings. 901 By default, if there already is a binding for the specified segment 902 in the collection, the new binding replaces the existing binding. 903 This default binding replacement behavior can be overridden using the 904 Overwrite header defined in Section 10.6 of [RFC4918]. 906 If a BIND request fails, the server state preceding the request MUST 907 be restored. This method is unsafe and idempotent (see [RFC2616], 908 Section 9.1). 910 Marshalling: 912 The request MAY include an Overwrite header. 914 The request body MUST be a DAV:bind XML element. 916 918 If the request succeeds, the server MUST return 201 (Created) when 919 a new binding was created and 200 (OK) or 204 (No Content) when an 920 existing binding was replaced. 922 If a response body for a successful request is included, it MUST 923 be a DAV:bind-response XML element. Note that this document does 924 not define any elements for the BIND response body, but the DAV: 925 bind-response element is defined to ensure interoperability 926 between future extensions that do define elements for the BIND 927 response body. 929 931 Preconditions: 933 (DAV:bind-into-collection): The Request-URI MUST identify a 934 collection. 936 (DAV:bind-source-exists): The DAV:href element MUST identify a 937 resource. 939 (DAV:binding-allowed): The resource identified by the DAV:href 940 supports multiple bindings to it. 942 (DAV:cross-server-binding): If the resource identified by the DAV: 943 href element in the request body is on another server from the 944 collection identified by the Request-URI, the server MUST support 945 cross-server bindings (servers that do not support cross-server 946 bindings can use this condition code to signal the client exactly 947 why the request failed). 949 (DAV:name-allowed): The name specified by the DAV:segment is 950 available for use as a new binding name. 952 (DAV:can-overwrite): If the collection already contains a binding 953 with the specified path segment, and if an Overwrite header is 954 included, the value of the Overwrite header MUST be "T". 956 (DAV:cycle-allowed): If the DAV:href element identifies a 957 collection, and if the Request-URI identifies a collection that is 958 a member of that collection, the server MUST support cycles in the 959 URI namespace (servers that do not support cycles can use this 960 condition code to signal the client exactly why the request 961 failed). 963 (DAV:locked-update-allowed): If the collection identified by the 964 Request-URI is write-locked, then the appropriate token MUST be 965 specified in an If request header. 967 (DAV:locked-overwrite-allowed): If the collection already contains 968 a binding with the specified path segment, and if that binding is 969 protected by a write-lock, then the appropriate token MUST be 970 specified in an If request header. 972 Postconditions: 974 (DAV:new-binding): The collection MUST have a binding that maps 975 the segment specified in the DAV:segment element in the request 976 body, to the resource identified by the DAV:href element in the 977 request body. 979 4.1. Example: BIND 981 >> Request: 983 BIND /CollY HTTP/1.1 984 Host: www.example.com 985 Content-Type: application/xml; charset="utf-8" 986 Content-Length: 172 988 989 990 bar.html 991 http://www.example.com/CollX/foo.html 992 994 >> Response: 996 HTTP/1.1 201 Created 998 Location: http://www.example.com/CollY/bar.html 1000 The server added a new binding to the collection, 1001 "http://www.example.com/CollY", associating "bar.html" with the 1002 resource identified by the URI 1003 "http://www.example.com/CollX/foo.html". Clients can now use the URI 1004 "http://www.example.com/CollY/bar.html" to submit requests to that 1005 resource. 1007 5. UNBIND Method 1009 The UNBIND method modifies the collection identified by the Request- 1010 URI, by removing the binding identified by the segment specified in 1011 the UNBIND body. 1013 Once a resource is unreachable by any URI mapping, the server MAY 1014 reclaim system resources associated with that resource. If UNBIND 1015 removes a binding to a resource, but there remain URI mappings to 1016 that resource, the server MUST NOT reclaim system resources 1017 associated with the resource. 1019 If an UNBIND request fails, the server state preceding the request 1020 MUST be restored. This method is unsafe and idempotent (see 1021 [RFC2616], Section 9.1). 1023 Marshalling: 1025 The request body MUST be a DAV:unbind XML element. 1027 1029 If the request succeeds, the server MUST return 200 (OK) or 204 1030 (No Content) when the binding was successfully deleted. 1032 If a response body for a successful request is included, it MUST 1033 be a DAV:unbind-response XML element. Note that this document 1034 does not define any elements for the UNBIND response body, but the 1035 DAV:unbind-response element is defined to ensure interoperability 1036 between future extensions that do define elements for the UNBIND 1037 response body. 1039 1041 Preconditions: 1043 (DAV:unbind-from-collection): The Request-URI MUST identify a 1044 collection. 1046 (DAV:unbind-source-exists): The DAV:segment element MUST identify 1047 a binding in the collection identified by the Request-URI. 1049 (DAV:locked-update-allowed): If the collection identified by the 1050 Request-URI is write-locked, then the appropriate token MUST be 1051 specified in the request. 1053 (DAV:protected-url-deletion-allowed): If the binding identified by 1054 the segment is protected by a write-lock, then the appropriate 1055 token MUST be specified in the request. 1057 Postconditions: 1059 (DAV:binding-deleted): The collection MUST NOT have a binding for 1060 the segment specified in the DAV:segment element in the request 1061 body. 1063 (DAV:lock-deleted): If the internal member URI of the binding 1064 specified by the Request-URI and the DAV:segment element in the 1065 request body was protected by a write-lock at the time of the 1066 request, that write-lock must have been deleted by the request. 1068 5.1. Example: UNBIND 1070 >> Request: 1072 UNBIND /CollX HTTP/1.1 1073 Host: www.example.com 1074 Content-Type: application/xml; charset="utf-8" 1075 Content-Length: 117 1077 1078 1079 foo.html 1080 1082 >> Response: 1084 HTTP/1.1 200 OK 1086 The server removed the binding named "foo.html" from the collection, 1087 "http://www.example.com/CollX". A request to the resource named 1088 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1089 response. 1091 6. REBIND Method 1093 The REBIND method removes a binding to a resource from a collection, 1094 and adds a binding to that resource into the collection identified by 1095 the Request-URI. The request body specifies the binding to be added 1096 (segment) and the old binding to be removed (href). It is 1097 effectively an atomic form of a MOVE request, and MUST be treated the 1098 same way as MOVE for the purpose of determining access permissions. 1100 If a REBIND request fails, the server state preceding the request 1101 MUST be restored. This method is unsafe and idempotent (see 1102 [RFC2616], Section 9.1). 1104 Marshalling: 1106 The request MAY include an Overwrite header. 1108 The request body MUST be a DAV:rebind XML element. 1110 1112 If the request succeeds, the server MUST return 201 (Created) when 1113 a new binding was created and 200 (OK) or 204 (No Content) when an 1114 existing binding was replaced. 1116 If a response body for a successful request is included, it MUST 1117 be a DAV:rebind-response XML element. Note that this document 1118 does not define any elements for the REBIND response body, but the 1119 DAV:rebind-response element is defined to ensure interoperability 1120 between future extensions that do define elements for the REBIND 1121 response body. 1123 1125 Preconditions: 1127 (DAV:rebind-into-collection): The Request-URI MUST identify a 1128 collection. 1130 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1131 resource. 1133 (DAV:cross-server-binding): If the resource identified by the DAV: 1134 href element in the request body is on another server from the 1135 collection identified by the Request-URI, the server MUST support 1136 cross-server bindings (servers that do not support cross-server 1137 bindings can use this condition code to signal the client exactly 1138 why the request failed). 1140 (DAV:name-allowed): The name specified by the DAV:segment is 1141 available for use as a new binding name. 1143 (DAV:can-overwrite): If the collection already contains a binding 1144 with the specified path segment, and if an Overwrite header is 1145 included, the value of the Overwrite header MUST be "T". 1147 (DAV:cycle-allowed): If the DAV:href element identifies a 1148 collection, and if the Request-URI identifies a collection that is 1149 a member of that collection, the server MUST support cycles in the 1150 URI namespace (servers that do not support cycles can use this 1151 condition code to signal the client exactly why the request 1152 failed). 1154 (DAV:locked-update-allowed): If the collection identified by the 1155 Request-URI is write-locked, then the appropriate token MUST be 1156 specified in the request. 1158 (DAV:protected-url-modification-allowed): If the collection 1159 identified by the Request-URI already contains a binding with the 1160 specified path segment, and if that binding is protected by a 1161 write-lock, then the appropriate token MUST be specified in the 1162 request. 1164 (DAV:locked-source-collection-update-allowed): If the collection 1165 identified by the parent collection prefix of the DAV:href URI is 1166 write-locked, then the appropriate token MUST be specified in the 1167 request. 1169 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1170 is protected by a write lock, then the appropriate token MUST be 1171 specified in the request. 1173 Postconditions: 1175 (DAV:new-binding): The collection MUST have a binding that maps 1176 the segment specified in the DAV:segment element in the request 1177 body, to the resource that was identified by the DAV:href element 1178 in the request body. 1180 (DAV:binding-deleted): The URL specified in the DAV:href element 1181 in the request body MUST NOT be mapped to a resource. 1183 (DAV:lock-deleted): If the URL specified in the DAV:href element 1184 in the request body was protected by a write-lock at the time of 1185 the request, that write-lock must have been deleted by the 1186 request. 1188 6.1. Example: REBIND 1190 >> Request: 1192 REBIND /CollX HTTP/1.1 1193 Host: www.example.com 1194 Content-Type: application/xml; charset="utf-8" 1195 Content-Length: 176 1197 1198 1199 foo.html 1200 http://www.example.com/CollY/bar.html 1201 1203 >> Response: 1205 HTTP/1.1 200 OK 1207 The server added a new binding to the collection, 1208 "http://www.example.com/CollX", associating "foo.html" with the 1209 resource identified by the URI 1210 "http://www.example.com/CollY/bar.html", and removes the binding 1211 named "bar.html" from the collection identified by the URI 1212 "http://www.example.com/CollY". Clients can now use the URI 1213 "http://www.example.com/CollX/foo.html" to submit requests to that 1214 resource, and requests on the URI 1215 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1216 Found) response. 1218 6.2. Example: REBIND in Presence of Locks and Bind Loops 1220 To illustrate the effects of locks and bind loops on a REBIND 1221 operation, consider the following collection: 1223 +------------------+ 1224 | Root Collection | 1225 | bindings: | 1226 | CollW | 1227 +------------------+ 1228 | 1229 | 1230 | 1231 +-------------------------------+ 1232 | Collection C1 |<--------+ 1233 | LOCKED infinity | | 1234 | (lock token L1) | | 1235 | bindings: | | 1236 | CollX CollY | | 1237 +-------------------------------+ | 1238 | | | 1239 | | (creates loop) | 1240 | | | 1241 +-----------------+ +------------------+ | 1242 | Collection C2 | | Collection C3 | | 1243 | (inherit lock) | | (inherit lock) | | 1244 | (lock token L1) | | (lock token L1) | | 1245 | bindings: | | bindings: | | 1246 | {none} | | y.gif CollZ | | 1247 +-----------------+ +------------------+ | 1248 | | | 1249 | +-----+ 1250 | 1251 +---------------------------+ 1252 | Resource R2 | 1253 | (lock inherited from C1) | 1254 | (lock token L1) | 1255 +---------------------------+ 1257 (where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1259 Note that the binding between CollZ and C1 creates a loop in the 1260 containment hierarchy. Servers are not required to support such 1261 loops, though the server in this example does. 1263 The REBIND request below will remove the segment "CollZ" from C3 and 1264 add a new binding from "CollA" to the collection C2. 1266 REBIND /CollW/CollX HTTP/1.1 1267 Host: www.example.com 1268 If: () 1269 Content-Type: application/xml; charset="utf-8" 1270 Content-Length: 152 1272 1273 1274 CollA 1275 /CollW/CollY/CollZ 1276 1277 The outcome of the REBIND operation is: 1279 +------------------+ 1280 | Root Collection | 1281 | bindings: | 1282 | CollW | 1283 +------------------+ 1284 | 1285 | 1286 | 1287 +-------------------------------+ 1288 | Collection C1 | 1289 | LOCKED infinity | 1290 | (lock token L1) | 1291 | bindings: | 1292 | CollX CollY | 1293 +-------------------------------+ 1294 | ^ | 1295 | | | 1296 +-----------------+ | +------------------+ 1297 | Collection C2 | | | Collection C3 | 1298 |(inherited lock) | | | (inherited lock) | 1299 |(lock token L1) | | | (lock token L1) | 1300 | bindings: | | | bindings: | 1301 | CollA | | | y.gif | 1302 +-----------------+ | +------------------+ 1303 | | | 1304 +---------------+ | 1305 (creates loop) | 1306 +---------------------------+ 1307 | Resource R2 | 1308 | (inherited lock from C1) | 1309 | (lock token L1) | 1310 +---------------------------+ 1312 7. Additional Status Codes 1314 7.1. 208 Already Reported 1316 The 208 (Already Reported) status code can be used inside a DAV: 1317 propstat response element to avoid enumerating the internal members 1318 of multiple bindings to the same collection repeatedly. For each 1319 binding to a collection inside the request's scope, only one will be 1320 reported with a 200 status, while subsequent DAV:response elements 1321 for all other bindings will use the 208 status, and no DAV:response 1322 elements for their descendants are included. 1324 Note that the 208 status will only occur for "Depth: infinity" 1325 requests, and that it is of particular importance when the multiple 1326 collection bindings cause a bind loop as discussed in Section 2.2. 1328 A client can request the DAV:resource-id property in a PROPFIND 1329 request to guarantee that they can accurately reconstruct the binding 1330 structure of a collection with multiple bindings to a single 1331 resource. 1333 For backward compatibility with clients not aware of the 208 status 1334 code appearing in multistatus response bodies, it SHOULD NOT be used 1335 unless the client has signalled support for this specification using 1336 the "DAV" request header (see Section 8.2). Instead, a 506 status 1337 should be returned when a binding loop is discovered. This allows 1338 the server to return the 506 as the top level return status, if it 1339 discovers it before it started the response, or in the middle of a 1340 multistatus, if it discovers it in the middle of streaming out a 1341 multistatus response. 1343 7.1.1. Example: PROPFIND by Bind-Aware Client 1345 For example, consider a PROPFIND request on /Coll (bound to 1346 collection C), where the members of /Coll are /Coll/Foo (bound to 1347 resource R) and /Coll/Bar (bound to collection C). 1349 >> Request: 1351 PROPFIND /Coll/ HTTP/1.1 1352 Host: www.example.com 1353 Depth: infinity 1354 DAV: bind 1355 Content-Type: application/xml; charset="utf-8" 1356 Content-Length: 152 1358 1359 1360 1361 1362 1363 1364 1366 >> Response: 1368 HTTP/1.1 207 Multi-Status 1369 Content-Type: application/xml; charset="utf-8" 1370 Content-Length: 1241 1372 1373 1374 1375 http://www.example.com/Coll/ 1376 1377 1378 Loop Demo 1379 1380 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1382 1383 1384 HTTP/1.1 200 OK 1385 1386 1387 1388 http://www.example.com/Coll/Foo 1389 1390 1391 Bird Inventory 1392 1393 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1395 1396 1397 HTTP/1.1 200 OK 1398 1399 1400 1401 http://www.example.com/Coll/Bar 1402 1403 1404 Loop Demo 1405 1406 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1408 1409 1410 HTTP/1.1 208 Already Reported 1411 1412 1413 1415 7.1.2. Example: PROPFIND by Non-Bind-Aware Client 1417 In this example, the client isn't aware of the 208 status code 1418 introduced by this specification. As the "Depth: infinity" PROPFIND 1419 request would cause a loop condition, the whole request is rejected 1420 with a 506 status. 1422 >> Request: 1424 PROPFIND /Coll/ HTTP/1.1 1425 Host: www.example.com 1426 Depth: infinity 1427 Content-Type: application/xml; charset="utf-8" 1428 Content-Length: 125 1430 1431 1432 1433 1435 >> Response: 1437 HTTP/1.1 506 Loop Detected 1439 7.2. 506 Loop Detected 1441 The 506 (Loop Detected) status code indicates that the server 1442 terminated an operation because it encountered an infinite loop while 1443 processing a request with "Depth: infinity". This status indicates 1444 that the entire operation failed. 1446 8. Capability Discovery 1448 8.1. OPTIONS Method 1450 If the server supports bindings, it MUST return the compliance class 1451 name "bind" as a field in the "DAV" response header (see [RFC4918], 1452 Section 10.1) from an OPTIONS request on any resource implemented by 1453 that server. A value of "bind" in the "DAV" header MUST indicate 1454 that the server supports all MUST level requirements and REQUIRED 1455 features specified in this document. 1457 8.2. 'DAV' Request Header 1459 Clients SHOULD signal support for all MUST level requirements and 1460 REQUIRED features by submitting a "DAV" request header containing the 1461 compliance class name "bind". In particular, the client MUST 1462 understand the 208 status code defined in Section 7.1. 1464 9. Relationship to WebDAV Access Control Protocol 1466 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1467 property (see [RFC3744], Section 7.3). 1469 10. Relationship to Versioning Extensions to WebDAV 1471 Servers that implement Workspaces ([RFC3253], Section 6) and Version 1472 Controlled Collections ([RFC3253], Section 14) already need to 1473 implement BIND-like behaviour in order to handle UPDATE and 1474 UNCHECKOUT semantics. 1476 Consider a workspace "/ws1/", containing the version-controlled, 1477 checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ 1478 CollY", and a version-controlled resource R, bound to C1 as "/ws1/ 1479 CollX/test": 1481 +-------------------------+ 1482 | Workspace | 1483 | bindings: | 1484 | CollX CollY | 1485 +-------------------------+ 1486 | | 1487 | | 1488 | | 1489 +---------------+ +---------------+ 1490 | Collection C1 | | Collection C2 | 1491 | bindings: | | | 1492 | test | | | 1493 +---------------+ +---------------+ 1494 | 1495 | 1496 | 1497 +------------------+ 1498 | Resource R | 1499 +------------------+ 1501 Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but 1502 undoing the checkout on C1 will undo part of the MOVE request, thus 1503 restoring the binding from C1 to R, but keeping the new binding from 1504 C2 to R: 1506 >> Request: 1508 MOVE /ws1/CollX/test HTTP/1.1 1509 Host: www.example.com 1510 Destination: /ws1/CollY/test 1512 >> Response: 1514 HTTP/1.1 204 No Content 1516 >> Request: 1518 CHECKIN /ws1/CollY/ HTTP/1.1 1519 Host: www.example.com 1521 >> Response: 1523 HTTP/1.1 201 Created 1524 Cache-Control: no-cache 1525 Location: http://repo.example.com/his/17/ver/42 1527 >> Request: 1529 UNCHECKOUT /ws1/CollX/ HTTP/1.1 1530 Host: www.example.com 1532 >> Response: 1534 HTTP/1.1 200 OK 1535 Cache-Control: no-cache 1537 As a result, both C1 and C2 would have a binding to R: 1539 +-------------------------+ 1540 | Workspace | 1541 | bindings: | 1542 | CollX CollY | 1543 +-------------------------+ 1544 | | 1545 | | 1546 | | 1547 +---------------+ +---------------+ 1548 | Collection C1 | | Collection C2 | 1549 | bindings: | | bindings: | 1550 | test | | test | 1551 +---------------+ +---------------+ 1552 | | 1553 | | 1554 | | 1555 +------------------+ 1556 | Resource R | 1557 +------------------+ 1559 The MOVE semantics defined in Section 3.15 of [RFC3253] already 1560 require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the 1561 same version history (as exposed in the DAV:version-history 1562 property). Furthermore, the UNCHECKOUT semantics (which in this case 1563 is similar to UPDATE, see Section 14.11 of [RFC3253]) require: 1565 ...If a new version-controlled member is in a workspace that 1566 already has a version-controlled resource for that version 1567 history, then the new version-controlled member MUST be just a 1568 binding (i.e., another name for) that existing version-controlled 1569 resource... 1571 Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the 1572 same resource R, and have identical DAV:resource-id properties. 1574 11. Security Considerations 1576 This section is provided to make WebDAV implementors aware of the 1577 security implications of this protocol. 1579 All of the security considerations of HTTP/1.1 and the WebDAV 1580 Distributed Authoring Protocol specification also apply to this 1581 protocol specification. In addition, bindings introduce several new 1582 security concerns and increase the risk of some existing threats. 1583 These issues are detailed below. 1585 11.1. Privacy Concerns 1587 In a context where cross-server bindings are supported, creating 1588 bindings on a trusted server may make it possible for a hostile agent 1589 to induce users to send private information to a target on a 1590 different server. 1592 11.2. Bind Loops 1594 Although bind loops were already possible in HTTP 1.1, the 1595 introduction of the BIND method creates a new avenue for clients to 1596 create loops accidentally or maliciously. If the binding and its 1597 target are on the same server, the server may be able to detect BIND 1598 requests that would create loops. Servers are required to detect 1599 loops that are caused by bindings to collections during the 1600 processing of any requests with "Depth: infinity". 1602 11.3. Bindings, and Denial of Service 1604 Denial of service attacks were already possible by posting URIs that 1605 were intended for limited use at heavily used Web sites. The 1606 introduction of BIND creates a new avenue for similar denial of 1607 service attacks. If cross-server bindings are supported, clients can 1608 now create bindings at heavily used sites to target locations that 1609 were not designed for heavy usage. 1611 11.4. Private Locations May Be Revealed 1613 If the DAV:parent-set property is maintained on a resource, the 1614 owners of the bindings risk revealing private locations. The 1615 directory structures where bindings are located are available to 1616 anyone who has access to the DAV:parent-set property on the resource. 1617 Moving a binding may reveal its new location to anyone with access to 1618 DAV:parent-set on its resource. 1620 11.5. DAV:parent-set and Denial of Service 1622 If the server maintains the DAV:parent-set property in response to 1623 bindings created in other administrative domains, it is exposed to 1624 hostile attempts to make it devote resources to adding bindings to 1625 the list. 1627 12. Internationalization Considerations 1629 All internationalization considerations mentioned in [RFC4918] also 1630 apply to this document. 1632 13. IANA Considerations 1634 Section 7 defines the HTTP status codes 208 (Already Reported) and 1635 506 (Loop Detected), to be added to the registry at 1636 . 1638 14. Acknowledgements 1640 This document is the collaborative product of the authors and Tyson 1641 Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited 1642 from thoughtful discussion by Jim Amsden, Peter Carlson, Steve 1643 Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus 1644 Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David 1645 Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, 1646 Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, 1647 Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1648 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1649 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1650 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1651 members of the WebDAV working group. 1653 15. References 1655 15.1. Normative References 1657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1658 Requirement Levels", BCP 14, RFC 2119, March 1997. 1660 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1661 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1662 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1664 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1665 Resource Identifier (URI): Generic Syntax", STD 66, 1666 RFC 3986, January 2005. 1668 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1669 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1671 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1672 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1673 Edition)", W3C REC-xml-20081126, November 2008, 1674 . 1676 15.2. Informative References 1678 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1679 Whitehead, "Versioning Extensions to WebDAV (Web 1680 Distributed Authoring and Versioning)", RFC 3253, 1681 March 2002. 1683 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1684 Distributed Authoring and Versioning (WebDAV) Access 1685 Control Protocol", RFC 3744, May 2004. 1687 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1688 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1689 July 2005. 1691 Appendix A. Clarification to RFC2518bis' Usage of the term 'lock root' 1693 [RFC4918], Section 9.10.1 claims: 1695 A LOCK request to an existing resource will create a lock on the 1696 resource identified by the Request-URI, provided the resource is 1697 not already locked with a conflicting lock. The resource 1698 identified in the Request-URI becomes the root of the lock. 1700 This is incorrect in that it implies that the "lock root" is a 1701 resource, not a URL 1702 (). However, 1703 should a directly locked resource have multiple bindings, only the 1704 one used in the Request-URI of the LOCK request will be the protected 1705 from changes of clients not supplying the lock token. 1707 A correct description would be: 1709 A LOCK request to an existing resource will create a lock on the 1710 resource identified by the Request-URI, provided the resource is 1711 not already locked with a conflicting lock. The Request-URI 1712 becomes the root of the lock. 1714 Note that this change makes the description consistent with the 1715 definition of the DAV:lockroot XML element in Section 14.12 of 1716 [RFC4918]. 1718 The authors of this specification recommend that future revisions of 1719 [RFC4918] will update the description as suggested above. 1721 Appendix B. Change Log (to be removed by RFC Editor before publication) 1723 B.1. Since draft-ietf-webdav-bind-02 1725 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1726 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1727 resolution, but keep it open. Add issues "ED_references" and 1728 "4_507_status". Started work on index. Rename document to "Binding 1729 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1730 Rename "References" to "Normative References". Close issue 1731 "ED_references". Close issue "4_507_status". 1733 B.2. Since draft-ietf-webdav-bind-03 1735 Add and close issues "9.2_redirect_loops", "ED_authors" and 1736 "ED_updates". Add section about capability discovery (DAV header). 1737 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1738 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1739 "locking" and resolve as invalid. 1741 B.3. Since draft-ietf-webdav-bind-04 1743 Add and close issues "6_precondition_binding_allowed" and 1744 "6_lock_behaviour". Add mailing list and issues list pointers to 1745 front. 1747 B.4. Since draft-ietf-webdav-bind-05 1749 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1750 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1751 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1753 B.5. Since draft-ietf-webdav-bind-06 1755 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1756 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1758 B.6. Since draft-ietf-webdav-bind-07 1760 Add more index items (no change tracking). Add and resolve issues 1761 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1762 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1763 DTD fragment in section 3.3. Make spelling of "Request-URI" 1764 consistent. 1766 B.7. Since draft-ietf-webdav-bind-08 1768 Resolved editorial issues raised by Jim Whitehead in . 1770 Add and resolve issues "atomicity", "2_allow_destroy", 1771 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1772 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1773 "2.6_resource-id_vs_versions", "3.2_example" and 1774 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1775 and resolve "6_rebind_intro". 1777 B.8. Since draft-ietf-webdav-bind-09 1779 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1780 text. Add action item "3.1_uuids". Close issue 1781 "2.6_when_do_ids_change". Add and resolve issues 1782 "2.6_bindings_vs_properties" and "uri_draft_ref". 1784 B.9. Since draft-ietf-webdav-bind-10 1786 Resolve action item "3.1_uuids". Add and resolve issue 1787 "2.7_unlock_vs_bindings". Revisit issue 1788 "2.6_bindings_vs_properties", and remove the part of the sentence 1789 that speaks about live properties. Update "rfc2396bis" references to 1790 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1791 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1793 B.10. Since draft-ietf-webdav-bind-11 1795 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1796 live properties in Section 2.6. 1798 B.11. Since draft-ietf-webdav-bind-12 1800 Updated Author's address. Uppercase "Section" when referring to 1801 other documents. 1803 Updating from RFC2518 to RFC2518bis: 1805 o Remove own explanation of DTD syntax. 1807 o Remove own definition of precondition/postcondition. 1809 o Remove reference to broken RFC2518 language about DELETE and 1810 UNLOCK. 1812 o Remove own definition of DAV: request header. 1814 o Updated "Rationale for Distinguishing Bindings from URI Mappings" 1815 to reflect the changes in [draft-ietf-webdav-rfc2518bis], making 1816 proposals for more changes so that the issue can be closed (see 1817 also 1818 and ). 1821 B.12. Since draft-ietf-webdav-bind-13 1823 Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one 1824 incorrect section reference. Remove Section "Rationale for 1825 Distinguishing Bindings from URI Mappings" as 1826 [draft-ietf-webdav-rfc2518-bis] now uses the proper definition of 1827 collection state. Examples use application/xml instead of text/xml 1828 MIME type. 1830 Fix IANA section (there are no IANA considerations). 1832 B.13. Since draft-ietf-webdav-bind-14 1834 Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to 1835 4th edition. 1837 Markup ASCII art for box recognition (doesn't affect ASCII version). 1839 Identify Julian Reschke as Editor. 1841 B.14. Since draft-ietf-webdav-bind-15 1843 Fix typo in RFC2119 keywords section (sorry!). 1845 Update [draft-ietf-webdav-rfc2518-bis] to draft 17. 1847 Add and resolve issue "rfc2518bis-lock-root". 1849 B.15. Since draft-ietf-webdav-bind-16 1851 Add and resolve issue "iana-vs-http-status". 1853 B.16. Since draft-ietf-webdav-bind-17 1855 Update rfc2518bis reference to draft 18 (note that the bug reported 1856 in 1857 is still present). 1859 B.17. Since draft-ietf-webdav-bind-18 1861 Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918. 1863 B.18. Since draft-ietf-webdav-bind-19 1865 Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move- 1866 creating-cycles", "3.1-clarify-resource-id" and "4-precondition- 1867 language". 1869 B.19. Since draft-ietf-webdav-bind-20 1871 Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples. 1872 Replace RFC2518bis issue link by pointer to RFC Errata Page. 1874 Add issues "relation-to-deltav" and "status-codes". 1876 B.20. Since draft-ietf-webdav-bind-21 1878 Resolve issues "relation-to-deltav" and "status-codes". 1880 Add correct content length values to examples (no change bars). 1882 B.21. Since draft-ietf-webdav-bind-22 1884 Set "Intended Status" to "Experimental". 1886 Update XML reference to "Extensible Markup Language (XML) 1.0 (Fifth 1887 Edition)". 1889 Appendix C. Open issues (to be removed by RFC Editor prior to 1890 publication) 1892 C.1. edit 1894 Type: edit 1896 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1897 editorial fixes/enhancements. 1899 Index 1901 2 1902 208 Already Reported (status code) 31, 39 1904 5 1905 506 Loop Detected (status code) 34, 39 1907 B 1908 BIND method 21 1909 Marshalling 22 1910 Postconditions 23 1911 Preconditions 22 1912 Binding 7 1914 C 1915 Collection 7 1916 Condition Names 1917 DAV:bind-into-collection (pre) 22 1918 DAV:bind-source-exists (pre) 22 1919 DAV:binding-allowed (pre) 23 1920 DAV:binding-deleted (post) 25, 28 1921 DAV:can-overwrite (pre) 23, 27 1922 DAV:cross-server-binding (pre) 23, 27 1923 DAV:cycle-allowed (pre) 23, 27 1924 DAV:lock-deleted (post) 25, 28 1925 DAV:locked-overwrite-allowed (pre) 23 1926 DAV:locked-source-collection-update-allowed (pre) 28 1927 DAV:locked-update-allowed (pre) 23, 25, 27 1928 DAV:name-allowed (pre) 23, 27 1929 DAV:new-binding (post) 23, 28 1930 DAV:protected-source-url-deletion-allowed (pre) 28 1931 DAV:protected-url-deletion-allowed (pre) 25 1932 DAV:protected-url-modification-allowed (pre) 27 1933 DAV:rebind-from-collection (pre) 27 1934 DAV:rebind-source-exists (pre) 27 1935 DAV:unbind-from-collection (pre) 25 1936 DAV:unbind-source-exists (pre) 25 1938 D 1939 DAV header 1940 compliance class 'bind' 34 1941 DAV:bind-into-collection precondition 22 1942 DAV:bind-source-exists precondition 22 1943 DAV:binding-allowed precondition 23 1944 DAV:binding-deleted postcondition 25, 28 1945 DAV:can-overwrite precondition 23, 27 1946 DAV:cross-server-binding precondition 23, 27 1947 DAV:cycle-allowed precondition 23, 27 1948 DAV:lock-deleted postcondition 25, 28 1949 DAV:locked-overwrite-allowed precondition 23 1950 DAV:locked-source-collection-update-allowed precondition 28 1951 DAV:locked-update-allowed precondition 23, 25, 27 1952 DAV:name-allowed precondition 23, 27 1953 DAV:new-binding postcondition 23, 28 1954 DAV:parent-set property 20 1955 DAV:protected-source-url-deletion-allowed precondition 28 1956 DAV:protected-url-deletion-allowed precondition 25 1957 DAV:protected-url-modification-allowed precondition 27 1958 DAV:rebind-from-collection precondition 27 1959 DAV:rebind-source-exists precondition 27 1960 DAV:resource-id property 19 1961 DAV:unbind-from-collection precondition 25 1962 DAV:unbind-source-exists precondition 25 1964 I 1965 Internal Member URI 7 1967 M 1968 Methods 1969 BIND 21 1970 REBIND 26 1971 UNBIND 24 1973 P 1974 Path Segment 6 1975 Properties 1976 DAV:parent-set 20 1977 DAV:resource-id 19 1979 R 1980 REBIND method 26 1981 Marshalling 26 1982 Postconditions 28 1983 Preconditions 27 1985 S 1986 Status Codes 1987 208 Already Reported 31, 39 1988 506 Loop Detected 34, 39 1990 U 1991 UNBIND method 24 1992 Marshalling 24 1993 Postconditions 25 1994 Preconditions 25 1995 URI Mapping 6 1997 Authors' Addresses 1999 Geoffrey Clemm 2000 IBM 2001 20 Maguire Road 2002 Lexington, MA 02421 2004 Email: geoffrey.clemm@us.ibm.com 2006 Jason Crawford 2007 IBM Research 2008 P.O. Box 704 2009 Yorktown Heights, NY 10598 2011 Email: ccjason@us.ibm.com 2013 Julian F. Reschke (editor) 2014 greenbytes GmbH 2015 Hafenweg 16 2016 Muenster, NW 48155 2017 Germany 2019 Email: julian.reschke@greenbytes.de 2021 Jim Whitehead 2022 UC Santa Cruz, Dept. of Computer Science 2023 1156 High Street 2024 Santa Cruz, CA 95064 2026 Email: ejw@cse.ucsc.edu