idnits 2.17.1 draft-ietf-webdav-bind-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1993. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4918, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 554 has weird spacing: '...| x.gif y.g...' == Line 576 has weird spacing: '...| x.gif y.g...' == Line 847 has weird spacing: '...| x.gif y.g...' (Using the creation date from RFC4918, updated by this document, for RFC5378 checks: 2002-02-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 15, 2007) is 6006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Clemm 3 Internet-Draft IBM 4 Updates: 4918 (if approved) J. Crawford 5 Intended status: Standards Track IBM Research 6 Expires: May 18, 2008 J. Reschke, Ed. 7 greenbytes 8 J. Whitehead 9 U.C. Santa Cruz 10 November 15, 2007 12 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) 13 draft-ietf-webdav-bind-20 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 18, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.2. Method Preconditions and Postconditions . . . . . . . . . 7 70 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 71 2.1. Bindings to Collections . . . . . . . . . . . . . . . . . 8 72 2.1.1. Bind loops . . . . . . . . . . . . . . . . . . . . . . 9 73 2.2. URI Mappings Created by a new Binding . . . . . . . . . . 9 74 2.3. COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10 75 2.3.1. Example: COPY with 'Depth: infinity' in presence 76 of bind loops . . . . . . . . . . . . . . . . . . . . 12 77 2.3.2. Example: COPY with 'Depth: infinity' with multiple 78 bindings to a leaf resource . . . . . . . . . . . . . 14 79 2.4. DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15 80 2.5. MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15 81 2.5.1. Example: Simple MOVE . . . . . . . . . . . . . . . . . 16 82 2.5.2. Example: MOVE request causing a bind loop . . . . . . 16 83 2.6. PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 18 84 2.7. Determining Whether Two Bindings Are to the Same 85 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 2.8. Discovering the Bindings to a Resource . . . . . . . . . . 19 87 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 3.1. DAV:resource-id Property . . . . . . . . . . . . . . . . . 19 89 3.2. DAV:parent-set Property . . . . . . . . . . . . . . . . . 20 90 3.2.1. Example for DAV:parent-set property . . . . . . . . . 20 91 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 4.1. Example: BIND . . . . . . . . . . . . . . . . . . . . . . 24 93 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 94 5.1. Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 26 95 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 26 96 6.1. Example: REBIND . . . . . . . . . . . . . . . . . . . . . 28 97 6.2. Example: REBIND in presence of locks and bind loops . . . 29 98 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31 99 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31 100 7.1.1. Example: PROPFIND by bind-aware client . . . . . . . . 32 101 7.1.2. Example: PROPFIND by non-bind-aware client . . . . . . 34 102 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34 103 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 34 104 8.1. OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 34 105 8.2. 'DAV' request header . . . . . . . . . . . . . . . . . . . 34 106 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 108 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 35 109 10.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 35 110 10.3. Bindings, and Denial of Service . . . . . . . . . . . . . 35 111 10.4. Private Locations May Be Revealed . . . . . . . . . . . . 36 112 10.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 36 113 11. Internationalization Considerations . . . . . . . . . . . . . 36 114 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 115 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 116 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 117 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 118 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 119 Appendix A. Clarification to RFC2518bis' Usage of the term 120 'lock root' . . . . . . . . . . . . . . . . . . . . . 37 121 Appendix B. Change Log (to be removed by RFC Editor before 122 publication) . . . . . . . . . . . . . . . . . . . . 38 123 B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 38 124 B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 38 125 B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 38 126 B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 39 127 B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 39 128 B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 39 129 B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 39 130 B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 39 131 B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 39 132 B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 40 133 B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 40 134 B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 40 135 B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 40 136 B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 41 137 B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 41 138 B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 41 139 B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 41 140 B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 41 141 Appendix C. Resolved issues (to be removed by RFC Editor 142 before publication) . . . . . . . . . . . . . . . . . 41 143 C.1. 2.1.1-bind-loops . . . . . . . . . . . . . . . . . . . . . 41 144 C.2. 2.1.1-cycles . . . . . . . . . . . . . . . . . . . . . . . 42 145 C.3. 2.5-move-creating-cycles . . . . . . . . . . . . . . . . . 42 146 C.4. 3.1-clarify-resource-id . . . . . . . . . . . . . . . . . 42 147 C.5. 4-precondition-language . . . . . . . . . . . . . . . . . 42 148 Appendix D. Open issues (to be removed by RFC Editor prior to 149 publication) . . . . . . . . . . . . . . . . . . . . 43 150 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 151 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 153 Intellectual Property and Copyright Statements . . . . . . . . . . 47 155 1. Introduction 157 This specification extends the WebDAV Distributed Authoring Protocol 158 ([RFC4918]) to enable clients to create new access paths to existing 159 resources. This capability is useful for several reasons: 161 URIs of WebDAV-compliant resources are hierarchical and correspond to 162 a hierarchy of collections in resource space. The WebDAV Distributed 163 Authoring Protocol makes it possible to organize these resources into 164 hierarchies, placing them into groupings, known as collections, which 165 are more easily browsed and manipulated than a single flat 166 collection. However, hierarchies require categorization decisions 167 that locate resources at a single location in the hierarchy, a 168 drawback when a resource has multiple valid categories. For example, 169 in a hierarchy of vehicle descriptions containing collections for 170 cars and boats, a description of a combination car/boat vehicle could 171 belong in either collection. Ideally, the description should be 172 accessible from both. Allowing clients to create new URIs that 173 access the existing resource lets them put that resource into 174 multiple collections. 176 Hierarchies also make resource sharing more difficult, since 177 resources that have utility across many collections are still forced 178 into a single collection. For example, the mathematics department at 179 one university might create a collection of information on fractals 180 that contains bindings to some local resources, but also provides 181 access to some resources at other universities. For many reasons, it 182 may be undesirable to make physical copies of the shared resources on 183 the local server: to conserve disk space, to respect copyright 184 constraints, or to make any changes in the shared resources visible 185 automatically. Being able to create new access paths to existing 186 resources in other collections or even on other servers is useful for 187 this sort of case. 189 The BIND method defined here provides a mechanism for allowing 190 clients to create alternative access paths to existing WebDAV 191 resources. HTTP [RFC2616] and WebDAV [RFC4918] methods are able to 192 work because there are mappings between URIs and resources. A method 193 is addressed to a URI, and the server follows the mapping from that 194 URI to a resource, applying the method to that resource. Multiple 195 URIs may be mapped to the same resource, but until now there has been 196 no way for clients to create additional URIs mapped to existing 197 resources. 199 BIND lets clients associate a new URI with an existing WebDAV 200 resource, and this URI can then be used to submit requests to the 201 resource. Since URIs of WebDAV resources are hierarchical, and 202 correspond to a hierarchy of collections in resource space, the BIND 203 method also has the effect of adding the resource to a collection. 204 As new URIs are associated with the resource, it appears in 205 additional collections. 207 A BIND request does not create a new resource, but simply makes 208 available a new URI for submitting requests to an existing resource. 209 The new URI is indistinguishable from any other URI when submitting a 210 request to a resource. Only one round trip is needed to submit a 211 request to the intended target. Servers are required to enforce the 212 integrity of the relationships between the new URIs and the resources 213 associated with them. Consequently, it may be very costly for 214 servers to support BIND requests that cross server boundaries. 216 This specification is organized as follows. Section 1.1 defines 217 terminology used in the rest of the specification, while Section 2 218 overviews bindings. Section 3 defines the new properties needed to 219 support multiple bindings to the same resource. Section 4 specifies 220 the BIND method, used to create multiple bindings to the same 221 resource. Section 5 specifies the UNBIND method, used to remove a 222 binding to a resource. Section 6 specifies the REBIND method, used 223 to move a binding to another collection. 225 1.1. Terminology 227 The terminology used here follows and extends that in the WebDAV 228 Distributed Authoring Protocol specification [RFC4918]. 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119]. 234 This document uses XML DTD fragments ([XML]) as a notational 235 convention, using the rules defined in Section 17 of [RFC4918]. 237 URI Mapping 239 A relation between an absolute URI and a resource. For an 240 absolute URI U and the resource it identifies R, the URI mapping 241 can be thought of as (U => R). Since a resource can represent 242 items that are not network retrievable, as well as those that are, 243 it is possible for a resource to have zero, one, or many URI 244 mappings. Mapping a resource to an "http" scheme URI makes it 245 possible to submit HTTP protocol requests to the resource using 246 the URI. 248 Path Segment 249 Informally, the characters found between slashes ("/") in a URI. 250 Formally, as defined in Section 3.3 of [RFC3986]. 252 Binding 254 A relation between a single path segment (in a collection) and a 255 resource. A binding is part of the state of a collection. If two 256 different collections contain a binding between the same path 257 segment and the same resource, these are two distinct bindings. 258 So for a collection C, a path segment S, and a resource R, the 259 binding can be thought of as C:(S -> R). Bindings create URI 260 mappings, and hence allow requests to be sent to a single resource 261 from multiple locations in a URI namespace. For example, given a 262 collection C (accessible through the URI 263 http://www.example.com/CollX), a path segment S (equal to 264 "foo.html"), and a resource R, then creating the binding C: (S -> 265 R) makes it possible to use the URI 266 http://www.example.com/CollX/foo.html to access R. 268 Collection 270 A resource that contains, as part of its state, a set of bindings 271 that identify internal member resources. 273 Internal Member URI 275 The URI that identifies an internal member of a collection, and 276 that consists of the URI for the collection, followed by a slash 277 character ('/'), followed by the path segment of the binding for 278 that internal member. 280 1.2. Method Preconditions and Postconditions 282 See Section 16 of [RFC4918] for the definitions of "precondition" and 283 "postcondition". 285 2. Overview of Bindings 287 Bindings are part of the state of a collection. They define the 288 internal members of the collection, and the names of those internal 289 members. 291 Bindings are added and removed by a variety of existing HTTP methods. 292 A method that creates a new resource, such as PUT, COPY, and MKCOL, 293 adds a binding. A method that deletes a resource, such as DELETE, 294 removes a binding. A method that moves a resource (e.g. MOVE) both 295 adds a binding (in the destination collection) and removes a binding 296 (in the source collection). The BIND method introduced here provides 297 a mechanism for adding a second binding to an existing resource. 298 There is no difference between an initial binding added by PUT, COPY, 299 or MKCOL, and additional bindings added with BIND. 301 It would be very undesirable if one binding could be destroyed as a 302 side effect of operating on the resource through a different binding. 303 In particular, the removal of one binding to a resource (e.g. with a 304 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 305 e.g. by turning that binding into a dangling path segment. The 306 server MUST NOT reclaim system resources after removing one binding, 307 while other bindings to the resource remain. In other words, the 308 server MUST maintain the integrity of a binding. It is permissible, 309 however, for future method definitions (e.g., a DESTROY method) to 310 have semantics that explicitly remove all bindings and/or immediately 311 reclaim system resources. 313 2.1. Bindings to Collections 315 Creating a new binding to a collection makes each resource associated 316 with a binding in that collection accessible via a new URI, and thus 317 creates new URI mappings to those resources but no new bindings. 319 For example, suppose a new binding CollY is created for collection C1 320 in the figure below. It immediately becomes possible to access 321 resource R1 using the URI /CollY/x.gif and to access resource R2 322 using the URI /CollY/y.jpg, but no new bindings for these child 323 resources were created. This is because bindings are part of the 324 state of a collection, and associate a URI that is relative to that 325 collection with its target resource. No change to the bindings in 326 Collection C1 is needed to make its children accessible using /CollY/ 327 x.gif and /CollY/y.jpg. 329 +-------------------------+ 330 | Root Collection | 331 | bindings: | 332 | CollX CollY | 333 +-------------------------+ 334 | / 335 | / 336 | / 337 +------------------+ 338 | Collection C1 | 339 | bindings: | 340 | x.gif y.jpg | 341 +------------------+ 342 | \ 343 | \ 344 | \ 345 +-------------+ +-------------+ 346 | Resource R1 | | Resource R2 | 347 +-------------+ +-------------+ 349 2.1.1. Bind loops 351 Bindings to collections can result in loops ("cycles"), which servers 352 MUST detect when processing "Depth: infinity" requests. It is 353 sometimes possible to complete an operation in spite of the presence 354 of a loop. For instance, a PROPFIND can still succeed if the server 355 uses the new status code 208 (Already Reported) defined in 356 Section 7.1. 358 However, the 506 (Loop Detected) status code is defined in 359 Section 7.2 for use in contexts where an operation is terminated 360 because a loop was encountered. 362 Support for loops is OPTIONAL: servers MAY reject requests that would 363 lead to the creation of a bind loop (see DAV:cycle-allowed 364 precondition defined in Section 4). 366 2.2. URI Mappings Created by a new Binding 368 Suppose a binding from "Binding-Name" to resource R is to be added to 369 a collection, C. Then if C-MAP is the set of URIs that were mapped to 370 C before the BIND request, then for each URI "C-URI" in C-MAP, the 371 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 372 request. 374 For example, if a binding from "foo.html" to R is added to a 375 collection C, and if the following URIs are mapped to C: 377 http://www.example.com/A/1/ 378 http://example.com/A/one/ 380 then the following new mappings to R are introduced: 382 http://www.example.com/A/1/foo.html 383 http://example.com/A/one/foo.html 385 Note that if R is a collection, additional URI mappings are created 386 to the descendents of R. Also, note that if a binding is made in 387 collection C to C itself (or to a parent of C), an infinite number of 388 mappings are introduced. 390 For example, if a binding from "myself" to C is then added to C, the 391 following infinite number of additional mappings to C are introduced: 393 http://www.example.com/A/1/myself 394 http://www.example.com/A/1/myself/myself 395 ... 397 and the following infinite number of additional mappings to R are 398 introduced: 400 http://www.example.com/A/1/myself/foo.html 401 http://www.example.com/A/1/myself/myself/foo.html 402 ... 404 2.3. COPY and Bindings 406 As defined in Section 9.8 of [RFC4918], COPY causes the resource 407 identified by the Request-URI to be duplicated, and makes the new 408 resource accessible using the URI specified in the Destination 409 header. Upon successful completion of a COPY, a new binding is 410 created between the last path segment of the Destination header, and 411 the destination resource. The new binding is added to its parent 412 collection, identified by the Destination header minus its final 413 segment. 415 The following figure shows an example: Suppose that a COPY is issued 416 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 417 with the Destination header set to URI-X. After successful 418 completion of the COPY operation, resource R is duplicated to create 419 resource R', and a new binding has been created which creates at 420 least the URI mapping between URI-X and the new resource (although 421 other URI mappings may also have been created). 423 URI-1 URI-2 URI-3 URI-X 424 | | | | 425 | | | <---- URI Mappings ----> | 426 | | | | 427 +---------------------+ +------------------------+ 428 | Resource R | | Resource R' | 429 +---------------------+ +------------------------+ 431 It might be thought that a COPY request with "Depth: 0" on a 432 collection would duplicate its bindings, since bindings are part of 433 the collection's state. This is not the case, however. The 434 definition of Depth in [RFC4918] makes it clear that a "Depth: 0" 435 request does not apply to a collection's members. Consequently, a 436 COPY with "Depth: 0" does not duplicate the bindings contained by the 437 collection. 439 If a COPY request causes an existing resource to be updated, the 440 bindings to that resource MUST be unaffected by the COPY request. 441 Using the preceding example, suppose that a COPY request is issued to 442 URI-X for resource R', with the Destination header set to URI-2. The 443 content and dead properties of resource R would be updated to be a 444 copy of those of resource R', but the mappings from URI-1, URI-2, and 445 URI-3 to resource R remain unaffected. If because of multiple 446 bindings to a resource, more than one source resource updates a 447 single destination resource, the order of the updates is server 448 defined. 450 If a COPY request would cause a new resource to be created as a copy 451 of an existing resource, and that COPY request has already created a 452 copy of that existing resource, the COPY request instead creates 453 another binding to the previous copy, instead of creating a new 454 resource. 456 2.3.1. Example: COPY with 'Depth: infinity' in presence of bind loops 458 As an example of how COPY with Depth infinity would work in the 459 presence of bindings, consider the following collection: 461 +------------------+ 462 | Root Collection | 463 | bindings: | 464 | CollX | 465 +------------------+ 466 | 467 | 468 +-------------------------------+ 469 | Collection C1 |<-------+ 470 | bindings: | | 471 | x.gif CollY | | 472 +-------------------------------+ | 473 | \ (creates loop) | 474 | \ | 475 +-------------+ +------------------+ | 476 | Resource R1 | | Collection C2 | | 477 +-------------+ | bindings: | | 478 | y.gif CollZ | | 479 +------------------+ | 480 | | | 481 | +--------+ 482 | 483 +-------------+ 484 | Resource R2 | 485 +-------------+ 487 If a COPY with Depth infinity is submitted to /CollX, with 488 destination of /CollA, the outcome of the copy operation is: 490 +------------------+ 491 | Root Collection | 492 | bindings: | 493 | CollX CollA | 494 +------------------+ 495 | | 496 | +---------------------------+ 497 | | 498 +-------------------+ | 499 | Collection C1 |<------------------+ | 500 | bindings: | | | 501 | x.gif CollY | | | 502 +-------------------+ | | 503 | \ (creates loop) | | 504 | \ | | 505 +-------------+ +-----------------+ | | 506 | Resource R1 | | Collection C2 | | | 507 +-------------+ | bindings: | | | 508 | y.gif CollZ | | | 509 +-----------------+ | | 510 | | | | 511 | +-------+ | 512 | | 513 +-------------+ | 514 | Resource R2 | | 515 +-------------+ | 516 | 517 +-------------------------------+ 518 | 519 +-------------------+ 520 | Collection C3 |<------------------+ 521 | bindings: | | 522 | x.gif CollY | | 523 +-------------------+ | 524 | \ (creates loop) | 525 | \ | 526 +-------------+ +-----------------+ | 527 | Resource R3 | | Collection C4 | | 528 +-------------+ | bindings: | | 529 | y.gif CollZ | | 530 +-----------------+ | 531 | | | 532 | +-------+ 533 | 534 +-------------+ 535 | Resource R4 | 536 +-------------+ 538 2.3.2. Example: COPY with 'Depth: infinity' with multiple bindings to a 539 leaf resource 541 Given the following collection hierarchy: 543 +------------------+ 544 | Root Collection | 545 | bindings: | 546 | CollX | 547 +------------------+ 548 | 549 | 550 | 551 +----------------+ 552 | Collection C1 | 553 | bindings: | 554 | x.gif y.gif | 555 +----------------+ 556 | | 557 | | 558 +-------------+ 559 | Resource R1 | 560 +-------------+ 562 A COPY of /CollX with Depth infinity to /CollY results in the 563 following collection hierarchy: 565 +------------------+ 566 | Root Collection | 567 | bindings: | 568 | CollX CollY | 569 +------------------+ 570 | \ 571 | \ 572 | \ 573 +----------------+ +-----------------+ 574 | Collection C1 | | Collection C2 | 575 | bindings: | | bindings: | 576 | x.gif y.gif | | x.gif y.gif | 577 +----------------+ +-----------------+ 578 | | | | 579 | | | | 580 +-------------+ +-------------+ 581 | Resource R1 | | Resource R2 | 582 +-------------+ +-------------+ 584 2.4. DELETE and Bindings 586 When there are multiple bindings to a resource, a DELETE applied to 587 that resource MUST NOT remove any bindings to that resource other 588 than the one identified by the Request-URI. For example, suppose the 589 collection identified by the URI "/a" has a binding named "x" to a 590 resource R, and another collection identified by "/b" has a binding 591 named "y" to the same resource R. Then a DELETE applied to "/a/x" 592 removes the binding named "x" from "/a" but MUST NOT remove the 593 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 594 to identify the resource R). 596 When DELETE is applied to a collection, it MUST NOT modify the 597 membership of any other collection that is not itself a member of the 598 collection being deleted. For example, if both "/a/.../x" and 599 "/b/.../y" identify the same collection, C, then applying DELETE to 600 "/a" must not delete an internal member from C or from any other 601 collection that is a member of C, because that would modify the 602 membership of "/b". 604 If a collection supports the UNBIND method (see Section 5), a DELETE 605 of an internal member of a collection MAY be implemented as an UNBIND 606 request. In this case, applying DELETE to a Request-URI has the 607 effect of removing the binding identified by the final segment of the 608 Request-URI from the collection identified by the Request-URI minus 609 its final segment. Although [RFC4918] allows a DELETE to be a non- 610 atomic operation, when the DELETE operation is implemented as an 611 UNBIND, the operation is atomic. In particular, a DELETE on a 612 hierarchy of resources is simply the removal of a binding to the 613 collection identified by the Request-URI. 615 2.5. MOVE and Bindings 617 When MOVE is applied to a resource, the other bindings to that 618 resource MUST be unaffected, and if the resource being moved is a 619 collection, the bindings to any members of that collection MUST be 620 unaffected. Also, if MOVE is used with Overwrite:T to delete an 621 existing resource, the constraints specified for DELETE apply. 623 If the destination collection of a MOVE request supports the REBIND 624 method (see Section 6), a MOVE of a resource into that collection MAY 625 be implemented as a REBIND request. Although [RFC4918] allows a MOVE 626 to be a non-atomic operation, when the MOVE operation is implemented 627 as a REBIND, the operation is atomic. In particular, applying a MOVE 628 to a Request-URI and a Destination URI has the effect of removing a 629 binding to a resource (at the Request-URI), and creating a new 630 binding to that resource (at the Destination URI). Even when the 631 Request-URI identifies a collection, the MOVE operation involves only 632 removing one binding to that collection and adding another. 634 2.5.1. Example: Simple MOVE 636 As an example, suppose that a MOVE is issued to URI-3 for resource R 637 below (which is also mapped to URI-1 and URI-2), with the Destination 638 header set to URI-X. After successful completion of the MOVE 639 operation, a new binding has been created which creates the URI 640 mapping between URI-X and resource R. The binding corresponding to 641 the final segment of URI-3 has been removed, which also causes the 642 URI mapping between URI-3 and R to be removed. If resource R were a 643 collection, old URI-3 based mappings to members of R would have been 644 removed, and new URI-X based mappings to members of R would have been 645 created. 647 >> Before Request: 649 URI-1 URI-2 URI-3 650 | | | 651 | | | <---- URI Mappings 652 | | | 653 +---------------------+ 654 | Resource R | 655 +---------------------+ 657 >> After Request: 659 URI-1 URI-2 URI-X 660 | | | 661 | | | <---- URI Mappings 662 | | | 663 +---------------------+ 664 | Resource R | 665 +---------------------+ 667 2.5.2. Example: MOVE request causing a bind loop 669 Note that in the presence of collection bindings, a MOVE request can 670 cause the creating of a bind loop. 672 Consider a the top level collections C1 and C2 with URIs "/CollW/" 673 and "/CollX/". C1 also contains an additional binding named "CollY" 674 to C2: 676 +------------------+ 677 | Root Collection | 678 | bindings: | 679 | CollW CollX | 680 +------------------+ 681 | | 682 | | 683 +------------------+ | 684 | Collection C1 | | 685 | bindings: | | 686 | CollY | | 687 +------------------+ | 688 | | 689 | | 690 +------------------+ 691 | Collection C2 | 692 | | 693 | | 694 +------------------+ 696 In this case, the MOVE request below would cause a bind loop: 698 >> Request: 700 MOVE /CollW HTTP/1.1 701 Host: example.com 702 Destination: /CollX/CollZ 703 If the request succeeded, the resulting state would be: 705 +------------------+ 706 | Root Collection | 707 | bindings: | 708 | CollX | 709 +------------------+ 710 | 711 | 712 +------------------+ | 713 | Collection C1 | | 714 +----> | bindings: | | 715 | | CollY | | 716 | +------------------+ | 717 | | | 718 | | | 719 | +------------------+ 720 | | Collection C2 | 721 | | bindings: | 722 | | CollZ | 723 | +------------------+ 724 | | 725 | | 726 +-------------------+ 728 2.6. PROPFIND and Bindings 730 Consistent with [RFC4918], the value of a dead property MUST be 731 independent of the number of bindings to its host resource or of the 732 path submitted to PROPFIND. On the other hand, the behaviour for 733 each live property depends on its individual definition (for example, 734 see [RFC3744], Section 5, paragraph 2). 736 2.7. Determining Whether Two Bindings Are to the Same Resource 738 It is useful to have some way of determining whether two bindings are 739 to the same resource. Two resources might have identical contents 740 and properties, but not be the same resource (e.g. an update to one 741 resource does not affect the other resource). 743 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 744 resource identifier, which MUST be unique across all resources for 745 all time. If the values of DAV:resource-id returned by PROPFIND 746 requests through two bindings are identical character by character, 747 the client can be assured that the two bindings are to the same 748 resource. 750 The DAV:resource-id property is created, and its value assigned, when 751 the resource is created. The value of DAV:resource-id MUST NOT be 752 changed. Even after the resource is no longer accessible through any 753 URI, that value MUST NOT be reassigned to another resource's DAV: 754 resource-id property. 756 Any method that creates a new resource MUST assign a new, unique 757 value to its DAV:resource-id property. For example, a PUT applied to 758 a null resource, COPY (when not overwriting an existing target) and 759 CHECKIN (see [RFC3253], Section 4.4) must assign a new, unique value 760 to the DAV:resource-id property of the new resource they create. 762 On the other hand, any method that affects an existing resource must 763 not change the value of its DAV:resource-id property. Specifically, 764 a PUT or a COPY that updates an existing resource must not change the 765 value of its DAV:resource-id property. A REBIND, since it does not 766 create a new resource, but only changes the location of an existing 767 resource, must not change the value of the DAV:resource-id property. 769 2.8. Discovering the Bindings to a Resource 771 An OPTIONAL DAV:parent-set property on a resource provides a list of 772 the bindings that associate a collection and a URI segment with that 773 resource. If the DAV:parent-set property exists on a given resource, 774 it MUST contain a complete list of all bindings to that resource that 775 the client is authorized to see. When deciding whether to support 776 the DAV:parent-set property, server implementers / administrators 777 should balance the benefits it provides against the cost of 778 maintaining the property and the security risks enumerated in 779 Sections 10.4 and 10.5. 781 3. Properties 783 The bind feature introduces the properties defined below. 785 A DAV:allprop PROPFIND request SHOULD NOT return any of the 786 properties defined by this document. This allows a binding server to 787 perform efficiently when a naive client, which does not understand 788 the cost of asking a server to compute all possible live properties, 789 issues a DAV:allprop PROPFIND request. 791 3.1. DAV:resource-id Property 793 The DAV:resource-id property is a REQUIRED property that enables 794 clients to determine whether two bindings are to the same resource. 795 The value of DAV:resource-id is a URI, and may use any registered URI 796 scheme that guarantees the uniqueness of the value across all 797 resources for all time (e.g. the urn:uuid: URN namespace defined in 799 [RFC4122] or the opaquelocktoken: URI scheme defined in [RFC4918]). 801 803 Note: by definition, the URI specified in the DAV:resource-id 804 property always is an alternate URI for that resource. 806 3.2. DAV:parent-set Property 808 The DAV:parent-set property is an OPTIONAL property that enables 809 clients to discover what collections contain a binding to this 810 resource (i.e. what collections have that resource as an internal 811 member). It contains an href/segment pair for each collection that 812 has a binding to the resource. The href identifies the collection, 813 and the segment identifies the binding name of that resource in that 814 collection. 816 A given collection MUST appear only once in the DAV:parent-set for 817 any given binding, even if there are multiple URI mappings to that 818 collection. 820 821 822 823 826 3.2.1. Example for DAV:parent-set property 828 For example, if collection C1 is mapped to both /CollX and /CollY, 829 and C1 contains a binding named "x.gif" to a resource R1, then either 830 [/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set 831 of R1, but not both. But if C1 also had a binding named "y.gif" to 832 R1, then there would be two entries for C1 in the DAV:binding-set of 833 R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively, 834 both [/CollY, x.gif] and [/CollY, y.gif]). 836 +-------------------------+ 837 | Root Collection | 838 | bindings: | 839 | CollX CollY | 840 +-------------------------+ 841 | / 842 | / 843 | / 844 +-----------------+ 845 | Collection C1 | 846 | bindings: | 847 | x.gif y.gif | 848 +-----------------+ 849 | | 850 | | 851 | | 852 +--------------+ 853 | Resource R1 | 854 +--------------+ 856 In this case, one possible value for DAV:parent-set property on 857 "/CollX/x.gif" would be: 859 860 861 /CollX 862 x.gif 863 864 865 /CollX 866 y.gif 867 868 870 4. BIND Method 872 The BIND method modifies the collection identified by the Request- 873 URI, by adding a new binding from the segment specified in the BIND 874 body to the resource identified in the BIND body. 876 If a server cannot guarantee the integrity of the binding, the BIND 877 request MUST fail. Note that it is especially difficult to maintain 878 the integrity of cross-server bindings. Unless the server where the 879 resource resides knows about all bindings on all servers to that 880 resource, it may unwittingly destroy the resource or make it 881 inaccessible without notifying another server that manages a binding 882 to the resource. For example, if server A permits creation of a 883 binding to a resource on server B, server A must notify server B 884 about its binding and must have an agreement with B that B will not 885 destroy the resource while A's binding exists. Otherwise server B 886 may receive a DELETE request that it thinks removes the last binding 887 to the resource and destroy the resource while A's binding still 888 exists. The precondition DAV:cross-server-binding is defined below 889 for cases where servers fail cross-server BIND requests because they 890 cannot guarantee the integrity of cross-server bindings. 892 By default, if there already is a binding for the specified segment 893 in the collection, the new binding replaces the existing binding. 894 This default binding replacement behavior can be overridden using the 895 Overwrite header defined in Section 10.6 of [RFC4918]. 897 If a BIND request fails, the server state preceding the request MUST 898 be restored. This method is unsafe and idempotent (see [RFC2616], 899 Section 9.1). 901 Marshalling: 903 The request MAY include an Overwrite header. 905 The request body MUST be a DAV:bind XML element. 907 909 If the request succeeds, the server MUST return 201 (Created) when 910 a new binding was created and 200 (OK) when an existing binding 911 was replaced. 913 If a response body for a successful request is included, it MUST 914 be a DAV:bind-response XML element. Note that this document does 915 not define any elements for the BIND response body, but the DAV: 916 bind-response element is defined to ensure interoperability 917 between future extensions that do define elements for the BIND 918 response body. 920 922 Preconditions: 924 (DAV:bind-into-collection): The Request-URI MUST identify a 925 collection. 927 (DAV:bind-source-exists): The DAV:href element MUST identify a 928 resource. 930 (DAV:binding-allowed): The resource identified by the DAV:href 931 supports multiple bindings to it. 933 (DAV:cross-server-binding): If the resource identified by the DAV: 934 href element in the request body is on another server from the 935 collection identified by the Request-URI, the server MUST support 936 cross-server bindings (servers that do not support cross-server 937 bindings can use this condition code to signal the client exactly 938 why the request failed). 940 (DAV:name-allowed): The name specified by the DAV:segment is 941 available for use as a new binding name. 943 (DAV:can-overwrite): If the collection already contains a binding 944 with the specified path segment, and if an Overwrite header is 945 included, the value of the Overwrite header MUST be "T". 947 (DAV:cycle-allowed): If the DAV:href element identifies a 948 collection, and if the Request-URI identifies a collection that is 949 a member of that collection, the server MUST support cycles in the 950 URI namespace (servers that do not support cycles can use this 951 condition code to signal the client exactly why the request 952 failed). 954 (DAV:locked-update-allowed): If the collection identified by the 955 Request-URI is write-locked, then the appropriate token MUST be 956 specified in an If request header. 958 (DAV:locked-overwrite-allowed): If the collection already contains 959 a binding with the specified path segment, and if that binding is 960 protected by a write-lock, then the appropriate token MUST be 961 specified in an If request header. 963 Postconditions: 965 (DAV:new-binding): The collection MUST have a binding that maps 966 the segment specified in the DAV:segment element in the request 967 body, to the resource identified by the DAV:href element in the 968 request body. 970 4.1. Example: BIND 972 >> Request: 974 BIND /CollY HTTP/1.1 975 Host: www.example.com 976 Content-Type: application/xml; charset="utf-8" 977 Content-Length: xxx 979 980 981 bar.html 982 http://www.example.com/CollX/foo.html 983 985 >> Response: 987 HTTP/1.1 201 Created 989 The server added a new binding to the collection, 990 "http://www.example.com/CollY", associating "bar.html" with the 991 resource identified by the URI 992 "http://www.example.com/CollX/foo.html". Clients can now use the URI 993 "http://www.example.com/CollY/bar.html" to submit requests to that 994 resource. 996 5. UNBIND Method 998 The UNBIND method modifies the collection identified by the Request- 999 URI, by removing the binding identified by the segment specified in 1000 the UNBIND body. 1002 Once a resource is unreachable by any URI mapping, the server MAY 1003 reclaim system resources associated with that resource. If UNBIND 1004 removes a binding to a resource, but there remain URI mappings to 1005 that resource, the server MUST NOT reclaim system resources 1006 associated with the resource. 1008 If an UNBIND request fails, the server state preceding the request 1009 MUST be restored. This method is unsafe and idempotent (see 1010 [RFC2616], Section 9.1). 1012 Marshalling: 1014 The request body MUST be a DAV:unbind XML element. 1016 1017 If the request succeeds, the server MUST return 200 (OK) when the 1018 binding was successfully deleted. 1020 If a response body for a successful request is included, it MUST 1021 be a DAV:unbind-response XML element. Note that this document 1022 does not define any elements for the UNBIND response body, but the 1023 DAV:unbind-response element is defined to ensure interoperability 1024 between future extensions that do define elements for the UNBIND 1025 response body. 1027 1029 Preconditions: 1031 (DAV:unbind-from-collection): The Request-URI MUST identify a 1032 collection. 1034 (DAV:unbind-source-exists): The DAV:segment element MUST identify 1035 a binding in the collection identified by the Request-URI. 1037 (DAV:locked-update-allowed): If the collection identified by the 1038 Request-URI is write-locked, then the appropriate token MUST be 1039 specified in the request. 1041 (DAV:protected-url-deletion-allowed): If the binding identified by 1042 the segment is protected by a write-lock, then the appropriate 1043 token MUST be specified in the request. 1045 Postconditions: 1047 (DAV:binding-deleted): The collection MUST NOT have a binding for 1048 the segment specified in the DAV:segment element in the request 1049 body. 1051 (DAV:lock-deleted): If the internal member URI of the binding 1052 specified by the Request-URI and the DAV:segment element in the 1053 request body was protected by a write-lock at the time of the 1054 request, that write-lock must have been deleted by the request. 1056 5.1. Example: UNBIND 1058 >> Request: 1060 UNBIND /CollX HTTP/1.1 1061 Host: www.example.com 1062 Content-Type: application/xml; charset="utf-8" 1063 Content-Length: xxx 1065 1066 1067 foo.html 1068 1070 >> Response: 1072 HTTP/1.1 200 OK 1074 The server removed the binding named "foo.html" from the collection, 1075 "http://www.example.com/CollX". A request to the resource named 1076 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 1077 response. 1079 6. REBIND Method 1081 The REBIND method removes a binding to a resource from a collection, 1082 and adds a binding to that resource into the collection identified by 1083 the Request-URI. The request body specifies the binding to be added 1084 (segment) and the old binding to be removed (href). It is 1085 effectively an atomic form of a MOVE request, and MUST be treated the 1086 same way as MOVE for the purpose of determining access permissions. 1088 If a REBIND request fails, the server state preceding the request 1089 MUST be restored. This method is unsafe and idempotent (see 1090 [RFC2616], Section 9.1). 1092 Marshalling: 1094 The request MAY include an Overwrite header. 1096 The request body MUST be a DAV:rebind XML element. 1098 1100 If the request succeeds, the server MUST return 201 (Created) when 1101 a new binding was created and 200 (OK) when an existing binding 1102 was replaced. 1104 If a response body for a successful request is included, it MUST 1105 be a DAV:rebind-response XML element. Note that this document 1106 does not define any elements for the REBIND response body, but the 1107 DAV:rebind-response element is defined to ensure interoperability 1108 between future extensions that do define elements for the REBIND 1109 response body. 1111 1113 Preconditions: 1115 (DAV:rebind-into-collection): The Request-URI MUST identify a 1116 collection. 1118 (DAV:rebind-source-exists): The DAV:href element MUST identify a 1119 resource. 1121 (DAV:cross-server-binding): If the resource identified by the DAV: 1122 href element in the request body is on another server from the 1123 collection identified by the Request-URI, the server MUST support 1124 cross-server bindings (servers that do not support cross-server 1125 bindings can use this condition code to signal the client exactly 1126 why the request failed). 1128 (DAV:name-allowed): The name specified by the DAV:segment is 1129 available for use as a new binding name. 1131 (DAV:can-overwrite): If the collection already contains a binding 1132 with the specified path segment, and if an Overwrite header is 1133 included, the value of the Overwrite header MUST be "T". 1135 (DAV:cycle-allowed): If the DAV:href element identifies a 1136 collection, and if the Request-URI identifies a collection that is 1137 a member of that collection, the server MUST support cycles in the 1138 URI namespace (servers that do not support cycles can use this 1139 condition code to signal the client exactly why the request 1140 failed). 1142 (DAV:locked-update-allowed): If the collection identified by the 1143 Request-URI is write-locked, then the appropriate token MUST be 1144 specified in the request. 1146 (DAV:protected-url-modification-allowed): If the collection 1147 identified by the Request-URI already contains a binding with the 1148 specified path segment, and if that binding is protected by a 1149 write-lock, then the appropriate token MUST be specified in the 1150 request. 1152 (DAV:locked-source-collection-update-allowed): If the collection 1153 identified by the parent collection prefix of the DAV:href URI is 1154 write-locked, then the appropriate token MUST be specified in the 1155 request. 1157 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 1158 is protected by a write lock, then the appropriate token MUST be 1159 specified in the request. 1161 Postconditions: 1163 (DAV:new-binding): The collection MUST have a binding that maps 1164 the segment specified in the DAV:segment element in the request 1165 body, to the resource that was identified by the DAV:href element 1166 in the request body. 1168 (DAV:binding-deleted): The URL specified in the DAV:href element 1169 in the request body MUST NOT be mapped to a resource. 1171 (DAV:lock-deleted): If the URL specified in the DAV:href element 1172 in the request body was protected by a write-lock at the time of 1173 the request, that write-lock must have been deleted by the 1174 request. 1176 6.1. Example: REBIND 1178 >> Request: 1180 REBIND /CollX HTTP/1.1 1181 Host: www.example.com 1182 Content-Type: application/xml; charset="utf-8" 1183 Content-Length: xxx 1185 1186 1187 foo.html 1188 http://www.example.com/CollY/bar.html 1189 1191 >> Response: 1193 HTTP/1.1 200 OK 1195 The server added a new binding to the collection, 1196 "http://www.example.com/CollX", associating "foo.html" with the 1197 resource identified by the URI 1198 "http://www.example.com/CollY/bar.html", and removes the binding 1199 named "bar.html" from the collection identified by the URI 1200 "http://www.example.com/CollY". Clients can now use the URI 1201 "http://www.example.com/CollX/foo.html" to submit requests to that 1202 resource, and requests on the URI 1203 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 1204 Found) response. 1206 6.2. Example: REBIND in presence of locks and bind loops 1208 To illustrate the effects of locks and bind loops on a REBIND 1209 operation, consider the following collection: 1211 +------------------+ 1212 | Root Collection | 1213 | bindings: | 1214 | CollW | 1215 +------------------+ 1216 | 1217 | 1218 | 1219 +-------------------------------+ 1220 | Collection C1 |<--------+ 1221 | LOCKED infinity | | 1222 | (lock token L1) | | 1223 | bindings: | | 1224 | CollX CollY | | 1225 +-------------------------------+ | 1226 | | | 1227 | | (creates loop) | 1228 | | | 1229 +-----------------+ +------------------+ | 1230 | Collection C2 | | Collection C3 | | 1231 | (inherit lock) | | (inherit lock) | | 1232 | (lock token L1) | | (lock token L1) | | 1233 | bindings: | | bindings: | | 1234 | {none} | | y.gif CollZ | | 1235 +-----------------+ +------------------+ | 1236 | | | 1237 | +-----+ 1238 | 1239 +---------------------------+ 1240 | Resource R2 | 1241 | (lock inherited from C1) | 1242 | (lock token L1) | 1243 +---------------------------+ 1245 (where L1 is "opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9"). 1247 Note that the binding between CollZ and C1 creates a loop in the 1248 containment hierarchy. Servers are not required to support such 1249 loops, though the server in this example does. 1251 The REBIND request below will remove the segment "CollZ" from C3 and 1252 add a new binding from "CollA" to the collection C2. 1254 REBIND /CollW/CollX HTTP/1.1 1255 Host: www.example.com 1256 If: () 1257 Content-Type: application/xml; charset="utf-8" 1258 Content-Length: xxx 1260 1261 1262 CollA 1263 /CollW/CollY/CollZ 1264 1265 The outcome of the REBIND operation is: 1267 +------------------+ 1268 | Root Collection | 1269 | bindings: | 1270 | CollW | 1271 +------------------+ 1272 | 1273 | 1274 | 1275 +-------------------------------+ 1276 | Collection C1 | 1277 | LOCKED infinity | 1278 | (lock token L1) | 1279 | bindings: | 1280 | CollX CollY | 1281 +-------------------------------+ 1282 | ^ | 1283 | | | 1284 +-----------------+ | +------------------+ 1285 | Collection C2 | | | Collection C3 | 1286 |(inherited lock) | | | (inherited lock) | 1287 |(lock token L1) | | | (lock token L1) | 1288 | bindings: | | | bindings: | 1289 | CollA | | | y.gif | 1290 +-----------------+ | +------------------+ 1291 | | | 1292 +---------------+ | 1293 (creates loop) | 1294 +---------------------------+ 1295 | Resource R2 | 1296 | (inherited lock from C1) | 1297 | (lock token L1) | 1298 +---------------------------+ 1300 7. Additional Status Codes 1302 7.1. 208 Already Reported 1304 The 208 (Already Reported) status code can be used inside a DAV: 1305 propstat response element to avoid enumerating the internal members 1306 of multiple bindings to the same collection repeatedly. For each 1307 binding to a collection inside the request's scope, only one will be 1308 reported with a 200 status, while subsequent DAV:response elements 1309 for all other bindings will use the 208 status, and no DAV:response 1310 elements for their descendants are included. 1312 Note that the 208 status will only occur for "Depth: infinity" 1313 requests, and that it is of particular importance when the multiple 1314 collection bindings cause a bind loop as discussed in Section 2.2. 1316 A client can request the DAV:resource-id property in a PROPFIND 1317 request to guarantee that they can accurately reconstruct the binding 1318 structure of a collection with multiple bindings to a single 1319 resource. 1321 For backward compatibility with clients not aware of the 208 status 1322 code appearing in multistatus response bodies, it SHOULD NOT be used 1323 unless the client has signalled support for this specification using 1324 the "DAV" request header (see Section 8.2). Instead, a 506 status 1325 should be returned when a binding loop is discovered. This allows 1326 the server to return the 506 as the top level return status, if it 1327 discovers it before it started the response, or in the middle of a 1328 multistatus, if it discovers it in the middle of streaming out a 1329 multistatus response. 1331 7.1.1. Example: PROPFIND by bind-aware client 1333 For example, consider a PROPFIND request on /Coll (bound to 1334 collection C), where the members of /Coll are /Coll/Foo (bound to 1335 resource R) and /Coll/Bar (bound to collection C). 1337 >> Request: 1339 PROPFIND /Coll/ HTTP/1.1 1340 Host: www.example.com 1341 Depth: infinity 1342 DAV: bind 1343 Content-Type: application/xml; charset="utf-8" 1344 Content-Length: xxx 1346 1347 1348 1349 1350 1351 1352 1354 >> Response: 1356 HTTP/1.1 207 Multi-Status 1357 Content-Type: application/xml; charset="utf-8" 1358 Content-Length: xxx 1360 1361 1362 1363 http://www.example.com/Coll/ 1364 1365 1366 Loop Demo 1367 1368 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1370 1371 1372 HTTP/1.1 200 OK 1373 1374 1375 1376 http://www.example.com/Coll/Foo 1377 1378 1379 Bird Inventory 1380 1381 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1383 1384 1385 HTTP/1.1 200 OK 1386 1387 1388 1389 http://www.example.com/Coll/Bar 1390 1391 1392 Loop Demo 1393 1394 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1396 1397 1398 HTTP/1.1 208 Already Reported 1399 1400 1401 1403 7.1.2. Example: PROPFIND by non-bind-aware client 1405 In this example, the client isn't aware of the 208 status code 1406 introduced by this specification. As the "Depth: infinity" PROPFIND 1407 request would cause a loop condition, the whole request is rejected 1408 with a 506 status. 1410 >> Request: 1412 PROPFIND /Coll/ HTTP/1.1 1413 Host: www.example.com 1414 Depth: infinity 1415 Content-Type: application/xml; charset="utf-8" 1416 Content-Length: xxx 1418 1419 1420 1421 1423 >> Response: 1425 HTTP/1.1 506 Loop Detected 1427 7.2. 506 Loop Detected 1429 The 506 (Loop Detected) status code indicates that the server 1430 terminated an operation because it encountered an infinite loop while 1431 processing a request with "Depth: infinity". This status indicates 1432 that the entire operation failed. 1434 8. Capability discovery 1436 8.1. OPTIONS method 1438 If the server supports bindings, it MUST return the compliance class 1439 name "bind" as a field in the "DAV" response header (see [RFC4918], 1440 Section 10.1) from an OPTIONS request on any resource implemented by 1441 that server. A value of "bind" in the "DAV" header MUST indicate 1442 that the server supports all MUST level requirements and REQUIRED 1443 features specified in this document. 1445 8.2. 'DAV' request header 1447 Clients SHOULD signal support for all MUST level requirements and 1448 REQUIRED features by submitting a "DAV" request header containing the 1449 compliance class name "bind". In particular, the client MUST 1450 understand the 208 status code defined in Section 7.1. 1452 9. Relationship to WebDAV Access Control Protocol 1454 BIND and REBIND behave the same as MOVE with respect to the DAV:acl 1455 property (see [RFC3744], Section 7.3). 1457 10. Security Considerations 1459 This section is provided to make WebDAV implementors aware of the 1460 security implications of this protocol. 1462 All of the security considerations of HTTP/1.1 and the WebDAV 1463 Distributed Authoring Protocol specification also apply to this 1464 protocol specification. In addition, bindings introduce several new 1465 security concerns and increase the risk of some existing threats. 1466 These issues are detailed below. 1468 10.1. Privacy Concerns 1470 In a context where cross-server bindings are supported, creating 1471 bindings on a trusted server may make it possible for a hostile agent 1472 to induce users to send private information to a target on a 1473 different server. 1475 10.2. Bind Loops 1477 Although bind loops were already possible in HTTP 1.1, the 1478 introduction of the BIND method creates a new avenue for clients to 1479 create loops accidentally or maliciously. If the binding and its 1480 target are on the same server, the server may be able to detect BIND 1481 requests that would create loops. Servers are required to detect 1482 loops that are caused by bindings to collections during the 1483 processing of any requests with "Depth: infinity". 1485 10.3. Bindings, and Denial of Service 1487 Denial of service attacks were already possible by posting URIs that 1488 were intended for limited use at heavily used Web sites. The 1489 introduction of BIND creates a new avenue for similar denial of 1490 service attacks. If cross-server bindings are supported, clients can 1491 now create bindings at heavily used sites to target locations that 1492 were not designed for heavy usage. 1494 10.4. Private Locations May Be Revealed 1496 If the DAV:parent-set property is maintained on a resource, the 1497 owners of the bindings risk revealing private locations. The 1498 directory structures where bindings are located are available to 1499 anyone who has access to the DAV:parent-set property on the resource. 1500 Moving a binding may reveal its new location to anyone with access to 1501 DAV:parent-set on its resource. 1503 10.5. DAV:parent-set and Denial of Service 1505 If the server maintains the DAV:parent-set property in response to 1506 bindings created in other administrative domains, it is exposed to 1507 hostile attempts to make it devote resources to adding bindings to 1508 the list. 1510 11. Internationalization Considerations 1512 All internationalization considerations mentioned in [RFC4918] also 1513 apply to this document. 1515 12. IANA Considerations 1517 Section 7 defines the HTTP status codes 208 (Already Reported) and 1518 506 (Loop Detected), to be added to the registry at 1519 . 1521 13. Acknowledgements 1523 This document is the collaborative product of the authors and Tyson 1524 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1525 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1526 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1527 Spencer Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, 1528 Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe 1529 Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris 1530 Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1531 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1532 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1533 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1534 members of the WebDAV working group. 1536 14. References 1537 14.1. Normative References 1539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1540 Requirement Levels", BCP 14, RFC 2119, March 1997. 1542 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1543 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1544 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1546 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1547 Resource Identifier (URI): Generic Syntax", STD 66, 1548 RFC 3986, January 2005. 1550 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 1551 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1553 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1554 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1555 Edition)", W3C REC-xml-20060816, August 2006, 1556 . 1558 14.2. Informative References 1560 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1561 Whitehead, "Versioning Extensions to WebDAV (Web 1562 Distributed Authoring and Versioning)", RFC 3253, 1563 March 2002. 1565 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1566 Distributed Authoring and Versioning (WebDAV) Access 1567 Control Protocol", RFC 3744, May 2004. 1569 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1570 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1571 July 2005. 1573 Appendix A. Clarification to RFC2518bis' Usage of the term 'lock root' 1575 [RFC4918], Section 9.10.1 claims: 1577 A LOCK request to an existing resource will create a lock on the 1578 resource identified by the Request-URI, provided the resource is 1579 not already locked with a conflicting lock. The resource 1580 identified in the Request-URI becomes the root of the lock. 1582 This is incorrect in that it implies that the "lock root" is a 1583 resource, not a URL 1584 (). 1585 However, should a directly locked resource have multiple bindings, 1586 only the one used in the Request-URI of the LOCK request will be the 1587 protected from changes of clients not supplying the lock token. 1589 A correct description would be: 1591 A LOCK request to an existing resource will create a lock on the 1592 resource identified by the Request-URI, provided the resource is 1593 not already locked with a conflicting lock. The Request-URI 1594 becomes the root of the lock. 1596 Note that this change makes the description consistent with the 1597 definition of the DAV:lockroot XML element in Section 14.12 of 1598 [RFC4918]. 1600 The authors of this specification recommend that future revisions of 1601 [RFC4918] will update the description as suggested above. 1603 Appendix B. Change Log (to be removed by RFC Editor before publication) 1605 B.1. Since draft-ietf-webdav-bind-02 1607 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1608 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1609 resolution, but keep it open. Add issues "ED_references" and 1610 "4_507_status". Started work on index. Rename document to "Binding 1611 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1612 Rename "References" to "Normative References". Close issue 1613 "ED_references". Close issue "4_507_status". 1615 B.2. Since draft-ietf-webdav-bind-03 1617 Add and close issues "9.2_redirect_loops", "ED_authors" and 1618 "ED_updates". Add section about capability discovery (DAV header). 1619 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1620 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1621 "locking" and resolve as invalid. 1623 B.3. Since draft-ietf-webdav-bind-04 1625 Add and close issues "6_precondition_binding_allowed" and 1626 "6_lock_behaviour". Add mailing list and issues list pointers to 1627 front. 1629 B.4. Since draft-ietf-webdav-bind-05 1631 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1632 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1633 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1635 B.5. Since draft-ietf-webdav-bind-06 1637 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1638 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1640 B.6. Since draft-ietf-webdav-bind-07 1642 Add more index items (no change tracking). Add and resolve issues 1643 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1644 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1645 DTD fragment in section 3.3. Make spelling of "Request-URI" 1646 consistent. 1648 B.7. Since draft-ietf-webdav-bind-08 1650 Resolved editorial issues raised by Jim Whitehead in . 1652 Add and resolve issues "atomicity", "2_allow_destroy", 1653 "2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", 1654 "2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops", 1655 "2.6_resource-id_vs_versions", "3.2_example" and 1656 "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open 1657 and resolve "6_rebind_intro". 1659 B.8. Since draft-ietf-webdav-bind-09 1661 Add and resolve issue "6.1_rebind_vs_locks", adding proposed example 1662 text. Add action item "3.1_uuids". Close issue 1663 "2.6_when_do_ids_change". Add and resolve issues 1664 "2.6_bindings_vs_properties" and "uri_draft_ref". 1666 B.9. Since draft-ietf-webdav-bind-10 1668 Resolve action item "3.1_uuids". Add and resolve issue 1669 "2.7_unlock_vs_bindings". Revisit issue 1670 "2.6_bindings_vs_properties", and remove the part of the sentence 1671 that speaks about live properties. Update "rfc2396bis" references to 1672 "RFC3986". Add issue "9_ns_op_and_acl" and add potential resolution. 1673 Align artwork where applicable (new xml2rfc1.29rc2 feature). 1675 B.10. Since draft-ietf-webdav-bind-11 1677 Updated [draft-mealling-uuid-urn] to [RFC4122]. Add statement about 1678 live properties in Section 2.6. 1680 B.11. Since draft-ietf-webdav-bind-12 1682 Updated Author's address. Uppercase "Section" when referring to 1683 other documents. 1685 Updating from RFC2518 to RFC2518bis: 1687 o Remove own explanation of DTD syntax. 1689 o Remove own definition of precondition/postcondition. 1691 o Remove reference to broken RFC2518 language about DELETE and 1692 UNLOCK. 1694 o Remove own definition of DAV: request header. 1696 o Updated "Rationale for Distinguishing Bindings from URI Mappings" 1697 to reflect the changes in [draft-ietf-webdav-rfc2518bis], making 1698 proposals for more changes so that the issue can be closed (see 1699 also 1700 and ). 1703 B.12. Since draft-ietf-webdav-bind-13 1705 Update [draft-ietf-webdav-rfc2518-bis] to draft 14. Update one 1706 incorrect section reference. Remove Section "Rationale for 1707 Distinguishing Bindings from URI Mappings" as 1708 [draft-ietf-webdav-rfc2518-bis] now uses the proper definition of 1709 collection state. Examples use application/xml instead of text/xml 1710 MIME type. 1712 Fix IANA section (there are no IANA considerations). 1714 B.13. Since draft-ietf-webdav-bind-14 1716 Update [draft-ietf-webdav-rfc2518-bis] to draft 15. Update [XML] to 1717 4th edition. 1719 Markup ASCII art for box recognition (doesn't affect ASCII version). 1721 Identify Julian Reschke as Editor. 1723 B.14. Since draft-ietf-webdav-bind-15 1725 Fix typo in RFC2119 keywords section (sorry!). 1727 Update [draft-ietf-webdav-rfc2518-bis] to draft 17. 1729 Add and resolve issue "rfc2518bis-lock-root". 1731 B.15. Since draft-ietf-webdav-bind-16 1733 Add and resolve issue "iana-vs-http-status". 1735 B.16. Since draft-ietf-webdav-bind-17 1737 Update rfc2518bis reference to draft 18 (note that the bug reported 1738 in 1739 is still present). 1741 B.17. Since draft-ietf-webdav-bind-18 1743 Update: draft-ietf-webdav-rfc2518bis replaced by RFC4918. 1745 B.18. Since draft-ietf-webdav-bind-19 1747 Add and resolve issues "2.1.1-bind-loops", "2.1.1-cycles", "2.5-move- 1748 creating-cycles", "3.1-clarify-resource-id" and "4-precondition- 1749 language". 1751 Appendix C. Resolved issues (to be removed by RFC Editor before 1752 publication) 1754 Issues that were either rejected or resolved in this version of this 1755 document. 1757 C.1. 2.1.1-bind-loops 1759 In Section 2.1.1: 1761 Type: edit 1763 julian.reschke@greenbytes.de (2007-07-29): Add a clarification over 1764 here that support for bind loops (= cycles) is optional. 1766 Resolution (2007-11-11): Done. 1768 C.2. 2.1.1-cycles 1770 In Section 2.1.1: 1772 Type: edit 1774 julian.reschke@greenbytes.de (2007-11-11): We never introduce the 1775 term "cycle". 1777 Resolution (2007-11-11): Fixed. 1779 C.3. 2.5-move-creating-cycles 1781 In Section 2.5: 1783 Type: change 1785 julian.reschke@greenbytes.de (2007-11-10): In presence of collection 1786 bindings, a MOVE operation can lead to a bind cycle. Add an example, 1787 and mention the right way to reject the request if that is required. 1788 See thread starting at . 1791 C.4. 3.1-clarify-resource-id 1793 In Section 3.1: 1795 Type: change 1797 julian.reschke@greenbytes.de (2007-11-11): Clarify that as the 1798 resource-id is a URI, it is effectively an alternate identifier for 1799 the resource. Thus, if it is resolvable, it should be resolved to 1800 the same resource. 1802 Resolution (2007-11-11): Done. 1804 C.5. 4-precondition-language 1806 In Section 4: 1808 Type: edit 1810 julian.reschke@greenbytes.de (2007-11-11): Rephrase definitions for 1811 DAV:cross-server-binding and DAV:cycle-allowed so it becomes clear 1812 that support for these features is optional. 1814 Resolution (2007-11-11): Done. 1816 Appendix D. Open issues (to be removed by RFC Editor prior to 1817 publication) 1819 D.1. edit 1821 Type: edit 1823 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1824 editorial fixes/enhancements. 1826 Index 1828 2 1829 208 Already Reported (status code) 31, 36 1831 5 1832 506 Loop Detected (status code) 34, 36 1834 B 1835 BIND method 21 1836 Marshalling 22 1837 Postconditions 23 1838 Preconditions 22 1839 Binding 7 1841 C 1842 Collection 7 1843 Condition Names 1844 DAV:bind-into-collection (pre) 22 1845 DAV:bind-source-exists (pre) 22 1846 DAV:binding-allowed (pre) 23 1847 DAV:binding-deleted (post) 25, 28 1848 DAV:can-overwrite (pre) 23, 27 1849 DAV:cross-server-binding (pre) 23, 27 1850 DAV:cycle-allowed (pre) 23, 27 1851 DAV:lock-deleted (post) 25, 28 1852 DAV:locked-overwrite-allowed (pre) 23 1853 DAV:locked-source-collection-update-allowed (pre) 28 1854 DAV:locked-update-allowed (pre) 23, 25, 27 1855 DAV:name-allowed (pre) 23, 27 1856 DAV:new-binding (post) 23, 28 1857 DAV:protected-source-url-deletion-allowed (pre) 28 1858 DAV:protected-url-deletion-allowed (pre) 25 1859 DAV:protected-url-modification-allowed (pre) 27 1860 DAV:rebind-from-collection (pre) 27 1861 DAV:rebind-source-exists (pre) 27 1862 DAV:unbind-from-collection (pre) 25 1863 DAV:unbind-source-exists (pre) 25 1865 D 1866 DAV header 1867 compliance class 'bind' 34 1868 DAV:bind-into-collection precondition 22 1869 DAV:bind-source-exists precondition 22 1870 DAV:binding-allowed precondition 23 1871 DAV:binding-deleted postcondition 25, 28 1872 DAV:can-overwrite precondition 23, 27 1873 DAV:cross-server-binding precondition 23, 27 1874 DAV:cycle-allowed precondition 23, 27 1875 DAV:lock-deleted postcondition 25, 28 1876 DAV:locked-overwrite-allowed precondition 23 1877 DAV:locked-source-collection-update-allowed precondition 28 1878 DAV:locked-update-allowed precondition 23, 25, 27 1879 DAV:name-allowed precondition 23, 27 1880 DAV:new-binding postcondition 23, 28 1881 DAV:parent-set property 20 1882 DAV:protected-source-url-deletion-allowed precondition 28 1883 DAV:protected-url-deletion-allowed precondition 25 1884 DAV:protected-url-modification-allowed precondition 27 1885 DAV:rebind-from-collection precondition 27 1886 DAV:rebind-source-exists precondition 27 1887 DAV:resource-id property 19 1888 DAV:unbind-from-collection precondition 25 1889 DAV:unbind-source-exists precondition 25 1891 I 1892 Internal Member URI 7 1894 M 1895 Methods 1896 BIND 21 1897 REBIND 26 1898 UNBIND 24 1900 P 1901 Path Segment 6 1902 Properties 1903 DAV:parent-set 20 1904 DAV:resource-id 19 1906 R 1907 REBIND method 26 1908 Marshalling 26 1909 Postconditions 28 1910 Preconditions 27 1912 S 1913 Status Codes 1914 208 Already Reported 31, 36 1915 506 Loop Detected 34, 36 1917 U 1918 UNBIND method 24 1919 Marshalling 24 1920 Postconditions 25 1921 Preconditions 25 1922 URI Mapping 6 1924 Authors' Addresses 1926 Geoffrey Clemm 1927 IBM 1928 20 Maguire Road 1929 Lexington, MA 02421 1931 Email: geoffrey.clemm@us.ibm.com 1933 Jason Crawford 1934 IBM Research 1935 P.O. Box 704 1936 Yorktown Heights, NY 10598 1938 Email: ccjason@us.ibm.com 1940 Julian F. Reschke (editor) 1941 greenbytes GmbH 1942 Hafenweg 16 1943 Muenster, NW 48155 1944 Germany 1946 Email: julian.reschke@greenbytes.de 1948 Jim Whitehead 1949 UC Santa Cruz, Dept. of Computer Science 1950 1156 High Street 1951 Santa Cruz, CA 95064 1953 Email: ejw@cse.ucsc.edu 1955 Full Copyright Statement 1957 Copyright (C) The IETF Trust (2007). 1959 This document is subject to the rights, licenses and restrictions 1960 contained in BCP 78, and except as set forth therein, the authors 1961 retain all their rights. 1963 This document and the information contained herein are provided on an 1964 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1965 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1966 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1967 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1968 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1969 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1971 Intellectual Property 1973 The IETF takes no position regarding the validity or scope of any 1974 Intellectual Property Rights or other rights that might be claimed to 1975 pertain to the implementation or use of the technology described in 1976 this document or the extent to which any license under such rights 1977 might or might not be available; nor does it represent that it has 1978 made any independent effort to identify any such rights. Information 1979 on the procedures with respect to rights in RFC documents can be 1980 found in BCP 78 and BCP 79. 1982 Copies of IPR disclosures made to the IETF Secretariat and any 1983 assurances of licenses to be made available, or the result of an 1984 attempt made to obtain a general license or permission for the use of 1985 such proprietary rights by implementers or users of this 1986 specification can be obtained from the IETF on-line IPR repository at 1987 http://www.ietf.org/ipr. 1989 The IETF invites any interested party to bring to its attention any 1990 copyrights, patents or patent applications, or other proprietary 1991 rights that may cover technology that may be required to implement 1992 this standard. Please address the information to the IETF at 1993 ietf-ipr@ietf.org. 1995 Acknowledgment 1997 Funding for the RFC Editor function is provided by the IETF 1998 Administrative Support Activity (IASA).