idnits 2.17.1 draft-ietf-webdav-bind-24.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 611 has weird spacing: '...| x.gif y.g...' == Line 633 has weird spacing: '...| x.gif y.g...' == Line 904 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 (May 29, 2009) is 5439 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: November 30, 2009 J. Reschke, Ed. 7 greenbytes 8 J. Whitehead 9 U.C. Santa Cruz 10 May 29, 2009 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-24 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 November 30, 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 ensure 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 . . . . . . . . . 8 83 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8 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 updating multiple Bindings . . . . . . . 14 91 2.3.3. Example: COPY with 'Depth: infinity' with Multiple 92 Bindings to a Leaf Resource . . . . . . . . . . . . . 15 93 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 16 94 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 16 95 2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 17 96 2.5.2. Example: MOVE Request causing a Bind Loop . . . . . . 17 97 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 19 98 2.7. Determining Whether Two Bindings Are to the Same 99 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 20 101 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 20 103 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 21 104 3.2.1. Example for DAV:parent-set Property . . . . . . . . . 21 105 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 25 107 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 25 108 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 27 109 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 27 110 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 29 111 6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 30 112 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 32 113 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 32 114 7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 33 115 7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 35 116 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 35 117 8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 35 118 8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 35 119 8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 35 120 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 36 121 10. Relationship to Versioning Extensions to WebDAV . . . . . . . 36 122 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 123 11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 39 124 11.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 39 125 11.3. Bindings, and Denial of Service . . . . . . . . . . . . . 39 126 11.4. Private Locations May Be Revealed . . . . . . . . . . . . 39 127 11.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 39 128 12. Internationalization Considerations . . . . . . . . . . . . . 39 129 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 130 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 131 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 132 15.1. Normative References . . . . . . . . . . . . . . . . . . . 40 133 15.2. Informative References . . . . . . . . . . . . . . . . . . 41 134 Appendix A. Clarification to RFC2518bis' Usage of the term 135 'lock root' . . . . . . . . . . . . . . . . . . . . . 41 136 Appendix B. Change Log (to be removed by RFC Editor before 137 publication) . . . . . . . . . . . . . . . . . . . . 42 138 B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 42 139 B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 42 140 B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 42 141 B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 42 142 B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 42 143 B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 42 144 B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 43 145 B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 43 146 B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 43 147 B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 43 148 B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 43 149 B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 44 150 B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 44 151 B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 44 152 B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 44 153 B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 44 154 B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 45 155 B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 45 156 B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 45 157 B.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 45 158 B.21. Since draft-ietf-webdav-bind-22 . . . . . . . . . . . . . 45 159 B.22. Since draft-ietf-webdav-bind-23 . . . . . . . . . . . . . 45 160 Appendix C. Resolved issues (to be removed by RFC Editor 161 before publication) . . . . . . . . . . . . . . . . . 45 162 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 163 C.2. def-integrity . . . . . . . . . . . . . . . . . . . . . . 46 164 C.3. ex-copy-multiple-update . . . . . . . . . . . . . . . . . 46 165 C.4. ex-copy-graph . . . . . . . . . . . . . . . . . . . . . . 46 166 C.5. ex-live-property . . . . . . . . . . . . . . . . . . . . . 47 167 C.6. clarify-alternate-uri . . . . . . . . . . . . . . . . . . 47 168 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 169 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 171 1. Introduction 173 This specification extends the WebDAV Distributed Authoring Protocol 174 ([RFC4918]) to enable clients to create new access paths to existing 175 resources. This capability is useful for several reasons: 177 URIs of WebDAV-compliant resources are hierarchical and correspond to 178 a hierarchy of collections in resource space. The WebDAV Distributed 179 Authoring Protocol makes it possible to organize these resources into 180 hierarchies, placing them into groupings, known as collections, which 181 are more easily browsed and manipulated than a single flat 182 collection. However, hierarchies require categorization decisions 183 that locate resources at a single location in the hierarchy, a 184 drawback when a resource has multiple valid categories. For example, 185 in a hierarchy of vehicle descriptions containing collections for 186 cars and boats, a description of a combination car/boat vehicle could 187 belong in either collection. Ideally, the description should be 188 accessible from both. Allowing clients to create new URIs that 189 access the existing resource lets them put that resource into 190 multiple collections. 192 Hierarchies also make resource sharing more difficult, since 193 resources that have utility across many collections are still forced 194 into a single collection. For example, the mathematics department at 195 one university might create a collection of information on fractals 196 that contains bindings to some local resources, but also provides 197 access to some resources at other universities. For many reasons, it 198 may be undesirable to make physical copies of the shared resources on 199 the local server: to conserve disk space, to respect copyright 200 constraints, or to make any changes in the shared resources visible 201 automatically. Being able to create new access paths to existing 202 resources in other collections or even on other servers is useful for 203 this sort of case. 205 The BIND method defined here provides a mechanism for allowing 206 clients to create alternative access paths to existing WebDAV 207 resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to 208 work because there are mappings between URIs and resources. A method 209 is addressed to a URI, and the server follows the mapping from that 210 URI to a resource, applying the method to that resource. Multiple 211 URIs may be mapped to the same resource, but until now there has been 212 no way for clients to create additional URIs mapped to existing 213 resources. 215 BIND lets clients associate a new URI with an existing WebDAV 216 resource, and this URI can then be used to submit requests to the 217 resource. Since URIs of WebDAV resources are hierarchical, and 218 correspond to a hierarchy of collections in resource space, the BIND 219 method also has the effect of adding the resource to a collection. 220 As new URIs are associated with the resource, it appears in 221 additional collections. 223 A BIND request does not create a new resource, but simply makes 224 available a new URI for submitting requests to an existing resource. 225 The new URI is indistinguishable from any other URI when submitting a 226 request to a resource. Only one round trip is needed to submit a 227 request to the intended target. Servers are required to enforce the 228 integrity of the relationships between the new URIs and the resources 229 associated with them. Consequently, it may be very costly for 230 servers to support BIND requests that cross server boundaries. 232 This specification is organized as follows. Section 1.1 defines 233 terminology used in the rest of the specification, while Section 2 234 overviews bindings. Section 3 defines the new properties needed to 235 support multiple bindings to the same resource. Section 4 specifies 236 the BIND method, used to create multiple bindings to the same 237 resource. Section 5 specifies the UNBIND method, used to remove a 238 binding to a resource. Section 6 specifies the REBIND method, used 239 to move a binding to another collection. 241 1.1. Terminology 243 The terminology used here follows and extends that in the WebDAV 244 Distributed Authoring Protocol specification [RFC4918]. 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 248 document are to be interpreted as described in [RFC2119]. 250 This document uses XML DTD fragments ([XML]) as a notational 251 convention, using the rules defined in Section 17 of [RFC4918]. 253 URI Mapping 255 A relation between an absolute URI and a resource. For an 256 absolute URI U and the resource it identifies R, the URI mapping 257 can be thought of as (U => R). Since a resource can represent 258 items that are not network retrievable, as well as those that are, 259 it is possible for a resource to have zero, one, or many URI 260 mappings. Mapping a resource to an "http" scheme URI makes it 261 possible to submit HTTP protocol requests to the resource using 262 the URI. 264 Path Segment 266 Informally, the characters found between slashes ("/") in a URI. 267 Formally, as defined in Section 3.3 of [RFC3986]. 269 Binding 271 A relation between a single path segment (in a collection) and a 272 resource. A binding is part of the state of a collection. If two 273 different collections contain a binding between the same path 274 segment and the same resource, these are two distinct bindings. 275 So for a collection C, a path segment S, and a resource R, the 276 binding can be thought of as C:(S -> R). Bindings create URI 277 mappings, and hence allow requests to be sent to a single resource 278 from multiple locations in a URI namespace. For example, given a 279 collection C (accessible through the URI 280 http://www.example.com/CollX), a path segment S (equal to 281 "foo.html"), and a resource R, then creating the binding C: (S -> 282 R) makes it possible to use the URI 283 http://www.example.com/CollX/foo.html to access R. 285 Collection 287 A resource that contains, as part of its state, a set of bindings 288 that identify internal member resources. 290 Internal Member URI 292 The URI that identifies an internal member of a collection, and 293 that consists of the URI for the collection, followed by a slash 294 character ('/'), followed by the path segment of the binding for 295 that internal member. 297 Binding Integrity 299 The property of a binding that says that: 301 * the binding continues to exist, and 303 * the identity of the resource identified by that binding does 304 not change 306 unless an explicit request is executed that is defined to delete 307 that binding (examples of requests that delete a binding are 308 DELETE, MOVE, and - defined later on - UNBIND, and REBIND). 310 1.2. Method Preconditions and Postconditions 312 See Section 16 of [RFC4918] for the definitions of "precondition" and 313 "postcondition". 315 2. Overview of Bindings 317 Bindings are part of the state of a collection. They define the 318 internal members of the collection, and the names of those internal 319 members. 321 Bindings are added and removed by a variety of existing HTTP methods. 322 A method that creates a new resource, such as PUT, COPY, and MKCOL, 323 adds a binding. A method that deletes a resource, such as DELETE, 324 removes a binding. A method that moves a resource (e.g. MOVE) both 325 adds a binding (in the destination collection) and removes a binding 326 (in the source collection). The BIND method introduced here provides 327 a mechanism for adding a second binding to an existing resource. 328 There is no difference between an initial binding added by PUT, COPY, 329 or MKCOL, and additional bindings added with BIND. 331 It would be very undesirable if one binding could be destroyed as a 332 side effect of operating on the resource through a different binding. 333 In particular, the removal of one binding to a resource (e.g. with a 334 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 335 e.g. by turning that binding into a dangling path segment. The 336 server MUST NOT reclaim system resources after removing one binding, 337 while other bindings to the resource remain. In other words, the 338 server MUST maintain the integrity of a binding. It is permissible, 339 however, for future method definitions (e.g., a DESTROY method) to 340 have semantics that explicitly remove all bindings and/or immediately 341 reclaim system resources. 343 2.1. Bindings to Collections 345 Creating a new binding to a collection makes each resource associated 346 with a binding in that collection accessible via a new URI, and thus 347 creates new URI mappings to those resources but no new bindings. 349 For example, suppose a new binding CollY is created for collection C1 350 in the figure below. It immediately becomes possible to access 351 resource R1 using the URI /CollY/x.gif and to access resource R2 352 using the URI /CollY/y.jpg, but no new bindings for these child 353 resources were created. This is because bindings are part of the 354 state of a collection, and associate a URI that is relative to that 355 collection with its target resource. No change to the bindings in 356 Collection C1 is needed to make its children accessible using /CollY/ 357 x.gif and /CollY/y.jpg. 359 +-------------------------+ 360 | Root Collection | 361 | bindings: | 362 | CollX CollY | 363 +-------------------------+ 364 | / 365 | / 366 | / 367 +------------------+ 368 | Collection C1 | 369 | bindings: | 370 | x.gif y.jpg | 371 +------------------+ 372 | \ 373 | \ 374 | \ 375 +-------------+ +-------------+ 376 | Resource R1 | | Resource R2 | 377 +-------------+ +-------------+ 379 2.1.1. Bind Loops 381 Bindings to collections can result in loops ("cycles"), which servers 382 MUST detect when processing "Depth: infinity" requests. It is 383 sometimes possible to complete an operation in spite of the presence 384 of a loop. For instance, a PROPFIND can still succeed if the server 385 uses the new status code 208 (Already Reported) defined in 386 Section 7.1. 388 However, the 506 (Loop Detected) status code is defined in 389 Section 7.2 for use in contexts where an operation is terminated 390 because a loop was encountered. 392 Support for loops is OPTIONAL: servers MAY reject requests that would 393 lead to the creation of a bind loop (see DAV:cycle-allowed 394 precondition defined in Section 4). 396 2.2. URI Mappings Created by a new Binding 398 Suppose a binding from "Binding-Name" to resource R is to be added to 399 a collection, C. Then if C-MAP is the set of URIs that were mapped to 400 C before the BIND request, then for each URI "C-URI" in C-MAP, the 401 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 402 request. 404 For example, if a binding from "foo.html" to R is added to a 405 collection C, and if the following URIs are mapped to C: 407 http://www.example.com/A/1/ 408 http://example.com/A/one/ 410 then the following new mappings to R are introduced: 412 http://www.example.com/A/1/foo.html 413 http://example.com/A/one/foo.html 415 Note that if R is a collection, additional URI mappings are created 416 to the descendents of R. Also, note that if a binding is made in 417 collection C to C itself (or to a parent of C), an infinite number of 418 mappings are introduced. 420 For example, if a binding from "myself" to C is then added to C, the 421 following infinite number of additional mappings to C are introduced: 423 http://www.example.com/A/1/myself 424 http://www.example.com/A/1/myself/myself 425 ... 427 and the following infinite number of additional mappings to R are 428 introduced: 430 http://www.example.com/A/1/myself/foo.html 431 http://www.example.com/A/1/myself/myself/foo.html 432 ... 434 2.3. COPY and Bindings 436 As defined in Section 9.8 of [RFC4918], COPY causes the resource 437 identified by the Request-URI to be duplicated, and makes the new 438 resource accessible using the URI specified in the Destination 439 header. Upon successful completion of a COPY, a new binding is 440 created between the last path segment of the Destination header, and 441 the destination resource. The new binding is added to its parent 442 collection, identified by the Destination header minus its final 443 segment. 445 The following figure shows an example: Suppose that a COPY is issued 446 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 447 with the Destination header set to URI-X. After successful 448 completion of the COPY operation, resource R is duplicated to create 449 resource R', and a new binding has been created which creates at 450 least the URI mapping between URI-X and the new resource (although 451 other URI mappings may also have been created). 453 URI-1 URI-2 URI-3 URI-X 454 | | | | 455 | | | <---- URI Mappings ----> | 456 | | | | 457 +---------------------+ +------------------------+ 458 | Resource R | | Resource R' | 459 +---------------------+ +------------------------+ 461 It might be thought that a COPY request with "Depth: 0" on a 462 collection would duplicate its bindings, since bindings are part of 463 the collection's state. This is not the case, however. The 464 definition of Depth in [RFC4918] makes it clear that a "Depth: 0" 465 request does not apply to a collection's members. Consequently, a 466 COPY with "Depth: 0" does not duplicate the bindings contained by the 467 collection. 469 If a COPY request causes an existing resource to be updated, the 470 bindings to that resource MUST be unaffected by the COPY request. 471 Using the preceding example, suppose that a COPY request is issued to 472 URI-X for resource R', with the Destination header set to URI-2. The 473 content and dead properties of resource R would be updated to be a 474 copy of those of resource R', but the mappings from URI-1, URI-2, and 475 URI-3 to resource R remain unaffected. If because of multiple 476 bindings to a resource, more than one source resource updates a 477 single destination resource, the order of the updates is server 478 defined (see Section 2.3.2 for an example). 480 If a COPY request would cause a new resource to be created as a copy 481 of an existing resource, and that COPY request has already created a 482 copy of that existing resource, the COPY request instead creates 483 another binding to the previous copy, instead of creating a new 484 resource (see Section 2.3.3 for an example). 486 2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops 488 As an example of how COPY with Depth infinity would work in the 489 presence of bindings, consider the following collection: 491 +------------------+ 492 | Root Collection | 493 | bindings: | 494 | CollX | 495 +------------------+ 496 | 497 | 498 +-------------------------------+ 499 | Collection C1 |<-------+ 500 | bindings: | | 501 | x.gif CollY | | 502 +-------------------------------+ | 503 | \ (creates loop) | 504 | \ | 505 +-------------+ +------------------+ | 506 | Resource R1 | | Collection C2 | | 507 +-------------+ | bindings: | | 508 | y.gif CollZ | | 509 +------------------+ | 510 | | | 511 | +--------+ 512 | 513 +-------------+ 514 | Resource R2 | 515 +-------------+ 517 If a COPY with Depth infinity is submitted to /CollX, with 518 destination of /CollA, the outcome of the copy operation is: 520 +------------------+ 521 | Root Collection | 522 | bindings: | 523 | CollX CollA | 524 +------------------+ 525 | | 526 | +---------------------------+ 527 | | 528 +-------------------+ | 529 | Collection C1 |<------------------+ | 530 | bindings: | | | 531 | x.gif CollY | | | 532 +-------------------+ | | 533 | \ (creates loop) | | 534 | \ | | 535 +-------------+ +-----------------+ | | 536 | Resource R1 | | Collection C2 | | | 537 +-------------+ | bindings: | | | 538 | y.gif CollZ | | | 539 +-----------------+ | | 540 | | | | 541 | +-------+ | 542 | | 543 +-------------+ | 544 | Resource R2 | | 545 +-------------+ | 546 | 547 +-------------------------------+ 548 | 549 +-------------------+ 550 | Collection C3 |<------------------+ 551 | bindings: | | 552 | x.gif CollY | | 553 +-------------------+ | 554 | \ (creates loop) | 555 | \ | 556 +-------------+ +-----------------+ | 557 | Resource R3 | | Collection C4 | | 558 +-------------+ | bindings: | | 559 | y.gif CollZ | | 560 +-----------------+ | 561 | | | 562 | +-------+ 563 | 564 +-------------+ 565 | Resource R4 | 566 +-------------+ 568 2.3.2. Example: COPY updating multiple Bindings 570 Given the following collection hierarchy: 572 +------------------+ 573 | Root Collection | 574 | bindings: | 575 | CollX CollY | 576 +------------------+ 577 / \ 578 / \ 579 / \ 580 +--------------------------+ +-----------------+ 581 | Collection C1 | | Collection C2 | 582 | bindings: | | bindings: | 583 | x.gif y.gif | | x.gif y.gif | 584 +--------------------------+ +-----------------+ 585 | | | | 586 | | | | 587 +-------------+ +-------------+ +-------------+ 588 | Resource R1 | | Resource R2 | | Resource R3 | 589 +-------------+ +-------------+ +-------------+ 591 A COPY of /CollX with Depth infinity to /CollY will not result in a 592 changed hierarchy, and Resource R3 will be updated with the content 593 of either Resource R1 or Resource R2. 595 2.3.3. Example: COPY with 'Depth: infinity' with Multiple Bindings to a 596 Leaf Resource 598 Given the following collection hierarchy: 600 +------------------+ 601 | Root Collection | 602 | bindings: | 603 | CollX | 604 +------------------+ 605 | 606 | 607 | 608 +----------------+ 609 | Collection C1 | 610 | bindings: | 611 | x.gif y.gif | 612 +----------------+ 613 | | 614 | | 615 +-------------+ 616 | Resource R1 | 617 +-------------+ 619 A COPY of /CollX with Depth infinity to /CollY results in the 620 following collection hierarchy: 622 +------------------+ 623 | Root Collection | 624 | bindings: | 625 | CollX CollY | 626 +------------------+ 627 | \ 628 | \ 629 | \ 630 +----------------+ +-----------------+ 631 | Collection C1 | | Collection C2 | 632 | bindings: | | bindings: | 633 | x.gif y.gif | | x.gif y.gif | 634 +----------------+ +-----------------+ 635 | | | | 636 | | | | 637 +-------------+ +-------------+ 638 | Resource R1 | | Resource R2 | 639 +-------------+ +-------------+ 641 2.4. DELETE and Bindings 643 When there are multiple bindings to a resource, a DELETE applied to 644 that resource MUST NOT remove any bindings to that resource other 645 than the one identified by the Request-URI. For example, suppose the 646 collection identified by the URI "/a" has a binding named "x" to a 647 resource R, and another collection identified by "/b" has a binding 648 named "y" to the same resource R. Then a DELETE applied to "/a/x" 649 removes the binding named "x" from "/a" but MUST NOT remove the 650 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 651 to identify the resource R). 653 When DELETE is applied to a collection, it MUST NOT modify the 654 membership of any other collection that is not itself a member of the 655 collection being deleted. For example, if both "/a/.../x" and 656 "/b/.../y" identify the same collection, C, then applying DELETE to 657 "/a" must not delete an internal member from C or from any other 658 collection that is a member of C, because that would modify the 659 membership of "/b". 661 If a collection supports the UNBIND method (see Section 5), a DELETE 662 of an internal member of a collection MAY be implemented as an UNBIND 663 request. In this case, applying DELETE to a Request-URI has the 664 effect of removing the binding identified by the final segment of the 665 Request-URI from the collection identified by the Request-URI minus 666 its final segment. Although [RFC4918] allows a DELETE to be a non- 667 atomic operation, when the DELETE operation is implemented as an 668 UNBIND, the operation is atomic. In particular, a DELETE on a 669 hierarchy of resources is simply the removal of a binding to the 670 collection identified by the Request-URI. 672 2.5. MOVE and Bindings 674 When MOVE is applied to a resource, the other bindings to that 675 resource MUST be unaffected, and if the resource being moved is a 676 collection, the bindings to any members of that collection MUST be 677 unaffected. Also, if MOVE is used with Overwrite:T to delete an 678 existing resource, the constraints specified for DELETE apply. 680 If the destination collection of a MOVE request supports the REBIND 681 method (see Section 6), a MOVE of a resource into that collection MAY 682 be implemented as a REBIND request. Although [RFC4918] allows a MOVE 683 to be a non-atomic operation, when the MOVE operation is implemented 684 as a REBIND, the operation is atomic. In particular, applying a MOVE 685 to a Request-URI and a Destination URI has the effect of removing a 686 binding to a resource (at the Request-URI), and creating a new 687 binding to that resource (at the Destination URI). Even when the 688 Request-URI identifies a collection, the MOVE operation involves only 689 removing one binding to that collection and adding another. 691 2.5.1. Example: Simple MOVE 693 As an example, suppose that a MOVE is issued to URI-3 for resource R 694 below (which is also mapped to URI-1 and URI-2), with the Destination 695 header set to URI-X. After successful completion of the MOVE 696 operation, a new binding has been created which creates the URI 697 mapping between URI-X and resource R. The binding corresponding to 698 the final segment of URI-3 has been removed, which also causes the 699 URI mapping between URI-3 and R to be removed. If resource R were a 700 collection, old URI-3 based mappings to members of R would have been 701 removed, and new URI-X based mappings to members of R would have been 702 created. 704 >> Before Request: 706 URI-1 URI-2 URI-3 707 | | | 708 | | | <---- URI Mappings 709 | | | 710 +---------------------+ 711 | Resource R | 712 +---------------------+ 714 >> After Request: 716 URI-1 URI-2 URI-X 717 | | | 718 | | | <---- URI Mappings 719 | | | 720 +---------------------+ 721 | Resource R | 722 +---------------------+ 724 2.5.2. Example: MOVE Request causing a Bind Loop 726 Note that in the presence of collection bindings, a MOVE request can 727 cause the creating of a bind loop. 729 Consider a the top level collections C1 and C2 with URIs "/CollW/" 730 and "/CollX/". C1 also contains an additional binding named "CollY" 731 to C2: 733 +------------------+ 734 | Root Collection | 735 | bindings: | 736 | CollW CollX | 737 +------------------+ 738 | | 739 | | 740 +------------------+ | 741 | Collection C1 | | 742 | bindings: | | 743 | CollY | | 744 +------------------+ | 745 | | 746 | | 747 +------------------+ 748 | Collection C2 | 749 | | 750 | | 751 +------------------+ 753 In this case, the MOVE request below would cause a bind loop: 755 >> Request: 757 MOVE /CollW HTTP/1.1 758 Host: example.com 759 Destination: /CollX/CollZ 760 If the request succeeded, the resulting state would be: 762 +------------------+ 763 | Root Collection | 764 | bindings: | 765 | CollX | 766 +------------------+ 767 | 768 | 769 +------------------+ | 770 | Collection C1 | | 771 +----> | bindings: | | 772 | | CollY | | 773 | +------------------+ | 774 | | | 775 | | | 776 | +------------------+ 777 | | Collection C2 | 778 | | bindings: | 779 | | CollZ | 780 | +------------------+ 781 | | 782 | | 783 +-------------------+ 785 2.6. PROPFIND and Bindings 787 Consistent with [RFC4918], the value of a dead property MUST be 788 independent of the number of bindings to its host resource or of the 789 path submitted to PROPFIND. On the other hand, the behaviour for 790 each live property depends on its individual definition (for example, 791 see [RFC3744], Section 5, paragraph 2 for a case where the value is 792 independent of path and bindings, and [RFC4918], Section 8.8 for a 793 discussion about the live properties DAV:getetag and DAV: 794 getlastmodified, which may behave differently). 796 2.7. Determining Whether Two Bindings Are to the Same Resource 798 It is useful to have some way of determining whether two bindings are 799 to the same resource. Two resources might have identical contents 800 and properties, but not be the same resource (e.g. an update to one 801 resource does not affect the other resource). 803 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 804 resource identifier, which MUST be unique across all resources for 805 all time. If the values of DAV:resource-id returned by PROPFIND 806 requests through two bindings are identical character by character, 807 the client can be assured that the two bindings are to the same 808 resource. 810 The DAV:resource-id property is created, and its value assigned, when 811 the resource is created. The value of DAV:resource-id MUST NOT be 812 changed. Even after the resource is no longer accessible through any 813 URI, that value MUST NOT be reassigned to another resource's DAV: 814 resource-id property. 816 Any method that creates a new resource MUST assign a new, unique 817 value to its DAV:resource-id property. For example, a PUT applied to 818 a null resource, COPY (when not overwriting an existing target) and 819 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 820 to the DAV:resource-id property of the new resource they create. 822 On the other hand, any method that affects an existing resource must 823 not change the value of its DAV:resource-id property. Specifically, 824 a PUT or a COPY that updates an existing resource must not change the 825 value of its DAV:resource-id property. A REBIND, since it does not 826 create a new resource, but only changes the location of an existing 827 resource, must not change the value of the DAV:resource-id property. 829 2.8. Discovering the Bindings to a Resource 831 An OPTIONAL DAV:parent-set property on a resource provides a list of 832 the bindings that associate a collection and a URI segment with that 833 resource. If the DAV:parent-set property exists on a given resource, 834 it MUST contain a complete list of all bindings to that resource that 835 the client is authorized to see. When deciding whether to support 836 the DAV:parent-set property, server implementers / administrators 837 should balance the benefits it provides against the cost of 838 maintaining the property and the security risks enumerated in 839 Sections 11.4 and 11.5. 841 3. Properties 843 The bind feature introduces the properties defined below. 845 A DAV:allprop PROPFIND request SHOULD NOT return any of the 846 properties defined by this document. This allows a binding server to 847 perform efficiently when a naive client, which does not understand 848 the cost of asking a server to compute all possible live properties, 849 issues a DAV:allprop PROPFIND request. 851 3.1. DAV:resource-id Property 853 The DAV:resource-id property is a REQUIRED property that enables 854 clients to determine whether two bindings are to the same resource. 856 The value of DAV:resource-id is a URI, and may use any registered URI 857 scheme that guarantees the uniqueness of the value across all 858 resources for all time (e.g. the urn:uuid: URN namespace defined in 859 [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]). 861 863 3.2. DAV:parent-set Property 865 The DAV:parent-set property is an OPTIONAL property that enables 866 clients to discover what collections contain a binding to this 867 resource (i.e. what collections have that resource as an internal 868 member). It contains an href/segment pair for each collection that 869 has a binding to the resource. The href identifies the collection, 870 and the segment identifies the binding name of that resource in that 871 collection. 873 A given collection MUST appear only once in the DAV:parent-set for 874 any given binding, even if there are multiple URI mappings to that 875 collection. 877 878 879 880 883 3.2.1. Example for DAV:parent-set Property 885 For example, if collection C1 is mapped to both /CollX and /CollY, 886 and C1 contains a binding named "x.gif" to a resource R1, then either 887 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 888 of R1, but not both. But if C1 also had a binding named "y.gif" to 889 R1, then there would be two entries for C1 in the DAV:parent-set of 890 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 891 both [/CollY, x.gif] and [/CollY, y.gif]). 893 +-------------------------+ 894 | Root Collection | 895 | bindings: | 896 | CollX CollY | 897 +-------------------------+ 898 | / 899 | / 900 | / 901 +-----------------+ 902 | Collection C1 | 903 | bindings: | 904 | x.gif y.gif | 905 +-----------------+ 906 | | 907 | | 908 | | 909 +-------------+ 910 | Resource R1 | 911 +-------------+ 913 In this case, one possible value for DAV:parent-set property on 914 "/CollX/x.gif" would be: 916 917 918 /CollX 919 x.gif 920 921 922 /CollX 923 y.gif 924 925 927 4. BIND Method 929 The BIND method modifies the collection identified by the Request- 930 URI, by adding a new binding from the segment specified in the BIND 931 body to the resource identified in the BIND body. 933 If a server cannot guarantee the integrity of the binding, the BIND 934 request MUST fail. Note that it is especially difficult to maintain 935 the integrity of cross-server bindings. Unless the server where the 936 resource resides knows about all bindings on all servers to that 937 resource, it may unwittingly destroy the resource or make it 938 inaccessible without notifying another server that manages a binding 939 to the resource. For example, if server A permits creation of a 940 binding to a resource on server B, server A must notify server B 941 about its binding and must have an agreement with B that B will not 942 destroy the resource while A's binding exists. Otherwise server B 943 may receive a DELETE request that it thinks removes the last binding 944 to the resource and destroy the resource while A's binding still 945 exists. The precondition DAV:cross-server-binding is defined below 946 for cases where servers fail cross-server BIND requests because they 947 cannot guarantee the integrity of cross-server bindings. 949 By default, if there already is a binding for the specified segment 950 in the collection, the new binding replaces the existing binding. 951 This default binding replacement behavior can be overridden using the 952 Overwrite header defined in Section 10.6 of [RFC4918]. 954 If a BIND request fails, the server state preceding the request MUST 955 be restored. This method is unsafe and idempotent (see [RFC2616], 956 Section 9.1). 958 Marshalling: 960 The request MAY include an Overwrite header. 962 The request body MUST be a DAV:bind XML element. 964 966 If the request succeeds, the server MUST return 201 (Created) when 967 a new binding was created and 200 (OK) or 204 (No Content) when an 968 existing binding was replaced. 970 If a response body for a successful request is included, it MUST 971 be a DAV:bind-response XML element. Note that this document does 972 not define any elements for the BIND response body, but the DAV: 973 bind-response element is defined to ensure interoperability 974 between future extensions that do define elements for the BIND 975 response body. 977 979 Preconditions: 981 (DAV:bind-into-collection): The Request-URI MUST identify a 982 collection. 984 (DAV:bind-source-exists): The DAV:href element MUST identify a 985 resource. 987 (DAV:binding-allowed): The resource identified by the DAV:href 988 supports multiple bindings to it. 990 (DAV:cross-server-binding): If the resource identified by the DAV: 991 href element in the request body is on another server from the 992 collection identified by the Request-URI, the server MUST support 993 cross-server bindings (servers that do not support cross-server 994 bindings can use this condition code to signal the client exactly 995 why the request failed). 997 (DAV:name-allowed): The name specified by the DAV:segment is 998 available for use as a new binding name. 1000 (DAV:can-overwrite): If the collection already contains a binding 1001 with the specified path segment, and if an Overwrite header is 1002 included, the value of the Overwrite header MUST be "T". 1004 (DAV:cycle-allowed): If the DAV:href element identifies a 1005 collection, and if the Request-URI identifies a collection that is 1006 a member of that collection, the server MUST support cycles in the 1007 URI namespace (servers that do not support cycles can use this 1008 condition code to signal the client exactly why the request 1009 failed). 1011 (DAV:locked-update-allowed): If the collection identified by the 1012 Request-URI is write-locked, then the appropriate token MUST be 1013 specified in an If request header. 1015 (DAV:locked-overwrite-allowed): If the collection already contains 1016 a binding with the specified path segment, and if that binding is 1017 protected by a write-lock, then the appropriate token MUST be 1018 specified in an If request header. 1020 Postconditions: 1022 (DAV:new-binding): The collection MUST have a binding that maps 1023 the segment specified in the DAV:segment element in the request 1024 body, to the resource identified by the DAV:href element in the 1025 request body. 1027 4.1. Example: BIND 1029 >> Request: 1031 BIND /CollY HTTP/1.1 1032 Host: www.example.com 1033 Content-Type: application/xml; charset="utf-8" 1034 Content-Length: 172 1036 1037 1038 bar.html 1039 http://www.example.com/CollX/foo.html 1040 1042 >> Response: 1044 HTTP/1.1 201 Created 1045 Location: http://www.example.com/CollY/bar.html 1047 The server added a new binding to the collection, 1048 "http://www.example.com/CollY", associating "bar.html" with the 1049 resource identified by the URI 1050 "http://www.example.com/CollX/foo.html". Clients can now use the URI 1051 "http://www.example.com/CollY/bar.html" to submit requests to that 1052 resource. 1054 5. UNBIND Method 1056 The UNBIND method modifies the collection identified by the Request- 1057 URI, by removing the binding identified by the segment specified in 1058 the UNBIND body. 1060 Once a resource is unreachable by any URI mapping, the server MAY 1061 reclaim system resources associated with that resource. If UNBIND 1062 removes a binding to a resource, but there remain URI mappings to 1063 that resource, the server MUST NOT reclaim system resources 1064 associated with the resource. 1066 If an UNBIND request fails, the server state preceding the request 1067 MUST be restored. This method is unsafe and idempotent (see 1068 [RFC2616], Section 9.1). 1070 Marshalling: 1072 The request body MUST be a DAV:unbind XML element. 1074 1076 If the request succeeds, the server MUST return 200 (OK) or 204 1077 (No Content) when the binding was successfully deleted. 1079 If a response body for a successful request is included, it MUST 1080 be a DAV:unbind-response XML element. Note that this document 1081 does not define any elements for the UNBIND response body, but the 1082 DAV:unbind-response element is defined to ensure interoperability 1083 between future extensions that do define elements for the UNBIND 1084 response body. 1086 1088 Preconditions: 1090 (DAV:unbind-from-collection): The Request-URI MUST identify a 1091 collection. 1093 (DAV:unbind-source-exists): The DAV:segment element MUST identify 1094 a binding in the collection identified by the Request-URI. 1096 (DAV:locked-update-allowed): If the collection identified by the 1097 Request-URI is write-locked, then the appropriate token MUST be 1098 specified in the request. 1100 (DAV:protected-url-deletion-allowed): If the binding identified by 1101 the segment is protected by a write-lock, then the appropriate 1102 token MUST be specified in the request. 1104 Postconditions: 1106 (DAV:binding-deleted): The collection MUST NOT have a binding for 1107 the segment specified in the DAV:segment element in the request 1108 body. 1110 (DAV:lock-deleted): If the internal member URI of the binding 1111 specified by the Request-URI and the DAV:segment element in the 1112 request body was protected by a write-lock at the time of the 1113 request, that write-lock must have been deleted by the request. 1115 5.1. Example: UNBIND 1117 >> Request: 1119 UNBIND /CollX HTTP/1.1 1120 Host: www.example.com 1121 Content-Type: application/xml; charset="utf-8" 1122 Content-Length: 117 1124 1125 1126 foo.html 1127 1129 >> Response: 1131 HTTP/1.1 200 OK 1133 The server removed the binding named "foo.html" from the collection, 1134 "http://www.example.com/CollX". A request to the resource named 1135 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1136 response. 1138 6. REBIND Method 1140 The REBIND method removes a binding to a resource from a collection, 1141 and adds a binding to that resource into the collection identified by 1142 the Request-URI. The request body specifies the binding to be added 1143 (segment) and the old binding to be removed (href). It is 1144 effectively an atomic form of a MOVE request, and MUST be treated the 1145 same way as MOVE for the purpose of determining access permissions. 1147 If a REBIND request fails, the server state preceding the request 1148 MUST be restored. This method is unsafe and idempotent (see 1149 [RFC2616], Section 9.1). 1151 Marshalling: 1153 The request MAY include an Overwrite header. 1155 The request body MUST be a DAV:rebind XML element. 1157 1159 If the request succeeds, the server MUST return 201 (Created) when 1160 a new binding was created and 200 (OK) or 204 (No Content) when an 1161 existing binding was replaced. 1163 If a response body for a successful request is included, it MUST 1164 be a DAV:rebind-response XML element. Note that this document 1165 does not define any elements for the REBIND response body, but the 1166 DAV:rebind-response element is defined to ensure interoperability 1167 between future extensions that do define elements for the REBIND 1168 response body. 1170 1172 Preconditions: 1174 (DAV:rebind-into-collection): The Request-URI MUST identify a 1175 collection. 1177 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1178 resource. 1180 (DAV:cross-server-binding): If the resource identified by the DAV: 1181 href element in the request body is on another server from the 1182 collection identified by the Request-URI, the server MUST support 1183 cross-server bindings (servers that do not support cross-server 1184 bindings can use this condition code to signal the client exactly 1185 why the request failed). 1187 (DAV:name-allowed): The name specified by the DAV:segment is 1188 available for use as a new binding name. 1190 (DAV:can-overwrite): If the collection already contains a binding 1191 with the specified path segment, and if an Overwrite header is 1192 included, the value of the Overwrite header MUST be "T". 1194 (DAV:cycle-allowed): If the DAV:href element identifies a 1195 collection, and if the Request-URI identifies a collection that is 1196 a member of that collection, the server MUST support cycles in the 1197 URI namespace (servers that do not support cycles can use this 1198 condition code to signal the client exactly why the request 1199 failed). 1201 (DAV:locked-update-allowed): If the collection identified by the 1202 Request-URI is write-locked, then the appropriate token MUST be 1203 specified in the request. 1205 (DAV:protected-url-modification-allowed): If the collection 1206 identified by the Request-URI already contains a binding with the 1207 specified path segment, and if that binding is protected by a 1208 write-lock, then the appropriate token MUST be specified in the 1209 request. 1211 (DAV:locked-source-collection-update-allowed): If the collection 1212 identified by the parent collection prefix of the DAV:href URI is 1213 write-locked, then the appropriate token MUST be specified in the 1214 request. 1216 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1217 is protected by a write lock, then the appropriate token MUST be 1218 specified in the request. 1220 Postconditions: 1222 (DAV:new-binding): The collection MUST have a binding that maps 1223 the segment specified in the DAV:segment element in the request 1224 body, to the resource that was identified by the DAV:href element 1225 in the request body. 1227 (DAV:binding-deleted): The URL specified in the DAV:href element 1228 in the request body MUST NOT be mapped to a resource. 1230 (DAV:lock-deleted): If the URL specified in the DAV:href element 1231 in the request body was protected by a write-lock at the time of 1232 the request, that write-lock must have been deleted by the 1233 request. 1235 6.1. Example: REBIND 1237 >> Request: 1239 REBIND /CollX HTTP/1.1 1240 Host: www.example.com 1241 Content-Type: application/xml; charset="utf-8" 1242 Content-Length: 176 1244 1245 1246 foo.html 1247 http://www.example.com/CollY/bar.html 1248 1250 >> Response: 1252 HTTP/1.1 200 OK 1254 The server added a new binding to the collection, 1255 "http://www.example.com/CollX", associating "foo.html" with the 1256 resource identified by the URI 1257 "http://www.example.com/CollY/bar.html", and removes the binding 1258 named "bar.html" from the collection identified by the URI 1259 "http://www.example.com/CollY". Clients can now use the URI 1260 "http://www.example.com/CollX/foo.html" to submit requests to that 1261 resource, and requests on the URI 1262 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1263 Found) response. 1265 6.2. Example: REBIND in Presence of Locks and Bind Loops 1267 To illustrate the effects of locks and bind loops on a REBIND 1268 operation, consider the following collection: 1270 +------------------+ 1271 | Root Collection | 1272 | bindings: | 1273 | CollW | 1274 +------------------+ 1275 | 1276 | 1277 | 1278 +-------------------------------+ 1279 | Collection C1 |<--------+ 1280 | LOCKED infinity | | 1281 | (lock token L1) | | 1282 | bindings: | | 1283 | CollX CollY | | 1284 +-------------------------------+ | 1285 | | | 1286 | | (creates loop) | 1287 | | | 1288 +-----------------+ +------------------+ | 1289 | Collection C2 | | Collection C3 | | 1290 | (inherit lock) | | (inherit lock) | | 1291 | (lock token L1) | | (lock token L1) | | 1292 | bindings: | | bindings: | | 1293 | {none} | | y.gif CollZ | | 1294 +-----------------+ +------------------+ | 1295 | | | 1296 | +-----+ 1297 | 1298 +---------------------------+ 1299 | Resource R2 | 1300 | (lock inherited from C1) | 1301 | (lock token L1) | 1302 +---------------------------+ 1304 (where L1 is "urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1306 Note that the binding between CollZ and C1 creates a loop in the 1307 containment hierarchy. Servers are not required to support such 1308 loops, though the server in this example does. 1310 The REBIND request below will remove the segment "CollZ" from C3 and 1311 add a new binding from "CollA" to the collection C2. 1313 REBIND /CollW/CollX HTTP/1.1 1314 Host: www.example.com 1315 If: () 1316 Content-Type: application/xml; charset="utf-8" 1317 Content-Length: 152 1319 1320 1321 CollA 1322 /CollW/CollY/CollZ 1323 1324 The outcome of the REBIND operation is: 1326 +------------------+ 1327 | Root Collection | 1328 | bindings: | 1329 | CollW | 1330 +------------------+ 1331 | 1332 | 1333 | 1334 +-------------------------------+ 1335 | Collection C1 | 1336 | LOCKED infinity | 1337 | (lock token L1) | 1338 | bindings: | 1339 | CollX CollY | 1340 +-------------------------------+ 1341 | ^ | 1342 | | | 1343 +-----------------+ | +------------------+ 1344 | Collection C2 | | | Collection C3 | 1345 |(inherited lock) | | | (inherited lock) | 1346 |(lock token L1) | | | (lock token L1) | 1347 | bindings: | | | bindings: | 1348 | CollA | | | y.gif | 1349 +-----------------+ | +------------------+ 1350 | | | 1351 +---------------+ | 1352 (creates loop) | 1353 +---------------------------+ 1354 | Resource R2 | 1355 | (inherited lock from C1) | 1356 | (lock token L1) | 1357 +---------------------------+ 1359 7. Additional Status Codes 1361 7.1. 208 Already Reported 1363 The 208 (Already Reported) status code can be used inside a DAV: 1364 propstat response element to avoid enumerating the internal members 1365 of multiple bindings to the same collection repeatedly. For each 1366 binding to a collection inside the request's scope, only one will be 1367 reported with a 200 status, while subsequent DAV:response elements 1368 for all other bindings will use the 208 status, and no DAV:response 1369 elements for their descendants are included. 1371 Note that the 208 status will only occur for "Depth: infinity" 1372 requests, and that it is of particular importance when the multiple 1373 collection bindings cause a bind loop as discussed in Section 2.2. 1375 A client can request the DAV:resource-id property in a PROPFIND 1376 request to guarantee that they can accurately reconstruct the binding 1377 structure of a collection with multiple bindings to a single 1378 resource. 1380 For backward compatibility with clients not aware of the 208 status 1381 code appearing in multistatus response bodies, it SHOULD NOT be used 1382 unless the client has signalled support for this specification using 1383 the "DAV" request header (see Section 8.2). Instead, a 506 status 1384 should be returned when a binding loop is discovered. This allows 1385 the server to return the 506 as the top level return status, if it 1386 discovers it before it started the response, or in the middle of a 1387 multistatus, if it discovers it in the middle of streaming out a 1388 multistatus response. 1390 7.1.1. Example: PROPFIND by Bind-Aware Client 1392 For example, consider a PROPFIND request on /Coll (bound to 1393 collection C), where the members of /Coll are /Coll/Foo (bound to 1394 resource R) and /Coll/Bar (bound to collection C). 1396 >> Request: 1398 PROPFIND /Coll/ HTTP/1.1 1399 Host: www.example.com 1400 Depth: infinity 1401 DAV: bind 1402 Content-Type: application/xml; charset="utf-8" 1403 Content-Length: 152 1405 1406 1407 1408 1409 1410 1411 1413 >> Response: 1415 HTTP/1.1 207 Multi-Status 1416 Content-Type: application/xml; charset="utf-8" 1417 Content-Length: 1241 1419 1420 1421 1422 http://www.example.com/Coll/ 1423 1424 1425 Loop Demo 1426 1427 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1429 1430 1431 HTTP/1.1 200 OK 1432 1433 1434 1435 http://www.example.com/Coll/Foo 1436 1437 1438 Bird Inventory 1439 1440 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1442 1443 1444 HTTP/1.1 200 OK 1445 1446 1447 1448 http://www.example.com/Coll/Bar 1449 1450 1451 Loop Demo 1452 1453 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1455 1456 1457 HTTP/1.1 208 Already Reported 1458 1459 1460 1462 7.1.2. Example: PROPFIND by Non-Bind-Aware Client 1464 In this example, the client isn't aware of the 208 status code 1465 introduced by this specification. As the "Depth: infinity" PROPFIND 1466 request would cause a loop condition, the whole request is rejected 1467 with a 506 status. 1469 >> Request: 1471 PROPFIND /Coll/ HTTP/1.1 1472 Host: www.example.com 1473 Depth: infinity 1474 Content-Type: application/xml; charset="utf-8" 1475 Content-Length: 125 1477 1478 1479 1480 1482 >> Response: 1484 HTTP/1.1 506 Loop Detected 1486 7.2. 506 Loop Detected 1488 The 506 (Loop Detected) status code indicates that the server 1489 terminated an operation because it encountered an infinite loop while 1490 processing a request with "Depth: infinity". This status indicates 1491 that the entire operation failed. 1493 8. Capability Discovery 1495 8.1. OPTIONS Method 1497 If the server supports bindings, it MUST return the compliance class 1498 name "bind" as a field in the "DAV" response header (see [RFC4918], 1499 Section 10.1) from an OPTIONS request on any resource implemented by 1500 that server. A value of "bind" in the "DAV" header MUST indicate 1501 that the server supports all MUST level requirements and REQUIRED 1502 features specified in this document. 1504 8.2. 'DAV' Request Header 1506 Clients SHOULD signal support for all MUST level requirements and 1507 REQUIRED features by submitting a "DAV" request header containing the 1508 compliance class name "bind". In particular, the client MUST 1509 understand the 208 status code defined in Section 7.1. 1511 9. Relationship to WebDAV Access Control Protocol 1513 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1514 property (see [RFC3744], Section 7.3). 1516 10. Relationship to Versioning Extensions to WebDAV 1518 Servers that implement Workspaces ([RFC3253], Section 6) and Version 1519 Controlled Collections ([RFC3253], Section 14) already need to 1520 implement BIND-like behaviour in order to handle UPDATE and 1521 UNCHECKOUT semantics. 1523 Consider a workspace "/ws1/", containing the version-controlled, 1524 checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ 1525 CollY", and a version-controlled resource R, bound to C1 as "/ws1/ 1526 CollX/test": 1528 +-------------------------+ 1529 | Workspace | 1530 | bindings: | 1531 | CollX CollY | 1532 +-------------------------+ 1533 | | 1534 | | 1535 | | 1536 +---------------+ +---------------+ 1537 | Collection C1 | | Collection C2 | 1538 | bindings: | | | 1539 | test | | | 1540 +---------------+ +---------------+ 1541 | 1542 | 1543 | 1544 +------------------+ 1545 | Resource R | 1546 +------------------+ 1548 Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but 1549 undoing the checkout on C1 will undo part of the MOVE request, thus 1550 restoring the binding from C1 to R, but keeping the new binding from 1551 C2 to R: 1553 >> Request: 1555 MOVE /ws1/CollX/test HTTP/1.1 1556 Host: www.example.com 1557 Destination: /ws1/CollY/test 1559 >> Response: 1561 HTTP/1.1 204 No Content 1563 >> Request: 1565 CHECKIN /ws1/CollY/ HTTP/1.1 1566 Host: www.example.com 1568 >> Response: 1570 HTTP/1.1 201 Created 1571 Cache-Control: no-cache 1572 Location: http://repo.example.com/his/17/ver/42 1574 >> Request: 1576 UNCHECKOUT /ws1/CollX/ HTTP/1.1 1577 Host: www.example.com 1579 >> Response: 1581 HTTP/1.1 200 OK 1582 Cache-Control: no-cache 1584 As a result, both C1 and C2 would have a binding to R: 1586 +-------------------------+ 1587 | Workspace | 1588 | bindings: | 1589 | CollX CollY | 1590 +-------------------------+ 1591 | | 1592 | | 1593 | | 1594 +---------------+ +---------------+ 1595 | Collection C1 | | Collection C2 | 1596 | bindings: | | bindings: | 1597 | test | | test | 1598 +---------------+ +---------------+ 1599 | | 1600 | | 1601 | | 1602 +------------------+ 1603 | Resource R | 1604 +------------------+ 1606 The MOVE semantics defined in Section 3.15 of [RFC3253] already 1607 require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the 1608 same version history (as exposed in the DAV:version-history 1609 property). Furthermore, the UNCHECKOUT semantics (which in this case 1610 is similar to UPDATE, see Section 14.11 of [RFC3253]) require: 1612 ...If a new version-controlled member is in a workspace that 1613 already has a version-controlled resource for that version 1614 history, then the new version-controlled member MUST be just a 1615 binding (i.e., another name for) that existing version-controlled 1616 resource... 1618 Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the 1619 same resource R, and have identical DAV:resource-id properties. 1621 11. Security Considerations 1623 This section is provided to make WebDAV implementors aware of the 1624 security implications of this protocol. 1626 All of the security considerations of HTTP/1.1 and the WebDAV 1627 Distributed Authoring Protocol specification also apply to this 1628 protocol specification. In addition, bindings introduce several new 1629 security concerns and increase the risk of some existing threats. 1630 These issues are detailed below. 1632 11.1. Privacy Concerns 1634 In a context where cross-server bindings are supported, creating 1635 bindings on a trusted server may make it possible for a hostile agent 1636 to induce users to send private information to a target on a 1637 different server. 1639 11.2. Bind Loops 1641 Although bind loops were already possible in HTTP 1.1, the 1642 introduction of the BIND method creates a new avenue for clients to 1643 create loops accidentally or maliciously. If the binding and its 1644 target are on the same server, the server may be able to detect BIND 1645 requests that would create loops. Servers are required to detect 1646 loops that are caused by bindings to collections during the 1647 processing of any requests with "Depth: infinity". 1649 11.3. Bindings, and Denial of Service 1651 Denial of service attacks were already possible by posting URIs that 1652 were intended for limited use at heavily used Web sites. The 1653 introduction of BIND creates a new avenue for similar denial of 1654 service attacks. If cross-server bindings are supported, clients can 1655 now create bindings at heavily used sites to target locations that 1656 were not designed for heavy usage. 1658 11.4. Private Locations May Be Revealed 1660 If the DAV:parent-set property is maintained on a resource, the 1661 owners of the bindings risk revealing private locations. The 1662 directory structures where bindings are located are available to 1663 anyone who has access to the DAV:parent-set property on the resource. 1664 Moving a binding may reveal its new location to anyone with access to 1665 DAV:parent-set on its resource. 1667 11.5. DAV:parent-set and Denial of Service 1669 If the server maintains the DAV:parent-set property in response to 1670 bindings created in other administrative domains, it is exposed to 1671 hostile attempts to make it devote resources to adding bindings to 1672 the list. 1674 12. Internationalization Considerations 1676 All internationalization considerations mentioned in [RFC4918] also 1677 apply to this document. 1679 13. IANA Considerations 1681 Section 7 defines the HTTP status codes 208 (Already Reported) and 1682 506 (Loop Detected), to be added to the registry at 1683 . 1685 14. Acknowledgements 1687 This document is the collaborative product of the authors and Tyson 1688 Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited 1689 from thoughtful discussion by Jim Amsden, Peter Carlson, Steve 1690 Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Cyrus 1691 Daboo, Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David 1692 Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, 1693 Joe Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, 1694 Chris Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1695 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Alexey 1696 Melnikov, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley 1697 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin 1698 Wiggen, and other members of the WebDAV working group. 1700 15. References 1702 15.1. Normative References 1704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1705 Requirement Levels", BCP 14, RFC 2119, March 1997. 1707 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1708 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1709 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1711 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1712 Resource Identifier (URI): Generic Syntax", STD 66, 1713 RFC 3986, January 2005. 1715 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1716 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1718 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1719 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1720 Edition)", W3C REC-xml-20081126, November 2008, 1721 . 1723 15.2. Informative References 1725 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1726 Whitehead, "Versioning Extensions to WebDAV (Web 1727 Distributed Authoring and Versioning)", RFC 3253, 1728 March 2002. 1730 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1731 Distributed Authoring and Versioning (WebDAV) Access 1732 Control Protocol", RFC 3744, May 2004. 1734 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1735 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1736 July 2005. 1738 Appendix A. Clarification to RFC2518bis' Usage of the term 'lock root' 1740 [RFC4918], Section 9.10.1 claims: 1742 A LOCK request to an existing resource will create a lock on the 1743 resource identified by the Request-URI, provided the resource is 1744 not already locked with a conflicting lock. The resource 1745 identified in the Request-URI becomes the root of the lock. 1747 This is incorrect in that it implies that the "lock root" is a 1748 resource, not a URL 1749 (). However, 1750 should a directly locked resource have multiple bindings, only the 1751 one used in the Request-URI of the LOCK request will be the protected 1752 from changes of clients not supplying the lock token. 1754 A correct description would be: 1756 A LOCK request to an existing resource will create a lock on the 1757 resource identified by the Request-URI, provided the resource is 1758 not already locked with a conflicting lock. The Request-URI 1759 becomes the root of the lock. 1761 Note that this change makes the description consistent with the 1762 definition of the DAV:lockroot XML element in Section 14.12 of 1763 [RFC4918]. 1765 The authors of this specification recommend that future revisions of 1766 [RFC4918] will update the description as suggested above. 1768 Appendix B. Change Log (to be removed by RFC Editor before publication) 1770 B.1. Since draft-ietf-webdav-bind-02 1772 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1773 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1774 resolution, but keep it open. Add issues "ED_references" and 1775 "4_507_status". Started work on index. Rename document to "Binding 1776 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1777 Rename "References" to "Normative References". Close issue 1778 "ED_references". Close issue "4_507_status". 1780 B.2. Since draft-ietf-webdav-bind-03 1782 Add and close issues "9.2_redirect_loops", "ED_authors" and 1783 "ED_updates". Add section about capability discovery (DAV header). 1784 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1785 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1786 "locking" and resolve as invalid. 1788 B.3. Since draft-ietf-webdav-bind-04 1790 Add and close issues "6_precondition_binding_allowed" and 1791 "6_lock_behaviour". Add mailing list and issues list pointers to 1792 front. 1794 B.4. Since draft-ietf-webdav-bind-05 1796 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1797 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1798 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1800 B.5. Since draft-ietf-webdav-bind-06 1802 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1803 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1805 B.6. Since draft-ietf-webdav-bind-07 1807 Add more index items (no change tracking). Add and resolve issues 1808 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1809 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1810 DTD fragment in section 3.3. Make spelling of "Request-URI" 1811 consistent. 1813 B.7. Since draft-ietf-webdav-bind-08 1815 Resolved editorial issues raised by Jim Whitehead in . 1817 Add and resolve issues "atomicity", "2_allow_destroy", 1818 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1819 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1820 "2.6_resource-id_vs_versions", "3.2_example" and 1821 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1822 and resolve "6_rebind_intro". 1824 B.8. Since draft-ietf-webdav-bind-09 1826 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1827 text. Add action item "3.1_uuids". Close issue 1828 "2.6_when_do_ids_change". Add and resolve issues 1829 "2.6_bindings_vs_properties" and "uri_draft_ref". 1831 B.9. Since draft-ietf-webdav-bind-10 1833 Resolve action item "3.1_uuids". Add and resolve issue 1834 "2.7_unlock_vs_bindings". Revisit issue 1835 "2.6_bindings_vs_properties", and remove the part of the sentence 1836 that speaks about live properties. Update "rfc2396bis" references to 1837 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1838 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1840 B.10. Since draft-ietf-webdav-bind-11 1842 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1843 live properties in Section 2.6. 1845 B.11. Since draft-ietf-webdav-bind-12 1847 Updated Author's address. Uppercase "Section" when referring to 1848 other documents. 1850 Updating from RFC2518 to RFC2518bis: 1852 o Remove own explanation of DTD syntax. 1854 o Remove own definition of precondition/postcondition. 1856 o Remove reference to broken RFC2518 language about DELETE and 1857 UNLOCK. 1859 o Remove own definition of DAV: request header. 1861 o Updated "Rationale for Distinguishing Bindings from URI Mappings" 1862 to reflect the changes in [draft-ietf-webdav-rfc2518bis], making 1863 proposals for more changes so that the issue can be closed (see 1864 also 1865 and ). 1868 B.12. Since draft-ietf-webdav-bind-13 1870 Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one 1871 incorrect section reference. Remove Section "Rationale for 1872 Distinguishing Bindings from URI Mappings" as 1873 [draft-ietf-webdav-rfc2518-bis] now uses the proper definition of 1874 collection state. Examples use application/xml instead of text/xml 1875 MIME type. 1877 Fix IANA section (there are no IANA considerations). 1879 B.13. Since draft-ietf-webdav-bind-14 1881 Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to 1882 4th edition. 1884 Markup ASCII art for box recognition (doesn't affect ASCII version). 1886 Identify Julian Reschke as Editor. 1888 B.14. Since draft-ietf-webdav-bind-15 1890 Fix typo in RFC2119 keywords section (sorry!). 1892 Update [draft-ietf-webdav-rfc2518-bis] to draft 17. 1894 Add and resolve issue "rfc2518bis-lock-root". 1896 B.15. Since draft-ietf-webdav-bind-16 1898 Add and resolve issue "iana-vs-http-status". 1900 B.16. Since draft-ietf-webdav-bind-17 1902 Update rfc2518bis reference to draft 18 (note that the bug reported 1903 in 1904 is still present). 1906 B.17. Since draft-ietf-webdav-bind-18 1908 Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918. 1910 B.18. Since draft-ietf-webdav-bind-19 1912 Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move- 1913 creating-cycles", "3.1-clarify-resource-id" and "4-precondition- 1914 language". 1916 B.19. Since draft-ietf-webdav-bind-20 1918 Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples. 1919 Replace RFC2518bis issue link by pointer to RFC Errata Page. 1921 Add issues "relation-to-deltav" and "status-codes". 1923 B.20. Since draft-ietf-webdav-bind-21 1925 Resolve issues "relation-to-deltav" and "status-codes". 1927 Add correct content length values to examples (no change bars). 1929 B.21. Since draft-ietf-webdav-bind-22 1931 Set "Intended Status" to "Experimental". 1933 Update XML reference to "Extensible Markup Language (XML) 1.0 (Fifth 1934 Edition)". 1936 B.22. Since draft-ietf-webdav-bind-23 1938 Remove surplus white space from one example. 1940 Fix typo: "DAV:binding-set" -> "DAV:parent-set". 1942 Add and resolve issues "clarify-alternate-uri", "def-integrity", "ex- 1943 copy-multiple-update", "ex-copy-graph", and "ex-live-property". 1945 Appendix C. Resolved issues (to be removed by RFC Editor before 1946 publication) 1948 Issues that were either rejected or resolved in this version of this 1949 document. 1951 C.1. edit 1953 Type: edit 1955 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1956 editorial fixes/enhancements. 1958 C.2. def-integrity 1960 In Section 1: 1962 Type: change 1964 alexey.melnikov@isode.com (2009-05-15): Define the term "integrity". 1966 Resolution (2009-05-28): Add definition to Terminology Section. 1968 C.3. ex-copy-multiple-update 1970 In Section 2.3: 1972 Type: edit 1974 alexey.melnikov@isode.com (2009-05-15): Add example for the case: "If 1975 because of multiple bindings to a resource, more than one source 1976 resource updates a single destination resource, the order of the 1977 updates is server defined." 1979 Resolution (2009-05-25): Example added. 1981 C.4. ex-copy-graph 1983 In Section 2.3: 1985 Type: edit 1987 alexey.melnikov@isode.com (2009-05-15): Add example for the case 1988 discussed below: "If a COPY request would cause a new resource to be 1989 created as a copy of an existing resource, and that COPY request has 1990 already created a copy of that existing resource, ..." 1992 julian.reschke@greenbytes.de (2009-05-18): It seems that we already 1993 have that example, see "2.3.2. Example: COPY with 'Depth: infinity' 1994 with Multiple Bindings to a Leaf Resource". 1996 Resolution (2009-05-25): Added forward reference to example. 1998 C.5. ex-live-property 2000 In Section 2.6: 2002 Type: edit 2004 alexey.melnikov@isode.com (2009-05-15): Give an example of a live 2005 property where the value depends on the path. 2007 julian.reschke@greenbytes.de (2009-05-19): Thread in which the latest 2008 version of this paragraph was discussed: . 2011 C.6. clarify-alternate-uri 2013 In Section 3.1: 2015 Type: change 2017 alexey.melnikov@isode.com (2009-05-15): The note about resource-id 2018 being an alternate URI is confusing. 2020 julian.reschke@greenbytes.de (2009-05-25): This was added in draft 2021 19, dealing with issue "3.1-clarify-resource-id" (). 2024 See also . Proposal: either clarify (expand) or remove 2026 it. 2028 Resolution (2009-05-25): Statement removed. 2030 Index 2032 2 2033 208 Already Reported (status code) 32, 40 2035 5 2036 506 Loop Detected (status code) 35, 40 2038 B 2039 BIND method 22 2040 Marshalling 23 2041 Postconditions 24 2042 Preconditions 23 2043 Binding 7 2044 Binding Integrity 7-8, 22 2046 C 2047 Collection 7 2048 Condition Names 2049 DAV:bind-into-collection (pre) 23 2050 DAV:bind-source-exists (pre) 23 2051 DAV:binding-allowed (pre) 24 2052 DAV:binding-deleted (post) 26, 29 2053 DAV:can-overwrite (pre) 24, 28 2054 DAV:cross-server-binding (pre) 24, 28 2055 DAV:cycle-allowed (pre) 24, 28 2056 DAV:lock-deleted (post) 26, 29 2057 DAV:locked-overwrite-allowed (pre) 24 2058 DAV:locked-source-collection-update-allowed (pre) 29 2059 DAV:locked-update-allowed (pre) 24, 26, 28 2060 DAV:name-allowed (pre) 24, 28 2061 DAV:new-binding (post) 24, 29 2062 DAV:protected-source-url-deletion-allowed (pre) 29 2063 DAV:protected-url-deletion-allowed (pre) 26 2064 DAV:protected-url-modification-allowed (pre) 28 2065 DAV:rebind-from-collection (pre) 28 2066 DAV:rebind-source-exists (pre) 28 2067 DAV:unbind-from-collection (pre) 26 2068 DAV:unbind-source-exists (pre) 26 2070 D 2071 DAV header 2072 compliance class 'bind' 35 2073 DAV:bind-into-collection precondition 23 2074 DAV:bind-source-exists precondition 23 2075 DAV:binding-allowed precondition 24 2076 DAV:binding-deleted postcondition 26, 29 2077 DAV:can-overwrite precondition 24, 28 2078 DAV:cross-server-binding precondition 24, 28 2079 DAV:cycle-allowed precondition 24, 28 2080 DAV:lock-deleted postcondition 26, 29 2081 DAV:locked-overwrite-allowed precondition 24 2082 DAV:locked-source-collection-update-allowed precondition 29 2083 DAV:locked-update-allowed precondition 24, 26, 28 2084 DAV:name-allowed precondition 24, 28 2085 DAV:new-binding postcondition 24, 29 2086 DAV:parent-set property 21 2087 DAV:protected-source-url-deletion-allowed precondition 29 2088 DAV:protected-url-deletion-allowed precondition 26 2089 DAV:protected-url-modification-allowed precondition 28 2090 DAV:rebind-from-collection precondition 28 2091 DAV:rebind-source-exists precondition 28 2092 DAV:resource-id property 20 2093 DAV:unbind-from-collection precondition 26 2094 DAV:unbind-source-exists precondition 26 2096 I 2097 Internal Member URI 7 2099 M 2100 Methods 2101 BIND 22 2102 REBIND 27 2103 UNBIND 25 2105 P 2106 Path Segment 6 2107 Properties 2108 DAV:parent-set 21 2109 DAV:resource-id 20 2111 R 2112 REBIND method 27 2113 Marshalling 27 2114 Postconditions 29 2115 Preconditions 28 2117 S 2118 Status Codes 2119 208 Already Reported 32, 40 2120 506 Loop Detected 35, 40 2122 U 2123 UNBIND method 25 2124 Marshalling 25 2125 Postconditions 26 2126 Preconditions 26 2127 URI Mapping 6 2129 Authors' Addresses 2131 Geoffrey Clemm 2132 IBM 2133 20 Maguire Road 2134 Lexington, MA 02421 2136 Email: geoffrey.clemm@us.ibm.com 2137 Jason Crawford 2138 IBM Research 2139 P.O. Box 704 2140 Yorktown Heights, NY 10598 2142 Email: ccjason@us.ibm.com 2144 Julian F. Reschke (editor) 2145 greenbytes GmbH 2146 Hafenweg 16 2147 Muenster, NW 48155 2148 Germany 2150 Email: julian.reschke@greenbytes.de 2152 Jim Whitehead 2153 UC Santa Cruz, Dept. of Computer Science 2154 1156 High Street 2155 Santa Cruz, CA 95064 2157 Email: ejw@cse.ucsc.edu