idnits 2.17.1 draft-ietf-webdav-bind-11.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1782. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2518, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 579 has weird spacing: '...| x.gif y.g...' == Line 601 has weird spacing: '...| x.gif y.g...' == Line 820 has weird spacing: '...| x.gif y.g...' (Using the creation date from RFC2518, updated by this document, for RFC5378 checks: 1997-07-21) -- 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 (February 17, 2005) is 7009 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 2518 (Obsoleted by RFC 4918) ** 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: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Clemm 2 Internet-Draft IBM 3 Updates: 2518 (if approved) J. Crawford 4 Expires: August 21, 2005 IBM Research 5 J. Reschke 6 greenbytes 7 J. Whitehead 8 U.C. Santa Cruz 9 February 17, 2005 11 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 12 draft-ietf-webdav-bind-11 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 21, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This specification defines bindings, and the BIND method for creating 48 multiple bindings to the same resource. Creating a new binding to a 49 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.2 Rationale for Distinguishing Bindings from URI Mappings . 7 70 1.3 Method Preconditions and Postconditions . . . . . . . . . 8 71 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8 72 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9 73 2.1.1 Bind loops . . . . . . . . . . . . . . . . . . . . . . 10 74 2.2 URI Mappings Created by a new Binding . . . . . . . . . . 10 75 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 11 76 2.3.1 Example: COPY with 'Depth: infinity' in presence 77 of bind loops . . . . . . . . . . . . . . . . . . . . 12 78 2.3.2 Example: COPY with 'Depth: infinity' with multiple 79 bindings to a leaf resource . . . . . . . . . . . . . 14 80 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15 81 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15 82 2.6 PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 16 83 2.7 UNLOCK and Bindings . . . . . . . . . . . . . . . . . . . 16 84 2.8 Determining Whether Two Bindings Are to the Same 85 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 2.9 Discovering the Bindings to a Resource . . . . . . . . . . 17 87 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 18 89 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 18 90 3.2.1 Example for DAV:parent-set property . . . . . . . . . 19 91 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 22 93 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 22 94 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 24 95 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 96 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 26 97 6.2 Example: REBIND in presence of locks and bind loops . . . 27 98 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 29 99 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 29 100 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 30 101 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 31 102 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 32 103 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 32 104 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 32 105 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 32 106 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 32 107 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 33 108 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 33 109 10. Security Considerations . . . . . . . . . . . . . . . . . . 33 110 10.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 33 111 10.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 33 112 10.3 Bindings, and Denial of Service . . . . . . . . . . . . . 34 113 10.4 Private Locations May Be Revealed . . . . . . . . . . . . 34 114 10.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 34 115 11. Internationalization Considerations . . . . . . . . . . . . 34 116 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 117 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 118 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 119 14.1 Normative References . . . . . . . . . . . . . . . . . . . 35 120 14.2 Informative References . . . . . . . . . . . . . . . . . . 35 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 122 A. Change Log (to be removed by RFC Editor before publication) . 36 123 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 36 124 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 37 125 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 37 126 A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 37 127 A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 37 128 A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 37 129 A.7 Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 37 130 A.8 Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 37 131 A.9 Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 38 132 B. Open issues (to be removed by RFC Editor prior to 133 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 38 134 B.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 135 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 136 Intellectual Property and Copyright Statements . . . . . . . . 41 138 1. Introduction 140 This specification extends the WebDAV Distributed Authoring Protocol 141 to enable clients to create new access paths to existing resources. 142 This capability is useful for several reasons: 144 URIs of WebDAV-compliant resources are hierarchical and correspond to 145 a hierarchy of collections in resource space. The WebDAV Distributed 146 Authoring Protocol makes it possible to organize these resources into 147 hierarchies, placing them into groupings, known as collections, which 148 are more easily browsed and manipulated than a single flat 149 collection. However, hierarchies require categorization decisions 150 that locate resources at a single location in the hierarchy, a 151 drawback when a resource has multiple valid categories. For example, 152 in a hierarchy of vehicle descriptions containing collections for 153 cars and boats, a description of a combination car/boat vehicle could 154 belong in either collection. Ideally, the description should be 155 accessible from both. Allowing clients to create new URIs that 156 access the existing resource lets them put that resource into 157 multiple collections. 159 Hierarchies also make resource sharing more difficult, since 160 resources that have utility across many collections are still forced 161 into a single collection. For example, the mathematics department at 162 one university might create a collection of information on fractals 163 that contains bindings to some local resources, but also provides 164 access to some resources at other universities. For many reasons, it 165 may be undesirable to make physical copies of the shared resources on 166 the local server: to conserve disk space, to respect copyright 167 constraints, or to make any changes in the shared resources visible 168 automatically. Being able to create new access paths to existing 169 resources in other collections or even on other servers is useful for 170 this sort of case. 172 The BIND method defined here provides a mechanism for allowing 173 clients to create alternative access paths to existing WebDAV 174 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to 175 work because there are mappings between URIs and resources. A method 176 is addressed to a URI, and the server follows the mapping from that 177 URI to a resource, applying the method to that resource. Multiple 178 URIs may be mapped to the same resource, but until now there has been 179 no way for clients to create additional URIs mapped to existing 180 resources. 182 BIND lets clients associate a new URI with an existing WebDAV 183 resource, and this URI can then be used to submit requests to the 184 resource. Since URIs of WebDAV resources are hierarchical, and 185 correspond to a hierarchy of collections in resource space, the BIND 186 method also has the effect of adding the resource to a collection. 187 As new URIs are associated with the resource, it appears in 188 additional collections. 190 A BIND request does not create a new resource, but simply makes 191 available a new URI for submitting requests to an existing resource. 192 The new URI is indistinguishable from any other URI when submitting a 193 request to a resource. Only one round trip is needed to submit a 194 request to the intended target. Servers are required to enforce the 195 integrity of the relationships between the new URIs and the resources 196 associated with them. Consequently, it may be very costly for 197 servers to support BIND requests that cross server boundaries. 199 This specification is organized as follows. Section 1.1 defines 200 terminology used in the rest of the specification, while Section 2 201 overviews bindings. Section 3 defines the new properties needed to 202 support multiple bindings to the same resource. Section 4 specifies 203 the BIND method, used to create multiple bindings to the same 204 resource. Section 5 specifies the UNBIND method, used to remove a 205 binding to a resource. Section 6 specifies the REBIND method, used 206 to move a binding to another collection. 208 1.1 Terminology 210 The terminology used here follows and extends that in the WebDAV 211 Distributed Authoring Protocol specification [RFC2518]. 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 This document uses XML DTD fragments ([XML]) as a purely notational 218 convention. WebDAV request and response bodies cannot be validated 219 due to the specific extensibility rules defined in section 23 of 220 [RFC2518] and due to the fact that all XML elements defined by this 221 specification use the XML namespace name "DAV:". In particular: 223 o Element names use the "DAV:" namespace. 225 o Element ordering is irrelevant. 227 o Extension elements/attributes (elements/attributes not already 228 defined as valid child elements) may be added anywhere, except 229 when explicitly stated otherwise. 231 URI Mapping 233 A relation between an absolute URI and a resource. For an 234 absolute URI U and the resource it identifies R, the URI mapping 235 can be thought of as (U => R). Since a resource can represent 236 items that are not network retrievable, as well as those that are, 237 it is possible for a resource to have zero, one, or many URI 238 mappings. Mapping a resource to an "http" scheme URI makes it 239 possible to submit HTTP protocol requests to the resource using 240 the URI. 242 Path Segment 244 Informally, the characters found between slashes ("/") in a URI. 245 Formally, as defined in section 3.3 of [RFC3986]. 247 Binding 249 A relation between a single path segment (in a collection) and a 250 resource. A binding is part of the state of a collection. If two 251 different collections contain a binding between the same path 252 segment and the same resource, these are two distinct bindings. 253 So for a collection C, a path segment S, and a resource R, the 254 binding can be thought of as C:(S -> R). Bindings create URI 255 mappings, and hence allow requests to be sent to a single resource 256 from multiple locations in a URI namespace. For example, given a 257 collection C (accessible through the URI 258 http://www.example.com/CollX), a path segment S (equal to 259 "foo.html"), and a resource R, then creating the binding C: (S -> 260 R) makes it possible to use the URI 261 http://www.example.com/CollX/foo.html to access R. 263 Collection 265 A resource that contains, as part of its state, a set of bindings 266 that identify internal member resources. 268 Internal Member URI 270 The URI that identifies an internal member of a collection, and 271 that consists of the URI for the collection, followed by a slash 272 character ('/'), followed by the path segment of the binding for 273 that internal member. 275 1.2 Rationale for Distinguishing Bindings from URI Mappings 277 In [RFC2518], the state of a collection is defined as containing a 278 list of internal member URIs. If there are multiple mappings to a 279 collection, then the state of the collection is different when you 280 refer to it via a different URI. This is undesirable, since ideally 281 a collection's membership should remain the same, independent of 282 which URI was used to reference it. 284 The notion of binding is introduced to separate the final segment of 285 a URI from its parent collection's contribution. This done, a 286 collection can be defined as containing a set of bindings, thus 287 permitting new mappings to a collection without modifying its 288 membership. The authors of this specification anticipate and 289 recommend that future revisions of [RFC2518] will update the 290 definition of the state of a collection to correspond to the 291 definition in this document. 293 1.3 Method Preconditions and Postconditions 295 A "precondition" of a method describes the state on the server that 296 must be true for that method to be performed. A "postcondition" of a 297 method describes the state on the server that must be true after that 298 method has completed. If a method precondition or postcondition for 299 a request is not satisfied, the response status of the request MUST 300 be either 403 (Forbidden) if the request should not be repeated 301 because it will always fail, or 409 (Conflict) if it is expected that 302 the user might be able to resolve the conflict and resubmit the 303 request. 305 In order to allow better client handling of 403 and 409 responses, a 306 distinct XML element type is associated with each method precondition 307 and postcondition of a request. When a particular precondition is 308 not satisfied or a particular postcondition cannot be achieved, the 309 appropriate XML element MUST be returned as the child of a top-level 310 DAV:error element in the response body, unless otherwise negotiated 311 by the request. In a 207 Multi-Status response, the DAV:error 312 element would appear in the appropriate DAV:responsedescription 313 element. 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, which servers MUST 382 detect when processing "Depth: infinity" requests. It is sometimes 383 possible to complete an operation in spite of the presence of a loop. 384 For instance, a PROPFIND can still succeed if the server uses the new 385 status code 208 (Already Reported) defined in Section 7.1. 387 However, the 506 (Loop Detected) status code is defined in 388 Section 7.2 for use in contexts where an operation is terminated 389 because a loop was encountered. 391 2.2 URI Mappings Created by a new Binding 393 Suppose a binding from "Binding-Name" to resource R is to be added to 394 a collection, C. Then if C-MAP is the set of URIs that were mapped to 395 C before the BIND request, then for each URI "C-URI" in C-MAP, the 396 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 397 request. 399 For example, if a binding from "foo.html" to R is added to a 400 collection C, and if the following URIs are mapped to C: 402 http://www.example.com/A/1/ 403 http://example.com/A/one/ 405 then the following new mappings to R are introduced: 407 http://www.example.com/A/1/foo.html 408 http://example.com/A/one/foo.html 410 Note that if R is a collection, additional URI mappings are created 411 to the descendents of R. Also, note that if a binding is made in 412 collection C to C itself (or to a parent of C), an infinite number of 413 mappings are introduced. 415 For example, if a binding from "myself" to C is then added to C, the 416 following infinite number of additional mappings to C are introduced: 418 http://www.example.com/A/1/myself 419 http://www.example.com/A/1/myself/myself 420 ... 422 and the following infinite number of additional mappings to R are 423 introduced: 425 http://www.example.com/A/1/myself/foo.html 426 http://www.example.com/A/1/myself/myself/foo.html 427 ... 429 2.3 COPY and Bindings 431 As defined in Section 8.8 of [RFC2518], COPY causes the resource 432 identified by the Request-URI to be duplicated, and makes the new 433 resource accessible using the URI specified in the Destination 434 header. Upon successful completion of a COPY, a new binding is 435 created between the last path segment of the Destination header, and 436 the destination resource. The new binding is added to its parent 437 collection, identified by the Destination header minus its final 438 segment. 440 The following figure shows an example: Suppose that a COPY is issued 441 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 442 with the Destination header set to URI-X. After successful 443 completion of the COPY operation, resource R is duplicated to create 444 resource R', and a new binding has been created which creates at 445 least the URI mapping between URI-X and the new resource (although 446 other URI mappings may also have been created). 448 URI-1 URI-2 URI-3 URI-X 449 | | | | 450 | | | <---- URI Mappings ----> | 451 | | | | 452 +---------------------+ +------------------------+ 453 | Resource R | | Resource R' | 454 +---------------------+ +------------------------+ 456 It might be thought that a COPY request with "Depth: 0" on a 457 collection would duplicate its bindings, since bindings are part of 458 the collection's state. This is not the case, however. The 459 definition of Depth in [RFC2518] makes it clear that a "Depth: 0" 460 request does not apply to a collection's members. Consequently, a 461 COPY with "Depth: 0" does not duplicate the bindings contained by the 462 collection. 464 If a COPY request causes an existing resource to be updated, the 465 bindings to that resource MUST be unaffected by the COPY request. 466 Using the preceding example, suppose that a COPY request is issued to 467 URI-X for resource R', with the Destination header set to URI-2. The 468 content and dead properties of resource R would be updated to be a 469 copy of those of resource R', but the mappings from URI-1, URI-2, and 470 URI-3 to resource R remain unaffected. If because of multiple 471 bindings to a resource, more than one source resource updates a 472 single destination resource, the order of the updates is server 473 defined. 475 If a COPY request would cause a new resource to be created as a copy 476 of an existing resource, and that COPY request has already created a 477 copy of that existing resource, the COPY request instead creates 478 another binding to the previous copy, instead of creating a new 479 resource. 481 2.3.1 Example: COPY with 'Depth: infinity' in presence of bind loops 483 As an example of how COPY with Depth infinity would work in the 484 presence of bindings, consider the following collection: 486 +------------------+ 487 | Root Collection | 488 | bindings: | 489 | CollX | 490 +------------------+ 491 | 492 | 493 +-------------------------------+ 494 | Collection C1 |<-------+ 495 | bindings: | | 496 | x.gif CollY | | 497 +-------------------------------+ | 498 | \ (creates loop) | 499 | \ | 500 +-------------+ +------------------+ | 501 | Resource R1 | | Collection C2 | | 502 +-------------+ | bindings: | | 503 | y.gif CollZ | | 504 +------------------+ | 505 | | | 506 | +--------+ 507 | 508 +-------------+ 509 | Resource R2 | 510 +-------------+ 512 If a COPY with Depth infinity is submitted to /CollX, with 513 destination of /CollA, the outcome of the copy operation is: 515 +------------------+ 516 | Root Collection | 517 | bindings: | 518 | CollX CollA | 519 +------------------+ 520 | | 521 | +---------------------------+ 522 | | 523 +-------------------+ | 524 | Collection C1 |<------------------+ | 525 | bindings: | | | 526 | x.gif CollY | | | 527 +-------------------+ | | 528 | \ (creates loop) | | 529 | \ | | 530 +-------------+ +-----------------+ | | 531 | Resource R1 | | Collection C2 | | | 532 +-------------+ | bindings: | | | 533 | y.gif CollZ | | | 534 +-----------------+ | | 535 | | | | 536 | +-------+ | 537 | | 538 +-------------+ | 539 | Resource R2 | | 540 +-------------+ | 541 | 542 +-------------------------------+ 543 | 544 +-------------------+ 545 | Collection C3 |<------------------+ 546 | bindings: | | 547 | x.gif CollY | | 548 +-------------------+ | 549 | \ (creates loop) | 550 | \ | 551 +-------------+ +-----------------+ | 552 | Resource R3 | | Collection C4 | | 553 +-------------+ | bindings: | | 554 | y.gif CollZ | | 555 +-----------------+ | 556 | | | 557 | +-------+ 558 | 559 +-------------+ 560 | Resource R4 | 561 +-------------+ 563 2.3.2 Example: COPY with 'Depth: infinity' with multiple bindings to a 564 leaf resource 566 Given the following collection hierarchy: 568 +------------------+ 569 | Root Collection | 570 | bindings: | 571 | CollX | 572 +------------------+ 573 | 574 | 575 | 576 +----------------+ 577 | Collection C1 | 578 | bindings: | 579 | x.gif y.gif | 580 +----------------+ 581 | | 582 | | 583 +-------------+ 584 | Resource R1 | 585 +-------------+ 587 A COPY of /CollX with Depth infinity to /CollY results in the 588 following collection hierarchy: 590 +------------------+ 591 | Root Collection | 592 | bindings: | 593 | CollX CollY | 594 +------------------+ 595 | \ 596 | \ 597 | \ 598 +----------------+ +-----------------+ 599 | Collection C1 | | Collection C2 | 600 | bindings: | | bindings: | 601 | x.gif y.gif | | x.gif y.gif | 602 +----------------+ +-----------------+ 603 | | | | 604 | | | | 605 +-------------+ +-------------+ 606 | Resource R1 | | Resource R2 | 607 +-------------+ +-------------+ 609 2.4 DELETE and Bindings 611 When there are multiple bindings to a resource, a DELETE applied to 612 that resource MUST NOT remove any bindings to that resource other 613 than the one identified by the Request-URI. For example, suppose the 614 collection identified by the URI "/a" has a binding named "x" to a 615 resource R, and another collection identified by "/b" has a binding 616 named "y" to the same resource R. Then a DELETE applied to "/a/x" 617 removes the binding named "x" from "/a" but MUST NOT remove the 618 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 619 to identify the resource R). In particular, although Section 8.6.1 620 of [RFC2518] states that during DELETE processing, a server "MUST 621 remove any URI for the resource identified by the Request-URI from 622 collections which contain it as a member", a server that supports the 623 binding protocol MUST NOT follow this requirement. 625 When DELETE is applied to a collection, it MUST NOT modify the 626 membership of any other collection that is not itself a member of the 627 collection being deleted. For example, if both "/a/.../x" and "/b/ 628 .../y" identify the same collection, C, then applying DELETE to "/a" 629 must not delete an internal member from C or from any other 630 collection that is a member of C, because that would modify the 631 membership of "/b". 633 If a collection supports the UNBIND method (see Section 5), a DELETE 634 of an internal member of a collection MAY be implemented as an UNBIND 635 request. In this case, applying DELETE to a Request-URI has the 636 effect of removing the binding identified by the final segment of the 637 Request-URI from the collection identified by the Request-URI minus 638 its final segment. Although [RFC2518] allows a DELETE to be a non- 639 atomic operation, when the DELETE operation is implemented as an 640 UNBIND, the operation is atomic. In particular, a DELETE on a 641 hierarchy of resources is simply the removal of a binding to the 642 collection identified by the Request-URI. 644 2.5 MOVE and Bindings 646 When MOVE is applied to a resource, the other bindings to that 647 resource MUST be unaffected, and if the resource being moved is a 648 collection, the bindings to any members of that collection MUST be 649 unaffected. Also, if MOVE is used with Overwrite:T to delete an 650 existing resource, the constraints specified for DELETE apply. 652 If the destination collection of a MOVE request supports the REBIND 653 method (see Section 6), a MOVE of a resource into that collection MAY 654 be implemented as a REBIND request. Although [RFC2518] allows a MOVE 655 to be a non-atomic operation, when the MOVE operation is implemented 656 as a REBIND, the operation is atomic. In particular, applying a MOVE 657 to a Request-URI and a Destination URI has the effect of removing a 658 binding to a resource (at the Request-URI), and creating a new 659 binding to that resource (at the Destination URI). Even when the 660 Request-URI identifies a collection, the MOVE operation involves only 661 removing one binding to that collection and adding another. 663 As an example, suppose that a MOVE is issued to URI-3 for resource R 664 below (which is also mapped to URI-1 and URI-2), with the Destination 665 header set to URI-X. After successful completion of the MOVE 666 operation, a new binding has been created which creates the URI 667 mapping between URI-X and resource R. The binding corresponding to 668 the final segment of URI-3 has been removed, which also causes the 669 URI mapping between URI-3 and R to be removed. If resource R were a 670 collection, old URI-3 based mappings to members of R would have been 671 removed, and new URI-X based mappings to members of R would have been 672 created. 674 >> Before Request: 676 URI-1 URI-2 URI-3 677 | | | 678 | | | <---- URI Mappings 679 | | | 680 +---------------------+ 681 | Resource R | 682 +---------------------+ 684 >> After Request: 686 URI-1 URI-2 URI-X 687 | | | 688 | | | <---- URI Mappings 689 | | | 690 +---------------------+ 691 | Resource R | 692 +---------------------+ 694 2.6 PROPFIND and Bindings 696 Consistent with [RFC2518] the value of a dead property MUST be 697 independent of the number of bindings to its host resource or of the 698 path submitted to PROPFIND. 700 2.7 UNLOCK and Bindings 702 Due to the specific language used in section 8.11 of [RFC2518], it 703 might be thought that an UNLOCK request to a locked resource would 704 unlock just the particular binding expressed by the Request-URI, 705 rather than the resource identified by that URI. This is not the 706 case, however. Section 6 of [RFC2518] clearly states that locks are 707 on resources, not URIs, so the server MUST allow UNLOCK to be used to 708 unlock a locked resource through any binding to that resource. The 709 authors of this specification anticipate and recommend that future 710 revisions of [RFC2518] maintain this behavior. 712 2.8 Determining Whether Two Bindings Are to the Same Resource 714 It is useful to have some way of determining whether two bindings are 715 to the same resource. Two resources might have identical contents 716 and properties, but not be the same resource (e.g. an update to one 717 resource does not affect the other resource). 719 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 720 resource identifier, which MUST be unique across all resources for 721 all time. If the values of DAV:resource-id returned by PROPFIND 722 requests through two bindings are identical character by character, 723 the client can be assured that the two bindings are to the same 724 resource. 726 The DAV:resource-id property is created, and its value assigned, when 727 the resource is created. The value of DAV:resource-id MUST NOT be 728 changed. Even after the resource is no longer accessible through any 729 URI, that value MUST NOT be reassigned to another resource's DAV: 730 resource-id property. 732 Any method that creates a new resource MUST assign a new, unique 733 value to its DAV:resource-id property. For example, a PUT applied to 734 a null resource, COPY (when not overwriting an existing target) and 735 CHECKIN (see [RFC3253], section 4.4) must assign a new, unique value 736 to the DAV:resource-id property of the new resource they create. 738 On the other hand, any method that affects an existing resource must 739 not change the value of its DAV:resource-id property. Specifically, 740 a PUT or a COPY that updates an existing resource must not change the 741 value of its DAV:resource-id property. A REBIND, since it does not 742 create a new resource, but only changes the location of an existing 743 resource, must not change the value of the DAV:resource-id property. 745 2.9 Discovering the Bindings to a Resource 747 An OPTIONAL DAV:parent-set property on a resource provides a list of 748 the bindings that associate a collection and a URI segment with that 749 resource. If the DAV:parent-set property exists on a given resource, 750 it MUST contain a complete list of all bindings to that resource that 751 the client is authorized to see. When deciding whether to support 752 the DAV:parent-set property, server implementers / administrators 753 should balance the benefits it provides against the cost of 754 maintaining the property and the security risks enumerated in 755 Sections 10.4 and 10.5. 757 3. Properties 759 The bind feature introduces the properties defined below. 761 A DAV:allprop PROPFIND request SHOULD NOT return any of the 762 properties defined by this document. This allows a binding server to 763 perform efficiently when a naive client, which does not understand 764 the cost of asking a server to compute all possible live properties, 765 issues a DAV:allprop PROPFIND request. 767 3.1 DAV:resource-id Property 769 The DAV:resource-id property is a REQUIRED property that enables 770 clients to determine whether two bindings are to the same resource. 771 The value of DAV:resource-id is a URI, and may use any registered URI 772 scheme that guarantees the uniqueness of the value across all 773 resources for all time (e.g. the urn:uuid: URN namespace defined in 774 [draft-mealling-uuid-urn] or the opaquelocktoken: URI scheme defined 775 in [RFC2518]). 777 779 3.2 DAV:parent-set Property 781 The DAV:parent-set property is an OPTIONAL property that enables 782 clients to discover what collections contain a binding to this 783 resource (i.e. what collections have that resource as an internal 784 member). It contains an of href/segment pair for each collection 785 that has a binding to the resource. The href identifies the 786 collection, and the segment identifies the binding name of that 787 resource in that collection. 789 A given collection MUST appear only once in the DAV:parent-set for 790 any given binding, even if there are multiple URI mappings to that 791 collection. 793 794 795 796 799 3.2.1 Example for DAV:parent-set property 801 For example, if collection C1 is mapped to both /CollX and /CollY, 802 and C1 contains a binding named "x.gif" to a resource R1, then either 803 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 804 of R1, but not both. But if C1 also had a binding named "y.gif" to 805 R1, then there would be two entries for C1 in the DAV:binding-set of 806 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 807 both [/CollY, x.gif] and [/CollY, y.gif]). 809 +-------------------------+ 810 | Root Collection | 811 | bindings: | 812 | CollX CollY | 813 +-------------------------+ 814 | / 815 | / 816 | / 817 +-----------------+ 818 | Collection C1 | 819 | bindings: | 820 | x.gif y.gif | 821 +-----------------+ 822 | | 823 | | 824 | | 825 +--------------+ 826 | Resource R1 | 827 +--------------+ 829 In this case, one possible value for DAV:parent-set property on 830 "/CollX/x.gif" would be: 832 833 834 /CollX 835 x.gif 836 837 838 /CollX 839 y.gif 840 841 843 4. BIND Method 845 The BIND method modifies the collection identified by the Request- 846 URI, by adding a new binding from the segment specified in the BIND 847 body to the resource identified in the BIND body. 849 If a server cannot guarantee the integrity of the binding, the BIND 850 request MUST fail. Note that it is especially difficult to maintain 851 the integrity of cross-server bindings. Unless the server where the 852 resource resides knows about all bindings on all servers to that 853 resource, it may unwittingly destroy the resource or make it 854 inaccessible without notifying another server that manages a binding 855 to the resource. For example, if server A permits creation of a 856 binding to a resource on server B, server A must notify server B 857 about its binding and must have an agreement with B that B will not 858 destroy the resource while A's binding exists. Otherwise server B 859 may receive a DELETE request that it thinks removes the last binding 860 to the resource and destroy the resource while A's binding still 861 exists. The precondition DAV:cross-server-binding is defined below 862 for cases where servers fail cross-server BIND requests because they 863 cannot guarantee the integrity of cross-server bindings. 865 By default, if there already is a binding for the specified segment 866 in the collection, the new binding replaces the existing binding. 867 This default binding replacement behavior can be overridden using the 868 Overwrite header defined in Section 9.6 of [RFC2518]. 870 If a BIND request fails, the server state preceding the request MUST 871 be restored. This method is unsafe and idempotent (see [RFC2616], 872 section 9.1). 874 Marshalling: 876 The request MAY include an Overwrite header. 878 The request body MUST be a DAV:bind XML element. 880 882 If the request succeeds, the server MUST return 201 (Created) when 883 a new binding was created and 200 (OK) when an existing binding 884 was replaced. 886 If a response body for a successful request is included, it MUST 887 be a DAV:bind-response XML element. Note that this document does 888 not define any elements for the BIND response body, but the DAV: 889 bind-response element is defined to ensure interoperability 890 between future extensions that do define elements for the BIND 891 response body. 893 895 Preconditions: 897 (DAV:bind-into-collection): The Request-URI MUST identify a 898 collection. 900 (DAV:bind-source-exists): The DAV:href element MUST identify a 901 resource. 903 (DAV:binding-allowed): The resource identified by the DAV:href 904 supports multiple bindings to it. 906 (DAV:cross-server-binding): If the resource identified by the DAV: 907 href element in the request body is on another server from the 908 collection identified by the Request-URI, the server MUST support 909 cross-server bindings. 911 (DAV:name-allowed): The name specified by the DAV:segment is 912 available for use as a new binding name. 914 (DAV:can-overwrite): If the collection already contains a binding 915 with the specified path segment, and if an Overwrite header is 916 included, the value of the Overwrite header MUST be "T". 918 (DAV:cycle-allowed): If the DAV:href element identifies a 919 collection, and if the Request-URI identifies a collection that is 920 a member of that collection, the server MUST support cycles in the 921 URI namespace. 923 (DAV:locked-update-allowed): If the collection identified by the 924 Request-URI is write-locked, then the appropriate token MUST be 925 specified in an If request header. 927 (DAV:locked-overwrite-allowed): If the collection already contains 928 a binding with the specified path segment, and if that binding is 929 protected by a write-lock, then the appropriate token MUST be 930 specified in an If request header. 932 Postconditions: 934 (DAV:new-binding): The collection MUST have a binding that maps 935 the segment specified in the DAV:segment element in the request 936 body, to the resource identified by the DAV:href element in the 937 request body. 939 4.1 Example: BIND 941 >> Request: 943 BIND /CollY HTTP/1.1 944 Host: www.example.com 945 Content-Type: text/xml; charset="utf-8" 946 Content-Length: xxx 948 949 950 bar.html 951 http://www.example.com/CollX/foo.html 952 954 >> Response: 956 HTTP/1.1 201 Created 958 The server added a new binding to the collection, 959 "http://www.example.com/CollY", associating "bar.html" with the 960 resource identified by the URI 961 "http://www.example.com/CollX/foo.html". Clients can now use the URI 962 "http://www.example.com/CollY/bar.html" to submit requests to that 963 resource. 965 5. UNBIND Method 967 The UNBIND method modifies the collection identified by the Request- 968 URI, by removing the binding identified by the segment specified in 969 the UNBIND body. 971 Once a resource is unreachable by any URI mapping, the server MAY 972 reclaim system resources associated with that resource. If UNBIND 973 removes a binding to a resource, but there remain URI mappings to 974 that resource, the server MUST NOT reclaim system resources 975 associated with the resource. 977 If an UNBIND request fails, the server state preceding the request 978 MUST be restored. This method is unsafe and idempotent (see 979 [RFC2616], section 9.1). 981 Marshalling: 983 The request body MUST be a DAV:unbind XML element. 985 986 If the request succeeds, the server MUST return 200 (OK) when the 987 binding was successfully deleted. 989 If a response body for a successful request is included, it MUST 990 be a DAV:unbind-response XML element. Note that this document 991 does not define any elements for the UNBIND response body, but the 992 DAV:unbind-response element is defined to ensure interoperability 993 between future extensions that do define elements for the UNBIND 994 response body. 996 998 Preconditions: 1000 (DAV:unbind-from-collection): The Request-URI MUST identify a 1001 collection. 1003 (DAV:unbind-source-exists): The DAV:segment element MUST identify 1004 a binding in the collection identified by the Request-URI. 1006 (DAV:locked-update-allowed): If the collection identified by the 1007 Request-URI is write-locked, then the appropriate token MUST be 1008 specified in the request. 1010 (DAV:protected-url-deletion-allowed): If the binding identified by 1011 the segment is protected by a write-lock, then the appropriate 1012 token MUST be specified in the request. 1014 Postconditions: 1016 (DAV:binding-deleted): The collection MUST NOT have a binding for 1017 the segment specified in the DAV:segment element in the request 1018 body. 1020 (DAV:lock-deleted): If the internal member URI of the binding 1021 specified by the Request-URI and the DAV:segment element in the 1022 request body was protected by a write-lock at the time of the 1023 request, that write-lock must have been deleted by the request. 1025 5.1 Example: UNBIND 1027 >> Request: 1029 UNBIND /CollX HTTP/1.1 1030 Host: www.example.com 1031 Content-Type: text/xml; charset="utf-8" 1032 Content-Length: xxx 1034 1035 1036 foo.html 1037 1039 >> Response: 1041 HTTP/1.1 200 OK 1043 The server removed the binding named "foo.html" from the collection, 1044 "http://www.example.com/CollX". A request to the resource named 1045 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1046 response. 1048 6. REBIND Method 1050 The REBIND method removes a binding to a resource from a collection, 1051 and adds a binding to that resource into the collection identified by 1052 the Request-URI. The request body specifies the binding to be added 1053 (segment) and the old binding to be removed (href). It is 1054 effectively an atomic form of a MOVE request, and MUST be treated the 1055 same way as MOVE for the purpose of determining access permissions. 1057 If a REBIND request fails, the server state preceding the request 1058 MUST be restored. This method is unsafe and idempotent (see 1059 [RFC2616], section 9.1). 1061 Marshalling: 1063 The request MAY include an Overwrite header. 1065 The request body MUST be a DAV:rebind XML element. 1067 1069 If the request succeeds, the server MUST return 201 (Created) when 1070 a new binding was created and 200 (OK) when an existing binding 1071 was replaced. 1073 If a response body for a successful request is included, it MUST 1074 be a DAV:rebind-response XML element. Note that this document 1075 does not define any elements for the REBIND response body, but the 1076 DAV:rebind-response element is defined to ensure interoperability 1077 between future extensions that do define elements for the REBIND 1078 response body. 1080 1082 Preconditions: 1084 (DAV:rebind-into-collection): The Request-URI MUST identify a 1085 collection. 1087 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1088 resource. 1090 (DAV:cross-server-binding): If the resource identified by the DAV: 1091 href element in the request body is on another server from the 1092 collection identified by the Request-URI, the server MUST support 1093 cross-server bindings. 1095 (DAV:name-allowed): The name specified by the DAV:segment is 1096 available for use as a new binding name. 1098 (DAV:can-overwrite): If the collection already contains a binding 1099 with the specified path segment, and if an Overwrite header is 1100 included, the value of the Overwrite header MUST be "T". 1102 (DAV:cycle-allowed): If the DAV:href element identifies a 1103 collection, and if the Request-URI identifies a collection that is 1104 a member of that collection, the server MUST support cycles in the 1105 URI namespace. 1107 (DAV:locked-update-allowed): If the collection identified by the 1108 Request-URI is write-locked, then the appropriate token MUST be 1109 specified in the request. 1111 (DAV:protected-url-modification-allowed): If the collection 1112 identified by the Request-URI already contains a binding with the 1113 specified path segment, and if that binding is protected by a 1114 write-lock, then the appropriate token MUST be specified in the 1115 request. 1117 (DAV:locked-source-collection-update-allowed): If the collection 1118 identified by the parent collection prefix of the DAV:href URI is 1119 write-locked, then the appropriate token MUST be specified in the 1120 request. 1122 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1123 is protected by a write lock, then the appropriate token MUST be 1124 specified in the request. 1126 Postconditions: 1128 (DAV:new-binding): The collection MUST have a binding that maps 1129 the segment specified in the DAV:segment element in the request 1130 body, to the resource that was identified by the DAV:href element 1131 in the request body. 1133 (DAV:binding-deleted): The URL specified in the DAV:href element 1134 in the request body MUST NOT be mapped to a resource. 1136 (DAV:lock-deleted): If the URL specified in the DAV:href element 1137 in the request body was protected by a write-lock at the time of 1138 the request, that write-lock must have been deleted by the 1139 request. 1141 6.1 Example: REBIND 1143 >> Request: 1145 REBIND /CollX HTTP/1.1 1146 Host: www.example.com 1147 Content-Type: text/xml; charset="utf-8" 1148 Content-Length: xxx 1150 1151 1152 foo.html 1153 http://www.example.com/CollY/bar.html 1154 1156 >> Response: 1158 HTTP/1.1 200 OK 1160 The server added a new binding to the collection, 1161 "http://www.example.com/CollX", associating "foo.html" with the 1162 resource identified by the URI 1163 "http://www.example.com/CollY/bar.html", and removes the binding 1164 named "bar.html" from the collection identified by the URI 1165 "http://www.example.com/CollY". Clients can now use the URI 1166 "http://www.example.com/CollX/foo.html" to submit requests to that 1167 resource, and requests on the URI 1168 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1169 Found) response. 1171 6.2 Example: REBIND in presence of locks and bind loops 1173 To illustrate the effects of locks and bind loops on a REBIND 1174 operation, consider the following collection: 1176 +------------------+ 1177 | Root Collection | 1178 | bindings: | 1179 | CollW | 1180 +------------------+ 1181 | 1182 | 1183 | 1184 +-------------------------------+ 1185 | Collection C1 |<--------+ 1186 | LOCKED infinity | | 1187 | (lock token L1) | | 1188 | bindings: | | 1189 | CollX CollY | | 1190 +-------------------------------+ | 1191 | | | 1192 | | (creates loop) | 1193 | | | 1194 +-----------------+ +------------------+ | 1195 | Collection C2 | | Collection C3 | | 1196 | (inherit lock) | | (inherit lock) | | 1197 | (lock token L1) | | (lock token L1) | | 1198 | bindings: | | bindings: | | 1199 | {none} | | y.gif CollZ | | 1200 +-----------------+ +------------------+ | 1201 | | | 1202 | +-----+ 1203 | 1204 +---------------------------+ 1205 | Resource R2 | 1206 | (lock inherited from C1) | 1207 | (lock token L1) | 1208 +---------------------------+ 1210 (where L1 is "opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1212 Note that the binding between CollZ and C1 creates a loop in the 1213 containment hierarchy. Servers are not required to support such 1214 loops, though the server in this example does. 1216 The REBIND request below will remove the segment "CollZ" from C3 and 1217 add a new binding from "CollA" to the collection C2. 1219 REBIND /CollW/CollX HTTP/1.1 1220 Host: www.example.com 1221 If: () 1222 Content-Type: text/xml; charset="utf-8" 1223 Content-Length: xxx 1225 1226 1227 CollA 1228 /CollW/CollY/CollZ 1229 1230 The outcome of the REBIND operation is: 1232 +------------------+ 1233 | Root Collection | 1234 | bindings: | 1235 | CollW | 1236 +------------------+ 1237 | 1238 | 1239 | 1240 +-------------------------------+ 1241 | Collection C1 | 1242 | LOCKED infinity | 1243 | (lock token L1) | 1244 | bindings: | 1245 | CollX CollY | 1246 +-------------------------------+ 1247 | ^ | 1248 | | | 1249 +-----------------+ | +------------------+ 1250 | Collection C2 | | | Collection C3 | 1251 |(inherited lock) | | | (inherited lock) | 1252 |(lock token L1) | | | (lock token L1) | 1253 | bindings: | | | bindings: | 1254 | CollA | | | y.gif | 1255 +-----------------+ | +------------------+ 1256 | | | 1257 +---------------+ | 1258 (creates loop) | 1259 +---------------------------+ 1260 | Resource R2 | 1261 | (inherited lock from C1) | 1262 | (lock token L1) | 1263 +---------------------------+ 1265 7. Additional Status Codes 1267 7.1 208 Already Reported 1269 The 208 (Already Reported) status code can be used inside a DAV: 1270 propstat response element to avoid enumerating the internal members 1271 of multiple bindings to the same collection repeatedly. For each 1272 binding to a collection inside the request's scope, only one will be 1273 reported with a 200 status, while subsequent DAV:response elements 1274 for all other bindings will use the 208 status, and no DAV:response 1275 elements for their descendants are included. 1277 Note that the 208 status will only occur for "Depth: infinity" 1278 requests, and that it is of particular importance when the multiple 1279 collection bindings cause a bind loop as discussed in Section 2.2. 1281 A client can request the DAV:resource-id property in a PROPFIND 1282 request to guarantee that they can accurately reconstruct the binding 1283 structure of a collection with multiple bindings to a single 1284 resource. 1286 For backward compatibility with clients not aware of the 208 status 1287 code appearing in multistatus response bodies, it SHOULD NOT be used 1288 unless the client has signalled support for this specification using 1289 the "DAV" request header (see Section 8.2). Instead, a 506 status 1290 should be returned when a binding loop is discovered. This allows 1291 the server to return the 506 as the top level return status, if it 1292 discovers it before it started the response, or in the middle of a 1293 multistatus, if it discovers it in the middle of streaming out a 1294 multistatus response. 1296 7.1.1 Example: PROPFIND by bind-aware client 1298 For example, consider a PROPFIND request on /Coll (bound to 1299 collection C), where the members of /Coll are /Coll/Foo (bound to 1300 resource R) and /Coll/Bar (bound to collection C). 1302 >> Request: 1304 PROPFIND /Coll/ HTTP/1.1 1305 Host: www.example.com 1306 Depth: infinity 1307 DAV: bind 1308 Content-Type: text/xml; charset="utf-8" 1309 Content-Length: xxx 1311 1312 1313 1314 1315 1316 1317 1319 >> Response: 1321 HTTP/1.1 207 Multi-Status 1322 Content-Type: text/xml; charset="utf-8" 1323 Content-Length: xxx 1324 1325 1326 1327 http://www.example.com/Coll/ 1328 1329 1330 Loop Demo 1331 1332 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1334 1335 1336 HTTP/1.1 200 OK 1337 1338 1339 1340 http://www.example.com/Coll/Foo 1341 1342 1343 Bird Inventory 1344 1345 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1347 1348 1349 HTTP/1.1 200 OK 1350 1351 1352 1353 http://www.example.com/Coll/Bar 1354 1355 1356 Loop Demo 1357 1358 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1360 1361 1362 HTTP/1.1 208 Already Reported 1363 1364 1365 1367 7.1.2 Example: PROPFIND by non-bind-aware client 1369 In this example, the client isn't aware of the 208 status code 1370 introduced by this specification. As the "Depth: infinity" PROPFIND 1371 request would cause a loop condition, the whole request is rejected 1372 with a 506 status. 1374 >> Request: 1376 PROPFIND /Coll/ HTTP/1.1 1377 Host: www.example.com 1378 Depth: infinity 1379 Content-Type: text/xml; charset="utf-8" 1380 Content-Length: xxx 1382 1383 1384 1385 1387 >> Response: 1389 HTTP/1.1 506 Loop Detected 1391 7.2 506 Loop Detected 1393 The 506 (Loop Detected) status code indicates that the server 1394 terminated an operation because it encountered an infinite loop while 1395 processing a request with "Depth: infinity". This status indicates 1396 that the entire operation failed. 1398 8. Capability discovery 1400 8.1 OPTIONS method 1402 If the server supports bindings, it MUST return the compliance class 1403 name "bind" as a field in the "DAV" response header (see [RFC2518], 1404 section 9.1) from an OPTIONS request on any resource implemented by 1405 that server. A value of "bind" in the "DAV" header MUST indicate 1406 that the server supports all MUST level requirements and REQUIRED 1407 features specified in this document. 1409 8.2 'DAV' request header 1411 8.2.1 Generic syntax 1413 This specification introduces the 'DAV' request header that allows 1414 clients to signal compliance to specific WebDAV features. It has the 1415 same syntax as the response header defined in [RFC2518], section 9.1, 1416 but MAY be used with any method. 1418 Note that clients MUST NOT submit a specific compliance class name in 1419 the request header unless the specification defining this compliance 1420 class specifically defines its semantics for clients. 1422 Note that if a server chooses to vary the result of a request based 1423 on values in the "DAV" header, the response either MUST NOT be 1424 cacheable or the server MUST mark the response accordingly using the 1425 "Vary" header (see [RFC2616], section 14.44). 1427 8.2.2 Client compliance class 'bind' 1429 Clients SHOULD signal support for all MUST level requirements and 1430 REQUIRED features by submitting a "DAV" request header containing the 1431 compliance class name "bind". In particular, the client MUST 1432 understand the 208 status code defined in Section 7.1. 1434 9. Relationship to WebDAV Access Control Protocol 1436 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1437 property (see [RFC3744], section 7.3). 1439 10. Security Considerations 1441 This section is provided to make WebDAV implementors aware of the 1442 security implications of this protocol. 1444 All of the security considerations of HTTP/1.1 and the WebDAV 1445 Distributed Authoring Protocol specification also apply to this 1446 protocol specification. In addition, bindings introduce several new 1447 security concerns and increase the risk of some existing threats. 1448 These issues are detailed below. 1450 10.1 Privacy Concerns 1452 In a context where cross-server bindings are supported, creating 1453 bindings on a trusted server may make it possible for a hostile agent 1454 to induce users to send private information to a target on a 1455 different server. 1457 10.2 Bind Loops 1459 Although bind loops were already possible in HTTP 1.1, the 1460 introduction of the BIND method creates a new avenue for clients to 1461 create loops accidentally or maliciously. If the binding and its 1462 target are on the same server, the server may be able to detect BIND 1463 requests that would create loops. Servers are required to detect 1464 loops that are caused by bindings to collections during the 1465 processing of any requests with "Depth: infinity". 1467 10.3 Bindings, and Denial of Service 1469 Denial of service attacks were already possible by posting URIs that 1470 were intended for limited use at heavily used Web sites. The 1471 introduction of BIND creates a new avenue for similar denial of 1472 service attacks. If cross-server bindings are supported, clients can 1473 now create bindings at heavily used sites to target locations that 1474 were not designed for heavy usage. 1476 10.4 Private Locations May Be Revealed 1478 If the DAV:parent-set property is maintained on a resource, the 1479 owners of the bindings risk revealing private locations. The 1480 directory structures where bindings are located are available to 1481 anyone who has access to the DAV:parent-set property on the resource. 1482 Moving a binding may reveal its new location to anyone with access to 1483 DAV:parent-set on its resource. 1485 10.5 DAV:parent-set and Denial of Service 1487 If the server maintains the DAV:parent-set property in response to 1488 bindings created in other administrative domains, it is exposed to 1489 hostile attempts to make it devote resources to adding bindings to 1490 the list. 1492 11. Internationalization Considerations 1494 All internationalization considerations mentioned in [RFC2518] also 1495 apply to this document. 1497 12. IANA Considerations 1499 All IANA considerations mentioned in [RFC2518] also apply to this 1500 document. 1502 13. Acknowledgements 1504 This document is the collaborative product of the authors and Tyson 1505 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1506 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1507 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1508 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa 1509 Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe 1510 Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris 1511 Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1512 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1513 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1514 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1515 members of the WebDAV working group. 1517 14. References 1519 14.1 Normative References 1521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1522 Requirement Levels", BCP 14, RFC 2119, March 1997. 1524 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1525 Jensen, "HTTP Extensions for Distributed Authoring -- 1526 WEBDAV", RFC 2518, February 1999. 1528 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1529 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1530 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1532 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1533 Resource Identifier (URI): Generic Syntax", STD 66, 1534 RFC 3986, January 2005. 1536 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1537 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1538 Edition)", W3C REC-xml-20040204, February 2004, 1539 . 1541 14.2 Informative References 1543 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1544 Whitehead, "Versioning Extensions to WebDAV (Web 1545 Distributed Authoring and Versioning)", RFC 3253, 1546 March 2002. 1548 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1549 Distributed Authoring and Versioning (WebDAV) Access 1550 Control Protocol", RFC 3744, May 2004. 1552 [draft-mealling-uuid-urn] 1553 Leach, P., Mealling, M., and R. Salz, "A UUID URN 1554 Namespace", draft-mealling-uuid-urn-05 (work in progress), 1555 January 2005, . 1558 Authors' Addresses 1560 Geoffrey Clemm 1561 IBM 1562 20 Maguire Road 1563 Lexington, MA 02421 1565 Email: geoffrey.clemm@us.ibm.com 1567 Jason Crawford 1568 IBM Research 1569 P.O. Box 704 1570 Yorktown Heights, NY 10598 1572 Email: ccjason@us.ibm.com 1574 Julian F. Reschke 1575 greenbytes GmbH 1576 Salzmannstrasse 152 1577 Muenster, NW 48159 1578 Germany 1580 Email: julian.reschke@greenbytes.de 1582 Jim Whitehead 1583 UC Santa Cruz, Dept. of Computer Science 1584 1156 High Street 1585 Santa Cruz, CA 95064 1587 Email: ejw@cse.ucsc.edu 1589 Appendix A. Change Log (to be removed by RFC Editor before publication) 1591 A.1 Since draft-ietf-webdav-bind-02 1593 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1594 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1595 resolution, but keep it open. Add issues "ED_references" and 1596 "4_507_status". Started work on index. Rename document to "Binding 1597 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1598 Rename "References" to "Normative References". Close issue 1599 "ED_references". Close issue "4_507_status". 1601 A.2 Since draft-ietf-webdav-bind-03 1603 Add and close issues "9.2_redirect_loops", "ED_authors" and 1604 "ED_updates". Add section about capability discovery (DAV header). 1605 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1606 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1607 "locking" and resolve as invalid. 1609 A.3 Since draft-ietf-webdav-bind-04 1611 Add and close issues "6_precondition_binding_allowed" and 1612 "6_lock_behaviour". Add mailing list and issues list pointers to 1613 front. 1615 A.4 Since draft-ietf-webdav-bind-05 1617 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1618 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1619 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1621 A.5 Since draft-ietf-webdav-bind-06 1623 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1624 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1626 A.6 Since draft-ietf-webdav-bind-07 1628 Add more index items (no change tracking). Add and resolve issues 1629 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1630 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1631 DTD fragment in section 3.3. Make spelling of "Request-URI" 1632 consistent. 1634 A.7 Since draft-ietf-webdav-bind-08 1636 Resolved editorial issues raised by Jim Whitehead in . 1638 Add and resolve issues "atomicity", "2_allow_destroy", 1639 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1640 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1641 "2.6_resource-id_vs_versions", "3.2_example" and 1642 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1643 and resolve "6_rebind_intro". 1645 A.8 Since draft-ietf-webdav-bind-09 1647 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1648 text. Add action item "3.1_uuids". Close issue 1649 "2.6_when_do_ids_change". Add and resolve issues 1650 "2.6_bindings_vs_properties" and "uri_draft_ref". 1652 A.9 Since draft-ietf-webdav-bind-10 1654 Resolve action item "3.1_uuids". Add and resolve issue 1655 "2.7_unlock_vs_bindings". Revisit issue 1656 "2.6_bindings_vs_properties", and remove the part of the sentence 1657 that speaks about live properties. Update "rfc2396bis" references to 1658 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1659 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1661 Appendix B. Open issues (to be removed by RFC Editor prior to 1662 publication) 1664 B.1 edit 1666 Type: edit 1668 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1669 editorial fixes/enhancements. 1671 Index 1673 2 1674 208 Already Reported (status code) 29 1676 5 1677 506 Loop Detected (status code) 32 1679 B 1680 BIND method 19 1681 Binding 7 1683 C 1684 Collection 7 1685 Condition Names 1686 DAV:bind-into-collection (pre) 21 1687 DAV:bind-source-exists (pre) 21 1688 DAV:binding-allowed (pre) 21 1689 DAV:binding-deleted (post) 23, 26 1690 DAV:can-overwrite (pre) 21, 25 1691 DAV:cross-server-binding (pre) 21, 25 1692 DAV:cycle-allowed (pre) 21, 25 1693 DAV:lock-deleted (post) 23, 26 1694 DAV:locked-overwrite-allowed (pre) 21 1695 DAV:locked-source-collection-update-allowed (pre) 25 1696 DAV:locked-update-allowed (pre) 21, 23, 25 1697 DAV:name-allowed (pre) 21, 25 1698 DAV:new-binding (post) 21, 26 1699 DAV:protected-source-url-deletion-allowed (pre) 26 1700 DAV:protected-url-deletion-allowed (pre) 23 1701 DAV:protected-url-modification-allowed (pre) 25 1702 DAV:rebind-from-collection (pre) 25 1703 DAV:rebind-source-exists (pre) 25 1704 DAV:unbind-from-collection (pre) 23 1705 DAV:unbind-source-exists (pre) 23 1707 D 1708 DAV header 1709 compliance class 'bind' 32 1710 DAV:bind-into-collection precondition 21 1711 DAV:bind-source-exists precondition 21 1712 DAV:binding-allowed precondition 21 1713 DAV:binding-deleted postcondition 23, 26 1714 DAV:can-overwrite precondition 21, 25 1715 DAV:cross-server-binding precondition 21, 25 1716 DAV:cycle-allowed precondition 21, 25 1717 DAV:lock-deleted postcondition 23, 26 1718 DAV:locked-overwrite-allowed precondition 21 1719 DAV:locked-source-collection-update-allowed precondition 25 1720 DAV:locked-update-allowed precondition 21, 23, 25 1721 DAV:name-allowed precondition 21, 25 1722 DAV:new-binding postcondition 21, 26 1723 DAV:parent-set property 18 1724 DAV:protected-source-url-deletion-allowed precondition 26 1725 DAV:protected-url-deletion-allowed precondition 23 1726 DAV:protected-url-modification-allowed precondition 25 1727 DAV:rebind-from-collection precondition 25 1728 DAV:rebind-source-exists precondition 25 1729 DAV:resource-id property 18 1730 DAV:unbind-from-collection precondition 23 1731 DAV:unbind-source-exists precondition 23 1733 I 1734 Internal Member URI 7 1736 M 1737 Methods 1738 BIND 19 1739 REBIND 24 1740 UNBIND 22 1742 P 1743 Path Segment 7 1744 Properties 1745 DAV:parent-set 18 1746 DAV:resource-id 18 1748 R 1749 REBIND method 24 1751 S 1752 Status Codes 1753 208 Already Reported 29 1754 506 Loop Detected 32 1756 U 1757 UNBIND method 22 1758 URI Mapping 6 1760 Intellectual Property Statement 1762 The IETF takes no position regarding the validity or scope of any 1763 Intellectual Property Rights or other rights that might be claimed to 1764 pertain to the implementation or use of the technology described in 1765 this document or the extent to which any license under such rights 1766 might or might not be available; nor does it represent that it has 1767 made any independent effort to identify any such rights. Information 1768 on the procedures with respect to rights in RFC documents can be 1769 found in BCP 78 and BCP 79. 1771 Copies of IPR disclosures made to the IETF Secretariat and any 1772 assurances of licenses to be made available, or the result of an 1773 attempt made to obtain a general license or permission for the use of 1774 such proprietary rights by implementers or users of this 1775 specification can be obtained from the IETF on-line IPR repository at 1776 http://www.ietf.org/ipr. 1778 The IETF invites any interested party to bring to its attention any 1779 copyrights, patents or patent applications, or other proprietary 1780 rights that may cover technology that may be required to implement 1781 this standard. Please address the information to the IETF at 1782 ietf-ipr@ietf.org. 1784 Disclaimer of Validity 1786 This document and the information contained herein are provided on an 1787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1794 Copyright Statement 1796 Copyright (C) The Internet Society (2005). This document is subject 1797 to the rights, licenses and restrictions contained in BCP 78, and 1798 except as set forth therein, the authors retain all their rights. 1800 Acknowledgment 1802 Funding for the RFC Editor function is currently provided by the 1803 Internet Society.