idnits 2.17.1 draft-ietf-webdav-bind-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2087. 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 Copyright Line does not match the current year == Line 550 has weird spacing: '...| x.gif y.g...' == Line 572 has weird spacing: '...| x.gif y.g...' == Line 843 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2008) is 5657 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: Standards Track IBM Research 6 Expires: May 1, 2009 J. Reschke, Ed. 7 greenbytes 8 J. Whitehead 9 U.C. Santa Cruz 10 October 28, 2008 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-22 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 1, 2009. 40 Abstract 42 This specification defines bindings, and the BIND method for creating 43 multiple bindings to the same resource. Creating a new binding to a 44 resource causes at least one new URI to be mapped to that resource. 45 Servers are required to insure the integrity of any bindings that 46 they allow to be created. 48 Editorial Note (To be removed by RFC Editor before publication) 50 Please send comments to the Distributed Authoring and Versioning 51 (WebDAV) working group at , which may be 52 joined by sending a message with subject "subscribe" to 53 . Discussions of the WEBDAV 54 working group are archived at 55 . 57 lists 58 all registered issues since draft 02. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.2. Method Preconditions and Postconditions . . . . . . . . . 7 65 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 66 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8 67 2.1.1. Bind Loops . . . . . . . . . . . . . . . . . . . . . . 9 68 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 9 69 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10 70 2.3.1. Example: COPY with 'Depth: infinity' in Presence 71 of Bind Loops . . . . . . . . . . . . . . . . . . . . 12 72 2.3.2. Example: COPY with 'Depth: infinity' with Multiple 73 Bindings to a Leaf Resource . . . . . . . . . . . . . 14 74 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15 75 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15 76 2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 16 77 2.5.2. Example: MOVE Request causing a Bind Loop . . . . . . 16 78 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 18 79 2.7. Determining Whether Two Bindings Are to the Same 80 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 19 82 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 19 84 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 20 85 3.2.1. Example for DAV:parent-set Property . . . . . . . . . 20 86 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 24 88 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 89 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 26 90 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 26 91 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 28 92 6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 29 93 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31 94 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31 95 7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32 96 7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34 97 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34 98 8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34 99 8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34 100 8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34 101 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35 102 10. Relationship to Versioning Extensions to WebDAV . . . . . . . 35 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 104 11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 38 105 11.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 38 106 11.3. Bindings, and Denial of Service . . . . . . . . . . . . . 38 107 11.4. Private Locations May Be Revealed . . . . . . . . . . . . 38 108 11.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 38 109 12. Internationalization Considerations . . . . . . . . . . . . . 38 110 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 111 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 112 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 113 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 114 15.2. Informative References . . . . . . . . . . . . . . . . . . 40 115 Appendix A. Clarification to RFC2518bis' Usage of the term 116 'lock root' . . . . . . . . . . . . . . . . . . . . . 40 117 Appendix B. Change Log (to be removed by RFC Editor before 118 publication) . . . . . . . . . . . . . . . . . . . . 41 119 B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 41 120 B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 41 121 B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 41 122 B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 41 123 B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 41 124 B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 41 125 B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 42 126 B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 42 127 B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 42 128 B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 42 129 B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 42 130 B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 43 131 B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 43 132 B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 43 133 B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 43 134 B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 43 135 B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 44 136 B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 44 137 B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 44 138 B.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 44 139 Appendix C. Resolved issues (to be removed by RFC Editor 140 before publication) . . . . . . . . . . . . . . . . . 44 141 C.1. status-codes . . . . . . . . . . . . . . . . . . . . . . . 44 142 C.2. relation-to-deltav . . . . . . . . . . . . . . . . . . . . 45 144 Appendix D. Open issues (to be removed by RFC Editor prior to 145 publication) . . . . . . . . . . . . . . . . . . . . 45 146 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 147 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 149 Intellectual Property and Copyright Statements . . . . . . . . . . 49 151 1. Introduction 153 This specification extends the WebDAV Distributed Authoring Protocol 154 ([RFC4918]) to enable clients to create new access paths to existing 155 resources. This capability is useful for several reasons: 157 URIs of WebDAV-compliant resources are hierarchical and correspond to 158 a hierarchy of collections in resource space. The WebDAV Distributed 159 Authoring Protocol makes it possible to organize these resources into 160 hierarchies, placing them into groupings, known as collections, which 161 are more easily browsed and manipulated than a single flat 162 collection. However, hierarchies require categorization decisions 163 that locate resources at a single location in the hierarchy, a 164 drawback when a resource has multiple valid categories. For example, 165 in a hierarchy of vehicle descriptions containing collections for 166 cars and boats, a description of a combination car/boat vehicle could 167 belong in either collection. Ideally, the description should be 168 accessible from both. Allowing clients to create new URIs that 169 access the existing resource lets them put that resource into 170 multiple collections. 172 Hierarchies also make resource sharing more difficult, since 173 resources that have utility across many collections are still forced 174 into a single collection. For example, the mathematics department at 175 one university might create a collection of information on fractals 176 that contains bindings to some local resources, but also provides 177 access to some resources at other universities. For many reasons, it 178 may be undesirable to make physical copies of the shared resources on 179 the local server: to conserve disk space, to respect copyright 180 constraints, or to make any changes in the shared resources visible 181 automatically. Being able to create new access paths to existing 182 resources in other collections or even on other servers is useful for 183 this sort of case. 185 The BIND method defined here provides a mechanism for allowing 186 clients to create alternative access paths to existing WebDAV 187 resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to 188 work because there are mappings between URIs and resources. A method 189 is addressed to a URI, and the server follows the mapping from that 190 URI to a resource, applying the method to that resource. Multiple 191 URIs may be mapped to the same resource, but until now there has been 192 no way for clients to create additional URIs mapped to existing 193 resources. 195 BIND lets clients associate a new URI with an existing WebDAV 196 resource, and this URI can then be used to submit requests to the 197 resource. Since URIs of WebDAV resources are hierarchical, and 198 correspond to a hierarchy of collections in resource space, the BIND 199 method also has the effect of adding the resource to a collection. 200 As new URIs are associated with the resource, it appears in 201 additional collections. 203 A BIND request does not create a new resource, but simply makes 204 available a new URI for submitting requests to an existing resource. 205 The new URI is indistinguishable from any other URI when submitting a 206 request to a resource. Only one round trip is needed to submit a 207 request to the intended target. Servers are required to enforce the 208 integrity of the relationships between the new URIs and the resources 209 associated with them. Consequently, it may be very costly for 210 servers to support BIND requests that cross server boundaries. 212 This specification is organized as follows. Section 1.1 defines 213 terminology used in the rest of the specification, while Section 2 214 overviews bindings. Section 3 defines the new properties needed to 215 support multiple bindings to the same resource. Section 4 specifies 216 the BIND method, used to create multiple bindings to the same 217 resource. Section 5 specifies the UNBIND method, used to remove a 218 binding to a resource. Section 6 specifies the REBIND method, used 219 to move a binding to another collection. 221 1.1. Terminology 223 The terminology used here follows and extends that in the WebDAV 224 Distributed Authoring Protocol specification [RFC4918]. 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 This document uses XML DTD fragments ([XML]) as a notational 231 convention, using the rules defined in Section 17 of [RFC4918]. 233 URI Mapping 235 A relation between an absolute URI and a resource. For an 236 absolute URI U and the resource it identifies R, the URI mapping 237 can be thought of as (U => R). Since a resource can represent 238 items that are not network retrievable, as well as those that are, 239 it is possible for a resource to have zero, one, or many URI 240 mappings. Mapping a resource to an "http" scheme URI makes it 241 possible to submit HTTP protocol requests to the resource using 242 the URI. 244 Path Segment 245 Informally, the characters found between slashes ("/") in a URI. 246 Formally, as defined in Section 3.3 of [RFC3986]. 248 Binding 250 A relation between a single path segment (in a collection) and a 251 resource. A binding is part of the state of a collection. If two 252 different collections contain a binding between the same path 253 segment and the same resource, these are two distinct bindings. 254 So for a collection C, a path segment S, and a resource R, the 255 binding can be thought of as C:(S -> R). Bindings create URI 256 mappings, and hence allow requests to be sent to a single resource 257 from multiple locations in a URI namespace. For example, given a 258 collection C (accessible through the URI 259 http://www.example.com/CollX), a path segment S (equal to 260 "foo.html"), and a resource R, then creating the binding C: (S -> 261 R) makes it possible to use the URI 262 http://www.example.com/CollX/foo.html to access R. 264 Collection 266 A resource that contains, as part of its state, a set of bindings 267 that identify internal member resources. 269 Internal Member URI 271 The URI that identifies an internal member of a collection, and 272 that consists of the URI for the collection, followed by a slash 273 character ('/'), followed by the path segment of the binding for 274 that internal member. 276 1.2. Method Preconditions and Postconditions 278 See Section 16 of [RFC4918] for the definitions of "precondition" and 279 "postcondition". 281 2. Overview of Bindings 283 Bindings are part of the state of a collection. They define the 284 internal members of the collection, and the names of those internal 285 members. 287 Bindings are added and removed by a variety of existing HTTP methods. 288 A method that creates a new resource, such as PUT, COPY, and MKCOL, 289 adds a binding. A method that deletes a resource, such as DELETE, 290 removes a binding. A method that moves a resource (e.g. MOVE) both 291 adds a binding (in the destination collection) and removes a binding 292 (in the source collection). The BIND method introduced here provides 293 a mechanism for adding a second binding to an existing resource. 294 There is no difference between an initial binding added by PUT, COPY, 295 or MKCOL, and additional bindings added with BIND. 297 It would be very undesirable if one binding could be destroyed as a 298 side effect of operating on the resource through a different binding. 299 In particular, the removal of one binding to a resource (e.g. with a 300 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 301 e.g. by turning that binding into a dangling path segment. The 302 server MUST NOT reclaim system resources after removing one binding, 303 while other bindings to the resource remain. In other words, the 304 server MUST maintain the integrity of a binding. It is permissible, 305 however, for future method definitions (e.g., a DESTROY method) to 306 have semantics that explicitly remove all bindings and/or immediately 307 reclaim system resources. 309 2.1. Bindings to Collections 311 Creating a new binding to a collection makes each resource associated 312 with a binding in that collection accessible via a new URI, and thus 313 creates new URI mappings to those resources but no new bindings. 315 For example, suppose a new binding CollY is created for collection C1 316 in the figure below. It immediately becomes possible to access 317 resource R1 using the URI /CollY/x.gif and to access resource R2 318 using the URI /CollY/y.jpg, but no new bindings for these child 319 resources were created. This is because bindings are part of the 320 state of a collection, and associate a URI that is relative to that 321 collection with its target resource. No change to the bindings in 322 Collection C1 is needed to make its children accessible using /CollY/ 323 x.gif and /CollY/y.jpg. 325 +-------------------------+ 326 | Root Collection | 327 | bindings: | 328 | CollX CollY | 329 +-------------------------+ 330 | / 331 | / 332 | / 333 +------------------+ 334 | Collection C1 | 335 | bindings: | 336 | x.gif y.jpg | 337 +------------------+ 338 | \ 339 | \ 340 | \ 341 +-------------+ +-------------+ 342 | Resource R1 | | Resource R2 | 343 +-------------+ +-------------+ 345 2.1.1. Bind Loops 347 Bindings to collections can result in loops ("cycles"), which servers 348 MUST detect when processing "Depth: infinity" requests. It is 349 sometimes possible to complete an operation in spite of the presence 350 of a loop. For instance, a PROPFIND can still succeed if the server 351 uses the new status code 208 (Already Reported) defined in 352 Section 7.1. 354 However, the 506 (Loop Detected) status code is defined in 355 Section 7.2 for use in contexts where an operation is terminated 356 because a loop was encountered. 358 Support for loops is OPTIONAL: servers MAY reject requests that would 359 lead to the creation of a bind loop (see DAV:cycle-allowed 360 precondition defined in Section 4). 362 2.2. URI Mappings Created by a new Binding 364 Suppose a binding from "Binding-Name" to resource R is to be added to 365 a collection, C. Then if C-MAP is the set of URIs that were mapped to 366 C before the BIND request, then for each URI "C-URI" in C-MAP, the 367 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 368 request. 370 For example, if a binding from "foo.html" to R is added to a 371 collection C, and if the following URIs are mapped to C: 373 http://www.example.com/A/1/ 374 http://example.com/A/one/ 376 then the following new mappings to R are introduced: 378 http://www.example.com/A/1/foo.html 379 http://example.com/A/one/foo.html 381 Note that if R is a collection, additional URI mappings are created 382 to the descendents of R. Also, note that if a binding is made in 383 collection C to C itself (or to a parent of C), an infinite number of 384 mappings are introduced. 386 For example, if a binding from "myself" to C is then added to C, the 387 following infinite number of additional mappings to C are introduced: 389 http://www.example.com/A/1/myself 390 http://www.example.com/A/1/myself/myself 391 ... 393 and the following infinite number of additional mappings to R are 394 introduced: 396 http://www.example.com/A/1/myself/foo.html 397 http://www.example.com/A/1/myself/myself/foo.html 398 ... 400 2.3. COPY and Bindings 402 As defined in Section 9.8 of [RFC4918], COPY causes the resource 403 identified by the Request-URI to be duplicated, and makes the new 404 resource accessible using the URI specified in the Destination 405 header. Upon successful completion of a COPY, a new binding is 406 created between the last path segment of the Destination header, and 407 the destination resource. The new binding is added to its parent 408 collection, identified by the Destination header minus its final 409 segment. 411 The following figure shows an example: Suppose that a COPY is issued 412 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 413 with the Destination header set to URI-X. After successful 414 completion of the COPY operation, resource R is duplicated to create 415 resource R', and a new binding has been created which creates at 416 least the URI mapping between URI-X and the new resource (although 417 other URI mappings may also have been created). 419 URI-1 URI-2 URI-3 URI-X 420 | | | | 421 | | | <---- URI Mappings ----> | 422 | | | | 423 +---------------------+ +------------------------+ 424 | Resource R | | Resource R' | 425 +---------------------+ +------------------------+ 427 It might be thought that a COPY request with "Depth: 0" on a 428 collection would duplicate its bindings, since bindings are part of 429 the collection's state. This is not the case, however. The 430 definition of Depth in [RFC4918] makes it clear that a "Depth: 0" 431 request does not apply to a collection's members. Consequently, a 432 COPY with "Depth: 0" does not duplicate the bindings contained by the 433 collection. 435 If a COPY request causes an existing resource to be updated, the 436 bindings to that resource MUST be unaffected by the COPY request. 437 Using the preceding example, suppose that a COPY request is issued to 438 URI-X for resource R', with the Destination header set to URI-2. The 439 content and dead properties of resource R would be updated to be a 440 copy of those of resource R', but the mappings from URI-1, URI-2, and 441 URI-3 to resource R remain unaffected. If because of multiple 442 bindings to a resource, more than one source resource updates a 443 single destination resource, the order of the updates is server 444 defined. 446 If a COPY request would cause a new resource to be created as a copy 447 of an existing resource, and that COPY request has already created a 448 copy of that existing resource, the COPY request instead creates 449 another binding to the previous copy, instead of creating a new 450 resource. 452 2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops 454 As an example of how COPY with Depth infinity would work in the 455 presence of bindings, consider the following collection: 457 +------------------+ 458 | Root Collection | 459 | bindings: | 460 | CollX | 461 +------------------+ 462 | 463 | 464 +-------------------------------+ 465 | Collection C1 |<-------+ 466 | bindings: | | 467 | x.gif CollY | | 468 +-------------------------------+ | 469 | \ (creates loop) | 470 | \ | 471 +-------------+ +------------------+ | 472 | Resource R1 | | Collection C2 | | 473 +-------------+ | bindings: | | 474 | y.gif CollZ | | 475 +------------------+ | 476 | | | 477 | +--------+ 478 | 479 +-------------+ 480 | Resource R2 | 481 +-------------+ 483 If a COPY with Depth infinity is submitted to /CollX, with 484 destination of /CollA, the outcome of the copy operation is: 486 +------------------+ 487 | Root Collection | 488 | bindings: | 489 | CollX CollA | 490 +------------------+ 491 | | 492 | +---------------------------+ 493 | | 494 +-------------------+ | 495 | Collection C1 |<------------------+ | 496 | bindings: | | | 497 | x.gif CollY | | | 498 +-------------------+ | | 499 | \ (creates loop) | | 500 | \ | | 501 +-------------+ +-----------------+ | | 502 | Resource R1 | | Collection C2 | | | 503 +-------------+ | bindings: | | | 504 | y.gif CollZ | | | 505 +-----------------+ | | 506 | | | | 507 | +-------+ | 508 | | 509 +-------------+ | 510 | Resource R2 | | 511 +-------------+ | 512 | 513 +-------------------------------+ 514 | 515 +-------------------+ 516 | Collection C3 |<------------------+ 517 | bindings: | | 518 | x.gif CollY | | 519 +-------------------+ | 520 | \ (creates loop) | 521 | \ | 522 +-------------+ +-----------------+ | 523 | Resource R3 | | Collection C4 | | 524 +-------------+ | bindings: | | 525 | y.gif CollZ | | 526 +-----------------+ | 527 | | | 528 | +-------+ 529 | 530 +-------------+ 531 | Resource R4 | 532 +-------------+ 534 2.3.2. Example: COPY with 'Depth: infinity' with Multiple Bindings to a 535 Leaf Resource 537 Given the following collection hierarchy: 539 +------------------+ 540 | Root Collection | 541 | bindings: | 542 | CollX | 543 +------------------+ 544 | 545 | 546 | 547 +----------------+ 548 | Collection C1 | 549 | bindings: | 550 | x.gif y.gif | 551 +----------------+ 552 | | 553 | | 554 +-------------+ 555 | Resource R1 | 556 +-------------+ 558 A COPY of /CollX with Depth infinity to /CollY results in the 559 following collection hierarchy: 561 +------------------+ 562 | Root Collection | 563 | bindings: | 564 | CollX CollY | 565 +------------------+ 566 | \ 567 | \ 568 | \ 569 +----------------+ +-----------------+ 570 | Collection C1 | | Collection C2 | 571 | bindings: | | bindings: | 572 | x.gif y.gif | | x.gif y.gif | 573 +----------------+ +-----------------+ 574 | | | | 575 | | | | 576 +-------------+ +-------------+ 577 | Resource R1 | | Resource R2 | 578 +-------------+ +-------------+ 580 2.4. DELETE and Bindings 582 When there are multiple bindings to a resource, a DELETE applied to 583 that resource MUST NOT remove any bindings to that resource other 584 than the one identified by the Request-URI. For example, suppose the 585 collection identified by the URI "/a" has a binding named "x" to a 586 resource R, and another collection identified by "/b" has a binding 587 named "y" to the same resource R. Then a DELETE applied to "/a/x" 588 removes the binding named "x" from "/a" but MUST NOT remove the 589 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 590 to identify the resource R). 592 When DELETE is applied to a collection, it MUST NOT modify the 593 membership of any other collection that is not itself a member of the 594 collection being deleted. For example, if both "/a/.../x" and 595 "/b/.../y" identify the same collection, C, then applying DELETE to 596 "/a" must not delete an internal member from C or from any other 597 collection that is a member of C, because that would modify the 598 membership of "/b". 600 If a collection supports the UNBIND method (see Section 5), a DELETE 601 of an internal member of a collection MAY be implemented as an UNBIND 602 request. In this case, applying DELETE to a Request-URI has the 603 effect of removing the binding identified by the final segment of the 604 Request-URI from the collection identified by the Request-URI minus 605 its final segment. Although [RFC4918] allows a DELETE to be a non- 606 atomic operation, when the DELETE operation is implemented as an 607 UNBIND, the operation is atomic. In particular, a DELETE on a 608 hierarchy of resources is simply the removal of a binding to the 609 collection identified by the Request-URI. 611 2.5. MOVE and Bindings 613 When MOVE is applied to a resource, the other bindings to that 614 resource MUST be unaffected, and if the resource being moved is a 615 collection, the bindings to any members of that collection MUST be 616 unaffected. Also, if MOVE is used with Overwrite:T to delete an 617 existing resource, the constraints specified for DELETE apply. 619 If the destination collection of a MOVE request supports the REBIND 620 method (see Section 6), a MOVE of a resource into that collection MAY 621 be implemented as a REBIND request. Although [RFC4918] allows a MOVE 622 to be a non-atomic operation, when the MOVE operation is implemented 623 as a REBIND, the operation is atomic. In particular, applying a MOVE 624 to a Request-URI and a Destination URI has the effect of removing a 625 binding to a resource (at the Request-URI), and creating a new 626 binding to that resource (at the Destination URI). Even when the 627 Request-URI identifies a collection, the MOVE operation involves only 628 removing one binding to that collection and adding another. 630 2.5.1. Example: Simple MOVE 632 As an example, suppose that a MOVE is issued to URI-3 for resource R 633 below (which is also mapped to URI-1 and URI-2), with the Destination 634 header set to URI-X. After successful completion of the MOVE 635 operation, a new binding has been created which creates the URI 636 mapping between URI-X and resource R. The binding corresponding to 637 the final segment of URI-3 has been removed, which also causes the 638 URI mapping between URI-3 and R to be removed. If resource R were a 639 collection, old URI-3 based mappings to members of R would have been 640 removed, and new URI-X based mappings to members of R would have been 641 created. 643 >> Before Request: 645 URI-1 URI-2 URI-3 646 | | | 647 | | | <---- URI Mappings 648 | | | 649 +---------------------+ 650 | Resource R | 651 +---------------------+ 653 >> After Request: 655 URI-1 URI-2 URI-X 656 | | | 657 | | | <---- URI Mappings 658 | | | 659 +---------------------+ 660 | Resource R | 661 +---------------------+ 663 2.5.2. Example: MOVE Request causing a Bind Loop 665 Note that in the presence of collection bindings, a MOVE request can 666 cause the creating of a bind loop. 668 Consider a the top level collections C1 and C2 with URIs "/CollW/" 669 and "/CollX/". C1 also contains an additional binding named "CollY" 670 to C2: 672 +------------------+ 673 | Root Collection | 674 | bindings: | 675 | CollW CollX | 676 +------------------+ 677 | | 678 | | 679 +------------------+ | 680 | Collection C1 | | 681 | bindings: | | 682 | CollY | | 683 +------------------+ | 684 | | 685 | | 686 +------------------+ 687 | Collection C2 | 688 | | 689 | | 690 +------------------+ 692 In this case, the MOVE request below would cause a bind loop: 694 >> Request: 696 MOVE /CollW HTTP/1.1 697 Host: example.com 698 Destination: /CollX/CollZ 699 If the request succeeded, the resulting state would be: 701 +------------------+ 702 | Root Collection | 703 | bindings: | 704 | CollX | 705 +------------------+ 706 | 707 | 708 +------------------+ | 709 | Collection C1 | | 710 +----> | bindings: | | 711 | | CollY | | 712 | +------------------+ | 713 | | | 714 | | | 715 | +------------------+ 716 | | Collection C2 | 717 | | bindings: | 718 | | CollZ | 719 | +------------------+ 720 | | 721 | | 722 +-------------------+ 724 2.6. PROPFIND and Bindings 726 Consistent with [RFC4918], the value of a dead property MUST be 727 independent of the number of bindings to its host resource or of the 728 path submitted to PROPFIND. On the other hand, the behaviour for 729 each live property depends on its individual definition (for example, 730 see [RFC3744], Section 5, paragraph 2). 732 2.7. Determining Whether Two Bindings Are to the Same Resource 734 It is useful to have some way of determining whether two bindings are 735 to the same resource. Two resources might have identical contents 736 and properties, but not be the same resource (e.g. an update to one 737 resource does not affect the other resource). 739 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 740 resource identifier, which MUST be unique across all resources for 741 all time. If the values of DAV:resource-id returned by PROPFIND 742 requests through two bindings are identical character by character, 743 the client can be assured that the two bindings are to the same 744 resource. 746 The DAV:resource-id property is created, and its value assigned, when 747 the resource is created. The value of DAV:resource-id MUST NOT be 748 changed. Even after the resource is no longer accessible through any 749 URI, that value MUST NOT be reassigned to another resource's DAV: 750 resource-id property. 752 Any method that creates a new resource MUST assign a new, unique 753 value to its DAV:resource-id property. For example, a PUT applied to 754 a null resource, COPY (when not overwriting an existing target) and 755 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 756 to the DAV:resource-id property of the new resource they create. 758 On the other hand, any method that affects an existing resource must 759 not change the value of its DAV:resource-id property. Specifically, 760 a PUT or a COPY that updates an existing resource must not change the 761 value of its DAV:resource-id property. A REBIND, since it does not 762 create a new resource, but only changes the location of an existing 763 resource, must not change the value of the DAV:resource-id property. 765 2.8. Discovering the Bindings to a Resource 767 An OPTIONAL DAV:parent-set property on a resource provides a list of 768 the bindings that associate a collection and a URI segment with that 769 resource. If the DAV:parent-set property exists on a given resource, 770 it MUST contain a complete list of all bindings to that resource that 771 the client is authorized to see. When deciding whether to support 772 the DAV:parent-set property, server implementers / administrators 773 should balance the benefits it provides against the cost of 774 maintaining the property and the security risks enumerated in 775 Sections 11.4 and 11.5. 777 3. Properties 779 The bind feature introduces the properties defined below. 781 A DAV:allprop PROPFIND request SHOULD NOT return any of the 782 properties defined by this document. This allows a binding server to 783 perform efficiently when a naive client, which does not understand 784 the cost of asking a server to compute all possible live properties, 785 issues a DAV:allprop PROPFIND request. 787 3.1. DAV:resource-id Property 789 The DAV:resource-id property is a REQUIRED property that enables 790 clients to determine whether two bindings are to the same resource. 791 The value of DAV:resource-id is a URI, and may use any registered URI 792 scheme that guarantees the uniqueness of the value across all 793 resources for all time (e.g. the urn:uuid: URN namespace defined in 795 [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]). 797 799 Note: by definition, the URI specified in the DAV:resource-id 800 property always is an alternate URI for that resource. 802 3.2. DAV:parent-set Property 804 The DAV:parent-set property is an OPTIONAL property that enables 805 clients to discover what collections contain a binding to this 806 resource (i.e. what collections have that resource as an internal 807 member). It contains an href/segment pair for each collection that 808 has a binding to the resource. The href identifies the collection, 809 and the segment identifies the binding name of that resource in that 810 collection. 812 A given collection MUST appear only once in the DAV:parent-set for 813 any given binding, even if there are multiple URI mappings to that 814 collection. 816 817 818 819 822 3.2.1. Example for DAV:parent-set Property 824 For example, if collection C1 is mapped to both /CollX and /CollY, 825 and C1 contains a binding named "x.gif" to a resource R1, then either 826 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 827 of R1, but not both. But if C1 also had a binding named "y.gif" to 828 R1, then there would be two entries for C1 in the DAV:binding-set of 829 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 830 both [/CollY, x.gif] and [/CollY, y.gif]). 832 +-------------------------+ 833 | Root Collection | 834 | bindings: | 835 | CollX CollY | 836 +-------------------------+ 837 | / 838 | / 839 | / 840 +-----------------+ 841 | Collection C1 | 842 | bindings: | 843 | x.gif y.gif | 844 +-----------------+ 845 | | 846 | | 847 | | 848 +--------------+ 849 | Resource R1 | 850 +--------------+ 852 In this case, one possible value for DAV:parent-set property on 853 "/CollX/x.gif" would be: 855 856 857 /CollX 858 x.gif 859 860 861 /CollX 862 y.gif 863 864 866 4. BIND Method 868 The BIND method modifies the collection identified by the Request- 869 URI, by adding a new binding from the segment specified in the BIND 870 body to the resource identified in the BIND body. 872 If a server cannot guarantee the integrity of the binding, the BIND 873 request MUST fail. Note that it is especially difficult to maintain 874 the integrity of cross-server bindings. Unless the server where the 875 resource resides knows about all bindings on all servers to that 876 resource, it may unwittingly destroy the resource or make it 877 inaccessible without notifying another server that manages a binding 878 to the resource. For example, if server A permits creation of a 879 binding to a resource on server B, server A must notify server B 880 about its binding and must have an agreement with B that B will not 881 destroy the resource while A's binding exists. Otherwise server B 882 may receive a DELETE request that it thinks removes the last binding 883 to the resource and destroy the resource while A's binding still 884 exists. The precondition DAV:cross-server-binding is defined below 885 for cases where servers fail cross-server BIND requests because they 886 cannot guarantee the integrity of cross-server bindings. 888 By default, if there already is a binding for the specified segment 889 in the collection, the new binding replaces the existing binding. 890 This default binding replacement behavior can be overridden using the 891 Overwrite header defined in Section 10.6 of [RFC4918]. 893 If a BIND request fails, the server state preceding the request MUST 894 be restored. This method is unsafe and idempotent (see [RFC2616], 895 Section 9.1). 897 Marshalling: 899 The request MAY include an Overwrite header. 901 The request body MUST be a DAV:bind XML element. 903 905 If the request succeeds, the server MUST return 201 (Created) when 906 a new binding was created and 200 (OK) or 204 (No Content) when an 907 existing binding was replaced. 909 If a response body for a successful request is included, it MUST 910 be a DAV:bind-response XML element. Note that this document does 911 not define any elements for the BIND response body, but the DAV: 912 bind-response element is defined to ensure interoperability 913 between future extensions that do define elements for the BIND 914 response body. 916 918 Preconditions: 920 (DAV:bind-into-collection): The Request-URI MUST identify a 921 collection. 923 (DAV:bind-source-exists): The DAV:href element MUST identify a 924 resource. 926 (DAV:binding-allowed): The resource identified by the DAV:href 927 supports multiple bindings to it. 929 (DAV:cross-server-binding): If the resource identified by the DAV: 930 href element in the request body is on another server from the 931 collection identified by the Request-URI, the server MUST support 932 cross-server bindings (servers that do not support cross-server 933 bindings can use this condition code to signal the client exactly 934 why the request failed). 936 (DAV:name-allowed): The name specified by the DAV:segment is 937 available for use as a new binding name. 939 (DAV:can-overwrite): If the collection already contains a binding 940 with the specified path segment, and if an Overwrite header is 941 included, the value of the Overwrite header MUST be "T". 943 (DAV:cycle-allowed): If the DAV:href element identifies a 944 collection, and if the Request-URI identifies a collection that is 945 a member of that collection, the server MUST support cycles in the 946 URI namespace (servers that do not support cycles can use this 947 condition code to signal the client exactly why the request 948 failed). 950 (DAV:locked-update-allowed): If the collection identified by the 951 Request-URI is write-locked, then the appropriate token MUST be 952 specified in an If request header. 954 (DAV:locked-overwrite-allowed): If the collection already contains 955 a binding with the specified path segment, and if that binding is 956 protected by a write-lock, then the appropriate token MUST be 957 specified in an If request header. 959 Postconditions: 961 (DAV:new-binding): The collection MUST have a binding that maps 962 the segment specified in the DAV:segment element in the request 963 body, to the resource identified by the DAV:href element in the 964 request body. 966 4.1. Example: BIND 968 >> Request: 970 BIND /CollY HTTP/1.1 971 Host: www.example.com 972 Content-Type: application/xml; charset="utf-8" 973 Content-Length: 172 975 976 977 bar.html 978 http://www.example.com/CollX/foo.html 979 981 >> Response: 983 HTTP/1.1 201 Created 985 Location: http://www.example.com/CollY/bar.html 987 The server added a new binding to the collection, 988 "http://www.example.com/CollY", associating "bar.html" with the 989 resource identified by the URI 990 "http://www.example.com/CollX/foo.html". Clients can now use the URI 991 "http://www.example.com/CollY/bar.html" to submit requests to that 992 resource. 994 5. UNBIND Method 996 The UNBIND method modifies the collection identified by the Request- 997 URI, by removing the binding identified by the segment specified in 998 the UNBIND body. 1000 Once a resource is unreachable by any URI mapping, the server MAY 1001 reclaim system resources associated with that resource. If UNBIND 1002 removes a binding to a resource, but there remain URI mappings to 1003 that resource, the server MUST NOT reclaim system resources 1004 associated with the resource. 1006 If an UNBIND request fails, the server state preceding the request 1007 MUST be restored. This method is unsafe and idempotent (see 1008 [RFC2616], Section 9.1). 1010 Marshalling: 1012 The request body MUST be a DAV:unbind XML element. 1014 1016 If the request succeeds, the server MUST return 200 (OK) or 204 1017 (No Content) when the binding was successfully deleted. 1019 If a response body for a successful request is included, it MUST 1020 be a DAV:unbind-response XML element. Note that this document 1021 does not define any elements for the UNBIND response body, but the 1022 DAV:unbind-response element is defined to ensure interoperability 1023 between future extensions that do define elements for the UNBIND 1024 response body. 1026 1028 Preconditions: 1030 (DAV:unbind-from-collection): The Request-URI MUST identify a 1031 collection. 1033 (DAV:unbind-source-exists): The DAV:segment element MUST identify 1034 a binding in the collection identified by the Request-URI. 1036 (DAV:locked-update-allowed): If the collection identified by the 1037 Request-URI is write-locked, then the appropriate token MUST be 1038 specified in the request. 1040 (DAV:protected-url-deletion-allowed): If the binding identified by 1041 the segment is protected by a write-lock, then the appropriate 1042 token MUST be specified in the request. 1044 Postconditions: 1046 (DAV:binding-deleted): The collection MUST NOT have a binding for 1047 the segment specified in the DAV:segment element in the request 1048 body. 1050 (DAV:lock-deleted): If the internal member URI of the binding 1051 specified by the Request-URI and the DAV:segment element in the 1052 request body was protected by a write-lock at the time of the 1053 request, that write-lock must have been deleted by the request. 1055 5.1. Example: UNBIND 1057 >> Request: 1059 UNBIND /CollX HTTP/1.1 1060 Host: www.example.com 1061 Content-Type: application/xml; charset="utf-8" 1062 Content-Length: 117 1064 1065 1066 foo.html 1067 1069 >> Response: 1071 HTTP/1.1 200 OK 1073 The server removed the binding named "foo.html" from the collection, 1074 "http://www.example.com/CollX". A request to the resource named 1075 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1076 response. 1078 6. REBIND Method 1080 The REBIND method removes a binding to a resource from a collection, 1081 and adds a binding to that resource into the collection identified by 1082 the Request-URI. The request body specifies the binding to be added 1083 (segment) and the old binding to be removed (href). It is 1084 effectively an atomic form of a MOVE request, and MUST be treated the 1085 same way as MOVE for the purpose of determining access permissions. 1087 If a REBIND request fails, the server state preceding the request 1088 MUST be restored. This method is unsafe and idempotent (see 1089 [RFC2616], Section 9.1). 1091 Marshalling: 1093 The request MAY include an Overwrite header. 1095 The request body MUST be a DAV:rebind XML element. 1097 1099 If the request succeeds, the server MUST return 201 (Created) when 1100 a new binding was created and 200 (OK) or 204 (No Content) when an 1101 existing binding was replaced. 1103 If a response body for a successful request is included, it MUST 1104 be a DAV:rebind-response XML element. Note that this document 1105 does not define any elements for the REBIND response body, but the 1106 DAV:rebind-response element is defined to ensure interoperability 1107 between future extensions that do define elements for the REBIND 1108 response body. 1110 1112 Preconditions: 1114 (DAV:rebind-into-collection): The Request-URI MUST identify a 1115 collection. 1117 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1118 resource. 1120 (DAV:cross-server-binding): If the resource identified by the DAV: 1121 href element in the request body is on another server from the 1122 collection identified by the Request-URI, the server MUST support 1123 cross-server bindings (servers that do not support cross-server 1124 bindings can use this condition code to signal the client exactly 1125 why the request failed). 1127 (DAV:name-allowed): The name specified by the DAV:segment is 1128 available for use as a new binding name. 1130 (DAV:can-overwrite): If the collection already contains a binding 1131 with the specified path segment, and if an Overwrite header is 1132 included, the value of the Overwrite header MUST be "T". 1134 (DAV:cycle-allowed): If the DAV:href element identifies a 1135 collection, and if the Request-URI identifies a collection that is 1136 a member of that collection, the server MUST support cycles in the 1137 URI namespace (servers that do not support cycles can use this 1138 condition code to signal the client exactly why the request 1139 failed). 1141 (DAV:locked-update-allowed): If the collection identified by the 1142 Request-URI is write-locked, then the appropriate token MUST be 1143 specified in the request. 1145 (DAV:protected-url-modification-allowed): If the collection 1146 identified by the Request-URI already contains a binding with the 1147 specified path segment, and if that binding is protected by a 1148 write-lock, then the appropriate token MUST be specified in the 1149 request. 1151 (DAV:locked-source-collection-update-allowed): If the collection 1152 identified by the parent collection prefix of the DAV:href URI is 1153 write-locked, then the appropriate token MUST be specified in the 1154 request. 1156 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1157 is protected by a write lock, then the appropriate token MUST be 1158 specified in the request. 1160 Postconditions: 1162 (DAV:new-binding): The collection MUST have a binding that maps 1163 the segment specified in the DAV:segment element in the request 1164 body, to the resource that was identified by the DAV:href element 1165 in the request body. 1167 (DAV:binding-deleted): The URL specified in the DAV:href element 1168 in the request body MUST NOT be mapped to a resource. 1170 (DAV:lock-deleted): If the URL specified in the DAV:href element 1171 in the request body was protected by a write-lock at the time of 1172 the request, that write-lock must have been deleted by the 1173 request. 1175 6.1. Example: REBIND 1177 >> Request: 1179 REBIND /CollX HTTP/1.1 1180 Host: www.example.com 1181 Content-Type: application/xml; charset="utf-8" 1182 Content-Length: 176 1184 1185 1186 foo.html 1187 http://www.example.com/CollY/bar.html 1188 1190 >> Response: 1192 HTTP/1.1 200 OK 1194 The server added a new binding to the collection, 1195 "http://www.example.com/CollX", associating "foo.html" with the 1196 resource identified by the URI 1197 "http://www.example.com/CollY/bar.html", and removes the binding 1198 named "bar.html" from the collection identified by the URI 1199 "http://www.example.com/CollY". Clients can now use the URI 1200 "http://www.example.com/CollX/foo.html" to submit requests to that 1201 resource, and requests on the URI 1202 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1203 Found) response. 1205 6.2. Example: REBIND in Presence of Locks and Bind Loops 1207 To illustrate the effects of locks and bind loops on a REBIND 1208 operation, consider the following collection: 1210 +------------------+ 1211 | Root Collection | 1212 | bindings: | 1213 | CollW | 1214 +------------------+ 1215 | 1216 | 1217 | 1218 +-------------------------------+ 1219 | Collection C1 |<--------+ 1220 | LOCKED infinity | | 1221 | (lock token L1) | | 1222 | bindings: | | 1223 | CollX CollY | | 1224 +-------------------------------+ | 1225 | | | 1226 | | (creates loop) | 1227 | | | 1228 +-----------------+ +------------------+ | 1229 | Collection C2 | | Collection C3 | | 1230 | (inherit lock) | | (inherit lock) | | 1231 | (lock token L1) | | (lock token L1) | | 1232 | bindings: | | bindings: | | 1233 | {none} | | y.gif CollZ | | 1234 +-----------------+ +------------------+ | 1235 | | | 1236 | +-----+ 1237 | 1238 +---------------------------+ 1239 | Resource R2 | 1240 | (lock inherited from C1) | 1241 | (lock token L1) | 1242 +---------------------------+ 1244 (where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1246 Note that the binding between CollZ and C1 creates a loop in the 1247 containment hierarchy. Servers are not required to support such 1248 loops, though the server in this example does. 1250 The REBIND request below will remove the segment "CollZ" from C3 and 1251 add a new binding from "CollA" to the collection C2. 1253 REBIND /CollW/CollX HTTP/1.1 1254 Host: www.example.com 1255 If: () 1256 Content-Type: application/xml; charset="utf-8" 1257 Content-Length: 152 1259 1260 1261 CollA 1262 /CollW/CollY/CollZ 1263 1264 The outcome of the REBIND operation is: 1266 +------------------+ 1267 | Root Collection | 1268 | bindings: | 1269 | CollW | 1270 +------------------+ 1271 | 1272 | 1273 | 1274 +-------------------------------+ 1275 | Collection C1 | 1276 | LOCKED infinity | 1277 | (lock token L1) | 1278 | bindings: | 1279 | CollX CollY | 1280 +-------------------------------+ 1281 | ^ | 1282 | | | 1283 +-----------------+ | +------------------+ 1284 | Collection C2 | | | Collection C3 | 1285 |(inherited lock) | | | (inherited lock) | 1286 |(lock token L1) | | | (lock token L1) | 1287 | bindings: | | | bindings: | 1288 | CollA | | | y.gif | 1289 +-----------------+ | +------------------+ 1290 | | | 1291 +---------------+ | 1292 (creates loop) | 1293 +---------------------------+ 1294 | Resource R2 | 1295 | (inherited lock from C1) | 1296 | (lock token L1) | 1297 +---------------------------+ 1299 7. Additional Status Codes 1301 7.1. 208 Already Reported 1303 The 208 (Already Reported) status code can be used inside a DAV: 1304 propstat response element to avoid enumerating the internal members 1305 of multiple bindings to the same collection repeatedly. For each 1306 binding to a collection inside the request's scope, only one will be 1307 reported with a 200 status, while subsequent DAV:response elements 1308 for all other bindings will use the 208 status, and no DAV:response 1309 elements for their descendants are included. 1311 Note that the 208 status will only occur for "Depth: infinity" 1312 requests, and that it is of particular importance when the multiple 1313 collection bindings cause a bind loop as discussed in Section 2.2. 1315 A client can request the DAV:resource-id property in a PROPFIND 1316 request to guarantee that they can accurately reconstruct the binding 1317 structure of a collection with multiple bindings to a single 1318 resource. 1320 For backward compatibility with clients not aware of the 208 status 1321 code appearing in multistatus response bodies, it SHOULD NOT be used 1322 unless the client has signalled support for this specification using 1323 the "DAV" request header (see Section 8.2). Instead, a 506 status 1324 should be returned when a binding loop is discovered. This allows 1325 the server to return the 506 as the top level return status, if it 1326 discovers it before it started the response, or in the middle of a 1327 multistatus, if it discovers it in the middle of streaming out a 1328 multistatus response. 1330 7.1.1. Example: PROPFIND by Bind-Aware Client 1332 For example, consider a PROPFIND request on /Coll (bound to 1333 collection C), where the members of /Coll are /Coll/Foo (bound to 1334 resource R) and /Coll/Bar (bound to collection C). 1336 >> Request: 1338 PROPFIND /Coll/ HTTP/1.1 1339 Host: www.example.com 1340 Depth: infinity 1341 DAV: bind 1342 Content-Type: application/xml; charset="utf-8" 1343 Content-Length: 152 1345 1346 1347 1348 1349 1350 1351 1353 >> Response: 1355 HTTP/1.1 207 Multi-Status 1356 Content-Type: application/xml; charset="utf-8" 1357 Content-Length: 1241 1359 1360 1361 1362 http://www.example.com/Coll/ 1363 1364 1365 Loop Demo 1366 1367 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1369 1370 1371 HTTP/1.1 200 OK 1372 1373 1374 1375 http://www.example.com/Coll/Foo 1376 1377 1378 Bird Inventory 1379 1380 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1382 1383 1384 HTTP/1.1 200 OK 1385 1386 1387 1388 http://www.example.com/Coll/Bar 1389 1390 1391 Loop Demo 1392 1393 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1395 1396 1397 HTTP/1.1 208 Already Reported 1398 1399 1400 1402 7.1.2. Example: PROPFIND by Non-Bind-Aware Client 1404 In this example, the client isn't aware of the 208 status code 1405 introduced by this specification. As the "Depth: infinity" PROPFIND 1406 request would cause a loop condition, the whole request is rejected 1407 with a 506 status. 1409 >> Request: 1411 PROPFIND /Coll/ HTTP/1.1 1412 Host: www.example.com 1413 Depth: infinity 1414 Content-Type: application/xml; charset="utf-8" 1415 Content-Length: 125 1417 1418 1419 1420 1422 >> Response: 1424 HTTP/1.1 506 Loop Detected 1426 7.2. 506 Loop Detected 1428 The 506 (Loop Detected) status code indicates that the server 1429 terminated an operation because it encountered an infinite loop while 1430 processing a request with "Depth: infinity". This status indicates 1431 that the entire operation failed. 1433 8. Capability Discovery 1435 8.1. OPTIONS Method 1437 If the server supports bindings, it MUST return the compliance class 1438 name "bind" as a field in the "DAV" response header (see [RFC4918], 1439 Section 10.1) from an OPTIONS request on any resource implemented by 1440 that server. A value of "bind" in the "DAV" header MUST indicate 1441 that the server supports all MUST level requirements and REQUIRED 1442 features specified in this document. 1444 8.2. 'DAV' Request Header 1446 Clients SHOULD signal support for all MUST level requirements and 1447 REQUIRED features by submitting a "DAV" request header containing the 1448 compliance class name "bind". In particular, the client MUST 1449 understand the 208 status code defined in Section 7.1. 1451 9. Relationship to WebDAV Access Control Protocol 1453 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1454 property (see [RFC3744], Section 7.3). 1456 10. Relationship to Versioning Extensions to WebDAV 1458 Servers that implement Workspaces ([RFC3253], Section 6) and Version 1459 Controlled Collections ([RFC3253], Section 14) already need to 1460 implement BIND-like behaviour in order to handle UPDATE and 1461 UNCHECKOUT semantics. 1463 Consider a workspace "/ws1/", containing the version-controlled, 1464 checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ 1465 CollY", and a version-controlled resource R, bound to C1 as "/ws1/ 1466 CollX/test": 1468 +-------------------------+ 1469 | Workspace | 1470 | bindings: | 1471 | CollX CollY | 1472 +-------------------------+ 1473 | | 1474 | | 1475 | | 1476 +---------------+ +---------------+ 1477 | Collection C1 | | Collection C2 | 1478 | bindings: | | | 1479 | test | | | 1480 +---------------+ +---------------+ 1481 | 1482 | 1483 | 1484 +------------------+ 1485 | Resource R | 1486 +------------------+ 1488 Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but 1489 undoing the checkout on C1 will undo part of the MOVE request, thus 1490 restoring the binding from C1 to R, but keeping the new binding from 1491 C2 to R: 1493 >> Request: 1495 MOVE /ws1/CollX/test HTTP/1.1 1496 Host: www.example.com 1497 Destination: /ws1/CollY/test 1499 >> Response: 1501 HTTP/1.1 204 No Content 1503 >> Request: 1505 CHECKIN /ws1/CollY/ HTTP/1.1 1506 Host: www.example.com 1508 >> Response: 1510 HTTP/1.1 201 Created 1511 Cache-Control: no-cache 1512 Location: http://repo.example.com/his/17/ver/42 1514 >> Request: 1516 UNCHECKOUT /ws1/CollX/ HTTP/1.1 1517 Host: www.example.com 1519 >> Response: 1521 HTTP/1.1 200 OK 1522 Cache-Control: no-cache 1524 As a result, both C1 and C2 would have a binding to R: 1526 +-------------------------+ 1527 | Workspace | 1528 | bindings: | 1529 | CollX CollY | 1530 +-------------------------+ 1531 | | 1532 | | 1533 | | 1534 +---------------+ +---------------+ 1535 | Collection C1 | | Collection C2 | 1536 | bindings: | | bindings: | 1537 | test | | test | 1538 +---------------+ +---------------+ 1539 | | 1540 | | 1541 | | 1542 +------------------+ 1543 | Resource R | 1544 +------------------+ 1546 The MOVE semantics defined in Section 3.15 of [RFC3253] already 1547 require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the 1548 same version history (as exposed in the DAV:version-history 1549 property). Furthermore, the UNCHECKOUT semantics (which in this case 1550 is similar to UPDATE, see Section 14.11 of [RFC3253]) require: 1552 ...If a new version-controlled member is in a workspace that 1553 already has a version-controlled resource for that version 1554 history, then the new version-controlled member MUST be just a 1555 binding (i.e., another name for) that existing version-controlled 1556 resource... 1558 Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the 1559 same resource R, and have identical DAV:resource-id properties. 1561 11. Security Considerations 1563 This section is provided to make WebDAV implementors aware of the 1564 security implications of this protocol. 1566 All of the security considerations of HTTP/1.1 and the WebDAV 1567 Distributed Authoring Protocol specification also apply to this 1568 protocol specification. In addition, bindings introduce several new 1569 security concerns and increase the risk of some existing threats. 1570 These issues are detailed below. 1572 11.1. Privacy Concerns 1574 In a context where cross-server bindings are supported, creating 1575 bindings on a trusted server may make it possible for a hostile agent 1576 to induce users to send private information to a target on a 1577 different server. 1579 11.2. Bind Loops 1581 Although bind loops were already possible in HTTP 1.1, the 1582 introduction of the BIND method creates a new avenue for clients to 1583 create loops accidentally or maliciously. If the binding and its 1584 target are on the same server, the server may be able to detect BIND 1585 requests that would create loops. Servers are required to detect 1586 loops that are caused by bindings to collections during the 1587 processing of any requests with "Depth: infinity". 1589 11.3. Bindings, and Denial of Service 1591 Denial of service attacks were already possible by posting URIs that 1592 were intended for limited use at heavily used Web sites. The 1593 introduction of BIND creates a new avenue for similar denial of 1594 service attacks. If cross-server bindings are supported, clients can 1595 now create bindings at heavily used sites to target locations that 1596 were not designed for heavy usage. 1598 11.4. Private Locations May Be Revealed 1600 If the DAV:parent-set property is maintained on a resource, the 1601 owners of the bindings risk revealing private locations. The 1602 directory structures where bindings are located are available to 1603 anyone who has access to the DAV:parent-set property on the resource. 1604 Moving a binding may reveal its new location to anyone with access to 1605 DAV:parent-set on its resource. 1607 11.5. DAV:parent-set and Denial of Service 1609 If the server maintains the DAV:parent-set property in response to 1610 bindings created in other administrative domains, it is exposed to 1611 hostile attempts to make it devote resources to adding bindings to 1612 the list. 1614 12. Internationalization Considerations 1616 All internationalization considerations mentioned in [RFC4918] also 1617 apply to this document. 1619 13. IANA Considerations 1621 Section 7 defines the HTTP status codes 208 (Already Reported) and 1622 506 (Loop Detected), to be added to the registry at 1623 . 1625 14. Acknowledgements 1627 This document is the collaborative product of the authors and Tyson 1628 Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited 1629 from thoughtful discussion by Jim Amsden, Peter Carlson, Steve 1630 Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer 1631 Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa 1632 Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe 1633 Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris 1634 Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1635 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1636 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1637 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1638 members of the WebDAV working group. 1640 15. References 1642 15.1. Normative References 1644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1645 Requirement Levels", BCP 14, RFC 2119, March 1997. 1647 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1648 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1649 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1651 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1652 Resource Identifier (URI): Generic Syntax", STD 66, 1653 RFC 3986, January 2005. 1655 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1656 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1658 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1659 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1660 Edition)", W3C REC-xml-20060816, August 2006, 1661 . 1663 15.2. Informative References 1665 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1666 Whitehead, "Versioning Extensions to WebDAV (Web 1667 Distributed Authoring and Versioning)", RFC 3253, 1668 March 2002. 1670 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1671 Distributed Authoring and Versioning (WebDAV) Access 1672 Control Protocol", RFC 3744, May 2004. 1674 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1675 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1676 July 2005. 1678 Appendix A. Clarification to RFC2518bis' Usage of the term 'lock root' 1680 [RFC4918], Section 9.10.1 claims: 1682 A LOCK request to an existing resource will create a lock on the 1683 resource identified by the Request-URI, provided the resource is 1684 not already locked with a conflicting lock. The resource 1685 identified in the Request-URI becomes the root of the lock. 1687 This is incorrect in that it implies that the "lock root" is a 1688 resource, not a URL 1689 (). However, 1690 should a directly locked resource have multiple bindings, only the 1691 one used in the Request-URI of the LOCK request will be the protected 1692 from changes of clients not supplying the lock token. 1694 A correct description would be: 1696 A LOCK request to an existing resource will create a lock on the 1697 resource identified by the Request-URI, provided the resource is 1698 not already locked with a conflicting lock. The Request-URI 1699 becomes the root of the lock. 1701 Note that this change makes the description consistent with the 1702 definition of the DAV:lockroot XML element in Section 14.12 of 1703 [RFC4918]. 1705 The authors of this specification recommend that future revisions of 1706 [RFC4918] will update the description as suggested above. 1708 Appendix B. Change Log (to be removed by RFC Editor before publication) 1710 B.1. Since draft-ietf-webdav-bind-02 1712 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1713 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1714 resolution, but keep it open. Add issues "ED_references" and 1715 "4_507_status". Started work on index. Rename document to "Binding 1716 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1717 Rename "References" to "Normative References". Close issue 1718 "ED_references". Close issue "4_507_status". 1720 B.2. Since draft-ietf-webdav-bind-03 1722 Add and close issues "9.2_redirect_loops", "ED_authors" and 1723 "ED_updates". Add section about capability discovery (DAV header). 1724 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1725 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1726 "locking" and resolve as invalid. 1728 B.3. Since draft-ietf-webdav-bind-04 1730 Add and close issues "6_precondition_binding_allowed" and 1731 "6_lock_behaviour". Add mailing list and issues list pointers to 1732 front. 1734 B.4. Since draft-ietf-webdav-bind-05 1736 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1737 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1738 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1740 B.5. Since draft-ietf-webdav-bind-06 1742 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1743 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1745 B.6. Since draft-ietf-webdav-bind-07 1747 Add more index items (no change tracking). Add and resolve issues 1748 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1749 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1750 DTD fragment in section 3.3. Make spelling of "Request-URI" 1751 consistent. 1753 B.7. Since draft-ietf-webdav-bind-08 1755 Resolved editorial issues raised by Jim Whitehead in . 1757 Add and resolve issues "atomicity", "2_allow_destroy", 1758 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1759 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1760 "2.6_resource-id_vs_versions", "3.2_example" and 1761 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1762 and resolve "6_rebind_intro". 1764 B.8. Since draft-ietf-webdav-bind-09 1766 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1767 text. Add action item "3.1_uuids". Close issue 1768 "2.6_when_do_ids_change". Add and resolve issues 1769 "2.6_bindings_vs_properties" and "uri_draft_ref". 1771 B.9. Since draft-ietf-webdav-bind-10 1773 Resolve action item "3.1_uuids". Add and resolve issue 1774 "2.7_unlock_vs_bindings". Revisit issue 1775 "2.6_bindings_vs_properties", and remove the part of the sentence 1776 that speaks about live properties. Update "rfc2396bis" references to 1777 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1778 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1780 B.10. Since draft-ietf-webdav-bind-11 1782 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1783 live properties in Section 2.6. 1785 B.11. Since draft-ietf-webdav-bind-12 1787 Updated Author's address. Uppercase "Section" when referring to 1788 other documents. 1790 Updating from RFC2518 to RFC2518bis: 1792 o Remove own explanation of DTD syntax. 1794 o Remove own definition of precondition/postcondition. 1796 o Remove reference to broken RFC2518 language about DELETE and 1797 UNLOCK. 1799 o Remove own definition of DAV: request header. 1801 o Updated "Rationale for Distinguishing Bindings from URI Mappings" 1802 to reflect the changes in [draft-ietf-webdav-rfc2518bis], making 1803 proposals for more changes so that the issue can be closed (see 1804 also 1805 and ). 1808 B.12. Since draft-ietf-webdav-bind-13 1810 Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one 1811 incorrect section reference. Remove Section "Rationale for 1812 Distinguishing Bindings from URI Mappings" as 1813 [draft-ietf-webdav-rfc2518-bis] now uses the proper definition of 1814 collection state. Examples use application/xml instead of text/xml 1815 MIME type. 1817 Fix IANA section (there are no IANA considerations). 1819 B.13. Since draft-ietf-webdav-bind-14 1821 Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to 1822 4th edition. 1824 Markup ASCII art for box recognition (doesn't affect ASCII version). 1826 Identify Julian Reschke as Editor. 1828 B.14. Since draft-ietf-webdav-bind-15 1830 Fix typo in RFC2119 keywords section (sorry!). 1832 Update [draft-ietf-webdav-rfc2518-bis] to draft 17. 1834 Add and resolve issue "rfc2518bis-lock-root". 1836 B.15. Since draft-ietf-webdav-bind-16 1838 Add and resolve issue "iana-vs-http-status". 1840 B.16. Since draft-ietf-webdav-bind-17 1842 Update rfc2518bis reference to draft 18 (note that the bug reported 1843 in 1844 is still present). 1846 B.17. Since draft-ietf-webdav-bind-18 1848 Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918. 1850 B.18. Since draft-ietf-webdav-bind-19 1852 Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move- 1853 creating-cycles", "3.1-clarify-resource-id" and "4-precondition- 1854 language". 1856 B.19. Since draft-ietf-webdav-bind-20 1858 Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples. 1859 Replace RFC518bis issue link by pointer to RFC Errata Page. 1861 Add issues "relation-to-deltav" and "status-codes". 1863 B.20. Since draft-ietf-webdav-bind-21 1865 Resolve issues "relation-to-deltav" and "status-codes". 1867 Add correct content length values to examples (no change bars). 1869 Appendix C. Resolved issues (to be removed by RFC Editor before 1870 publication) 1872 Issues that were either rejected or resolved in this version of this 1873 document. 1875 C.1. status-codes 1877 Type: change 1879 1882 julian.reschke@greenbytes.de (2008-09-26): The spec currently micro- 1883 manages HTTP status codes: for instance, for a successful BIND it 1884 requires status codes of 200 or 201, while - from an HTTP point of 1885 view - a 204 should be acceptable as well. Proposal: rephrase the 1886 text so that other success codes are acceptable as well, or remove 1887 the normative language completely, point to RFC2616, and rely on 1888 examples. 1890 Resolution (2008-10-05): Also allow 204 where previously only 200 was 1891 allowed. Add Location header to example using status 201. 1893 C.2. relation-to-deltav 1895 Type: change 1897 1900 werner.donne@re.be (2008-08-11): ...When supporting version 1901 controlled collections, bindings may be introduced in a server 1902 without actually issuing the BIND method. When a MOVE is performed 1903 of a resource from one collection to another, both collections should 1904 be checked out. An additional binding would be the result if one 1905 collection would be subsequently checked in, while the check-out of 1906 the other is undone. The resulting situation is meaningless if the 1907 binding model is not supported... 1909 Resolution (2008-10-04): Add new section containing that example. 1911 Appendix D. Open issues (to be removed by RFC Editor prior to 1912 publication) 1914 D.1. edit 1916 Type: edit 1918 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1919 editorial fixes/enhancements. 1921 Index 1923 2 1924 208 Already Reported (status code) 31, 39 1926 5 1927 506 Loop Detected (status code) 34, 39 1929 B 1930 BIND method 21 1931 Marshalling 22 1932 Postconditions 23 1933 Preconditions 22 1934 Binding 7 1936 C 1937 Collection 7 1938 Condition Names 1939 DAV:bind-into-collection (pre) 22 1940 DAV:bind-source-exists (pre) 22 1941 DAV:binding-allowed (pre) 23 1942 DAV:binding-deleted (post) 25, 28 1943 DAV:can-overwrite (pre) 23, 27 1944 DAV:cross-server-binding (pre) 23, 27 1945 DAV:cycle-allowed (pre) 23, 27 1946 DAV:lock-deleted (post) 25, 28 1947 DAV:locked-overwrite-allowed (pre) 23 1948 DAV:locked-source-collection-update-allowed (pre) 28 1949 DAV:locked-update-allowed (pre) 23, 25, 27 1950 DAV:name-allowed (pre) 23, 27 1951 DAV:new-binding (post) 23, 28 1952 DAV:protected-source-url-deletion-allowed (pre) 28 1953 DAV:protected-url-deletion-allowed (pre) 25 1954 DAV:protected-url-modification-allowed (pre) 27 1955 DAV:rebind-from-collection (pre) 27 1956 DAV:rebind-source-exists (pre) 27 1957 DAV:unbind-from-collection (pre) 25 1958 DAV:unbind-source-exists (pre) 25 1960 D 1961 DAV header 1962 compliance class 'bind' 34 1963 DAV:bind-into-collection precondition 22 1964 DAV:bind-source-exists precondition 22 1965 DAV:binding-allowed precondition 23 1966 DAV:binding-deleted postcondition 25, 28 1967 DAV:can-overwrite precondition 23, 27 1968 DAV:cross-server-binding precondition 23, 27 1969 DAV:cycle-allowed precondition 23, 27 1970 DAV:lock-deleted postcondition 25, 28 1971 DAV:locked-overwrite-allowed precondition 23 1972 DAV:locked-source-collection-update-allowed precondition 28 1973 DAV:locked-update-allowed precondition 23, 25, 27 1974 DAV:name-allowed precondition 23, 27 1975 DAV:new-binding postcondition 23, 28 1976 DAV:parent-set property 20 1977 DAV:protected-source-url-deletion-allowed precondition 28 1978 DAV:protected-url-deletion-allowed precondition 25 1979 DAV:protected-url-modification-allowed precondition 27 1980 DAV:rebind-from-collection precondition 27 1981 DAV:rebind-source-exists precondition 27 1982 DAV:resource-id property 19 1983 DAV:unbind-from-collection precondition 25 1984 DAV:unbind-source-exists precondition 25 1986 I 1987 Internal Member URI 7 1989 M 1990 Methods 1991 BIND 21 1992 REBIND 26 1993 UNBIND 24 1995 P 1996 Path Segment 6 1997 Properties 1998 DAV:parent-set 20 1999 DAV:resource-id 19 2001 R 2002 REBIND method 26 2003 Marshalling 26 2004 Postconditions 28 2005 Preconditions 27 2007 S 2008 Status Codes 2009 208 Already Reported 31, 39 2010 506 Loop Detected 34, 39 2012 U 2013 UNBIND method 24 2014 Marshalling 24 2015 Postconditions 25 2016 Preconditions 25 2017 URI Mapping 6 2019 Authors' Addresses 2021 Geoffrey Clemm 2022 IBM 2023 20 Maguire Road 2024 Lexington, MA 02421 2026 Email: geoffrey.clemm@us.ibm.com 2027 Jason Crawford 2028 IBM Research 2029 P.O. Box 704 2030 Yorktown Heights, NY 10598 2032 Email: ccjason@us.ibm.com 2034 Julian F. Reschke (editor) 2035 greenbytes GmbH 2036 Hafenweg 16 2037 Muenster, NW 48155 2038 Germany 2040 Email: julian.reschke@greenbytes.de 2042 Jim Whitehead 2043 UC Santa Cruz, Dept. of Computer Science 2044 1156 High Street 2045 Santa Cruz, CA 95064 2047 Email: ejw@cse.ucsc.edu 2049 Full Copyright Statement 2051 Copyright (C) The IETF Trust (2008). 2053 This document is subject to the rights, licenses and restrictions 2054 contained in BCP 78, and except as set forth therein, the authors 2055 retain all their rights. 2057 This document and the information contained herein are provided on an 2058 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2059 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2060 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2061 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2062 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2063 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2065 Intellectual Property 2067 The IETF takes no position regarding the validity or scope of any 2068 Intellectual Property Rights or other rights that might be claimed to 2069 pertain to the implementation or use of the technology described in 2070 this document or the extent to which any license under such rights 2071 might or might not be available; nor does it represent that it has 2072 made any independent effort to identify any such rights. Information 2073 on the procedures with respect to rights in RFC documents can be 2074 found in BCP 78 and BCP 79. 2076 Copies of IPR disclosures made to the IETF Secretariat and any 2077 assurances of licenses to be made available, or the result of an 2078 attempt made to obtain a general license or permission for the use of 2079 such proprietary rights by implementers or users of this 2080 specification can be obtained from the IETF on-line IPR repository at 2081 http://www.ietf.org/ipr. 2083 The IETF invites any interested party to bring to its attention any 2084 copyrights, patents or patent applications, or other proprietary 2085 rights that may cover technology that may be required to implement 2086 this standard. Please address the information to the IETF at 2087 ietf-ipr@ietf.org.