idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-07.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 913 has weird spacing: '...ment of a 207...' == Line 914 has weird spacing: '...equests to th...' -- 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 (November 17, 2003) is 7459 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: 'WebDAV' is mentioned on line 1308, but not defined ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group J. Whitehead 3 Internet-Draft U.C. Santa Cruz 4 Expires: May 17, 2004 G. Clemm 5 IBM 6 J. Reschke, Ed. 7 greenbytes 8 November 17, 2003 10 WebDAV Redirect Reference Resources 11 draft-ietf-webdav-redirectref-protocol-07 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 17, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This specification defines redirect reference resources. A redirect 42 reference resource is a resource whose default response is an HTTP/ 43 1.1 302 (Found) status code, redirecting the client to a different 44 resource, the target resource. A redirect reference makes it 45 possible to access the target resource indirectly, through any URI 46 mapped to the redirect reference resource. There are no integrity 47 guarantees associated with redirect reference resources. 49 Distribution of this document is unlimited. Please send comments to 50 the Distributed Authoring and Versioning (WebDAV) working group at 51 w3c-dist-auth@w3.org [1], which may be joined by sending a message 52 with subject "subscribe" to w3c-dist-auth-request@w3.org [2]. 54 Discussions of the WEBDAV working group are archived at URL: http:// 55 lists.w3.org/Archives/Public/w3c-dist-auth/. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Overview of Redirect Reference Resources . . . . . . . . . . 8 63 5. Creating a Redirect Reference Resource . . . . . . . . . . . 9 64 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.2 Example: Creating a Redirect Reference Resource with 66 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Operations on Redirect Reference Resources . . . . . . . . . 12 68 7. Operations on Collections That Contain Redirect Reference 69 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.1 LOCK on a Collection That Contains Redirect References . . . 13 71 7.2 Example: PROPFIND on a Collection with Redirect Reference 72 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a 74 Collection with Redirect Reference Resources . . . . . . . . 16 75 7.4 Example: COPY on a Collection That Contains a Redirect 76 Reference Resource . . . . . . . . . . . . . . . . . . . . . 17 77 7.5 Example: LOCK on a Collection That Contains a Redirect 78 Reference Resource . . . . . . . . . . . . . . . . . . . . . 18 79 8. Operations on Targets of Redirect Reference Resources . . . 20 80 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 21 81 9.1 Example: Resolving a Relative URI in a Multi-Status 82 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 10. Redirect References to Collections . . . . . . . . . . . . . 23 84 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 25 86 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 25 87 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 26 89 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 27 90 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 27 91 14. Extensions to the DAV:response XML Element for 92 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 28 93 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 29 94 15.1 Example: Discovery of Support for Redirect Reference 95 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 16. Security Considerations . . . . . . . . . . . . . . . . . . 30 97 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 30 98 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 30 99 16.3 Redirect Reference Resources and Denial of Service . . . . . 30 100 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 30 101 17. Internationalization Considerations . . . . . . . . . . . . 32 102 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 103 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 104 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 105 Normative References . . . . . . . . . . . . . . . . . . . . 36 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 107 A. Changes to the WebDAV Document Type Definition . . . . . . . 38 108 B. Change Log (to be removed by RFC Editor before 109 publication) . . . . . . . . . . . . . . . . . . . . . . . . 39 110 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 39 111 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 39 112 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . . 39 113 B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . . 39 114 B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . . 39 115 C. Resolved issues (to be removed by RFC Editor before 116 publication) . . . . . . . . . . . . . . . . . . . . . . . . 40 117 C.1 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 40 118 C.2 rfc2606-compliance . . . . . . . . . . . . . . . . . . . . . 40 119 C.3 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 40 120 C.4 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 40 121 C.5 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 41 122 C.6 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 41 123 C.7 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 41 124 C.8 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 42 125 C.9 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 42 126 C.10 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 42 127 C.11 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 43 128 D. Open issues (to be removed by RFC Editor before 129 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44 130 D.1 old_clients . . . . . . . . . . . . . . . . . . . . . . . . 44 131 D.2 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 44 132 D.3 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 45 133 D.4 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 45 134 D.5 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 45 135 D.6 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 46 136 D.7 3-terminology-redirectref . . . . . . . . . . . . . . . . . 46 137 D.8 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 46 138 D.9 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 46 139 D.10 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 47 140 D.11 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 47 141 D.12 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 47 142 D.13 12.1-property-name . . . . . . . . . . . . . . . . . . . . . 48 143 D.14 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 48 144 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 145 Intellectual Property and Copyright Statements . . . . . . . 50 147 1. Introduction 149 This is one of a pair of specifications that extend the WebDAV 150 Distributed Authoring Protocol to enable clients to create new access 151 paths to existing resources. This capability is useful for several 152 reasons: 154 URIs of WebDAV-compliant resources are hierarchical and correspond to 155 a hierarchy of collections in resource space. The WebDAV Distributed 156 Authoring Protocol makes it possible to organize these resources into 157 hierarchies, placing them into groupings, known as collections, which 158 are more easily browsed and manipulated than a single flat 159 collection. However, hierarchies require categorization decisions 160 that locate resources at a single location in the hierarchy, a 161 drawback when a resource has multiple valid categories. For example, 162 in a hierarchy of vehicle descriptions containing collections for 163 cars and boats, a description of a combination car/boat vehicle could 164 belong in either collection. Ideally, the description should be 165 accessible from both. Allowing clients to create new URIs that access 166 the existing resource lets them put that resource into multiple 167 collections. 169 Hierarchies also make resource sharing more difficult, since 170 resources that have utility across many collections are still forced 171 into a single collection. For example, the mathematics department at 172 one university might create a collection of information on fractals 173 that contains bindings to some local resources, but also provides 174 access to some resources at other universities. For many reasons, it 175 may be undesirable to make physical copies of the shared resources on 176 the local server: to conserve disk space, to respect copyright 177 constraints, or to make any changes in the shared resources visible 178 automatically. Being able to create new access paths to existing 179 resources in other collections or even on other servers is useful for 180 this sort of case. 182 The redirect reference resources defined here provide a mechanism for 183 creating alternative access paths to existing resources. A redirect 184 reference resource is a resource in one collection whose purpose is 185 to forward requests to another resource (its target), possibly in a 186 different collection. In this way, it allows clients to submit 187 requests to the target resource from another collection. It 188 redirects most requests to the target resource using the HTTP 302 189 (Found) status code, thereby providing a form of mediated access to 190 the target resource. 192 A redirect reference is a resource with properties but no body of its 193 own. Properties of a redirect reference resource can contain such 194 information as who created the reference, when, and why. Since 195 redirect reference resources are implemented using HTTP 302 196 responses, it generally takes two round trips to submit a request to 197 the intended resource. Servers are not required to enforce the 198 integrity of redirect references. Redirect references work equally 199 well for local resources and for resources that reside on a different 200 server from the reference. 202 The remainder of this document is structured as follows: Section 3 203 defines terms that will be used throughout the specification. 204 Section 4 provides an overview of redirect reference resources. 205 Section 5 discusses how to create a redirect reference resource. 206 Section 6 defines the semantics of existing methods when applied to 207 redirect reference resources, and Section 7 discusses their semantics 208 when applied to collections that contain redirect reference 209 resources. Sections 8 through 10 discuss several other issues raised 210 by the existence of redirect reference resources. Sections 11 211 through 14 define the new headers, properties, and XML elements 212 required to support redirect reference resources. Section 15 213 discusses capability discovery. Sections 16 through 18 present the 214 security, internationalization, and IANA concerns raised by this 215 specification. The remaining sections provide a variety of supporting 216 information. 218 2. Notational Conventions 220 Since this document describes a set of extensions to the WebDAV 221 Distributed Authoring Protocol [RFC2518], itself an extension to the 222 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 223 elements is exactly the same as described in Section 2.1 of 224 [RFC2616]. Since this augmented BNF uses the basic production rules 225 provided in Section 2.2 of [RFC2616], these rules apply to this 226 document as well. 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in [RFC2119]. 232 3. Terminology 234 The terminology used here follows and extends that in the WebDAV 235 Distributed Authoring Protocol specification [RFC2518]. Definitions 236 of the terms resource, Uniform Resource Identifier (URI), and Uniform 237 Resource Locator (URL) are provided in [RFC2396]. 239 Redirect Reference Resource 241 A resource created to redirect all requests made to it, using 302 242 (Found), to a defined target resource. 244 Non-Reference Resource 246 A resource that is not a reference to another resource. 248 Target Resource 250 The resource to which requests are forwarded by a reference 251 resource. A target resource can be anything that can be identified 252 by an absolute URI (see [RFC2396], "absoluteURI"). 254 4. Overview of Redirect Reference Resources 256 For all operations submitted to a redirect reference resource, the 257 default response is a 302 (Found), accompanied by the Redirect-Ref 258 header (defined in Section 11.1 below) and the Location header set to 259 the URI of the target resource. With this information, the client 260 can resubmit the request to the URI of the target resource. 262 A redirect reference resource never automatically forwards requests 263 to its target resource. Redirect resources bring the same benefits as 264 links in HTML documents. They can be created and maintained without 265 the involvement or even knowledge of their target resource. This 266 reduces the cost of linking between resources." 268 If the client is aware that it is operating on a redirect reference 269 resource, it can resolve the reference by retrieving the reference 270 resource's DAV:reftarget property (defined in Section 12.1 below), 271 whose value contains the URI of the target resource. It can then 272 submit requests to the target resource. 274 A redirect reference resource is a new type of resource. To 275 distinguish redirect reference resources from non-reference 276 resources, a new value of the DAV:resourcetype property (defined in 277 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below. 279 Since a redirect reference resource is a resource, methods can be 280 applied to the reference resource as well as to its target resource. 281 The Apply-To-Redirect-Ref request header (defined in Section 11.2 282 below) is provided so that referencing-aware clients can control 283 whether an operation is applied to the redirect reference resource or 284 standard HTTP/WebDAV behaviour (redirection with a 3xx status code) 285 should occur. The Apply-To-Redirect-Ref header can be used with most 286 requests to redirect reference resources. This header is 287 particularly useful with PROPFIND, to retrieve the reference 288 resource's own properties. 290 5. Creating a Redirect Reference Resource 292 The new MKRESOURCE method is used to create new redirect reference 293 resources. In order to create a redirect reference resource using 294 MKRESOURCE, the values of two properties must be set in the body of 295 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to 296 DAV:redirectref, a new value of DAV:resourcetype defined in Section 297 13.1. The value of DAV:reftarget MUST be set to the URI of the target 298 resource. 300 Used in this way, the MKRESOURCE method creates a redirect reference 301 resource whose target is identified by the DAV:reftarget property. 303 5.1 MKRESOURCE 305 The MKRESOURCE method requests the creation of a redirect reference 306 resource and initialization of its properties in one atomic 307 operation. 309 Preconditions: 311 A resource MUST NOT exist at the Request-URI. 313 Request Marshalling: 315 The location of the new resource to be created is specified by the 316 Request-URI. 318 The request body of the MKRESOURCE method MUST consist of the 319 DAV:propertyupdate XML element defined in Section 12.13 of 320 [RFC2518], specifying a DAV:resourcetype of "DAV:redirectref". 322 Postconditions: 324 If the response status code is 201, a new resource exists at the 325 Request-URI. 327 The properties of the new resource are as specified by the 328 DAV:propertyupdate request body, using PROPPATCH semantics. 330 If the response status code is not 201, then a new resource is not 331 created at the Request-URI, and any existing resource at the 332 Request-URI is unaffected. 334 Response Marshalling: 336 Responses from a MKRESOURCE request MUST NOT be cached, as 337 MKRESOURCE has non-idempotent semantics. 339 The following status codes can be expected in responses to 340 MKRESOURCE: 342 201 (Created): The new resource was successfully created. 344 403 (Forbidden): The server does not allow the creation of the 345 requested resource type at the requested location, or the parent 346 collection of the Request-URI exists but cannot accept members. 348 409 (Conflict): A resource cannot be created at the Request-URI 349 because the parent collection for the resource does not exist, or 350 because there is already a resource at that request-URL. 352 423 (Locked): The Request-URI is locked, and the lock token was 353 not passed with the request. 355 507 (Insufficient Storage): The server does not have sufficient 356 space to record the state of the resource. 358 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE 360 >> Request: 362 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 363 Host: www.example.com 364 Content-Type: text/xml; charset="utf-8" 365 Content-Length: xxx 367 368 369 370 371 372 373 /i-d/draft-webdav-protocol-08.txt 374 375 376 377 379 >> Response: 381 HTTP/1.1 201 Created 383 This request resulted in the creation of a new redirect reference 384 resource at http://www.example.com/~whitehead/dav/spec08.ref, which 385 points to the resource identified by the DAV:reftarget property. In 386 this example, the target resource is identified by the URI http:// 387 www.example.com/i-d/draft-webdav-protocol-08.txt. The redirect 388 reference resource's DAV:resourcetype property is set to 389 DAV:redirectref. 391 6. Operations on Redirect Reference Resources 393 Although non-referencing-aware clients cannot create reference 394 resources, they should be able to submit requests through the 395 reference resources created by reference-aware WebDAV clients. They 396 should be able to follow any references to their targets. To make 397 this possible, a server that receives any request made via a redirect 398 reference resource MUST return a 302 (Found) status code, unless the 399 request includes an Apply-To-Redirect-Ref header specifying "T". The 400 client and server MUST follow [RFC2616] Section 10.3.3 "302 Found", 401 but with these additional rules: 403 o The Location response header MUST contain an absolute URI that 404 identifies the target of the reference resource. 406 o The response MUST include the Redirect-Ref header. This header 407 allows reference-aware WebDAV clients to recognize the resource as 408 a reference resource and understand the reason for the 409 redirection. 411 A reference-aware WebDAV client can, like a non-referencing client, 412 resubmit the request to the URI in the Location header in order to 413 operate on the target resource. Alternatively, it can resubmit the 414 request to the URI of the redirect reference resource with the 415 "Apply-To-Redirect-Ref: T" header in order to operate on the 416 reference resource itself. In this case, the request MUST be applied 417 to the reference resource itself, and a 302 response MUST NOT be 418 returned. 420 As redirect references do not have bodies, GET and PUT requests with 421 "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden). 423 7. Operations on Collections That Contain Redirect Reference Resources 425 Consistent with the rules in Section 6, the response for each 426 redirect reference encountered while processing a collection MUST be 427 a 302 (Found) unless a "Apply-To-Redirect-Ref: T" header is included 428 with the request. The overall response will therefore be a 207 429 (Multi-Status). For each DAV:response element representing a redirect 430 reference, the server MUST include an additional DAV:location 431 element, specifying the value of the "Location" header that would be 432 returned otherwise. The extension is defined in Section 14 below. 434 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be 435 used with any request on a collection. If present, it will be 436 applied to all redirect reference resources encountered while 437 processing the collection. 439 7.1 LOCK on a Collection That Contains Redirect References 441 An attempt to lock (with Depth: infinity) a collection that contains 442 redirect references without specifying "Apply-To-Redirect-Ref: T" 443 will always fail. The Multi-Status response will contain a 302 444 response for each redirect reference. 446 Reference-aware clients can lock the collection by using 447 Apply-To-Redirect-Ref, and, if desired, lock the targets of the 448 redirect references individually. 450 Non-referencing clients must resort to locking each resource 451 individually. 453 7.2 Example: PROPFIND on a Collection with Redirect Reference Resources 455 Suppose a PROPFIND request with Depth: infinity is submitted to the 456 following collection, with the members shown here: 458 /MyCollection/ 459 (non-reference resource) diary.html 460 (redirect reference resource) nunavut 462 >> Request: 464 PROPFIND /MyCollection/ HTTP/1.1 465 Host: example.com 466 Depth: infinity 467 Apply-To-Redirect-Ref: F 468 Content-Type: text/xml 469 Content-Length: xxxx 471 472 473 474 475 476 477 478 >> Response: 480 HTTP/1.1 207 Multi-Status 481 Content-Type: text/xml 482 Content-Length: xxxx 484 485 486 487 /MyCollection/ 488 489 490 491 diary, interests, hobbies 492 493 HTTP/1.1 200 OK 494 495 496 497 /MyCollection/diary.html 498 499 500 501 diary, travel, family, history 502 503 HTTP/1.1 200 OK 504 505 506 507 /MyCollection/nunavut 508 HTTP/1.1 302 Found 509 510 http://example.ca/art/inuit/ 511 512 513 515 In this example the Depth header is set to infinity, and the 516 Apply-To-Redirect-Ref header is set to "F". The collection contains 517 one URI that identifies a redirect reference resource. The response 518 element for the redirect reference resource has a status of 302 519 (Found), and includes a DAV:location extension element to allow 520 clients to retrieve the properties of its target resource. (The 521 response element for the redirect reference resource does not include 522 the requested properties. The client can submit another PROPFIND 523 request to the URI in the DAV:location pseudo-property to retrieve 524 those properties.) 526 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 527 Redirect Reference Resources 529 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: 530 infinity is submitted to the following collection, with the members 531 shown here: 533 /MyCollection/ 534 (non-reference resource) diary.html 535 (redirect reference resource) nunavut 537 >> Request: 539 PROPFIND /MyCollection/ HTTP/1.1 540 Host: example.com 541 Depth: infinity 542 Apply-To-Redirect-Ref: T 543 Content-Type: text/xml 544 Content-Length: xxxx 546 547 548 549 550 551 552 554 >> Response: 556 HTTP/1.1 207 Multi-Status 557 Content-Type: text/xml 558 Content-Length: xxxx 560 561 562 563 /MyCollection/ 564 565 566 567 568 HTTP/1.1 200 OK 569 570 571 572 HTTP/1.1 404 Not Found 573 575 576 577 /MyCollection/diary.html 578 579 580 581 582 HTTP/1.1 200 OK 583 584 585 586 HTTP/1.1 404 Not Found 587 588 589 590 /MyCollection/nunavut 591 592 593 594 595 http://example.ca/art/inuit/ 596 597 598 HTTP/1.1 200 OK 599 600 601 603 Since the "Apply-To-Redirect-Ref: T" header is present, the response 604 shows the properties of the redirect reference resource in the 605 collection rather than reporting a 302 status. 607 7.4 Example: COPY on a Collection That Contains a Redirect Reference 608 Resource 610 Suppose a COPY request is submitted to the following collection, with 611 the members shown: 613 /MyCollection/ 614 (non-reference resource) diary.html 615 (redirect reference resource) nunavut with target 616 /Someplace/nunavut.map 618 >> Request: 620 COPY /MyCollection/ HTTP/1.1 621 Host: example.com 622 Depth: infinity 623 Destination: http://example.com/OtherCollection/ 625 >> Response: 627 HTTP/1.1 207 Multi-Status 628 Content-Type: text/xml; charset="utf-8" 629 Content-Length: xxx 631 632 633 634 /MyCollection/nunavut 635 HTTP/1.1 302 Found 636 637 http://example.com//Someplace/nunavut.map 638 639 640 642 In this case, since /MyCollection/nunavut is a redirect reference 643 resource, the COPY operation was only a partial success. The 644 redirect reference resource was not copied, but a 302 response was 645 returned for it. So the resulting collection is as follows: 647 /OtherCollection/ 648 (non-reference resource) diary.html 650 7.5 Example: LOCK on a Collection That Contains a Redirect Reference 651 Resource 653 Suppose a LOCK request is submitted to the following collection, with 654 the members shown: 656 /MyCollection/ 657 (non-reference resource) diary.html 658 (redirect reference resource) nunavut 660 >> Request: 662 LOCK /MyCollection/ HTTP/1.1 663 Host: example.com 664 Apply-To-Redirect-Ref: F 665 Content-Type: text/xml 667 668 669 670 671 673 >> Response: 675 HTTP/1.1 207 Multi-Status 676 Content-Type: text/xml 677 Content-Length: nnnn 679 680 681 682 /MyCollection/ 683 HTTP/1.1 424 Failed Dependency 684 685 686 /MyCollection/diary.html 687 HTTP/1.1 424 Failed Dependency 688 689 690 /MyCollection/nunavut 691 HTTP/1.1 302 Found 692 693 http://example.ca/art/inuit/ 694 695 696 698 The server returns a 302 response code for the redirect reference 699 resource in the collection. Consequently, neither the collection nor 700 any of the resources identified by its internal member URIs were 701 locked. A referencing-aware client can submit a separate LOCK request 702 to the URI in the DAV:location element returned for the redirect 703 reference resource, and can resubmit the LOCK request with the 704 Apply-To-Redirect-Ref header to the collection. At that point both 705 the reference resource and its target resource will be locked (as 706 well as the collection and all the resources identified by its other 707 members). 709 8. Operations on Targets of Redirect Reference Resources 711 Operations on targets of redirect reference resources have no effect 712 on the reference resource. 714 9. Relative URIs in DAV:reftarget 716 The URI in the href in a DAV:reftarget property MAY be a relative 717 URI. In this case, the base URI to be used for resolving the relative 718 URI to absolute form is the URI used in the HTTP message to identify 719 the redirect reference resource to which the DAV:reftarget property 720 belongs. 722 When DAV:reftarget appears in the context of a Multi-Status response, 723 it is in a DAV:response element that contains a single DAV:href 724 element. The value of this DAV:href element serves as the base URI 725 for resolving a relative URI in DAV:reftarget. The value of DAV:href 726 may itself be relative, in which case it must be resolved first in 727 order to serve as the base URI for the relative URI in DAV:reftarget. 728 If the DAV:href element is relative, its base URI is constructed from 729 the scheme component "http", the value of the Host header in the 730 request, and the request-URI. 732 9.1 Example: Resolving a Relative URI in a Multi-Status Response 734 >> Request: 736 PROPFIND /geog/ HTTP/1.1 737 Host: example.com 738 Apply-To-Redirect-Ref: T 739 Depth: 1 740 Content-Type: text/xml 741 Content-Length: nnn 743 744 745 746 747 748 749 750 >> Response: 752 HTTP/1.1 207 Multi-Status 753 Content-Type: text/xml 754 Content-Length: nnn 756 757 758 759 /geog/ 760 761 762 763 764 HTTP/1.1 200 OK 765 766 767 768 HTTP/1.1 404 Not Found 769 770 771 772 /geog/stats.html 773 774 775 776 777 statistics/population/1997.html 778 779 780 HTTP/1.1 200 OK 781 782 783 785 In this example, the relative URI statistics/population/1997.html is 786 returned as the value of reftarget for the reference resource 787 identified by href /geog/stats.html. The href is itself a relative 788 URI, which resolves to http://example.com/geog/stats.html. This is 789 the base URI for resolving the relative URI in reftarget. The 790 absolute URI of reftarget is http://example.com/geog/statistics/ 791 population/1997.html. 793 10. Redirect References to Collections 795 In a Request-URI /segment1/segment2/segment3, any of the three 796 segments may identify a redirect reference resource. (See [RFC2396], 797 Section 3.3, for definitions of "path" and "segment".) If any 798 segment in a Request-URI identifies a redirect reference resource, 799 the response SHOULD be a 302. The value of the Location header in the 800 302 response is as follows: 802 The leftmost path segment of the request-URI that identifies a 803 redirect reference resource, together with all path segments and 804 separators to the left of it, is replaced by the value of the 805 redirect reference resource's DAV:reftarget property (resolved to an 806 absolute URI). The remainder of the request-URI is concatenated to 807 this path. 809 Note: If the DAV:reftarget property ends with a "/" and the remainder 810 of the Request-URI is non-empty (and therefore must begin with a "/ 811 "), the final "/" in the DAV:reftarget property is dropped before the 812 remainder of the Request-URI is appended. 814 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 815 reference resource whose target resource is collection /a/, which 816 contains redirect reference resource y whose target resource is 817 collection /b/, which contains redirect reference resource z.html 818 whose target resource is /c/d.html. 820 /x/y/z.html 821 | 822 | /x -> /a 823 | 824 v 825 /a/y/z.html 826 | 827 | /a/y -> /b 828 | 829 v 830 /b/z.html 831 | 832 | /b/z.html -> /c/d.html 833 | 834 v 835 /c/d.html 837 In this case the client must follow up three separate 302 responses 838 before finally reaching the target resource. The server responds to 839 the initial request with a 302 with Location: /a/y/z.html, and the 840 client resubmits the request to /a/y/z.html. The server responds to 841 this request with a 302 with Location: /b/z.html, and the client 842 resubmits the request to /b/z.html. The server responds to this 843 request with a 302 with Location: /c/d.html, and the client resubmits 844 the request to /c/d.html. This final request succeeds. 846 Note: the behavior described above may have a very serious impact 847 on the efficiency of mapping Request-URIs to resources in HTTP 848 request processing. Therefore servers MAY respond with a 404 849 status code if the cost of checking all leading path segments for 850 redirect references seems prohibitive. 852 11. Headers 854 11.1 Redirect-Ref Response Header 856 Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI) 857 ; see sections 3 and 5 of [RFC2396] 859 The Redirect-Ref header is used in all 302 responses from redirect 860 reference resources. The value is the (possibly relative) URI of the 861 link target as specified during redirect reference resource creation. 863 11.2 Apply-To-Redirect-Ref Request Header 865 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") 867 The optional Apply-To-Redirect-Ref header can be used on any request 868 to a redirect reference resource. When it is present and set to "T", 869 the request MUST be applied to the reference resource itself, and a 870 302 response MUST NOT be returned. 872 If the Apply-To-Redirect-Ref header is used on a request to any other 873 sort of resource besides a redirect reference resource, the server 874 MUST ignore it. 876 12. Properties 878 12.1 reftarget Property 880 Name: reftarget 882 Namespace: DAV: 884 Purpose: A property of redirect reference resources that provides an 885 efficient way for clients to discover the URI of the target 886 resource. This is a read-only property after its initial 887 creation. Its value can only be set in a MKRESOURCE request. 889 Value: href containing the URI of the target resource. This value 890 MAY be a relative URI. The reftarget property can occur in the 891 entity bodies of MKRESOURCE requests and of responses to PROPFIND 892 requests. 894 896 13. XML Elements 898 13.1 redirectref XML Element 900 Name: redirectref 902 Namespace: DAV: 904 Purpose: Used as the value of the DAV:resourcetype property to 905 specify that the resource type is a redirect reference resource. 907 909 14. Extensions to the DAV:response XML Element for Multi-Status 910 Responses 912 As described in Section 7, the DAV:location element may be returned 913 in the DAV:response element of a 207 Multi-Status response, to allow 914 clients to resubmit their requests to the target resource of a 915 redirect reference resource. 917 Consequently, the definition of the DAV:response XML element changes 918 to the following: 920 922 924 15. Capability Discovery 926 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 927 classes with the DAV header in responses to OPTIONS, to indicate 928 which parts of the WebDAV Distributed Authoring protocols the 929 resource supports. This specification defines an OPTIONAL extension 930 to [RFC2518]. It defines a new compliance class, called 931 redirectrefs, for use with the DAV header in responses to OPTIONS 932 requests. If a resource does support redirect references, its 933 response to an OPTIONS request may indicate that it does, by listing 934 the new redirectrefs compliance class in the DAV header and by 935 listing the MKRESOURCE method as one it supports. 937 When responding to an OPTIONS request, any type of resource can 938 include redirectrefs in the value of the DAV header. Doing so 939 indicates that the server permits a redirect reference resource at 940 the request URI. 942 15.1 Example: Discovery of Support for Redirect Reference Resources 944 >> Request: 946 OPTIONS /somecollection/someresource HTTP/1.1 947 Host: example.org 949 >> Response: 951 HTTP/1.1 200 OK 952 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 953 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE 954 DAV: 1, 2, redirectrefs 956 The DAV header in the response indicates that the resource / 957 somecollection/someresource is level 1 and level 2 compliant, as 958 defined in [RFC2518]. In addition, /somecollection/someresource 959 supports redirect reference resources. The Allow header indicates 960 that MKRESOURCE requests can be submitted to /somecollection/ 961 someresource. 963 16. Security Considerations 965 This section is provided to make applications that implement this 966 protocol aware of the security implications of this protocol. 968 All of the security considerations of HTTP/1.1 and the WebDAV 969 Distributed Authoring Protocol specification also apply to this 970 protocol specification. In addition, redirect reference resources 971 introduce several new security concerns and increase the risk of some 972 existing threats. These issues are detailed below. 974 16.1 Privacy Concerns 976 By creating redirect reference resources on a trusted server, it is 977 possible for a hostile agent to induce users to send private 978 information to a target on a different server. This risk is 979 mitigated somewhat, since clients are required to notify the user of 980 the redirection for any request other than GET or HEAD. (See 981 [RFC2616], Section 10.3.3 302 Found.) 983 16.2 Redirect Loops 985 Although redirect loops were already possible in HTTP 1.1, the 986 introduction of the MKRESOURCE method creates a new avenue for 987 clients to create loops accidentally or maliciously. If the 988 reference resource and its target are on the same server, the server 989 may be able to detect MKRESOURCE requests that would create loops. 990 See also [RFC2616], Section 10.3 "Redirection 3xx." 992 16.3 Redirect Reference Resources and Denial of Service 994 Denial of service attacks were already possible by posting URLs that 995 were intended for limited use at heavily used Web sites. The 996 introduction of MKRESOURCE creates a new avenue for similar denial of 997 service attacks. Clients can now create redirect reference resources 998 at heavily used sites to target locations that were not designed for 999 heavy usage. 1001 16.4 Revealing Private Locations 1003 There are several ways that redirect reference resources may reveal 1004 information about collection structures. First, the DAV:reftarget 1005 property of every redirect reference resource contains the URI of the 1006 target resource. Anyone who has access to the reference resource can 1007 discover the collection path that leads to the target resource. The 1008 owner of the target resource may have wanted to limit knowledge of 1009 this collection structure. 1011 Sufficiently powerful access control mechanisms can control this risk 1012 to some extent. Property-level access control could prevent users 1013 from examining the DAV:reftarget property. (The Location header 1014 returned in responses to requests on redirect reference resources 1015 reveals the same information, however.) 1017 This risk is no greater than the similar risk posed by HTML links. 1019 17. Internationalization Considerations 1021 All internationalization considerations mentioned in [RFC2518] also 1022 apply to this document. 1024 18. IANA Considerations 1026 All IANA considerations mentioned in [RFC2518] also apply to this 1027 document. 1029 19. Contributors 1031 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 1032 who can take credit for big parts of the original design of this 1033 specification. 1035 20. Acknowledgements 1037 This document has benefited from thoughtful discussion by Jim Amsden, 1038 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1039 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1040 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, 1041 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel 1042 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton, 1043 Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley 1044 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin 1045 Wiggen, and others. 1047 Normative References 1049 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1050 Requirement Levels", BCP 14, RFC 2119, March 1997. 1052 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1053 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1054 August 1998. 1056 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1057 Jensen, "HTTP Extensions for Distributed Authoring -- 1058 WEBDAV", RFC 2518, February 1999. 1060 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1061 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1062 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1064 [1] 1066 [2] 1068 Authors' Addresses 1070 Jim Whitehead 1071 UC Santa Cruz, Dept. of Computer Science 1072 1156 High Street 1073 Santa Cruz, CA 95064 1074 US 1076 EMail: ejw@cse.ucsc.edu 1078 Geoff Clemm 1079 IBM 1080 20 Maguire Road 1081 Lexington, MA 02421 1082 US 1084 EMail: geoffrey.clemm@us.ibm.com 1085 Julian F. Reschke (editor) 1086 greenbytes GmbH 1087 Salzmannstrasse 152 1088 Muenster, NW 48159 1089 Germany 1091 Phone: +49 251 2807760 1092 Fax: +49 251 2807761 1093 EMail: julian.reschke@greenbytes.de 1094 URI: http://greenbytes.de/tech/webdav/ 1096 Appendix A. Changes to the WebDAV Document Type Definition 1098 1099 1100 Property Elements from Section 12 --> 1101 1102 1103 1104 1107 Appendix B. Change Log (to be removed by RFC Editor before publication) 1109 B.1 Since draft-ietf-webdav-redirectref-protocol-02 1111 Julian Reschke takes editorial role (added to authors list). Cleanup 1112 XML indentation. Start adding all unresolved last call issues. Update 1113 some author's contact information. Update references, split into 1114 "normative" and "informational". Remove non-RFC2616 headers 1115 ("Public") from examples. Fixed width problems in artwork. Start 1116 resolving editorial issues. 1118 B.2 Since draft-ietf-webdav-redirectref-protocol-03 1120 Added Joe Orton and Juergen Reuter to Acknowledgements section. Close 1121 more editorial issues. Remove dependencies on BIND spec. 1123 B.3 Since draft-ietf-webdav-redirectref-protocol-04 1125 More editorial fixes. Clarify that MKRESOURCE can only be used to 1126 create redirect references (switch to new method in a future draft). 1127 Clarify that redirect references do not have bodies. 1129 B.4 Since draft-ietf-webdav-redirectref-protocol-05 1131 Close (accept) issue "lc-79-accesscontrol". Add issue 1132 "rfc2606-compliance". Close issues "lc-50-blindredirect", 1133 "lc-71-relative", "lc-74-terminology". Update contact info for Geoff 1134 Clemm. Moved some of the original authors names to new Contributors 1135 section. Add and close issue "9-MKRESOURCE-vs-relative-URI". Close 1136 issue "lc-72-trailingslash". Close issue "lc-60-ex". Update issue 1137 "lc-85-301" with proposal. Close issue "lc-06-reftarget-relative" 1138 (9-MKRESOURCE-vs-relative-URI was a duplicate of this one). Also 1139 remove section 9.1 (example for MKRESOURCE vs relative URIs). Add 1140 and resolve issue "11.2-apply-to-redirect-ref-syntax" (header now has 1141 values "T" and "F"). Also some cleanup for "rfc2606-compliance". 1142 Typo fixes. Add and resolve "15.1-options-response". 1144 B.5 Since draft-ietf-webdav-redirectref-protocol-06 1146 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", 1147 "lc-44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", 1148 "lc-80-i18n" and "rfc2606-compliance". Start work on index. Add new 1149 issue "old_clients". 1151 Appendix C. Resolved issues (to be removed by RFC Editor before 1152 publication) 1154 Issues that were either rejected or resolved in this version of this 1155 document. 1157 C.1 lc-19-direct-ref 1159 Type: change 1161 1164 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6, 1165 para 3 discussions of the Apply-to-Redirect-Ref header make it sound 1166 as if we are specifying direct reference behavior. 1168 Resolution (2003-11-04): Change these passages so that the contrast 1169 is between applying the method to the redirect reference and 1170 responding with a 302. 1172 C.2 rfc2606-compliance 1174 Type: editor 1176 julian.reschke@greenbytes.de (2003-10-02): Ensure that examples use 1177 only sample domains as per RFC2606. 1179 C.3 lc-28-lang 1181 Type: edit 1183 1186 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence 1187 "A reference-aware WebDAV client can act on this response in one of 1188 two ways." A client can act on the response in any way it wants. 1190 Resolution (2003-11-04): Agreed. See also issue 48. 1192 C.4 lc-29-lang 1194 Type: edit 1196 1198 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't 1199 need to be stated. Maybe note in an example. 1201 Resolution (2003-11-04): Agreed. See also issue 48. 1203 C.5 lc-44-pseudo 1205 Type: change 1207 1210 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an 1211 optional prop XML element to the response element in 207 responses, 1212 define a new location XML element and a new refresource XML element. 1214 Resolution: Agree to define new XML elements that are not 1215 pseudo-properties. Disagreement about whether refresource is needed. 1216 See issue 61. 1218 C.6 lc-61-pseudo 1220 Type: change 1222 1225 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to 1226 ask future editors of RFC 2518 to define DAV:location with the 1227 semantics it has here. RFC 2518 should provide the information in the 1228 Location header somehow in multistatus responses, but not by using 1229 properties. 1231 Resolution (2003-10-31): Define an XML element for location that is 1232 not a pseudo-property. We'll keep the recommendation that RFC 2518 1233 add this for 302 responses. See also issue 44. 1235 C.7 lc-62-oldclient 1237 Type: change 1239 1242 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim 1243 that non-referencing clients can't process 302 responses occurring in 1244 Multi-Status responses. They just have an extra round trip for each 1245 302. 1247 Resolution (2003-10-31): Remove last sentence of the paragraph that 1248 recommends changes to RFC 2518. 1250 C.8 lc-63-move 1252 Type: change 1254 1257 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the 1258 perspective of a client? Agrees that there should be no 302s for 1259 member redirect references, but finds the rationale dubious. 1261 Resolution (2003-11-11): Remove 7.1. Reword 7.2 to avoid concerns 1262 with "poses special problems" and "due to atomicity". 1264 C.9 lc-53-s10 1266 Type: change 1268 1271 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in 1272 this section would have a very serious impact on the efficiency of 1273 mapping Request-URIs to resources in HTTP request processing. Also 1274 specify another type of redirect resource that does not behave as in 1275 section 10, but instead would "expose the behavior we see today in 1276 various HTTP servers that allow their users to create 300 resources." 1277 Be sure we know what behavior will be if the redirect location is not 1278 an HTTP URL, but, say ftp. 1280 Resolution (2003-11-04): We won't define 2 sorts of redirect 1281 references here. Servers SHOULD respond with 302 as described here, 1282 but if they can't do that, respond with 404 Not Found. (It's hard to 1283 modularize the behavior specified - it impacts processing Not Found 1284 cases of all methods, so you can't just add it to an HTTP server in a 1285 redirect ref module.) 1287 C.10 lc-76-location 1289 Type: change 1291 1294 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real 1295 (live) property, get rid of the DAV:reftarget property 1297 Resolution (2003-10-31): Pseudo-property was removed. 1299 C.11 lc-80-i18n 1301 Type: change 1303 1306 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot 1307 of this section, since this protocol extends WebDAV. Just reference 1308 [WebDAV]. 1310 julian.reschke@greenbytes.de (2003-10-02): True, but I note that 1311 other specs have re-stated these considerations as well. Opinions? 1313 Resolution (2003-11-11): Just point to RFC2518. Remove RFC2277 and 1314 XML from references (not needed anymore). 1316 Appendix D. Open issues (to be removed by RFC Editor before publication) 1318 D.1 old_clients 1320 Type: change 1322 1325 julian.reschke@greenbytes.de (2003-11-10): There are (at least) two 1326 major design goals, but unfortunately both are in direct 1327 contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This 1328 means that any request that addresses a redirect reference resource 1329 MUST result in a 3xx status code (obviously the whole point is that 1330 GET MUST result in a redirection, and if it does, it's hard to say 1331 why other methods such as PUT or DELETE should behave differently). 1332 Therefore, the redirect reference protocol introduces a new request 1333 header ("Apply-To-Redirect-Ref") through which a client can indicate 1334 that the request indeed should be applied to the redirect reference 1335 resource itself. #2: Maximum usability with existing clients. For 1336 instance, the Microsoft Webfolder client will not be able to DELETE a 1337 redirect reference resource unless the server deviates from #1. Right 1338 now I'm not sure about the best way to resolve this. Currently the 1339 spec chooses #1 (back when this decision was made, there was probably 1340 the assumption that existing clients would quickly be updated -- 1341 something that probably isn't true today). However this may result in 1342 implementers either just ignoring these rules, or adding special 1343 workarounds based on "User Agent" detection. 1345 D.2 lc-85-301 1347 Type: change 1349 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302 1350 redirects, especially 301. 1352 julian.reschke@greenbytes.de (2003-10-13): HTTP seems to distinguish 1353 the following use cases: (a) permanent redirect (301), (b) temporary 1354 redirect (302 or 307), (c) redirect to a GET location after POST 1355 (303) and (d) agent-driven negotiation (300). Among these, (a) and 1356 (b) seem to be well understood, so we should support both. (c) 1357 doesn't seem to be applicable. (d) may become interesting when user 1358 agents start supporting it, so the spec should be flexible enough to 1359 support a feature extension for that. For now I propose that the 1360 client is able to specify the redirection type as a resource type, 1361 such as "DAV:permanent-redirect-reference" and 1362 "DAV:temporary-redirect-reference". This spec would only define the 1363 behaviour for these two resource types and would allow future 1364 extensions using new resource types and suggested response codes. 1366 D.3 lc-38-not-hierarchical 1368 Type: change 1370 1373 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The 1374 first sentence of the second paragraph of the introduction of the 1375 redirect spec asserts that the URIs of WebDAV compliant resources 1376 match to collections. The WebDAV standard makes no such requirement. 1377 I therefore move that this sentence be stricken. 1379 Resolution: State the more general HTTP rationale first (alternative 1380 names for the same resource), then introduce the collection hierarchy 1381 rationale, which applies only if you are in a WebDAV-compliant space. 1383 D.4 lc-36-server 1385 Type: change 1387 1390 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" 1391 with "unrelated system" throughout. 1393 Resolution: Try replacing "server" with "host" in some contexts, 1394 rephrasing in passive voice in others. See also issue 40. 1396 D.5 lc-33-forwarding 1398 Type: change 1400 1403 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace 1404 "forward" with "redirect" throughout. 1406 Resolution: Use "redirect" for the behavior redirect resources do 1407 exhibit. Use "forward" for the contrasting behavior (passing a method 1408 on to the target with no client action needed). Define these two 1409 terms. See also issue 40. 1411 D.6 lc-37-integrity 1413 Type: change 1415 1418 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7 1419 "Servers are not required to enforce the integrity of redirect 1420 references." Integrity is not defined. Replace with something 1421 clearer. 1423 Resolution: Rewrite to say that the server MUST NOT update the target 1424 See also issue 6. 1426 D.7 3-terminology-redirectref 1428 Type: change 1430 1433 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of 1434 "redirect reference resource" to "redirect resource". 1436 D.8 lc-41-no-webdav 1438 Type: change 1440 1443 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references 1444 independent of the rest of WebDAV. The creation method for redirect 1445 references shouldn't require an XML request body. 1447 Resolution: We will make redirect references independent of the rest 1448 of WebDAV. MKREF will not have an XML request body. 1450 D.9 lc-58-update 1452 Type: change 1454 1457 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way 1458 to update the target of a redirect reference. 1460 Resolution: Agreed. See also issues 6, 43. 1462 D.10 lc-24-properties 1464 Type: change 1466 1469 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence 1470 "The properties of the new resource are as specified by the 1471 DAV:propertyupdate request body, using PROPPATCH semantics" with the 1472 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate 1473 request body to initialize resource properties. Herein, the semantics 1474 is the same as when sending a MKRESOURCE request without a request 1475 body, followed by a PROPPATCH with the DAV:propertyupdate request 1476 body." 1478 Resolution: No longer relevant once we switch to MKREF with no 1479 request body. 1481 D.11 lc-48-s6 1483 Type: change 1485 1488 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 1489 with just this: A redirect resource, upon receiving a request without 1490 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) 1491 response. The 302 (Found) response MUST include a location header 1492 identifying the target and a Redirect-Ref header. If a redirect 1493 resource receives a request with an Apply-To-Redirect-Ref header then 1494 the redirect reference resource MUST apply the method to itself 1495 rather than blindly returning a 302 (Found) response. 1497 Resolution: Keep a summary along the lines of Yaron's proposal (don't 1498 use the word "blindly"). Keep the bullets detailing the headers to be 1499 returned. Delete the rest, including the examples. See also issue 28, 1500 29, 30, 31, 32. 1502 D.12 lc-57-noautoupdate 1504 Type: change 1506 1508 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid 1509 servers from automatically updating redirect resources when their 1510 targets move. 1512 Resolution: Agreed. See also issue 6. 1514 D.13 12.1-property-name 1516 Type: change 1518 julian.reschke@greenbytes.de (2003-10-06): Sync names for 1519 DAV:reftarget property and "Redirect-Ref" response headers. 1521 D.14 lc-55-iana 1523 Type: change 1525 1528 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section 1529 to list all methods, headers, XML elements, MIME types, URL schemes, 1530 etc., defined by the spec. 1532 Resolution: Agreed. 1534 Index 1536 A 1537 Apply-To-Redirect-Ref header 25 1539 D 1540 DAV header 1541 compliance class 'redirectrefs' 29 1542 DAV:redirectref resource type 27 1543 DAV:reftarget property 26 1545 H 1546 Headers 1547 Apply-To-Redirect-Ref 25 1548 Redirect-Ref 25 1550 M 1551 Methods 1552 MKRESOURCE 9 1553 MKRESOURCE method 9 1555 P 1556 Properties 1557 DAV:reftarget 26 1559 R 1560 Redirect-Ref header 25 1561 Resource Types 1562 DAV:redirectref 27 1564 Intellectual Property Statement 1566 The IETF takes no position regarding the validity or scope of any 1567 intellectual property or other rights that might be claimed to 1568 pertain to the implementation or use of the technology described in 1569 this document or the extent to which any license under such rights 1570 might or might not be available; neither does it represent that it 1571 has made any effort to identify any such rights. Information on the 1572 IETF's procedures with respect to rights in standards-track and 1573 standards-related documentation can be found in BCP-11. Copies of 1574 claims of rights made available for publication and any assurances of 1575 licenses to be made available, or the result of an attempt made to 1576 obtain a general license or permission for the use of such 1577 proprietary rights by implementors or users of this specification can 1578 be obtained from the IETF Secretariat. 1580 The IETF invites any interested party to bring to its attention any 1581 copyrights, patents or patent applications, or other proprietary 1582 rights which may cover technology that may be required to practice 1583 this standard. Please address the information to the IETF Executive 1584 Director. 1586 Full Copyright Statement 1588 Copyright (C) The Internet Society (2003). All Rights Reserved. 1590 This document and translations of it may be copied and furnished to 1591 others, and derivative works that comment on or otherwise explain it 1592 or assist in its implementation may be prepared, copied, published 1593 and distributed, in whole or in part, without restriction of any 1594 kind, provided that the above copyright notice and this paragraph are 1595 included on all such copies and derivative works. However, this 1596 document itself may not be modified in any way, such as by removing 1597 the copyright notice or references to the Internet Society or other 1598 Internet organizations, except as needed for the purpose of 1599 developing Internet standards in which case the procedures for 1600 copyrights defined in the Internet Standards process must be 1601 followed, or as required to translate it into languages other than 1602 English. 1604 The limited permissions granted above are perpetual and will not be 1605 revoked by the Internet Society or its successors or assignees. 1607 This document and the information contained herein is provided on an 1608 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1609 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1610 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1611 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1612 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1614 Acknowledgment 1616 Funding for the RFC Editor function is currently provided by the 1617 Internet Society.