idnits 2.17.1 draft-ietf-webdav-bind-06.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1479. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1495), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-webdav-bind-latest-06', but the file name used is 'draft-ietf-webdav-bind-06' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 2, 2004) is 7236 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) == Unused Reference: 'RFC2026' is defined on line 1195, but no explicit reference was found in the text ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 10 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: December 31, 2004 IBM Research 5 J. Reschke 6 greenbytes 7 J. Whitehead 8 U.C. Santa Cruz 9 July 2, 2004 11 Binding Extensions to Web Distributed Authoring and Versioning 12 (WebDAV) 13 draft-ietf-webdav-bind-latest-06 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 31, 2004. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This specification defines bindings, and the BIND method for creating 47 multiple bindings to the same resource. Creating a new binding to a 48 resource causes at least one new URI to be mapped to that resource. 50 Servers are required to insure the integrity of any bindings that 51 they allow to be created. 53 Editorial Note 55 *(To be removed before publication as RFC):* 57 Please send comments to the Distributed Authoring and Versioning 58 (WebDAV) working group at w3c-dist-auth@w3.org [1], which may be 59 joined by sending a message with subject "subscribe" to 60 w3c-dist-auth-request@w3.org [2]. Discussions of the WEBDAV working 61 group are archived at . 63 lists all registered issues since draft 02. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2 Rationale for Distinguishing Bindings from URI Mappings . 6 70 1.3 Method Preconditions and Postconditions . . . . . . . . . 7 71 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 72 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 8 73 2.2 URI Mappings Created by a new Binding . . . . . . . . . . 9 74 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10 75 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 11 76 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 12 77 2.6 Determining Whether Two Bindings Are to the Same 78 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 2.7 Discovering the Bindings to a Resource . . . . . . . . . . 13 80 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 14 82 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 14 83 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 17 85 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 17 86 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 19 87 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 19 88 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 21 89 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 21 90 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 21 91 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 22 92 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 24 93 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 24 94 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 24 95 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 24 96 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 24 97 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 24 98 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 25 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 25 101 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 25 102 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 26 103 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 26 104 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 26 105 10. Internationalization Considerations . . . . . . . . . . . . 26 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 107 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 108 13. Normative References . . . . . . . . . . . . . . . . . . . . 27 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 110 A. Change Log (to be removed by RFC Editor before publication) . 28 111 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 28 112 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 28 113 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 28 114 A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 28 115 B. Resolved issues (to be removed by RFC Editor before 116 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 B.1 4_LOCK_BEHAVIOR . . . . . . . . . . . . . . . . . . . . . 29 118 B.2 1.3_error_negotiation . . . . . . . . . . . . . . . . . . 29 119 B.3 2.5_language . . . . . . . . . . . . . . . . . . . . . . . 30 120 B.4 7.1.1_add_resource_id . . . . . . . . . . . . . . . . . . 30 121 C. Open issues (to be removed by RFC Editor prior to 122 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30 123 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 124 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 125 Intellectual Property and Copyright Statements . . . . . . . . 33 127 1. Introduction 129 This specification extends the WebDAV Distributed Authoring Protocol 130 to enable clients to create new access paths to existing resources. 131 This capability is useful for several reasons: 133 URIs of WebDAV-compliant resources are hierarchical and correspond to 134 a hierarchy of collections in resource space. The WebDAV Distributed 135 Authoring Protocol makes it possible to organize these resources into 136 hierarchies, placing them into groupings, known as collections, which 137 are more easily browsed and manipulated than a single flat 138 collection. However, hierarchies require categorization decisions 139 that locate resources at a single location in the hierarchy, a 140 drawback when a resource has multiple valid categories. For example, 141 in a hierarchy of vehicle descriptions containing collections for 142 cars and boats, a description of a combination car/boat vehicle could 143 belong in either collection. Ideally, the description should be 144 accessible from both. Allowing clients to create new URIs that 145 access the existing resource lets them put that resource into 146 multiple collections. 148 Hierarchies also make resource sharing more difficult, since 149 resources that have utility across many collections are still forced 150 into a single collection. For example, the mathematics department at 151 one university might create a collection of information on fractals 152 that contains bindings to some local resources, but also provides 153 access to some resources at other universities. For many reasons, it 154 may be undesirable to make physical copies of the shared resources on 155 the local server: to conserve disk space, to respect copyright 156 constraints, or to make any changes in the shared resources visible 157 automatically. Being able to create new access paths to existing 158 resources in other collections or even on other servers is useful for 159 this sort of case. 161 The BIND method defined here provides a mechanism for allowing 162 clients to create alternative access paths to existing WebDAV 163 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to 164 work because there are mappings between URIs and resources. A method 165 is addressed to a URI, and the server follows the mapping from that 166 URI to a resource, applying the method to that resource. Multiple 167 URIs may be mapped to the same resource, but until now there has been 168 no way for clients to create additional URIs mapped to existing 169 resources. 171 BIND lets clients associate a new URI with an existing WebDAV 172 resource, and this URI can then be used to submit requests to the 173 resource. Since URIs of WebDAV resources are hierarchical, and 174 correspond to a hierarchy of collections in resource space, the BIND 175 method also has the effect of adding the resource to a collection. 176 As new URIs are associated with the resource, it appears in 177 additional collections. 179 A BIND request does not create a new resource, but simply makes 180 available a new URI for submitting requests to an existing resource. 181 The new URI is indistinguishable from any other URI when submitting a 182 request to a resource. Only one round trip is needed to submit a 183 request to the intended target. Servers are required to enforce the 184 integrity of the relationships between the new URIs and the resources 185 associated with them. Consequently, it may be very costly for 186 servers to support BIND requests that cross server boundaries. 188 This specification is organized as follows. Section 1.1 defines 189 terminology used in the rest of the specification, while Section 2 190 overviews bindings. Section 3 defines the new properties needed to 191 support multiple bindings to the same resource. Section 4 specifies 192 the BIND method, used to create multiple bindings to the same 193 resource. Section 5 specifies the UNBIND method, used to remove a 194 binding to a resource. Section 6 specifies the REBIND method, used 195 to move a binding to another collection. 197 1.1 Terminology 199 The terminology used here follows and extends that in the WebDAV 200 Distributed Authoring Protocol specification [RFC2518]. 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 This document uses XML DTD fragments ([XML]) as a purely notational 207 convention. WebDAV request and response bodies cannot be validated 208 due to the specific extensibility rules defined in section 23 of 209 [RFC2518] and due to the fact that all XML elements defined by this 210 specification use the XML namespace name "DAV:". In particular: 212 o Element names use the "DAV:" namespace. 214 o Element ordering is irrelevant. 216 o Extension elements/attributes (elements/attributes not already 217 defined as valid child elements) may be added anywhere, except 218 when explicitly stated otherwise. 220 URI Mapping 222 A relation between an absolute URI and a resource. For an 223 absolute URI U and the resource it identifies R, the URI mapping 224 can be thought of as (U => R). Since a resource can represent 225 items that are not network retrievable, as well as those that are, 226 it is possible for a resource to have zero, one, or many URI 227 mappings. Mapping a resource to an "http" scheme URI makes it 228 possible to submit HTTP protocol requests to the resource using 229 the URI. 231 Path Segment 233 Informally, the characters found between slashes ("/") in a URI. 234 Formally, as defined in section 3.3 of [RFC2396]. 236 Binding 238 A relation between a single path segment (in a collection) and a 239 resource. A binding is part of the state of a collection. If two 240 different collections contain a binding between the same path 241 segment and the same resource, these are two distinct bindings. 242 So for a collection C, a path segment S, and a resource R, the 243 binding can be thought of as C:(S -> R). Bindings create URI 244 mappings, and hence allow requests to be sent to a single resource 245 from multiple locations in a URI namespace. For example, given a 246 collection C (accessible through the URI 247 http://www.example.com/CollX), a path segment S (equal to 248 "foo.html"), and a resource R, then creating the binding C: (S -> 249 R) makes it possible to use the URI 250 http://www.example.com/CollX/foo.html to access R. 252 Collection 254 A resource that contains, as part of its state, a set of bindings 255 that identify internal member resources. 257 Internal Member URI 259 The URI that identifies an internal member of a collection, and 260 that consists of the URI for the collection, followed by a slash 261 character ('/'), followed by the path segment of the binding for 262 that internal member. 264 1.2 Rationale for Distinguishing Bindings from URI Mappings 266 In [RFC2518], the state of a collection is defined as containing a 267 list of internal member URIs. If there are multiple mappings to a 268 collection, then the state of the collection is different when you 269 refer to it via a different URI. This is undesirable, since ideally 270 a collection's membership should remain the same, independent of 271 which URI was used to reference it. 273 The notion of binding is introduced to separate the final segment of 274 a URI from its parent collection's contribution. This done, a 275 collection can be defined as containing a set of bindings, thus 276 permitting new mappings to a collection without modifying its 277 membership. The authors of this specification anticipate and 278 recommend that future revisions of [RFC2518] will update the 279 definition of the state of a collection to correspond to the 280 definition in this document. 282 1.3 Method Preconditions and Postconditions 284 A "precondition" of a method describes the state on the server that 285 must be true for that method to be performed. A "postcondition" of a 286 method describes the state on the server that must be true after that 287 method has completed. If a method precondition or postcondition for 288 a request is not satisfied, the response status of the request MUST 289 be either 403 (Forbidden) if the request should not be repeated 290 because it will always fail, or 409 (Conflict) if it is expected that 291 the user might be able to resolve the conflict and resubmit the 292 request. 294 In order to allow better client handling of 403 and 409 responses, a 295 distinct XML element type is associated with each method precondition 296 and postcondition of a request. When a particular precondition is 297 not satisfied or a particular postcondition cannot be achieved, the 298 appropriate XML element MUST be returned as the child of a top-level 299 DAV:error element in the response body, unless otherwise negotiated 300 by the request. In a 207 Multi-Status response, the DAV:error 301 element would appear in the appropriate DAV:responsedescription 302 element. 304 2. Overview of Bindings 306 Bindings are part of the state of a collection. They define the 307 internal members of the collection, and the names of those internal 308 members. 310 Bindings are added and removed by a variety of existing HTTP methods. 311 A method that creates a new resource, such as PUT, COPY, and MKCOL, 312 adds a binding. A method that deletes a resource, such as DELETE, 313 removes a binding. A method that moves a resource (e.g. MOVE) both 314 adds a binding (in the destination collection) and removes a binding 315 (in the source collection). The BIND method introduced here provides 316 a mechanism for adding a second binding to an existing resource. 317 There is no difference between an initial binding added by PUT, COPY, 318 or MKCOL, and additional bindings added with BIND. 320 It would be very undesirable if one binding could be destroyed as a 321 side effect of operating on the resource through a different binding. 322 In particular, the removal of one binding to a resource (e.g. with a 323 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 324 e.g. by turning that binding into a dangling path segment. The 325 server MUST NOT reclaim system resources after removing one binding, 326 while other bindings to the resource remain. In other words, the 327 server MUST maintain the integrity of a binding. 329 2.1 Bindings to Collections 331 Bindings to collections can result in loops, which servers MUST 332 detect when processing "Depth: infinity" requests. It is sometimes 333 possible to complete an operation in spite of the presence of a loop. 334 However, the 506 (Loop Detected) status code is defined in Section 7 335 for use in contexts where an operation is terminated because a loop 336 was encountered. 338 Creating a new binding to a collection makes each resource associated 339 with a binding in that collection accessible via a new URI, and thus 340 creates new URI mappings to those resources but no new bindings. 342 For example, suppose a new binding CollY is created for collection C1 343 in the figure below. It immediately becomes possible to access 344 resource R1 using the URI /CollY/x.gif and to access resource R2 345 using the URI /CollY/y.jpg, but no new bindings for these child 346 resources were created. This is because bindings are part of the 347 state of a collection, and associate a URI that is relative to that 348 collection with its target resource. No change to the bindings in 349 Collection C1 is needed to make its children accessible using /CollY/ 350 x.gif and /CollY/y.jpg. 352 +-------------------------+ 353 | Root Collection | 354 | bindings: | 355 | CollX CollY | 356 +-------------------------+ 357 | / 358 | / 359 | / 360 +------------------+ 361 | Collection C1 | 362 | bindings: | 363 | x.gif y.jpg | 364 +------------------+ 365 | \ 366 | \ 367 | \ 368 +-------------+ +-------------+ 369 | Resource R1 | | Resource R2 | 370 +-------------+ +-------------+ 372 2.2 URI Mappings Created by a new Binding 374 Suppose a binding from "Binding-Name" to resource R is to be added to 375 a collection, C. Then if C-MAP is the set of URIs that were mapped 376 to C before the BIND request, then for each URI "C-URI" in C-MAP, the 377 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 378 request. 380 For example, if a binding from "foo.html" to R is added to a 381 collection C, and if the following URIs are mapped to C: 383 http://www.example.com/A/1/ 384 http://example.com/A/one/ 386 then the following new mappings to R are introduced: 388 http://www.example.com/A/1/foo.html 389 http://example.com/A/one/foo.html 391 Note that if R is a collection, additional URI mappings are created 392 to the descendents of R. Also, note that if a binding is made in 393 collection C to C itself (or to a parent of C), an infinite number of 394 mappings are introduced. 396 For example, if a binding from "myself" to C is then added to C, the 397 following infinite number of additional mappings to C are introduced: 399 http://www.example.com/A/1/myself 400 http://www.example.com/A/1/myself/myself 401 ... 403 and the following infinite number of additional mappings to R are 404 introduced: 406 http://www.example.com/A/1/myself/foo.html 407 http://www.example.com/A/1/myself/myself/foo.html 408 ... 410 2.3 COPY and Bindings 412 As defined in Section 8.8 of [RFC2518], COPY causes the resource 413 identified by the Request-URI to be duplicated, and makes the new 414 resource accessible using the URI specified in the Destination 415 header. Upon successful completion of a COPY, a new binding is 416 created between the last path segment of the Destination header, and 417 the destination resource. The new binding is added to its parent 418 collection, identified by the Destination header minus its final 419 segment. 421 The following figure shows an example: Suppose that a COPY is issued 422 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 423 with the Destination header set to URI-X. After successful 424 completion of the COPY operation, resource R is duplicated to create 425 resource R', and a new binding has been created which creates at 426 least the URI mapping between URI-X and the new resource (although 427 other URI mappings may also have been created). 429 URI-1 URI-2 URI-3 URI-X 430 | | | | 431 | | | <---- URI Mappings ----> | 432 | | | | 433 +---------------------+ +------------------------+ 434 | Resource R | | Resource R' | 435 +---------------------+ +------------------------+ 437 It might be thought that a COPY request with "Depth: 0" on a 438 collection would duplicate its bindings, since bindings are part of 439 the collection's state. This is not the case, however. The 440 definition of Depth in [RFC2518] makes it clear that a "Depth: 0" 441 request does not apply to a collection's members. Consequently, a 442 COPY with "Depth: 0" does not duplicate the bindings contained by the 443 collection. 445 If a COPY request causes an existing resource to be updated, the 446 bindings to that resource MUST be unaffected by the COPY request. 447 Using the preceding example, suppose that a COPY request is issued to 448 URI-X for resource R', with the Destination header set to URI-2. The 449 content and dead properties of resource R would be updated to be a 450 copy of those of resource R', but the mappings from URI-1, URI-2, and 451 URI-3 to resource R remain unaffected. If because of multiple 452 bindings to a resource, more than one source resource updates a 453 single destination resource, the order of the updates is server 454 defined. 456 If a COPY request would cause a new resource to be created as a copy 457 of an existing resource, and that COPY request has already created a 458 copy of that existing resource, the COPY request instead creates 459 another binding to the previous copy, instead of creating a new 460 resource. 462 2.4 DELETE and Bindings 464 When there are multiple bindings to a resource, a DELETE applied to 465 that resource MUST NOT remove any bindings to that resource other 466 than the one identified by the request URI. For example, suppose the 467 collection identified by the URI "/a" has a binding named "x" to a 468 resource R, and another collection identified by "/b" has a binding 469 named "y" to the same resource R. Then a DELETE applied to "/a/x" 470 removes the binding named "x" from "/a" but MUST NOT remove the 471 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 472 to identify the resource R). In particular, although Section 8.6.1 473 of [RFC2518] states that during DELETE processing, a server "MUST 474 remove any URI for the resource identified by the Request-URI from 475 collections which contain it as a member", a server that supports the 476 binding protocol MUST NOT follow this requirement. 478 When DELETE is applied to a collection, it MUST NOT modify the 479 membership of any other collection that is not itself a member of the 480 collection being deleted. For example, if both "/a/.../x" and "/b/ 481 .../y" identify the same collection, C, then applying DELETE to "/a" 482 MUST NOT delete an internal member from C or from any other 483 collection that is a member of C, because that would modify the 484 membership of "/b". 486 If a collection supports the UNBIND method (see Section 5), a DELETE 487 of an internal member of a collection MAY be implemented as an UNBIND 488 request. In this case, applying DELETE to a Request-URI has the 489 effect of removing the binding identified by the final segment of the 490 Request-URI from the collection identified by the Request-URI minus 491 its final segment. Although [RFC2518] allows a DELETE to be a 492 non-atomic operation, when the DELETE operation is implemented as an 493 UNBIND, the operation is atomic. In particular, a DELETE on a 494 hierarchy of resources is simply the removal of a binding to the 495 collection identified by the Request-URI. 497 2.5 MOVE and Bindings 499 When MOVE is applied to a resource, the other bindings to that 500 resource MUST be unaffected, and if the resource being moved is a 501 collection, the bindings to any members of that collection MUST be 502 unaffected. Also, if MOVE is used with Overwrite:T to delete an 503 existing resource, the constraints specified for DELETE apply. 505 If the destination collection of a MOVE request supports the REBIND 506 method (see Section 6), a MOVE of a resource into that collection MAY 507 be implemented as a REBIND request. Although [RFC2518] allows a MOVE 508 to be a non-atomic operation, when the MOVE operation is implemented 509 as a REBIND, the operation is atomic. In particular, applying a MOVE 510 to a Request-URI and a Destination URI has the effect of removing a 511 binding to a resource (at the Request-URI), and creating a new 512 binding to that resource (at the Destination URI). Even when the 513 Request-URI identifies a collection, the MOVE operation involves only 514 removing one binding to that collection and adding another. 516 As an example, suppose that a MOVE is issued to URI-3 for resource R 517 below (which is also mapped to URI-1 and URI-2), with the Destination 518 header set to URI-X. After successful completion of the MOVE 519 operation, a new binding has been created which creates the URI 520 mapping between URI-X and resource R. The binding corresponding to 521 the final segment of URI-3 has been removed, which also causes the 522 URI mapping between URI-3 and R to be removed. If resource R were a 523 collection, old URI-3 based mappings to members of R would have been 524 removed, and new URI-X based mappings to members of R would have been 525 created. 527 >> Before Request: 529 URI-1 URI-2 URI-3 530 | | | 531 | | | <---- URI Mappings 532 | | | 533 +---------------------+ 534 | Resource R | 535 +---------------------+ 536 >> After Request: 538 URI-1 URI-2 URI-X 539 | | | 540 | | | <---- URI Mappings 541 | | | 542 +---------------------+ 543 | Resource R | 544 +---------------------+ 546 2.6 Determining Whether Two Bindings Are to the Same Resource 548 It is useful to have some way of determining whether two bindings are 549 to the same resource. Two resources might have identical contents 550 and properties, but not be the same resource (e.g. an update to one 551 resource does not affect the other resource). 553 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 554 resource identifier, which MUST be unique across all resources for 555 all time. If the values of DAV:resource-id returned by PROPFIND 556 requests through two bindings are identical, the client can be 557 assured that the two bindings are to the same resource. 559 The DAV:resource-id property is created, and its value assigned, when 560 the resource is created. The value of DAV:resource-id MUST NOT be 561 changed. Even after the resource is no longer accessible through any 562 URI, that value MUST NOT be reassigned to another resource's 563 DAV:resource-id property. 565 Any method that creates a new resource MUST assign a new, unique 566 value to its DAV:resource-id property. For example, a PUT or a COPY 567 that creates a new resource must assign a new, unique value to the 568 DAV:resource-id property of that new resource. 570 On the other hand, any method that affects an existing resource MUST 571 NOT change the value of its DAV:resource-id property. For example, a 572 PUT or a COPY that updates an existing resource must not change the 573 value of its DAV:resource-id property. A MOVE, since it does not 574 create a new resource, but only changes the location of an existing 575 resource, must not change the value of the DAV:resource-id property. 577 2.7 Discovering the Bindings to a Resource 579 An OPTIONAL DAV:parent-set property on a resource provides a list of 580 the bindings that associate a collection and a URI segment with that 581 resource. If the DAV:parent-set property exists on a given resource, 582 it MUST contain a complete list of all bindings to that resource that 583 the client is authorized to see. When deciding whether to support 584 the DAV:parent-set property, server implementers / administrators 585 should balance the benefits it provides against the cost of 586 maintaining the property and the security risks enumerated in 587 Sections 8.4 and 8.5. 589 3. Properties 591 The bind feature introduces the following properties for a resource. 593 A DAV:allprop PROPFIND request SHOULD NOT return any of the 594 properties defined by this document. This allows a binding server to 595 perform efficiently when a naive client, which does not understand 596 the cost of asking a server to compute all possible live properties, 597 issues a DAV:allprop PROPFIND request. 599 3.1 DAV:resource-id Property 601 The DAV:resource-id property is a REQUIRED property that enables 602 clients to determine whether two bindings are to the same resource. 603 The value of DAV:resource-id is a URI, and may use any registered URI 604 scheme that guarantees the uniqueness of the value across all 605 resources for all time (e.g. the opaquelocktoken: scheme defined in 606 [RFC2518]). 608 610 3.2 DAV:parent-set Property 612 The DAV:parent-set property is an OPTIONAL property that enables 613 clients to discover what collections contain a binding to this 614 resource (i.e. what collections have that resource as an internal 615 member). It contains an of href/segment pair for each collection 616 that has a binding to the resource. The href identifies the 617 collection, and the segment identifies the binding name of that 618 resource in that collection. 620 A given collection MUST appear only once in the DAV:parent-set for 621 any given binding, even if there are multiple URI mappings to that 622 collection. For example, if collection C1 is mapped to both /CollX 623 and /CollY, and C1 contains a binding named "x.gif" to a resource R1, 624 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the 625 DAV:parent-set of R1, but not both. But if C1 also had a binding 626 named "y.gif" to R1, then there would be two entries for C1 in the 627 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX, 628 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). 630 631 632 633 PCDATA value: segment, as defined in section 3.3 of [RFC2396] 635 4. BIND Method 637 The BIND method modifies the collection identified by the 638 Request-URI, by adding a new binding from the segment specified in 639 the BIND body to the resource identified in the BIND body. 641 If a server cannot guarantee the integrity of the binding, the BIND 642 request MUST fail. Note that it is especially difficult to maintain 643 the integrity of cross-server bindings. Unless the server where the 644 resource resides knows about all bindings on all servers to that 645 resource, it may unwittingly destroy the resource or make it 646 inaccessible without notifying another server that manages a binding 647 to the resource. For example, if server A permits creation of a 648 binding to a resource on server B, server A must notify server B 649 about its binding and must have an agreement with B that B will not 650 destroy the resource while A's binding exists. Otherwise server B 651 may receive a DELETE request that it thinks removes the last binding 652 to the resource and destroy the resource while A's binding still 653 exists. The precondition DAV:cross-server-binding is defined below 654 for cases where servers fail cross-server BIND requests because they 655 cannot guarantee the integrity of cross-server bindings. 657 By default, if there already is a binding for the specified segment 658 in the collection, the new binding replaces the existing binding. 659 This default binding replacement behavior can be overridden using the 660 Overwrite header defined in Section 9.6 of [RFC2518]. 662 Marshalling: 664 The request MAY include an Overwrite header. 666 The request body MUST be a DAV:bind XML element. 668 670 If the request succeeds, the server MUST return 201 (Created) when 671 a new binding was created and 200 (OK) when an existing binding 672 was replaced. 674 If a response body for a successful request is included, it MUST 675 be a DAV:bind-response XML element. Note that this document does 676 not define any elements for the BIND response body, but the 677 DAV:bind-response element is defined to ensure interoperability 678 between future extensions that do define elements for the BIND 679 response body. 681 683 Preconditions: 685 (DAV:bind-into-collection): The Request-URI MUST identify a 686 collection. 688 (DAV:bind-source-exists): The DAV:href element MUST identify a 689 resource. 691 (DAV:binding-allowed): The resource identified by the DAV:href 692 supports multiple bindings to it. 694 (DAV:cross-server-binding): If the resource identified by the 695 DAV:href element in the request body is on another server from the 696 collection identified by the request-URI, the server MUST support 697 cross-server bindings. 699 (DAV:name-allowed): The name specified by the DAV:segment is 700 available for use as a new binding name. 702 (DAV:can-overwrite): If the collection already contains a binding 703 with the specified path segment, and if an Overwrite header is 704 included, the value of the Overwrite header MUST be "T". 706 (DAV:cycle-allowed): If the DAV:href element identifies a 707 collection, and if the request-URI identifies a collection that is 708 a member of that collection, the server MUST support cycles in the 709 URI namespace. 711 (DAV:locked-update-allowed): If the collection identified by the 712 Request-URI is write-locked, then the appropriate token MUST be 713 specified in an If request header. 715 (DAV:locked-overwrite-allowed): If the collection already contains 716 a binding with the specified path segment, and if that binding is 717 protected by a write-lock, then the appropriate token MUST be 718 specified in an If request header. 720 Postconditions: 722 (DAV:new-binding): The collection MUST have a binding that maps 723 the segment specified in the DAV:segment element in the request 724 body, to the resource identified by the DAV:href element in the 725 request body. 727 4.1 Example: BIND 729 >> Request: 731 BIND /CollY HTTP/1.1 732 Host: www.example.com 733 Content-Type: text/xml; charset="utf-8" 734 Content-Length: xxx 736 737 738 bar.html 739 http://www.example.com/CollX/foo.html 740 742 >> Response: 744 HTTP/1.1 201 Created 746 The server added a new binding to the collection, 747 "http://www.example.com/CollY", associating "bar.html" with the 748 resource identified by the URI 749 "http://www.example.com/CollX/foo.html". Clients can now use the URI 750 "http://www.example.com/CollY/bar.html", to submit requests to that 751 resource. 753 5. UNBIND Method 755 The UNBIND method modifies the collection identified by the 756 Request-URI, by removing the binding identified by the segment 757 specified in the UNBIND body. 759 Once a resource is unreachable by any URI mapping, the server MAY 760 reclaim system resources associated with that resource. If UNBIND 761 removes a binding to a resource, but there remain URI mappings to 762 that resource, the server MUST NOT reclaim system resources 763 associated with the resource. 765 Marshalling: 767 The request body MUST be a DAV:unbind XML element. 769 770 If the request succeeds, the server MUST return 200 (OK) when the 771 binding was successfully deleted. 773 If a response body for a successful request is included, it MUST 774 be a DAV:unbind-response XML element. Note that this document 775 does not define any elements for the UNBIND response body, but the 776 DAV:unbind-response element is defined to ensure interoperability 777 between future extensions that do define elements for the UNBIND 778 response body. 780 782 Preconditions: 784 (DAV:unbind-from-collection): The Request-URI MUST identify a 785 collection. 787 (DAV:unbind-source-exists): The DAV:segment element MUST identify 788 a binding in the collection identified by the Request-URI. 790 (DAV:locked-update-allowed): If the collection identified by the 791 Request-URI is write-locked, then the appropriate token MUST be 792 specified in the request. 794 (DAV:protected-url-deletion-allowed): If the binding identified by 795 the segment is protected by a write-lock, then the appropriate 796 token MUST be specified in the request. 798 Postconditions: 800 (DAV:binding-deleted): The collection MUST NOT have a binding for 801 the segment specified in the DAV:segment element in the request 802 body. 804 (DAV:lock-deleted): If the internal member URI of the binding 805 specified by the Request-URI and the DAV:segment element in the 806 request body was protected by a write-lock at the time of the 807 request, that write-lock must have been deleted by the request. 809 5.1 Example: UNBIND 811 >> Request: 813 UNBIND /CollX HTTP/1.1 814 Host: www.example.com 815 Content-Type: text/xml; charset="utf-8" 816 Content-Length: xxx 818 819 820 foo.html 821 823 >> Response: 825 HTTP/1.1 200 OK 827 The server removed the binding named "foo.html" from the collection, 828 "http://www.example.com/CollX". A request to the resource named 829 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 830 response. 832 6. REBIND Method 834 The REBIND method removes a binding to a resource from one 835 collection, and adds a binding to that resource into another 836 collection. It is effectively an atomic form of a MOVE request. 838 Marshalling: 840 The request MAY include an Overwrite header. 842 The request body MUST be a DAV:rebind XML element. 844 846 If the request succeeds, the server MUST return 201 (Created) when 847 a new binding was created and 200 (OK) when an existing binding 848 was replaced. 850 If a response body for a successful request is included, it MUST 851 be a DAV:rebind-response XML element. Note that this document 852 does not define any elements for the REBIND response body, but the 853 DAV:rebind-response element is defined to ensure interoperability 854 between future extensions that do define elements for the REBIND 855 response body. 857 859 Preconditions: 861 (DAV:rebind-into-collection): The Request-URI MUST identify a 862 collection. 864 (DAV:rebind-source-exists): The DAV:href element MUST identify a 865 resource. 867 (DAV:cross-server-binding): If the resource identified by the 868 DAV:href element in the request body is on another server from the 869 collection identified by the request-URI, the server MUST support 870 cross-server bindings. 872 (DAV:name-allowed): The name specified by the DAV:segment is 873 available for use as a new binding name. 875 (DAV:can-overwrite): If the collection already contains a binding 876 with the specified path segment, and if an Overwrite header is 877 included, the value of the Overwrite header MUST be "T". 879 (DAV:cycle-allowed): If the DAV:href element identifies a 880 collection, and if the request-URI identifies a collection that is 881 a member of that collection, the server MUST support cycles in the 882 URI namespace. 884 (DAV:locked-update-allowed): If the collection identified by the 885 Request-URI is write-locked, then the appropriate token MUST be 886 specified in the request. 888 (DAV:protected-url-modification-allowed): If the collection 889 identified by the Request-URI already contains a binding with the 890 specified path segment, and if that binding is protected by a 891 write-lock, then the appropriate token MUST be specified in the 892 request. 894 (DAV:locked-source-collection-update-allowed): If the collection 895 identified by the parent collection prefix of the DAV:href URI is 896 write-locked, then the appropriate token MUST be specified in the 897 request. 899 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 900 is protected by a write lock, then the appropriate token MUST be 901 specified in the request. 903 Postconditions: 905 (DAV:new-binding): The collection MUST have a binding that maps 906 the segment specified in the DAV:segment element in the request 907 body, to the resource that was identified by the DAV:href element 908 in the request body. 910 (DAV:binding-deleted): The URL specified in the DAV:href element 911 in the request body MUST NOT be mapped to a resource. 913 (DAV:lock-deleted): If the URL specified in the DAV:href element 914 in the request body was protected by a write-lock at the time of 915 the request, that write-lock must have been deleted by the 916 request. 918 6.1 Example: REBIND 920 >> Request: 922 REBIND /CollX HTTP/1.1 923 Host: www.example.com 924 Content-Type: text/xml; charset="utf-8" 925 Content-Length: xxx 927 928 929 foo.html 930 http://www.example.com/CollY/bar.html 931 933 >> Response: 935 HTTP/1.1 200 OK 937 The server added a new binding to the collection, 938 "http://www.example.com/CollX", associating "foo.html" with the 939 resource identified by the URI 940 "http://www.example.com/CollY/bar.html", and removes the binding 941 named "bar.html" from the collection identified by the URI 942 "http://www.example.com/CollY". Clients can now use the URI "http:// 943 www.example.com/CollX/foo.html" to submit requests to that resource, 944 and requests on the URI "http://www.example.com/CollY/bar.html" will 945 fail with a 404 (Not Found) response. 947 7. Additional Status Codes 949 7.1 208 Already Reported 951 The 208 (Already Reported) status code can be used inside a 952 DAV:propstat response element to avoid enumerating the internal 953 members of multiple bindings to the same collection repeatedly. For 954 each binding to a collection inside the request's scope, only one 955 will be reported with a 200 status, while subsequent DAV:response 956 elements for all other bindings will use the 208 status, and no 957 DAV:response elements for their descendants are included. 959 Note that the 208 status will only occur for "Depth: infinity" 960 requests, and that it is of particular importance when the multiple 961 collection bindings cause a bind loop as discussed in Section 2.2. 963 A client can request the DAV:resourceid property in a PROPFIND 964 request to guarantee that they can accurately reconstruct the binding 965 structure of a collection with multiple bindings to a single 966 resource. 968 For backward compatibility with clients not aware of the 208 status 969 code appearing in multistatus response bodies, it SHOULD NOT be used 970 unless the client has signalled support for this specification using 971 the "DAV" request header (see Section 8.2). Instead, a 506 status 972 should be returned when a binding loop is discovered. This allows 973 the server to return the 506 as the top level return status, if it 974 discovers it before it started the response, or in the middle of a 975 multistatus, if it discovers it in the middle of streaming out a 976 multistatus response. 978 7.1.1 Example: PROPFIND by bind-aware client 980 For example, consider a PROPFIND request on /Coll (bound to 981 collection C), where the members of /Coll are /Coll/Foo (bound to 982 resource R) and /Coll/Bar (bound to collection C). 984 >> Request: 986 PROPFIND /Coll/ HTTP/1.1 987 Host: www.example.com 988 Depth: infinity 989 DAV: bind 990 Content-Type: text/xml; charset="utf-8" 991 Content-Length: xxx 993 994 995 996 997 998 999 1000 >> Response: 1002 HTTP/1.1 207 Multi-Status 1003 Content-Type: text/xml; charset="utf-8" 1004 Content-Length: xxx 1006 1007 1008 1009 http://www.example.com/Coll/ 1010 1011 1012 Loop Demo 1013 1014 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1016 1017 1018 HTTP/1.1 200 OK 1019 1020 1021 1022 http://www.example.com/Coll/Foo 1023 1024 1025 Bird Inventory 1026 1027 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf9 1029 1030 1031 HTTP/1.1 200 OK 1032 1033 1034 1035 http://www.example.com/Coll/Bar 1036 1037 1038 Loop Demo 1039 1040 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8 1042 1043 1044 HTTP/1.1 208 Already Reported 1045 1046 1047 1049 7.1.2 Example: PROPFIND by non-bind-aware client 1051 In this example, the client isn't aware of the 208 status code 1052 introduced by this specification. As the "Depth: infinity" PROPFIND 1053 request would cause a loop condition, the whole request is rejected 1054 with a 506 status. 1056 >> Request: 1058 PROPFIND /Coll/ HTTP/1.1 1059 Host: www.example.com 1060 Depth: infinity 1061 Content-Type: text/xml; charset="utf-8" 1062 Content-Length: xxx 1064 1065 1066 1067 1069 >> Response: 1071 HTTP/1.1 506 Loop Detected 1073 7.2 506 Loop Detected 1075 The 506 (Loop Detected) status code indicates that the server 1076 terminated an operation because it encountered an infinite loop while 1077 processing a request with "Depth: infinity". This status indicates 1078 that the entire operation failed. 1080 8. Capability discovery 1082 8.1 OPTIONS method 1084 If the server supports bindings, it MUST return the compliance class 1085 name "bind" as a field in the "DAV" response header (see [RFC2518], 1086 section 9.1) from an OPTIONS request on any resource implemented by 1087 that server. A value of "bind" in the "DAV" header MUST indicate 1088 that the server supports all MUST level requirements and REQUIRED 1089 features specified in this document. 1091 8.2 'DAV' request header 1093 8.2.1 Generic syntax 1095 This specification introduces the 'DAV' request header that allows 1096 clients to signal compliance to specific WebDAV features. It has the 1097 same syntax as the response header defined in [RFC2518], section 9.1, 1098 but MAY be used with any method. 1100 Note that clients MUST NOT submit a specific compliance class name in 1101 the request header unless the specification defining this compliance 1102 class specifically defines its semantics for clients. 1104 Note that if a server chooses to vary the result of a request based 1105 on values in the "DAV" header, the response either MUST NOT be 1106 cacheable or the server MUST mark the response accordingly using the 1107 "Vary" header (see [RFC2616], section 14.44). 1109 8.2.2 Client compliance class 'bind' 1111 Clients SHOULD signal support for all MUST level requirements and 1112 REQUIRED features by submitting a "DAV" request header containing the 1113 compliance class name "bind". In particular, the client MUST 1114 understand the 208 status code defined in Section 7.1. 1116 9. Security Considerations 1118 This section is provided to make WebDAV implementors aware of the 1119 security implications of this protocol. 1121 All of the security considerations of HTTP/1.1 and the WebDAV 1122 Distributed Authoring Protocol specification also apply to this 1123 protocol specification. In addition, bindings introduce several new 1124 security concerns and increase the risk of some existing threats. 1125 These issues are detailed below. 1127 9.1 Privacy Concerns 1129 In a context where cross-server bindings are supported, creating 1130 bindings on a trusted server may make it possible for a hostile agent 1131 to induce users to send private information to a target on a 1132 different server. 1134 9.2 Bind Loops 1136 Although bind loops were already possible in HTTP 1.1, the 1137 introduction of the BIND method creates a new avenue for clients to 1138 create loops accidentally or maliciously. If the binding and its 1139 target are on the same server, the server may be able to detect BIND 1140 requests that would create loops. Servers are required to detect 1141 loops that are caused by bindings to collections during the 1142 processing of any requests with "Depth: infinity". 1144 9.3 Bindings, and Denial of Service 1146 Denial of service attacks were already possible by posting URIs that 1147 were intended for limited use at heavily used Web sites. The 1148 introduction of BIND creates a new avenue for similar denial of 1149 service attacks. If cross-server bindings are supported, clients can 1150 now create bindings at heavily used sites to target locations that 1151 were not designed for heavy usage. 1153 9.4 Private Locations May Be Revealed 1155 If the DAV:parent-set property is maintained on a resource, the 1156 owners of the bindings risk revealing private locations. The 1157 directory structures where bindings are located are available to 1158 anyone who has access to the DAV:parent-set property on the resource. 1159 Moving a binding may reveal its new location to anyone with access to 1160 DAV:parent-set on its resource. 1162 9.5 DAV:parent-set and Denial of Service 1164 If the server maintains the DAV:parent-set property in response to 1165 bindings created in other administrative domains, it is exposed to 1166 hostile attempts to make it devote resources to adding bindings to 1167 the list. 1169 10. Internationalization Considerations 1171 All internationalization considerations mentioned in [RFC2518] also 1172 apply to this document. 1174 11. IANA Considerations 1176 All IANA considerations mentioned in [RFC2518] also apply to this 1177 document. 1179 12. Acknowledgements 1181 This document is the collaborative product of the authors and Tyson 1182 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1183 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1184 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1185 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan 1186 Eissing, Roy Fielding, Yaron Goland, Joe Hildebrand, Fred Hitt, Alex 1187 Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, 1188 Rohit Khare, Brian Korver, Daniel LaLiberte Steve Martin, Larry 1189 Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, 1190 Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John 1191 Turner, Kevin Wiggen, and other members of the WebDAV working group. 1193 13 Normative References 1195 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1196 3", BCP 9, RFC 2026, October 1996. 1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1199 Requirement Levels", BCP 14, RFC 2119, March 1997. 1201 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1202 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1203 August 1998. 1205 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1206 Jensen, "HTTP Extensions for Distributed Authoring -- 1207 WEBDAV", RFC 2518, February 1999. 1209 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1210 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1211 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1213 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 1214 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1215 Edition)", W3C REC-xml-20040204, February 2004, 1216 . 1218 [1] 1220 [2] 1222 Authors' Addresses 1224 Geoffrey Clemm 1225 IBM 1226 20 Maguire Road 1227 Lexington, MA 02421 1229 EMail: geoffrey.clemm@us.ibm.com 1231 Jason Crawford 1232 IBM Research 1233 P.O. Box 704 1234 Yorktown Heights, NY 10598 1236 EMail: ccjason@us.ibm.com 1237 Julian F. Reschke 1238 greenbytes GmbH 1239 Salzmannstrasse 152 1240 Muenster, NW 48159 1241 Germany 1243 EMail: julian.reschke@greenbytes.de 1245 Jim Whitehead 1246 UC Santa Cruz, Dept. of Computer Science 1247 1156 High Street 1248 Santa Cruz, CA 95064 1250 EMail: ejw@cse.ucsc.edu 1252 Appendix A. Change Log (to be removed by RFC Editor before publication) 1254 A.1 Since draft-ietf-webdav-bind-02 1256 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1257 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1258 resolution, but keep it open. Add issues "ED_references" and 1259 "4_507_status". Started work on index. Rename document to "Binding 1260 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1261 Rename "References" to "Normative References". Close issue 1262 "ED_references". Close issue "4_507_status". 1264 A.2 Since draft-ietf-webdav-bind-03 1266 Add and close issues "9.2_redirect_loops", "ED_authors" and 1267 "ED_updates". Add section about capability discovery (DAV header). 1268 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1269 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1270 "locking" and resolve as invalid. 1272 A.3 Since draft-ietf-webdav-bind-04 1274 Add and close issues "6_precondition_binding_allowed" and 1275 "6_lock_behaviour". Add mailing list and issues list pointers to 1276 front. 1278 A.4 Since draft-ietf-webdav-bind-05 1280 Editorial fixes. Add and resolve issues "1.3_error_negotiation", 1281 "2.5_language" and "7.1.1_add_resource_id". Add historical issue 1282 "4_LOCK_BEHAVIOR" and it's resolution for better tracking. 1284 Appendix B. Resolved issues (to be removed by RFC Editor before 1285 publication) 1287 Issues that were either rejected or resolved in this version of this 1288 document. 1290 B.1 4_LOCK_BEHAVIOR 1292 Type: change 1294 1296 briank@xythos.com (2003-02-28): Define "Resource": The term 1297 "resource" should be defined in the draft. I imagine the definition 1298 is something along the lines of "all content and all properties 1299 associated with that content (including live and dead properties), 1300 but which does not include properties associated with URIs." Bindings 1301 and Locks: The relationship between bindings and locks is missing 1302 from the draft. I think the behavior of locks and the lock methods 1303 should be fully specified in this draft. URL Properties: The 1304 behavior of other URL properties (in addition to locks) should be 1305 fully specified, for instance the display-name property. Move and 1306 Delete: The spec states that move and delete are merely operations on 1307 bindings. At the very least, this is inconsistent with 2518, but I 1308 also think that the draft doesn't adequately address any of the 1309 issues that come up when the server goes to "reclaim system 1310 resources." I would expect most servers to reclaim said resources 1311 during move and delete. Operations not Atomic: None of the 1312 operations specified should be required to be atomic. I'd prefer 1313 SHOULD NOT myself. This is especially true for any operation that 1314 involves deleting collections. 1316 Resolution: This was closed in draft 02. Some comments: (1) It's up 1317 to RFC2396 and RFC2616 to define what a "resource" is. We don't 1318 change that here. (2) There is no such thing as URL properties. 1319 WebDAV properties are part of the state of a WebDAV/HTTP resource; 1320 and a URI by itself is not a resource. (3) Bindings vs Locks: see 1321 other issues. (4) MOVE and DELETE are allowed to work the same way 1322 as in RFC2518 (except for Delete not removing all bindings). (5) The 1323 new methods are all atomic on purpose. If a server can't implement 1324 UNBIND on collections; that is fine. It can still implement DELETE 1325 with the classic non-atomic behaviour. 1327 B.2 1.3_error_negotiation 1329 Type: change 1330 1332 joe@cursive.net (2004-06-22): Second paragraph: how might I otherwise 1333 negotiate? The DAV:bind header? 1335 Resolution: No change. Summary: this is to allow future extensions 1336 where different error marsahlling mechanisms would be used. See also 1337 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0210.html. 1339 B.3 2.5_language 1341 Type: change 1343 1345 joe@cursive.net (2004-06-22): Last paragraph is a repeat of text two 1346 paragraphs before. 1348 Resolution (2004-06-24): Just move the second sentence of the last 1349 paragraph to the end of the second paragraph, and then delete the 1350 rest of the last paragraph. 1352 B.4 7.1.1_add_resource_id 1354 Type: change 1356 1358 joe@cursive.net (2004-06-22): I think this would be clearer if it 1359 included D:resource-id in the request and response, so you could tell 1360 where the loop happened. Are resource-id's likely to be costly to 1361 return? 1363 Resolution (2004-06-23): No, they should be cheap. Update example. 1365 Appendix C. Open issues (to be removed by RFC Editor prior to 1366 publication) 1368 C.1 edit 1370 Type: edit 1372 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for 1373 editorial fixes/enhancements. 1375 Index 1377 2 1378 208 Already Reported (status code) 21 1380 5 1381 506 Loop Detected (status code) 24 1383 B 1384 BIND method 15 1386 C 1387 Condition Names 1388 DAV:bind-into-collection (pre) 16 1389 DAV:bind-source-exists (pre) 16 1390 DAV:binding-allowed (pre) 16 1391 DAV:binding-deleted (post) 18, 21 1392 DAV:can-overwrite (pre) 16, 20 1393 DAV:cross-server-binding (pre) 16, 20 1394 DAV:cycle-allowed (pre) 16, 20 1395 DAV:lock-deleted (post) 18, 21 1396 DAV:locked-overwrite-allowed (pre) 16 1397 DAV:locked-source-collection-update-allowed (pre) 20 1398 DAV:locked-update-allowed (pre) 16, 18, 20 1399 DAV:name-allowed (pre) 16, 20 1400 DAV:new-binding (post) 16, 21 1401 DAV:protected-source-url-deletion-allowed (pre) 20 1402 DAV:protected-url-deletion-allowed (pre) 18 1403 DAV:protected-url-modification-allowed (pre) 20 1404 DAV:rebind-into-collection (pre) 20 1405 DAV:rebind-source-exists (pre) 20 1406 DAV:unbind-from-collection (pre) 18 1407 DAV:unbind-source-exists (pre) 18 1409 D 1410 DAV header 1411 compliance class 'bind' 24 1412 DAV:bind-into-collection precondition 16 1413 DAV:bind-source-exists precondition 16 1414 DAV:binding-allowed precondition 16 1415 DAV:binding-deleted postcondition 18, 21 1416 DAV:can-overwrite precondition 16, 20 1417 DAV:cross-server-binding precondition 16, 20 1418 DAV:cycle-allowed precondition 16, 20 1419 DAV:lock-deleted postcondition 18, 21 1420 DAV:locked-overwrite-allowed precondition 16 1421 DAV:locked-source-collection-update-allowed precondition 20 1422 DAV:locked-update-allowed precondition 16, 18, 20 1423 DAV:name-allowed precondition 16, 20 1424 DAV:new-binding postcondition 16, 21 1425 DAV:parent-set property 14 1426 DAV:protected-source-url-deletion-allowed precondition 20 1427 DAV:protected-url-deletion-allowed precondition 18 1428 DAV:protected-url-modification-allowed precondition 20 1429 DAV:rebind-into-collection precondition 20 1430 DAV:rebind-source-exists precondition 20 1431 DAV:resource-id property 14 1432 DAV:unbind-from-collection precondition 18 1433 DAV:unbind-source-exists precondition 18 1435 M 1436 Methods 1437 BIND 15 1438 REBIND 19 1439 UNBIND 17 1441 P 1442 Properties 1443 DAV:parent-set 14 1444 DAV:resource-id 14 1446 R 1447 REBIND method 19 1449 S 1450 Status Codes 1451 208 Already Reported 21 1452 506 Loop Detected 24 1454 U 1455 UNBIND method 17 1457 Intellectual Property Statement 1459 The IETF takes no position regarding the validity or scope of any 1460 Intellectual Property Rights or other rights that might be claimed to 1461 pertain to the implementation or use of the technology described in 1462 this document or the extent to which any license under such rights 1463 might or might not be available; nor does it represent that it has 1464 made any independent effort to identify any such rights. Information 1465 on the procedures with respect to rights in RFC documents can be 1466 found in BCP 78 and BCP 79. 1468 Copies of IPR disclosures made to the IETF Secretariat and any 1469 assurances of licenses to be made available, or the result of an 1470 attempt made to obtain a general license or permission for the use of 1471 such proprietary rights by implementers or users of this 1472 specification can be obtained from the IETF on-line IPR repository at 1473 http://www.ietf.org/ipr. 1475 The IETF invites any interested party to bring to its attention any 1476 copyrights, patents or patent applications, or other proprietary 1477 rights that may cover technology that may be required to implement 1478 this standard. Please address the information to the IETF at 1479 ietf-ipr@ietf.org. 1481 Disclaimer of Validity 1483 This document and the information contained herein are provided on an 1484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1486 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1487 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1488 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1491 Copyright Statement 1493 Copyright (C) The Internet Society (2004). This document is subject 1494 to the rights, licenses and restrictions contained in BCP 78, and 1495 except as set forth therein, the authors retain all their rights. 1497 Acknowledgment 1499 Funding for the RFC Editor function is currently provided by the 1500 Internet Society.