idnits 2.17.1 draft-ietf-webdav-bind-05.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.5 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1396. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1412), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 19) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages 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 (March 23, 2004) is 7338 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 1177, 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' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: September 21, 2004 IBM Research 5 J. Reschke 6 greenbytes 7 J. Whitehead 8 U.C. Santa Cruz 9 March 23, 2004 11 Binding Extensions to Web Distributed Authoring and Versioning 12 (WebDAV) 13 draft-ietf-webdav-bind-05 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 3667. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 21, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This specification defines bindings, and the BIND method for creating 46 multiple bindings to the same resource. Creating a new binding to a 47 resource causes at least one new URI to be mapped to that resource. 48 Servers are required to insure the integrity of any bindings that 49 they allow to be created. 51 Please send comments to the Distributed Authoring and Versioning 52 (WebDAV) working group at , which may be 53 joined by sending a message with subject "subscribe" to 54 . Discussions 55 of the WEBDAV working group are archived at . 58 *(To be removed before publication as RFC): * 60 61 lists all registered issues since draft 02. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.2 Rationale for Distinguishing Bindings from URI Mappings . . 6 68 1.3 Method Preconditions and Postconditions . . . . . . . . . . 7 69 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . 7 70 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . 8 71 2.2 URI Mappings Created by a new Binding . . . . . . . . . . . 9 72 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . 10 73 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . 11 74 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . 12 75 2.6 Determining Whether Two Bindings Are to the Same Resource . 13 76 2.7 Discovering the Bindings to a Resource . . . . . . . . . . . 14 77 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . 14 79 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . 14 80 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . 15 81 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . 17 82 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . 17 83 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . 19 84 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . 19 85 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . 21 86 7. Additional Status Codes . . . . . . . . . . . . . . . . . . 21 87 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . 21 88 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . . . . 22 89 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . . . . 23 90 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . 24 91 8. Capability discovery . . . . . . . . . . . . . . . . . . . . 24 92 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . . 24 93 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . . 24 94 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . . . . 24 95 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . . . . 25 96 9. Security Considerations . . . . . . . . . . . . . . . . . . 25 97 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 25 98 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . . 25 100 9.4 Private Locations May Be Revealed . . . . . . . . . . . . . 26 101 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . 26 102 10. Internationalization Considerations . . . . . . . . . . . . 26 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 104 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 105 Normative References . . . . . . . . . . . . . . . . . . . . 26 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 107 A. Change Log (to be removed by RFC Editor before 108 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 109 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . 28 110 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . . 28 111 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . . 28 112 B. Resolved issues (to be removed by RFC Editor before 113 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 114 B.1 6_precondition_binding_allowed . . . . . . . . . . . . . . . 28 115 B.2 6_lock_behaviour . . . . . . . . . . . . . . . . . . . . . . 29 116 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 117 Intellectual Property and Copyright Statements . . . . . . . 32 119 1. Introduction 121 This specification extends the WebDAV Distributed Authoring Protocol 122 to enable clients to create new access paths to existing resources. 123 This capability is useful for several reasons: 125 URIs of WebDAV-compliant resources are hierarchical and correspond to 126 a hierarchy of collections in resource space. The WebDAV Distributed 127 Authoring Protocol makes it possible to organize these resources into 128 hierarchies, placing them into groupings, known as collections, which 129 are more easily browsed and manipulated than a single flat 130 collection. However, hierarchies require categorization decisions 131 that locate resources at a single location in the hierarchy, a 132 drawback when a resource has multiple valid categories. For example, 133 in a hierarchy of vehicle descriptions containing collections for 134 cars and boats, a description of a combination car/boat vehicle could 135 belong in either collection. Ideally, the description should be 136 accessible from both. Allowing clients to create new URIs that access 137 the existing resource lets them put that resource into multiple 138 collections. 140 Hierarchies also make resource sharing more difficult, since 141 resources that have utility across many collections are still forced 142 into a single collection. For example, the mathematics department at 143 one university might create a collection of information on fractals 144 that contains bindings to some local resources, but also provides 145 access to some resources at other universities. For many reasons, it 146 may be undesirable to make physical copies of the shared resources on 147 the local server: to conserve disk space, to respect copyright 148 constraints, or to make any changes in the shared resources visible 149 automatically. Being able to create new access paths to existing 150 resources in other collections or even on other servers is useful for 151 this sort of case. 153 The BIND method defined here provides a mechanism for allowing 154 clients to create alternative access paths to existing WebDAV 155 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to 156 work because there are mappings between URIs and resources. A method 157 is addressed to a URI, and the server follows the mapping from that 158 URI to a resource, applying the method to that resource. Multiple 159 URIs may be mapped to the same resource, but until now there has been 160 no way for clients to create additional URIs mapped to existing 161 resources. 163 BIND lets clients associate a new URI with an existing WebDAV 164 resource, and this URI can then be used to submit requests to the 165 resource. Since URIs of WebDAV resources are hierarchical, and 166 correspond to a hierarchy of collections in resource space, the BIND 167 method also has the effect of adding the resource to a collection. 168 As new URIs are associated with the resource, it appears in 169 additional collections. 171 A BIND request does not create a new resource, but simply makes 172 available a new URI for submitting requests to an existing resource. 173 The new URI is indistinguishable from any other URI when submitting a 174 request to a resource. Only one round trip is needed to submit a 175 request to the intended target. Servers are required to enforce the 176 integrity of the relationships between the new URIs and the resources 177 associated with them. Consequently, it may be very costly for 178 servers to support BIND requests that cross server boundaries. 180 This specification is organized as follows. Section 1.1 defines 181 terminology used in the rest of the specification, while Section 2 182 overviews bindings. Section 3 defines the new properties needed to 183 support multiple bindings to the same resource. Section 4 specifies 184 the BIND method, used to create multiple bindings to the same 185 resource. Section 5 specifies the UNBIND method, used to remove a 186 binding to a resource. Section 6 specifies the REBIND method, used 187 to move a binding to another collection. 189 1.1 Terminology 191 The terminology used here follows and extends that in the WebDAV 192 Distributed Authoring Protocol specification [RFC2518]. 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 This document uses XML DTD fragments ([XML]) as a purely notational 199 convention. WebDAV request and response bodies cannot be validated 200 due to the specific extensibility rules defined in section 23 of 201 [RFC2518] and due to the fact that all XML elements defined by this 202 specification use the XML namespace name "DAV:". In particular: 204 o Element names use the "DAV:" namespace. 206 o Element ordering is irrelevant. 208 o Extension elements/attributes (elements/attributes not already 209 defined as valid child elements) may be added anywhere, except 210 when explicitly stated otherwise. 212 URI Mapping 214 A relation between an absolute URI and a resource. For an 215 absolute URI U and the resource it identifies R, the URI mapping 216 can be thought of as (U => R). Since a resource can represent 217 items that are not network retrievable, as well as those that are, 218 it is possible for a resource to have zero, one, or many URI 219 mappings. Mapping a resource to an "http" scheme URI makes it 220 possible to submit HTTP protocol requests to the resource using 221 the URI. 223 Path Segment 225 Informally, the characters found between slashes ("/") in a URI. 226 Formally, as defined in section 3.3 of [RFC2396]. 228 Binding 230 A relation between a single path segment (in a collection) and a 231 resource. A binding is part of the state of a collection. If two 232 different collections contain a binding between the same path 233 segment and the same resource, these are two distinct bindings. 234 So for a collection C, a path segment S, and a resource R, the 235 binding can be thought of as C:(S -> R). Bindings create URI 236 mappings, and hence allow requests to be sent to a single resource 237 from multiple locations in a URI namespace. For example, given a 238 collection C (accessible through the URI http://www.example.com/ 239 CollX), a path segment S (equal to "foo.html"), and a resource R, 240 then creating the binding C: (S -> R) makes it possible to use the 241 URI http://www.example.com/CollX/foo.html to access R. 243 Collection 245 A resource that contains, as part of its state, a set of bindings 246 that identify internal member resources. 248 Internal Member URI 250 The URI that identifies an internal member of a collection, and 251 that consists of the URI for the collection, followed by a slash 252 character ('/'), followed by the path segment of the binding for 253 that internal member. 255 1.2 Rationale for Distinguishing Bindings from URI Mappings 257 In [RFC2518], the state of a collection is defined as containing a 258 list of internal member URIs. If there are multiple mappings to a 259 collection, then the state of the collection is different when you 260 refer to it via a different URI. This is undesirable, since ideally a 261 collection's membership should remain the same, independent of which 262 URI was used to reference it. 264 The notion of binding is introduced to separate the final segment of 265 a URI from its parent collection's contribution. This done, a 266 collection can be defined as containing a set of bindings, thus 267 permitting new mappings to a collection without modifying its 268 membership. The authors of this specification anticipate and 269 recommend that future revisions of [RFC2518] will update the 270 definition of the state of a collection to correspond to the 271 definition in this document. 273 1.3 Method Preconditions and Postconditions 275 A "precondition" of a method describes the state on the server that 276 must be true for that method to be performed. A "postcondition" of a 277 method describes the state on the server that must be true after that 278 method has completed. If a method precondition or postcondition for 279 a request is not satisfied, the response status of the request MUST 280 be either 403 (Forbidden) if the request should not be repeated 281 because it will always fail, or 409 (Conflict) if it is expected that 282 the user might be able to resolve the conflict and resubmit the 283 request. 285 In order to allow better client handling of 403 and 409 responses, a 286 distinct XML element type is associated with each method precondition 287 and postcondition of a request. When a particular precondition is 288 not satisfied or a particular postcondition cannot be achieved, the 289 appropriate XML element MUST be returned as the child of a top-level 290 DAV:error element in the response body, unless otherwise negotiated 291 by the request. In a 207 Multi-Status response, the DAV:error 292 element would appear in the appropriate DAV:responsedescription 293 element. 295 2. Overview of Bindings 297 Bindings are part of the state of a collection. They define the 298 internal members of the collection, and the names of those internal 299 members. 301 Bindings are added and removed by a variety of existing HTTP methods. 302 A method that creates a new resource, such as PUT, COPY, and MKCOL, 303 adds a binding. A method that deletes a resource, such as DELETE, 304 removes a binding. A method that moves a resource (e.g. MOVE) both 305 adds a binding (in the destination collection) and removes a binding 306 (in the source collection). The BIND method introduced here provides 307 a mechanism for adding a second binding to an existing resource. 308 There is no difference between an initial binding added by PUT, COPY, 309 or MKCOL, and additional bindings added with BIND. 311 It would be very undesirable if one binding could be destroyed as a 312 side effect of operating on the resource through a different binding. 313 In particular, the removal of one binding to a resource (e.g. with a 314 DELETE or a MOVE) MUST NOT disrupt another binding to that resource, 315 e.g. by turning that binding into a dangling path segment. The 316 server MUST NOT reclaim system resources after removing one binding, 317 while other bindings to the resource remain. In other words, the 318 server MUST maintain the integrity of a binding. 320 2.1 Bindings to Collections 322 Bindings to collections can result in loops, which servers MUST 323 detect when processing "Depth: infinity" requests. It is sometimes 324 possible to complete an operation in spite of the presence of a loop. 325 However, the 506 (Loop Detected) status code is defined in Section 7 326 for use in contexts where an operation is terminated because a loop 327 was encountered. 329 Creating a new binding to a collection makes each resource associated 330 with a binding in that collection accessible via a new URI, and thus 331 creates new URI mappings to those resources but no new bindings. 333 For example, suppose a new binding CollY is created for collection C1 334 in the figure below. It immediately becomes possible to access 335 resource R1 using the URI /CollY/x.gif and to access resource R2 336 using the URI /CollY/y.jpg, but no new bindings for these child 337 resources were created. This is because bindings are part of the 338 state of a collection, and associate a URI that is relative to that 339 collection with its target resource. No change to the bindings in 340 Collection C1 is needed to make its children accessible using /CollY/ 341 x.gif and /CollY/y.jpg. 343 +-------------------------+ 344 | Root Collection | 345 | bindings: | 346 | CollX CollY | 347 +-------------------------+ 348 | / 349 | / 350 | / 351 +------------------+ 352 | Collection C1 | 353 | bindings: | 354 | x.gif y.jpg | 355 +------------------+ 356 | \ 357 | \ 358 | \ 359 +-------------+ +-------------+ 360 | Resource R1 | | Resource R2 | 361 +-------------+ +-------------+ 363 2.2 URI Mappings Created by a new Binding 365 Suppose a binding from "Binding-Name" to resource R to be added to a 366 collection, C. Then if C-MAP is the set of URIs that were mapped to 367 C before the BIND request, then for each URI "C-URI" in C-MAP, the 368 URI "C-URI/Binding-Name" is mapped to resource R following the BIND 369 request. 371 For example, if a binding from "foo.html" to R is added to a 372 collection C, and if the following URIs are mapped to C: 374 http://www.example.com/A/1/ 375 http://example.com/A/one/ 377 then the following new mappings to R are introduced: 379 http://www.example.com/A/1/foo.html 380 http://example.com/A/one/foo.html 382 Note that if R is a collection, additional URI mappings are created 383 to the descendents of R. Also, note that if a binding is made in 384 collection C to C itself (or to a parent of C), an infinite number of 385 mappings are introduced. 387 For example, if a binding from "myself" to C is then added to C, the 388 following infinite number of additional mappings to C are introduced: 390 http://www.example.com/A/1/myself 391 http://www.example.com/A/1/myself/myself 392 ... 394 and the following infinite number of additional mappings to R are 395 introduced: 397 http://www.example.com/A/1/myself/foo.html 398 http://www.example.com/A/1/myself/myself/foo.html 399 ... 401 2.3 COPY and Bindings 403 As defined in Section 8.8 of [RFC2518], COPY causes the resource 404 identified by the Request-URI to be duplicated, and makes the new 405 resource accessible using the URI specified in the Destination 406 header. Upon successful completion of a COPY, a new binding is 407 created between the last path segment of the Destination header, and 408 the destination resource. The new binding is added to its parent 409 collection, identified by the Destination header minus its final 410 segment. 412 The following figure shows an example: Suppose that a COPY is issued 413 to URI-3 for resource R (which is also mapped to URI-1 and URI-2), 414 with the Destination header set to URI-X. After successful 415 completion of the COPY operation, resource R is duplicated to create 416 resource R', and a new binding has been created which creates at 417 least the URI mapping between URI-X and the new resource (although 418 other URI mappings may also have been created). 420 URI-1 URI-2 URI-3 URI-X 421 | | | | 422 | | | <---- URI Mappings ----> | 423 | | | | 424 +---------------------+ +------------------------+ 425 | Resource R | | Resource R' | 426 +---------------------+ +------------------------+ 428 It might be thought that a COPY request with "Depth: 0" on a 429 collection would duplicate its bindings, since bindings are part of 430 the collection's state. This is not the case, however. The 431 definition of Depth in [RFC2518] makes it clear that a "Depth: 0" 432 request does not apply to a collection's members. Consequently, a 433 COPY with "Depth: 0" does not duplicate the bindings contained by the 434 collection. 436 If a COPY request causes an existing resource to be updated, the 437 bindings to that resource MUST be unaffected by the COPY request. 438 Using the preceding example, suppose that a COPY request is issued to 439 URI-X for resource R', with the Destination header set to URI-2. The 440 content and dead properties of resource R would be updated to be a 441 copy of those of resource R', but the mappings from URI-1, URI-2, and 442 URI-3 to resource R remain unaffected. If because of multiple 443 bindings to a resource, more than one source resource updates a 444 single destination resource, the order of the updates is server 445 defined. 447 If a COPY request would cause a new resource to be created as a copy 448 of an existing resource, and that COPY request has already created a 449 copy of that existing resource, the COPY request instead creates 450 another binding to the previous copy, instead of creating a new 451 resource. 453 2.4 DELETE and Bindings 455 When there are multiple bindings to a resource, a DELETE applied to 456 that resource MUST NOT remove any bindings to that resource other 457 than the one identified by the request URI. For example, suppose the 458 collection identified by the URI "/a" has a binding named "x" to a 459 resource R, and another collection identified by "/b" has a binding 460 named "y" to the same resource R. Then a DELETE applied to "/a/x" 461 removes the binding named "x" from "/a" but MUST NOT remove the 462 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues 463 to identify the resource R). In particular, although Section 8.6.1 464 of [RFC2518] states that during DELETE processing, a server "MUST 465 remove any URI for the resource identified by the Request-URI from 466 collections which contain it as a member", a server that supports the 467 binding protocol MUST NOT follow this requirement. 469 When DELETE is applied to a collection, it MUST NOT modify the 470 membership of any other collection that is not itself a member of the 471 collection being deleted. For example, if both "/a/.../x" and "/b/ 472 .../y" identify the same collection, C, then applying DELETE to "/a" 473 MUST NOT delete an internal member from C or from any other 474 collection that is a member of C, because that would modify the 475 membership of "/b". 477 If a collection supports the UNBIND method (see Section 5), a DELETE 478 of an internal member of a collection MAY be implemented as an UNBIND 479 request. In this case, applying DELETE to a Request-URI has the 480 effect of removing the binding identified by the final segment of the 481 Request-URI from the collection identified by the Request-URI minus 482 its final segment. Although [RFC2518] allows a DELETE to be a 483 non-atomic operation, when the DELETE operation is implemented as an 484 UNBIND, the operation is atomic. In particular, a DELETE on a 485 hierarchy of resources is simply the removal of a binding to the 486 collection identified by the Request-URI. 488 2.5 MOVE and Bindings 490 When MOVE is applied to a resource, the other bindings to that 491 resource MUST be unaffected, and if the resource being moved is a 492 collection, the bindings to any members of that collection MUST be 493 unaffected. Also, if MOVE is used with Overwrite:T to delete an 494 existing resource, the constraints specified for DELETE apply. 496 If the destination collection of a MOVE request supports the REBIND 497 method (see Section 6), a MOVE of a resource into that collection MAY 498 be implemented as a REBIND request. Although [RFC2518] allows a MOVE 499 to be a non-atomic operation, when the MOVE operation is implemented 500 as a REBIND, the operation is atomic. In particular, applying a MOVE 501 to a Request-URI and a Destination URI has the effect of removing a 502 binding to a resource (at the Request-URI), and creating a new 503 binding to that resource (at the Destination URI). 505 As an example, suppose that a MOVE is issued to URI-3 for resource R 506 below (which is also mapped to URI-1 and URI-2), with the Destination 507 header set to URI-X. After successful completion of the MOVE 508 operation, a new binding has been created which creates the URI 509 mapping between URI-X and resource R. The binding corresponding to 510 the final segment of URI-3 has been removed, which also causes the 511 URI mapping between URI-3 and R to be removed. If resource R were a 512 collection, old URI-3 based mappings to members of R would have been 513 removed, and new URI-X based mappings to members of R would have been 514 created. 516 >> Before Request: 518 URI-1 URI-2 URI-3 519 | | | 520 | | | <---- URI Mappings 521 | | | 522 +---------------------+ 523 | Resource R | 524 +---------------------+ 525 >> After Request: 527 URI-1 URI-2 URI-X 528 | | | 529 | | | <---- URI Mappings 530 | | | 531 +---------------------+ 532 | Resource R | 533 +---------------------+ 535 Although [RFC2518] allows a MOVE on a collection to be a non-atomic 536 operation, a MOVE implemented as a REBIND MUST be atomic. Even when 537 the Request-URI identifies a collection, the MOVE operation involves 538 only removing one binding to that collection and adding another. 539 There are no operations on bindings to any of its children, so the 540 case of MOVE on a collection is the same as the case of MOVE on a 541 non-collection resource. Both are atomic. 543 2.6 Determining Whether Two Bindings Are to the Same Resource 545 It is useful to have some way of determining whether two bindings are 546 to the same resource. Two resources might have identical contents 547 and properties, but not be the same resource (e.g. an update to one 548 resource does not affect the other resource). 550 The REQUIRED DAV:resource-id property defined in Section 3.1 is a 551 resource identifier, which MUST be unique across all resources for 552 all time. If the values of DAV:resource-id returned by PROPFIND 553 requests through two bindings are identical, the client can be 554 assured that the two bindings are to the same resource. 556 The DAV:resource-id property is created, and its value assigned, when 557 the resource is created. The value of DAV:resource-id MUST NOT be 558 changed. Even after the resource is no longer accessible through any 559 URI, that value MUST NOT be reassigned to another resource's 560 DAV:resource-id property. 562 Any method that creates a new resource MUST assign a new, unique 563 value to its DAV:resource-id property. For example, a PUT or a COPY 564 that creates a new resource must assign a new, unique value to the 565 DAV:resource-id property of that new resource. 567 On the other hand, any method that affects an existing resource MUST 568 NOT change the value of its DAV:resource-id property. For example, a 569 PUT or a COPY that updates an existing resource must not change the 570 value of its DAV:resource-id property. A MOVE, since it does not 571 create a new resource, but only changes the location of an existing 572 resource, must not change the value of the DAV:resource-id property. 574 2.7 Discovering the Bindings to a Resource 576 An OPTIONAL DAV:parent-set property on a resource provides a list of 577 the bindings that associate a collection and a URI segment with that 578 resource. If the DAV:parent-set property exists on a given resource, 579 it MUST contain a complete list of all bindings to that resource that 580 the client is authorized to see. When deciding whether to support 581 the DAV:parent-set property, server implementers / administrators 582 should balance the benefits it provides against the cost of 583 maintaining the property and the security risks enumerated in 584 Sections 8.4 and 8.5. 586 3. Properties 588 The bind feature introduces the following properties for a resource. 590 A DAV:allprop PROPFIND request SHOULD NOT return any of the 591 properties defined by this document. This allows a binding server to 592 perform efficiently when a naive client, which does not understand 593 the cost of asking a server to compute all possible live properties, 594 issues a DAV:allprop PROPFIND request. 596 3.1 DAV:resource-id Property 598 The DAV:resource-id property is a REQUIRED property that enables 599 clients to determine whether two bindings are to the same resource. 600 The value of DAV:resource-id is a URI, and may use any registered URI 601 scheme that guarantees the uniqueness of the value across all 602 resources for all time (e.g. the opaquelocktoken: scheme defined in 603 [RFC2518]). 605 607 3.2 DAV:parent-set Property 609 The DAV:parent-set property is an OPTIONAL property that enables 610 clients to discover what collections contain a binding to this 611 resource (i.e. what collections have that resource as an internal 612 member). It contains an of href/segment pair for each collection 613 that has a binding to the resource. The href identifies the 614 collection, and the segment identifies the binding name of that 615 resource in that collection. 617 A given collection MUST appear only once in the DAV:parent-set for 618 any given binding, even if there are multiple URI mappings to that 619 collection. For example, if collection C1 is mapped to both /CollX 620 and /CollY, and C1 contains a binding named "x.gif" to a resource R1, 621 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the 622 DAV:parent-set of R1, but not both. But if C1 also had a binding 623 named "y.gif" to R1, then there would be two entries for C1 in the 624 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX, 625 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]). 627 628 629 630 PCDATA value: segment, as defined in section 3.3 of [RFC2396] 632 4. BIND Method 634 The BIND method modifies the collection identified by the 635 Request-URI, by adding a new binding from the segment specified in 636 the BIND body to the resource identified in the BIND body. 638 If a server cannot guarantee the integrity of the binding, the BIND 639 request MUST fail. Note that it is especially difficult to maintain 640 the integrity of cross-server bindings. Unless the server where the 641 resource resides knows about all bindings on all servers to that 642 resource, it may unwittingly destroy the resource or make it 643 inaccessible without notifying another server that manages a binding 644 to the resource. For example, if server A permits creation of a 645 binding to a resource on server B, server A must notify server B 646 about its binding and must have an agreement with B that B will not 647 destroy the resource while A's binding exists. Otherwise server B 648 may receive a DELETE request that it thinks removes the last binding 649 to the resource and destroy the resource while A's binding still 650 exists. The precondition DAV:cross-server-binding is defined below 651 for cases where servers fail cross-server BIND requests because they 652 cannot guarantee the integrity of cross-server bindings. 654 By default, if there already is a binding for the specified segment 655 in the collection, the new binding replaces the existing binding. 656 This default binding replacement behavior can be overridden using the 657 Overwrite header defined in Section 9.6 of [RFC2518]. 659 Marshalling: 661 The request MAY include an Overwrite header. 663 The request body MUST be a DAV:bind XML element. 665 666 If the request succeeds, the server MUST return 201 (Created) when 667 a new binding was created and 200 (OK) when an existing binding 668 was replaced. 670 If a response body for a successful request is included, it MUST 671 be a DAV:bind-response XML element. Note that this document does 672 not define any elements for the BIND response body, but the 673 DAV:bind-response element is defined to ensure interoperability 674 between future extensions that do define elements for the BIND 675 response body. 677 679 Preconditions: 681 (DAV:bind-into-collection): The Request-URI MUST identify a 682 collection. 684 (DAV:bind-source-exists): The DAV:href element MUST identify a 685 resource. 687 (DAV:binding-allowed): The resource identified by the DAV:href 688 supports multiple bindings to it. 690 (DAV:cross-server-binding): If the resource identified by the 691 DAV:href element in the request body is on another server from the 692 collection identified by the request-URI, the server MUST support 693 cross-server bindings. 695 (DAV:name-allowed): The name specified by the DAV:segment is 696 available for use as a new binding name. 698 (DAV:can-overwrite): If the collection already contains a binding 699 with the specified path segment, and if an Overwrite header is 700 included, the value of the Overwrite header MUST be "T". 702 (DAV:cycle-allowed): If the DAV:href element identifies a 703 collection, and if the request-URI identifies a collection that is 704 a member of that collection, the server MUST support cycles in the 705 URI namespace. 707 (DAV:locked-update-allowed): If the collection identified by the 708 Request-URI is write-locked, then the appropriate token MUST be 709 specified in an If request header. 711 (DAV:locked-overwrite-allowed): If the collection already contains 712 a binding with the specified path segment, and if that binding is 713 protected by a write-lock, then the appropriate token MUST be 714 specified in an If request header. 716 Postconditions: 718 (DAV:new-binding): The collection MUST have a binding that maps 719 the segment specified in the DAV:segment element in the request 720 body, to the resource identified by the DAV:href element in the 721 request body. 723 4.1 Example: BIND 725 >> Request: 727 BIND /CollY HTTP/1.1 728 Host: www.example.com 729 Content-Type: text/xml; charset="utf-8" 730 Content-Length: xxx 732 733 734 bar.html 735 http://www.example.com/CollX/foo.html 736 738 >> Response: 740 HTTP/1.1 201 Created 742 The server added a new binding to the collection, "http:// 743 www.example.com/CollY", associating "bar.html" with the resource 744 identified by the URI "http://www.example.com/CollX/foo.html". 745 Clients can now use the URI "http://www.example.com/CollY/bar.html", 746 to submit requests to that resource. 748 5. UNBIND Method 750 The UNBIND method modifies the collection identified by the 751 Request-URI, by removing the binding identified by the segment 752 specified in the UNBIND body. 754 Once a resource is unreachable by any URI mapping, the server MAY 755 reclaim system resources associated with that resource. If UNBIND 756 removes a binding to a resource, but there remain URI mappings to 757 that resource, the server MUST NOT reclaim system resources 758 associated with the resource. 760 Marshalling: 762 The request body MUST be a DAV:unbind XML element. 764 766 If the request succeeds, the server MUST return 200 (OK) when the 767 binding was successfully deleted. 769 If a response body for a successful request is included, it MUST 770 be a DAV:unbind-response XML element. Note that this document 771 does not define any elements for the UNBIND response body, but the 772 DAV:unbind-response element is defined to ensure interoperability 773 between future extensions that do define elements for the UNBIND 774 response body. 776 778 Preconditions: 780 (DAV:unbind-from-collection): The Request-URI MUST identify a 781 collection. 783 (DAV:unbind-source-exists): The DAV:segment element MUST identify 784 a binding in the collection identified by the Request-URI. 786 (DAV:locked-update-allowed): If the collection identified by the 787 Request-URI is write-locked, then the appropriate token MUST be 788 specified in the request. 790 (DAV:protected-url-deletion-allowed): If the binding identified by 791 the segment is protected by a write-lock, then the appropriate 792 token MUST be specified in the request. 794 Postconditions: 796 (DAV:binding-deleted): The collection MUST NOT have a binding for 797 the segment specified in the DAV:segment element in the request 798 body. 800 (DAV:lock-deleted): If the internal member URI of the binding 801 specified by the Request-URI and the DAV:segment element in the 802 request body was protected by a write-lock at the time of the 803 request, that write-lock must have been deleted by the request. 805 5.1 Example: UNBIND 807 >> Request: 809 UNBIND /CollX HTTP/1.1 810 Host: www.example.com 811 Content-Type: text/xml; charset="utf-8" 812 Content-Length: xxx 814 815 816 foo.html 817 819 >> Response: 821 HTTP/1.1 200 OK 823 The server removed the binding named "foo.html" from the collection, 824 "http://www.example.com/CollX". A request to the resource named 825 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found) 826 response. 828 6. REBIND Method 830 The REBIND method removes a binding to a resource from one 831 collection, and adds a binding to that resource into another 832 collection. It is effectively an atomic form of a MOVE request. 834 Marshalling: 836 The request MAY include an Overwrite header. 838 The request body MUST be a DAV:rebind XML element. 840 842 If the request succeeds, the server MUST return 201 (Created) when 843 a new binding was created and 200 (OK) when an existing binding 844 was replaced. 846 If a response body for a successful request is included, it MUST 847 be a DAV:rebind-response XML element. Note that this document 848 does not define any elements for the REBIND response body, but the 849 DAV:rebind-response element is defined to ensure interoperability 850 between future extensions that do define elements for the REBIND 851 response body. 853 855 Preconditions: 857 (DAV:rebind-into-collection): The Request-URI MUST identify a 858 collection. 860 (DAV:rebind-source-exists): The DAV:href element MUST identify a 861 resource. 863 (DAV:cross-server-binding): If the resource identified by the 864 DAV:href element in the request body is on another server from the 865 collection identified by the request-URI, the server MUST support 866 cross-server bindings. 868 (DAV:name-allowed): The name specified by the DAV:segment is 869 available for use as a new binding name. 871 (DAV:can-overwrite): If the collection already contains a binding 872 with the specified path segment, and if an Overwrite header is 873 included, the value of the Overwrite header MUST be "T". 875 (DAV:cycle-allowed): If the DAV:href element identifies a 876 collection, and if the request-URI identifies a collection that is 877 a member of that collection, the server MUST support cycles in the 878 URI namespace. 880 (DAV:locked-update-allowed): If the collection identified by the 881 Request-URI is write-locked, then the appropriate token MUST be 882 specified in the request. 884 (DAV:protected-url-modification-allowed): If the collection 885 identified by the Request-URI already contains a binding with the 886 specified path segment, and if that binding is protected by a 887 write-lock, then the appropriate token MUST be specified in the 888 request. 890 (DAV:locked-source-collection-update-allowed): If the collection 891 identified by the parent collection prefix of the DAV:href URI is 892 write-locked, then the appropriate token MUST be specified in the 893 request. 895 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI 896 is protected by a write lock, then the appropriate token MUST be 897 specified in the request. 899 Postconditions: 901 (DAV:new-binding): The collection MUST have a binding that maps 902 the segment specified in the DAV:segment element in the request 903 body, to the resource that was identified by the DAV:href element 904 in the request body. 906 (DAV:binding-deleted): The URL specified in the DAV:href element 907 in the request body MUST NOT be mapped to a resource. 909 (DAV:lock-deleted): If the URL specified in the DAV:href element 910 in the request body was protected by a write-lock at the time of 911 the request, that write-lock must have been deleted by the 912 request. 914 6.1 Example: REBIND 916 >> Request: 918 REBIND /CollX HTTP/1.1 919 Host: www.example.com 920 Content-Type: text/xml; charset="utf-8" 921 Content-Length: xxx 923 924 925 foo.html 926 http://www.example.com/CollY/bar.html 927 929 >> Response: 931 HTTP/1.1 200 OK 933 The server added a new binding to the collection, "http:// 934 www.example.com/CollX", associating "foo.html" with the resource 935 identified by the URI "http://www.example.com/CollY/bar.html", and 936 removes the binding named "bar.html" from the collection identified 937 by the URI "http://www.example.com/CollY". Clients can now use the 938 URI "http://www.example.com/CollX/foo.html" to submit requests to 939 that resource, and requests on the URI "http://www.example.com/CollY/ 940 bar.html" will fail with a 404 (Not Found) response. 942 7. Additional Status Codes 944 7.1 208 Already Reported 946 The 208 (Already Reported) status code can be used inside a 947 DAV:propstat response element to avoid enumerating the internal 948 members of multiple bindings to the same collection repeatedly. For 949 each binding to a collection inside the request's scope, only one 950 will be reported with a 200 status, while subsequent DAV:response 951 elements for all other bindings will use the 208 status, and no 952 DAV:response elements for their descendants are included. 954 Note that the 208 status will only occur for "Depth: infinity" 955 requests, and that it is of particular importance when the multiple 956 collection bindings cause a bind loop as discussed in Section 2.2. 958 A client can request the DAV:resourceid property in a PROPFIND 959 request to guarantee that they can accurately reconstruct the binding 960 structure of a collection with multiple bindings to a single 961 resource. 963 For backward compatibility with clients not aware of the 208 status 964 code appearing in multistatus response bodies, it SHOULD NOT be used 965 unless the client has signalled support for this specification using 966 the "DAV" request header (see Section 8.2). Instead, a 506 status 967 should be returned when a binding loop is discovered. This allows the 968 server to return the 506 as the top level return status, if it 969 discovers it before it started the response, or in the middle of a 970 multistatus, if it discovers it in the middle of streaming out a 971 multistatus response. 973 7.1.1 Example: PROPFIND by bind-aware client 975 For example, consider a PROPFIND request on /Coll (bound to 976 collection C), where the members of /Coll are /Coll/Foo (bound to 977 resource R) and /Coll/Bar (bound to collection C). 979 >> Request: 981 PROPFIND /Coll/ HTTP/1.1 982 Host: www.example.com 983 Depth: infinity 984 DAV: bind 985 Content-Type: text/xml; charset="utf-8" 986 Content-Length: xxx 988 989 990 991 992 993 994 >> Response: 996 HTTP/1.1 207 Multi-Status 997 Content-Type: text/xml; charset="utf-8" 998 Content-Length: xxx 1000 1001 1002 1003 http://www.example.com/Coll/ 1004 1005 1006 Loop Demo 1007 1008 HTTP/1.1 200 OK 1009 1010 1011 1012 http://www.example.com/Coll/Foo 1013 1014 1015 Bird Inventory 1016 1017 HTTP/1.1 200 OK 1018 1019 1020 1021 http://www.example.com/Coll/Bar 1022 1023 1024 Loop Demo 1025 1026 HTTP/1.1 208 Already Reported 1027 1028 1029 1031 7.1.2 Example: PROPFIND by non-bind-aware client 1033 In this example, the client isn't aware of the 208 status code 1034 introduced by this specification. As the "Depth: infinity" PROPFIND 1035 request would cause a loop condition, the whole request is rejected 1036 with a 506 status. 1038 >> Request: 1040 PROPFIND /Coll/ HTTP/1.1 1041 Host: www.example.com 1042 Depth: infinity 1043 Content-Type: text/xml; charset="utf-8" 1044 Content-Length: xxx 1046 1047 1048 1049 1051 >> Response: 1053 HTTP/1.1 506 Loop Detected 1055 7.2 506 Loop Detected 1057 The 506 (Loop Detected) status code indicates that the server 1058 terminated an operation because it encountered an infinite loop while 1059 processing a request with "Depth: infinity". This status indicates 1060 that the entire operation failed. 1062 8. Capability discovery 1064 8.1 OPTIONS method 1066 If the server supports bindings, it MUST return the compliance class 1067 name "bind" as a field in the "DAV" response header (see [RFC2518], 1068 section 9.1) from an OPTIONS request on any resource implemented by 1069 that server. A value of "bind" in the "DAV" header MUST indicate that 1070 the server supports all MUST level requirements and REQUIRED features 1071 specified in this document. 1073 8.2 'DAV' request header 1075 8.2.1 Generic syntax 1077 This specification introduces the 'DAV' request header that allows 1078 clients to signal compliance to specific WebDAV features. It has the 1079 same syntax as the response header defined in [RFC2518], section 9.1, 1080 but MAY be used with any method. 1082 Note that clients MUST NOT submit a specific compliance class name in 1083 the request header unless the specification defining this compliance 1084 class specifically defines it's semantics for clients. 1086 Note that if a server chooses to vary the result of a request based 1087 on values in the "DAV" header, the response either MUST NOT be 1088 cacheable or the server MUST mark the response accordingly using the 1089 "Vary" header (see [RFC2616], section 14.44). 1091 8.2.2 Client compliance class 'bind' 1093 Clients SHOULD signal support for all MUST level requirements and 1094 REQUIRED features by submitting a "DAV" request header containing the 1095 compliance class name "bind". In particular, the client MUST 1096 understand the 208 status code defined in Section 7.1. 1098 9. Security Considerations 1100 This section is provided to make WebDAV implementors aware of the 1101 security implications of this protocol. 1103 All of the security considerations of HTTP/1.1 and the WebDAV 1104 Distributed Authoring Protocol specification also apply to this 1105 protocol specification. In addition, bindings introduce several new 1106 security concerns and increase the risk of some existing threats. 1107 These issues are detailed below. 1109 9.1 Privacy Concerns 1111 In a context where cross-server bindings are supported, creating 1112 bindings on a trusted server may make it possible for a hostile agent 1113 to induce users to send private information to a target on a 1114 different server. 1116 9.2 Bind Loops 1118 Although bind loops were already possible in HTTP 1.1, the 1119 introduction of the BIND method creates a new avenue for clients to 1120 create loops accidentally or maliciously. If the binding and its 1121 target are on the same server, the server may be able to detect BIND 1122 requests that would create loops. Servers are required to detect 1123 loops that are caused by bindings to collections during the 1124 processing of any requests with "Depth: infinity". 1126 9.3 Bindings, and Denial of Service 1128 Denial of service attacks were already possible by posting URIs that 1129 were intended for limited use at heavily used Web sites. The 1130 introduction of BIND creates a new avenue for similar denial of 1131 service attacks. If cross-server bindings are supported, clients can 1132 now create bindings at heavily used sites to target locations that 1133 were not designed for heavy usage. 1135 9.4 Private Locations May Be Revealed 1137 If the DAV:parent-set property is maintained on a resource, the 1138 owners of the bindings risk revealing private locations. The 1139 directory structures where bindings are located are available to 1140 anyone who has access to the DAV:parent-set property on the resource. 1141 Moving a binding may reveal its new location to anyone with access to 1142 DAV:parent-set on its resource. 1144 9.5 DAV:parent-set and Denial of Service 1146 If the server maintains the DAV:parent-set property in response to 1147 bindings created in other administrative domains, it is exposed to 1148 hostile attempts to make it devote resources to adding bindings to 1149 the list. 1151 10. Internationalization Considerations 1153 All internationalization considerations mentioned in [RFC2518] also 1154 apply to this document. 1156 11. IANA Considerations 1158 All IANA considerations mentioned in [RFC2518] also apply to this 1159 document. 1161 12. Acknowledgements 1163 This draft is the collaborative product of the authors and Tyson 1164 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has 1165 benefited from thoughtful discussion by Jim Amsden, Peter Carlson, 1166 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, 1167 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan 1168 Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James 1169 Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, 1170 Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, 1171 Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick 1172 Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and 1173 other members of the WebDAV working group. 1175 Normative References 1177 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1178 3", BCP 9, RFC 2026, October 1996. 1180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1181 Requirement Levels", BCP 14, RFC 2119, March 1997. 1183 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1184 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1185 August 1998. 1187 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1188 Jensen, "HTTP Extensions for Distributed Authoring -- 1189 WEBDAV", RFC 2518, February 1999. 1191 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1192 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1193 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1195 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and 1196 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 1197 Edition)", W3C REC-xml-20040204, February 2004, . 1200 Authors' Addresses 1202 Geoffrey Clemm 1203 IBM 1204 20 Maguire Road 1205 Lexington, MA 02421 1207 EMail: geoffrey.clemm@us.ibm.com 1209 Jason Crawford 1210 IBM Research 1211 P.O. Box 704 1212 Yorktown Heights, NY 10598 1214 EMail: ccjason@us.ibm.com 1216 Julian F. Reschke 1217 greenbytes GmbH 1218 Salzmannstrasse 152 1219 Muenster, NW 48159 1220 Germany 1222 EMail: julian.reschke@greenbytes.de 1223 Jim Whitehead 1224 UC Santa Cruz, Dept. of Computer Science 1225 1156 High Street 1226 Santa Cruz, CA 95064 1228 EMail: ejw@cse.ucsc.edu 1230 Appendix A. Change Log (to be removed by RFC Editor before publication) 1232 A.1 Since draft-ietf-webdav-bind-02 1234 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and 1235 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed 1236 resolution, but keep it open. Add issues "ED_references" and 1237 "4_507_status". Started work on index. Rename document to "Binding 1238 Extensions to Web Distributed Authoring and Versioning (WebDAV)". 1239 Rename "References" to "Normative References". Close issue 1240 "ED_references". CLose issue "4_507_status". 1242 A.2 Since draft-ietf-webdav-bind-03 1244 Add and close issues "9.2_redirect_loops", "ED_authors" and 1245 "ED_updates". Add section about capability discovery (DAV header). 1246 Close issues "5.1_LOOP_STATUS". Add and resolve new issue 1247 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue 1248 "locking" and resolve as invalid. 1250 A.3 Since draft-ietf-webdav-bind-04 1252 Add and close issues "6_precondition_binding_allowed" and 1253 "6_lock_behaviour". Add mailing list and issues list pointers to 1254 front. 1256 Appendix B. Resolved issues (to be removed by RFC Editor before 1257 publication) 1259 Issues that were either rejected or resolved in this version of this 1260 document. 1262 B.1 6_precondition_binding_allowed 1264 Type: change 1266 1269 lisa@osafoundation.org (2004-03-17): One precondition is " 1270 (DAV:binding-allowed): The resource identified by the DAV:href 1271 supports multiple bindings to it." How can this error possibly 1272 occur? 1274 Resolution (2004-03-19): Cut & Paste error (copied from BIND method). 1275 Remove it. 1277 B.2 6_lock_behaviour 1279 Type: change 1281 1284 lisa@osafoundation.org (2004-03-17): Does REBIND destroy locks, as 1285 MOVE does? It shouldn't, unless there's a compelling reason for 1286 backward compatibility. 1288 Resolution (2004-03-20): REBIND behaves like MOVE (and any other 1289 namespace operation), thus locks are destroyed. Add postcondition 1290 DAV:lock-deleted. 1292 Index 1294 2 1295 208 Already Reported (status code) 21 1297 5 1298 506 Loop Detected (status code) 24 1300 B 1301 BIND method 15 1303 C 1304 Condition Names 1305 DAV:bind-into-collection (pre) 16 1306 DAV:bind-source-exists (pre) 16 1307 DAV:binding-allowed (pre) 16 1308 DAV:binding-deleted (post) 18, 21 1309 DAV:can-overwrite (pre) 16, 20 1310 DAV:cross-server-binding (pre) 16, 20 1311 DAV:cycle-allowed (pre) 16, 20 1312 DAV:lock-deleted (post) 18, 21 1313 DAV:locked-overwrite-allowed (pre) 16 1314 DAV:locked-source-collection-update-allowed (pre) 20 1315 DAV:locked-update-allowed (pre) 16, 18, 20 1316 DAV:name-allowed (pre) 16, 20 1317 DAV:new-binding (post) 17, 21 1318 DAV:protected-source-url-deletion-allowed (pre) 20 1319 DAV:protected-url-deletion-allowed (pre) 18 1320 DAV:protected-url-modification-allowed (pre) 20 1321 DAV:rebind-into-collection (pre) 20 1322 DAV:rebind-source-exists (pre) 20 1323 DAV:unbind-from-collection (pre) 18 1324 DAV:unbind-source-exists (pre) 18 1326 D 1327 DAV header 1328 compliance class 'bind' 24 1329 DAV:bind-into-collection precondition 16 1330 DAV:bind-source-exists precondition 16 1331 DAV:binding-allowed precondition 16 1332 DAV:binding-deleted postcondition 18, 21 1333 DAV:can-overwrite precondition 16, 20 1334 DAV:cross-server-binding precondition 16, 20 1335 DAV:cycle-allowed precondition 16, 20 1336 DAV:lock-deleted postcondition 18, 21 1337 DAV:locked-overwrite-allowed precondition 16 1338 DAV:locked-source-collection-update-allowed precondition 20 1339 DAV:locked-update-allowed precondition 16, 18, 20 1340 DAV:name-allowed precondition 16, 20 1341 DAV:new-binding postcondition 17, 21 1342 DAV:parent-set property 14 1343 DAV:protected-source-url-deletion-allowed precondition 20 1344 DAV:protected-url-deletion-allowed precondition 18 1345 DAV:protected-url-modification-allowed precondition 20 1346 DAV:rebind-into-collection precondition 20 1347 DAV:rebind-source-exists precondition 20 1348 DAV:resource-id property 14 1349 DAV:unbind-from-collection precondition 18 1350 DAV:unbind-source-exists precondition 18 1352 M 1353 Methods 1354 BIND 15 1355 REBIND 19 1356 UNBIND 17 1358 P 1359 Properties 1360 DAV:parent-set 14 1361 DAV:resource-id 14 1363 R 1364 REBIND method 19 1366 S 1367 Status Codes 1368 208 Already Reported 21 1369 506 Loop Detected 24 1371 U 1372 UNBIND method 17 1374 Intellectual Property Statement 1376 The IETF takes no position regarding the validity or scope of any 1377 Intellectual Property Rights or other rights that might be claimed to 1378 pertain to the implementation or use of the technology described in 1379 this document or the extent to which any license under such rights 1380 might or might not be available; nor does it represent that it has 1381 made any independent effort to identify any such rights. Information 1382 on the IETF's procedures with respect to rights in IETF Documents can 1383 be found in BCP 78 and BCP 79. 1385 Copies of IPR disclosures made to the IETF Secretariat and any 1386 assurances of licenses to be made available, or the result of an 1387 attempt made to obtain a general license or permission for the use of 1388 such proprietary rights by implementers or users of this 1389 specification can be obtained from the IETF on-line IPR repository at 1390 http://www.ietf.org/ipr. 1392 The IETF invites any interested party to bring to its attention any 1393 copyrights, patents or patent applications, or other proprietary 1394 rights that may cover technology that may be required to implement 1395 this standard. Please address the information to the IETF at 1396 ietf-ipr@ietf.org. 1398 Disclaimer of Validity 1400 This document and the information contained herein are provided on an 1401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1403 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1404 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1405 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1408 Copyright Statement 1410 Copyright (C) The Internet Society (2004). This document is subject 1411 to the rights, licenses and restrictions contained in BCP 78, and 1412 except as set forth therein, the authors retain all their rights. 1414 Acknowledgment 1416 Funding for the RFC Editor function is currently provided by the 1417 Internet Society.