idnits 2.17.1 draft-ietf-webdav-bind-08.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1531. ** 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 1336 has weird spacing: '...d think that ...' (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 (November 25, 2004) is 7090 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 (~~), 3 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: May 26, 2005 IBM Research 5 J. Reschke 6 greenbytes 7 J. Whitehead 8 U.C. Santa Cruz 9 November 25, 2004 11 Binding Extensions to Web Distributed Authoring and Versioning 12 (WebDAV) 13 draft-ietf-webdav-bind-08 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 26, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This specification defines bindings, and the BIND method for creating 49 multiple bindings to the same resource. Creating a new binding to a 50 resource causes at least one new URI to be mapped to that resource. 51 Servers are required to insure the integrity of any bindings that 52 they allow to be created. 54 Editorial Note (To be removed by RFC Editor before publication) 56 Please send comments to the Distributed Authoring and Versioning 57 (WebDAV) working group at , which may be 58 joined by sending a message with subject "subscribe" to 59 . Discussions of the WEBDAV 60 working group are archived at 61 . 63 lists 64 all registered issues since draft 02. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.2 Rationale for Distinguishing Bindings from URI Mappings . 7 71 1.3 Method Preconditions and Postconditions . . . . . . . . . 8 72 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8 73 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9 74 2.2 URI Mappings Created by a new Binding . . . . . . . . . . 10 75 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 11 76 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 12 77 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 13 78 2.6 Determining Whether Two Bindings Are to the Same 79 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 2.7 Discovering the Bindings to a Resource . . . . . . . . . . 14 81 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 15 83 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 15 84 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 18 86 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 18 87 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 20 88 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 20 89 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 22 90 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 23 91 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 23 92 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 23 93 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 25 94 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 25 95 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 26 96 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 26 97 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 26 98 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 26 99 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 26 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 27 102 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 27 103 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 27 104 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 27 105 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 27 106 10. Internationalization Considerations . . . . . . . . . . . . 27 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 108 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 109 13. Normative References . . . . . . . . . . . . . . . . . . . . 28 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 111 A. Change Log (to be removed by RFC Editor before publication) . 29 112 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 29 113 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 30 114 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 30 115 A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 30 116 A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 30 117 A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 30 118 B. Resolved issues (to be removed by RFC Editor before 119 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30 120 B.1 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30 121 B.2 bind_vs_ACL . . . . . . . . . . . . . . . . . . . . . . . 31 122 B.3 bind_properties . . . . . . . . . . . . . . . . . . . . . 31 123 B.4 2.3_copy_to_same . . . . . . . . . . . . . . . . . . . . . 31 124 B.5 6_rebind_intro . . . . . . . . . . . . . . . . . . . . . . 32 125 C. Open issues (to be removed by RFC Editor prior to 126 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 32 127 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 128 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 129 Intellectual Property and Copyright Statements . . . . . . . . 35 131 1. Introduction 133 This specification extends the WebDAV Distributed Authoring Protocol 134 to enable clients to create new access paths to existing resources. 135 This capability is useful for several reasons: 137 URIs of WebDAV-compliant resources are hierarchical and correspond to 138 a hierarchy of collections in resource space. The WebDAV Distributed 139 Authoring Protocol makes it possible to organize these resources into 140 hierarchies, placing them into groupings, known as collections, which 141 are more easily browsed and manipulated than a single flat 142 collection. However, hierarchies require categorization decisions 143 that locate resources at a single location in the hierarchy, a 144 drawback when a resource has multiple valid categories. For example, 145 in a hierarchy of vehicle descriptions containing collections for 146 cars and boats, a description of a combination car/boat vehicle could 147 belong in either collection. Ideally, the description should be 148 accessible from both. Allowing clients to create new URIs that 149 access the existing resource lets them put that resource into 150 multiple collections. 152 Hierarchies also make resource sharing more difficult, since 153 resources that have utility across many collections are still forced 154 into a single collection. For example, the mathematics department at 155 one university might create a collection of information on fractals 156 that contains bindings to some local resources, but also provides 157 access to some resources at other universities. For many reasons, it 158 may be undesirable to make physical copies of the shared resources on 159 the local server: to conserve disk space, to respect copyright 160 constraints, or to make any changes in the shared resources visible 161 automatically. Being able to create new access paths to existing 162 resources in other collections or even on other servers is useful for 163 this sort of case. 165 The BIND method defined here provides a mechanism for allowing 166 clients to create alternative access paths to existing WebDAV 167 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to 168 work because there are mappings between URIs and resources. A method 169 is addressed to a URI, and the server follows the mapping from that 170 URI to a resource, applying the method to that resource. Multiple 171 URIs may be mapped to the same resource, but until now there has been 172 no way for clients to create additional URIs mapped to existing 173 resources. 175 BIND lets clients associate a new URI with an existing WebDAV 176 resource, and this URI can then be used to submit requests to the 177 resource. Since URIs of WebDAV resources are hierarchical, and 178 correspond to a hierarchy of collections in resource space, the BIND 179 method also has the effect of adding the resource to a collection. 180 As new URIs are associated with the resource, it appears in 181 additional collections. 183 A BIND request does not create a new resource, but simply makes 184 available a new URI for submitting requests to an existing resource. 185 The new URI is indistinguishable from any other URI when submitting a 186 request to a resource. Only one round trip is needed to submit a 187 request to the intended target. Servers are required to enforce the 188 integrity of the relationships between the new URIs and the resources 189 associated with them. Consequently, it may be very costly for 190 servers to support BIND requests that cross server boundaries. 192 This specification is organized as follows. Section 1.1 defines 193 terminology used in the rest of the specification, while Section 2 194 overviews bindings. Section 3 defines the new properties needed to 195 support multiple bindings to the same resource. Section 4 specifies 196 the BIND method, used to create multiple bindings to the same 197 resource. Section 5 specifies the UNBIND method, used to remove a 198 binding to a resource. Section 6 specifies the REBIND method, used 199 to move a binding to another collection. 201 1.1 Terminology 203 The terminology used here follows and extends that in the WebDAV 204 Distributed Authoring Protocol specification [RFC2518]. 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 This document uses XML DTD fragments ([XML]) as a purely notational 211 convention. WebDAV request and response bodies cannot be validated 212 due to the specific extensibility rules defined in section 23 of 213 [RFC2518] and due to the fact that all XML elements defined by this 214 specification use the XML namespace name "DAV:". In particular: 216 o Element names use the "DAV:" namespace. 218 o Element ordering is irrelevant. 220 o Extension elements/attributes (elements/attributes not already 221 defined as valid child elements) may be added anywhere, except 222 when explicitly stated otherwise. 224 URI Mapping 226 A relation between an absolute URI and a resource. For an 227 absolute URI U and the resource it identifies R, the URI mapping 228 can be thought of as (U => R). Since a resource can represent 229 items that are not network retrievable, as well as those that are, 230 it is possible for a resource to have zero, one, or many URI 231 mappings. Mapping a resource to an "http" scheme URI makes it 232 possible to submit HTTP protocol requests to the resource using 233 the URI. 235 Path Segment 237 Informally, the characters found between slashes ("/") in a URI. 238 Formally, as defined in section 3.3 of 239 [draft-fielding-rfc2396bis]. 241 Binding 243 A relation between a single path segment (in a collection) and a 244 resource. A binding is part of the state of a collection. If two 245 different collections contain a binding between the same path 246 segment and the same resource, these are two distinct bindings. 247 So for a collection C, a path segment S, and a resource R, the 248 binding can be thought of as C:(S -> R). Bindings create URI 249 mappings, and hence allow requests to be sent to a single resource 250 from multiple locations in a URI namespace. For example, given a 251 collection C (accessible through the URI 252 http://www.example.com/CollX), a path segment S (equal to 253 "foo.html"), and a resource R, then creating the binding C: (S -> 254 R) makes it possible to use the URI 255 http://www.example.com/CollX/foo.html to access R. 257 Collection 259 A resource that contains, as part of its state, a set of bindings 260 that identify internal member resources. 262 Internal Member URI 264 The URI that identifies an internal member of a collection, and 265 that consists of the URI for the collection, followed by a slash 266 character ('/'), followed by the path segment of the binding for 267 that internal member. 269 1.2 Rationale for Distinguishing Bindings from URI Mappings 271 In [RFC2518], the state of a collection is defined as containing a 272 list of internal member URIs. If there are multiple mappings to a 273 collection, then the state of the collection is different when you 274 refer to it via a different URI. This is undesirable, since ideally 275 a collection's membership should remain the same, independent of 276 which URI was used to reference it. 278 The notion of binding is introduced to separate the final segment of 279 a URI from its parent collection's contribution. This done, a 280 collection can be defined as containing a set of bindings, thus 281 permitting new mappings to a collection without modifying its 282 membership. The authors of this specification anticipate and 283 recommend that future revisions of [RFC2518] will update the 284 definition of the state of a collection to correspond to the 285 definition in this document. 287 1.3 Method Preconditions and Postconditions 289 A "precondition" of a method describes the state on the server that 290 must be true for that method to be performed. A "postcondition" of a 291 method describes the state on the server that must be true after that 292 method has completed. If a method precondition or postcondition for 293 a request is not satisfied, the response status of the request MUST 294 be either 403 (Forbidden) if the request should not be repeated 295 because it will always fail, or 409 (Conflict) if it is expected that 296 the user might be able to resolve the conflict and resubmit the 297 request. 299 In order to allow better client handling of 403 and 409 responses, a 300 distinct XML element type is associated with each method precondition 301 and postcondition of a request. When a particular precondition is 302 not satisfied or a particular postcondition cannot be achieved, the 303 appropriate XML element MUST be returned as the child of a top-level 304 DAV:error element in the response body, unless otherwise negotiated 305 by the request. In a 207 Multi-Status response, the DAV:error 306 element would appear in the appropriate DAV:responsedescription 307 element. 309 2. Overview of Bindings 311 Bindings are part of the state of a collection. They define the 312 internal members of the collection, and the names of those internal 313 members. 315 Bindings are added and removed by a variety of existing HTTP methods. 316 A method that creates a new resource, such as PUT, COPY, and MKCOL, 317 adds a binding. A method that deletes a resource, such as DELETE, 318 removes a binding. A method that moves a resource (e.g. MOVE) both 319 adds a binding (in the destination collection) and removes a binding 320 (in the source collection). The BIND method introduced here provides 321 a mechanism for adding a second binding to an existing resource. 323 There is no difference between an initial binding added by PUT, COPY, 324 or MKCOL, and additional bindings added with BIND. 326 It would be very undesirable if one binding could be destroyed as a 327 side effect of operating on the resource through a different binding. 328 In particular, the removal of one binding to a resource (e.g. with a 329 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 330 e.g. by turning that binding into a dangling path segment. The 331 server MUST NOT reclaim system resources after removing one binding, 332 while other bindings to the resource remain. In other words, the 333 server MUST maintain the integrity of a binding. 335 2.1 Bindings to Collections 337 Bindings to collections can result in loops, which servers MUST 338 detect when processing "Depth: infinity" requests. It is sometimes 339 possible to complete an operation in spite of the presence of a loop. 340 However, the 506 (Loop Detected) status code is defined in Section 7 341 for use in contexts where an operation is terminated because a loop 342 was encountered. 344 Creating a new binding to a collection makes each resource associated 345 with a binding in that collection accessible via a new URI, and thus 346 creates new URI mappings to those resources but no new bindings. 348 For example, suppose a new binding CollY is created for collection C1 349 in the figure below. It immediately becomes possible to access 350 resource R1 using the URI /CollY/x.gif and to access resource R2 351 using the URI /CollY/y.jpg, but no new bindings for these child 352 resources were created. This is because bindings are part of the 353 state of a collection, and associate a URI that is relative to that 354 collection with its target resource. No change to the bindings in 355 Collection C1 is needed to make its children accessible using 356 /CollY/x.gif and /CollY/y.jpg. 358 +-------------------------+ 359 | Root Collection | 360 | bindings: | 361 | CollX CollY | 362 +-------------------------+ 363 | / 364 | / 365 | / 366 +------------------+ 367 | Collection C1 | 368 | bindings: | 369 | x.gif y.jpg | 370 +------------------+ 371 | \ 372 | \ 373 | \ 374 +-------------+ +-------------+ 375 | Resource R1 | | Resource R2 | 376 +-------------+ +-------------+ 378 2.2 URI Mappings Created by a new Binding 380 Suppose a binding from "Binding-Name" to resource R is to be added to 381 a collection, C. Then if C-MAP is the set of URIs that were mapped 382 to C before the BIND request, then for each URI "C-URI" in C-MAP, the 383 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 384 request. 386 For example, if a binding from "foo.html" to R is added to a 387 collection C, and if the following URIs are mapped to C: 389 http://www.example.com/A/1/ 390 http://example.com/A/one/ 392 then the following new mappings to R are introduced: 394 http://www.example.com/A/1/foo.html 395 http://example.com/A/one/foo.html 397 Note that if R is a collection, additional URI mappings are created 398 to the descendents of R. Also, note that if a binding is made in 399 collection C to C itself (or to a parent of C), an infinite number of 400 mappings are introduced. 402 For example, if a binding from "myself" to C is then added to C, the 403 following infinite number of additional mappings to C are introduced: 405 http://www.example.com/A/1/myself 406 http://www.example.com/A/1/myself/myself 407 ... 409 and the following infinite number of additional mappings to R are 410 introduced: 412 http://www.example.com/A/1/myself/foo.html 413 http://www.example.com/A/1/myself/myself/foo.html 414 ... 416 2.3 COPY and Bindings 418 As defined in Section 8.8 of [RFC2518], COPY causes the resource 419 identified by the Request-URI to be duplicated, and makes the new 420 resource accessible using the URI specified in the Destination 421 header. Upon successful completion of a COPY, a new binding is 422 created between the last path segment of the Destination header, and 423 the destination resource. The new binding is added to its parent 424 collection, identified by the Destination header minus its final 425 segment. 427 The following figure shows an example: Suppose that a COPY is issued 428 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 429 with the Destination header set to URI-X. After successful 430 completion of the COPY operation, resource R is duplicated to create 431 resource R', and a new binding has been created which creates at 432 least the URI mapping between URI-X and the new resource (although 433 other URI mappings may also have been created). 435 URI-1 URI-2 URI-3 URI-X 436 | | | | 437 | | | <---- URI Mappings ----> | 438 | | | | 439 +---------------------+ +------------------------+ 440 | Resource R | | Resource R' | 441 +---------------------+ +------------------------+ 443 It might be thought that a COPY request with "Depth: 0" on a 444 collection would duplicate its bindings, since bindings are part of 445 the collection's state. This is not the case, however. The 446 definition of Depth in [RFC2518] makes it clear that a "Depth: 0" 447 request does not apply to a collection's members. Consequently, a 448 COPY with "Depth: 0" does not duplicate the bindings contained by the 449 collection. 451 If a COPY request causes an existing resource to be updated, the 452 bindings to that resource MUST be unaffected by the COPY request. 453 Using the preceding example, suppose that a COPY request is issued to 454 URI-X for resource R', with the Destination header set to URI-2. The 455 content and dead properties of resource R would be updated to be a 456 copy of those of resource R', but the mappings from URI-1, URI-2, and 457 URI-3 to resource R remain unaffected. If because of multiple 458 bindings to a resource, more than one source resource updates a 459 single destination resource, the order of the updates is server 460 defined. 462 If a COPY request would cause a new resource to be created as a copy 463 of an existing resource, and that COPY request has already created a 464 copy of that existing resource, the COPY request instead creates 465 another binding to the previous copy, instead of creating a new 466 resource. 468 2.4 DELETE and Bindings 470 When there are multiple bindings to a resource, a DELETE applied to 471 that resource MUST NOT remove any bindings to that resource other 472 than the one identified by the Request-URI. For example, suppose the 473 collection identified by the URI "/a" has a binding named "x" to a 474 resource R, and another collection identified by "/b" has a binding 475 named "y" to the same resource R. Then a DELETE applied to "/a/x" 476 removes the binding named "x" from "/a" but MUST NOT remove the 477 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 478 to identify the resource R). In particular, although Section 8.6.1 479 of [RFC2518] states that during DELETE processing, a server "MUST 480 remove any URI for the resource identified by the Request-URI from 481 collections which contain it as a member", a server that supports the 482 binding protocol MUST NOT follow this requirement. 484 When DELETE is applied to a collection, it MUST NOT modify the 485 membership of any other collection that is not itself a member of the 486 collection being deleted. For example, if both "/a/.../x" and 487 "/b/.../y" identify the same collection, C, then applying DELETE to 488 "/a" MUST NOT delete an internal member from C or from any other 489 collection that is a member of C, because that would modify the 490 membership of "/b". 492 If a collection supports the UNBIND method (see Section 5), a DELETE 493 of an internal member of a collection MAY be implemented as an UNBIND 494 request. In this case, applying DELETE to a Request-URI has the 495 effect of removing the binding identified by the final segment of the 496 Request-URI from the collection identified by the Request-URI minus 497 its final segment. Although [RFC2518] allows a DELETE to be a 498 non-atomic operation, when the DELETE operation is implemented as an 499 UNBIND, the operation is atomic. In particular, a DELETE on a 500 hierarchy of resources is simply the removal of a binding to the 501 collection identified by the Request-URI. 503 2.5 MOVE and Bindings 505 When MOVE is applied to a resource, the other bindings to that 506 resource MUST be unaffected, and if the resource being moved is a 507 collection, the bindings to any members of that collection MUST be 508 unaffected. Also, if MOVE is used with Overwrite:T to delete an 509 existing resource, the constraints specified for DELETE apply. 511 If the destination collection of a MOVE request supports the REBIND 512 method (see Section 6), a MOVE of a resource into that collection MAY 513 be implemented as a REBIND request. Although [RFC2518] allows a MOVE 514 to be a non-atomic operation, when the MOVE operation is implemented 515 as a REBIND, the operation is atomic. In particular, applying a MOVE 516 to a Request-URI and a Destination URI has the effect of removing a 517 binding to a resource (at the Request-URI), and creating a new 518 binding to that resource (at the Destination URI). Even when the 519 Request-URI identifies a collection, the MOVE operation involves only 520 removing one binding to that collection and adding another. 522 As an example, suppose that a MOVE is issued to URI-3 for resource R 523 below (which is also mapped to URI-1 and URI-2), with the Destination 524 header set to URI-X. After successful completion of the MOVE 525 operation, a new binding has been created which creates the URI 526 mapping between URI-X and resource R. The binding corresponding to 527 the final segment of URI-3 has been removed, which also causes the 528 URI mapping between URI-3 and R to be removed. If resource R were a 529 collection, old URI-3 based mappings to members of R would have been 530 removed, and new URI-X based mappings to members of R would have been 531 created. 533 >> Before Request: 535 URI-1 URI-2 URI-3 536 | | | 537 | | | <---- URI Mappings 538 | | | 539 +---------------------+ 540 | Resource R | 541 +---------------------+ 542 >> After Request: 544 URI-1 URI-2 URI-X 545 | | | 546 | | | <---- URI Mappings 547 | | | 548 +---------------------+ 549 | Resource R | 550 +---------------------+ 552 2.6 Determining Whether Two Bindings Are to the Same Resource 554 It is useful to have some way of determining whether two bindings are 555 to the same resource. Two resources might have identical contents 556 and properties, but not be the same resource (e.g. an update to one 557 resource does not affect the other resource). 559 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 560 resource identifier, which MUST be unique across all resources for 561 all time. If the values of DAV:resource-id returned by PROPFIND 562 requests through two bindings are identical character by character, 563 the client can be assured that the two bindings are to the same 564 resource. 566 The DAV:resource-id property is created, and its value assigned, when 567 the resource is created. The value of DAV:resource-id MUST NOT be 568 changed. Even after the resource is no longer accessible through any 569 URI, that value MUST NOT be reassigned to another resource's 570 DAV:resource-id property. 572 Any method that creates a new resource MUST assign a new, unique 573 value to its DAV:resource-id property. For example, a PUT or a COPY 574 that creates a new resource must assign a new, unique value to the 575 DAV:resource-id property of that new resource. 577 On the other hand, any method that affects an existing resource MUST 578 NOT change the value of its DAV:resource-id property. For example, a 579 PUT or a COPY that updates an existing resource must not change the 580 value of its DAV:resource-id property. A MOVE, since it does not 581 create a new resource, but only changes the location of an existing 582 resource, must not change the value of the DAV:resource-id property. 584 2.7 Discovering the Bindings to a Resource 586 An OPTIONAL DAV:parent-set property on a resource provides a list of 587 the bindings that associate a collection and a URI segment with that 588 resource. If the DAV:parent-set property exists on a given resource, 589 it MUST contain a complete list of all bindings to that resource that 590 the client is authorized to see. When deciding whether to support 591 the DAV:parent-set property, server implementers / administrators 592 should balance the benefits it provides against the cost of 593 maintaining the property and the security risks enumerated in 594 Sections 8.4 and 8.5. 596 3. Properties 598 The bind feature introduces the following properties for a resource. 600 A DAV:allprop PROPFIND request SHOULD NOT return any of the 601 properties defined by this document. This allows a binding server to 602 perform efficiently when a naive client, which does not understand 603 the cost of asking a server to compute all possible live properties, 604 issues a DAV:allprop PROPFIND request. 606 3.1 DAV:resource-id Property 608 The DAV:resource-id property is a REQUIRED property that enables 609 clients to determine whether two bindings are to the same resource. 610 The value of DAV:resource-id is a URI, and may use any registered URI 611 scheme that guarantees the uniqueness of the value across all 612 resources for all time (e.g. the opaquelocktoken: scheme defined in 613 [RFC2518]). 615 617 3.2 DAV:parent-set Property 619 The DAV:parent-set property is an OPTIONAL property that enables 620 clients to discover what collections contain a binding to this 621 resource (i.e. what collections have that resource as an internal 622 member). It contains an of href/segment pair for each collection 623 that has a binding to the resource. The href identifies the 624 collection, and the segment identifies the binding name of that 625 resource in that collection. 627 A given collection MUST appear only once in the DAV:parent-set for 628 any given binding, even if there are multiple URI mappings to that 629 collection. For example, if collection C1 is mapped to both /CollX 630 and /CollY, and C1 contains a binding named "x.gif" to a resource R1, 631 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the 632 DAV:parent-set of R1, but not both. But if C1 also had a binding 633 named "y.gif" to R1, then there would be two entries for C1 in the 634 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX, 635 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). 637 638 639 640 643 4. BIND Method 645 The BIND method modifies the collection identified by the 646 Request-URI, by adding a new binding from the segment specified in 647 the BIND body to the resource identified in the BIND body. 649 If a server cannot guarantee the integrity of the binding, the BIND 650 request MUST fail. Note that it is especially difficult to maintain 651 the integrity of cross-server bindings. Unless the server where the 652 resource resides knows about all bindings on all servers to that 653 resource, it may unwittingly destroy the resource or make it 654 inaccessible without notifying another server that manages a binding 655 to the resource. For example, if server A permits creation of a 656 binding to a resource on server B, server A must notify server B 657 about its binding and must have an agreement with B that B will not 658 destroy the resource while A's binding exists. Otherwise server B 659 may receive a DELETE request that it thinks removes the last binding 660 to the resource and destroy the resource while A's binding still 661 exists. The precondition DAV:cross-server-binding is defined below 662 for cases where servers fail cross-server BIND requests because they 663 cannot guarantee the integrity of cross-server bindings. 665 By default, if there already is a binding for the specified segment 666 in the collection, the new binding replaces the existing binding. 667 This default binding replacement behavior can be overridden using the 668 Overwrite header defined in Section 9.6 of [RFC2518]. 670 This method is unsafe and idempotent (see [RFC2616], section 9.1). 672 Marshalling: 674 The request MAY include an Overwrite header. 676 The request body MUST be a DAV:bind XML element. 678 680 If the request succeeds, the server MUST return 201 (Created) when 681 a new binding was created and 200 (OK) when an existing binding 682 was replaced. 684 If a response body for a successful request is included, it MUST 685 be a DAV:bind-response XML element. Note that this document does 686 not define any elements for the BIND response body, but the 687 DAV:bind-response element is defined to ensure interoperability 688 between future extensions that do define elements for the BIND 689 response body. 691 693 Preconditions: 695 (DAV:bind-into-collection): The Request-URI MUST identify a 696 collection. 698 (DAV:bind-source-exists): The DAV:href element MUST identify a 699 resource. 701 (DAV:binding-allowed): The resource identified by the DAV:href 702 supports multiple bindings to it. 704 (DAV:cross-server-binding): If the resource identified by the 705 DAV:href element in the request body is on another server from the 706 collection identified by the Request-URI, the server MUST support 707 cross-server bindings. 709 (DAV:name-allowed): The name specified by the DAV:segment is 710 available for use as a new binding name. 712 (DAV:can-overwrite): If the collection already contains a binding 713 with the specified path segment, and if an Overwrite header is 714 included, the value of the Overwrite header MUST be "T". 716 (DAV:cycle-allowed): If the DAV:href element identifies a 717 collection, and if the Request-URI identifies a collection that is 718 a member of that collection, the server MUST support cycles in the 719 URI namespace. 721 (DAV:locked-update-allowed): If the collection identified by the 722 Request-URI is write-locked, then the appropriate token MUST be 723 specified in an If request header. 725 (DAV:locked-overwrite-allowed): If the collection already contains 726 a binding with the specified path segment, and if that binding is 727 protected by a write-lock, then the appropriate token MUST be 728 specified in an If request header. 730 Postconditions: 732 (DAV:new-binding): The collection MUST have a binding that maps 733 the segment specified in the DAV:segment element in the request 734 body, to the resource identified by the DAV:href element in the 735 request body. 737 4.1 Example: BIND 739 >> Request: 741 BIND /CollY HTTP/1.1 742 Host: www.example.com 743 Content-Type: text/xml; charset="utf-8" 744 Content-Length: xxx 746 747 748 bar.html 749 http://www.example.com/CollX/foo.html 750 752 >> Response: 754 HTTP/1.1 201 Created 756 The server added a new binding to the collection, 757 "http://www.example.com/CollY", associating "bar.html" with the 758 resource identified by the URI 759 "http://www.example.com/CollX/foo.html". Clients can now use the URI 760 "http://www.example.com/CollY/bar.html", to submit requests to that 761 resource. 763 5. UNBIND Method 765 The UNBIND method modifies the collection identified by the 766 Request-URI, by removing the binding identified by the segment 767 specified in the UNBIND body. 769 Once a resource is unreachable by any URI mapping, the server MAY 770 reclaim system resources associated with that resource. If UNBIND 771 removes a binding to a resource, but there remain URI mappings to 772 that resource, the server MUST NOT reclaim system resources 773 associated with the resource. 775 This method is unsafe and idempotent (see [RFC2616], section 9.1). 777 Marshalling: 779 The request body MUST be a DAV:unbind XML element. 781 783 If the request succeeds, the server MUST return 200 (OK) when the 784 binding was successfully deleted. 786 If a response body for a successful request is included, it MUST 787 be a DAV:unbind-response XML element. Note that this document 788 does not define any elements for the UNBIND response body, but the 789 DAV:unbind-response element is defined to ensure interoperability 790 between future extensions that do define elements for the UNBIND 791 response body. 793 795 Preconditions: 797 (DAV:unbind-from-collection): The Request-URI MUST identify a 798 collection. 800 (DAV:unbind-source-exists): The DAV:segment element MUST identify 801 a binding in the collection identified by the Request-URI. 803 (DAV:locked-update-allowed): If the collection identified by the 804 Request-URI is write-locked, then the appropriate token MUST be 805 specified in the request. 807 (DAV:protected-url-deletion-allowed): If the binding identified by 808 the segment is protected by a write-lock, then the appropriate 809 token MUST be specified in the request. 811 Postconditions: 813 (DAV:binding-deleted): The collection MUST NOT have a binding for 814 the segment specified in the DAV:segment element in the request 815 body. 817 (DAV:lock-deleted): If the internal member URI of the binding 818 specified by the Request-URI and the DAV:segment element in the 819 request body was protected by a write-lock at the time of the 820 request, that write-lock must have been deleted by the request. 822 5.1 Example: UNBIND 824 >> Request: 826 UNBIND /CollX HTTP/1.1 827 Host: www.example.com 828 Content-Type: text/xml; charset="utf-8" 829 Content-Length: xxx 831 832 833 foo.html 834 836 >> Response: 838 HTTP/1.1 200 OK 840 The server removed the binding named "foo.html" from the collection, 841 "http://www.example.com/CollX". A request to the resource named 842 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 843 response. 845 6. REBIND Method 847 The REBIND method removes a binding to a resource from the collection 848 identified by the Request-URI, and adds a binding to that resource 849 into another collection. The request body specifies the binding to 850 be removed (segment) and the new binding to be created (href). It is 851 effectively an atomic form of a MOVE request. 853 This method is unsafe and idempotent (see [RFC2616], section 9.1). 855 Marshalling: 857 The request MAY include an Overwrite header. 859 The request body MUST be a DAV:rebind XML element. 861 863 If the request succeeds, the server MUST return 201 (Created) when 864 a new binding was created and 200 (OK) when an existing binding 865 was replaced. 867 If a response body for a successful request is included, it MUST 868 be a DAV:rebind-response XML element. Note that this document 869 does not define any elements for the REBIND response body, but the 870 DAV:rebind-response element is defined to ensure interoperability 871 between future extensions that do define elements for the REBIND 872 response body. 874 876 Preconditions: 878 (DAV:rebind-into-collection): The Request-URI MUST identify a 879 collection. 881 (DAV:rebind-source-exists): The DAV:href element MUST identify a 882 resource. 884 (DAV:cross-server-binding): If the resource identified by the 885 DAV:href element in the request body is on another server from the 886 collection identified by the Request-URI, the server MUST support 887 cross-server bindings. 889 (DAV:name-allowed): The name specified by the DAV:segment is 890 available for use as a new binding name. 892 (DAV:can-overwrite): If the collection already contains a binding 893 with the specified path segment, and if an Overwrite header is 894 included, the value of the Overwrite header MUST be "T". 896 (DAV:cycle-allowed): If the DAV:href element identifies a 897 collection, and if the Request-URI identifies a collection that is 898 a member of that collection, the server MUST support cycles in the 899 URI namespace. 901 (DAV:locked-update-allowed): If the collection identified by the 902 Request-URI is write-locked, then the appropriate token MUST be 903 specified in the request. 905 (DAV:protected-url-modification-allowed): If the collection 906 identified by the Request-URI already contains a binding with the 907 specified path segment, and if that binding is protected by a 908 write-lock, then the appropriate token MUST be specified in the 909 request. 911 (DAV:locked-source-collection-update-allowed): If the collection 912 identified by the parent collection prefix of the DAV:href URI is 913 write-locked, then the appropriate token MUST be specified in the 914 request. 916 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 917 is protected by a write lock, then the appropriate token MUST be 918 specified in the request. 920 Postconditions: 922 (DAV:new-binding): The collection MUST have a binding that maps 923 the segment specified in the DAV:segment element in the request 924 body, to the resource that was identified by the DAV:href element 925 in the request body. 927 (DAV:binding-deleted): The URL specified in the DAV:href element 928 in the request body MUST NOT be mapped to a resource. 930 (DAV:lock-deleted): If the URL specified in the DAV:href element 931 in the request body was protected by a write-lock at the time of 932 the request, that write-lock must have been deleted by the 933 request. 935 6.1 Example: REBIND 937 >> Request: 939 REBIND /CollX HTTP/1.1 940 Host: www.example.com 941 Content-Type: text/xml; charset="utf-8" 942 Content-Length: xxx 944 945 946 foo.html 947 http://www.example.com/CollY/bar.html 948 950 >> Response: 952 HTTP/1.1 200 OK 954 The server added a new binding to the collection, 955 "http://www.example.com/CollX", associating "foo.html" with the 956 resource identified by the URI 957 "http://www.example.com/CollY/bar.html", and removes the binding 958 named "bar.html" from the collection identified by the URI 959 "http://www.example.com/CollY". Clients can now use the URI 960 "http://www.example.com/CollX/foo.html" to submit requests to that 961 resource, and requests on the URI 962 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 963 Found) response. 965 7. Additional Status Codes 967 7.1 208 Already Reported 969 The 208 (Already Reported) status code can be used inside a 970 DAV:propstat response element to avoid enumerating the internal 971 members of multiple bindings to the same collection repeatedly. For 972 each binding to a collection inside the request's scope, only one 973 will be reported with a 200 status, while subsequent DAV:response 974 elements for all other bindings will use the 208 status, and no 975 DAV:response elements for their descendants are included. 977 Note that the 208 status will only occur for "Depth: infinity" 978 requests, and that it is of particular importance when the multiple 979 collection bindings cause a bind loop as discussed in Section 2.2. 981 A client can request the DAV:resourceid property in a PROPFIND 982 request to guarantee that they can accurately reconstruct the binding 983 structure of a collection with multiple bindings to a single 984 resource. 986 For backward compatibility with clients not aware of the 208 status 987 code appearing in multistatus response bodies, it SHOULD NOT be used 988 unless the client has signalled support for this specification using 989 the "DAV" request header (see Section 8.2). Instead, a 506 status 990 should be returned when a binding loop is discovered. This allows 991 the server to return the 506 as the top level return status, if it 992 discovers it before it started the response, or in the middle of a 993 multistatus, if it discovers it in the middle of streaming out a 994 multistatus response. 996 7.1.1 Example: PROPFIND by bind-aware client 998 For example, consider a PROPFIND request on /Coll (bound to 999 collection C), where the members of /Coll are /Coll/Foo (bound to 1000 resource R) and /Coll/Bar (bound to collection C). 1002 >> Request: 1004 PROPFIND /Coll/ HTTP/1.1 1005 Host: www.example.com 1006 Depth: infinity 1007 DAV: bind 1008 Content-Type: text/xml; charset="utf-8" 1009 Content-Length: xxx 1011 1012 1013 1014 1015 1016 1017 1019 >> Response: 1021 HTTP/1.1 207 Multi-Status 1022 Content-Type: text/xml; charset="utf-8" 1023 Content-Length: xxx 1025 1026 1027 1028 http://www.example.com/Coll/ 1029 1030 1031 Loop Demo 1032 1033 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1035 1036 1037 HTTP/1.1 200 OK 1038 1039 1040 1041 http://www.example.com/Coll/Foo 1042 1043 1044 Bird Inventory 1045 1046 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1048 1049 1050 HTTP/1.1 200 OK 1051 1052 1053 1054 http://www.example.com/Coll/Bar 1055 1056 1057 Loop Demo 1058 1059 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1061 1062 1063 HTTP/1.1 208 Already Reported 1064 1065 1066 1068 7.1.2 Example: PROPFIND by non-bind-aware client 1070 In this example, the client isn't aware of the 208 status code 1071 introduced by this specification. As the "Depth: infinity" PROPFIND 1072 request would cause a loop condition, the whole request is rejected 1073 with a 506 status. 1075 >> Request: 1077 PROPFIND /Coll/ HTTP/1.1 1078 Host: www.example.com 1079 Depth: infinity 1080 Content-Type: text/xml; charset="utf-8" 1081 Content-Length: xxx 1083 1084 1085 1086 1088 >> Response: 1090 HTTP/1.1 506 Loop Detected 1092 7.2 506 Loop Detected 1094 The 506 (Loop Detected) status code indicates that the server 1095 terminated an operation because it encountered an infinite loop while 1096 processing a request with "Depth: infinity". This status indicates 1097 that the entire operation failed. 1099 8. Capability discovery 1101 8.1 OPTIONS method 1103 If the server supports bindings, it MUST return the compliance class 1104 name "bind" as a field in the "DAV" response header (see [RFC2518], 1105 section 9.1) from an OPTIONS request on any resource implemented by 1106 that server. A value of "bind" in the "DAV" header MUST indicate 1107 that the server supports all MUST level requirements and REQUIRED 1108 features specified in this document. 1110 8.2 'DAV' request header 1112 8.2.1 Generic syntax 1114 This specification introduces the 'DAV' request header that allows 1115 clients to signal compliance to specific WebDAV features. It has the 1116 same syntax as the response header defined in [RFC2518], section 9.1, 1117 but MAY be used with any method. 1119 Note that clients MUST NOT submit a specific compliance class name in 1120 the request header unless the specification defining this compliance 1121 class specifically defines its semantics for clients. 1123 Note that if a server chooses to vary the result of a request based 1124 on values in the "DAV" header, the response either MUST NOT be 1125 cacheable or the server MUST mark the response accordingly using the 1126 "Vary" header (see [RFC2616], section 14.44). 1128 8.2.2 Client compliance class 'bind' 1130 Clients SHOULD signal support for all MUST level requirements and 1131 REQUIRED features by submitting a "DAV" request header containing the 1132 compliance class name "bind". In particular, the client MUST 1133 understand the 208 status code defined in Section 7.1. 1135 9. Security Considerations 1137 This section is provided to make WebDAV implementors aware of the 1138 security implications of this protocol. 1140 All of the security considerations of HTTP/1.1 and the WebDAV 1141 Distributed Authoring Protocol specification also apply to this 1142 protocol specification. In addition, bindings introduce several new 1143 security concerns and increase the risk of some existing threats. 1145 These issues are detailed below. 1147 9.1 Privacy Concerns 1149 In a context where cross-server bindings are supported, creating 1150 bindings on a trusted server may make it possible for a hostile agent 1151 to induce users to send private information to a target on a 1152 different server. 1154 9.2 Bind Loops 1156 Although bind loops were already possible in HTTP 1.1, the 1157 introduction of the BIND method creates a new avenue for clients to 1158 create loops accidentally or maliciously. If the binding and its 1159 target are on the same server, the server may be able to detect BIND 1160 requests that would create loops. Servers are required to detect 1161 loops that are caused by bindings to collections during the 1162 processing of any requests with "Depth: infinity". 1164 9.3 Bindings, and Denial of Service 1166 Denial of service attacks were already possible by posting URIs that 1167 were intended for limited use at heavily used Web sites. The 1168 introduction of BIND creates a new avenue for similar denial of 1169 service attacks. If cross-server bindings are supported, clients can 1170 now create bindings at heavily used sites to target locations that 1171 were not designed for heavy usage. 1173 9.4 Private Locations May Be Revealed 1175 If the DAV:parent-set property is maintained on a resource, the 1176 owners of the bindings risk revealing private locations. The 1177 directory structures where bindings are located are available to 1178 anyone who has access to the DAV:parent-set property on the resource. 1179 Moving a binding may reveal its new location to anyone with access to 1180 DAV:parent-set on its resource. 1182 9.5 DAV:parent-set and Denial of Service 1184 If the server maintains the DAV:parent-set property in response to 1185 bindings created in other administrative domains, it is exposed to 1186 hostile attempts to make it devote resources to adding bindings to 1187 the list. 1189 10. Internationalization Considerations 1191 All internationalization considerations mentioned in [RFC2518] also 1192 apply to this document. 1194 11. IANA Considerations 1196 All IANA considerations mentioned in [RFC2518] also apply to this 1197 document. 1199 12. Acknowledgements 1201 This document is the collaborative product of the authors and Tyson 1202 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1203 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1204 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1205 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa 1206 Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe 1207 Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris 1208 Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel 1209 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1210 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1211 John Stracke, John Tigue, John Turner, Kevin Wiggen, and other 1212 members of the WebDAV working group. 1214 13 Normative References 1216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1217 Requirement Levels", BCP 14, RFC 2119, March 1997. 1219 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1220 Jensen, "HTTP Extensions for Distributed Authoring -- 1221 WEBDAV", RFC 2518, February 1999. 1223 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1224 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1225 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1227 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 1228 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1229 Edition)", W3C REC-xml-20040204, February 2004, 1230 . 1232 [draft-fielding-rfc2396bis] 1233 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1234 Resource Identifier (URI): Generic Syntax", ID 1235 draft-fielding-rfc2396bis-07, September 2004. 1237 Authors' Addresses 1239 Geoffrey Clemm 1240 IBM 1241 20 Maguire Road 1242 Lexington, MA 02421 1244 EMail: geoffrey.clemm@us.ibm.com 1246 Jason Crawford 1247 IBM Research 1248 P.O. Box 704 1249 Yorktown Heights, NY 10598 1251 EMail: ccjason@us.ibm.com 1253 Julian F. Reschke 1254 greenbytes GmbH 1255 Salzmannstrasse 152 1256 Muenster, NW 48159 1257 Germany 1259 EMail: julian.reschke@greenbytes.de 1261 Jim Whitehead 1262 UC Santa Cruz, Dept. of Computer Science 1263 1156 High Street 1264 Santa Cruz, CA 95064 1266 EMail: ejw@cse.ucsc.edu 1268 Appendix A. Change Log (to be removed by RFC Editor before publication) 1270 A.1 Since draft-ietf-webdav-bind-02 1272 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1273 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1274 resolution, but keep it open. Add issues "ED_references" and 1275 "4_507_status". Started work on index. Rename document to "Binding 1276 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1277 Rename "References" to "Normative References". Close issue 1278 "ED_references". Close issue "4_507_status". 1280 A.2 Since draft-ietf-webdav-bind-03 1282 Add and close issues "9.2_redirect_loops", "ED_authors" and 1283 "ED_updates". Add section about capability discovery (DAV header). 1284 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1285 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1286 "locking" and resolve as invalid. 1288 A.3 Since draft-ietf-webdav-bind-04 1290 Add and close issues "6_precondition_binding_allowed" and 1291 "6_lock_behaviour". Add mailing list and issues list pointers to 1292 front. 1294 A.4 Since draft-ietf-webdav-bind-05 1296 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1297 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1298 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1300 A.5 Since draft-ietf-webdav-bind-06 1302 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1303 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1305 A.6 Since draft-ietf-webdav-bind-07 1307 Add more index items (no change tracking). Add and resolve issues 1308 "2.3_copy_to_same", "bind_properties", "bind_vs_ACL", 1309 "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML 1310 DTD fragment in section 3.3. Make spelling of "Request-URI" 1311 consistent. 1313 Appendix B. Resolved issues (to be removed by RFC Editor before 1314 publication) 1316 Issues that were either rejected or resolved in this version of this 1317 document. 1319 B.1 rfc2396bis 1321 Type: edit 1323 julian.reschke@greenbytes.de (2004-10-21): Update references to 1324 RFC2396 with draft-fielding-uri-rfc2396bis-07. 1326 Resolution (2004-11-06): Done. 1328 B.2 bind_vs_ACL 1330 Type: change 1332 1335 lisa@osafoundation.org (2004-03-24): What permissions are required in 1336 order to perform a BIND request? I would think that permissions for 1337 UNBIND and REBIND are identical to permissions for DELETE and MOVE 1338 respectively, but this should be stated. 1340 Resolution (2004-10-16): BIND and UNBIND are controlled by the 1341 privileges DAV:bind and DAV:unbind. REBIND is an atomic form of 1342 MOVE, those the same privileges apply. The authors feel that this 1343 does not need to be explicitly stated (see 1344 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0150.htm 1345 l). 1347 B.3 bind_properties 1349 Type: change 1351 1354 lisa@osafoundation.org (2004-03-24): (Issues with BIND semantics vs 1355 servers that compute properties based on request-URI, see 1356 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.htm 1357 l and 1358 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0154.htm 1359 l). 1361 Resolution (2004-10-16): The authors feel that in the WebDAV data 1362 model, properties are part of the state of the resource, thus should 1363 not vary on request URI. A server that implements properties as 1364 state of a binding instead of the resource to which it binds would be 1365 inherently incompatible with both WebDAV and BIND semantics. It's 1366 unclear why this would matter - a server that can't implement BIND 1368 semantics simply can't support this specification (likely for more 1369 reasons than this one). See also summary at 1370 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0022.htm 1371 l. 1373 B.4 2.3_copy_to_same 1375 Type: change 1376 1379 lisa@osafoundation.org (2004-03-24): When a user does a COPY or MOVE 1380 from one binding to another binding to the same resource, this should 1381 be flagged as an error. Since this has to interoperate with existing 1382 clients that won't look at the error body, the status code would have 1383 to stand alone. 409 is already used for non-existent parent 1384 collections, so that can't be reused. Possibly 403 which in 2518 for 1385 COPY means "_ The source and destination URIs are the same." 1387 Resolution (2004-10-16): Copying/moving to a binding identifying the 1388 same resource is harmless (see explanation in 1389 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0143.htm 1390 l) and does not need to be rejected by the server. 1392 B.5 6_rebind_intro 1394 Type: edit 1396 1399 ejw@cs.ucsc.edu (2004-11-12): I'm reading through the BIND 1400 specification, and the description of the REBIND method's operands is 1401 a bit unclear to me. I'm assuming the intent is similar to BIND and 1402 UNBIND, each of which clearly state in the first sentence what role 1403 the Request-URI, segment, and href fields play. In my reading I just 1404 jumped right into the spec. at this method (typical reference 1405 reading pattern), and hence I didn't initially see the similarity 1406 with the BIND and UNBIND method operands. 1408 Resolution (2004-11-12): Agreed and fixed. 1410 Appendix C. Open issues (to be removed by RFC Editor prior to 1411 publication) 1413 C.1 edit 1415 Type: edit 1417 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1418 editorial fixes/enhancements. 1420 Index 1422 2 1423 208 Already Reported (status code) 23 1425 5 1426 506 Loop Detected (status code) 25 1428 B 1429 BIND method 16 1430 Binding 7 1432 C 1433 Collection 7 1434 Condition Names 1435 DAV:bind-into-collection (pre) 17 1436 DAV:bind-source-exists (pre) 17 1437 DAV:binding-allowed (pre) 17 1438 DAV:binding-deleted (post) 19, 22 1439 DAV:can-overwrite (pre) 17, 21 1440 DAV:cross-server-binding (pre) 17, 21 1441 DAV:cycle-allowed (pre) 17, 21 1442 DAV:lock-deleted (post) 19, 22 1443 DAV:locked-overwrite-allowed (pre) 17 1444 DAV:locked-source-collection-update-allowed (pre) 21 1445 DAV:locked-update-allowed (pre) 17, 19, 21 1446 DAV:name-allowed (pre) 17, 21 1447 DAV:new-binding (post) 18, 22 1448 DAV:protected-source-url-deletion-allowed (pre) 21 1449 DAV:protected-url-deletion-allowed (pre) 19 1450 DAV:protected-url-modification-allowed (pre) 21 1451 DAV:rebind-into-collection (pre) 21 1452 DAV:rebind-source-exists (pre) 21 1453 DAV:unbind-from-collection (pre) 19 1454 DAV:unbind-source-exists (pre) 19 1456 D 1457 DAV header 1458 compliance class 'bind' 26 1459 DAV:bind-into-collection precondition 17 1460 DAV:bind-source-exists precondition 17 1461 DAV:binding-allowed precondition 17 1462 DAV:binding-deleted postcondition 19, 22 1463 DAV:can-overwrite precondition 17, 21 1464 DAV:cross-server-binding precondition 17, 21 1465 DAV:cycle-allowed precondition 17, 21 1466 DAV:lock-deleted postcondition 19, 22 1467 DAV:locked-overwrite-allowed precondition 17 1468 DAV:locked-source-collection-update-allowed precondition 21 1469 DAV:locked-update-allowed precondition 17, 19, 21 1470 DAV:name-allowed precondition 17, 21 1471 DAV:new-binding postcondition 18, 22 1472 DAV:parent-set property 15 1473 DAV:protected-source-url-deletion-allowed precondition 21 1474 DAV:protected-url-deletion-allowed precondition 19 1475 DAV:protected-url-modification-allowed precondition 21 1476 DAV:rebind-into-collection precondition 21 1477 DAV:rebind-source-exists precondition 21 1478 DAV:resource-id property 15 1479 DAV:unbind-from-collection precondition 19 1480 DAV:unbind-source-exists precondition 19 1482 I 1483 Internal Member URI 7 1485 M 1486 Methods 1487 BIND 16 1488 REBIND 20 1489 UNBIND 18 1491 P 1492 Path Segment 7 1493 Properties 1494 DAV:parent-set 15 1495 DAV:resource-id 15 1497 R 1498 REBIND method 20 1500 S 1501 Status Codes 1502 208 Already Reported 23 1503 506 Loop Detected 25 1505 U 1506 UNBIND method 18 1507 URI Mapping 6 1509 Intellectual Property Statement 1511 The IETF takes no position regarding the validity or scope of any 1512 Intellectual Property Rights or other rights that might be claimed to 1513 pertain to the implementation or use of the technology described in 1514 this document or the extent to which any license under such rights 1515 might or might not be available; nor does it represent that it has 1516 made any independent effort to identify any such rights. Information 1517 on the procedures with respect to rights in RFC documents can be 1518 found in BCP 78 and BCP 79. 1520 Copies of IPR disclosures made to the IETF Secretariat and any 1521 assurances of licenses to be made available, or the result of an 1522 attempt made to obtain a general license or permission for the use of 1523 such proprietary rights by implementers or users of this 1524 specification can be obtained from the IETF on-line IPR repository at 1525 http://www.ietf.org/ipr. 1527 The IETF invites any interested party to bring to its attention any 1528 copyrights, patents or patent applications, or other proprietary 1529 rights that may cover technology that may be required to implement 1530 this standard. Please address the information to the IETF at 1531 ietf-ipr@ietf.org. 1533 Disclaimer of Validity 1535 This document and the information contained herein are provided on an 1536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1538 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1539 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1540 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1543 Copyright Statement 1545 Copyright (C) The Internet Society (2004). This document is subject 1546 to the rights, licenses and restrictions contained in BCP 78, and 1547 except as set forth therein, the authors retain all their rights. 1549 Acknowledgment 1551 Funding for the RFC Editor function is currently provided by the 1552 Internet Society.