idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-12.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 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1394. ** 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. 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 893 has weird spacing: '... the respon...' == Line 954 has weird spacing: '... is the link ...' == Line 1013 has weird spacing: '...ment of a 207...' == Line 1014 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 (May 7, 2005) is 6926 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 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: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: November 8, 2005 G. Clemm 5 IBM 6 J. Reschke, Ed. 7 greenbytes 8 May 7, 2005 10 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference 11 Resources 12 draft-ietf-webdav-redirectref-protocol-12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 8, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This specification defines redirect reference resources. A redirect 46 reference resource is a resource whose default response is an 47 HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), 48 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 . . 13 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 . . . . . . . . . . . . . . . . . . . . 24 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. Change Log (to be removed by RFC Editor before 123 publication) . . . . . . . . . . . . . . . . . . . . . . . . 27 124 A.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 27 125 A.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 27 126 A.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28 127 A.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28 128 A.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28 129 A.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28 130 A.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 28 131 A.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29 132 A.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29 133 A.10 Since draft-ietf-webdav-redirectref-protocol-11 . . . . 29 134 B. Open issues (to be removed by RFC Editor prior to 135 publication) . . . . . . . . . . . . . . . . . . . . . . . . 29 136 B.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 137 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 138 Intellectual Property and Copyright Statements . . . . . . . 32 140 1. Introduction 142 This specification extends the Web Distributed Authoring Protocol 143 (WebDAV) to enable clients to create new access paths to existing 144 resources. This capability is useful for several reasons: 146 WebDAV makes it possible to organize HTTP resources into hierarchies, 147 placing them into groupings, known as collections, which are more 148 easily browsed and manipulated than a single flat collection. 149 However, hierarchies require categorization decisions that locate 150 resources at a single location in the hierarchy, a drawback when a 151 resource has multiple valid categories. For example, in a hierarchy 152 of vehicle descriptions containing collections for cars and boats, a 153 description of a combination car/boat vehicle could belong in either 154 collection. Ideally, the description should be accessible from both. 155 Allowing clients to create new URIs that access the existing resource 156 lets them put that resource into multiple collections. 158 Hierarchies also make resource sharing more difficult, since 159 resources that have utility across many collections are still forced 160 into a single collection. For example, the mathematics department at 161 one university might create a collection of information on fractals 162 that contains bindings to some local resources, but also provides 163 access to some resources at other universities. For many reasons, it 164 may be undesirable to make physical copies of the shared resources: 165 to conserve disk space, to respect copyright constraints, or to make 166 any changes in the shared resources visible automatically. Being 167 able to create new access paths to existing resources in other 168 collections or even on other unrelated systems is useful for this 169 sort of case. 171 The redirect reference resources defined here provide a mechanism for 172 creating alternative access paths to existing resources. A redirect 173 reference resource is a resource in one collection whose purpose is 174 to redirect requests to another resource (its target), possibly in a 175 different collection. In this way, it allows clients to submit 176 requests to the target resource from another collection. It 177 redirects most requests to the target resource using a HTTP status 178 code from the 3xx range (Redirection), thereby providing a form of 179 mediated access to the target resource. 181 A redirect reference is a resource with properties but no body of its 182 own. Properties of a redirect reference resource can contain such 183 information as who created the reference, when, and why. Since 184 redirect reference resources are implemented using HTTP 3xx 185 responses, it generally takes two round trips to submit a request to 186 the intended resource. Redirect references work equally well for 187 local resources and for resources that reside on a different system 188 from the reference. 190 The remainder of this document is structured as follows: Section 3 191 defines terms that will be used throughout the specification. 192 Section 4 provides an overview of redirect reference resources. 193 Section 5 defines the semantics of existing methods when applied to 194 redirect reference resources. Section 6 discusses how to create a 195 redirect reference resource, and Section 7 discusses updating 196 redirect references. Section 8 discusses their semantics when 197 applied to collections that contain redirect reference resources. 198 Sections 9 through 11 discuss several other issues raised by the 199 existence of redirect reference resources. Sections 12 through 15 200 define the new headers, properties, and XML elements required to 201 support redirect reference resources. Section 16 discusses 202 capability discovery. Sections 17 through 19 present the security, 203 internationalization, and IANA concerns raised by this specification. 204 The remaining sections provide a variety of supporting information. 206 2. Notational Conventions 208 Since this document describes a set of extensions to the WebDAV 209 Distributed Authoring Protocol [RFC2518], itself an extension to the 210 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 211 elements is exactly the same as described in Section 2.1 of 212 [RFC2616]. Since this augmented BNF uses the basic production rules 213 provided in Section 2.2 of [RFC2616], these rules apply to this 214 document as well. 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 3. Terminology 222 The terminology used here follows and extends that in the WebDAV 223 Distributed Authoring Protocol specification [RFC2518]. Definitions 224 of the terms resource, Uniform Resource Identifier (URI), and Uniform 225 Resource Locator (URL) are provided in [RFC3986]. 227 Redirect Reference Resource 229 A resource created to redirect all requests made to it, using an 230 HTTP status code from the 3xx range, to a defined target resource. 232 Non-Reference Resource 234 A resource that is not a reference to another resource. 236 Target Resource 238 The resource to which requests are redirected by a redirect 239 reference resource. A target resource can be anything that can be 240 identified by an absolute URI (see [RFC3986], "absolute-URI"). 242 This document uses the terms "precondition", "postcondition" and 243 "protected property" as defined in [RFC3253]. Servers MUST report 244 pre-/postcondition failures as described in section 1.6 of this 245 document. 247 4. Overview of Redirect Reference Resources 249 For all operations submitted to a redirect reference resource, the 250 default response is a 302 (Found), accompanied by the Redirect-Ref 251 header (defined in Section 12.1 below) and the Location header 252 ([RFC2616], Section 14.30) set to the URI of the target resource. 253 With this information, the client can resubmit the request to the URI 254 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 URI (see [RFC3986], 303 Section 3) that 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 333 [RFC2616], section 9.1). 335 Marshalling: 337 The request body MUST be a DAV:mkredirectref XML element. 339 340 341 342 343 345 The DAV:href element is defined in [RFC2518] (Section 12.3) and 346 MUST contain either an URI or a relative-ref (see [RFC3986], 347 Sections 3 and 4.2). 349 If no DAV:redirect-lifetime element is specified, the server MUST 350 behave as if a value of DAV:temporary was specified. 352 If the request succeeds, the server MUST return 201 (Created) 353 status. 355 If a response body for a successful request is included, it MUST 356 be a DAV:mkredirectref-response XML element. Note that this 357 document does not define any elements for the MKREDIRECTREF 358 response body, but the DAV:mkredirectref-response element is 359 defined to ensure interoperability between future extensions that 360 do define elements for the response body. 362 364 Preconditions: 366 (DAV:resource-must-be-null): A resource MUST NOT exist at the 367 Request-URI. 369 (DAV:parent-resource-must-be-non-null): The Request-URI minus the 370 last past segment MUST identify a collection. 372 (DAV:name-allowed): The last segment of the Request-URI is 373 available for use as a resource name. 375 (DAV:locked-update-allowed): If the collection identified by the 376 Request-URI minus the last path segment is write-locked, then the 377 appropriate token MUST be specified in an If request header. 379 (DAV:redirect-lifetime-supported): If the request body contains a 380 DAV:redirect-lifetime element, the server MUST support the 381 specified lifetime. Support for DAV:temporary is REQUIRED, while 382 support for DAV:permanent is OPTIONAL. 384 (DAV:legal-reftarget): The specified is a legal URI or relative- 385 ref. 387 Postconditions: 389 (DAV:new-redirectref): a new redirect reference resource is 390 created whose DAV:reftarget property has the value specified in 391 the request body. 393 6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF 395 >> Request: 397 MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 398 Host: www.example.com 399 Content-Type: text/xml; charset="utf-8" 400 Content-Length: xxx 402 403 404 405 /i-d/draft-webdav-protocol-08.txt 406 407 409 >> Response: 411 HTTP/1.1 201 Created 413 This request resulted in the creation of a new redirect reference 414 resource at http://www.example.com/~whitehead/dav/spec08.ref, which 415 points to the resource identified by the DAV:reftarget property. In 416 this example, the target resource is identified by the URI 417 http://www.example.com/i-d/draft-webdav-protocol-08.txt. The 418 redirect reference resource's DAV:resourcetype property is set to 419 DAV:redirectref and it's DAV:redirect-lifetime property has the value 420 DAV:temporary. 422 7. UPDATEREDIRECTREF Method 424 The UPDATEREDIRECTREF method requests the update of a redirect 425 reference resource. 427 If a UPDATEREDIRECTREF request fails, the server state preceding the 428 request MUST be restored. 430 Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as 431 UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], section 432 9.1). 434 Marshalling: 436 The request body MUST be a DAV:updateredirectref XML element. 438 439 See Section 6 for a definition of DAV:reftarget and DAV:redirect- 440 lifetime. 442 If no DAV:reftarget element is specified, the server MUST NOT 443 change the target of the redirect reference. 445 If no DAV:redirect-lifetime element is specified, the server MUST 446 NOT change the lifetime of the redirect reference. 448 If a response body for a successful request is included, it MUST 449 be a DAV:updateredirectref-response XML element. Note that this 450 document does not define any elements for the UPDATEREDIRECTREF 451 response body, but the DAV:updateredirectref-response element is 452 defined to ensure interoperability between future extensions that 453 do define elements for the response body. 455 457 Preconditions: 459 (DAV:locked-update-allowed): if the resource is write-locked, then 460 the appropriate token MUST be specified in an If request header. 462 (DAV:must-be-redirectref): the resource identified by the Request- 463 URI must be a redirect reference resource as defined by this 464 specification. 466 (DAV:redirect-lifetime-supported): see Section 6. 468 (DAV:redirect-lifetime-update-supported): servers MAY support 469 changing the DAV:redirect-lifetime property; if they don't, this 470 condition code can be used to signal failure. 472 (DAV:legal-reftarget): see Section 6. 474 Postconditions: 476 (DAV:redirectref-updated): the DAV:reftarget and DAV:redirect- 477 lifetime properties of the redirect reference have been updated 478 accordingly. 480 7.1 Example: Updating a Redirect Reference Resource with 481 UPDATEREDIRECTREF 483 >> Request: 485 UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 486 Host: www.example.com 487 Apply-To-Redirect-Ref: T 488 Content-Type: text/xml; charset="utf-8" 489 Content-Length: xxx 491 492 493 494 /i-d/draft-webdav-protocol-08b.txt 495 496 498 >> Response: 500 HTTP/1.1 200 OK 502 This request has updated the redirect reference's DAV:reftarget 503 property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed 504 the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect- 505 Ref" request header must be used, otherwise the request would result 506 in a redirect (3xx) response status. 508 8. Operations on Collections That Contain Redirect Reference Resources 510 Consistent with the rules in Section 5, the response for each 511 redirect reference encountered while processing a collection MUST be 512 a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is 513 included with the request. The overall response will therefore be a 514 207 (Multi-Status). For each DAV:response element representing a 515 redirect reference, the server MUST include an additional DAV: 516 location element, specifying the value of the "Location" header that 517 would be returned otherwise. The extension is defined in Section 15 518 below. 520 The Apply-To-Redirect-Ref header (defined in Section 12.2) MAY be 521 used with any request on a collection. If present, it will be 522 applied to all redirect reference resources encountered while 523 processing the collection. 525 8.1 LOCK on a Collection That Contains Redirect References 527 An attempt to lock (with Depth: infinity) a collection that contains 528 redirect references without specifying "Apply-To-Redirect-Ref: T" 529 will always fail. The Multi-Status response will contain a 3xx 530 response for each redirect reference. 532 Reference-aware clients can lock the collection by using Apply-To- 533 Redirect-Ref, and, if desired, lock the targets of the redirect 534 references individually. 536 Non-referencing clients must resort to locking each resource 537 individually. 539 8.2 Example: PROPFIND on a Collection with Redirect Reference Resources 541 Suppose a PROPFIND request with Depth: infinity is submitted to the 542 following collection, with the members shown here: 544 /MyCollection/ 545 (non-reference resource) diary.html 546 (redirect reference resource) nunavut 548 >> Request: 550 PROPFIND /MyCollection/ HTTP/1.1 551 Host: example.com 552 Depth: infinity 553 Apply-To-Redirect-Ref: F 554 Content-Type: text/xml 555 Content-Length: xxxx 557 558 559 560 561 562 563 564 >> Response: 566 HTTP/1.1 207 Multi-Status 567 Content-Type: text/xml 568 Content-Length: xxxx 570 571 572 573 /MyCollection/ 574 575 576 577 diary, interests, hobbies 578 579 HTTP/1.1 200 OK 580 581 582 583 /MyCollection/diary.html 584 585 586 587 diary, travel, family, history 588 589 HTTP/1.1 200 OK 590 591 592 593 /MyCollection/nunavut 594 HTTP/1.1 302 Found 595 596 http://example.ca/art/inuit/ 597 598 599 601 In this example the Depth header is set to infinity, and the Apply- 602 To-Redirect-Ref header is set to "F". The collection contains one 603 URI that identifies a redirect reference resource. The response 604 element for the redirect reference resource has a status of 302 605 (Found), and includes a DAV:location extension element to allow 606 clients to retrieve the properties of its target resource. (The 607 response element for the redirect reference resource does not include 608 the requested properties. The client can submit another PROPFIND 609 request to the URI in the DAV:location pseudo-property to retrieve 610 those properties.) 612 8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 613 Redirect Reference Resources 615 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: 616 infinity is submitted to the following collection, with the members 617 shown here: 619 /MyCollection/ 620 (non-reference resource) diary.html 621 (redirect reference resource) nunavut 623 >> Request: 625 PROPFIND /MyCollection/ HTTP/1.1 626 Host: example.com 627 Depth: infinity 628 Apply-To-Redirect-Ref: T 629 Content-Type: text/xml 630 Content-Length: xxxx 632 633 634 635 636 637 638 639 641 >> Response: 643 HTTP/1.1 207 Multi-Status 644 Content-Type: text/xml 645 Content-Length: xxxx 647 648 649 650 /MyCollection/ 651 652 653 654 655 HTTP/1.1 200 OK 656 657 658 659 660 661 662 HTTP/1.1 404 Not Found 663 664 665 666 /MyCollection/diary.html 667 668 669 670 671 HTTP/1.1 200 OK 672 673 674 675 676 677 678 HTTP/1.1 404 Not Found 679 680 681 682 /MyCollection/nunavut 683 684 685 686 687 http://example.ca/art/inuit/ 688 689 690 691 HTTP/1.1 200 OK 692 693 694 696 Since the "Apply-To-Redirect-Ref: T" header is present, the response 697 shows the properties of the redirect reference resource in the 698 collection rather than reporting a 302 status. 700 8.4 Example: COPY on a Collection That Contains a Redirect Reference 701 Resource 703 Suppose a COPY request is submitted to the following collection, with 704 the members shown: 706 /MyCollection/ 707 (non-reference resource) diary.html 708 (redirect reference resource) nunavut with target 709 /Someplace/nunavut.map 711 >> Request: 713 COPY /MyCollection/ HTTP/1.1 714 Host: example.com 715 Depth: infinity 716 Destination: http://example.com/OtherCollection/ 718 >> Response: 720 HTTP/1.1 207 Multi-Status 721 Content-Type: text/xml; charset="utf-8" 722 Content-Length: xxx 724 725 726 727 /MyCollection/nunavut 728 HTTP/1.1 302 Found 729 730 http://example.com//Someplace/nunavut.map 731 732 733 735 In this case, since /MyCollection/nunavut is a redirect reference 736 resource, the COPY operation was only a partial success. The 737 redirect reference resource was not copied, but a 302 response was 738 returned for it. So the resulting collection is as follows: 740 /OtherCollection/ 741 (non-reference resource) diary.html 743 8.5 Example: LOCK on a Collection That Contains a Redirect Reference 744 Resource 746 Suppose a LOCK request is submitted to the following collection, with 747 the members shown: 749 /MyCollection/ 750 (non-reference resource) diary.html 751 (redirect reference resource) nunavut 753 >> Request: 755 LOCK /MyCollection/ HTTP/1.1 756 Host: example.com 757 Apply-To-Redirect-Ref: F 758 Content-Type: text/xml 760 761 762 763 764 766 >> Response: 768 HTTP/1.1 207 Multi-Status 769 Content-Type: text/xml 770 Content-Length: nnnn 772 773 774 775 /MyCollection/ 776 HTTP/1.1 424 Failed Dependency 777 778 779 /MyCollection/diary.html 780 HTTP/1.1 424 Failed Dependency 781 782 783 /MyCollection/nunavut 784 HTTP/1.1 302 Found 785 786 http://example.ca/art/inuit/ 787 788 789 791 The server returns a 302 response code for the redirect reference 792 resource in the collection. Consequently, neither the collection nor 793 any of the resources identified by its internal member URIs were 794 locked. A referencing-aware client can submit a separate LOCK 795 request to the URI in the DAV:location element returned for the 796 redirect reference resource, and can resubmit the LOCK request with 797 the Apply-To-Redirect-Ref header to the collection. At that point 798 both the reference resource and its target resource will be locked 799 (as well as the collection and all the resources identified by its 800 other members). 802 9. Operations on Targets of Redirect Reference Resources 804 Operations on targets of redirect reference resources have no effect 805 on the reference resource. 807 10. Relative references in DAV:reftarget 809 The URI in the href in a DAV:reftarget property MAY be a relative 810 reference. In this case, the base URI to be used for resolving it to 811 absolute form is the URI used in the HTTP message to identify the 812 redirect reference resource to which the DAV:reftarget property 813 belongs. 815 When DAV:reftarget appears in the context of a Multi-Status response, 816 it is in a DAV:response element that contains a single DAV:href 817 element. The value of this DAV:href element serves as the base URI 818 for resolving a relative reference in DAV:reftarget. The value of 819 DAV:href may itself be relative, in which case it must be resolved 820 first in order to serve as the base URI for the relative reference in 821 DAV:reftarget. If the DAV:href element is relative, its base URI is 822 constructed from the scheme component "http", the value of the Host 823 header in the request, and the Request-URI. 825 10.1 Example: Resolving a Relative Reference in a Multi-Status Response 827 >> Request: 829 PROPFIND /geog/ HTTP/1.1 830 Host: example.com 831 Apply-To-Redirect-Ref: T 832 Depth: 1 833 Content-Type: text/xml 834 Content-Length: nnn 836 837 838 839 840 841 842 843 >> Response: 845 HTTP/1.1 207 Multi-Status 846 Content-Type: text/xml 847 Content-Length: nnn 849 850 851 852 /geog/ 853 854 855 856 857 HTTP/1.1 200 OK 858 859 860 861 HTTP/1.1 404 Not Found 862 863 864 865 /geog/stats.html 866 867 868 869 870 statistics/population/1997.html 871 872 873 HTTP/1.1 200 OK 874 875 876 878 In this example, the relative reference "statistics/population/ 879 1997.html" is returned as the value of the DAV:reftarget property for 880 the reference resource identified by href /geog/stats.html. The href 881 is itself a relative reference, which resolves to 882 http://example.com/geog/stats.html. This is the base URI for 883 resolving the relative reference in reftarget. The absolute URI of 884 reftarget is http://example.com/geog/statistics/population/1997.html. 886 11. Redirect References to Collections 888 In a Request-URI /segment1/segment2/segment3, any of the three 889 segments may identify a redirect reference resource. (See [RFC3986], 890 Section 3.3, for definitions of "path" and "segment".) If any 891 segment in a Request-URI identifies a redirect reference resource, 892 the response SHOULD be a 3xx. The value of the Location header in 893 the response is as follows: 895 The leftmost path segment of the Request-URI that identifies a 896 redirect reference resource, together with all path segments and 897 separators to the left of it, is replaced by the value of the 898 redirect reference resource's DAV:reftarget property (resolved to an 899 absolute URI). The remainder of the Request-URI is concatenated to 900 this path. 902 Note: If the DAV:reftarget property ends with a "/" and the remainder 903 of the Request-URI is non-empty (and therefore must begin with a 904 "/"), the final "/" in the DAV:reftarget property is dropped before 905 the remainder of the Request-URI is appended. 907 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 908 reference resource whose target resource is collection /a/, which 909 contains redirect reference resource y whose target resource is 910 collection /b/, which contains redirect reference resource z.html 911 whose target resource is /c/d.html. 913 /x/y/z.html 914 | 915 | /x -> /a 916 | 917 v 918 /a/y/z.html 919 | 920 | /a/y -> /b 921 | 922 v 923 /b/z.html 924 | 925 | /b/z.html -> /c/d.html 926 | 927 v 928 /c/d.html 930 In this case the client must follow up three separate 3xx responses 931 before finally reaching the target resource. The server responds to 932 the initial request with a 3xx with Location: /a/y/z.html, and the 933 client resubmits the request to /a/y/z.html. The server responds to 934 this request with a 3xx with Location: /b/z.html, and the client 935 resubmits the request to /b/z.html. The server responds to this 936 request with a 3xx with Location: /c/d.html, and the client resubmits 937 the request to /c/d.html. This final request succeeds. 939 Note: the behavior described above may have a very serious impact 940 on the efficiency of mapping Request-URIs to resources in HTTP 941 request processing. Therefore servers MAY respond with a 404 942 status code if the cost of checking all leading path segments for 943 redirect references seems prohibitive. 945 12. Headers 947 12.1 Redirect-Ref Response Header 949 Redirect-Ref = "Redirect-Ref:" (URI | relative-ref) 950 ; URI: see [RFC3986], Section 3 951 ; relative-ref: see [RFC3986], Section 4.2 953 The Redirect-Ref header is used in all 3xx responses from redirect 954 reference resources. The value is the link target as specified 955 during redirect reference resource creation. 957 12.2 Apply-To-Redirect-Ref Request Header 959 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") 961 The optional Apply-To-Redirect-Ref header can be used on any request 962 to a redirect reference resource. When it is present and set to "T", 963 the request MUST be applied to the reference resource itself, and a 964 3xx response MUST NOT be returned. 966 If the Apply-To-Redirect-Ref header is used on a request to any other 967 sort of resource besides a redirect reference resource, the server 968 MUST ignore it. 970 13. Redirect Reference Resource Properties 972 The properties defined below are REQUIRED on redirect reference 973 resources. A PROPFIND/allprop request SHOULD NOT return any of the 974 properties defined in this document. 976 13.1 DAV:redirect-lifetime (protected) 978 This property provides information about the lifetime of a redirect. 979 It can either be DAV:permanent (HTTP status 301) or DAV:temporary 980 (HTTP status 302). Future protocols may define additional values. 982 983 984 986 13.2 DAV:reftarget (protected) 988 This property provides an efficient way for clients to discover the 989 URI of the target resource. This is a read-only property after its 990 initial creation. Its value can only be set in a MKREDIRECTREF 991 request. The value is a DAV:href element containing the URI of the 992 target resource. 994 996 14. XML Elements 998 14.1 redirectref XML Element 1000 Name: redirectref 1002 Namespace: DAV: 1004 Purpose: Used as the value of the DAV:resourcetype property to 1005 specify that the resource type is a redirect reference resource. 1007 1009 15. Extensions to the DAV:response XML Element for Multi-Status 1010 Responses 1012 As described in Section 8, the DAV:location element may be returned 1013 in the DAV:response element of a 207 Multi-Status response, to allow 1014 clients to resubmit their requests to the target resource of a 1015 redirect reference resource. 1017 Consequently, the definition of the DAV:response XML element changes 1018 to the following: 1020 1022 1024 16. Capability Discovery 1026 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 1027 classes with the DAV header in responses to OPTIONS, to indicate 1028 which parts of the WebDAV Distributed Authoring protocols the 1029 resource supports. This specification defines an OPTIONAL extension 1030 to [RFC2518]. It defines a new compliance class, called 1031 redirectrefs, for use with the DAV header in responses to OPTIONS 1032 requests. If a resource does support redirect references, its 1033 response to an OPTIONS request may indicate that it does, by listing 1034 the new redirectrefs compliance class in the DAV header and by 1035 listing the MKREDIRECTREF method as one it supports. 1037 When responding to an OPTIONS request, any type of resource can 1038 include redirectrefs in the value of the DAV header. Doing so 1039 indicates that the server permits a redirect reference resource at 1040 the Request-URI. 1042 16.1 Example: Discovery of Support for Redirect Reference Resources 1044 >> Request: 1046 OPTIONS /somecollection/someresource HTTP/1.1 1047 Host: example.org 1049 >> Response: 1051 HTTP/1.1 200 OK 1052 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 1053 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF 1054 DAV: 1, 2, redirectrefs 1056 The DAV header in the response indicates that the resource 1057 /somecollection/someresource is level 1 and level 2 compliant, as 1058 defined in [RFC2518]. In addition, /somecollection/someresource 1059 supports redirect reference resources. The Allow header indicates 1060 that MKREDIRECTREF requests can be submitted to /somecollection/ 1061 someresource. 1063 17. Security Considerations 1065 This section is provided to make applications that implement this 1066 protocol aware of the security implications of this protocol. 1068 All of the security considerations of HTTP/1.1 and the WebDAV 1069 Distributed Authoring Protocol specification also apply to this 1070 protocol specification. In addition, redirect reference resources 1071 introduce several new security concerns and increase the risk of some 1072 existing threats. These issues are detailed below. 1074 17.1 Privacy Concerns 1076 By creating redirect reference resources on a trusted server, it is 1077 possible for a hostile agent to induce users to send private 1078 information to a target on an unrelated system. This risk is 1079 mitigated somewhat, since clients are required to notify the user of 1080 the redirection for any request other than GET or HEAD. (See 1081 [RFC2616], Section 10.3.3 302 Found.) 1083 17.2 Redirect Loops 1085 Although redirect loops were already possible in HTTP 1.1, the 1086 introduction of the MKREDIRECTREF method creates a new avenue for 1087 clients to create loops accidentally or maliciously. If the 1088 reference resource and its target are on the same server, the server 1089 may be able to detect MKREDIRECTREF requests that would create loops. 1090 See also [RFC2616], Section 10.3 "Redirection 3xx." 1092 17.3 Redirect Reference Resources and Denial of Service 1094 Denial of service attacks were already possible by posting URLs that 1095 were intended for limited use at heavily used Web sites. The 1096 introduction of MKREDIRECTREF creates a new avenue for similar denial 1097 of service attacks. Clients can now create redirect reference 1098 resources at heavily used sites to target locations that were not 1099 designed for heavy usage. 1101 17.4 Revealing Private Locations 1103 There are several ways that redirect reference resources may reveal 1104 information about collection structures. First, the DAV:reftarget 1105 property of every redirect reference resource contains the URI of the 1106 target resource. Anyone who has access to the reference resource can 1107 discover the collection path that leads to the target resource. The 1108 owner of the target resource may have wanted to limit knowledge of 1109 this collection structure. 1111 Sufficiently powerful access control mechanisms can control this risk 1112 to some extent. Property-level access control could prevent users 1113 from examining the DAV:reftarget property. (The Location header 1114 returned in responses to requests on redirect reference resources 1115 reveals the same information, however.) 1117 This risk is no greater than the similar risk posed by HTML links. 1119 18. Internationalization Considerations 1121 All internationalization considerations mentioned in [RFC2518] also 1122 apply to this document. 1124 19. IANA Considerations 1126 All IANA considerations mentioned in [RFC2518] also apply to this 1127 document. 1129 20. Contributors 1131 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 1132 who can take credit for big parts of the original design of this 1133 specification. 1135 21. Acknowledgements 1137 This document has benefited from thoughtful discussion by Jim Amsden, 1138 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1139 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1140 Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred 1141 Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj 1142 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry 1143 Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen 1144 Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1145 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1147 22. Normative References 1149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1150 Requirement Levels", BCP 14, RFC 2119, March 1997. 1152 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1153 Jensen, "HTTP Extensions for Distributed Authoring -- 1154 WEBDAV", RFC 2518, February 1999. 1156 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1157 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1158 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1160 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1161 Whitehead, "Versioning Extensions to WebDAV (Web 1162 Distributed Authoring and Versioning)", RFC 3253, 1163 March 2002. 1165 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1166 Resource Identifier (URI): Generic Syntax", STD 66, 1167 RFC 3986, January 2005. 1169 Authors' Addresses 1171 Jim Whitehead 1172 UC Santa Cruz, Dept. of Computer Science 1173 1156 High Street 1174 Santa Cruz, CA 95064 1175 US 1177 Email: ejw@cse.ucsc.edu 1179 Geoff Clemm 1180 IBM 1181 20 Maguire Road 1182 Lexington, MA 02421 1183 US 1185 Email: geoffrey.clemm@us.ibm.com 1187 Julian F. Reschke (editor) 1188 greenbytes GmbH 1189 Salzmannstrasse 152 1190 Muenster, NW 48159 1191 Germany 1193 Phone: +49 251 2807760 1194 Fax: +49 251 2807761 1195 Email: julian.reschke@greenbytes.de 1196 URI: http://greenbytes.de/tech/webdav/ 1198 Appendix A. Change Log (to be removed by RFC Editor before publication) 1200 A.1 Since draft-ietf-webdav-redirectref-protocol-02 1202 Julian Reschke takes editorial role (added to authors list). Cleanup 1203 XML indentation. Start adding all unresolved last call issues. 1204 Update some author's contact information. Update references, split 1205 into "normative" and "informational". Remove non-RFC2616 headers 1206 ("Public") from examples. Fixed width problems in artwork. Start 1207 resolving editorial issues. 1209 A.2 Since draft-ietf-webdav-redirectref-protocol-03 1211 Added Joe Orton and Juergen Reuter to Acknowledgements section. 1212 Close more editorial issues. Remove dependencies on BIND spec. 1214 A.3 Since draft-ietf-webdav-redirectref-protocol-04 1216 More editorial fixes. Clarify that MKRESOURCE can only be used to 1217 create redirect references (switch to new method in a future draft). 1218 Clarify that redirect references do not have bodies. 1220 A.4 Since draft-ietf-webdav-redirectref-protocol-05 1222 Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606- 1223 compliance". Close issues "lc-50-blindredirect", "lc-71-relative", 1224 "lc-74-terminology". Update contact info for Geoff Clemm. Moved 1225 some of the original authors names to new Contributors section. Add 1226 and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72- 1227 trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301" 1228 with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE- 1229 vs-relative-URI was a duplicate of this one). Also remove section 1230 9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue 1231 "11.2-apply-to-redirect-ref-syntax" (header now has values "T" and 1232 "F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add 1233 and resolve "15.1-options-response". 1235 A.5 Since draft-ietf-webdav-redirectref-protocol-06 1237 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc- 1238 44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n" 1239 and "rfc2606-compliance". Start work on index. Add new issue 1240 "old_clients". 1242 A.6 Since draft-ietf-webdav-redirectref-protocol-07 1244 Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in 1245 appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav". 1246 Add issue "5_mkresource" and start work on MKREDIRECTREF (issue 1247 closed, but more work on MKREDIRECTREF needs to be done for updates 1248 and status codes other than 302). Start resolution of "lc-85-301", 1249 replacing "302" by more generic language. Update issue "lc-57- 1250 noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57- 1251 autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S. 1252 Eissing to Acknowledgments section. 1254 A.7 Since draft-ietf-webdav-redirectref-protocol-08 1256 Fix index entries for conditions. Open and resolve issue 1257 "specify_safeness". Rewrite editorial section and parts of intro. 1258 Add more clarifications for issue "lc-85-301" and close it. 1260 A.8 Since draft-ietf-webdav-redirectref-protocol-09 1262 Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57- 1263 noautoupdate". Close issues "lc-48-s6", "12.1-property-name", 1264 "3-terminology-redirectref" and "lc-58-update". Rearrange section 5 1265 and 6. Add some more terms to index (no change tracking). 1267 A.9 Since draft-ietf-webdav-redirectref-protocol-10 1269 Add and resolve issues "13_allprop" and "rfc2396bis". Use the term 1270 "Request-URI" throughout (this is what RFC2616 defines). Center some 1271 of the artwork. Add and resolve issue "abnf". 1273 A.10 Since draft-ietf-webdav-redirectref-protocol-11 1275 Re-open and close issue "anbf" (implied LWS). Raise and close issue 1276 "frag_in_target". Add precondition name for legal reftarget element 1277 contents. Enhance index. Add and close issue "dtd-changes". 1279 Appendix B. Open issues (to be removed by RFC Editor prior to 1280 publication) 1282 B.1 edit 1284 Type: edit 1286 julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for 1287 editorial changes. 1289 Index 1291 A 1292 Apply-To-Redirect-Ref header 22 1294 C 1295 Condition Names 1296 DAV:legal-reftarget (pre) 10-11 1297 DAV:locked-update-allowed (pre) 9, 11 1298 DAV:must-be-redirectref (pre) 11 1299 DAV:name-allowed (pre) 9 1300 DAV:new-redirectref (post) 10 1301 DAV:parent-resource-must-be-non-null (pre) 9 1302 DAV:redirect-lifetime-supported (pre) 10-11 1303 DAV:redirect-lifetime-update-supported (pre) 11 1304 DAV:redirectref-updated (post) 12 1305 DAV:resource-must-be-null (pre) 9 1307 D 1308 DAV header 1309 compliance class 'redirectrefs' 23 1310 DAV:legal-reftarget precondition 10-11 1311 DAV:locked-update-allowed precondition 9, 11 1312 DAV:mkdirectref XML element 9 1313 DAV:mkredirectref-response XML element 9 1314 DAV:must-be-redirectref precondition 11 1315 DAV:name-allowed precondition 9 1316 DAV:new-redirectref postcondition 10 1317 DAV:parent-resource-must-be-non-null precondition 9 1318 DAV:permanent XML element 9, 22 1319 DAV:redirect-lifetime property 22 1320 DAV:redirect-lifetime XML element 9, 22 1321 DAV:redirect-lifetime-supported precondition 10-11 1322 DAV:redirect-lifetime-update-supported precondition 11 1323 DAV:redirectref resource type 23 1324 DAV:redirectref-updated postcondition 12 1325 DAV:reftarget property 23 1326 DAV:reftarget XML element 9 1327 DAV:resource-must-be-null precondition 9 1328 DAV:temporary XML element 9, 22 1329 DAV:updateredirectref-response XML element 11 1331 H 1332 Headers 1333 Apply-To-Redirect-Ref 22 1334 Redirect-Ref 22 1336 M 1337 Methods 1338 MKREDIRECTREF 8 1339 UPDATEREDIRECTREF 10 1340 MKREDIRECTREF method 8 1342 N 1343 Non-Reference Resource 6 1345 P 1346 Properties 1347 DAV:redirect-lifetime 22 1348 DAV:reftarget 23 1350 R 1351 Redirect Reference Resource 6 1352 Redirect-Ref header 22 1353 Resource Types 1354 DAV:redirectref 23 1356 T 1357 Target Resource 7 1359 U 1360 UPDATEREDIRECTREF method 10 1362 X 1363 XML elements 1364 DAV:mkdirectref 9 1365 DAV:mkredirectref-response 9 1366 DAV:permanent 9, 22 1367 DAV:redirect-lifetime 9, 22 1368 DAV:reftarget 9 1369 DAV:temporary 9, 22 1370 DAV:updateredirectref-response 11 1372 Intellectual Property Statement 1374 The IETF takes no position regarding the validity or scope of any 1375 Intellectual Property Rights or other rights that might be claimed to 1376 pertain to the implementation or use of the technology described in 1377 this document or the extent to which any license under such rights 1378 might or might not be available; nor does it represent that it has 1379 made any independent effort to identify any such rights. Information 1380 on the procedures with respect to rights in RFC documents can be 1381 found in BCP 78 and BCP 79. 1383 Copies of IPR disclosures made to the IETF Secretariat and any 1384 assurances of licenses to be made available, or the result of an 1385 attempt made to obtain a general license or permission for the use of 1386 such proprietary rights by implementers or users of this 1387 specification can be obtained from the IETF on-line IPR repository at 1388 http://www.ietf.org/ipr. 1390 The IETF invites any interested party to bring to its attention any 1391 copyrights, patents or patent applications, or other proprietary 1392 rights that may cover technology that may be required to implement 1393 this standard. Please address the information to the IETF at 1394 ietf-ipr@ietf.org. 1396 Disclaimer of Validity 1398 This document and the information contained herein are provided on an 1399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1401 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1402 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1403 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1406 Copyright Statement 1408 Copyright (C) The Internet Society (2005). This document is subject 1409 to the rights, licenses and restrictions contained in BCP 78, and 1410 except as set forth therein, the authors retain all their rights. 1412 Acknowledgment 1414 Funding for the RFC Editor function is currently provided by the 1415 Internet Society.