idnits 2.17.1 draft-ietf-webdav-binding-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 50 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 269 has weird spacing: '... | foo bar ...' == Line 332 has weird spacing: '... | foo bar ...' -- 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 (June 17, 2000) is 8712 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) == Missing Reference: 'Extension' is mentioned on line 812, but not defined == Unused Reference: 'RR' is defined on line 1152, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2518 (ref. 'WebDAV') (Obsoleted by RFC 4918) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-11578' == Outdated reference: A later version (-13) exists of draft-ietf-webdav-redirectref-protocol-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-webdav-redirectref-protocol (ref. 'RR') Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group J. Slein, Xerox 2 INTERNET DRAFT E.J. Whitehead Jr., UC Irvine 3 J. Davis, CourseNet 4 G. Clemm, Rational 5 C. Fay, FileNet 6 J. Crawford, IBM 7 December 17, 1999 8 Expires June 17, 2000 10 WebDAV Bindings 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Distribution of this document is unlimited. Please send comments to the 29 Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject 31 "subscribe" to . 33 Discussions of the WEBDAV working group are archived at URL: 34 . 36 Abstract 38 This is one of a pair of specifications that extend the WebDAV 39 Distributed Authoring Protocol to enable clients to create new access 40 paths to existing resources. The two protocol extensions have very 41 different characteristics that make them useful for different sorts of 42 applications. 44 The present specification defines bindings, and the BIND method for 45 creating them. Creating a new binding to a resource indirectly creates 46 one or more new URIs mapped to that resource, which can then be used to 47 access it. Servers are required to insure the integrity of any bindings 48 that they allow to be created. 50 The related specification, RFC xxxx, defines redirect reference 51 resources. A redirect reference resource is a resource whose default 52 response is an HTTP/1.1 302 (Found) status code, redirecting the client 53 to a different resource, the target resource. A redirect reference 54 makes it possible to access the target resource indirectly, through any 55 URI mapped to the redirect reference resource. There are no integrity 56 guarantees associated with redirect reference resources. 58 Table of Contents 60 1 Notational Conventions.......................................2 61 2 Introduction.................................................3 62 3 Terminology..................................................4 63 3.1 Rationale for Distinguishing Bindings from URI Mappings......7 64 4 Overview of Bindings.........................................8 65 5 BIND Method..................................................8 66 5.1 Overview of BIND.............................................8 67 5.2 Bindings to Collections......................................9 68 5.3 URI Mappings Created by a BIND..............................10 69 5.4 Example: URI Mappings Created by a BIND.....................11 70 5.5 BIND Status Codes...........................................11 71 5.6 Example: BIND...............................................11 72 6 DELETE and Bindings.........................................12 73 7 COPY and Bindings...........................................12 74 8 MOVE and Bindings...........................................13 75 9 Bindings and Other Methods..................................14 76 10 Determining Whether Two Bindings Are to the Same Resource...14 77 10.1 resourceid URI Scheme.......................................15 78 11 Discovering the Bindings to a Resource......................15 79 12 Status Codes................................................16 80 12.1 506 Loop Detected...........................................16 81 12.2 507 Cross-Server Binding Forbidden..........................17 82 13 Properties..................................................17 83 13.1 bindings Property...........................................17 84 13.2 resourceid Property.........................................18 85 14 XML Elements................................................18 86 14.1 segment XML Element.........................................18 87 15 Capability Discovery........................................18 88 15.1 Example: Discovery of Support for Bindings..................18 89 16 Security Considerations.....................................19 90 16.1 Privacy Concerns............................................19 91 16.2 Redirect Loops..............................................19 92 16.3 Bindings, and Denial of Service.............................19 93 16.4 Private Locations May Be Revealed...........................20 94 16.5 DAV:bindings and Denial of Service..........................20 95 17 Internationalization Considerations.........................20 96 18 IANA Considerations.........................................20 97 19 Copyright...................................................21 98 20 Intellectual Property.......................................21 99 21 Acknowledgements............................................21 100 22 References..................................................21 101 23 Authors' Addresses..........................................22 102 24 Appendices..................................................22 103 24.1 Appendix 1: Extensions to the WebDAV Document Type 104 Definition..................................................22 106 1 Notational Conventions 108 Since this document describes a set of extensions to the WebDAV 109 Distributed Authoring Protocol [WebDAV], itself an extension to the 110 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 111 elements is exactly the same as described in Section 2.1 of [HTTP]. 113 Since this augmented BNF uses the basic production rules provided in 114 Section 2.2 of [HTTP], these rules apply to this document as well. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2 Introduction 122 This is one of a pair of specifications that extend the WebDAV 123 Distributed Authoring Protocol to enable clients to create new access 124 paths to existing resources. This capability is useful for several 125 reasons: 127 URIs of WebDAV-compliant resources are hierarchical and correspond to a 128 hierarchy of collections in resource space. The WebDAV Distributed 129 Authoring Protocol makes it possible to organize these resources into 130 hierarchies, placing them into groupings, known as collections, which 131 are more easily browsed and manipulated than a single flat collection. 132 However, hierarchies require categorization decisions that locate 133 resources at a single location in the hierarchy, a drawback when a 134 resource has multiple valid categories. For example, in a hierarchy of 135 vehicle descriptions containing collections for cars and boats, a 136 description of a combination car/boat vehicle could belong in either 137 collection. Ideally, the description should be accessible from both. 138 Allowing clients to create new URIs that access the existing resource 139 lets them put that resource into multiple collections. 141 Hierarchies also make resource sharing more difficult, since resources 142 that have utility across many collections are still forced into a single 143 collection. For example, the mathematics department at one university 144 might create a collection of information on fractals that contains 145 bindings to some local resources, but also provides access to some 146 resources at other universities. For many reasons, it may be 147 undesirable to make physical copies of the shared resources on the local 148 server: to conserve disk space, to respect copyright constraints, or to 149 make any changes in the shared resources visible automatically. Being 150 able to create new access paths to existing resources in other 151 collections or even on other servers is useful for this sort of case. 153 The BIND method defined here provides a mechanism for allowing clients 154 to create alternative access paths to existing WebDAV resources. HTTP 155 and WebDAV methods are able to work because there are mappings between 156 URIs and resources. A method is addressed to a URI, and the server 157 follows the mapping from that URI to a resource, applying the method to 158 that resource. Multiple URIs may be mapped to the same resource, but 159 until now there has been no way for clients to create additional URIs 160 mapped to existing resources. 162 BIND lets clients associate a new URI with an existing WebDAV resource, 163 and this URI can then be used to submit requests to the resource. Since 164 URIs of WebDAV resources are hierarchical, and correspond to a hierarchy 165 of collections in resource space, the BIND method also has the effect of 166 adding the resource to a collection. As new URIs are associated with 167 the resource, it appears in additional collections. 169 The companion specification, RFC xxxx, defines redirect reference 170 resources, a different mechanism for creating alternative access paths 171 to existing resources. A redirect reference is a resource in one 172 collection whose purpose is to forward requests to another resource (its 173 target), usually in a different collection. In this way, it provides 174 access to the target resource from another collection. It redirects 175 most requests to the target resource using the HTTP 302 (Moved 176 Temporarily) status code, thereby providing a form of mediated access to 177 the target resource. 179 Bindings and redirect reference resources have very different 180 characteristics: 182 A BIND request does not create a new resource, but simply makes 183 available a new URI for submitting requests to an existing resource. 184 The new URI is indistinguishable from any other URI when submitting a 185 request to a resource. Only one round trip is needed to submit a 186 request to the intended target. Servers are required to enforce the 187 integrity of the relationships between the new URIs and the resources 188 associated with them. Consequently, it may be very costly for servers 189 to support BIND requests that cross server boundaries. 191 A redirect reference is a resource, and so can have properties of its 192 own. Properties of the redirect reference can contain such information 193 as who created the reference, when, and why. Since redirect references 194 are implemented using HTTP 302 responses, it generally takes two round 195 trips to submit a request to the intended resource. Servers are not 196 required to enforce the integrity of redirect references. Redirect 197 references work equally well for local resources and for resources that 198 reside on a different server from the reference. 200 The remainder of this specification is organized as follows. Section 3 201 defines terminology used in the rest of the specification, while Section 202 4 briefly overviews bindings. Section 5 specifies the BIND method, used 203 to create bindings. Sections 6 through 9 discuss the relationships 204 between bindings and other HTTP and WebDAV methods. Sections 10 and 11 205 define mechanisms for tracking bindings. Sections 12 through 14 define 206 the new status codes, properties, and XML elements needed to support 207 bindings. Section 15 discusses compliance and capability discovery. 208 Security concerns, internationalization issues, and IANA considerations 209 are described in Sections 16 through 18. The remaining sections provide 210 other supporting information. 212 3 Terminology 214 The terminology used here follows and extends that in the WebDAV 215 Distributed Authoring Protocol specification [WebDAV]. Definitions of 216 the terms resource, Uniform Resource Identifier (URI), and Uniform 217 Resource Locator (URL) are provided in [URI]. 219 URI Mapping 220 A relation between an absolute URI and a resource. For an 221 absolute URI U and the resource it identifies R, the URI mapping 222 can be thought of as (U => R). Since a resource can represent 223 items that are not network retrievable, as well as those that are, 224 it is possible for a resource to have zero, one, or many URI 225 mappings. Mapping a resource to an "http" scheme URL makes it 226 possible to submit HTTP protocol requests to the resource using 227 the URL. 229 Path Segment 230 Informally, the characters found between slashes ("/") in a URI. 231 Formally, as defined in section 3.3 of [URI]. 233 Binding 234 A relation between a single path segment (in a collection) and a 235 resource. A binding is part of the state of a collection. If two 236 different collections contain a binding between the same path 237 segment and the same resource, these are two distinct bindings. 238 So for a collection C, a path segment S, and a resource R, the 239 binding can be thought of as C:(S -> R). Bindings create URI 240 mappings, and hence allow requests to be sent to a single resource 241 from multiple locations in a URI namespace. For example, given 243 o collection C, accessible through the URI 244 http://www.srv.com/coll/, 245 o path segment S, equal to "foo.html", and 246 o resource R, 248 creating the binding C: (S -> R) makes it possible to use the URI 249 http://www.srv.com/coll/foo.html to access R. 251 The following figure illustrates a more complex example of how 252 bindings create URI mappings. 254 +-----------------------------+ 255 | root collection | 256 |-----------------------------| 257 | bindings: | 258 | | 259 | Coll1 Coll2 Coll3 | 260 | | | \ | 261 +---|-------|--------\--------+ 262 | | \ 263 | | \ 264 +-------------------+ +----------------------+ 265 | collection C1 | | collection C2 | 266 |-------------------| |----------------------| 267 | bindings: | | bindings: | 268 | | | | 269 | foo bar | | foo | 270 | | \ | | / | 271 +--|------\---------+ +-/--------------------+ 272 | \ / 273 | \ / 274 | \ / 275 | \ / 276 +--------------+ +---------------+ 277 | resource R1 | | resource R2 | 278 +--------------+ +---------------+ 280 Figure 1 282 Since there are two bindings in the root collection, Coll1 and 283 Coll2, to collection C1, the single binding C1:(foo -> R1) between 284 foo and resource R1 in collection C1 creates two URI mappings, 285 /Coll1/foo and /Coll2/foo, to resource R1. Each of these URI 286 mappings can be used to submit requests to R1. The binding 287 C1:(bar -> R2) between bar and resource R2 in collection C1 and 288 the binding C2:(foo -> R2) between foo and resource R2 in 289 collection C2 create altogether 3 URI mappings to resource R2: 290 /Coll1/bar, /Coll2/bar, and /Coll3/foo. All 3 URI mappings can be 291 used to submit requests to resource R2. 293 Collection 294 A resource that contains, as part of its state, a set of bindings 295 that identify member resources. 297 Internal Member URI 298 Informally, the complete set of URLs by which a collection member 299 is known. Formally, the URI U of a URI mapping (U => R), created 300 by a binding that is contained in a collection. The following 301 figure illustrates the relationship between bindings and internal 302 member URIs in a collection: 304 +-----------------------------+ 305 | root collection | 306 |-----------------------------| 307 | internal member URIs: | 308 | | 309 | /Coll1/ | 310 | /Coll2/ | 311 | /Coll3/ | 312 |-----------------------------| 313 | bindings: | 314 | | 315 | Coll1 Coll2 Coll3 | 316 | | | \ | 317 +---|-------|--------\--------+ 318 | | \ 319 | | \ 320 +----------------------+ +----------------------+ 321 | collection C1 | | collection C2 | 322 |----------------------| |----------------------| 323 | internal member URIs:| | internal member URIs:| 324 | | | | 325 | /Coll1/foo | | /Coll3/foo | 326 | /Coll2/foo | |----------------------| 327 | /Coll1/bar | | bindings: | 328 | /Coll2/bar | | | 329 |----------------------| | foo | 330 | bindings: | | / | 331 | | +-/--------------------+ 332 | foo bar | / 333 | | \ | / 334 +--|------\------------+ / 335 | \ / 336 | \ / 337 | \ / 338 | \ / 339 +--------------+ +---------------+ 340 | resource R1 | | resource R2 | 341 +--------------+ +---------------+ 343 Figure 2 345 The URIs of all URI mappings created by a collection's bindings 346 are internal member URIs of the collection. 348 However, for a given request, only the URIs from those URI 349 mappings that incorporate the Request-URI are treated as internal 350 member URIs. This is done to prevent large amounts of duplicate 351 information from being returned for operations on collections. 352 The problem would occur if a PROPFIND on a collection to which 353 there are multiple URI mappings returned information for every URI 354 mapping. 356 For example, in Figure 2 above, if a PROPFIND request with "Depth: 357 infinity" is submitted to collection C1 using the Request-URI 358 /Coll1/, only the URI mappings starting with the Request-URI would 359 be listed as internal member URIs. The response would include 360 only /Coll1/ itself and the internal member URIs /Coll1/foo and 361 /Coll1/bar. It would not include /Coll2/, /Coll2/foo, or 362 /Coll2/bar, even though the URI /Coll2/ does map to the 363 collection, and /Coll2/foo and /Coll2/bar are internal member URIs 364 of the collection. 366 In [WebDAV], a collection is defined as containing a list of 367 internal member URIs, where an internal member URI is the URI of 368 the collection, plus a single path segment. This definition 369 combines the two concepts of binding and URI mapping that are 370 separated in this specification. As a result, this specification 371 redefines a collection's state to be a set of bindings, and 372 redefines an internal member URI to be the URI of a URI mapping 373 derived from a binding. After this redefinition, an internal 374 member URI can be used when reading [WebDAV] without loss of 375 meaning. For purposes of interpretation, when [WebDAV] discusses a 376 collection "containing" an internal member URI, this should be 377 read as the collection containing a binding whose mapping to a URI 378 creates an internal member URI, in this sense "containing" the 379 internal member URI. The authors of this specification anticipate 380 and recommend that future revisions of [WebDAV] perform a full 381 reconciliation of terms between these two specifications. 383 3.1 Rationale for Distinguishing Bindings from URI Mappings 385 Consider again collection C1 in Figure 2. If we had only the notion of 386 URI mappings, we would be forced to say that C1's membership was defined 387 by the list of internal member URIs. If these URIs identify the 388 membership, and are part of the state of the collection, then the act of 389 making the collection available via a new URI has the effect of changing 390 the collection's membership, hence changing the collection's state. This 391 is undesirable, since ideally a collection's membership should remain 392 the same, if suddenly a new URI can be used to access the collection. 393 What is needed is a way to separate the final segment of a URI from the 394 collection's URI contribution. 396 The notion of binding is introduced to separate the final segment of a 397 URI from its parent collection�s contribution. This done, a collection 398 can be defined as containing a set of bindings, thus permitting new 399 mappings to a collection without modifying its membership. We introduce 400 the concept of URI mapping to combine together the collection's URI and 401 a binding's segment to create a full URI that can be used in protocol 402 requests. Finally, the internal member URI, first defined in [WebDAV], 403 is redefined here to maintain backward compatibility with that 404 specification. 406 4 Overview of Bindings 408 Bindings are part of the state of a collection. In general, there is a 409 one-to-many correspondence between a collection's bindings and its 410 internal member URIs, as illustrated in Figure 2 above. The URI segment 411 associated with a resource by one of a collection's bindings is also the 412 final segment of one or more of the collection's internal member URIs. 413 The final segment of each internal member URI identifies one of the 414 bindings that is part of the collection's state. 416 Bindings are not unique to advanced collections, although the BIND 417 method for explicitly creating bindings is introduced here. Existing 418 methods that create resources, such as PUT, MOVE, COPY, and MKCOL, 419 implicitly create bindings. There is no difference between implicitly 420 created bindings and bindings created with BIND. 422 The identity of a binding C:(S -> R) is determined by the URI segment 423 (in its collection) and the resource that the binding associates. If 424 the resource goes out of existence (as a result of some out-of-band 425 operation), the binding also goes out of existence. If the URI segment 426 comes to be associated with a different resource, the original binding 427 ceases to exist and another binding is created. 429 It would be very undesirable if one binding could be destroyed as a side 430 effect of operating on the resource through a different binding. It is 431 not acceptable for moving a resource through one binding to disrupt 432 another binding, turning that binding into a dangling path segment. Nor 433 is it acceptable for a server, after removing one binding, to reclaim 434 the system resources associated with its resource while other bindings 435 to the resource remain. Implementations MUST ensure the integrity of 436 bindings. 438 5 BIND Method 440 5.1 Overview of BIND 442 The BIND method creates a new binding between the resource identified by 443 the Request-URI and the final segment of the Destination header (minus 444 any trailing slash). This binding is added to the collection identified 445 by the Destination header minus its trailing slash (if present) and 446 final segment. The Destination header is defined in Section 9.3 of 447 [WebDAV]. 449 If a server cannot guarantee the binding behavior specified here, 450 including the guarantee of the integrity of the binding, the BIND 451 request MUST fail. 453 Note: It is especially difficult to maintain the integrity of cross- 454 server bindings. Unless the server where the resource resides knows 455 about all bindings on all servers to that resource, it may unwittingly 456 destroy the resource or move it without notifying another server that 457 manages a binding to the resource. For example, if server A permits 458 creation of a binding to a resource on server B, server A must notify 459 server B about its binding and must have an agreement with B that B will 460 not destroy the resource while A's binding exists. Otherwise server B 461 may receive a DELETE request that it thinks removes the last binding to 462 the resource and destroy the resource while A's binding still exists. 463 Status code 507 (Cross-server Binding Forbidden) is defined in Section 464 12.2 for cases where servers must fail cross-server BIND requests 465 because they cannot guarantee the integrity of cross-server bindings. 467 If the Destination header does not contain a path segment (i.e., it 468 consists simply of a slash "/"), the BIND operation MUST fail and report 469 a 400 (Bad Request) status code. A binding consists of a (collection, 470 segment, resource) triple, and the Destination header is required to 471 specify the collection and segment of this triple. 473 If the Destination header minus its final path segment does not identify 474 a collection, the BIND operation MUST fail and report a 400 (Bad 475 Request) status code. 477 Note: Section 5.1 of [WebDAV] defines a consistent namespace to be one 478 such that "for every URL in the HTTP hierarchy there exists a collection 479 that contains that URL as an internal member," but [WebDAV] does not 480 require namespaces to be consistent. There can exist URIs that map to 481 resources, but do not depend on the existence of collections for the 482 mapping. For example, the URI http://www.svr.com/x/y.html may map to 483 resource R even if the URI http://www.svr.com/x/ does not map to any 484 resource. This specification does not support the creation of such URI 485 mappings. The BIND method can be used only in consistent sections of a 486 namespace. 488 After successful processing of a BIND request, it MUST be possible for 489 clients to use the URI in the Destination header to submit requests to 490 the resource identified by the Request-URI. 492 By default, if the Destination header identifies an existing binding, 493 the new binding replaces the existing binding. This default binding 494 replacement behavior can be overridden using the Overwrite header 495 defined in Section 9.6 of [WebDAV]. 497 5.2 Bindings to Collections 498 Bindings to collections can result in loops. If a server wants to 499 prevent a loop from being created, it MAY fail the BIND request with a 500 403 (Forbidden) status code. If a server allows a loop to be created, 501 it MUST detect the loop when processing "Depth: infinity" requests that 502 encounter the loop. It is sometimes possible to complete an operation 503 in spite of the presence of a loop. However, the 506 (Loop Detected) 504 status code is defined in Section 12.1 for use in contexts where an 505 operation is terminated because a loop was encountered. 507 Creating a new binding to a collection makes each resource associated 508 with a binding in that collection accessible via a new URI, and thus 509 creates new URI mappings to those resources but no new bindings. 511 For example, suppose a new binding COLLX is created for collection C1 in 512 the figure below. It immediately becomes possible to access resource R1 513 using the URI /COLLX/x.gif and to access resource R2 using the URI 514 /COLLX/y.jpg, but no new bindings for these child resources were 515 created. This is because bindings are part of the state of a 516 collection, and associate a URI that is relative to that collection with 517 its target resource. No change to the bindings in Collection C1 is 518 needed to make its children accessible using /COLLX/x.gif and 519 /COLLX/y.jpg. 521 +-------------------------+ 522 | Root Collection | 523 | (properties) | 524 | bindings: | 525 | coll1 COLLX | 526 +-------------------------+ 527 | / 528 | / 529 | / 530 +------------------+ 531 | Collection C1 | 532 | (properties) | 533 | bindings: | 534 | x.gif y.jpg | 535 +------------------+ 536 | \ 537 | \ 538 | \ 539 +-------------+ +-------------+ 540 | Resource R1 | | Resource R2 | 541 +-------------+ +-------------+ 543 Figure 3 545 5.3 URI Mappings Created by a BIND 547 Suppose a BIND request causes a binding from "Binding-Name" to resource 548 R to be added to a collection, C. Then if C-MAP is the set of URI's 549 that were mapped to C before the BIND request, then for each URI "C-URI" 550 in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following 551 the BIND request. 553 Note that if R is a collection, additional URI mappings are created to 554 the descendents of R. Also note that if a binding is made in collection 555 C to C itself (or to a parent of C), an infinite number of mappings is 556 introduced. 558 5.4 Example: URI Mappings Created by a BIND 560 For example, if a binding from "foo.html" to R is added to a collection 561 C, and if the following URI's are mapped to C: 563 http://www.fuzz.com/A/1 564 http://fuzz.com/A/one 566 then the following new mappings to R are introduced: 568 http://www.fuzz.com/A/1/foo.html 569 http://fuzz.com/A/one/foo.html 571 If a binding from "myself" to C is then added to C, the following 572 infinite number of additional mappings to C are introduced: 574 http://www.fuzz.com/A/1/myself 575 http://www.fuzz.com/A/1/myself/myself 576 ... 578 and the following infinite number of additional mappings to R are 579 introduced: 581 http://www.fuzz.com/A/1/myself/foo.html 582 http://www.fuzz.com/A/1/myself/myself/foo.html 583 ... 585 5.5 BIND Status Codes 587 201 (Created): The binding was successfully created. 589 400 (Bad Request): The client set an invalid value for the Destination 590 header or Request-URI. 592 403 (Forbidden): This server has a policy that forbids creation of 593 bindings that would result in loops. 595 412 (Precondition Failed): The Overwrite header is "F", and a binding 596 already exists for the Destination header. 598 507 (Cross-Server Binding Forbidden): The server is unable to create the 599 requested binding because it would bind a segment in a collection on one 600 server to a resource on a different server. 602 5.6 Example: BIND 604 >> Request: 606 BIND /pub/i-d/draft-webdav-protocol-08.txt HTTP/1.1 607 Host: www.ics.uci.edu 608 Destination: http://www.ics.uci.edu/~whitehead/dav/spec08.txt 610 >> Response: 612 HTTP/1.1 201 Created 614 The server created a new binding, associating "spec08.txt" with the 615 resource identified by the URL "http://www.ics.uci.edu/pub/i-d/draft- 616 webdav-protocol-08.txt". Clients can now use the URI in the Destination 617 header, "http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit 618 requests to that resource. As part of this operation, the server added 619 the binding "spec08.txt" to collection /~whitehead/dav/. 621 6 DELETE and Bindings 623 The DELETE method was originally defined in [HTTP]. This section 624 redefines the behavior of DELETE in terms of bindings, an abstraction 625 not available when writing [HTTP]. [HTTP] states that "the DELETE method 626 requests that the origin server delete the resource identified by the 627 Request-URI." Because [HTTP] did not distinguish between bindings and 628 resources, the intent of its definition of DELETE is unclear. The 629 definition presented here is a clarification of the definition in 630 [HTTP]. 632 The DELETE method requests that the server remove the binding between 633 the resource identified by the Request-URI and the binding name, the 634 last path segment of the Request-URI. The binding MUST be removed from 635 its parent collection, identified by the Request-URI minus its trailing 636 slash (if present) and final segment. 638 Once a resource is unreachable by any URI mapping, the server MAY 639 reclaim system resources associated with that resource. If DELETE 640 removes a binding to a resource, but there remain URI mappings to that 641 resource, the server MUST NOT reclaim system resources associated with 642 the resource. 644 Although [WebDAV] allows a DELETE to be a non-atomic operation, the 645 DELETE operation defined here is atomic. In particular, a DELETE on a 646 hierarchy of resources is simply the removal of a binding to the 647 collection identified by the Request-URI, and so is a single (and 648 therefore atomic) operation. 650 Section 8.6.1 of [WebDAV] states that during DELETE processing, a server 651 "MUST remove any URI for the resource identified by the Request-URI from 652 collections which contain it as a member." Servers that support 653 bindings MUST NOT follow this requirement. 655 7 COPY and Bindings 657 As defined in Section 8.8 of [WebDAV], COPY causes the resource 658 identified by the Request-URI to be duplicated, and makes the new 659 resource accessible using the URI specified in the Destination header. 660 Upon successful completion of a COPY, a new binding is created between 661 the last path segment of the Destination header, and the destination 662 resource. The new binding is added to its parent collection, identified 663 by the Destination header minus its trailing slash (if present) and 664 final segment. 666 Figure 4 below shows an example: Suppose that a COPY is issued to URI 3 667 for resource R (which is also mapped to URI 1 and URI 2), with the 668 Destination header set to URIX. After successful completion of the COPY 669 operation, resource R is duplicated to create resource R', and a new 670 binding has been created which creates at least the URI mapping between 671 URIX and the new resource (although other URI mappings may also have 672 been created). 674 URI 1 URI 2 URI 3 URIX 675 | | | | 676 | | | <---- URI Mappings ----> | 677 | | | | 678 +---------------------+ +------------------------+ 679 | Resource R | | Resource R' | 680 +---------------------+ +------------------------+ 682 Figure 4 684 It might be thought that a COPY request with "Depth: 0" on a collection 685 would duplicate its bindings, since bindings are part of the 686 collection's state. This is not the case, however. The definition of 687 Depth in [WebDAV] makes it clear that a "Depth: 0" request does not 688 apply to a collection's members. Consequently, a COPY with "Depth: 0" 689 does not duplicate the bindings contained by the collection. 691 8 MOVE and Bindings 693 The MOVE method has the effect of creating a new binding to a resource 694 (at the Destination), and removing an existing binding (at the Request- 695 URI). The name of the new binding is the last path segment of the 696 Destination header, and the new binding is added to its parent 697 collection, identified by the Destination header minus its trailing 698 slash (if present) and final segment. 700 As an example, suppose that a MOVE is issued to URI 3 for resource R 701 below (which is also mapped to URI 1 and URI 2), with the Destination 702 header set to URIX. After successful completion of the MOVE operation, 703 a new binding has been created which creates at least the URI mapping 704 between URIX and resource R (although other URI mappings may also have 705 been created). The binding corresponding to the final segment of URI 3 706 has been removed, which also causes the URI mapping between URI 3 and R 707 to be removed. 709 >> Before Request: 711 URI 1 URI 2 URI 3 712 | | | 713 | | | <---- URI Mappings 714 | | | 715 +---------------------+ 716 | Resource R | 717 +---------------------+ 719 >> After Request: 721 URI 1 URI 2 URIX 722 | | | 723 | | | <---- URI Mappings 724 | | | 725 +---------------------+ 726 | Resource R | 727 +---------------------+ 729 Figure 5 731 Although [WebDAV] allows a MOVE on a collection to be a non-atomic 732 operation, the MOVE operation defined here MUST be atomic. Even when 733 the Request-URI identifies a collection, the MOVE operation involves 734 only removing one binding to that collection and adding another. There 735 are no operations on bindings to any of its children, so the case of 736 MOVE on a collection is the same as the case of MOVE on a non-collection 737 resource. Both are atomic. 739 9 Bindings and Other Methods 741 This section describes the interaction of bindings with those HTTP 742 methods not yet explicitly discussed. The semantics of the methods GET, 743 HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of 744 PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. 746 For these methods, no new complexities are introduced by allowing 747 explicit creation of multiple bindings to the same resource. When 748 applied to static resources (that is, resources that are not CGI 749 scripts, Active Server Pages, etc.), they obey the following rule: 751 o A method submitted through one URI mapping, on success, MUST produce 752 the same results as the same method, with the same headers and entity 753 body, submitted through any other URI mapping to the same resource. 755 When applied to dynamic resources, it is not possible to state any such 756 rule. For any method, a dynamic resource may be sensitive to the URI 757 mapping used to access it. The resource may produce different results 758 depending upon which URI mapping was used to submit the request. 760 Nevertheless, servers MAY allow new bindings to dynamic resources to be 761 created using BIND. 763 10 Determining Whether Two Bindings Are to the Same Resource 765 It is useful to have some way of determining whether two bindings are to 766 the same resource. Two different resources might have identical 767 contents and identical values for the properties defined in [WebDAV]. 768 Although the DAV:bindings property defined in Section 13.1 provides this 769 information, it is an optional property. 771 The REQUIRED DAV:resourceid property defined in Section 13.2 is a 772 resource identifier, which MUST be unique across all resources for all 773 time. If the values of DAV:resourceid returned by PROPFIND requests 774 through two bindings are identical, the client can be assured that the 775 two bindings are to the same resource. 777 The DAV:resourceid property is created, and its value assigned, when the 778 resource is created. The value of DAV:resourceid MUST NOT be changed. 779 Even after the resource is no longer accessible through any URI, that 780 value MUST NOT be reassigned to another resource's DAV:resourceid 781 property. 783 Any method that creates a new resource MUST assign a new, unique value 784 to its DAV:resourceid property. For example, a PUT that creates a new 785 resource must assign a new, unique value to its DAV:resourceid property. 786 A COPY, since it creates a new resource at the Destination URI, must 787 assign a new, unique value to its DAV:resourceid property. 789 On the other hand, any method that affects an existing resource MUST NOT 790 change the value of its DAV:resourceid property. For example, a PUT 791 that updates an existing resource must not change the value of its 792 DAV:resourceid property. A MOVE, since it does not create a new 793 resource, but only changes the location of an existing resource, must 794 not change the value of its DAV:resourceid property. 796 10.1 resourceid URI Scheme 798 The value of DAV:resourceid is a URI and may use any URI scheme that 799 guarantees the uniqueness of the value across all resources for all 800 time. The resourceid URI scheme defined here is an example of an 801 acceptable URI scheme. 803 The resourceid URI scheme requires the use of the Universal Unique 804 Identifier (UUID) mechanism, as described in [ISO-11578]. UUID 805 generators may choose between two methods of creating the identifiers. 806 They can either generate a new UUID for every identifier they create or 807 they can create a single UUID and then add extension characters. If the 808 second method is selected, then the program generating the extensions 809 MUST guarantee that the same extension will never be used twice with the 810 associated UUID. 812 resourceid-URI = "resourceid:" UUID [Extension] ; The UUID production is 813 the string representation of a UUID, as defined in [ISO-11578]. Note 814 that white space (LWS) is not allowed between elements of this 815 production. 817 Extension = path ; path is defined in Section 3.3 of [URI]. 819 11 Discovering the Bindings to a Resource 821 An OPTIONAL DAV:bindings property on a resource provides a list of the 822 bindings that associate URI segments with that resource. If the 823 DAV:bindings property exists on a given resource, it MUST contain a 824 complete list of all bindings to that resource. A PROPFIND requesting 825 DAV:bindings MUST return only those bindings that the client is 826 authorized to see. By retrieving this property, a client can discover 827 the bindings that point to the resource and the collections that contain 828 bindings to the resource. 830 Rationale: A number of scenarios require clients to navigate from a 831 resource to the bindings that point to it, and to the collections that 832 contain those bindings. This capability is particularly important for 833 Document Management Systems. Their clients may need to determine, for 834 any object in the DMS, what collections contain bindings to that object. 835 This information can be used for upward navigation through a hierarchy 836 or to discover related documents in other collections. 838 Risks: When deciding whether to support the DAV:bindings property, 839 server implementers / administrators should balance the benefits it 840 provides against the cost of maintaining the property and the security 841 risks enumerated in Sections 16.4 and 16.5. 843 12 Status Codes 845 12.1 506 Loop Detected 847 The 506 (Loop Detected) status code indicates that the server terminated 848 an operation because it encountered an infinite loop while processing a 849 request with "Depth: infinity". 851 When this status code is the top-level status code for the operation, it 852 indicates that the entire operation failed. 854 When this status code occurs inside a multistatus response, it indicates 855 only that a loop is being terminated, but does not indicate failure of 856 the operation as a whole. 858 For example, consider a PROPFIND request on the following collection: 860 Coll-1 (bound to collection C) 861 Foo (bound to resource R) 862 Bar (bound to collection C) 864 >> Request: 866 PROPFIND /Coll-1/ HTTP/1.1 867 Host: www.somehost.com 868 Depth: infinity 869 Content-Type: text/xml; charset="utf-8" 870 Content-Length: xxx 872 873 874 875 876 877 879 >> Response: 881 HTTP/1.1 207 Multi-Status 882 Content-Type: text/xml; charset="utf-8" 883 Content-Length: xxx 885 886 887 888 http://www.somehost.com/Coll-1/ 889 890 891 Loop Demo 892 893 HTTP/1.1 200 OK 894 895 896 897 http://www.somehost.com/Coll-1/Foo 898 899 900 Bird Inventory 901 902 HTTP/1.1 200 OK 903 904 905 906 http://www.somehost.com/Coll-1/Bar 907 908 909 910 911 HTTP/1.1 506 Loop Detected 912 913 914 916 12.2 507 Cross-Server Binding Forbidden 918 The server is unable to create the requested binding because it would 919 bind a segment in a collection on one server to a resource on a 920 different server. 922 13 Properties 924 13.1 bindings Property 926 Name: bindings 927 Namespace: DAV: 928 Purpose: Enables clients to discover, for any resource, what bindings 929 point to it and what collections contain those bindings. 930 This is an optional property. If present on a given 931 resource, it is a read-only property, maintained by the 932 server, and contains a complete list of all bindings to that 933 resource. 934 Value: List of href / segment pairs for all of the bindings that 935 associate URI segments with the resource. The href is an 936 absolute URI for one URI mapping of the collection 937 containing the binding. Since there may be multiple URI 938 mappings for this collection, it is necessary to select one 939 (preferably the URI mapping contained in the Request-URI of 940 the BIND request) for use in the DAV:bindings property. The 941 segment is the URI segment that identifies the binding 942 within that collection. 944 946 13.2 resourceid Property 948 Name: resourceid 949 Namespace: DAV: 950 Purpose: Enables clients to determine whether two bindings are for 951 the same resource. 952 Value: URI that is guaranteed unique across all resources for all 953 time. It may be of the resourceid URI scheme 954 defined in Section 10.1 or any other URI scheme that 955 guarantees this uniqueness. 957 959 14 XML Elements 961 14.1 segment XML Element 963 Name: segment 964 Namespace: DAV: 965 Purpose: The segment that names a binding, used in the DAV:bindings 966 property. 967 Value: segment ; as defined in section 3.3 of [URI]. 969 971 15 Capability Discovery 973 Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes 974 with the DAV header in responses to OPTIONS, to indicate which parts of 975 the WebDAV Distributed Authoring protocol the resource supports. This 976 specification defines an OPTIONAL extension to [WebDAV]. It defines a 977 new compliance class, called bindings, for use with the DAV header in 978 responses to OPTIONS requests. If a resource does support bindings, its 979 response to an OPTIONS request may indicate that it does, by listing the 980 new BIND method as one it supports, and by listing the new bindings 981 compliance class in the DAV header. 983 When responding to an OPTIONS request, any type of resource can include 984 bindings in the value of the DAV header. Doing so indicates that the 985 server permits a binding at the request URI. 987 15.1 Example: Discovery of Support for Bindings 989 >> Request: 991 OPTIONS /somecollection/someresource HTTP/1.1 992 HOST: somehost.org 994 >> Response: 996 HTTP/1.1 200 OK 997 Date: Tue, 20 Jan 1998 20:52:29 GMT 998 Connection: close 999 Accept-Ranges: none 1000 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1001 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND 1002 Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1003 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH 1004 DAV: 1, 2, bindings 1006 The DAV header in the response indicates that the resource 1007 /somecollection/someresource is level 1 and level 2 compliant, as 1008 defined in [WebDAV]. In addition, /somecollection/someresource supports 1009 bindings. The Allow header indicates that BIND requests can be 1010 submitted to /somecollection/someresource. The Public header shows that 1011 other Request-URIs on the server support additional methods. 1013 16 Security Considerations 1015 This section is provided to make WebDAV applications aware of the 1016 security implications of this protocol. 1018 All of the security considerations of HTTP/1.1 and the WebDAV 1019 Distributed Authoring Protocol specification also apply to this protocol 1020 specification. In addition, bindings introduce several new security 1021 concerns and increase the risk of some existing threats. These issues 1022 are detailed below. 1024 16.1 Privacy Concerns 1026 In a context where cross-server bindings are supported, creating 1027 bindings on a trusted server may make it possible for a hostile agent to 1028 induce users to send private information to a target on a different 1029 server. 1031 16.2 Redirect Loops 1033 Although redirect loops were already possible in HTTP 1.1, the 1034 introduction of the BIND method creates a new avenue for clients to 1035 create loops accidentally or maliciously. If the binding and its target 1036 are on the same server, the server may be able to detect BIND requests 1037 that would create loops. Servers are required to detect loops that are 1038 caused by bindings to collections during the processing of any requests 1039 with "Depth: infinity". 1041 16.3 Bindings, and Denial of Service 1043 Denial of service attacks were already possible by posting URLs that 1044 were intended for limited use at heavily used Web sites. The 1045 introduction of BIND creates a new avenue for similar denial of service 1046 attacks. If cross-server bindings are supported, clients can now create 1047 bindings at heavily used sites to target locations that were not 1048 designed for heavy usage. 1050 16.4 Private Locations May Be Revealed 1052 If the DAV:bindings property is maintained on a resource, the owners of 1053 the bindings risk revealing private locations. The directory structures 1054 where bindings are located are available to anyone who has access to the 1055 DAV:bindings property on the resource. Moving a binding may reveal its 1056 new location to anyone with access to DAV:bindings on its resource. 1058 16.5 DAV:bindings and Denial of Service 1060 If the server maintains the DAV:bindings property in response to 1061 bindings created in other administrative domains, it is exposed to 1062 hostile attempts to make it devote resources to adding bindings to the 1063 list. 1065 17 Internationalization Considerations 1067 This specification follows the practices of [WebDAV] in encoding all 1068 human-readable content using XML [XML] and in the treatment of names. 1069 Consequently, this specification complies with the IETF Character Set 1070 Policy [RFC2277]. 1072 WebDAV applications MUST support the character set tagging, character 1073 set encoding, and the language tagging functionality of the XML 1074 specification. This constraint ensures that the human-readable content 1075 of this specification complies with [RFC2277]. 1077 As in [WebDAV], names in this specification fall into three categories: 1078 names of protocol elements such as methods and headers, names of XML 1079 elements, and names of properties. Naming of protocol elements follows 1080 the precedent of HTTP, using English names encoded in USASCII for 1081 methods and headers. The names of XML elements used in this 1082 specification are English names encoded in UTF-8. 1084 For error reporting, [WebDAV] follows the convention of HTTP/1.1 status 1085 codes, including with each status code a short, English description of 1086 the code (e.g., 423 Locked). Internationalized applications will ignore 1087 this message, and display an appropriate message in the user's language 1088 and character set. 1090 This specification introduces no new strings that are displayed to users 1091 as part of normal, error-free operation of the protocol. 1093 For rationales for these decisions and advice for application 1094 implementors, see [WebDAV]. 1096 18 IANA Considerations 1098 This document uses the namespaces defined by [WebDAV] for properties and 1099 XML elements. All other IANA considerations mentioned in [WebDAV] also 1100 apply to this document. 1102 In addition, this document defines the new resourceid URI Scheme in 1103 Section 10.1 and the new HTTP/1.1 status codes 506 and 507in Section 12. 1105 19 Copyright 1107 To be supplied by the RFC Editor. 1109 20 Intellectual Property 1111 To be supplied by the RFC Editor. 1113 21 Acknowledgements 1115 This draft has benefited from thoughtful discussion by Jim Amsden, Peter 1116 Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Dan 1117 Connolly, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David 1118 Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, 1119 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel 1120 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru 1121 Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1122 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1124 22 References 1126 [RFC2277] H.T. Alvestrand, "IETF Policy on Character Sets and 1127 Languages." RFC 2277, BCP 18. Uninett. January, 1998. 1129 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1130 Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, 1131 Xerox. August, 1998. 1133 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1134 Levels." RFC 2119, BCP 14. Harvard University. March, 1997. 1136 [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup 1137 Language (XML)." World Wide Web Consortium Recommendation REC-xml- 1138 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 1140 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1141 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 1142 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. 1144 [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. 1145 Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. 1146 Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. 1148 [ISO-11578] ISO (International Organization for Standardization), 1149 ISO/IEC 11578:1996. "Information technology - Open Systems 1150 Interconnection - Remote Procedure Call (RPC)." 1152 [RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 1153 Crawford, "WebDAV Redirect References." Internet Draft (work 1154 in progress) draft-ietf-webdav-redirectref-protocol-02. Xerox, UC 1155 Irvine, CourseNet, Rational, FileNet, IBM. December, 1999. 1157 23 Authors' Addresses 1159 J. Slein 1160 Xerox Corporation 1161 800 Phillips Road, 105-50C 1162 Webster, NY 14580 1163 Email: jslein@crt.xerox.com 1165 E. J. Whitehead, Jr. 1166 Dept. of Information and Computer Science 1167 University of California, Irvine 1168 Irvine, CA 92697-3425 1169 Email: ejw@ics.uci.edu 1171 J. Davis 1172 CourseNet Systems 1173 170 Capp Street 1174 San Francisco, CA 94110 1175 Email: jrd3@alum.mit.edu 1177 G. Clemm 1178 Rational Software Corporation 1179 20 Maguire Road 1180 Lexington, MA 02173-3104 1181 Email: gclemm@rational.com 1183 C. Fay 1184 FileNet Corporation 1185 3565 Harbor Boulevard 1186 Costa Mesa, CA 92626-1420 1187 Email: cfay@filenet.com 1189 J. Crawford 1190 IBM Research 1191 P.O. Box 704 1192 Yorktown Heights, NY 10598 1193 Email: ccjason@us.ibm.com 1195 24 Appendices 1197 24.1 Appendix 1: Extensions to the WebDAV Document Type Definition 1199 1200 1201 1202 1203 1205 Expires June 17, 2000