idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1451. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 887 has weird spacing: '... the respon...' == Line 950 has weird spacing: '... is the link ...' == Line 1009 has weird spacing: '...ment of a 207...' == Line 1010 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 (February 9, 2005) is 6987 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) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** 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) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group J. Whitehead 2 Internet-Draft U.C. Santa Cruz 3 Expires: August 13, 2005 G. Clemm 4 IBM 5 J. Reschke, Ed. 6 greenbytes 7 February 9, 2005 9 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference 10 Resources 11 draft-ietf-webdav-redirectref-protocol-11 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 13, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This specification defines redirect reference resources. A redirect 47 reference resource is a resource whose default response is an HTTP/ 48 1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), 49 redirecting the client to a different resource, the target resource. 50 A redirect reference makes it possible to access the target resource 51 indirectly, through any URI mapped to the redirect reference 52 resource. There are no integrity guarantees associated with redirect 53 reference resources. 55 Editorial Note (To be removed by RFC Editor before publication) 57 Distribution of this document is unlimited. Please send comments to 58 the Distributed Authoring and Versioning (WebDAV) working group at 59 , which may be joined by sending a 60 message with subject "subscribe" to 61 . Discussions of the WEBDAV 62 working group are archived at 63 . 65 An issues list and XML and HTML versions of this draft are available 66 from . 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Overview of Redirect Reference Resources . . . . . . . . . . 7 75 5. Operations on Redirect Reference Resources . . . . . . . . . 8 76 6. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8 77 6.1 Example: Creating a Redirect Reference Resource with 78 MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10 79 7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10 80 7.1 Example: Updating a Redirect Reference Resource with 81 UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12 82 8. Operations on Collections That Contain Redirect Reference 83 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 8.1 LOCK on a Collection That Contains Redirect References . . 12 85 8.2 Example: PROPFIND on a Collection with Redirect 86 Reference Resources . . . . . . . . . . . . . . . . . . . 13 87 8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a 88 Collection with Redirect Reference Resources . . . . . . . 15 89 8.4 Example: COPY on a Collection That Contains a Redirect 90 Reference Resource . . . . . . . . . . . . . . . . . . . . 16 91 8.5 Example: LOCK on a Collection That Contains a Redirect 92 Reference Resource . . . . . . . . . . . . . . . . . . . . 17 93 9. Operations on Targets of Redirect Reference Resources . . . 19 94 10. Relative references in DAV:reftarget . . . . . . . . . . . . 19 95 10.1 Example: Resolving a Relative Reference in a 96 Multi-Status Response . . . . . . . . . . . . . . . . . 19 97 11. Redirect References to Collections . . . . . . . . . . . . . 20 98 12. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 12.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 22 100 12.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 22 101 13. Redirect Reference Resource Properties . . . . . . . . . . . 22 102 13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 22 103 13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 23 104 14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 23 105 14.1 redirectref XML Element . . . . . . . . . . . . . . . . 23 106 15. Extensions to the DAV:response XML Element for 107 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 23 108 16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23 109 16.1 Example: Discovery of Support for Redirect Reference 110 Resources . . . . . . . . . . . . . . . . . . . . . . . 24 111 17. Security Considerations . . . . . . . . . . . . . . . . . . 24 112 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 25 113 17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 25 114 17.3 Redirect Reference Resources and Denial of Service . . . 25 115 17.4 Revealing Private Locations . . . . . . . . . . . . . . 25 116 18. Internationalization Considerations . . . . . . . . . . . . 25 117 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 118 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 119 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 120 22. Normative References . . . . . . . . . . . . . . . . . . . . 26 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 122 A. Changes to the WebDAV Document Type Definition . . . . . . . 27 123 B. Change Log (to be removed by RFC Editor before 124 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 125 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 28 126 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 28 127 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28 128 B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28 129 B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28 130 B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 29 131 B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 29 132 B.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29 133 B.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29 134 C. Resolved issues (to be removed by RFC Editor before 135 publication) . . . . . . . . . . . . . . . . . . . . . . . . 29 136 C.1 abnf . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 137 C.2 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30 138 C.3 13_allprop . . . . . . . . . . . . . . . . . . . . . . . . 30 139 D. Open issues (to be removed by RFC Editor prior to 140 publication) . . . . . . . . . . . . . . . . . . . . . . . . 30 141 D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 142 D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 30 143 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 144 Intellectual Property and Copyright Statements . . . . . . . 34 146 1. Introduction 148 This specification extends the Web Distributed Authoring Protocol 149 (WebDAV) to enable clients to create new access paths to existing 150 resources. This capability is useful for several reasons: 152 WebDAV makes it possible to organize HTTP resources into hierarchies, 153 placing them into groupings, known as collections, which are more 154 easily browsed and manipulated than a single flat collection. 155 However, hierarchies require categorization decisions that locate 156 resources at a single location in the hierarchy, a drawback when a 157 resource has multiple valid categories. For example, in a hierarchy 158 of vehicle descriptions containing collections for cars and boats, a 159 description of a combination car/boat vehicle could belong in either 160 collection. Ideally, the description should be accessible from both. 161 Allowing clients to create new URIs that access the existing resource 162 lets them put that resource into multiple collections. 164 Hierarchies also make resource sharing more difficult, since 165 resources that have utility across many collections are still forced 166 into a single collection. For example, the mathematics department at 167 one university might create a collection of information on fractals 168 that contains bindings to some local resources, but also provides 169 access to some resources at other universities. For many reasons, it 170 may be undesirable to make physical copies of the shared resources: 171 to conserve disk space, to respect copyright constraints, or to make 172 any changes in the shared resources visible automatically. Being 173 able to create new access paths to existing resources in other 174 collections or even on other unrelated systems is useful for this 175 sort of case. 177 The redirect reference resources defined here provide a mechanism for 178 creating alternative access paths to existing resources. A redirect 179 reference resource is a resource in one collection whose purpose is 180 to redirect requests to another resource (its target), possibly in a 181 different collection. In this way, it allows clients to submit 182 requests to the target resource from another collection. It 183 redirects most requests to the target resource using a HTTP status 184 code from the 3xx range (Redirection), thereby providing a form of 185 mediated access to the target resource. 187 A redirect reference is a resource with properties but no body of its 188 own. Properties of a redirect reference resource can contain such 189 information as who created the reference, when, and why. Since 190 redirect reference resources are implemented using HTTP 3xx 191 responses, it generally takes two round trips to submit a request to 192 the intended resource. Redirect references work equally well for 193 local resources and for resources that reside on a different system 194 from the reference. 196 The remainder of this document is structured as follows: Section 3 197 defines terms that will be used throughout the specification. 198 Section 4 provides an overview of redirect reference resources. 199 Section 5 defines the semantics of existing methods when applied to 200 redirect reference resources. Section 6 discusses how to create a 201 redirect reference resource, and Section 7 discusses updating 202 redirect references. Section 8 discusses their semantics when 203 applied to collections that contain redirect reference resources. 204 Sections 9 through 11 discuss several other issues raised by the 205 existence of redirect reference resources. Sections 12 through 15 206 define the new headers, properties, and XML elements required to 207 support redirect reference resources. Section 16 discusses 208 capability discovery. Sections 17 through 19 present the security, 209 internationalization, and IANA concerns raised by this specification. 210 The remaining sections provide a variety of supporting information. 212 2. Notational Conventions 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 This specification uses the Augmented Backus-Naur Form (ABNF) 219 notation of [RFC2234]. 221 3. Terminology 223 The terminology used here follows and extends that in the WebDAV 224 Distributed Authoring Protocol specification [RFC2518]. Definitions 225 of the terms resource, Uniform Resource Identifier (URI), and Uniform 226 Resource Locator (URL) are provided in [RFC3986]. 228 Redirect Reference Resource 230 A resource created to redirect all requests made to it, using an 231 HTTP status code from the 3xx range, to a defined target resource. 233 Non-Reference Resource 235 A resource that is not a reference to another resource. 237 Target Resource 239 The resource to which requests are redirected by a redirect 240 reference resource. A target resource can be anything that can be 241 identified by an absolute URI (see [RFC3986], "absolute-URI"). 243 This document uses the terms "precondition", "postcondition" and 244 "protected property" as defined in [RFC3253]. Servers MUST report 245 pre-/postcondition failures as described in section 1.6 of this 246 document. 248 4. Overview of Redirect Reference Resources 250 For all operations submitted to a redirect reference resource, the 251 default response is a 302 (Found), accompanied by the Redirect-Ref 252 header (defined in Section 12.1 below) and the Location header set to 253 the URI of the target resource. With this information, the client 254 can resubmit the request to the URI of the target resource. 256 A redirect reference resource never automatically forwards requests 257 to its target resource. Redirect resources bring the same benefits 258 as links in HTML documents. They can be created and maintained 259 without the involvement or even knowledge of their target resource. 260 This reduces the cost of linking between resources. 262 If the client is aware that it is operating on a redirect reference 263 resource, it can resolve the reference by retrieving the reference 264 resource's DAV:reftarget property (defined in Section 13.2 below), 265 whose value contains the URI of the target resource. It can then 266 submit requests to the target resource. 268 A redirect reference resource is a new type of resource. To 269 distinguish redirect reference resources from non-reference 270 resources, a new value of the DAV:resourcetype property (defined in 271 [RFC2518]), DAV:redirectref, is defined in Section 14.1 below. 273 Since a redirect reference resource is a resource, methods can be 274 applied to the reference resource as well as to its target resource. 275 The Apply-To-Redirect-Ref request header (defined in Section 12.2 276 below) is provided so that referencing-aware clients can control 277 whether an operation is applied to the redirect reference resource or 278 standard HTTP/WebDAV behaviour (redirection with a 3xx status code) 279 should occur. The Apply-To-Redirect-Ref header can be used with most 280 requests to redirect reference resources. This header is 281 particularly useful with PROPFIND, to retrieve the reference 282 resource's own properties. 284 Implementation Note: Operations on the target of a redirect reference 285 usually do not affect the redirect reference itself. However, 286 clients should not rely on this behaviour (for instance, some servers 287 may update redirect references as a result of namespace operations on 288 the reference's target). 290 5. Operations on Redirect Reference Resources 292 Although non-referencing-aware clients cannot create reference 293 resources, they should be able to submit requests through the 294 reference resources created by reference-aware WebDAV clients. They 295 should be able to follow any references to their targets. To make 296 this possible, a server that receives any request made via a redirect 297 reference resource MUST return a 3xx range (Redirection) status code, 298 unless the request includes an Apply-To-Redirect-Ref header 299 specifying "T". The client and server MUST follow [RFC2616] Section 300 10.3, but with these additional rules: 302 o The Location response header MUST contain an absolute URI that 303 identifies the target of the reference resource. 305 o The response MUST include the Redirect-Ref header. This header 306 allows reference-aware WebDAV clients to recognize the resource as 307 a reference resource and understand the reason for the 308 redirection. 310 A reference-aware WebDAV client can, like a non-referencing client, 311 resubmit the request to the URI in the Location header in order to 312 operate on the target resource. Alternatively, it can resubmit the 313 request to the URI of the redirect reference resource with the 314 "Apply-To-Redirect-Ref: T" header in order to operate on the 315 reference resource itself. In this case, the request MUST be applied 316 to the reference resource itself, and a 3xx response MUST NOT be 317 returned. 319 As redirect references do not have bodies, GET and PUT requests with 320 "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden). 322 6. MKREDIRECTREF Method 324 The MKREDIRECTREF method requests the creation of a redirect 325 reference resource. 327 If a MKREDIRECTREF request fails, the server state preceding the 328 request MUST be restored. 330 Responses from a MKREDIRECTREF request MUST NOT be cached, as 331 MKREDIRECTREF has non-idempotent and non-safe semantics (see 332 [RFC2616], section 9.1). 334 Marshalling: 336 The request body MUST be a DAV:mkredirectref XML element. 338 339 340 341 342 344 The DAV:href element is defined in [RFC2518] (Section 12.3) and 345 MUST contain either an absolute-URI or a relative-ref (without 346 fragment), see [RFC3986], Sections 4.2 and 4.3). 348 If no DAV:redirect-lifetime element is specified, the server MUST 349 behave as if a value of DAV:temporary was specified. 351 If the request succeeds, the server MUST return 201 (Created) 352 status. 354 If a response body for a successful request is included, it MUST 355 be a DAV:mkredirectref-response XML element. Note that this 356 document does not define any elements for the MKREDIRECTREF 357 response body, but the DAV:mkredirectref-response element is 358 defined to ensure interoperability between future extensions that 359 do define elements for the response body. 361 363 Preconditions: 365 (DAV:resource-must-be-null): A resource MUST NOT exist at the 366 Request-URI. 368 (DAV:parent-resource-must-be-non-null): The Request-URI minus the 369 last past segment MUST identify a collection. 371 (DAV:name-allowed): The last segment of the Request-URI is 372 available for use as a resource name. 374 (DAV:locked-update-allowed): If the collection identified by the 375 Request-URI minus the last path segment is write-locked, then the 376 appropriate token MUST be specified in an If request header. 378 (DAV:redirect-lifetime-supported): If the request body contains a 379 DAV:redirect-lifetime element, the server MUST support the 380 specified lifetime. Support for DAV:temporary is REQUIRED, while 381 support for DAV:permanent is OPTIONAL. 383 Postconditions: 385 (DAV:new-redirectref): a new redirect reference resource is 386 created whose DAV:reftarget property has the value specified in 387 the request body. 389 6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF 391 >> Request: 393 MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 394 Host: www.example.com 395 Content-Type: text/xml; charset="utf-8" 396 Content-Length: xxx 398 399 400 401 /i-d/draft-webdav-protocol-08.txt 402 403 405 >> Response: 407 HTTP/1.1 201 Created 409 This request resulted in the creation of a new redirect reference 410 resource at http://www.example.com/~whitehead/dav/spec08.ref, which 411 points to the resource identified by the DAV:reftarget property. In 412 this example, the target resource is identified by the URI 413 http://www.example.com/i-d/draft-webdav-protocol-08.txt. The 414 redirect reference resource's DAV:resourcetype property is set to 415 DAV:redirectref and it's DAV:redirect-lifetime property has the value 416 DAV:temporary. 418 7. UPDATEREDIRECTREF Method 420 The UPDATEREDIRECTREF method requests the update of a redirect 421 reference resource. 423 If a UPDATEREDIRECTREF request fails, the server state preceding the 424 request MUST be restored. 426 Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as 427 UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], section 428 9.1). 430 Marshalling: 432 The request body MUST be a DAV:updateredirectref XML element. 434 435 See Section 6 for a definition of DAV:reftarget and DAV:redirect- 436 lifetime. 438 If no DAV:reftarget element is specified, the server MUST NOT 439 change the target of the redirect reference. 441 If no DAV:redirect-lifetime element is specified, the server MUST 442 NOT change the lifetime of the redirect reference. 444 If a response body for a successful request is included, it MUST 445 be a DAV:updateredirectref-response XML element. Note that this 446 document does not define any elements for the UPDATEREDIRECTREF 447 response body, but the DAV:updateredirectref-response element is 448 defined to ensure interoperability between future extensions that 449 do define elements for the response body. 451 453 Preconditions: 455 (DAV:locked-update-allowed): if the resource is write-locked, then 456 the appropriate token MUST be specified in an If request header. 458 (DAV:must-be-redirectref): the resource identified by the Request- 459 URI must be a redirect reference resource as defined by this 460 specification. 462 (DAV:redirect-lifetime-supported): see Section 6. 464 (DAV:redirect-lifetime-update-supported): servers MAY support 465 changing the DAV:redirect-lifetime property; if they don't, this 466 condition code can be used to signal failure. 468 Postconditions: 470 (DAV:redirectref-updated): the DAV:reftarget and DAV:redirect- 471 lifetime properties of the redirect reference have been updated 472 accordingly. 474 7.1 Example: Updating a Redirect Reference Resource with 475 UPDATEREDIRECTREF 477 >> Request: 479 UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 480 Host: www.example.com 481 Apply-To-Redirect-Ref: T 482 Content-Type: text/xml; charset="utf-8" 483 Content-Length: xxx 485 486 487 488 /i-d/draft-webdav-protocol-08b.txt 489 490 492 >> Response: 494 HTTP/1.1 200 OK 496 This request has updated the redirect reference's DAV:reftarget 497 property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed 498 the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect- 499 Ref" request header must be used, otherwise the request would result 500 in a redirect (3xx) response status. 502 8. Operations on Collections That Contain Redirect Reference Resources 504 Consistent with the rules in Section 5, the response for each 505 redirect reference encountered while processing a collection MUST be 506 a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is 507 included with the request. The overall response will therefore be a 508 207 (Multi-Status). For each DAV:response element representing a 509 redirect reference, the server MUST include an additional DAV: 510 location element, specifying the value of the "Location" header that 511 would be returned otherwise. The extension is defined in Section 15 512 below. 514 The Apply-To-Redirect-Ref header (defined in Section 12.2) MAY be 515 used with any request on a collection. If present, it will be 516 applied to all redirect reference resources encountered while 517 processing the collection. 519 8.1 LOCK on a Collection That Contains Redirect References 521 An attempt to lock (with Depth: infinity) a collection that contains 522 redirect references without specifying "Apply-To-Redirect-Ref: T" 523 will always fail. The Multi-Status response will contain a 3xx 524 response for each redirect reference. 526 Reference-aware clients can lock the collection by using Apply-To- 527 Redirect-Ref, and, if desired, lock the targets of the redirect 528 references individually. 530 Non-referencing clients must resort to locking each resource 531 individually. 533 8.2 Example: PROPFIND on a Collection with Redirect Reference Resources 535 Suppose a PROPFIND request with Depth: infinity is submitted to the 536 following collection, with the members shown here: 538 /MyCollection/ 539 (non-reference resource) diary.html 540 (redirect reference resource) nunavut 542 >> Request: 544 PROPFIND /MyCollection/ HTTP/1.1 545 Host: example.com 546 Depth: infinity 547 Apply-To-Redirect-Ref: F 548 Content-Type: text/xml 549 Content-Length: xxxx 551 552 553 554 555 556 557 558 >> Response: 560 HTTP/1.1 207 Multi-Status 561 Content-Type: text/xml 562 Content-Length: xxxx 564 565 566 567 /MyCollection/ 568 569 570 571 diary, interests, hobbies 572 573 HTTP/1.1 200 OK 574 575 576 577 /MyCollection/diary.html 578 579 580 581 diary, travel, family, history 582 583 HTTP/1.1 200 OK 584 585 586 587 /MyCollection/nunavut 588 HTTP/1.1 302 Found 589 590 http://example.ca/art/inuit/ 591 592 593 595 In this example the Depth header is set to infinity, and the Apply- 596 To-Redirect-Ref header is set to "F". The collection contains one 597 URI that identifies a redirect reference resource. The response 598 element for the redirect reference resource has a status of 302 599 (Found), and includes a DAV:location extension element to allow 600 clients to retrieve the properties of its target resource. (The 601 response element for the redirect reference resource does not include 602 the requested properties. The client can submit another PROPFIND 603 request to the URI in the DAV:location pseudo-property to retrieve 604 those properties.) 606 8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 607 Redirect Reference Resources 609 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: 610 infinity is submitted to the following collection, with the members 611 shown here: 613 /MyCollection/ 614 (non-reference resource) diary.html 615 (redirect reference resource) nunavut 617 >> Request: 619 PROPFIND /MyCollection/ HTTP/1.1 620 Host: example.com 621 Depth: infinity 622 Apply-To-Redirect-Ref: T 623 Content-Type: text/xml 624 Content-Length: xxxx 626 627 628 629 630 631 632 633 635 >> Response: 637 HTTP/1.1 207 Multi-Status 638 Content-Type: text/xml 639 Content-Length: xxxx 641 642 643 644 /MyCollection/ 645 646 647 648 649 HTTP/1.1 200 OK 650 651 652 653 654 655 656 HTTP/1.1 404 Not Found 657 658 659 660 /MyCollection/diary.html 661 662 663 664 665 HTTP/1.1 200 OK 666 667 668 669 670 671 672 HTTP/1.1 404 Not Found 673 674 675 676 /MyCollection/nunavut 677 678 679 680 681 http://example.ca/art/inuit/ 682 683 684 685 HTTP/1.1 200 OK 686 687 688 690 Since the "Apply-To-Redirect-Ref: T" header is present, the response 691 shows the properties of the redirect reference resource in the 692 collection rather than reporting a 302 status. 694 8.4 Example: COPY on a Collection That Contains a Redirect Reference 695 Resource 697 Suppose a COPY request is submitted to the following collection, with 698 the members shown: 700 /MyCollection/ 701 (non-reference resource) diary.html 702 (redirect reference resource) nunavut with target 703 /Someplace/nunavut.map 705 >> Request: 707 COPY /MyCollection/ HTTP/1.1 708 Host: example.com 709 Depth: infinity 710 Destination: http://example.com/OtherCollection/ 712 >> Response: 714 HTTP/1.1 207 Multi-Status 715 Content-Type: text/xml; charset="utf-8" 716 Content-Length: xxx 718 719 720 721 /MyCollection/nunavut 722 HTTP/1.1 302 Found 723 724 http://example.com//Someplace/nunavut.map 725 726 727 729 In this case, since /MyCollection/nunavut is a redirect reference 730 resource, the COPY operation was only a partial success. The 731 redirect reference resource was not copied, but a 302 response was 732 returned for it. So the resulting collection is as follows: 734 /OtherCollection/ 735 (non-reference resource) diary.html 737 8.5 Example: LOCK on a Collection That Contains a Redirect Reference 738 Resource 740 Suppose a LOCK request is submitted to the following collection, with 741 the members shown: 743 /MyCollection/ 744 (non-reference resource) diary.html 745 (redirect reference resource) nunavut 747 >> Request: 749 LOCK /MyCollection/ HTTP/1.1 750 Host: example.com 751 Apply-To-Redirect-Ref: F 752 Content-Type: text/xml 754 755 756 757 758 760 >> Response: 762 HTTP/1.1 207 Multi-Status 763 Content-Type: text/xml 764 Content-Length: nnnn 766 767 768 769 /MyCollection/ 770 HTTP/1.1 424 Failed Dependency 771 772 773 /MyCollection/diary.html 774 HTTP/1.1 424 Failed Dependency 775 776 777 /MyCollection/nunavut 778 HTTP/1.1 302 Found 779 780 http://example.ca/art/inuit/ 781 782 783 785 The server returns a 302 response code for the redirect reference 786 resource in the collection. Consequently, neither the collection nor 787 any of the resources identified by its internal member URIs were 788 locked. A referencing-aware client can submit a separate LOCK 789 request to the URI in the DAV:location element returned for the 790 redirect reference resource, and can resubmit the LOCK request with 791 the Apply-To-Redirect-Ref header to the collection. At that point 792 both the reference resource and its target resource will be locked 793 (as well as the collection and all the resources identified by its 794 other members). 796 9. Operations on Targets of Redirect Reference Resources 798 Operations on targets of redirect reference resources have no effect 799 on the reference resource. 801 10. Relative references in DAV:reftarget 803 The URI in the href in a DAV:reftarget property MAY be a relative 804 reference. In this case, the base URI to be used for resolving it to 805 absolute form is the URI used in the HTTP message to identify the 806 redirect reference resource to which the DAV:reftarget property 807 belongs. 809 When DAV:reftarget appears in the context of a Multi-Status response, 810 it is in a DAV:response element that contains a single DAV:href 811 element. The value of this DAV:href element serves as the base URI 812 for resolving a relative reference in DAV:reftarget. The value of 813 DAV:href may itself be relative, in which case it must be resolved 814 first in order to serve as the base URI for the relative reference in 815 DAV:reftarget. If the DAV:href element is relative, its base URI is 816 constructed from the scheme component "http", the value of the Host 817 header in the request, and the Request-URI. 819 10.1 Example: Resolving a Relative Reference in a Multi-Status Response 821 >> Request: 823 PROPFIND /geog/ HTTP/1.1 824 Host: example.com 825 Apply-To-Redirect-Ref: T 826 Depth: 1 827 Content-Type: text/xml 828 Content-Length: nnn 830 831 832 833 834 835 836 837 >> Response: 839 HTTP/1.1 207 Multi-Status 840 Content-Type: text/xml 841 Content-Length: nnn 843 844 845 846 /geog/ 847 848 849 850 851 HTTP/1.1 200 OK 852 853 854 855 HTTP/1.1 404 Not Found 856 857 858 859 /geog/stats.html 860 861 862 863 864 statistics/population/1997.html 865 866 867 HTTP/1.1 200 OK 868 869 870 872 In this example, the relative reference "statistics/population/ 873 1997.html" is returned as the value of the DAV:reftarget property for 874 the reference resource identified by href /geog/stats.html. The href 875 is itself a relative reference, which resolves to 876 http://example.com/geog/stats.html. This is the base URI for 877 resolving the relative reference in reftarget. The absolute URI of 878 reftarget is http://example.com/geog/statistics/population/1997.html. 880 11. Redirect References to Collections 882 In a Request-URI /segment1/segment2/segment3, any of the three 883 segments may identify a redirect reference resource. (See [RFC3986], 884 Section 3.3, for definitions of "path" and "segment".) If any 885 segment in a Request-URI identifies a redirect reference resource, 886 the response SHOULD be a 3xx. The value of the Location header in 887 the response is as follows: 889 The leftmost path segment of the Request-URI that identifies a 890 redirect reference resource, together with all path segments and 891 separators to the left of it, is replaced by the value of the 892 redirect reference resource's DAV:reftarget property (resolved to an 893 absolute URI). The remainder of the Request-URI is concatenated to 894 this path. 896 Note: If the DAV:reftarget property ends with a "/" and the remainder 897 of the Request-URI is non-empty (and therefore must begin with a 898 "/"), the final "/" in the DAV:reftarget property is dropped before 899 the remainder of the Request-URI is appended. 901 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 902 reference resource whose target resource is collection /a/, which 903 contains redirect reference resource y whose target resource is 904 collection /b/, which contains redirect reference resource z.html 905 whose target resource is /c/d.html. 907 /x/y/z.html 908 | 909 | /x -> /a 910 | 911 v 912 /a/y/z.html 913 | 914 | /a/y -> /b 915 | 916 v 917 /b/z.html 918 | 919 | /b/z.html -> /c/d.html 920 | 921 v 922 /c/d.html 924 In this case the client must follow up three separate 3xx responses 925 before finally reaching the target resource. The server responds to 926 the initial request with a 3xx with Location: /a/y/z.html, and the 927 client resubmits the request to /a/y/z.html. The server responds to 928 this request with a 3xx with Location: /b/z.html, and the client 929 resubmits the request to /b/z.html. The server responds to this 930 request with a 3xx with Location: /c/d.html, and the client resubmits 931 the request to /c/d.html. This final request succeeds. 933 Note: the behavior described above may have a very serious impact 934 on the efficiency of mapping Request-URIs to resources in HTTP 935 request processing. Therefore servers MAY respond with a 404 936 status code if the cost of checking all leading path segments for 937 redirect references seems prohibitive. 939 12. Headers 941 12.1 Redirect-Ref Response Header 943 Redirect-Ref = "Redirect-Ref:" (absolute-URI | 944 relative-part [ "?" query ]) 945 ; absolute-URI: see [RFC3986], section 4.3 946 ; query: see [RFC3986], section 3.4 947 ; relative-part: see [RFC3986], section 4.2 949 The Redirect-Ref header is used in all 3xx responses from redirect 950 reference resources. The value is the link target as specified 951 during redirect reference resource creation. 953 12.2 Apply-To-Redirect-Ref Request Header 955 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") 957 The optional Apply-To-Redirect-Ref header can be used on any request 958 to a redirect reference resource. When it is present and set to "T", 959 the request MUST be applied to the reference resource itself, and a 960 3xx response MUST NOT be returned. 962 If the Apply-To-Redirect-Ref header is used on a request to any other 963 sort of resource besides a redirect reference resource, the server 964 MUST ignore it. 966 13. Redirect Reference Resource Properties 968 The properties defined below are REQUIRED on redirect reference 969 resources. A PROPFIND/allprop request SHOULD NOT return any of the 970 properties defined in this document. 972 13.1 DAV:redirect-lifetime (protected) 974 This property provides information about the lifetime of a redirect. 975 It can either be DAV:permanent (HTTP status 301) or DAV:temporary 976 (HTTP status 302). Future protocols may define additional values. 978 979 980 982 13.2 DAV:reftarget (protected) 984 This property provides an efficient way for clients to discover the 985 URI of the target resource. This is a read-only property after its 986 initial creation. Its value can only be set in a MKREDIRECTREF 987 request. The value is a DAV:href element containing the URI of the 988 target resource. 990 992 14. XML Elements 994 14.1 redirectref XML Element 996 Name: redirectref 998 Namespace: DAV: 1000 Purpose: Used as the value of the DAV:resourcetype property to 1001 specify that the resource type is a redirect reference resource. 1003 1005 15. Extensions to the DAV:response XML Element for Multi-Status 1006 Responses 1008 As described in Section 8, the DAV:location element may be returned 1009 in the DAV:response element of a 207 Multi-Status response, to allow 1010 clients to resubmit their requests to the target resource of a 1011 redirect reference resource. 1013 Consequently, the definition of the DAV:response XML element changes 1014 to the following: 1016 1018 1020 16. Capability Discovery 1022 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 1023 classes with the DAV header in responses to OPTIONS, to indicate 1024 which parts of the WebDAV Distributed Authoring protocols the 1025 resource supports. This specification defines an OPTIONAL extension 1026 to [RFC2518]. It defines a new compliance class, called 1027 redirectrefs, for use with the DAV header in responses to OPTIONS 1028 requests. If a resource does support redirect references, its 1029 response to an OPTIONS request may indicate that it does, by listing 1030 the new redirectrefs compliance class in the DAV header and by 1031 listing the MKREDIRECTREF method as one it supports. 1033 When responding to an OPTIONS request, any type of resource can 1034 include redirectrefs in the value of the DAV header. Doing so 1035 indicates that the server permits a redirect reference resource at 1036 the Request-URI. 1038 16.1 Example: Discovery of Support for Redirect Reference Resources 1040 >> Request: 1042 OPTIONS /somecollection/someresource HTTP/1.1 1043 Host: example.org 1045 >> Response: 1047 HTTP/1.1 200 OK 1048 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 1049 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF 1050 DAV: 1, 2, redirectrefs 1052 The DAV header in the response indicates that the resource 1053 /somecollection/someresource is level 1 and level 2 compliant, as 1054 defined in [RFC2518]. In addition, /somecollection/someresource 1055 supports redirect reference resources. The Allow header indicates 1056 that MKREDIRECTREF requests can be submitted to /somecollection/ 1057 someresource. 1059 17. Security Considerations 1061 This section is provided to make applications that implement this 1062 protocol aware of the security implications of this protocol. 1064 All of the security considerations of HTTP/1.1 and the WebDAV 1065 Distributed Authoring Protocol specification also apply to this 1066 protocol specification. In addition, redirect reference resources 1067 introduce several new security concerns and increase the risk of some 1068 existing threats. These issues are detailed below. 1070 17.1 Privacy Concerns 1072 By creating redirect reference resources on a trusted server, it is 1073 possible for a hostile agent to induce users to send private 1074 information to a target on an unrelated system. This risk is 1075 mitigated somewhat, since clients are required to notify the user of 1076 the redirection for any request other than GET or HEAD. (See 1077 [RFC2616], Section 10.3.3 302 Found.) 1079 17.2 Redirect Loops 1081 Although redirect loops were already possible in HTTP 1.1, the 1082 introduction of the MKREDIRECTREF method creates a new avenue for 1083 clients to create loops accidentally or maliciously. If the 1084 reference resource and its target are on the same server, the server 1085 may be able to detect MKREDIRECTREF requests that would create loops. 1086 See also [RFC2616], Section 10.3 "Redirection 3xx." 1088 17.3 Redirect Reference Resources and Denial of Service 1090 Denial of service attacks were already possible by posting URLs that 1091 were intended for limited use at heavily used Web sites. The 1092 introduction of MKREDIRECTREF creates a new avenue for similar denial 1093 of service attacks. Clients can now create redirect reference 1094 resources at heavily used sites to target locations that were not 1095 designed for heavy usage. 1097 17.4 Revealing Private Locations 1099 There are several ways that redirect reference resources may reveal 1100 information about collection structures. First, the DAV:reftarget 1101 property of every redirect reference resource contains the URI of the 1102 target resource. Anyone who has access to the reference resource can 1103 discover the collection path that leads to the target resource. The 1104 owner of the target resource may have wanted to limit knowledge of 1105 this collection structure. 1107 Sufficiently powerful access control mechanisms can control this risk 1108 to some extent. Property-level access control could prevent users 1109 from examining the DAV:reftarget property. (The Location header 1110 returned in responses to requests on redirect reference resources 1111 reveals the same information, however.) 1113 This risk is no greater than the similar risk posed by HTML links. 1115 18. Internationalization Considerations 1117 All internationalization considerations mentioned in [RFC2518] also 1118 apply to this document. 1120 19. IANA Considerations 1122 All IANA considerations mentioned in [RFC2518] also apply to this 1123 document. 1125 20. Contributors 1127 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 1128 who can take credit for big parts of the original design of this 1129 specification. 1131 21. Acknowledgements 1133 This document has benefited from thoughtful discussion by Jim Amsden, 1134 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1135 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1136 Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred 1137 Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj 1138 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry 1139 Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen 1140 Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1141 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1143 22. Normative References 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, March 1997. 1148 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1149 Specifications: ABNF", RFC 2234, November 1997. 1151 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1152 Jensen, "HTTP Extensions for Distributed Authoring -- 1153 WEBDAV", RFC 2518, February 1999. 1155 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1156 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1157 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1159 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1160 Whitehead, "Versioning Extensions to WebDAV (Web 1161 Distributed Authoring and Versioning)", RFC 3253, 1162 March 2002. 1164 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1165 Resource Identifier (URI): Generic Syntax", STD 66, 1166 RFC 3986, January 2005. 1168 Authors' Addresses 1170 Jim Whitehead 1171 UC Santa Cruz, Dept. of Computer Science 1172 1156 High Street 1173 Santa Cruz, CA 95064 1174 US 1176 Email: ejw@cse.ucsc.edu 1178 Geoff Clemm 1179 IBM 1180 20 Maguire Road 1181 Lexington, MA 02421 1182 US 1184 Email: geoffrey.clemm@us.ibm.com 1186 Julian F. Reschke (editor) 1187 greenbytes GmbH 1188 Salzmannstrasse 152 1189 Muenster, NW 48159 1190 Germany 1192 Phone: +49 251 2807760 1193 Fax: +49 251 2807761 1194 Email: julian.reschke@greenbytes.de 1195 URI: http://greenbytes.de/tech/webdav/ 1197 Appendix A. Changes to the WebDAV Document Type Definition 1199 1201 1202 1204 1206 1207 1209 1211 1213 Appendix B. Change Log (to be removed by RFC Editor before publication) 1215 B.1 Since draft-ietf-webdav-redirectref-protocol-02 1217 Julian Reschke takes editorial role (added to authors list). Cleanup 1218 XML indentation. Start adding all unresolved last call issues. 1219 Update some author's contact information. Update references, split 1220 into "normative" and "informational". Remove non-RFC2616 headers 1221 ("Public") from examples. Fixed width problems in artwork. Start 1222 resolving editorial issues. 1224 B.2 Since draft-ietf-webdav-redirectref-protocol-03 1226 Added Joe Orton and Juergen Reuter to Acknowledgements section. 1227 Close more editorial issues. Remove dependencies on BIND spec. 1229 B.3 Since draft-ietf-webdav-redirectref-protocol-04 1231 More editorial fixes. Clarify that MKRESOURCE can only be used to 1232 create redirect references (switch to new method in a future draft). 1233 Clarify that redirect references do not have bodies. 1235 B.4 Since draft-ietf-webdav-redirectref-protocol-05 1237 Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606- 1238 compliance". Close issues "lc-50-blindredirect", "lc-71-relative", 1239 "lc-74-terminology". Update contact info for Geoff Clemm. Moved 1240 some of the original authors names to new Contributors section. Add 1241 and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72- 1242 trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301" 1243 with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE- 1244 vs-relative-URI was a duplicate of this one). Also remove section 1245 9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue 1246 "11.2-apply-to-redirect-ref-syntax" (header now has values "T" and 1247 "F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add 1248 and resolve "15.1-options-response". 1250 B.5 Since draft-ietf-webdav-redirectref-protocol-06 1252 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc- 1253 44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n" 1254 and "rfc2606-compliance". Start work on index. Add new issue 1255 "old_clients". 1257 B.6 Since draft-ietf-webdav-redirectref-protocol-07 1259 Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in 1260 appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav". 1261 Add issue "5_mkresource" and start work on MKREDIRECTREF (issue 1262 closed, but more work on MKREDIRECTREF needs to be done for updates 1263 and status codes other than 302). Start resolution of "lc-85-301", 1264 replacing "302" by more generic language. Update issue "lc-57- 1265 noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57- 1266 autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S. 1267 Eissing to Acknowledgments section. 1269 B.7 Since draft-ietf-webdav-redirectref-protocol-08 1271 Fix index entries for conditions. Open and resolve issue 1272 "specify_safeness". Rewrite editorial section and parts of intro. 1273 Add more clarifications for issue "lc-85-301" and close it. 1275 B.8 Since draft-ietf-webdav-redirectref-protocol-09 1277 Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57- 1278 noautoupdate". Close issues "lc-48-s6", "12.1-property-name", "3- 1279 terminology-redirectref" and "lc-58-update". Rearrange section 5 and 1280 6. Add some more terms to index (no change tracking). 1282 B.9 Since draft-ietf-webdav-redirectref-protocol-10 1284 Add and resolve issues "13_allprop" and "rfc2396bis". Use the term 1285 "Request-URI" throughout (this is what RFC2616 defines). Center some 1286 of the artwork. Add and resolve issue "abnf". 1288 Appendix C. Resolved issues (to be removed by RFC Editor before 1289 publication) 1291 Issues that were either rejected or resolved in this version of this 1292 document. 1294 C.1 abnf 1296 Type: change 1298 julian.reschke@greenbytes.de (2005-02-09): Use ABNF syntax from 1299 RFC2234. 1301 Resolution (2005-02-09): Done. 1303 C.2 rfc2396bis 1305 Type: change 1307 julian.reschke@greenbytes.de (2004-10-22): Update to RFC2396bis (this 1308 needs to be done carefully because we are using the term "relative 1309 URI reference" which does not exist in RFC2396bis anymore). 1311 Resolution (2005-01-25): Agreed (draft-rfc2396bis has been published 1312 as RFC3986). 1314 C.3 13_allprop 1316 Type: change 1318 1321 julian.reschke@greenbytes.de (2004-11-13): Make the spec consistent 1322 with RFC3253, RFC3648 and RFC3744 (new properties not returned upon 1323 PROPFIND/allprop requests). 1325 Resolution (2004-11-13): Add statement about PROPFIND/allprop 1326 behaviour. 1328 Appendix D. Open issues (to be removed by RFC Editor prior to 1329 publication) 1331 D.1 edit 1333 Type: edit 1335 julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for 1336 editorial changes. 1338 D.2 old_clients 1340 Type: change 1342 1345 julian.reschke@greenbytes.de (2003-11-10): There are (at least) two 1346 major design goals, but unfortunately both are in direct 1347 contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This 1348 means that any request that addresses a redirect reference resource 1349 MUST result in a 3xx status code (obviously the whole point is that 1350 GET MUST result in a redirection, and if it does, it's hard to say 1351 why other methods such as PUT or DELETE should behave differently). 1352 Therefore, the redirect reference protocol introduces a new request 1353 header ("Apply-To-Redirect-Ref") through which a client can indicate 1354 that the request indeed should be applied to the redirect reference 1355 resource itself. #2: Maximum usability with existing clients. For 1356 instance, the Microsoft Webfolder client will not be able to DELETE a 1357 redirect reference resource unless the server deviates from #1. 1358 Right now I'm not sure about the best way to resolve this. Currently 1359 the spec chooses #1 (back when this decision was made, there was 1360 probably the assumption that existing clients would quickly be 1361 updated -- something that probably isn't true today). However this 1362 may result in implementers either just ignoring these rules, or 1363 adding special workarounds based on "User Agent" detection. 1365 Index 1367 A 1368 Apply-To-Redirect-Ref header 22 1370 C 1371 Condition Names 1372 DAV:locked-update-allowed (pre) 9, 11 1373 DAV:must-be-redirectref (pre) 11 1374 DAV:name-allowed (pre) 9 1375 DAV:new-redirectref (post) 10 1376 DAV:parent-resource-must-be-non-null (pre) 9 1377 DAV:redirect-lifetime-supported (pre) 9, 11 1378 DAV:redirect-lifetime-update-supported (pre) 11 1379 DAV:redirectref-updated (post) 11 1380 DAV:resource-must-be-null (pre) 9 1382 D 1383 DAV header 1384 compliance class 'redirectrefs' 23 1385 DAV:locked-update-allowed precondition 9, 11 1386 DAV:must-be-redirectref precondition 11 1387 DAV:name-allowed precondition 9 1388 DAV:new-redirectref postcondition 10 1389 DAV:parent-resource-must-be-non-null precondition 9 1390 DAV:redirect-lifetime property 22 1391 DAV:redirect-lifetime-supported precondition 9, 11 1392 DAV:redirect-lifetime-update-supported precondition 11 1393 DAV:redirectref resource type 23 1394 DAV:redirectref-updated postcondition 11 1395 DAV:reftarget property 23 1396 DAV:resource-must-be-null precondition 9 1398 H 1399 Headers 1400 Apply-To-Redirect-Ref 22 1401 Redirect-Ref 22 1403 M 1404 Methods 1405 MKREDIRECTREF 8 1406 UPDATEREDIRECTREF 10 1407 MKREDIRECTREF method 8 1409 N 1410 Non-Reference Resource 6 1412 P 1413 Properties 1414 DAV:redirect-lifetime 22 1415 DAV:reftarget 23 1417 R 1418 Redirect-Ref header 22 1419 Rediret Reference Resource 6 1420 Resource Types 1421 DAV:redirectref 23 1423 T 1424 Target Resource 6 1426 U 1427 UPDATEREDIRECTREF method 10 1429 Intellectual Property Statement 1431 The IETF takes no position regarding the validity or scope of any 1432 Intellectual Property Rights or other rights that might be claimed to 1433 pertain to the implementation or use of the technology described in 1434 this document or the extent to which any license under such rights 1435 might or might not be available; nor does it represent that it has 1436 made any independent effort to identify any such rights. Information 1437 on the procedures with respect to rights in RFC documents can be 1438 found in BCP 78 and BCP 79. 1440 Copies of IPR disclosures made to the IETF Secretariat and any 1441 assurances of licenses to be made available, or the result of an 1442 attempt made to obtain a general license or permission for the use of 1443 such proprietary rights by implementers or users of this 1444 specification can be obtained from the IETF on-line IPR repository at 1445 http://www.ietf.org/ipr. 1447 The IETF invites any interested party to bring to its attention any 1448 copyrights, patents or patent applications, or other proprietary 1449 rights that may cover technology that may be required to implement 1450 this standard. Please address the information to the IETF at 1451 ietf-ipr@ietf.org. 1453 Disclaimer of Validity 1455 This document and the information contained herein are provided on an 1456 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1457 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1458 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1459 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1460 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1461 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1463 Copyright Statement 1465 Copyright (C) The Internet Society (2005). This document is subject 1466 to the rights, licenses and restrictions contained in BCP 78, and 1467 except as set forth therein, the authors retain all their rights. 1469 Acknowledgment 1471 Funding for the RFC Editor function is currently provided by the 1472 Internet Society.