idnits 2.17.1 draft-ietf-webdav-binding-protocol-01.txt: -(163): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(379): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 7 instances 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 24 longer pages, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages 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 58 instances of lines with control characters in the document. ** The abstract seems to contain references ([OC], [RR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 266 has weird spacing: '... | foo bar ...' == Line 328 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 (April 15, 2000) is 8770 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 948, but not defined == Missing Reference: 'Alvestrand' is mentioned on line 1236, but not defined == Unused Reference: 'OC' is defined on line 1306, 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 (-10) exists of draft-ietf-webdav-ordering-protocol-00 == Outdated reference: A later version (-13) exists of draft-ietf-webdav-redirectref-protocol-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-webdav-redirectref-protocol (ref. 'RR') Summary: 9 errors (**), 0 flaws (~~), 12 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 T. Chihaya, DataChannel 8 October 15, 1999 9 Expires April 15, 2000 11 WebDAV Bindings 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this document is unlimited. Please send comments to the 33 Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject 35 "subscribe" to . 37 Discussions of the WEBDAV working group are archived at URL: 38 . 40 Abstract 42 The WebDAV Distributed Authoring Protocol provides basic support for 43 collections, offering the ability to create and list unordered 44 collections. 46 This specification is one of a group of three specifications that 47 supplement the WebDAV Distributed Authoring Protocol to increase the 48 power of WebDAV collections. This specification defines bindings, one 49 mechanism for allowing a single resource to appear in more than one 50 collection. Bindings make this possible by creating mappings of URIs to 51 resources. The BIND method defined here gives clients the ability to 52 create new bindings to existing resources. The second specification, 53 "WebDAV Redirect Reference Resources"[RR], defines redirect references, 54 another approach to allowing a single resource to be accessed from 55 multiple collections. The third specification, "WebDAV Ordered 56 Collections Protocol"[OC], provides a mechanism for ordering 57 collections. 59 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.....................10 70 5.5 BIND Status Codes...........................................11 71 5.6 Example: BIND...............................................11 72 6 DELETE and Bindings.........................................11 73 7 COPY and Bindings...........................................12 74 8 MOVE and Bindings...........................................13 75 8.1 Implementation Note.........................................14 76 8.2 MOVE and Locks..............................................15 77 9 LOCK and UNLOCK.............................................16 78 10 Bindings and Other Methods..................................17 79 11 Determining Whether Two Bindings Are to the Same 80 Resource....................................................17 81 11.1 davresourceid URI Scheme....................................17 82 12 Discovering the Bindings to a Resource......................18 83 13 Status Codes................................................18 84 13.1 506 Loop Detected...........................................18 85 13.2 507 Loop Forbidden..........................................20 86 13.3 508 Cross-Server Binding Forbidden..........................20 87 14 Headers.....................................................20 88 14.1 All-Bindings Request Header.................................20 89 14.2 Loop Header.................................................20 90 15 Properties..................................................20 91 15.1 bindings Property...........................................20 92 15.2 guid Property...............................................21 93 16 XML Elements................................................21 94 16.1 segment XML Element.........................................21 95 17 Capability Discovery........................................21 96 17.1 Example: Discovery of Support for Bindings..................21 97 18 Security Considerations.....................................22 98 18.1 Privacy Concerns............................................22 99 18.2 Redirect Loops..............................................22 100 18.3 Bindings, and Denial of Service.............................22 101 18.4 Private Locations May Be Revealed...........................22 102 18.5 DAV:bindings and Denial of Service..........................23 103 19 Internationalization Considerations.........................23 104 20 IANA Considerations.........................................23 105 21 Copyright...................................................23 106 22 Intellectual Property.......................................23 107 23 Acknowledgements............................................24 108 24 References..................................................24 109 25 Authors' Addresses..........................................24 110 26 Appendices..................................................25 111 26.1 Appendix 1: Extensions to the WebDAV Document Type 112 Definition..................................................25 114 1 Notational Conventions 115 Since this document describes a set of extensions to the WebDAV 116 Distributed Authoring Protocol [WebDAV], itself an extension to the 117 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 118 elements is exactly the same as described in Section 2.1 of [HTTP]. 119 Since this augmented BNF uses the basic production rules provided in 120 Section 2.2 of [HTTP], these rules apply to this document as well. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2 Introduction 128 The simple collections that the WebDAV Distributed Authoring Protocol 129 supports are powerful enough to be widely useful. They provide for the 130 hierarchical organization of resources, with mechanisms for creating and 131 deleting collections, copying and moving them, locking them, adding 132 members to them and removing members from them, and getting listings of 133 their members. Delete, copy, move, list, and lock operations can be 134 applied recursively, so that a client can operate on whole hierarchies 135 with a single request. 137 This specification is one of a family of three specifications that build 138 on the infrastructure defined in [HTTP] and [WebDAV] to extend the 139 capabilities of collections. The companion specification, "WebDAV 140 Ordered Collections Protocol"[OC], defines protocol extensions to 141 support ordered collections. The present specification and the 142 companion specification, "WebDAV Redirect Reference Resources"[RR], 143 define mechanisms for allowing the same resource to appear in multiple 144 collections. This capability is useful for several reasons: 146 Organizing resources into hierarchies places them into smaller 147 groupings, known as collections, which are more easily browsed and 148 manipulated than a flat namespace. However, hierarchies require 149 categorization decisions that locate resources at a single location in 150 the hierarchy, a drawback when a resource has multiple valid categories. 151 For example, in a hierarchy of vehicle descriptions containing 152 collections for cars and boats, a description of a combination car/boat 153 vehicle could belong in either collection. Ideally, the description 154 should be accessible from both. 156 Hierarchies also make resource sharing more difficult, since resources 157 that have utility across many collections are still forced into a single 158 collection. For example, the mathematics department at one university 159 might create a collection of information on fractals that contains 160 bindings to some local resources, but also provides access to some 161 resources at other universities. For many reasons, it may be 162 undesirable to make physical copies of the shared resources on the local 163 server � to conserve disk space, to respect copyright constraints, or to 164 make any changes in the shared resources visible automatically. 166 The companion specification [RR] defines redirect references, one 167 mechanism for providing access to a single resource from multiple 168 collections. A redirect reference is a resource in one collection whose 169 purpose is to forward requests to another resource (its target), usually 170 in a different collection. In this way, it provides access to the 171 target resource from another collection. It redirects most requests to 172 the target resource using the HTTP 302 (Moved Temporarily) status code, 173 thereby providing a form of mediated access to the target resource. 175 The BIND method defined here provides a different mechanism for allowing 176 a single resource to appear in multiple collections. BIND lets clients 177 associate a new URI with an existing resource, and this URI can then be 178 used to submit requests to the resource. Since URIs in WebDAV are 179 hierarchical, and correspond to a hierarchy of collections in resource 180 space, the BIND method also has the effect of adding the resource to a 181 collection. As new URIs are associated with the resource, it appears in 182 additional collections. 184 These two approaches to allowing clients to add a single resource to 185 multiple collections have very different characteristics: 187 A redirect reference is a resource, and so can have properties of its 188 own. Such information as who created the reference, when, and why can 189 be stored on the redirect reference resource. Since redirect references 190 are implemented using HTTP 302 responses, it generally takes two round 191 trips to submit a request to the intended resource. Servers are not 192 required to enforce the integrity of redirect references. Redirect 193 references work equally well for local resources and for resources that 194 reside on a different server from the reference. 196 By contrast, a BIND request does not create a new resource, but simply 197 makes available a new URI for submitting requests to an existing 198 resource. The new URI can be used like any other URI when submitting a 199 request to a resource. Only one round trip is needed to submit a 200 request to the intended target. Servers are required to enforce the 201 integrity of the relationships between the new URIs clients create and 202 the resources associated with them. Consequently, it is unlikely that 203 servers will support BIND requests that cross server boundaries. 205 The remainder of this specification is organized as follows. Section 3 206 defines terminology used in the rest of the specification, while Section 207 4 briefly overviews bindings. Section 5 specified the BIND method, used 208 to create bindings. Sections 6 through 10 discuss the relationships 209 between bindings and other HTTP and WebDAV methods. Sections 11 and 12 210 define mechanisms for tracking bindings. Sections 13 through 16 define 211 the new status codes, headers, properties, and XML elements needed to 212 support bindings. Section 17 discusses compliance and capability 213 discovery. Security concerns, internationalization issues, and IANA 214 considerations are described in Sections 18 through 20. The remaining 215 sections provide other supporting information. 217 3 Terminology 219 The terminology used here follows and extends that in the WebDAV 220 Distributed Authoring Protocol specification [WebDAV]. Definitions of 221 the terms resource, Uniform Resource Identifier (URI), and Uniform 222 Resource Locator (URL) are provided in [URI]. 224 URI Mapping 225 A relation between an absolute URI and a resource. For an 226 absolute URI U and the resource it identifies R, the URI mapping 227 can be thought of as (U => R). Since a resource can represent 228 items that are not network retrievable, as well as those that are, 229 it is possible for a resource to have zero, one, or many URI 230 mappings. Mapping a resource to an "http" scheme URL makes it 231 possible to submit HTTP protocol requests to the resource using 232 the URL. 234 Path Segment 235 Informally, the characters found between slashes ("/") in a URI. 236 Formally, as defined in section 3.3 of [URI]. 238 Binding 239 A relation between a single path segment (in a collection) and a 240 resource. A binding is part of the state of a collection. If two 241 different collections contain a binding between the same path 242 segment and the same resource, these are two distinct bindings. 243 So for a collection C, a path segment S, and a resource R, the 244 binding can be thought of as C:(S -> R). Bindings create URI 245 mappings, and hence allow requests to be sent to a single resource 246 from multiple locations in a URI namespace. 248 The following figure can be used to illustrate how bindings create 249 URI mappings. 251 +-----------------------------+ 252 | root collection | 253 |-----------------------------| 254 | bindings: | 255 | | 256 | Coll1 Coll2 Coll3 | 257 | | | \ | 258 +---|-------|--------\--------+ 259 | | \ 260 | | \ 261 +-------------------+ +----------------------+ 262 | collection C1 | | collection C2 | 263 |-------------------| |----------------------| 264 | bindings: | | bindings: | 265 | | | | 266 | foo bar | | foo | 267 | | \ | | / | 268 +--|------\---------+ +-/--------------------+ 269 | \ / 270 | \ / 271 | \ / 272 | \ / 273 +--------------+ +---------------+ 274 | resource R1 | | resource R2 | 275 +--------------+ +---------------+ 277 Figure 2 278 Since there are two bindings in the root collection, Coll1 and 279 Coll2, to collection C1, the single binding C1:(foo -> R1) between 280 foo and resource R1 in collection C1 creates two URI mappings, 281 /Coll1/foo and /Coll2/foo, to resource R1. Each of these URI 282 mappings can be used to submit requests to R1. The binding 283 C1:(bar -> R2) between bar and resource R2 in collection C1 and 284 the binding C2:(foo -> R2) between foo and resource R2 in 285 collection C2 create altogether 3 URI mappings to resource R2: 286 /Coll1/bar, /Coll2/bar, and /Coll3/foo. All 3 URI mappings can be 287 used to submit requests to resource R2. 289 Collection 290 A resource that contains, as part of its state, a set of bindings 291 that identify member resources. 293 Internal Member URI 294 Informally, the complete set of URLs by which a collection�s 295 member is known. Formally, the URI element U of a URI mapping 296 (U => R), created by a binding that is contained in a collection. 297 The following figure illustrates the relationship between bindings 298 and internal member URIs in a collection: 300 +-----------------------------+ 301 | root collection | 302 |-----------------------------| 303 | internal member URIs: | 304 | | 305 | /Coll1/ | 306 | /Coll2/ | 307 | /Coll3/ | 308 |-----------------------------| 309 | bindings: | 310 | | 311 | Coll1 Coll2 Coll3 | 312 | | | \ | 313 +---|-------|--------\--------+ 314 | | \ 315 | | \ 316 +----------------------+ +----------------------+ 317 | collection C1 | | collection C2 | 318 |----------------------| |----------------------| 319 | internal member URIs:| | internal member URIs:| 320 | | | | 321 | /Coll1/foo | | /Coll3/foo | 322 | /Coll2/foo | |----------------------| 323 | /Coll1/bar | | bindings: | 324 | /Coll2/bar | | | 325 |----------------------| | foo | 326 | bindings: | | / | 327 | | +-/--------------------+ 328 | foo bar | / 329 | | \ | / 330 +--|------\------------+ / 331 | \ / 332 | \ / 333 | \ / 334 | \ / 335 +--------------+ +---------------+ 336 | resource R1 | | resource R2 | 337 +--------------+ +---------------+ 339 Figure 3 341 The URI elements of all URI mappings created by a collection's 342 bindings are internal member URIs of the collection. 344 However, for a given request, only the URIs from those URI 345 mappings that incorporate the Request-URI are treated as internal 346 member URIs. For example, in Figure 3 above, if a PROPFIND 347 request with "Depth: infinity" is submitted to collection C1 using 348 the Request-URI /Coll1/, only the URI mappings starting with the 349 Request-URI would be listed as internal member URIs. The response 350 would include only /Coll1/ itself and the internal member URIs 351 /Coll1/foo and /Coll1/bar. This is done to prevent large amounts 352 of duplicate information from being returned for operations on 353 collections. 355 In [WebDAV], a collection is defined as containing a list of 356 internal member URIs, where an internal member URI is the URI of 357 the collection, plus a single path segment. This definition 358 combines the two concepts of binding and URI mapping that are 359 separated in this specification. As a result, this specification 360 redefines a collection's state to be a set of bindings, and 361 redefines an internal member URI to be the URI of a URI mapping 362 derived from a binding. After this redefinition, an internal 363 member URI can be used when reading [WebDAV] without loss of 364 meaning. For purposes of interpretation, when [WebDAV] discusses a 365 collection "containing" an internal member URI, this should be 366 read as the collection containing a binding whose mapping to a URI 367 creates an internal member URI, in this sense "containing" the 368 internal member URI. The authors of this specification anticipate 369 and recommend that future revisions of [WebDAV] perform a full 370 reconciliation of terms between these two specifications. 372 3.1 Rationale for Distinguishing Bindings from URI Mappings 374 Consider again collection C1 in Figure 3. If we had only the notion of 375 URI mappings, we would be forced to say that C1's membership was defined 376 by the list of internal member URIs. If these URIs identify the 377 membership, and are part of the state of the collection, then the act of 378 making the collection available via a new URI has the effect of changing 379 the collection�s membership, hence changing the collection�s state. This 380 is undesirable, since ideally a collection�s membership should remain 381 the same, no matter what URIs can be used to access the collection. What 382 is needed is a way to separate the final segment of a URI from the 383 collection�s URI contribution. 385 The notion of binding is introduced to separate the final segment of a 386 URI from its parent collection�s contribution. This done, a collection 387 can be defined as containing a set of bindings, thus permitting a new 388 mapping to be defined to a collection without modifying its membership 389 state. We introduce the concept of URI mapping to combine together the 390 collection�s URI and a binding�s segment to create a full URI that can 391 be used in protocol requests. Finally, the internal member URI, first 392 defined in [WebDAV], is redefined here to maintain backward 393 compatibility with that specification. 395 4 Overview of Bindings 397 Bindings are part of the state of a collection. In general, there is a 398 one-to-many correspondence between a collection's bindings and its 399 internal member URIs, as illustrated in Figure 3 above. The URI segment 400 associated with a resource by one of a collection's bindings is also the 401 final segment of one or more of the collection's internal member URIs. 402 The final segment of each internal member URI identifies one of the 403 bindings that is part of the collection's state. 405 Bindings are not unique to advanced collections, although the BIND 406 method for explicitly creating bindings is introduced here. Existing 407 methods that create resources, such as PUT, MOVE, COPY, and MKCOL, 408 implicitly create bindings. There is no difference between implicitly 409 created bindings and bindings created with BIND. 411 The identity of a binding C:(S -> R) is determined by the URI segment 412 (in its collection) and the resource that the binding associates. If 413 the resource goes out of existence (as a result of some out-of-band 414 operation), the binding also goes out of existence. If the URI segment 415 comes to be associated with a different resource, the original binding 416 ceases to exist and another binding is created. 418 Since a binding is a relation between a path segment in a collection and 419 a resource, it would be very undesirable if one binding could be 420 destroyed as a side effect of operating on the resource through a 421 different binding. It is not acceptable for a MOVE through one binding 422 to disrupt another binding, turning that binding into a dangling path 423 segment. Nor is it acceptable for a server, after performing a DELETE 424 through one binding, to reclaim the system resources associated with its 425 resource while other bindings to the resource remain. Implementations 426 MUST ensure the integrity of bindings. 428 5 BIND Method 430 5.1 Overview of BIND 432 The BIND method creates a new binding between the resource identified by 433 the Request-URI and the final segment of the Destination header (minus 434 any trailing slash). This binding is added to the collection identified 435 by the Destination header minus its trailing slash (if present) and 436 final segment. The Destination header is defined in Section 9.3 of 437 [WebDAV]. 439 If a server cannot guarantee the binding behavior specified here, 440 including the guarantee of the integrity of the binding, the BIND 441 request MUST fail. 443 Note: It is especially difficult to maintain the integrity of cross- 444 server bindings. Unless the server where the resource resides knows 445 about all bindings on all servers to that resource, it may unwittingly 446 destroy the resource or move it without notifying another server that 447 manages a binding to the resource. For example, if server A permits 448 creation of a binding to a resource on server B, server A must notify 449 server B about its binding and must have an agreement with B that B will 450 not destroy the resource while A's binding exists. Otherwise server B 451 may receive a DELETE request that it thinks removes the last binding to 452 the resource and destroy the resource while A's binding still exists. 453 Since most servers will be forced to fail cross-server BIND requests 454 because they are unable to guarantee the integrity of cross-server 455 bindings, status code 508 (Cross-server Binding Forbidden) is defined in 456 Section 13.3. 458 If the Destination header does not contain a path segment (i.e., it 459 consists simply of a slash "/"), the BIND operation MUST fail and report 460 a 400 (Bad Request) status code. A binding consists of a (collection, 461 segment, resource) triple, and the Destination header is required to 462 specify the collection and segment of this triple. 464 After successful processing of a BIND request, it MUST be possible for 465 clients to use the URI in the Destination header to submit requests to 466 the resource identified by the Request-URI. 468 By default, if the Destination header identifies an existing binding, 469 the new binding replaces the existing binding. This default binding 470 replacement behavior can be overridden using the Overwrite header 471 defined in Section 9.6 of [WebDAV]. 473 5.2 Bindings to Collections 475 BIND can create a binding to a collection resource. A collection 476 accessed through such a binding behaves exactly as would a collection 477 accessed through any other binding. 479 Bindings to collections can result in loops, which servers MUST detect 480 when processing "Depth: infinity" requests. It is sometimes possible to 481 complete an operation in spite of the presence of a loop. However, the 482 506 (Loop Detected) status code is defined in Section 13.1 for use in 483 contexts where an operation is terminated because a loop was 484 encountered. Some servers may wish to prevent loops from being created 485 at all. These servers MAY fail BIND requests with the 507 (Loop 486 Forbidden) status code defined in Section 13.2. 488 Creating a new binding to a collection makes each resource associated 489 with a binding in that collection accessible via a new URI, and thus 490 creates new URI mappings to those resources but no new bindings. 492 For example, suppose a new binding COLLX is created for collection C1 in 493 the figure below. It immediately becomes possible to access resource R1 494 using the URI /COLLX/x.gif and to access resource R2 using the URI 495 /COLLX/y.jpg, but no new bindings for these child resources were 496 created. This is because bindings are part of the state of a 497 collection, and associate a URI that is relative to that collection with 498 its target resource. No change to the bindings in Collection C1 is 499 needed to make its children accessible using /COLLX/x.gif and 500 /COLLX/y.jpg. 502 +-------------------------+ 503 | Root Collection | 504 | (properties) | 505 | bindings: | 506 | coll1 COLLX | 507 +-------------------------+ 508 | / 509 | / 510 | / 511 +------------------+ 512 | Collection C1 | 513 | (properties) | 514 | bindings: | 515 | x.gif y.jpg | 516 +------------------+ 517 | \ 518 | \ 519 | \ 520 +-------------+ +-------------+ 521 | Resource R1 | | Resource R2 | 522 +-------------+ +-------------+ 524 Figure 6 526 5.3 URI Mappings Created by a BIND 528 Suppose a BIND request causes a binding from "Binding-Name" to resource 529 R to be added to a collection, C. Then if C-MAP is the set of URI's 530 that were mapped to C before the BIND request, then for each URI "C-URI" 531 in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following 532 the BIND request. 534 Note that if R is a collection, additional URI mappings are created to 535 the descendents of R. Also note that if a binding is made in collection 536 C to C itself (or to a parent of C), an infinite number of mappings is 537 introduced. 539 5.4 Example: URI Mappings Created by a BIND 541 For example, if a binding from "foo.html" to R is added to the 542 collection C, and if the following URI's are mapped to C: 544 http://www.fuzz.com/A/1 545 http://fuzz.com/A/one 547 then the following new mappings to R are introduced: 549 http://www.fuzz.com/A/1/foo.html 550 http://fuzz.com/A/one/foo.html 552 If a binding from "myself" to C is then added to C, the following 553 infinite number of additional mappings to C are introduced: 555 http://www.fuzz.com/A/1/myself 556 http://www.fuzz.com/A/1/myself/myself 557 ... 559 and the following infinite number of additional mappings to R are 560 introduced: 562 http://www.fuzz.com/A/1/myself/foo.html 563 http://www.fuzz.com/A/1/myself/myself/foo.html 564 ... 566 5.5 BIND Status Codes 568 201 (Created): The binding was successfully created. 570 400 (Bad Request): The client set an invalid value for the Destination 571 header or Request-URI. 573 412 (Precondition Failed): The Overwrite header is "F", and a binding 574 already exists for the Destination header. 576 507 (Loop Forbidden): The server does not support bindings that create 577 loops. 579 508 (Cross-Server Binding Forbidden): The server is unable to create the 580 requested binding because it would bind a segment in a collection on one 581 server to a resource on a different server. 583 5.6 Example: BIND 585 >> Request: 587 BIND /pub/i-d/draft-webdav-protocol-08.txt HTTP/1.1 588 Host: www.ics.uci.edu 589 Destination: http://www.ics.uci.edu/~whitehead/dav/spec08.txt 591 >> Response: 593 HTTP/1.1 201 Created 595 The server created a new binding, associating "spec08.txt" with the 596 resource identified by the URL "http://www.ics.uci.edu/pub/i-d/draft- 597 webdav-protocol-08.txt". Clients can now use the URI in the Destination 598 header, "http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit 599 requests to that resource. As part of this operation, the server added 600 the binding "spec08.txt" to collection /~whitehead/dav/. 602 6 DELETE and Bindings 604 The DELETE method was originally defined in [HTTP]. This section 605 redefines the behavior of DELETE in terms of bindings, an abstraction 606 not available when writing [HTTP]. [HTTP] states that "the DELETE method 607 requests that the origin server delete the resource identified by the 608 Request-URI." Because [HTTP] did not distinguish between bindings and 609 resources, the intent of its definition of DELETE is unclear. The 610 definition presented here is a clarification of the definition in 611 [HTTP]. 613 The DELETE method requests that the server remove the binding between 614 the resource identified by the Request-URI and the binding name, the 615 last path segment of the Request-URI. The binding MUST be removed from 616 its parent collection, identified by the Request-URI minus its trailing 617 slash (if present) and final segment. The All-Bindings header may be 618 used with DELETE to request that the server remove all bindings to the 619 resource identified by the Request-URI. 621 Once a set of resources are unreachable by any URI mapping, the server 622 MAY reclaim system resources associated with those resources. If DELETE 623 removes a binding to a resource, but there remain URI mappings to that 624 resource, the server MUST NOT reclaim system resources associated with 625 the resource. 627 Although [WebDAV] allows a DELETE to be a non-atomic operation, the 628 DELETE operation defined here is atomic. In particular, a DELETE with 629 an All-Bindings header MUST fail if any of the bindings to the resource 630 cannot be deleted. In addition, a DELETE on a hierarchy of resources is 631 simply the removal of a binding to the collection identified by the 632 Request-URI, and so is a single (and therefore atomic) operation. 634 Section 8.6.1 of [WebDAV] states that during DELETE processing, a server 635 "MUST remove any URI for the resource identified by the Request-URI from 636 collections which contain it as a member." Servers that support 637 bindings SHOULD NOT follow this requirement unless the All-Bindings 638 header is included in the request. 640 7 COPY and Bindings 642 As defined in Section 8.8 of [WebDAV], COPY causes the resource 643 identified by the Request-URI to be duplicated, and makes the new 644 resource accessible using the URI specified in the Destination header. 645 Upon successful completion of a COPY, a new binding is created between 646 the last path segment of the Destination header, and the destination 647 resource. The new binding is added to its parent collection, identified 648 by the Destination header minus its trailing slash (if present) and 649 final segment. 651 As an example, suppose that a COPY is issued to URI 3 for resource R 652 below (which is also mapped to URI 1 and URI 2), with the Destination 653 header set to URIX. After successful completion of the COPY operation, 654 resource R is duplicated to create resource R', and a new binding has 655 been created which creates at least the URI mapping between URIX and the 656 new resource (although other URI mappings may also have been created). 658 URI 1 URI 2 URI 3 URIX 659 | | | | 660 | | | <---- URI Mappings ----> | 661 | | | | 662 +---------------------+ +------------------------+ 663 | Resource R | | Resource R' | 664 +---------------------+ +------------------------+ 666 Figure 7 668 It might be thought that a COPY request with "Depth: 0" on a collection 669 would duplicate its bindings, since bindings are part of the 670 collection's state. This is not the case, however. The definition of 671 Depth in [WebDAV] makes it clear that a "Depth: 0" request does not 672 apply to a collection's members. Consequently, a COPY with "Depth: 0" 673 does not duplicate the bindings contained by the collection. 675 8 MOVE and Bindings 677 The MOVE method has the effect of creating a new binding to a resource 678 (at the Destination), and removing an existing binding (at the Request- 679 URI). The name of the new binding is the last path segment of the 680 Destination header, and the new binding is added to its parent 681 collection, identified by the Destination header minus its trailing 682 slash (if present) and final segment. 684 As an example, suppose that a MOVE is issued to URI 3 for resource R 685 below (which is also mapped to URI 1 and URI 2), with the Destination 686 header set to URIX. After successful completion of the MOVE operation, 687 a new binding has been created which creates at least the URI mapping 688 between URIX and resource R (although other URI mappings may also have 689 been created). The binding corresponding to the final segment of URI 3 690 has been removed, which also causes the URI mapping between URI 3 and R 691 to be removed. 693 >> Before Request: 695 URI 1 URI 2 URI 3 696 | | | 697 | | | <---- URI Mappings 698 | | | 699 +---------------------+ 700 | Resource R | 701 +---------------------+ 703 >> After Request: 705 URI 1 URI 2 URIX 706 | | | 707 | | | <---- URI Mappings 708 | | | 709 +---------------------+ 710 | Resource R | 711 +---------------------+ 713 Figure 8 715 Although [WebDAV] allows a MOVE on a collection to be a non-atomic 716 operation, the MOVE operation defined here MUST be atomic. Even when 717 the Request-URI identifies a collection, the MOVE operation involves 718 only removing one binding to that collection and adding another. There 719 are no operations on bindings to any of its children, so the case of 720 MOVE on a collection is the same as the case of MOVE on a non-collection 721 resource. Both are atomic. 723 8.1 Implementation Note 725 In some situations, particularly when the destination is on a different 726 server from the original resource, the server may implement MOVE by 727 performing a COPY, performing some consistency maintenance on bindings 728 and properties, and then performing a DELETE. In the end, all of the 729 original bindings except the one corresponding to the Request-URI will 730 be associated with the new resource. The binding corresponding to the 731 URI in the Destination header will be associated with the new resource. 732 And the original resource together with the binding corresponding to the 733 Request-URI will have been deleted. This implementation is logically 734 equivalent to the definition of MOVE given in Section 8 above. 736 The consistency maintenance processing that is required for this 737 implementation is as follows: 739 The DAV:creationdate property of the new resource SHOULD have the same 740 value as the DAV:creationdate property of the old resource. 742 The DAV:getlastmodified property of the new resource SHOULD have the 743 same value as the DAV:getlastmodified property of the old resource. 745 All URIs that were bound to the original resource except for the 746 Request-URI MUST be bound instead to the new resource. 748 Consider again the case where a MOVE is issued to URI 3 for resource R 749 (which is also mapped to URI 1 and URI 2), with the Destination header 750 set to URIX. Unlike the previous example, in this implementation, after 751 successful completion of the MOVE operation, resource R has been 752 duplicated as resource R'. The original bindings corresponding to URI 1 753 and URI2 are now associated with R'. The binding corresponding to the 754 Request-URI (URI 3) has been removed. And a new binding has been 755 created which creates at least the URI mapping between URIX and resource 756 R'. Note that the server may reclaim the storage associated with 757 resource R once the MOVE operation has finished. 759 >> Before Request: 761 URI 1 URI 2 URI 3 762 | | | 763 | | | <---- URI Mappings 764 | | | 765 +---------------------+ 766 | Resource R | 767 +---------------------+ 769 >> After Request: 771 URI1 URI2 --------------------------------- URIX 772 | | | 773 ----------------------------------------- | | 774 | | | 775 +---------------------+ +------------------------+ 776 | Resource R | | Resource R' | 777 +---------------------+ +------------------------+ 779 Figure 9 781 8.2 MOVE and Locks 783 The MOVE semantics defined in Section 8 above implies lock behavior that 784 is different from that specified in Section 7.7 of [WebDAV]. Section 785 7.7 of [WebDAV] states, "A successful MOVE request on a write locked 786 resource MUST NOT move the write lock with the resource." 788 However, the semantics of MOVE defined here say that MOVE does nothing 789 but remove one binding to a resource and create another binding to the 790 same resource. The resource itself is not modified. Its state after 791 the MOVE should be as nearly as possible identical to its state before 792 the MOVE. Therefore, if it was locked before the MOVE, it MUST be 793 locked after the MOVE, and with the same lock token. If this 794 requirement cannot be met, the MOVE MUST fail. 796 Specifically, the following rules apply to MOVE and locks: 798 1. If there is a lock on the resource before the MOVE, and that lock is 799 rooted at the resource (that is, it is not inherited from a parent 800 collection), the resource MUST still have that same lock after the 801 MOVE. (This conflicts with [WebDAV].) 802 2. If there is a lock on the resource at the destination URL before the 803 MOVE, and that lock is rooted at the destination resource (that is, 804 it is not inherited from a parent collection), that lock does not 805 apply to the resource that is moved to that Destination after the 806 MOVE. (This is consistent with [WebDAV].) 807 3. If the resource being moved inherits a lock from a parent collection, 808 and the resource is moved out of the tree affected by that lock, the 809 lock no longer applies to the resource after the MOVE. (This is 810 consistent with [WebDAV].) 811 4. If the resource at the destination URL inherits a lock from a parent 812 collection before the MOVE, the moved resource inherits that lock 813 after the MOVE. (This is consistent with [WebDAV].) 814 5. If there is a lock on the resource before the MOVE, and that lock is 815 rooted at the resource, and the resource at the destination URL 816 inherits a lock from a parent collection before the MOVE, the MOVE 817 MUST fail due to a conflict between rules 1 and 4. (This conflicts 818 with [WebDAV].) 819 6. If a collection is MOVEd, and there are some locked resources in that 820 collection, those resources MUST still have the same locks after the 821 MOVE. (This conflicts with [WebDAV].) 823 The results of applying these rules are as follows: 825 +-------------------------------------------------------------------+ 826 | Before MOVE | After MOVE | 827 |---------------------------------------------| | 828 | Source Resource S | Destination Resource D | | 829 |-------------------------------------------------------------------- 830 | no lock | no lock | no lock | 831 |-------------------|-------------------------|---------------------| 832 | no lock | lock rooted at D | no lock | 833 |-------------------|-------------------------|---------------------| 834 | no lock | inherited lock | D's inherited lock | 835 | | | applies | 836 |-------------------|-------------------------|---------------------| 837 | lock rooted at S | no lock | S's lock applies | 838 |-------------------|-------------------------|---------------------| 839 | lock rooted at S | lock rooted at D | S's lock applies | 840 |-------------------|-------------------------|---------------------| 841 | lock rooted at S | inherited lock | MOVE fails | 842 |-------------------|-------------------------|---------------------| 843 | inherited lock | no lock | no lock | 844 |-------------------|-------------------------|---------------------| 845 | inherited lock | lock rooted at D | no lock | 846 |-------------------|-------------------------|---------------------| 847 | inherited lock | inherited lock | D's inherited lock | 848 | | | applies | 849 +-------------------------------------------------------------------+ 851 9 LOCK and UNLOCK 853 Bindings do not change the fundamental requirement on locks, stated in 854 section 8.10.3 of [WebDAV], that "a LOCK request on a resource MUST NOT 855 succeed if it can not be honored by all the URIs through which the 856 resource is accessible". The LOCK method locks the resource, and a lock 857 is visible via all URIs mapped to that resource. Similarly, a successful 858 UNLOCK issued via any URI mapping to a resource removes the lock from 859 the resource, and this lock removal is visible via all URI mappings. 861 When a resource is locked, the lock owner expects to be able to access 862 the resource -- using the same Request-URI that he used to lock the 863 resource -- for as long as he holds the lock. This would not be 864 possible if another user could move or delete any of the collections 865 corresponding to segments of the request-URI. 867 Consequently, for the duration of a lock, it MUST NOT be possible for a 868 principal other than the lock owner to make a locked resource 869 inaccessible via the URI mapping used to lock the resource. Only the 870 lock owner can move or delete any of the collections corresponding to 871 segments of the Request-URI. This restriction does not prevent others 872 from modifying those collections, by adding members to them, removing 873 members from them, or changing their property values. 875 For example, if a user locks /plants/herbs/rosemary.html, it is not 876 possible for another user to move /plants/herbs/ to 877 /plants/flowering/herbs/, or to completely delete /plants/herbs/, though 878 it is possible this delete operation may succeed in deleting everything 879 except for /plants/herbs/rosemary.html and /plants/herbs/. 881 Note that this requirement is weaker than the one implied by [WebDAV]. 882 Sections 8.9.6 and 8.9.2 of [WebDAV] together imply that all URI 883 mappings to a locked resource must be protected. They forbid moving or 884 deleting any collection that has a locked resource as a descendent. It 885 is likely that in an environment where multiple URI mappings to a single 886 resource are common, it will be prohibitively expensive to enforce this 887 stronger constraint. 889 10 Bindings and Other Methods 891 This section describes the interaction of bindings with those HTTP 892 methods not yet explicitly discussed. The semantics of the methods GET, 893 HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of 894 PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. 896 For these methods, no new complexities are introduced by allowing 897 explicit creation of multiple bindings to the same resource. When 898 applied to static resources (that is, resources that are not CGI 899 scripts, Active Server Pages, etc.), they obey the following rule: 901 o The method submitted through one URI mapping MUST produce the same 902 results as the same method, with the same headers and entity body, 903 submitted through any other URI mapping to the same resource. 905 When applied to dynamic resources, it is not possible to state any such 906 rule. For any method, a dynamic resource may be sensitive to the URI 907 mapping used to access it. The resource may produce different results 908 depending upon which URI mapping was used to submit the request. 910 Nevertheless, servers MAY allow new bindings to dynamic resources to be 911 created using BIND. 913 11 Determining Whether Two Bindings Are to the Same Resource 915 It is useful to have some way of determining whether two bindings are to 916 the same resource. Two different resources might have identical 917 contents and identical values for the properties defined in [WebDAV]. 918 Although the DAV:bindings property defined in Section 15.1 provides this 919 information, it is an optional property. 921 The REQUIRED DAV:guid property defined in Section 15.2 is a resource 922 identifier, which MUST be unique across all resources for all time. If 923 the values of DAV:guid returned by PROPFIND requests through two 924 bindings are identical, the client can be assured that the two bindings 925 are to the same resource. 927 The DAV:guid property is created, and its value assigned, when the 928 resource is created. The value of DAV:guid MUST NOT be changed. Even 929 after the resource is no longer accessible through any URI, that value 930 MUST NOT be reassigned to another resource's DAV:guid property. 932 11.1 davresourceid URI Scheme 934 The value of DAV:guid is a URI and may use any URI scheme that 935 guarantees the uniqueness of the value across all resources for all 936 time. The davresourceid URI scheme defined here is an example of an 937 acceptable URI scheme. 939 The davresourceid URI scheme requires the use of the Universal Unique 940 Identifier (UUID) mechanism, as described in [ISO-11578]. Davresourceid 941 generators may choose between two methods of creating the identifiers. 942 They can either generate a new UUID for every davresourceid they create 943 or they can create a single UUID and then add extension characters. If 944 the second method is selected, then the program generating the 945 extensions MUST guarantee that the same extension will never be used 946 twice with the associated UUID. 948 DAVResourceID-URI = "davresourceid:" UUID [Extension] ; The UUID 949 production is the string representation of a UUID, as defined in [ISO- 950 11578]. Note that white space (LWS) is not allowed between elements of 951 this production. 953 Extension = path ; path is defined in Section 3.3 of [URI]. 955 12 Discovering the Bindings to a Resource 957 An OPTIONAL DAV:bindings property on a resource provides a list of the 958 bindings that associate URI segments with that resource. If the 959 DAV:bindings property exists on a given resource, it MUST provide a 960 complete list of all bindings to that resource. By retrieving this 961 property, a client can discover the bindings that point to the resource 962 and the collections that contain bindings to the resource. As for all 963 DAV: properties, this specification is silent as to how the DAV:bindings 964 property is implemented on the server. 966 Rationale: A number of scenarios require clients to navigate from a 967 resource to the bindings that point to it, and to the collections that 968 contain those bindings. This capability is particularly important for 969 Document Management Systems. Their clients may need to determine, for 970 any object in the DMS, what collections contain bindings to that object. 971 This information can be used for upward navigation through a hierarchy 972 or to discover related documents in other collections. 974 Risks: When deciding whether to support the DAV:bindings property, 975 server implementers / administrators should balance the benefits it 976 provides against the cost of maintaining the property and the security 977 risks enumerated in Sections 18.4 and 18.5. 979 13 Status Codes 981 13.1 506 Loop Detected 983 The 506 (Loop Detected) status code indicates that the server terminated 984 an operation because it encountered an infinite loop while processing a 985 request with "Depth: infinity". 987 When this status code is the top-level status code for the operation, it 988 indicates that the entire operation failed. In this case, the Loop 989 header can be used in the response to identify the URI that caused the 990 failure. 992 When this status code occurs inside a multistatus response, it indicates 993 only that a loop is being terminated, but does not indicate failure of 994 the operation as a whole. 996 For example, consider a PROPFIND request on the following collection: 998 Coll-1 (bound to collection C) 999 Foo (bound to resource R) 1000 Bar (bound to collection C) 1002 >> Request: 1004 PROPFIND /Coll-1/ HTTP/1.1 1005 Host: www.somehost.com 1006 Depth: infinity 1007 Content-Type: text/xml; charset="utf-8" 1008 Content-Length: xxx 1010 1011 1012 1013 1014 1015 1017 >> Response: 1019 HTTP/1.1 207 Multi-Status 1020 Content-Type: text/xml; charset="utf-8" 1021 Content-Length: xxx 1023 1024 1025 1026 http://www.somehost.com/Coll-1/ 1027 1028 1029 Loop Demo 1030 1031 HTTP/1.1 200 OK 1032 1033 1034 1035 http://www.somehost.com/Coll-1/Foo 1036 1037 1038 Bird Inventory 1039 1040 HTTP/1.1 200 OK 1041 1042 1043 1044 http://www.somehost.com/Coll-1/Bar 1045 1046 1047 1049 1050 HTTP/1.1 506 Loop Detected 1051 1052 1053 1055 13.2 507 Loop Forbidden 1057 The server does not allow creation of bindings that create loops. 1059 13.3 508 Cross-Server Binding Forbidden 1061 The server is unable to create the requested binding because it would 1062 bind a segment in a collection on one server to a resource on a 1063 different server. 1065 14 Headers 1067 14.1 All-Bindings Request Header 1069 All-Bindings = "All-Bindings" ":" 1071 The All-Bindings request header may be used with DELETE requests to 1072 instruct the server to remove all bindings to the resource identified by 1073 the Request-URI. 1075 14.2 Loop Header 1077 Loop = "Loop" ":" Coded-URL 1079 The Loop header is used in 506 (Loop Detected) responses to identify the 1080 URI that caused the operation to fail. Note that the Coded-URL 1081 production is defined in Section 9.4 of [WebDAV]. 1083 15 Properties 1085 15.1 bindings Property 1087 Name: bindings 1088 Namespace: DAV: 1089 Purpose: Enables clients to discover, for any resource, what bindings 1090 point to it and what collections contain those bindings. 1091 This is an optional property. If present on a given 1092 resource, it is a read-only property, maintained by the 1093 server, and contains a complete list of all bindings to that 1094 resource. 1095 Value: List of href / segment pairs for all of the bindings that 1096 associate URI segments with the resource. The href is an 1097 absolute URI for one URI mapping of the collection 1098 containing the binding. Since there may be multiple URI 1099 mappings for this collection, it is necessary to select one 1100 (preferably the URI mapping contained in the Request-URI of 1101 the BIND request) for use in the DAV:bindings property. The 1102 segment is the URI segment that identifies the binding 1103 within that collection. 1105 1107 15.2 guid Property 1109 Name: guid 1110 Namespace: DAV: 1111 Purpose: Enables clients to determine whether two bindings are for 1112 the same resource. 1113 Value: URI that is guaranteed unique across all resources for all 1114 time. It may be of the davresourceid URI scheme defined in 1115 Section 12.1 or any other URI scheme that guarantees this 1116 uniqueness. 1118 1120 16 XML Elements 1122 16.1 segment XML Element 1124 Name: segment 1125 Namespace: DAV: 1126 Purpose: The segment that names a binding, used in the DAV:bindings 1127 property. 1128 Value: segment ; as defined in section 3.3 of [URI]. 1130 1132 17 Capability Discovery 1134 Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes 1135 with the DAV header in responses to OPTIONS, to indicate which parts of 1136 the Web Distributed Authoring protocols the resource supports. This 1137 specification defines an OPTIONAL extension to [WebDAV]. It defines a 1138 new compliance class, called bindings, for use with the DAV header in 1139 responses to OPTIONS requests. If a resource does support bindings, its 1140 response to an OPTIONS request MUST indicate that it does, by listing 1141 the new BIND method as one it supports, and by listing the new bindings 1142 compliance class in the DAV header. 1144 When responding to an OPTIONS request, any type of resource can include 1145 bindings in the value of the DAV header. Doing so indicates that the 1146 server permits a binding at the request URI. 1148 17.1 Example: Discovery of Support for Bindings 1150 >> Request: 1152 OPTIONS /somecollection/someresource HTTP/1.1 1153 HOST: somehost.org 1155 >> Response: 1157 HTTP/1.1 200 OK 1158 Date: Tue, 20 Jan 1998 20:52:29 GMT 1159 Connection: close 1160 Accept-Ranges: none 1161 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1162 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND 1163 Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1164 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH 1165 DAV: 1, 2, bindings 1167 The DAV header in the response indicates that the resource 1168 /somecollection/someresource is level 1 and level 2 compliant, as 1169 defined in [WebDAV]. In addition, /somecollection/someresource supports 1170 bindings. The Allow header indicates that BIND requests can be 1171 submitted to /somecollection/someresource. The Public header shows that 1172 other Request-URIs on the server support additional methods. 1174 18 Security Considerations 1176 This section is provided to make WebDAV applications aware of the 1177 security implications of this protocol. 1179 All of the security considerations of HTTP/1.1 and the WebDAV 1180 Distributed Authoring Protocol specification also apply to this protocol 1181 specification. In addition, bindings introduce several new security 1182 concerns and increase the risk of some existing threats. These issues 1183 are detailed below. 1185 18.1 Privacy Concerns 1187 In a context where cross-server bindings are supported, creating 1188 bindings on a trusted server may make it possible for a hostile agent to 1189 induce users to send private information to a target on a different 1190 server. 1192 18.2 Redirect Loops 1194 Although redirect loops were already possible in HTTP 1.1, the 1195 introduction of the BIND method creates a new avenue for clients to 1196 create loops accidentally or maliciously. If the binding and its target 1197 are on the same server, the server may be able to detect BIND requests 1198 that would create loops. Servers are required to detect loops that are 1199 caused by bindings to collections during the processing of any requests 1200 with "Depth: infinity". 1202 18.3 Bindings, and Denial of Service 1204 Denial of service attacks were already possible by posting URLs that 1205 were intended for limited use at heavily used Web sites. The 1206 introduction of BIND creates a new avenue for similar denial of service 1207 attacks. If cross-server bindings are supported, clients can now create 1208 bindings at heavily used sites to target locations that were not 1209 designed for heavy usage. 1211 18.4 Private Locations May Be Revealed 1213 If the DAV:bindings property is maintained on a resource, the owners of 1214 the bindings risk revealing private locations. The directory structures 1215 where bindings are located are available to anyone who has access to the 1216 DAV:bindings property on the resource. Moving a binding may reveal its 1217 new location to anyone with access to DAV:bindings on its resource. 1219 18.5 DAV:bindings and Denial of Service 1221 If the server maintains the DAV:bindings property in response to 1222 bindings created in other administrative domains, it is exposed to 1223 hostile attempts to make it devote resources to adding bindings to the 1224 list. 1226 19 Internationalization Considerations 1228 This specification follows the practices of [WebDAV] in encoding all 1229 human-readable content using XML [XML] and in the treatment of names. 1230 Consequently, this specification complies with the IETF Character Set 1231 Policy [Alvestrand]. 1233 WebDAV applications MUST support the character set tagging, character 1234 set encoding, and the language tagging functionality of the XML 1235 specification. This constraint ensures that the human-readable content 1236 of this specification complies with [Alvestrand]. 1238 As in [WebDAV}, names in this specification fall into three categories: 1239 names of protocol elements such as methods and headers, names of XML 1240 elements, and names of properties. Naming of protocol elements follows 1241 the precedent of HTTP, using English names encoded in USASCII for 1242 methods and headers. The names of XML elements used in this 1243 specification are English names encoded in UTF-8. 1245 For error reporting, [WebDAV] follows the convention of HTTP/1.1 status 1246 codes, including with each status code a short, English description of 1247 the code (e.g., 423 Locked). Internationalized applications will ignore 1248 this message, and display an appropriate message in the user's language 1249 and character set. 1251 For rationales for these decisions and advice for application 1252 implementors, see [WebDAV]. 1254 20 IANA Considerations 1256 This document uses the namespaces defined by [WebDAV] for properties and 1257 XML elements. All other IANA considerations mentioned in [WebDAV] also 1258 apply to this document. 1260 In addition, this document defines new HTTP/1.1 status codes 506, 507, 1261 and 508 in Section 13. 1263 21 Copyright 1265 To be supplied by the RFC Editor. 1267 22 Intellectual Property 1268 To be supplied by the RFC Editor. 1270 23 Acknowledgements 1272 This draft has benefited from thoughtful discussion by Jim Amsden, Steve 1273 Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer 1274 Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron 1275 Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj 1276 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry 1277 Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, 1278 Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, 1279 Kevin Wiggen, and others. 1281 24 References 1283 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1284 Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, 1285 Xerox. August, 1998. 1287 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1288 Levels." RFC 2119, BCP 14. Harvard University. March, 1997. 1290 [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup 1291 Language (XML)." World Wide Web Consortium Recommendation REC-xml- 1292 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 1294 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1295 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 1296 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. 1298 [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. 1299 Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. 1300 Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. 1302 [ISO-11578] ISO (International Organization for Standardization), 1303 ISO/IEC 11578:1996. "Information technology - Open Systems 1304 Interconnection - Remote Procedure Call (RPC)." 1306 [OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 1307 Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work 1308 in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine, 1309 CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. 1311 [RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 1312 Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work 1313 in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC 1314 Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. 1316 25 Authors' Addresses 1318 J. Slein 1319 Xerox Corporation 1320 800 Phillips Road, 105-50C 1321 Webster, NY 14580 1322 Email: jslein@crt.xerox.com 1323 E. J. Whitehead, Jr. 1324 Dept. of Information and Computer Science 1325 University of California, Irvine 1326 Irvine, CA 92697-3425 1327 Email: ejw@ics.uci.edu 1329 J. Davis 1330 CourseNet Systems 1331 170 Capp Street 1332 San Francisco, CA 94110 1333 Email: jrd3@alum.mit.edu 1335 G. Clemm 1336 Rational Software Corporation 1337 20 Maguire Road 1338 Lexington, MA 02173-3104 1339 Email: gclemm@rational.com 1341 C. Fay 1342 FileNet Corporation 1343 3565 Harbor Boulevard 1344 Costa Mesa, CA 92626-1420 1345 Email: cfay@filenet.com 1347 J. Crawford 1348 IBM 1349 Email: ccjason@us.ibm.com 1351 T. Chihaya 1352 DataChannel, Inc. 1353 155 108th Ave. N.E., Suite 400 1354 Bellevue, WA 98004 1355 Email: Tyson@DataChannel.com 1357 26 Appendices 1359 26.1 Appendix 1: Extensions to the WebDAV Document Type Definition 1361 1362 1363