idnits 2.17.1 draft-ietf-webdav-bind-07.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 1462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1452. ** 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 (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 (September 28, 2004) is 7144 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 2396 (Obsoleted by RFC 3986) ** 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: 8 errors (**), 0 flaws (~~), 2 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: March 29, 2005 IBM Research 5 J. Reschke 6 greenbytes 7 J. Whitehead 8 U.C. Santa Cruz 9 September 28, 2004 11 Binding Extensions to Web Distributed Authoring and Versioning 12 (WebDAV) 13 draft-ietf-webdav-bind-07 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 March 29, 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 B. Resolved issues (to be removed by RFC Editor before 118 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30 119 B.1 ED_rfc2026_ref . . . . . . . . . . . . . . . . . . . . . . 30 120 B.2 specify_safeness_and_idempotence . . . . . . . . . . . . . 30 121 B.3 2.6_identical . . . . . . . . . . . . . . . . . . . . . . 31 122 C. Open issues (to be removed by RFC Editor prior to 123 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 125 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 Intellectual Property and Copyright Statements . . . . . . . . 34 128 1. Introduction 130 This specification extends the WebDAV Distributed Authoring Protocol 131 to enable clients to create new access paths to existing resources. 132 This capability is useful for several reasons: 134 URIs of WebDAV-compliant resources are hierarchical and correspond to 135 a hierarchy of collections in resource space. The WebDAV Distributed 136 Authoring Protocol makes it possible to organize these resources into 137 hierarchies, placing them into groupings, known as collections, which 138 are more easily browsed and manipulated than a single flat 139 collection. However, hierarchies require categorization decisions 140 that locate resources at a single location in the hierarchy, a 141 drawback when a resource has multiple valid categories. For example, 142 in a hierarchy of vehicle descriptions containing collections for 143 cars and boats, a description of a combination car/boat vehicle could 144 belong in either collection. Ideally, the description should be 145 accessible from both. Allowing clients to create new URIs that 146 access the existing resource lets them put that resource into 147 multiple collections. 149 Hierarchies also make resource sharing more difficult, since 150 resources that have utility across many collections are still forced 151 into a single collection. For example, the mathematics department at 152 one university might create a collection of information on fractals 153 that contains bindings to some local resources, but also provides 154 access to some resources at other universities. For many reasons, it 155 may be undesirable to make physical copies of the shared resources on 156 the local server: to conserve disk space, to respect copyright 157 constraints, or to make any changes in the shared resources visible 158 automatically. Being able to create new access paths to existing 159 resources in other collections or even on other servers is useful for 160 this sort of case. 162 The BIND method defined here provides a mechanism for allowing 163 clients to create alternative access paths to existing WebDAV 164 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to 165 work because there are mappings between URIs and resources. A method 166 is addressed to a URI, and the server follows the mapping from that 167 URI to a resource, applying the method to that resource. Multiple 168 URIs may be mapped to the same resource, but until now there has been 169 no way for clients to create additional URIs mapped to existing 170 resources. 172 BIND lets clients associate a new URI with an existing WebDAV 173 resource, and this URI can then be used to submit requests to the 174 resource. Since URIs of WebDAV resources are hierarchical, and 175 correspond to a hierarchy of collections in resource space, the BIND 176 method also has the effect of adding the resource to a collection. 177 As new URIs are associated with the resource, it appears in 178 additional collections. 180 A BIND request does not create a new resource, but simply makes 181 available a new URI for submitting requests to an existing resource. 182 The new URI is indistinguishable from any other URI when submitting a 183 request to a resource. Only one round trip is needed to submit a 184 request to the intended target. Servers are required to enforce the 185 integrity of the relationships between the new URIs and the resources 186 associated with them. Consequently, it may be very costly for 187 servers to support BIND requests that cross server boundaries. 189 This specification is organized as follows. Section 1.1 defines 190 terminology used in the rest of the specification, while Section 2 191 overviews bindings. Section 3 defines the new properties needed to 192 support multiple bindings to the same resource. Section 4 specifies 193 the BIND method, used to create multiple bindings to the same 194 resource. Section 5 specifies the UNBIND method, used to remove a 195 binding to a resource. Section 6 specifies the REBIND method, used 196 to move a binding to another collection. 198 1.1 Terminology 200 The terminology used here follows and extends that in the WebDAV 201 Distributed Authoring Protocol specification [RFC2518]. 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 This document uses XML DTD fragments ([XML]) as a purely notational 208 convention. WebDAV request and response bodies cannot be validated 209 due to the specific extensibility rules defined in section 23 of 210 [RFC2518] and due to the fact that all XML elements defined by this 211 specification use the XML namespace name "DAV:". In particular: 213 o Element names use the "DAV:" namespace. 215 o Element ordering is irrelevant. 217 o Extension elements/attributes (elements/attributes not already 218 defined as valid child elements) may be added anywhere, except 219 when explicitly stated otherwise. 221 URI Mapping 223 A relation between an absolute URI and a resource. For an 224 absolute URI U and the resource it identifies R, the URI mapping 225 can be thought of as (U => R). Since a resource can represent 226 items that are not network retrievable, as well as those that are, 227 it is possible for a resource to have zero, one, or many URI 228 mappings. Mapping a resource to an "http" scheme URI makes it 229 possible to submit HTTP protocol requests to the resource using 230 the URI. 232 Path Segment 234 Informally, the characters found between slashes ("/") in a URI. 235 Formally, as defined in section 3.3 of [RFC2396]. 237 Binding 239 A relation between a single path segment (in a collection) and a 240 resource. A binding is part of the state of a collection. If two 241 different collections contain a binding between the same path 242 segment and the same resource, these are two distinct bindings. 243 So for a collection C, a path segment S, and a resource R, the 244 binding can be thought of as C:(S -> R). Bindings create URI 245 mappings, and hence allow requests to be sent to a single resource 246 from multiple locations in a URI namespace. For example, given a 247 collection C (accessible through the URI 248 http://www.example.com/CollX), a path segment S (equal to 249 "foo.html"), and a resource R, then creating the binding C: (S -> 250 R) makes it possible to use the URI 251 http://www.example.com/CollX/foo.html to access R. 253 Collection 255 A resource that contains, as part of its state, a set of bindings 256 that identify internal member resources. 258 Internal Member URI 260 The URI that identifies an internal member of a collection, and 261 that consists of the URI for the collection, followed by a slash 262 character ('/'), followed by the path segment of the binding for 263 that internal member. 265 1.2 Rationale for Distinguishing Bindings from URI Mappings 267 In [RFC2518], the state of a collection is defined as containing a 268 list of internal member URIs. If there are multiple mappings to a 269 collection, then the state of the collection is different when you 270 refer to it via a different URI. This is undesirable, since ideally 271 a collection's membership should remain the same, independent of 272 which URI was used to reference it. 274 The notion of binding is introduced to separate the final segment of 275 a URI from its parent collection's contribution. This done, a 276 collection can be defined as containing a set of bindings, thus 277 permitting new mappings to a collection without modifying its 278 membership. The authors of this specification anticipate and 279 recommend that future revisions of [RFC2518] will update the 280 definition of the state of a collection to correspond to the 281 definition in this document. 283 1.3 Method Preconditions and Postconditions 285 A "precondition" of a method describes the state on the server that 286 must be true for that method to be performed. A "postcondition" of a 287 method describes the state on the server that must be true after that 288 method has completed. If a method precondition or postcondition for 289 a request is not satisfied, the response status of the request MUST 290 be either 403 (Forbidden) if the request should not be repeated 291 because it will always fail, or 409 (Conflict) if it is expected that 292 the user might be able to resolve the conflict and resubmit the 293 request. 295 In order to allow better client handling of 403 and 409 responses, a 296 distinct XML element type is associated with each method precondition 297 and postcondition of a request. When a particular precondition is 298 not satisfied or a particular postcondition cannot be achieved, the 299 appropriate XML element MUST be returned as the child of a top-level 300 DAV:error element in the response body, unless otherwise negotiated 301 by the request. In a 207 Multi-Status response, the DAV:error 302 element would appear in the appropriate DAV:responsedescription 303 element. 305 2. Overview of Bindings 307 Bindings are part of the state of a collection. They define the 308 internal members of the collection, and the names of those internal 309 members. 311 Bindings are added and removed by a variety of existing HTTP methods. 312 A method that creates a new resource, such as PUT, COPY, and MKCOL, 313 adds a binding. A method that deletes a resource, such as DELETE, 314 removes a binding. A method that moves a resource (e.g. MOVE) both 315 adds a binding (in the destination collection) and removes a binding 316 (in the source collection). The BIND method introduced here provides 317 a mechanism for adding a second binding to an existing resource. 318 There is no difference between an initial binding added by PUT, COPY, 319 or MKCOL, and additional bindings added with BIND. 321 It would be very undesirable if one binding could be destroyed as a 322 side effect of operating on the resource through a different binding. 323 In particular, the removal of one binding to a resource (e.g. with a 324 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 325 e.g. by turning that binding into a dangling path segment. The 326 server MUST NOT reclaim system resources after removing one binding, 327 while other bindings to the resource remain. In other words, the 328 server MUST maintain the integrity of a binding. 330 2.1 Bindings to Collections 332 Bindings to collections can result in loops, which servers MUST 333 detect when processing "Depth: infinity" requests. It is sometimes 334 possible to complete an operation in spite of the presence of a loop. 335 However, the 506 (Loop Detected) status code is defined in Section 7 336 for use in contexts where an operation is terminated because a loop 337 was encountered. 339 Creating a new binding to a collection makes each resource associated 340 with a binding in that collection accessible via a new URI, and thus 341 creates new URI mappings to those resources but no new bindings. 343 For example, suppose a new binding CollY is created for collection C1 344 in the figure below. It immediately becomes possible to access 345 resource R1 using the URI /CollY/x.gif and to access resource R2 346 using the URI /CollY/y.jpg, but no new bindings for these child 347 resources were created. This is because bindings are part of the 348 state of a collection, and associate a URI that is relative to that 349 collection with its target resource. No change to the bindings in 350 Collection C1 is needed to make its children accessible using /CollY/ 351 x.gif and /CollY/y.jpg. 353 +-------------------------+ 354 | Root Collection | 355 | bindings: | 356 | CollX CollY | 357 +-------------------------+ 358 | / 359 | / 360 | / 361 +------------------+ 362 | Collection C1 | 363 | bindings: | 364 | x.gif y.jpg | 365 +------------------+ 366 | \ 367 | \ 368 | \ 369 +-------------+ +-------------+ 370 | Resource R1 | | Resource R2 | 371 +-------------+ +-------------+ 373 2.2 URI Mappings Created by a new Binding 375 Suppose a binding from "Binding-Name" to resource R is to be added to 376 a collection, C. Then if C-MAP is the set of URIs that were mapped 377 to C before the BIND request, then for each URI "C-URI" in C-MAP, the 378 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 379 request. 381 For example, if a binding from "foo.html" to R is added to a 382 collection C, and if the following URIs are mapped to C: 384 http://www.example.com/A/1/ 385 http://example.com/A/one/ 387 then the following new mappings to R are introduced: 389 http://www.example.com/A/1/foo.html 390 http://example.com/A/one/foo.html 392 Note that if R is a collection, additional URI mappings are created 393 to the descendents of R. Also, note that if a binding is made in 394 collection C to C itself (or to a parent of C), an infinite number of 395 mappings are introduced. 397 For example, if a binding from "myself" to C is then added to C, the 398 following infinite number of additional mappings to C are introduced: 400 http://www.example.com/A/1/myself 401 http://www.example.com/A/1/myself/myself 402 ... 404 and the following infinite number of additional mappings to R are 405 introduced: 407 http://www.example.com/A/1/myself/foo.html 408 http://www.example.com/A/1/myself/myself/foo.html 409 ... 411 2.3 COPY and Bindings 413 As defined in Section 8.8 of [RFC2518], COPY causes the resource 414 identified by the Request-URI to be duplicated, and makes the new 415 resource accessible using the URI specified in the Destination 416 header. Upon successful completion of a COPY, a new binding is 417 created between the last path segment of the Destination header, and 418 the destination resource. The new binding is added to its parent 419 collection, identified by the Destination header minus its final 420 segment. 422 The following figure shows an example: Suppose that a COPY is issued 423 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 424 with the Destination header set to URI-X. After successful 425 completion of the COPY operation, resource R is duplicated to create 426 resource R', and a new binding has been created which creates at 427 least the URI mapping between URI-X and the new resource (although 428 other URI mappings may also have been created). 430 URI-1 URI-2 URI-3 URI-X 431 | | | | 432 | | | <---- URI Mappings ----> | 433 | | | | 434 +---------------------+ +------------------------+ 435 | Resource R | | Resource R' | 436 +---------------------+ +------------------------+ 438 It might be thought that a COPY request with "Depth: 0" on a 439 collection would duplicate its bindings, since bindings are part of 440 the collection's state. This is not the case, however. The 441 definition of Depth in [RFC2518] makes it clear that a "Depth: 0" 442 request does not apply to a collection's members. Consequently, a 443 COPY with "Depth: 0" does not duplicate the bindings contained by the 444 collection. 446 If a COPY request causes an existing resource to be updated, the 447 bindings to that resource MUST be unaffected by the COPY request. 448 Using the preceding example, suppose that a COPY request is issued to 449 URI-X for resource R', with the Destination header set to URI-2. The 450 content and dead properties of resource R would be updated to be a 451 copy of those of resource R', but the mappings from URI-1, URI-2, and 452 URI-3 to resource R remain unaffected. If because of multiple 453 bindings to a resource, more than one source resource updates a 454 single destination resource, the order of the updates is server 455 defined. 457 If a COPY request would cause a new resource to be created as a copy 458 of an existing resource, and that COPY request has already created a 459 copy of that existing resource, the COPY request instead creates 460 another binding to the previous copy, instead of creating a new 461 resource. 463 2.4 DELETE and Bindings 465 When there are multiple bindings to a resource, a DELETE applied to 466 that resource MUST NOT remove any bindings to that resource other 467 than the one identified by the request URI. For example, suppose the 468 collection identified by the URI "/a" has a binding named "x" to a 469 resource R, and another collection identified by "/b" has a binding 470 named "y" to the same resource R. Then a DELETE applied to "/a/x" 471 removes the binding named "x" from "/a" but MUST NOT remove the 472 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 473 to identify the resource R). In particular, although Section 8.6.1 474 of [RFC2518] states that during DELETE processing, a server "MUST 475 remove any URI for the resource identified by the Request-URI from 476 collections which contain it as a member", a server that supports the 477 binding protocol MUST NOT follow this requirement. 479 When DELETE is applied to a collection, it MUST NOT modify the 480 membership of any other collection that is not itself a member of the 481 collection being deleted. For example, if both "/a/.../x" and "/b/ 482 .../y" identify the same collection, C, then applying DELETE to "/a" 483 MUST NOT delete an internal member from C or from any other 484 collection that is a member of C, because that would modify the 485 membership of "/b". 487 If a collection supports the UNBIND method (see Section 5), a DELETE 488 of an internal member of a collection MAY be implemented as an UNBIND 489 request. In this case, applying DELETE to a Request-URI has the 490 effect of removing the binding identified by the final segment of the 491 Request-URI from the collection identified by the Request-URI minus 492 its final segment. Although [RFC2518] allows a DELETE to be a 493 non-atomic operation, when the DELETE operation is implemented as an 494 UNBIND, the operation is atomic. In particular, a DELETE on a 495 hierarchy of resources is simply the removal of a binding to the 496 collection identified by the Request-URI. 498 2.5 MOVE and Bindings 500 When MOVE is applied to a resource, the other bindings to that 501 resource MUST be unaffected, and if the resource being moved is a 502 collection, the bindings to any members of that collection MUST be 503 unaffected. Also, if MOVE is used with Overwrite:T to delete an 504 existing resource, the constraints specified for DELETE apply. 506 If the destination collection of a MOVE request supports the REBIND 507 method (see Section 6), a MOVE of a resource into that collection MAY 508 be implemented as a REBIND request. Although [RFC2518] allows a MOVE 509 to be a non-atomic operation, when the MOVE operation is implemented 510 as a REBIND, the operation is atomic. In particular, applying a MOVE 511 to a Request-URI and a Destination URI has the effect of removing a 512 binding to a resource (at the Request-URI), and creating a new 513 binding to that resource (at the Destination URI). Even when the 514 Request-URI identifies a collection, the MOVE operation involves only 515 removing one binding to that collection and adding another. 517 As an example, suppose that a MOVE is issued to URI-3 for resource R 518 below (which is also mapped to URI-1 and URI-2), with the Destination 519 header set to URI-X. After successful completion of the MOVE 520 operation, a new binding has been created which creates the URI 521 mapping between URI-X and resource R. The binding corresponding to 522 the final segment of URI-3 has been removed, which also causes the 523 URI mapping between URI-3 and R to be removed. If resource R were a 524 collection, old URI-3 based mappings to members of R would have been 525 removed, and new URI-X based mappings to members of R would have been 526 created. 528 >> Before Request: 530 URI-1 URI-2 URI-3 531 | | | 532 | | | <---- URI Mappings 533 | | | 534 +---------------------+ 535 | Resource R | 536 +---------------------+ 537 >> After Request: 539 URI-1 URI-2 URI-X 540 | | | 541 | | | <---- URI Mappings 542 | | | 543 +---------------------+ 544 | Resource R | 545 +---------------------+ 547 2.6 Determining Whether Two Bindings Are to the Same Resource 549 It is useful to have some way of determining whether two bindings are 550 to the same resource. Two resources might have identical contents 551 and properties, but not be the same resource (e.g. an update to one 552 resource does not affect the other resource). 554 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 555 resource identifier, which MUST be unique across all resources for 556 all time. If the values of DAV:resource-id returned by PROPFIND 557 requests through two bindings are identical character by character, 558 the client can be assured that the two bindings are to the same 559 resource. 561 The DAV:resource-id property is created, and its value assigned, when 562 the resource is created. The value of DAV:resource-id MUST NOT be 563 changed. Even after the resource is no longer accessible through any 564 URI, that value MUST NOT be reassigned to another resource's 565 DAV:resource-id property. 567 Any method that creates a new resource MUST assign a new, unique 568 value to its DAV:resource-id property. For example, a PUT or a COPY 569 that creates a new resource must assign a new, unique value to the 570 DAV:resource-id property of that new resource. 572 On the other hand, any method that affects an existing resource MUST 573 NOT change the value of its DAV:resource-id property. For example, a 574 PUT or a COPY that updates an existing resource must not change the 575 value of its DAV:resource-id property. A MOVE, since it does not 576 create a new resource, but only changes the location of an existing 577 resource, must not change the value of the DAV:resource-id property. 579 2.7 Discovering the Bindings to a Resource 581 An OPTIONAL DAV:parent-set property on a resource provides a list of 582 the bindings that associate a collection and a URI segment with that 583 resource. If the DAV:parent-set property exists on a given resource, 584 it MUST contain a complete list of all bindings to that resource that 585 the client is authorized to see. When deciding whether to support 586 the DAV:parent-set property, server implementers / administrators 587 should balance the benefits it provides against the cost of 588 maintaining the property and the security risks enumerated in 589 Sections 8.4 and 8.5. 591 3. Properties 593 The bind feature introduces the following properties for a resource. 595 A DAV:allprop PROPFIND request SHOULD NOT return any of the 596 properties defined by this document. This allows a binding server to 597 perform efficiently when a naive client, which does not understand 598 the cost of asking a server to compute all possible live properties, 599 issues a DAV:allprop PROPFIND request. 601 3.1 DAV:resource-id Property 603 The DAV:resource-id property is a REQUIRED property that enables 604 clients to determine whether two bindings are to the same resource. 605 The value of DAV:resource-id is a URI, and may use any registered URI 606 scheme that guarantees the uniqueness of the value across all 607 resources for all time (e.g. the opaquelocktoken: scheme defined in 608 [RFC2518]). 610 612 3.2 DAV:parent-set Property 614 The DAV:parent-set property is an OPTIONAL property that enables 615 clients to discover what collections contain a binding to this 616 resource (i.e. what collections have that resource as an internal 617 member). It contains an of href/segment pair for each collection 618 that has a binding to the resource. The href identifies the 619 collection, and the segment identifies the binding name of that 620 resource in that collection. 622 A given collection MUST appear only once in the DAV:parent-set for 623 any given binding, even if there are multiple URI mappings to that 624 collection. For example, if collection C1 is mapped to both /CollX 625 and /CollY, and C1 contains a binding named "x.gif" to a resource R1, 626 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the 627 DAV:parent-set of R1, but not both. But if C1 also had a binding 628 named "y.gif" to R1, then there would be two entries for C1 in the 629 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX, 630 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). 632 633 634 635 PCDATA value: segment, as defined in section 3.3 of [RFC2396] 637 4. BIND Method 639 The BIND method modifies the collection identified by the 640 Request-URI, by adding a new binding from the segment specified in 641 the BIND body to the resource identified in the BIND body. 643 If a server cannot guarantee the integrity of the binding, the BIND 644 request MUST fail. Note that it is especially difficult to maintain 645 the integrity of cross-server bindings. Unless the server where the 646 resource resides knows about all bindings on all servers to that 647 resource, it may unwittingly destroy the resource or make it 648 inaccessible without notifying another server that manages a binding 649 to the resource. For example, if server A permits creation of a 650 binding to a resource on server B, server A must notify server B 651 about its binding and must have an agreement with B that B will not 652 destroy the resource while A's binding exists. Otherwise server B 653 may receive a DELETE request that it thinks removes the last binding 654 to the resource and destroy the resource while A's binding still 655 exists. The precondition DAV:cross-server-binding is defined below 656 for cases where servers fail cross-server BIND requests because they 657 cannot guarantee the integrity of cross-server bindings. 659 By default, if there already is a binding for the specified segment 660 in the collection, the new binding replaces the existing binding. 661 This default binding replacement behavior can be overridden using the 662 Overwrite header defined in Section 9.6 of [RFC2518]. 664 This method is unsafe and idempotent (see [RFC2616], section 9.1). 666 Marshalling: 668 The request MAY include an Overwrite header. 670 The request body MUST be a DAV:bind XML element. 672 674 If the request succeeds, the server MUST return 201 (Created) when 675 a new binding was created and 200 (OK) when an existing binding 676 was replaced. 678 If a response body for a successful request is included, it MUST 679 be a DAV:bind-response XML element. Note that this document does 680 not define any elements for the BIND response body, but the 681 DAV:bind-response element is defined to ensure interoperability 682 between future extensions that do define elements for the BIND 683 response body. 685 687 Preconditions: 689 (DAV:bind-into-collection): The Request-URI MUST identify a 690 collection. 692 (DAV:bind-source-exists): The DAV:href element MUST identify a 693 resource. 695 (DAV:binding-allowed): The resource identified by the DAV:href 696 supports multiple bindings to it. 698 (DAV:cross-server-binding): If the resource identified by the 699 DAV:href element in the request body is on another server from the 700 collection identified by the request-URI, the server MUST support 701 cross-server bindings. 703 (DAV:name-allowed): The name specified by the DAV:segment is 704 available for use as a new binding name. 706 (DAV:can-overwrite): If the collection already contains a binding 707 with the specified path segment, and if an Overwrite header is 708 included, the value of the Overwrite header MUST be "T". 710 (DAV:cycle-allowed): If the DAV:href element identifies a 711 collection, and if the request-URI identifies a collection that is 712 a member of that collection, the server MUST support cycles in the 713 URI namespace. 715 (DAV:locked-update-allowed): If the collection identified by the 716 Request-URI is write-locked, then the appropriate token MUST be 717 specified in an If request header. 719 (DAV:locked-overwrite-allowed): If the collection already contains 720 a binding with the specified path segment, and if that binding is 721 protected by a write-lock, then the appropriate token MUST be 722 specified in an If request header. 724 Postconditions: 726 (DAV:new-binding): The collection MUST have a binding that maps 727 the segment specified in the DAV:segment element in the request 728 body, to the resource identified by the DAV:href element in the 729 request body. 731 4.1 Example: BIND 733 >> Request: 735 BIND /CollY HTTP/1.1 736 Host: www.example.com 737 Content-Type: text/xml; charset="utf-8" 738 Content-Length: xxx 740 741 742 bar.html 743 http://www.example.com/CollX/foo.html 744 746 >> Response: 748 HTTP/1.1 201 Created 750 The server added a new binding to the collection, 751 "http://www.example.com/CollY", associating "bar.html" with the 752 resource identified by the URI 753 "http://www.example.com/CollX/foo.html". Clients can now use the URI 754 "http://www.example.com/CollY/bar.html", to submit requests to that 755 resource. 757 5. UNBIND Method 759 The UNBIND method modifies the collection identified by the 760 Request-URI, by removing the binding identified by the segment 761 specified in the UNBIND body. 763 Once a resource is unreachable by any URI mapping, the server MAY 764 reclaim system resources associated with that resource. If UNBIND 765 removes a binding to a resource, but there remain URI mappings to 766 that resource, the server MUST NOT reclaim system resources 767 associated with the resource. 769 This method is unsafe and idempotent (see [RFC2616], section 9.1). 771 Marshalling: 773 The request body MUST be a DAV:unbind XML element. 775 777 If the request succeeds, the server MUST return 200 (OK) when the 778 binding was successfully deleted. 780 If a response body for a successful request is included, it MUST 781 be a DAV:unbind-response XML element. Note that this document 782 does not define any elements for the UNBIND response body, but the 783 DAV:unbind-response element is defined to ensure interoperability 784 between future extensions that do define elements for the UNBIND 785 response body. 787 789 Preconditions: 791 (DAV:unbind-from-collection): The Request-URI MUST identify a 792 collection. 794 (DAV:unbind-source-exists): The DAV:segment element MUST identify 795 a binding in the collection identified by the Request-URI. 797 (DAV:locked-update-allowed): If the collection identified by the 798 Request-URI is write-locked, then the appropriate token MUST be 799 specified in the request. 801 (DAV:protected-url-deletion-allowed): If the binding identified by 802 the segment is protected by a write-lock, then the appropriate 803 token MUST be specified in the request. 805 Postconditions: 807 (DAV:binding-deleted): The collection MUST NOT have a binding for 808 the segment specified in the DAV:segment element in the request 809 body. 811 (DAV:lock-deleted): If the internal member URI of the binding 812 specified by the Request-URI and the DAV:segment element in the 813 request body was protected by a write-lock at the time of the 814 request, that write-lock must have been deleted by the request. 816 5.1 Example: UNBIND 818 >> Request: 820 UNBIND /CollX HTTP/1.1 821 Host: www.example.com 822 Content-Type: text/xml; charset="utf-8" 823 Content-Length: xxx 825 826 827 foo.html 828 830 >> Response: 832 HTTP/1.1 200 OK 834 The server removed the binding named "foo.html" from the collection, 835 "http://www.example.com/CollX". A request to the resource named 836 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 837 response. 839 6. REBIND Method 841 The REBIND method removes a binding to a resource from one 842 collection, and adds a binding to that resource into another 843 collection. It is effectively an atomic form of a MOVE request. 845 This method is unsafe and idempotent (see [RFC2616], section 9.1). 847 Marshalling: 849 The request MAY include an Overwrite header. 851 The request body MUST be a DAV:rebind XML element. 853 855 If the request succeeds, the server MUST return 201 (Created) when 856 a new binding was created and 200 (OK) when an existing binding 857 was replaced. 859 If a response body for a successful request is included, it MUST 860 be a DAV:rebind-response XML element. Note that this document 861 does not define any elements for the REBIND response body, but the 862 DAV:rebind-response element is defined to ensure interoperability 863 between future extensions that do define elements for the REBIND 864 response body. 866 868 Preconditions: 870 (DAV:rebind-into-collection): The Request-URI MUST identify a 871 collection. 873 (DAV:rebind-source-exists): The DAV:href element MUST identify a 874 resource. 876 (DAV:cross-server-binding): If the resource identified by the 877 DAV:href element in the request body is on another server from the 878 collection identified by the request-URI, the server MUST support 879 cross-server bindings. 881 (DAV:name-allowed): The name specified by the DAV:segment is 882 available for use as a new binding name. 884 (DAV:can-overwrite): If the collection already contains a binding 885 with the specified path segment, and if an Overwrite header is 886 included, the value of the Overwrite header MUST be "T". 888 (DAV:cycle-allowed): If the DAV:href element identifies a 889 collection, and if the request-URI identifies a collection that is 890 a member of that collection, the server MUST support cycles in the 891 URI namespace. 893 (DAV:locked-update-allowed): If the collection identified by the 894 Request-URI is write-locked, then the appropriate token MUST be 895 specified in the request. 897 (DAV:protected-url-modification-allowed): If the collection 898 identified by the Request-URI already contains a binding with the 899 specified path segment, and if that binding is protected by a 900 write-lock, then the appropriate token MUST be specified in the 901 request. 903 (DAV:locked-source-collection-update-allowed): If the collection 904 identified by the parent collection prefix of the DAV:href URI is 905 write-locked, then the appropriate token MUST be specified in the 906 request. 908 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 909 is protected by a write lock, then the appropriate token MUST be 910 specified in the request. 912 Postconditions: 914 (DAV:new-binding): The collection MUST have a binding that maps 915 the segment specified in the DAV:segment element in the request 916 body, to the resource that was identified by the DAV:href element 917 in the request body. 919 (DAV:binding-deleted): The URL specified in the DAV:href element 920 in the request body MUST NOT be mapped to a resource. 922 (DAV:lock-deleted): If the URL specified in the DAV:href element 923 in the request body was protected by a write-lock at the time of 924 the request, that write-lock must have been deleted by the 925 request. 927 6.1 Example: REBIND 929 >> Request: 931 REBIND /CollX HTTP/1.1 932 Host: www.example.com 933 Content-Type: text/xml; charset="utf-8" 934 Content-Length: xxx 936 937 938 foo.html 939 http://www.example.com/CollY/bar.html 940 942 >> Response: 944 HTTP/1.1 200 OK 946 The server added a new binding to the collection, 947 "http://www.example.com/CollX", associating "foo.html" with the 948 resource identified by the URI 949 "http://www.example.com/CollY/bar.html", and removes the binding 950 named "bar.html" from the collection identified by the URI 951 "http://www.example.com/CollY". Clients can now use the URI 952 "http://www.example.com/CollX/foo.html" to submit requests to that 953 resource, and requests on the URI 954 "http://www.example.com/CollY/bar.html" will fail with a 404 (Not 955 Found) response. 957 7. Additional Status Codes 959 7.1 208 Already Reported 961 The 208 (Already Reported) status code can be used inside a 962 DAV:propstat response element to avoid enumerating the internal 963 members of multiple bindings to the same collection repeatedly. For 964 each binding to a collection inside the request's scope, only one 965 will be reported with a 200 status, while subsequent DAV:response 966 elements for all other bindings will use the 208 status, and no 967 DAV:response elements for their descendants are included. 969 Note that the 208 status will only occur for "Depth: infinity" 970 requests, and that it is of particular importance when the multiple 971 collection bindings cause a bind loop as discussed in Section 2.2. 973 A client can request the DAV:resourceid property in a PROPFIND 974 request to guarantee that they can accurately reconstruct the binding 975 structure of a collection with multiple bindings to a single 976 resource. 978 For backward compatibility with clients not aware of the 208 status 979 code appearing in multistatus response bodies, it SHOULD NOT be used 980 unless the client has signalled support for this specification using 981 the "DAV" request header (see Section 8.2). Instead, a 506 status 982 should be returned when a binding loop is discovered. This allows 983 the server to return the 506 as the top level return status, if it 984 discovers it before it started the response, or in the middle of a 985 multistatus, if it discovers it in the middle of streaming out a 986 multistatus response. 988 7.1.1 Example: PROPFIND by bind-aware client 990 For example, consider a PROPFIND request on /Coll (bound to 991 collection C), where the members of /Coll are /Coll/Foo (bound to 992 resource R) and /Coll/Bar (bound to collection C). 994 >> Request: 996 PROPFIND /Coll/ HTTP/1.1 997 Host: www.example.com 998 Depth: infinity 999 DAV: bind 1000 Content-Type: text/xml; charset="utf-8" 1001 Content-Length: xxx 1003 1004 1005 1006 1007 1008 1009 1011 >> Response: 1013 HTTP/1.1 207 Multi-Status 1014 Content-Type: text/xml; charset="utf-8" 1015 Content-Length: xxx 1017 1018 1019 1020 http://www.example.com/Coll/ 1021 1022 1023 Loop Demo 1024 1025 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1027 1028 1029 HTTP/1.1 200 OK 1030 1031 1032 1033 http://www.example.com/Coll/Foo 1034 1035 1036 Bird Inventory 1037 1038 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1040 1041 1042 HTTP/1.1 200 OK 1043 1044 1045 1046 http://www.example.com/Coll/Bar 1047 1048 1049 Loop Demo 1050 1051 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1053 1054 1055 HTTP/1.1 208 Already Reported 1056 1057 1058 1060 7.1.2 Example: PROPFIND by non-bind-aware client 1062 In this example, the client isn't aware of the 208 status code 1063 introduced by this specification. As the "Depth: infinity" PROPFIND 1064 request would cause a loop condition, the whole request is rejected 1065 with a 506 status. 1067 >> Request: 1069 PROPFIND /Coll/ HTTP/1.1 1070 Host: www.example.com 1071 Depth: infinity 1072 Content-Type: text/xml; charset="utf-8" 1073 Content-Length: xxx 1075 1076 1077 1078 1080 >> Response: 1082 HTTP/1.1 506 Loop Detected 1084 7.2 506 Loop Detected 1086 The 506 (Loop Detected) status code indicates that the server 1087 terminated an operation because it encountered an infinite loop while 1088 processing a request with "Depth: infinity". This status indicates 1089 that the entire operation failed. 1091 8. Capability discovery 1093 8.1 OPTIONS method 1095 If the server supports bindings, it MUST return the compliance class 1096 name "bind" as a field in the "DAV" response header (see [RFC2518], 1097 section 9.1) from an OPTIONS request on any resource implemented by 1098 that server. A value of "bind" in the "DAV" header MUST indicate 1099 that the server supports all MUST level requirements and REQUIRED 1100 features specified in this document. 1102 8.2 'DAV' request header 1104 8.2.1 Generic syntax 1106 This specification introduces the 'DAV' request header that allows 1107 clients to signal compliance to specific WebDAV features. It has the 1108 same syntax as the response header defined in [RFC2518], section 9.1, 1109 but MAY be used with any method. 1111 Note that clients MUST NOT submit a specific compliance class name in 1112 the request header unless the specification defining this compliance 1113 class specifically defines its semantics for clients. 1115 Note that if a server chooses to vary the result of a request based 1116 on values in the "DAV" header, the response either MUST NOT be 1117 cacheable or the server MUST mark the response accordingly using the 1118 "Vary" header (see [RFC2616], section 14.44). 1120 8.2.2 Client compliance class 'bind' 1122 Clients SHOULD signal support for all MUST level requirements and 1123 REQUIRED features by submitting a "DAV" request header containing the 1124 compliance class name "bind". In particular, the client MUST 1125 understand the 208 status code defined in Section 7.1. 1127 9. Security Considerations 1129 This section is provided to make WebDAV implementors aware of the 1130 security implications of this protocol. 1132 All of the security considerations of HTTP/1.1 and the WebDAV 1133 Distributed Authoring Protocol specification also apply to this 1134 protocol specification. In addition, bindings introduce several new 1135 security concerns and increase the risk of some existing threats. 1137 These issues are detailed below. 1139 9.1 Privacy Concerns 1141 In a context where cross-server bindings are supported, creating 1142 bindings on a trusted server may make it possible for a hostile agent 1143 to induce users to send private information to a target on a 1144 different server. 1146 9.2 Bind Loops 1148 Although bind loops were already possible in HTTP 1.1, the 1149 introduction of the BIND method creates a new avenue for clients to 1150 create loops accidentally or maliciously. If the binding and its 1151 target are on the same server, the server may be able to detect BIND 1152 requests that would create loops. Servers are required to detect 1153 loops that are caused by bindings to collections during the 1154 processing of any requests with "Depth: infinity". 1156 9.3 Bindings, and Denial of Service 1158 Denial of service attacks were already possible by posting URIs that 1159 were intended for limited use at heavily used Web sites. The 1160 introduction of BIND creates a new avenue for similar denial of 1161 service attacks. If cross-server bindings are supported, clients can 1162 now create bindings at heavily used sites to target locations that 1163 were not designed for heavy usage. 1165 9.4 Private Locations May Be Revealed 1167 If the DAV:parent-set property is maintained on a resource, the 1168 owners of the bindings risk revealing private locations. The 1169 directory structures where bindings are located are available to 1170 anyone who has access to the DAV:parent-set property on the resource. 1171 Moving a binding may reveal its new location to anyone with access to 1172 DAV:parent-set on its resource. 1174 9.5 DAV:parent-set and Denial of Service 1176 If the server maintains the DAV:parent-set property in response to 1177 bindings created in other administrative domains, it is exposed to 1178 hostile attempts to make it devote resources to adding bindings to 1179 the list. 1181 10. Internationalization Considerations 1183 All internationalization considerations mentioned in [RFC2518] also 1184 apply to this document. 1186 11. IANA Considerations 1188 All IANA considerations mentioned in [RFC2518] also apply to this 1189 document. 1191 12. Acknowledgements 1193 This document is the collaborative product of the authors and Tyson 1194 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1195 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1196 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1197 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan 1198 Eissing, Roy Fielding, Yaron Goland, Joe Hildebrand, Fred Hitt, Alex 1199 Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, 1200 Rohit Khare, Brian Korver, Daniel LaLiberte Steve Martin, Larry 1201 Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, 1202 Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John 1203 Turner, Kevin Wiggen, and other members of the WebDAV working group. 1205 13 Normative References 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, March 1997. 1210 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1211 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1212 August 1998. 1214 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1215 Jensen, "HTTP Extensions for Distributed Authoring -- 1216 WEBDAV", RFC 2518, February 1999. 1218 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1219 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1220 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1222 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 1223 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1224 Edition)", W3C REC-xml-20040204, February 2004, 1225 . 1227 Authors' Addresses 1229 Geoffrey Clemm 1230 IBM 1231 20 Maguire Road 1232 Lexington, MA 02421 1234 EMail: geoffrey.clemm@us.ibm.com 1236 Jason Crawford 1237 IBM Research 1238 P.O. Box 704 1239 Yorktown Heights, NY 10598 1241 EMail: ccjason@us.ibm.com 1243 Julian F. Reschke 1244 greenbytes GmbH 1245 Salzmannstrasse 152 1246 Muenster, NW 48159 1247 Germany 1249 EMail: julian.reschke@greenbytes.de 1251 Jim Whitehead 1252 UC Santa Cruz, Dept. of Computer Science 1253 1156 High Street 1254 Santa Cruz, CA 95064 1256 EMail: ejw@cse.ucsc.edu 1258 Appendix A. Change Log (to be removed by RFC Editor before publication) 1260 A.1 Since draft-ietf-webdav-bind-02 1262 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1263 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1264 resolution, but keep it open. Add issues "ED_references" and 1265 "4_507_status". Started work on index. Rename document to "Binding 1266 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1267 Rename "References" to "Normative References". Close issue 1268 "ED_references". Close issue "4_507_status". 1270 A.2 Since draft-ietf-webdav-bind-03 1272 Add and close issues "9.2_redirect_loops", "ED_authors" and 1273 "ED_updates". Add section about capability discovery (DAV header). 1274 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1275 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1276 "locking" and resolve as invalid. 1278 A.3 Since draft-ietf-webdav-bind-04 1280 Add and close issues "6_precondition_binding_allowed" and 1281 "6_lock_behaviour". Add mailing list and issues list pointers to 1282 front. 1284 A.4 Since draft-ietf-webdav-bind-05 1286 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1287 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1288 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1290 A.5 Since draft-ietf-webdav-bind-06 1292 Rewrite Editorial Note. Open and resolve issues "2.6_identical", 1293 "specify_safeness_and_idempotence" and "ED_rfc2026_ref". 1295 Appendix B. Resolved issues (to be removed by RFC Editor before 1296 publication) 1298 Issues that were either rejected or resolved in this version of this 1299 document. 1301 B.1 ED_rfc2026_ref 1303 Type: edit 1305 1308 julian.reschke@greenbytes.de (2004-09-27): The reference to RFC2026 1309 isn't used anywhere in the text. 1311 Resolution (2004-09-27): Remove it. 1313 B.2 specify_safeness_and_idempotence 1315 Type: edit 1317 1320 julian.reschke@greenbytes.de (2004-09-18): Specify safeness and 1321 idempotence of new methods. 1323 Resolution (2004-09-19): Done. 1325 B.3 2.6_identical 1327 Type: change 1329 1332 julian.reschke@greenbytes.de (2004-09-17): Clarify exactly when when 1333 two resource-ids are identical. 1335 Resolution (2004-09-17): They are identical if and only they are the 1336 same character by character. 1338 Appendix C. Open issues (to be removed by RFC Editor prior to 1339 publication) 1341 C.1 edit 1343 Type: edit 1345 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1346 editorial fixes/enhancements. 1348 Index 1350 2 1351 208 Already Reported (status code) 23 1353 5 1354 506 Loop Detected (status code) 25 1356 B 1357 BIND method 16 1359 C 1360 Condition Names 1361 DAV:bind-into-collection (pre) 17 1362 DAV:bind-source-exists (pre) 17 1363 DAV:binding-allowed (pre) 17 1364 DAV:binding-deleted (post) 19, 22 1365 DAV:can-overwrite (pre) 17, 21 1366 DAV:cross-server-binding (pre) 17, 21 1367 DAV:cycle-allowed (pre) 17, 21 1368 DAV:lock-deleted (post) 19, 22 1369 DAV:locked-overwrite-allowed (pre) 17 1370 DAV:locked-source-collection-update-allowed (pre) 21 1371 DAV:locked-update-allowed (pre) 17, 19, 21 1372 DAV:name-allowed (pre) 17, 21 1373 DAV:new-binding (post) 17, 22 1374 DAV:protected-source-url-deletion-allowed (pre) 21 1375 DAV:protected-url-deletion-allowed (pre) 19 1376 DAV:protected-url-modification-allowed (pre) 21 1377 DAV:rebind-into-collection (pre) 21 1378 DAV:rebind-source-exists (pre) 21 1379 DAV:unbind-from-collection (pre) 19 1380 DAV:unbind-source-exists (pre) 19 1382 D 1383 DAV header 1384 compliance class 'bind' 26 1385 DAV:bind-into-collection precondition 17 1386 DAV:bind-source-exists precondition 17 1387 DAV:binding-allowed precondition 17 1388 DAV:binding-deleted postcondition 19, 22 1389 DAV:can-overwrite precondition 17, 21 1390 DAV:cross-server-binding precondition 17, 21 1391 DAV:cycle-allowed precondition 17, 21 1392 DAV:lock-deleted postcondition 19, 22 1393 DAV:locked-overwrite-allowed precondition 17 1394 DAV:locked-source-collection-update-allowed precondition 21 1395 DAV:locked-update-allowed precondition 17, 19, 21 1396 DAV:name-allowed precondition 17, 21 1397 DAV:new-binding postcondition 17, 22 1398 DAV:parent-set property 15 1399 DAV:protected-source-url-deletion-allowed precondition 21 1400 DAV:protected-url-deletion-allowed precondition 19 1401 DAV:protected-url-modification-allowed precondition 21 1402 DAV:rebind-into-collection precondition 21 1403 DAV:rebind-source-exists precondition 21 1404 DAV:resource-id property 15 1405 DAV:unbind-from-collection precondition 19 1406 DAV:unbind-source-exists precondition 19 1408 M 1409 Methods 1410 BIND 16 1411 REBIND 20 1412 UNBIND 18 1414 P 1415 Properties 1416 DAV:parent-set 15 1417 DAV:resource-id 15 1419 R 1420 REBIND method 20 1422 S 1423 Status Codes 1424 208 Already Reported 23 1425 506 Loop Detected 25 1427 U 1428 UNBIND method 18 1430 Intellectual Property Statement 1432 The IETF takes no position regarding the validity or scope of any 1433 Intellectual Property Rights or other rights that might be claimed to 1434 pertain to the implementation or use of the technology described in 1435 this document or the extent to which any license under such rights 1436 might or might not be available; nor does it represent that it has 1437 made any independent effort to identify any such rights. Information 1438 on the procedures with respect to rights in RFC documents can be 1439 found in BCP 78 and BCP 79. 1441 Copies of IPR disclosures made to the IETF Secretariat and any 1442 assurances of licenses to be made available, or the result of an 1443 attempt made to obtain a general license or permission for the use of 1444 such proprietary rights by implementers or users of this 1445 specification can be obtained from the IETF on-line IPR repository at 1446 http://www.ietf.org/ipr. 1448 The IETF invites any interested party to bring to its attention any 1449 copyrights, patents or patent applications, or other proprietary 1450 rights that may cover technology that may be required to implement 1451 this standard. Please address the information to the IETF at 1452 ietf-ipr@ietf.org. 1454 Disclaimer of Validity 1456 This document and the information contained herein are provided on an 1457 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1458 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1459 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1460 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1461 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1462 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1464 Copyright Statement 1466 Copyright (C) The Internet Society (2004). This document is subject 1467 to the rights, licenses and restrictions contained in BCP 78, and 1468 except as set forth therein, the authors retain all their rights. 1470 Acknowledgment 1472 Funding for the RFC Editor function is currently provided by the 1473 Internet Society.