idnits 2.17.1 draft-ietf-webdav-bind-15.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 on line 1756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1780. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-webdav-rfc2518bis', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-webdav-rfc2518bis', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-webdav-rfc2518bis', but the file name used is 'draft-ietf-webdav-bind-15' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 536 has weird spacing: '...| x.gif y.g...' == Line 558 has weird spacing: '...| x.gif y.g...' == Line 764 has weird spacing: '...| x.gif y.g...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 27, 2006) is 6445 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: 5 errors (**), 1 flaw (~~), 6 warnings (==), 8 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: J. Crawford 5 draft-ietf-webdav-rfc2518bis (if IBM Research 6 approved) J. Reschke, Ed. 7 Intended status: Standards Track greenbytes 8 Expires: February 28, 2007 J. Whitehead 9 U.C. Santa Cruz 10 August 27, 2006 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-15 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 February 28, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This specification defines bindings, and the BIND method for creating 47 multiple bindings to the same resource. Creating a new binding to a 48 resource causes at least one new URI to be mapped to that resource. 50 Servers are required to insure the integrity of any bindings that 51 they allow to be created. 53 Editorial Note (To be removed by RFC Editor before publication) 55 Please send comments to the Distributed Authoring and Versioning 56 (WebDAV) working group at , which may be 57 joined by sending a message with subject "subscribe" to 58 . Discussions of the WEBDAV 59 working group are archived at 60 . 62 lists 63 all registered issues since draft 02. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2. Method Preconditions and Postconditions . . . . . . . . . 6 70 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 7 72 2.1.1. Bind loops . . . . . . . . . . . . . . . . . . . . . . 8 73 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 8 74 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 9 75 2.3.1. Example: COPY with 'Depth: infinity' in presence 76 of bind loops . . . . . . . . . . . . . . . . . . . . 11 77 2.3.2. Example: COPY with 'Depth: infinity' with multiple 78 bindings to a leaf resource . . . . . . . . . . . . . 13 79 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 14 80 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 14 81 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 15 82 2.7. Determining Whether Two Bindings Are to the Same 83 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 16 85 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 17 87 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 17 88 3.2.1. Example for DAV:parent-set property . . . . . . . . . 17 89 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 21 91 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 21 92 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 23 93 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 23 94 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 25 95 6.2. Example: REBIND in presence of locks and bind loops . . . 26 96 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 28 97 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 28 98 7.1.1. Example: PROPFIND by bind-aware client . . . . . . . . 29 99 7.1.2. Example: PROPFIND by non-bind-aware client . . . . . . 31 100 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 31 101 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 31 102 8.1. OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 31 103 8.2. 'DAV' request header . . . . . . . . . . . . . . . . . . . 31 104 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 32 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 106 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 32 107 10.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 32 108 10.3. Bindings, and Denial of Service . . . . . . . . . . . . . 32 109 10.4. Private Locations May Be Revealed . . . . . . . . . . . . 33 110 10.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 33 111 11. Internationalization Considerations . . . . . . . . . . . . . 33 112 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 113 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 116 14.2. Informative References . . . . . . . . . . . . . . . . . . 34 117 Appendix A. Change Log (to be removed by RFC Editor before 118 publication) . . . . . . . . . . . . . . . . . . . . 34 119 A.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 34 120 A.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 35 121 A.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 35 122 A.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 35 123 A.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 35 124 A.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 35 125 A.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 35 126 A.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 36 127 A.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 36 128 A.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 36 129 A.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 36 130 A.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 37 131 A.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 37 132 Appendix B. Open issues (to be removed by RFC Editor prior to 133 publication) . . . . . . . . . . . . . . . . . . . . 37 134 B.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 135 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 137 Intellectual Property and Copyright Statements . . . . . . . . . . 41 139 1. Introduction 141 This specification extends the WebDAV Distributed Authoring Protocol 142 ([draft-ietf-webdav-rfc2518bis]) to enable clients to create new 143 access paths to existing resources. This capability is useful for 144 several reasons: 146 URIs of WebDAV-compliant resources are hierarchical and correspond to 147 a hierarchy of collections in resource space. The WebDAV Distributed 148 Authoring Protocol makes it possible to organize these resources into 149 hierarchies, placing them into groupings, known as collections, which 150 are more easily browsed and manipulated than a single flat 151 collection. However, hierarchies require categorization decisions 152 that locate resources at a single location in the hierarchy, a 153 drawback when a resource has multiple valid categories. For example, 154 in a hierarchy of vehicle descriptions containing collections for 155 cars and boats, a description of a combination car/boat vehicle could 156 belong in either collection. Ideally, the description should be 157 accessible from both. Allowing clients to create new URIs that 158 access the existing resource lets them put that resource into 159 multiple collections. 161 Hierarchies also make resource sharing more difficult, since 162 resources that have utility across many collections are still forced 163 into a single collection. For example, the mathematics department at 164 one university might create a collection of information on fractals 165 that contains bindings to some local resources, but also provides 166 access to some resources at other universities. For many reasons, it 167 may be undesirable to make physical copies of the shared resources on 168 the local server: to conserve disk space, to respect copyright 169 constraints, or to make any changes in the shared resources visible 170 automatically. Being able to create new access paths to existing 171 resources in other collections or even on other servers is useful for 172 this sort of case. 174 The BIND method defined here provides a mechanism for allowing 175 clients to create alternative access paths to existing WebDAV 176 resources. HTTP [RFC2616] and WebDAV [draft-ietf-webdav-rfc2518bis] 177 methods are able to work because there are mappings between URIs and 178 resources. A method is addressed to a URI, and the server follows 179 the mapping from that URI to a resource, applying the method to that 180 resource. Multiple URIs may be mapped to the same resource, but 181 until now there has been no way for clients to create additional URIs 182 mapped to existing resources. 184 BIND lets clients associate a new URI with an existing WebDAV 185 resource, and this URI can then be used to submit requests to the 186 resource. Since URIs of WebDAV resources are hierarchical, and 187 correspond to a hierarchy of collections in resource space, the BIND 188 method also has the effect of adding the resource to a collection. 189 As new URIs are associated with the resource, it appears in 190 additional collections. 192 A BIND request does not create a new resource, but simply makes 193 available a new URI for submitting requests to an existing resource. 194 The new URI is indistinguishable from any other URI when submitting a 195 request to a resource. Only one round trip is needed to submit a 196 request to the intended target. Servers are required to enforce the 197 integrity of the relationships between the new URIs and the resources 198 associated with them. Consequently, it may be very costly for 199 servers to support BIND requests that cross server boundaries. 201 This specification is organized as follows. Section 1.1 defines 202 terminology used in the rest of the specification, while Section 2 203 overviews bindings. Section 3 defines the new properties needed to 204 support multiple bindings to the same resource. Section 4 specifies 205 the BIND method, used to create multiple bindings to the same 206 resource. Section 5 specifies the UNBIND method, used to remove a 207 binding to a resource. Section 6 specifies the REBIND method, used 208 to move a binding to another collection. 210 1.1. Terminology 212 The terminology used here follows and extends that in the WebDAV 213 Distributed Authoring Protocol specification 214 [draft-ietf-webdav-rfc2518bis]. 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL-NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 This document uses XML DTD fragments ([XML]) as a notational 221 convention, using the rules defined in Section 17 of 222 [draft-ietf-webdav-rfc2518bis]. 224 URI Mapping 226 A relation between an absolute URI and a resource. For an 227 absolute URI U and the resource it identifies R, the URI mapping 228 can be thought of as (U => R). Since a resource can represent 229 items that are not network retrievable, as well as those that are, 230 it is possible for a resource to have zero, one, or many URI 231 mappings. Mapping a resource to an "http" scheme URI makes it 232 possible to submit HTTP protocol requests to the resource using 233 the URI. 235 Path Segment 237 Informally, the characters found between slashes ("/") in a URI. 238 Formally, as defined in Section 3.3 of [RFC3986]. 240 Binding 242 A relation between a single path segment (in a collection) and a 243 resource. A binding is part of the state of a collection. If two 244 different collections contain a binding between the same path 245 segment and the same resource, these are two distinct bindings. 246 So for a collection C, a path segment S, and a resource R, the 247 binding can be thought of as C:(S -> R). Bindings create URI 248 mappings, and hence allow requests to be sent to a single resource 249 from multiple locations in a URI namespace. For example, given a 250 collection C (accessible through the URI 251 http://www.example.com/CollX), a path segment S (equal to 252 "foo.html"), and a resource R, then creating the binding C: (S -> 253 R) makes it possible to use the URI 254 http://www.example.com/CollX/foo.html to access R. 256 Collection 258 A resource that contains, as part of its state, a set of bindings 259 that identify internal member resources. 261 Internal Member URI 263 The URI that identifies an internal member of a collection, and 264 that consists of the URI for the collection, followed by a slash 265 character ('/'), followed by the path segment of the binding for 266 that internal member. 268 1.2. Method Preconditions and Postconditions 270 See Section 16 of [draft-ietf-webdav-rfc2518bis] for the definitions 271 of "precondition" and "postcondition". 273 2. Overview of Bindings 275 Bindings are part of the state of a collection. They define the 276 internal members of the collection, and the names of those internal 277 members. 279 Bindings are added and removed by a variety of existing HTTP methods. 280 A method that creates a new resource, such as PUT, COPY, and MKCOL, 281 adds a binding. A method that deletes a resource, such as DELETE, 282 removes a binding. A method that moves a resource (e.g. MOVE) both 283 adds a binding (in the destination collection) and removes a binding 284 (in the source collection). The BIND method introduced here provides 285 a mechanism for adding a second binding to an existing resource. 286 There is no difference between an initial binding added by PUT, COPY, 287 or MKCOL, and additional bindings added with BIND. 289 It would be very undesirable if one binding could be destroyed as a 290 side effect of operating on the resource through a different binding. 291 In particular, the removal of one binding to a resource (e.g. with a 292 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 293 e.g. by turning that binding into a dangling path segment. The 294 server MUST NOT reclaim system resources after removing one binding, 295 while other bindings to the resource remain. In other words, the 296 server MUST maintain the integrity of a binding. It is permissible, 297 however, for future method definitions (e.g., a DESTROY method) to 298 have semantics that explicitly remove all bindings and/or immediately 299 reclaim system resources. 301 2.1. Bindings to Collections 303 Creating a new binding to a collection makes each resource associated 304 with a binding in that collection accessible via a new URI, and thus 305 creates new URI mappings to those resources but no new bindings. 307 For example, suppose a new binding CollY is created for collection C1 308 in the figure below. It immediately becomes possible to access 309 resource R1 using the URI /CollY/x.gif and to access resource R2 310 using the URI /CollY/y.jpg, but no new bindings for these child 311 resources were created. This is because bindings are part of the 312 state of a collection, and associate a URI that is relative to that 313 collection with its target resource. No change to the bindings in 314 Collection C1 is needed to make its children accessible using /CollY/ 315 x.gif and /CollY/y.jpg. 317 +-------------------------+ 318 | Root Collection | 319 | bindings: | 320 | CollX CollY | 321 +-------------------------+ 322 | / 323 | / 324 | / 325 +------------------+ 326 | Collection C1 | 327 | bindings: | 328 | x.gif y.jpg | 329 +------------------+ 330 | \ 331 | \ 332 | \ 333 +-------------+ +-------------+ 334 | Resource R1 | | Resource R2 | 335 +-------------+ +-------------+ 337 2.1.1. Bind loops 339 Bindings to collections can result in loops, which servers MUST 340 detect when processing "Depth: infinity" requests. It is sometimes 341 possible to complete an operation in spite of the presence of a loop. 342 For instance, a PROPFIND can still succeed if the server uses the new 343 status code 208 (Already Reported) defined in Section 7.1. 345 However, the 506 (Loop Detected) status code is defined in 346 Section 7.2 for use in contexts where an operation is terminated 347 because a loop was encountered. 349 2.2. URI Mappings Created by a new Binding 351 Suppose a binding from "Binding-Name" to resource R is to be added to 352 a collection, C. Then if C-MAP is the set of URIs that were mapped to 353 C before the BIND request, then for each URI "C-URI" in C-MAP, the 354 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 355 request. 357 For example, if a binding from "foo.html" to R is added to a 358 collection C, and if the following URIs are mapped to C: 360 http://www.example.com/A/1/ 361 http://example.com/A/one/ 362 then the following new mappings to R are introduced: 364 http://www.example.com/A/1/foo.html 365 http://example.com/A/one/foo.html 367 Note that if R is a collection, additional URI mappings are created 368 to the descendents of R. Also, note that if a binding is made in 369 collection C to C itself (or to a parent of C), an infinite number of 370 mappings are introduced. 372 For example, if a binding from "myself" to C is then added to C, the 373 following infinite number of additional mappings to C are introduced: 375 http://www.example.com/A/1/myself 376 http://www.example.com/A/1/myself/myself 377 ... 379 and the following infinite number of additional mappings to R are 380 introduced: 382 http://www.example.com/A/1/myself/foo.html 383 http://www.example.com/A/1/myself/myself/foo.html 384 ... 386 2.3. COPY and Bindings 388 As defined in Section 9.8 of [draft-ietf-webdav-rfc2518bis], COPY 389 causes the resource identified by the Request-URI to be duplicated, 390 and makes the new resource accessible using the URI specified in the 391 Destination header. Upon successful completion of a COPY, a new 392 binding is created between the last path segment of the Destination 393 header, and the destination resource. The new binding is added to 394 its parent collection, identified by the Destination header minus its 395 final segment. 397 The following figure shows an example: Suppose that a COPY is issued 398 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 399 with the Destination header set to URI-X. After successful 400 completion of the COPY operation, resource R is duplicated to create 401 resource R', and a new binding has been created which creates at 402 least the URI mapping between URI-X and the new resource (although 403 other URI mappings may also have been created). 405 URI-1 URI-2 URI-3 URI-X 406 | | | | 407 | | | <---- URI Mappings ----> | 408 | | | | 409 +---------------------+ +------------------------+ 410 | Resource R | | Resource R' | 411 +---------------------+ +------------------------+ 413 It might be thought that a COPY request with "Depth: 0" on a 414 collection would duplicate its bindings, since bindings are part of 415 the collection's state. This is not the case, however. The 416 definition of Depth in [draft-ietf-webdav-rfc2518bis] makes it clear 417 that a "Depth: 0" request does not apply to a collection's members. 418 Consequently, a COPY with "Depth: 0" does not duplicate the bindings 419 contained by the collection. 421 If a COPY request causes an existing resource to be updated, the 422 bindings to that resource MUST be unaffected by the COPY request. 423 Using the preceding example, suppose that a COPY request is issued to 424 URI-X for resource R', with the Destination header set to URI-2. The 425 content and dead properties of resource R would be updated to be a 426 copy of those of resource R', but the mappings from URI-1, URI-2, and 427 URI-3 to resource R remain unaffected. If because of multiple 428 bindings to a resource, more than one source resource updates a 429 single destination resource, the order of the updates is server 430 defined. 432 If a COPY request would cause a new resource to be created as a copy 433 of an existing resource, and that COPY request has already created a 434 copy of that existing resource, the COPY request instead creates 435 another binding to the previous copy, instead of creating a new 436 resource. 438 2.3.1. Example: COPY with 'Depth: infinity' in presence of bind loops 440 As an example of how COPY with Depth infinity would work in the 441 presence of bindings, consider the following collection: 443 +------------------+ 444 | Root Collection | 445 | bindings: | 446 | CollX | 447 +------------------+ 448 | 449 | 450 +-------------------------------+ 451 | Collection C1 |<-------+ 452 | bindings: | | 453 | x.gif CollY | | 454 +-------------------------------+ | 455 | \ (creates loop) | 456 | \ | 457 +-------------+ +------------------+ | 458 | Resource R1 | | Collection C2 | | 459 +-------------+ | bindings: | | 460 | y.gif CollZ | | 461 +------------------+ | 462 | | | 463 | +--------+ 464 | 465 +-------------+ 466 | Resource R2 | 467 +-------------+ 469 If a COPY with Depth infinity is submitted to /CollX, with 470 destination of /CollA, the outcome of the copy operation is: 472 +------------------+ 473 | Root Collection | 474 | bindings: | 475 | CollX CollA | 476 +------------------+ 477 | | 478 | +---------------------------+ 479 | | 480 +-------------------+ | 481 | Collection C1 |<------------------+ | 482 | bindings: | | | 483 | x.gif CollY | | | 484 +-------------------+ | | 485 | \ (creates loop) | | 486 | \ | | 487 +-------------+ +-----------------+ | | 488 | Resource R1 | | Collection C2 | | | 489 +-------------+ | bindings: | | | 490 | y.gif CollZ | | | 491 +-----------------+ | | 492 | | | | 493 | +-------+ | 494 | | 495 +-------------+ | 496 | Resource R2 | | 497 +-------------+ | 498 | 499 +-------------------------------+ 500 | 501 +-------------------+ 502 | Collection C3 |<------------------+ 503 | bindings: | | 504 | x.gif CollY | | 505 +-------------------+ | 506 | \ (creates loop) | 507 | \ | 508 +-------------+ +-----------------+ | 509 | Resource R3 | | Collection C4 | | 510 +-------------+ | bindings: | | 511 | y.gif CollZ | | 512 +-----------------+ | 513 | | | 514 | +-------+ 515 | 516 +-------------+ 517 | Resource R4 | 518 +-------------+ 520 2.3.2. Example: COPY with 'Depth: infinity' with multiple bindings to a 521 leaf resource 523 Given the following collection hierarchy: 525 +------------------+ 526 | Root Collection | 527 | bindings: | 528 | CollX | 529 +------------------+ 530 | 531 | 532 | 533 +----------------+ 534 | Collection C1 | 535 | bindings: | 536 | x.gif y.gif | 537 +----------------+ 538 | | 539 | | 540 +-------------+ 541 | Resource R1 | 542 +-------------+ 544 A COPY of /CollX with Depth infinity to /CollY results in the 545 following collection hierarchy: 547 +------------------+ 548 | Root Collection | 549 | bindings: | 550 | CollX CollY | 551 +------------------+ 552 | \ 553 | \ 554 | \ 555 +----------------+ +-----------------+ 556 | Collection C1 | | Collection C2 | 557 | bindings: | | bindings: | 558 | x.gif y.gif | | x.gif y.gif | 559 +----------------+ +-----------------+ 560 | | | | 561 | | | | 562 +-------------+ +-------------+ 563 | Resource R1 | | Resource R2 | 564 +-------------+ +-------------+ 566 2.4. DELETE and Bindings 568 When there are multiple bindings to a resource, a DELETE applied to 569 that resource MUST NOT remove any bindings to that resource other 570 than the one identified by the Request-URI. For example, suppose the 571 collection identified by the URI "/a" has a binding named "x" to a 572 resource R, and another collection identified by "/b" has a binding 573 named "y" to the same resource R. Then a DELETE applied to "/a/x" 574 removes the binding named "x" from "/a" but MUST NOT remove the 575 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 576 to identify the resource R). 578 When DELETE is applied to a collection, it MUST NOT modify the 579 membership of any other collection that is not itself a member of the 580 collection being deleted. For example, if both "/a/.../x" and 581 "/b/.../y" identify the same collection, C, then applying DELETE to 582 "/a" must not delete an internal member from C or from any other 583 collection that is a member of C, because that would modify the 584 membership of "/b". 586 If a collection supports the UNBIND method (see Section 5), a DELETE 587 of an internal member of a collection MAY be implemented as an UNBIND 588 request. In this case, applying DELETE to a Request-URI has the 589 effect of removing the binding identified by the final segment of the 590 Request-URI from the collection identified by the Request-URI minus 591 its final segment. Although [draft-ietf-webdav-rfc2518bis] allows a 592 DELETE to be a non-atomic operation, when the DELETE operation is 593 implemented as an UNBIND, the operation is atomic. In particular, a 594 DELETE on a hierarchy of resources is simply the removal of a binding 595 to the collection identified by the Request-URI. 597 2.5. MOVE and Bindings 599 When MOVE is applied to a resource, the other bindings to that 600 resource MUST be unaffected, and if the resource being moved is a 601 collection, the bindings to any members of that collection MUST be 602 unaffected. Also, if MOVE is used with Overwrite:T to delete an 603 existing resource, the constraints specified for DELETE apply. 605 If the destination collection of a MOVE request supports the REBIND 606 method (see Section 6), a MOVE of a resource into that collection MAY 607 be implemented as a REBIND request. Although 608 [draft-ietf-webdav-rfc2518bis] allows a MOVE to be a non-atomic 609 operation, when the MOVE operation is implemented as a REBIND, the 610 operation is atomic. In particular, applying a MOVE to a Request-URI 611 and a Destination URI has the effect of removing a binding to a 612 resource (at the Request-URI), and creating a new binding to that 613 resource (at the Destination URI). Even when the Request-URI 614 identifies a collection, the MOVE operation involves only removing 615 one binding to that collection and adding another. 617 As an example, suppose that a MOVE is issued to URI-3 for resource R 618 below (which is also mapped to URI-1 and URI-2), with the Destination 619 header set to URI-X. After successful completion of the MOVE 620 operation, a new binding has been created which creates the URI 621 mapping between URI-X and resource R. The binding corresponding to 622 the final segment of URI-3 has been removed, which also causes the 623 URI mapping between URI-3 and R to be removed. If resource R were a 624 collection, old URI-3 based mappings to members of R would have been 625 removed, and new URI-X based mappings to members of R would have been 626 created. 628 >> Before Request: 630 URI-1 URI-2 URI-3 631 | | | 632 | | | <---- URI Mappings 633 | | | 634 +---------------------+ 635 | Resource R | 636 +---------------------+ 638 >> After Request: 640 URI-1 URI-2 URI-X 641 | | | 642 | | | <---- URI Mappings 643 | | | 644 +---------------------+ 645 | Resource R | 646 +---------------------+ 648 2.6. PROPFIND and Bindings 650 Consistent with [draft-ietf-webdav-rfc2518bis], the value of a dead 651 property MUST be independent of the number of bindings to its host 652 resource or of the path submitted to PROPFIND. On the other hand, 653 the behaviour for each live property depends on its individual 654 definition (for example, see [RFC3744], Section 5, paragraph 2). 656 2.7. Determining Whether Two Bindings Are to the Same Resource 658 It is useful to have some way of determining whether two bindings are 659 to the same resource. Two resources might have identical contents 660 and properties, but not be the same resource (e.g. an update to one 661 resource does not affect the other resource). 663 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 664 resource identifier, which MUST be unique across all resources for 665 all time. If the values of DAV:resource-id returned by PROPFIND 666 requests through two bindings are identical character by character, 667 the client can be assured that the two bindings are to the same 668 resource. 670 The DAV:resource-id property is created, and its value assigned, when 671 the resource is created. The value of DAV:resource-id MUST NOT be 672 changed. Even after the resource is no longer accessible through any 673 URI, that value MUST NOT be reassigned to another resource's DAV: 674 resource-id property. 676 Any method that creates a new resource MUST assign a new, unique 677 value to its DAV:resource-id property. For example, a PUT applied to 678 a null resource, COPY (when not overwriting an existing target) and 679 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 680 to the DAV:resource-id property of the new resource they create. 682 On the other hand, any method that affects an existing resource must 683 not change the value of its DAV:resource-id property. Specifically, 684 a PUT or a COPY that updates an existing resource must not change the 685 value of its DAV:resource-id property. A REBIND, since it does not 686 create a new resource, but only changes the location of an existing 687 resource, must not change the value of the DAV:resource-id property. 689 2.8. Discovering the Bindings to a Resource 691 An OPTIONAL DAV:parent-set property on a resource provides a list of 692 the bindings that associate a collection and a URI segment with that 693 resource. If the DAV:parent-set property exists on a given resource, 694 it MUST contain a complete list of all bindings to that resource that 695 the client is authorized to see. When deciding whether to support 696 the DAV:parent-set property, server implementers / administrators 697 should balance the benefits it provides against the cost of 698 maintaining the property and the security risks enumerated in 699 Sections 10.4 and 10.5. 701 3. Properties 703 The bind feature introduces the properties defined below. 705 A DAV:allprop PROPFIND request SHOULD NOT return any of the 706 properties defined by this document. This allows a binding server to 707 perform efficiently when a naive client, which does not understand 708 the cost of asking a server to compute all possible live properties, 709 issues a DAV:allprop PROPFIND request. 711 3.1. DAV:resource-id Property 713 The DAV:resource-id property is a REQUIRED property that enables 714 clients to determine whether two bindings are to the same resource. 715 The value of DAV:resource-id is a URI, and may use any registered URI 716 scheme that guarantees the uniqueness of the value across all 717 resources for all time (e.g. the urn:uuid: URN namespace defined in 718 [RFC4122] or the opaquelocktoken: URI scheme defined in 719 [draft-ietf-webdav-rfc2518bis]). 721 723 3.2. DAV:parent-set Property 725 The DAV:parent-set property is an OPTIONAL property that enables 726 clients to discover what collections contain a binding to this 727 resource (i.e. what collections have that resource as an internal 728 member). It contains an of href/segment pair for each collection 729 that has a binding to the resource. The href identifies the 730 collection, and the segment identifies the binding name of that 731 resource in that collection. 733 A given collection MUST appear only once in the DAV:parent-set for 734 any given binding, even if there are multiple URI mappings to that 735 collection. 737 738 739 740 743 3.2.1. Example for DAV:parent-set property 745 For example, if collection C1 is mapped to both /CollX and /CollY, 746 and C1 contains a binding named "x.gif" to a resource R1, then either 747 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 748 of R1, but not both. But if C1 also had a binding named "y.gif" to 749 R1, then there would be two entries for C1 in the DAV:binding-set of 750 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 751 both [/CollY, x.gif] and [/CollY, y.gif]). 753 +-------------------------+ 754 | Root Collection | 755 | bindings: | 756 | CollX CollY | 757 +-------------------------+ 758 | / 759 | / 760 | / 761 +-----------------+ 762 | Collection C1 | 763 | bindings: | 764 | x.gif y.gif | 765 +-----------------+ 766 | | 767 | | 768 | | 769 +--------------+ 770 | Resource R1 | 771 +--------------+ 773 In this case, one possible value for DAV:parent-set property on 774 "/CollX/x.gif" would be: 776 777 778 /CollX 779 x.gif 780 781 782 /CollX 783 y.gif 784 785 787 4. BIND Method 789 The BIND method modifies the collection identified by the Request- 790 URI, by adding a new binding from the segment specified in the BIND 791 body to the resource identified in the BIND body. 793 If a server cannot guarantee the integrity of the binding, the BIND 794 request MUST fail. Note that it is especially difficult to maintain 795 the integrity of cross-server bindings. Unless the server where the 796 resource resides knows about all bindings on all servers to that 797 resource, it may unwittingly destroy the resource or make it 798 inaccessible without notifying another server that manages a binding 799 to the resource. For example, if server A permits creation of a 800 binding to a resource on server B, server A must notify server B 801 about its binding and must have an agreement with B that B will not 802 destroy the resource while A's binding exists. Otherwise server B 803 may receive a DELETE request that it thinks removes the last binding 804 to the resource and destroy the resource while A's binding still 805 exists. The precondition DAV:cross-server-binding is defined below 806 for cases where servers fail cross-server BIND requests because they 807 cannot guarantee the integrity of cross-server bindings. 809 By default, if there already is a binding for the specified segment 810 in the collection, the new binding replaces the existing binding. 811 This default binding replacement behavior can be overridden using the 812 Overwrite header defined in Section 10.6 of 813 [draft-ietf-webdav-rfc2518bis]. 815 If a BIND request fails, the server state preceding the request MUST 816 be restored. This method is unsafe and idempotent (see [RFC2616], 817 Section 9.1). 819 Marshalling: 821 The request MAY include an Overwrite header. 823 The request body MUST be a DAV:bind XML element. 825 827 If the request succeeds, the server MUST return 201 (Created) when 828 a new binding was created and 200 (OK) when an existing binding 829 was replaced. 831 If a response body for a successful request is included, it MUST 832 be a DAV:bind-response XML element. Note that this document does 833 not define any elements for the BIND response body, but the DAV: 834 bind-response element is defined to ensure interoperability 835 between future extensions that do define elements for the BIND 836 response body. 838 840 Preconditions: 842 (DAV:bind-into-collection): The Request-URI MUST identify a 843 collection. 845 (DAV:bind-source-exists): The DAV:href element MUST identify a 846 resource. 848 (DAV:binding-allowed): The resource identified by the DAV:href 849 supports multiple bindings to it. 851 (DAV:cross-server-binding): If the resource identified by the DAV: 852 href element in the request body is on another server from the 853 collection identified by the Request-URI, the server MUST support 854 cross-server bindings. 856 (DAV:name-allowed): The name specified by the DAV:segment is 857 available for use as a new binding name. 859 (DAV:can-overwrite): If the collection already contains a binding 860 with the specified path segment, and if an Overwrite header is 861 included, the value of the Overwrite header MUST be "T". 863 (DAV:cycle-allowed): If the DAV:href element identifies a 864 collection, and if the Request-URI identifies a collection that is 865 a member of that collection, the server MUST support cycles in the 866 URI namespace. 868 (DAV:locked-update-allowed): If the collection identified by the 869 Request-URI is write-locked, then the appropriate token MUST be 870 specified in an If request header. 872 (DAV:locked-overwrite-allowed): If the collection already contains 873 a binding with the specified path segment, and if that binding is 874 protected by a write-lock, then the appropriate token MUST be 875 specified in an If request header. 877 Postconditions: 879 (DAV:new-binding): The collection MUST have a binding that maps 880 the segment specified in the DAV:segment element in the request 881 body, to the resource identified by the DAV:href element in the 882 request body. 884 4.1. Example: BIND 886 >> Request: 888 BIND /CollY HTTP/1.1 889 Host: www.example.com 890 Content-Type: application/xml; charset="utf-8" 891 Content-Length: xxx 893 894 895 bar.html 896 http://www.example.com/CollX/foo.html 897 899 >> Response: 901 HTTP/1.1 201 Created 903 The server added a new binding to the collection, 904 "http://www.example.com/CollY", associating "bar.html" with the 905 resource identified by the URI 906 "http://www.example.com/CollX/foo.html". Clients can now use the URI 907 "http://www.example.com/CollY/bar.html" to submit requests to that 908 resource. 910 5. UNBIND Method 912 The UNBIND method modifies the collection identified by the Request- 913 URI, by removing the binding identified by the segment specified in 914 the UNBIND body. 916 Once a resource is unreachable by any URI mapping, the server MAY 917 reclaim system resources associated with that resource. If UNBIND 918 removes a binding to a resource, but there remain URI mappings to 919 that resource, the server MUST NOT reclaim system resources 920 associated with the resource. 922 If an UNBIND request fails, the server state preceding the request 923 MUST be restored. This method is unsafe and idempotent (see 924 [RFC2616], Section 9.1). 926 Marshalling: 928 The request body MUST be a DAV:unbind XML element. 930 931 If the request succeeds, the server MUST return 200 (OK) when the 932 binding was successfully deleted. 934 If a response body for a successful request is included, it MUST 935 be a DAV:unbind-response XML element. Note that this document 936 does not define any elements for the UNBIND response body, but the 937 DAV:unbind-response element is defined to ensure interoperability 938 between future extensions that do define elements for the UNBIND 939 response body. 941 943 Preconditions: 945 (DAV:unbind-from-collection): The Request-URI MUST identify a 946 collection. 948 (DAV:unbind-source-exists): The DAV:segment element MUST identify 949 a binding in the collection identified by the Request-URI. 951 (DAV:locked-update-allowed): If the collection identified by the 952 Request-URI is write-locked, then the appropriate token MUST be 953 specified in the request. 955 (DAV:protected-url-deletion-allowed): If the binding identified by 956 the segment is protected by a write-lock, then the appropriate 957 token MUST be specified in the request. 959 Postconditions: 961 (DAV:binding-deleted): The collection MUST NOT have a binding for 962 the segment specified in the DAV:segment element in the request 963 body. 965 (DAV:lock-deleted): If the internal member URI of the binding 966 specified by the Request-URI and the DAV:segment element in the 967 request body was protected by a write-lock at the time of the 968 request, that write-lock must have been deleted by the request. 970 5.1. Example: UNBIND 972 >> Request: 974 UNBIND /CollX HTTP/1.1 975 Host: www.example.com 976 Content-Type: application/xml; charset="utf-8" 977 Content-Length: xxx 979 980 981 foo.html 982 984 >> Response: 986 HTTP/1.1 200 OK 988 The server removed the binding named "foo.html" from the collection, 989 "http://www.example.com/CollX". A request to the resource named 990 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 991 response. 993 6. REBIND Method 995 The REBIND method removes a binding to a resource from a collection, 996 and adds a binding to that resource into the collection identified by 997 the Request-URI. The request body specifies the binding to be added 998 (segment) and the old binding to be removed (href). It is 999 effectively an atomic form of a MOVE request, and MUST be treated the 1000 same way as MOVE for the purpose of determining access permissions. 1002 If a REBIND request fails, the server state preceding the request 1003 MUST be restored. This method is unsafe and idempotent (see 1004 [RFC2616], Section 9.1). 1006 Marshalling: 1008 The request MAY include an Overwrite header. 1010 The request body MUST be a DAV:rebind XML element. 1012 1014 If the request succeeds, the server MUST return 201 (Created) when 1015 a new binding was created and 200 (OK) when an existing binding 1016 was replaced. 1018 If a response body for a successful request is included, it MUST 1019 be a DAV:rebind-response XML element. Note that this document 1020 does not define any elements for the REBIND response body, but the 1021 DAV:rebind-response element is defined to ensure interoperability 1022 between future extensions that do define elements for the REBIND 1023 response body. 1025 1027 Preconditions: 1029 (DAV:rebind-into-collection): The Request-URI MUST identify a 1030 collection. 1032 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1033 resource. 1035 (DAV:cross-server-binding): If the resource identified by the DAV: 1036 href element in the request body is on another server from the 1037 collection identified by the Request-URI, the server MUST support 1038 cross-server bindings. 1040 (DAV:name-allowed): The name specified by the DAV:segment is 1041 available for use as a new binding name. 1043 (DAV:can-overwrite): If the collection already contains a binding 1044 with the specified path segment, and if an Overwrite header is 1045 included, the value of the Overwrite header MUST be "T". 1047 (DAV:cycle-allowed): If the DAV:href element identifies a 1048 collection, and if the Request-URI identifies a collection that is 1049 a member of that collection, the server MUST support cycles in the 1050 URI namespace. 1052 (DAV:locked-update-allowed): If the collection identified by the 1053 Request-URI is write-locked, then the appropriate token MUST be 1054 specified in the request. 1056 (DAV:protected-url-modification-allowed): If the collection 1057 identified by the Request-URI already contains a binding with the 1058 specified path segment, and if that binding is protected by a 1059 write-lock, then the appropriate token MUST be specified in the 1060 request. 1062 (DAV:locked-source-collection-update-allowed): If the collection 1063 identified by the parent collection prefix of the DAV:href URI is 1064 write-locked, then the appropriate token MUST be specified in the 1065 request. 1067 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1068 is protected by a write lock, then the appropriate token MUST be 1069 specified in the request. 1071 Postconditions: 1073 (DAV:new-binding): The collection MUST have a binding that maps 1074 the segment specified in the DAV:segment element in the request 1075 body, to the resource that was identified by the DAV:href element 1076 in the request body. 1078 (DAV:binding-deleted): The URL specified in the DAV:href element 1079 in the request body MUST NOT be mapped to a resource. 1081 (DAV:lock-deleted): If the URL specified in the DAV:href element 1082 in the request body was protected by a write-lock at the time of 1083 the request, that write-lock must have been deleted by the 1084 request. 1086 6.1. Example: REBIND 1088 >> Request: 1090 REBIND /CollX HTTP/1.1 1091 Host: www.example.com 1092 Content-Type: application/xml; charset="utf-8" 1093 Content-Length: xxx 1095 1096 1097 foo.html 1098 http://www.example.com/CollY/bar.html 1099 1101 >> Response: 1103 HTTP/1.1 200 OK 1105 The server added a new binding to the collection, 1106 "http://www.example.com/CollX", associating "foo.html" with the 1107 resource identified by the URI 1108 "http://www.example.com/CollY/bar.html", and removes the binding 1109 named "bar.html" from the collection identified by the URI 1110 "http://www.example.com/CollY". Clients can now use the URI 1111 "http://www.example.com/CollX/foo.html" to submit requests to that 1112 resource, and requests on the URI 1113 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1114 Found) response. 1116 6.2. Example: REBIND in presence of locks and bind loops 1118 To illustrate the effects of locks and bind loops on a REBIND 1119 operation, consider the following collection: 1121 +------------------+ 1122 | Root Collection | 1123 | bindings: | 1124 | CollW | 1125 +------------------+ 1126 | 1127 | 1128 | 1129 +-------------------------------+ 1130 | Collection C1 |<--------+ 1131 | LOCKED infinity | | 1132 | (lock token L1) | | 1133 | bindings: | | 1134 | CollX CollY | | 1135 +-------------------------------+ | 1136 | | | 1137 | | (creates loop) | 1138 | | | 1139 +-----------------+ +------------------+ | 1140 | Collection C2 | | Collection C3 | | 1141 | (inherit lock) | | (inherit lock) | | 1142 | (lock token L1) | | (lock token L1) | | 1143 | bindings: | | bindings: | | 1144 | {none} | | y.gif CollZ | | 1145 +-----------------+ +------------------+ | 1146 | | | 1147 | +-----+ 1148 | 1149 +---------------------------+ 1150 | Resource R2 | 1151 | (lock inherited from C1) | 1152 | (lock token L1) | 1153 +---------------------------+ 1155 (where L1 is "opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1157 Note that the binding between CollZ and C1 creates a loop in the 1158 containment hierarchy. Servers are not required to support such 1159 loops, though the server in this example does. 1161 The REBIND request below will remove the segment "CollZ" from C3 and 1162 add a new binding from "CollA" to the collection C2. 1164 REBIND /CollW/CollX HTTP/1.1 1165 Host: www.example.com 1166 If: () 1167 Content-Type: application/xml; charset="utf-8" 1168 Content-Length: xxx 1170 1171 1172 CollA 1173 /CollW/CollY/CollZ 1174 1175 The outcome of the REBIND operation is: 1177 +------------------+ 1178 | Root Collection | 1179 | bindings: | 1180 | CollW | 1181 +------------------+ 1182 | 1183 | 1184 | 1185 +-------------------------------+ 1186 | Collection C1 | 1187 | LOCKED infinity | 1188 | (lock token L1) | 1189 | bindings: | 1190 | CollX CollY | 1191 +-------------------------------+ 1192 | ^ | 1193 | | | 1194 +-----------------+ | +------------------+ 1195 | Collection C2 | | | Collection C3 | 1196 |(inherited lock) | | | (inherited lock) | 1197 |(lock token L1) | | | (lock token L1) | 1198 | bindings: | | | bindings: | 1199 | CollA | | | y.gif | 1200 +-----------------+ | +------------------+ 1201 | | | 1202 +---------------+ | 1203 (creates loop) | 1204 +---------------------------+ 1205 | Resource R2 | 1206 | (inherited lock from C1) | 1207 | (lock token L1) | 1208 +---------------------------+ 1210 7. Additional Status Codes 1212 7.1. 208 Already Reported 1214 The 208 (Already Reported) status code can be used inside a DAV: 1215 propstat response element to avoid enumerating the internal members 1216 of multiple bindings to the same collection repeatedly. For each 1217 binding to a collection inside the request's scope, only one will be 1218 reported with a 200 status, while subsequent DAV:response elements 1219 for all other bindings will use the 208 status, and no DAV:response 1220 elements for their descendants are included. 1222 Note that the 208 status will only occur for "Depth: infinity" 1223 requests, and that it is of particular importance when the multiple 1224 collection bindings cause a bind loop as discussed in Section 2.2. 1226 A client can request the DAV:resource-id property in a PROPFIND 1227 request to guarantee that they can accurately reconstruct the binding 1228 structure of a collection with multiple bindings to a single 1229 resource. 1231 For backward compatibility with clients not aware of the 208 status 1232 code appearing in multistatus response bodies, it SHOULD NOT be used 1233 unless the client has signalled support for this specification using 1234 the "DAV" request header (see Section 8.2). Instead, a 506 status 1235 should be returned when a binding loop is discovered. This allows 1236 the server to return the 506 as the top level return status, if it 1237 discovers it before it started the response, or in the middle of a 1238 multistatus, if it discovers it in the middle of streaming out a 1239 multistatus response. 1241 7.1.1. Example: PROPFIND by bind-aware client 1243 For example, consider a PROPFIND request on /Coll (bound to 1244 collection C), where the members of /Coll are /Coll/Foo (bound to 1245 resource R) and /Coll/Bar (bound to collection C). 1247 >> Request: 1249 PROPFIND /Coll/ HTTP/1.1 1250 Host: www.example.com 1251 Depth: infinity 1252 DAV: bind 1253 Content-Type: application/xml; charset="utf-8" 1254 Content-Length: xxx 1256 1257 1258 1259 1260 1261 1262 1264 >> Response: 1266 HTTP/1.1 207 Multi-Status 1267 Content-Type: application/xml; charset="utf-8" 1268 Content-Length: xxx 1270 1271 1272 1273 http://www.example.com/Coll/ 1274 1275 1276 Loop Demo 1277 1278 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1280 1281 1282 HTTP/1.1 200 OK 1283 1284 1285 1286 http://www.example.com/Coll/Foo 1287 1288 1289 Bird Inventory 1290 1291 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1293 1294 1295 HTTP/1.1 200 OK 1296 1297 1298 1299 http://www.example.com/Coll/Bar 1300 1301 1302 Loop Demo 1303 1304 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1306 1307 1308 HTTP/1.1 208 Already Reported 1309 1310 1311 1313 7.1.2. Example: PROPFIND by non-bind-aware client 1315 In this example, the client isn't aware of the 208 status code 1316 introduced by this specification. As the "Depth: infinity" PROPFIND 1317 request would cause a loop condition, the whole request is rejected 1318 with a 506 status. 1320 >> Request: 1322 PROPFIND /Coll/ HTTP/1.1 1323 Host: www.example.com 1324 Depth: infinity 1325 Content-Type: application/xml; charset="utf-8" 1326 Content-Length: xxx 1328 1329 1330 1331 1333 >> Response: 1335 HTTP/1.1 506 Loop Detected 1337 7.2. 506 Loop Detected 1339 The 506 (Loop Detected) status code indicates that the server 1340 terminated an operation because it encountered an infinite loop while 1341 processing a request with "Depth: infinity". This status indicates 1342 that the entire operation failed. 1344 8. Capability discovery 1346 8.1. OPTIONS method 1348 If the server supports bindings, it MUST return the compliance class 1349 name "bind" as a field in the "DAV" response header (see 1350 [draft-ietf-webdav-rfc2518bis], Section 10.1) from an OPTIONS request 1351 on any resource implemented by that server. A value of "bind" in the 1352 "DAV" header MUST indicate that the server supports all MUST level 1353 requirements and REQUIRED features specified in this document. 1355 8.2. 'DAV' request header 1357 Clients SHOULD signal support for all MUST level requirements and 1358 REQUIRED features by submitting a "DAV" request header containing the 1359 compliance class name "bind". In particular, the client MUST 1360 understand the 208 status code defined in Section 7.1. 1362 9. Relationship to WebDAV Access Control Protocol 1364 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1365 property (see [RFC3744], Section 7.3). 1367 10. Security Considerations 1369 This section is provided to make WebDAV implementors aware of the 1370 security implications of this protocol. 1372 All of the security considerations of HTTP/1.1 and the WebDAV 1373 Distributed Authoring Protocol specification also apply to this 1374 protocol specification. In addition, bindings introduce several new 1375 security concerns and increase the risk of some existing threats. 1376 These issues are detailed below. 1378 10.1. Privacy Concerns 1380 In a context where cross-server bindings are supported, creating 1381 bindings on a trusted server may make it possible for a hostile agent 1382 to induce users to send private information to a target on a 1383 different server. 1385 10.2. Bind Loops 1387 Although bind loops were already possible in HTTP 1.1, the 1388 introduction of the BIND method creates a new avenue for clients to 1389 create loops accidentally or maliciously. If the binding and its 1390 target are on the same server, the server may be able to detect BIND 1391 requests that would create loops. Servers are required to detect 1392 loops that are caused by bindings to collections during the 1393 processing of any requests with "Depth: infinity". 1395 10.3. Bindings, and Denial of Service 1397 Denial of service attacks were already possible by posting URIs that 1398 were intended for limited use at heavily used Web sites. The 1399 introduction of BIND creates a new avenue for similar denial of 1400 service attacks. If cross-server bindings are supported, clients can 1401 now create bindings at heavily used sites to target locations that 1402 were not designed for heavy usage. 1404 10.4. Private Locations May Be Revealed 1406 If the DAV:parent-set property is maintained on a resource, the 1407 owners of the bindings risk revealing private locations. The 1408 directory structures where bindings are located are available to 1409 anyone who has access to the DAV:parent-set property on the resource. 1410 Moving a binding may reveal its new location to anyone with access to 1411 DAV:parent-set on its resource. 1413 10.5. DAV:parent-set and Denial of Service 1415 If the server maintains the DAV:parent-set property in response to 1416 bindings created in other administrative domains, it is exposed to 1417 hostile attempts to make it devote resources to adding bindings to 1418 the list. 1420 11. Internationalization Considerations 1422 All internationalization considerations mentioned in 1423 [draft-ietf-webdav-rfc2518bis] also apply to this document. 1425 12. IANA Considerations 1427 There are no IANA considerations related to this specification. 1429 13. Acknowledgements 1431 This document is the collaborative product of the authors and Tyson 1432 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1433 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1434 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1435 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa 1436 Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe 1437 Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris 1438 Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1439 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1440 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1441 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1442 members of the WebDAV working group. 1444 14. References 1445 14.1. Normative References 1447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1448 Requirement Levels", BCP 14, RFC 2119, March 1997. 1450 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1451 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1452 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1454 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1455 Resource Identifier (URI): Generic Syntax", STD 66, 1456 RFC 3986, January 2005. 1458 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1459 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1460 Edition)", W3C REC-xml-20060816, August 2006, 1461 . 1463 [draft-ietf-webdav-rfc2518bis] 1464 Dusseault, L., Ed., "HTTP Extensions for Distributed 1465 Authoring - WebDAV RFC2518 bis", 1466 draft-ietf-webdav-rfc2518bis-15 (work in progress), 1467 May 2006. 1469 14.2. Informative References 1471 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1472 Whitehead, "Versioning Extensions to WebDAV (Web 1473 Distributed Authoring and Versioning)", RFC 3253, 1474 March 2002. 1476 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1477 Distributed Authoring and Versioning (WebDAV) Access 1478 Control Protocol", RFC 3744, May 2004. 1480 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1481 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1482 July 2005. 1484 Appendix A. Change Log (to be removed by RFC Editor before publication) 1486 A.1. Since draft-ietf-webdav-bind-02 1488 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1489 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1490 resolution, but keep it open. Add issues "ED_references" and 1491 "4_507_status". Started work on index. Rename document to "Binding 1492 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1493 Rename "References" to "Normative References". Close issue 1494 "ED_references". Close issue "4_507_status". 1496 A.2. Since draft-ietf-webdav-bind-03 1498 Add and close issues "9.2_redirect_loops", "ED_authors" and 1499 "ED_updates". Add section about capability discovery (DAV header). 1500 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1501 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1502 "locking" and resolve as invalid. 1504 A.3. Since draft-ietf-webdav-bind-04 1506 Add and close issues "6_precondition_binding_allowed" and 1507 "6_lock_behaviour". Add mailing list and issues list pointers to 1508 front. 1510 A.4. Since draft-ietf-webdav-bind-05 1512 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1513 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1514 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1516 A.5. Since draft-ietf-webdav-bind-06 1518 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1519 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1521 A.6. Since draft-ietf-webdav-bind-07 1523 Add more index items (no change tracking). Add and resolve issues 1524 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1525 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1526 DTD fragment in section 3.3. Make spelling of "Request-URI" 1527 consistent. 1529 A.7. Since draft-ietf-webdav-bind-08 1531 Resolved editorial issues raised by Jim Whitehead in . 1533 Add and resolve issues "atomicity", "2_allow_destroy", 1534 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1535 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1536 "2.6_resource-id_vs_versions", "3.2_example" and 1537 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1538 and resolve "6_rebind_intro". 1540 A.8. Since draft-ietf-webdav-bind-09 1542 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1543 text. Add action item "3.1_uuids". Close issue 1544 "2.6_when_do_ids_change". Add and resolve issues 1545 "2.6_bindings_vs_properties" and "uri_draft_ref". 1547 A.9. Since draft-ietf-webdav-bind-10 1549 Resolve action item "3.1_uuids". Add and resolve issue 1550 "2.7_unlock_vs_bindings". Revisit issue 1551 "2.6_bindings_vs_properties", and remove the part of the sentence 1552 that speaks about live properties. Update "rfc2396bis" references to 1553 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1554 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1556 A.10. Since draft-ietf-webdav-bind-11 1558 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1559 live properties in Section 2.6. 1561 A.11. Since draft-ietf-webdav-bind-12 1563 Updated Author's address. Uppercase "Section" when referring to 1564 other documents. 1566 Updating from RFC2518 to RFC2518bis: 1568 o Remove own explanation of DTD syntax. 1570 o Remove own definition of precondition/postcondition. 1572 o Remove reference to broken RFC2518 language about DELETE and 1573 UNLOCK. 1575 o Remove own definition of DAV: request header. 1577 o Updated "Rationale for Distinguishing Bindings from URI Mappings" 1578 to reflect the changes in [draft-ietf-webdav-rfc2518bis], making 1579 proposals for more changes so that the issue can be closed (see 1580 also 1581 and ). 1584 A.12. Since draft-ietf-webdav-bind-13 1586 Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one 1587 incorrect section reference. Remove Section "Rationale for 1588 Distinguishing Bindings from URI Mappings" as 1589 [draft-ietf-webdav-rfc2518-bis] now uses the proper definition of 1590 collection state. Examples use application/xml instead of text/xml 1591 MIME type. 1593 Fix IANA section (there are no IANA considerations). 1595 A.13. Since draft-ietf-webdav-bind-14 1597 Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to 1598 4th edition. 1600 Markup ASCII art for box recognition (doesn't affect ASCII version). 1602 Identify Julian Reschke as Editor. 1604 Appendix B. Open issues (to be removed by RFC Editor prior to 1605 publication) 1607 B.1. edit 1609 Type: edit 1611 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1612 editorial fixes/enhancements. 1614 Index 1616 2 1617 208 Already Reported (status code) 28 1619 5 1620 506 Loop Detected (status code) 31 1622 B 1623 BIND method 18 1624 Marshalling 19 1625 Postconditions 20 1626 Preconditions 19 1627 Binding 6 1629 C 1630 Collection 6 1631 Condition Names 1632 DAV:bind-into-collection (pre) 19 1633 DAV:bind-source-exists (pre) 19 1634 DAV:binding-allowed (pre) 20 1635 DAV:binding-deleted (post) 22, 25 1636 DAV:can-overwrite (pre) 20, 24 1637 DAV:cross-server-binding (pre) 20, 24 1638 DAV:cycle-allowed (pre) 20, 24 1639 DAV:lock-deleted (post) 22, 25 1640 DAV:locked-overwrite-allowed (pre) 20 1641 DAV:locked-source-collection-update-allowed (pre) 24 1642 DAV:locked-update-allowed (pre) 20, 22, 24 1643 DAV:name-allowed (pre) 20, 24 1644 DAV:new-binding (post) 20, 25 1645 DAV:protected-source-url-deletion-allowed (pre) 25 1646 DAV:protected-url-deletion-allowed (pre) 22 1647 DAV:protected-url-modification-allowed (pre) 24 1648 DAV:rebind-from-collection (pre) 24 1649 DAV:rebind-source-exists (pre) 24 1650 DAV:unbind-from-collection (pre) 22 1651 DAV:unbind-source-exists (pre) 22 1653 D 1654 DAV header 1655 compliance class 'bind' 31 1656 DAV:bind-into-collection precondition 19 1657 DAV:bind-source-exists precondition 19 1658 DAV:binding-allowed precondition 20 1659 DAV:binding-deleted postcondition 22, 25 1660 DAV:can-overwrite precondition 20, 24 1661 DAV:cross-server-binding precondition 20, 24 1662 DAV:cycle-allowed precondition 20, 24 1663 DAV:lock-deleted postcondition 22, 25 1664 DAV:locked-overwrite-allowed precondition 20 1665 DAV:locked-source-collection-update-allowed precondition 24 1666 DAV:locked-update-allowed precondition 20, 22, 24 1667 DAV:name-allowed precondition 20, 24 1668 DAV:new-binding postcondition 20, 25 1669 DAV:parent-set property 17 1670 DAV:protected-source-url-deletion-allowed precondition 25 1671 DAV:protected-url-deletion-allowed precondition 22 1672 DAV:protected-url-modification-allowed precondition 24 1673 DAV:rebind-from-collection precondition 24 1674 DAV:rebind-source-exists precondition 24 1675 DAV:resource-id property 17 1676 DAV:unbind-from-collection precondition 22 1677 DAV:unbind-source-exists precondition 22 1679 I 1680 Internal Member URI 6 1682 M 1683 Methods 1684 BIND 18 1685 REBIND 23 1686 UNBIND 21 1688 P 1689 Path Segment 6 1690 Properties 1691 DAV:parent-set 17 1692 DAV:resource-id 17 1694 R 1695 REBIND method 23 1696 Marshalling 23 1697 Postconditions 25 1698 Preconditions 24 1700 S 1701 Status Codes 1702 208 Already Reported 28 1703 506 Loop Detected 31 1705 U 1706 UNBIND method 21 1707 Marshalling 21 1708 Postconditions 22 1709 Preconditions 22 1710 URI Mapping 5 1712 Authors' Addresses 1714 Geoffrey Clemm 1715 IBM 1716 20 Maguire Road 1717 Lexington, MA 02421 1719 Email: geoffrey.clemm@us.ibm.com 1720 Jason Crawford 1721 IBM Research 1722 P.O. Box 704 1723 Yorktown Heights, NY 10598 1725 Email: ccjason@us.ibm.com 1727 Julian F. Reschke (editor) 1728 greenbytes GmbH 1729 Hafenweg 16 1730 Muenster, NW 48155 1731 Germany 1733 Email: julian.reschke@greenbytes.de 1735 Jim Whitehead 1736 UC Santa Cruz, Dept. of Computer Science 1737 1156 High Street 1738 Santa Cruz, CA 95064 1740 Email: ejw@cse.ucsc.edu 1742 Full Copyright Statement 1744 Copyright (C) The Internet Society (2006). 1746 This document is subject to the rights, licenses and restrictions 1747 contained in BCP 78, and except as set forth therein, the authors 1748 retain all their rights. 1750 This document and the information contained herein are provided on an 1751 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1752 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1753 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1754 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1755 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1756 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1758 Intellectual Property 1760 The IETF takes no position regarding the validity or scope of any 1761 Intellectual Property Rights or other rights that might be claimed to 1762 pertain to the implementation or use of the technology described in 1763 this document or the extent to which any license under such rights 1764 might or might not be available; nor does it represent that it has 1765 made any independent effort to identify any such rights. Information 1766 on the procedures with respect to rights in RFC documents can be 1767 found in BCP 78 and BCP 79. 1769 Copies of IPR disclosures made to the IETF Secretariat and any 1770 assurances of licenses to be made available, or the result of an 1771 attempt made to obtain a general license or permission for the use of 1772 such proprietary rights by implementers or users of this 1773 specification can be obtained from the IETF on-line IPR repository at 1774 http://www.ietf.org/ipr. 1776 The IETF invites any interested party to bring to its attention any 1777 copyrights, patents or patent applications, or other proprietary 1778 rights that may cover technology that may be required to implement 1779 this standard. Please address the information to the IETF at 1780 ietf-ipr@ietf.org. 1782 Acknowledgment 1784 Funding for the RFC Editor function is provided by the IETF 1785 Administrative Support Activity (IASA).