idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-13.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 1378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1368. ** 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 801 has weird spacing: '... the respon...' == Line 862 has weird spacing: '... is the link ...' == Line 921 has weird spacing: '...ment of a 207...' == Line 922 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 (October 12, 2005) is 6768 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: April 15, 2006 G. Clemm 5 IBM 6 J. Reschke, Ed. 7 greenbytes 8 October 12, 2005 10 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference 11 Resources 12 draft-ietf-webdav-redirectref-protocol-13 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 April 15, 2006. 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 Example: PROPFIND on a Collection with Redirect 85 Reference Resources . . . . . . . . . . . . . . . . . . . 13 86 8.2 Example: PROPFIND with Apply-To-Redirect-Ref on a 87 Collection with Redirect Reference Resources . . . . . . . 16 88 9. Operations on Targets of Redirect Reference Resources . . . 17 89 10. Relative references in DAV:reftarget . . . . . . . . . . . . 17 90 10.1 Example: Resolving a Relative Reference in a 91 Multi-Status Response . . . . . . . . . . . . . . . . . 18 92 11. Redirect References to Collections . . . . . . . . . . . . . 19 93 12. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 12.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 21 95 12.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 21 96 13. Redirect Reference Resource Properties . . . . . . . . . . . 21 97 13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 21 98 13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 22 99 14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 22 100 14.1 redirectref XML Element . . . . . . . . . . . . . . . . 22 101 15. Extensions to the DAV:response XML Element for 102 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 22 103 16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 22 104 16.1 Example: Discovery of Support for Redirect Reference 105 Resources . . . . . . . . . . . . . . . . . . . . . . . 23 106 17. Security Considerations . . . . . . . . . . . . . . . . . . 23 107 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 23 108 17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 24 109 17.3 Redirect Reference Resources and Denial of Service . . . 24 110 17.4 Revealing Private Locations . . . . . . . . . . . . . . 24 111 18. Internationalization Considerations . . . . . . . . . . . . 24 112 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 113 19.1 HTTP headers . . . . . . . . . . . . . . . . . . . . . . 25 114 19.1.1 Redirect-Ref . . . . . . . . . . . . . . . . . . . . 25 115 19.1.2 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . 25 116 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 117 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 118 22. Normative References . . . . . . . . . . . . . . . . . . . . 26 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 120 A. Change Log (to be removed by RFC Editor before 121 publication) . . . . . . . . . . . . . . . . . . . . . . . . 27 122 A.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 27 123 A.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 27 124 A.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 27 125 A.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 27 126 A.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28 127 A.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28 128 A.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 28 129 A.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 28 130 A.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 28 131 A.10 Since draft-ietf-webdav-redirectref-protocol-11 . . . . 28 132 A.11 Since draft-ietf-webdav-redirectref-protocol-12 . . . . 28 133 B. Resolved issues (to be removed by RFC Editor before 134 publication) . . . . . . . . . . . . . . . . . . . . . . . . 29 135 B.1 8.1_deep_lock_complexity . . . . . . . . . . . . . . . . . 29 136 B.2 headerreg . . . . . . . . . . . . . . . . . . . . . . . . 29 137 C. Open issues (to be removed by RFC Editor prior to 138 publication) . . . . . . . . . . . . . . . . . . . . . . . . 29 139 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 140 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 141 Intellectual Property and Copyright Statements . . . . . . . 32 143 1. Introduction 145 This specification extends the Web Distributed Authoring Protocol 146 (WebDAV) to enable clients to create new access paths to existing 147 resources. This capability is useful for several reasons: 149 WebDAV makes it possible to organize HTTP resources into hierarchies, 150 placing them into groupings, known as collections, which are more 151 easily browsed and manipulated than a single flat collection. 152 However, hierarchies require categorization decisions that locate 153 resources at a single location in the hierarchy, a drawback when a 154 resource has multiple valid categories. For example, in a hierarchy 155 of vehicle descriptions containing collections for cars and boats, a 156 description of a combination car/boat vehicle could belong in either 157 collection. Ideally, the description should be accessible from both. 158 Allowing clients to create new URIs that access the existing resource 159 lets them put that resource into multiple collections. 161 Hierarchies also make resource sharing more difficult, since 162 resources that have utility across many collections are still forced 163 into a single collection. For example, the mathematics department at 164 one university might create a collection of information on fractals 165 that contains bindings to some local resources, but also provides 166 access to some resources at other universities. For many reasons, it 167 may be undesirable to make physical copies of the shared resources: 168 to conserve disk space, to respect copyright constraints, or to make 169 any changes in the shared resources visible automatically. Being 170 able to create new access paths to existing resources in other 171 collections or even on other unrelated systems is useful for this 172 sort of case. 174 The redirect reference resources defined here provide a mechanism for 175 creating alternative access paths to existing resources. A redirect 176 reference resource is a resource in one collection whose purpose is 177 to redirect requests to another resource (its target), possibly in a 178 different collection. In this way, it allows clients to submit 179 requests to the target resource from another collection. It 180 redirects most requests to the target resource using a HTTP status 181 code from the 3xx range (Redirection), thereby providing a form of 182 mediated access to the target resource. 184 A redirect reference is a resource with properties but no body of its 185 own. Properties of a redirect reference resource can contain such 186 information as who created the reference, when, and why. Since 187 redirect reference resources are implemented using HTTP 3xx 188 responses, it generally takes two round trips to submit a request to 189 the intended resource. Redirect references work equally well for 190 local resources and for resources that reside on a different system 191 from the reference. 193 The remainder of this document is structured as follows: Section 3 194 defines terms that will be used throughout the specification. 195 Section 4 provides an overview of redirect reference resources. 196 Section 5 defines the semantics of existing methods when applied to 197 redirect reference resources. Section 6 discusses how to create a 198 redirect reference resource, and Section 7 discusses updating 199 redirect references. Section 8 discusses their semantics when 200 applied to collections that contain redirect reference resources. 201 Sections 9 through 11 discuss several other issues raised by the 202 existence of redirect reference resources. Sections 12 through 15 203 define the new headers, properties, and XML elements required to 204 support redirect reference resources. Section 16 discusses 205 capability discovery. Sections 17 through 19 present the security, 206 internationalization, and IANA concerns raised by this specification. 207 The remaining sections provide a variety of supporting information. 209 2. Notational Conventions 211 Since this document describes a set of extensions to the WebDAV 212 Distributed Authoring Protocol [RFC2518], itself an extension to the 213 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 214 elements is exactly the same as described in Section 2.1 of 215 [RFC2616]. Since this augmented BNF uses the basic production rules 216 provided in Section 2.2 of [RFC2616], these rules apply to this 217 document as well. 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 3. Terminology 225 The terminology used here follows and extends that in the WebDAV 226 Distributed Authoring Protocol specification [RFC2518]. Definitions 227 of the terms resource, Uniform Resource Identifier (URI), and Uniform 228 Resource Locator (URL) are provided in [RFC3986]. 230 Redirect Reference Resource 232 A resource created to redirect all requests made to it, using an 233 HTTP status code from the 3xx range, to a defined target resource. 235 Non-Reference Resource 237 A resource that is not a reference to another resource. 239 Target Resource 241 The resource to which requests are redirected by a redirect 242 reference resource. A target resource can be anything that can be 243 identified by an absolute URI (see [RFC3986], "absolute-URI"). 245 This document uses the terms "precondition", "postcondition" and 246 "protected property" as defined in [RFC3253]. Servers MUST report 247 pre-/postcondition failures as described in section 1.6 of this 248 document. 250 4. Overview of Redirect Reference Resources 252 For all operations submitted to a redirect reference resource, the 253 default response is a 302 (Found), accompanied by the Redirect-Ref 254 header (defined in Section 12.1 below) and the Location header 255 ([RFC2616], Section 14.30) set to the URI of the target resource. 256 With this information, the client can resubmit the request to the URI 257 of the target resource. 259 A redirect reference resource never automatically forwards requests 260 to its target resource. Redirect resources bring the same benefits 261 as links in HTML documents. They can be created and maintained 262 without the involvement or even knowledge of their target resource. 263 This reduces the cost of linking between resources. 265 If the client is aware that it is operating on a redirect reference 266 resource, it can resolve the reference by retrieving the reference 267 resource's DAV:reftarget property (defined in Section 13.2 below), 268 whose value contains the URI of the target resource. It can then 269 submit requests to the target resource. 271 A redirect reference resource is a new type of resource. To 272 distinguish redirect reference resources from non-reference 273 resources, a new value of the DAV:resourcetype property (defined in 274 [RFC2518]), DAV:redirectref, is defined in Section 14.1 below. 276 Since a redirect reference resource is a resource, methods can be 277 applied to the reference resource as well as to its target resource. 278 The Apply-To-Redirect-Ref request header (defined in Section 12.2 279 below) is provided so that referencing-aware clients can control 280 whether an operation is applied to the redirect reference resource or 281 standard HTTP/WebDAV behaviour (redirection with a 3xx status code) 282 should occur. The Apply-To-Redirect-Ref header can be used with most 283 requests to redirect reference resources. This header is 284 particularly useful with PROPFIND, to retrieve the reference 285 resource's own properties. 287 Implementation Note: Operations on the target of a redirect reference 288 usually do not affect the redirect reference itself. However, 289 clients should not rely on this behaviour (for instance, some servers 290 may update redirect references as a result of namespace operations on 291 the reference's target). 293 5. Operations on Redirect Reference Resources 295 Although non-referencing-aware clients cannot create reference 296 resources, they should be able to submit requests through the 297 reference resources created by reference-aware WebDAV clients. They 298 should be able to follow any references to their targets. To make 299 this possible, a server that receives any request made via a redirect 300 reference resource MUST return a 3xx range (Redirection) status code, 301 unless the request includes an Apply-To-Redirect-Ref header 302 specifying "T". The client and server MUST follow [RFC2616] Section 303 10.3, but with these additional rules: 305 o The Location response header MUST contain an URI (see [RFC3986], 306 Section 3) that identifies the target of the reference resource. 308 o The response MUST include the Redirect-Ref header. This header 309 allows reference-aware WebDAV clients to recognize the resource as 310 a reference resource and understand the reason for the 311 redirection. 313 A reference-aware WebDAV client can, like a non-referencing client, 314 resubmit the request to the URI in the Location header in order to 315 operate on the target resource. Alternatively, it can resubmit the 316 request to the URI of the redirect reference resource with the 317 "Apply-To-Redirect-Ref: T" header in order to operate on the 318 reference resource itself. In this case, the request MUST be applied 319 to the reference resource itself, and a 3xx response MUST NOT be 320 returned. 322 As redirect references do not have bodies, GET and PUT requests with 323 "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden). 325 6. MKREDIRECTREF Method 327 The MKREDIRECTREF method requests the creation of a redirect 328 reference resource. 330 If a MKREDIRECTREF request fails, the server state preceding the 331 request MUST be restored. 333 Responses from a MKREDIRECTREF request MUST NOT be cached, as 334 MKREDIRECTREF has non-idempotent and non-safe semantics (see 336 [RFC2616], section 9.1). 338 Marshalling: 340 The request body MUST be a DAV:mkredirectref XML element. 342 343 344 345 346 348 The DAV:href element is defined in [RFC2518] (Section 12.3) and 349 MUST contain either an URI or a relative-ref (see [RFC3986], 350 Sections 3 and 4.2). 352 If no DAV:redirect-lifetime element is specified, the server MUST 353 behave as if a value of DAV:temporary was specified. 355 If the request succeeds, the server MUST return 201 (Created) 356 status. 358 If a response body for a successful request is included, it MUST 359 be a DAV:mkredirectref-response XML element. Note that this 360 document does not define any elements for the MKREDIRECTREF 361 response body, but the DAV:mkredirectref-response element is 362 defined to ensure interoperability between future extensions that 363 do define elements for the response body. 365 367 Preconditions: 369 (DAV:resource-must-be-null): A resource MUST NOT exist at the 370 Request-URI. 372 (DAV:parent-resource-must-be-non-null): The Request-URI minus the 373 last past segment MUST identify a collection. 375 (DAV:name-allowed): The last segment of the Request-URI is 376 available for use as a resource name. 378 (DAV:locked-update-allowed): If the collection identified by the 379 Request-URI minus the last path segment is write-locked, then the 380 appropriate token MUST be specified in an If request header. 382 (DAV:redirect-lifetime-supported): If the request body contains a 383 DAV:redirect-lifetime element, the server MUST support the 384 specified lifetime. Support for DAV:temporary is REQUIRED, while 385 support for DAV:permanent is OPTIONAL. 387 (DAV:legal-reftarget): The specified is a legal URI or relative- 388 ref. 390 Postconditions: 392 (DAV:new-redirectref): a new redirect reference resource is 393 created whose DAV:reftarget property has the value specified in 394 the request body. 396 6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF 398 >> Request: 400 MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 401 Host: www.example.com 402 Content-Type: text/xml; charset="utf-8" 403 Content-Length: xxx 405 406 407 408 /i-d/draft-webdav-protocol-08.txt 409 410 412 >> Response: 414 HTTP/1.1 201 Created 416 This request resulted in the creation of a new redirect reference 417 resource at http://www.example.com/~whitehead/dav/spec08.ref, which 418 points to the resource identified by the DAV:reftarget property. In 419 this example, the target resource is identified by the URI 420 http://www.example.com/i-d/draft-webdav-protocol-08.txt. The 421 redirect reference resource's DAV:resourcetype property is set to 422 DAV:redirectref and it's DAV:redirect-lifetime property has the value 423 DAV:temporary. 425 7. UPDATEREDIRECTREF Method 427 The UPDATEREDIRECTREF method requests the update of a redirect 428 reference resource. 430 If a UPDATEREDIRECTREF request fails, the server state preceding the 431 request MUST be restored. 433 Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as 434 UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], section 435 9.1). 437 Marshalling: 439 The request body MUST be a DAV:updateredirectref XML element. 441 442 See Section 6 for a definition of DAV:reftarget and DAV:redirect- 443 lifetime. 445 If no DAV:reftarget element is specified, the server MUST NOT 446 change the target of the redirect reference. 448 If no DAV:redirect-lifetime element is specified, the server MUST 449 NOT change the lifetime of the redirect reference. 451 If a response body for a successful request is included, it MUST 452 be a DAV:updateredirectref-response XML element. Note that this 453 document does not define any elements for the UPDATEREDIRECTREF 454 response body, but the DAV:updateredirectref-response element is 455 defined to ensure interoperability between future extensions that 456 do define elements for the response body. 458 460 Preconditions: 462 (DAV:locked-update-allowed): if the resource is write-locked, then 463 the appropriate token MUST be specified in an If request header. 465 (DAV:must-be-redirectref): the resource identified by the Request- 466 URI must be a redirect reference resource as defined by this 467 specification. 469 (DAV:redirect-lifetime-supported): see Section 6. 471 (DAV:redirect-lifetime-update-supported): servers MAY support 472 changing the DAV:redirect-lifetime property; if they don't, this 473 condition code can be used to signal failure. 475 (DAV:legal-reftarget): see Section 6. 477 Postconditions: 479 (DAV:redirectref-updated): the DAV:reftarget and DAV:redirect- 480 lifetime properties of the redirect reference have been updated 481 accordingly. 483 7.1 Example: Updating a Redirect Reference Resource with 484 UPDATEREDIRECTREF 486 >> Request: 488 UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 489 Host: www.example.com 490 Apply-To-Redirect-Ref: T 491 Content-Type: text/xml; charset="utf-8" 492 Content-Length: xxx 494 495 496 497 /i-d/draft-webdav-protocol-08b.txt 498 499 501 >> Response: 503 HTTP/1.1 200 OK 505 This request has updated the redirect reference's DAV:reftarget 506 property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed 507 the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect- 508 Ref" request header must be used, otherwise the request would result 509 in a redirect (3xx) response status. 511 8. Operations on Collections That Contain Redirect Reference Resources 513 According to [RFC2518], Section 9.2, methods that have defined 514 interactions with the "Depth" request header should apply all other 515 request headers to each resource in scope. However, applying this 516 principle to the "Apply-To-Redirect-Ref" header uniformly would make 517 it impractical to implement this specification on top of existing 518 servers and also would result in unexpected server behaviour for 519 clients that do not take the existence of redirect references into 520 account. On the other hand, the definition of the "Depth" header 521 allows to explicitly define alternate behaviours. 523 For this reason, this specification defines the interaction between 524 "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case 525 basis, and also provides a default for methods not mentioned here 526 that do not specify the behaviour themselves. 528 +-------------+-----------------+------------------+-----------+ 529 | method name | defined in | supported depths | behaviour | 530 +-------------+-----------------+------------------+-----------+ 531 | COPY | [RFC2518], 8.9 | 0, infinity | "T" | 532 | DELETE | [RFC2518], 8.7 | infinity | "T" | 533 | LOCK | [RFC2518], 8.11 | 0, infinity | "T" | 534 | MOVE | [RFC2518], 8.10 | 0, infinity | "T" | 535 | PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit | 536 | REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit | 537 | default | | | "T" | 538 +-------------+-----------------+------------------+-----------+ 540 When the behaviour is defined to be "inherit", the method should 541 follow RFC2518's default behaviour for "Depth" operations, which 542 means applying the value given for "Apply-To-Redirect-Ref" to each 543 resource in scope. On the other hand, when it is defined to be "T", 544 the method should behave as if a "Apply-To-Redirect-Ref: T" header 545 was specified for each operation on child resources. The latter 546 ensures that "Depth: infinity" operations will not fail unexpectedly 547 just because there was a redirect reference resource in scope. 549 8.1 Example: PROPFIND on a Collection with Redirect Reference Resources 551 Suppose a PROPFIND request with Depth: infinity is submitted to the 552 following collection, with the members shown here: 554 /MyCollection/ 555 (non-reference resource) diary.html 556 (redirect reference resource) nunavut 558 >> Request: 560 PROPFIND /MyCollection/ HTTP/1.1 561 Host: example.com 562 Depth: infinity 563 Apply-To-Redirect-Ref: F 564 Content-Type: text/xml 565 Content-Length: xxxx 567 568 569 570 571 572 573 574 >> Response: 576 HTTP/1.1 207 Multi-Status 577 Content-Type: text/xml 578 Content-Length: xxxx 580 581 582 583 /MyCollection/ 584 585 586 587 diary, interests, hobbies 588 589 HTTP/1.1 200 OK 590 591 592 593 /MyCollection/diary.html 594 595 596 597 diary, travel, family, history 598 599 HTTP/1.1 200 OK 600 601 602 603 /MyCollection/nunavut 604 HTTP/1.1 302 Found 605 606 http://example.ca/art/inuit/ 607 608 609 611 In this example the Depth header is set to infinity, and the Apply- 612 To-Redirect-Ref header is set to "F". The collection contains one 613 URI that identifies a redirect reference resource. The response 614 element for the redirect reference resource has a status of 302 615 (Found), and includes a DAV:location extension element to allow 616 clients to retrieve the properties of its target resource. (The 617 response element for the redirect reference resource does not include 618 the requested properties. The client can submit another PROPFIND 619 request to the URI in the DAV:location pseudo-property to retrieve 620 those properties.) 622 8.2 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 623 Redirect Reference Resources 625 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: 626 infinity is submitted to the following collection, with the members 627 shown here: 629 /MyCollection/ 630 (non-reference resource) diary.html 631 (redirect reference resource) nunavut 633 >> Request: 635 PROPFIND /MyCollection/ HTTP/1.1 636 Host: example.com 637 Depth: infinity 638 Apply-To-Redirect-Ref: T 639 Content-Type: text/xml 640 Content-Length: xxxx 642 643 644 645 646 647 648 649 651 >> Response: 653 HTTP/1.1 207 Multi-Status 654 Content-Type: text/xml 655 Content-Length: xxxx 657 658 659 660 /MyCollection/ 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/diary.html 677 678 679 680 681 HTTP/1.1 200 OK 682 683 684 685 686 687 688 HTTP/1.1 404 Not Found 689 690 691 692 /MyCollection/nunavut 693 694 695 696 697 http://example.ca/art/inuit/ 698 699 700 701 HTTP/1.1 200 OK 702 703 704 706 Since the "Apply-To-Redirect-Ref: T" header is present, the response 707 shows the properties of the redirect reference resource in the 708 collection rather than reporting a 302 status. 710 9. Operations on Targets of Redirect Reference Resources 712 Operations on targets of redirect reference resources have no effect 713 on the reference resource. 715 10. Relative references in DAV:reftarget 717 The URI in the href in a DAV:reftarget property MAY be a relative 718 reference. In this case, the base URI to be used for resolving it to 719 absolute form is the URI used in the HTTP message to identify the 720 redirect reference resource to which the DAV:reftarget property 721 belongs. 723 When DAV:reftarget appears in the context of a Multi-Status response, 724 it is in a DAV:response element that contains a single DAV:href 725 element. The value of this DAV:href element serves as the base URI 726 for resolving a relative reference in DAV:reftarget. The value of 727 DAV:href may itself be relative, in which case it must be resolved 728 first in order to serve as the base URI for the relative reference in 729 DAV:reftarget. If the DAV:href element is relative, its base URI is 730 constructed from the scheme component "http", the value of the Host 731 header in the request, and the Request-URI. 733 10.1 Example: Resolving a Relative Reference in a Multi-Status Response 735 >> Request: 737 PROPFIND /geog/ HTTP/1.1 738 Host: example.com 739 Apply-To-Redirect-Ref: T 740 Depth: 1 741 Content-Type: text/xml 742 Content-Length: nnn 744 745 746 747 748 749 750 751 >> Response: 753 HTTP/1.1 207 Multi-Status 754 Content-Type: text/xml 755 Content-Length: nnn 757 758 759 760 /geog/ 761 762 763 764 765 HTTP/1.1 200 OK 766 767 768 769 HTTP/1.1 404 Not Found 770 771 772 773 /geog/stats.html 774 775 776 777 778 statistics/population/1997.html 779 780 781 HTTP/1.1 200 OK 782 783 784 786 In this example, the relative reference "statistics/population/ 787 1997.html" is returned as the value of the DAV:reftarget property for 788 the reference resource identified by href /geog/stats.html. The href 789 is itself a relative reference, which resolves to 790 http://example.com/geog/stats.html. This is the base URI for 791 resolving the relative reference in reftarget. The absolute URI of 792 reftarget is http://example.com/geog/statistics/population/1997.html. 794 11. Redirect References to Collections 796 In a Request-URI /segment1/segment2/segment3, any of the three 797 segments may identify a redirect reference resource. (See [RFC3986], 798 Section 3.3, for definitions of "path" and "segment".) If any 799 segment in a Request-URI identifies a redirect reference resource, 800 the response SHOULD be a 3xx. The value of the Location header in 801 the response is as follows: 803 The leftmost path segment of the Request-URI that identifies a 804 redirect reference resource, together with all path segments and 805 separators to the left of it, is replaced by the value of the 806 redirect reference resource's DAV:reftarget property (resolved to an 807 absolute URI). The remainder of the Request-URI is concatenated to 808 this path. 810 Note: If the DAV:reftarget property ends with a "/" and the remainder 811 of the Request-URI is non-empty (and therefore must begin with a 812 "/"), the final "/" in the DAV:reftarget property is dropped before 813 the remainder of the Request-URI is appended. 815 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 816 reference resource whose target resource is collection /a/, which 817 contains redirect reference resource y whose target resource is 818 collection /b/, which contains redirect reference resource z.html 819 whose target resource is /c/d.html. 821 /x/y/z.html 822 | 823 | /x -> /a 824 | 825 v 826 /a/y/z.html 827 | 828 | /a/y -> /b 829 | 830 v 831 /b/z.html 832 | 833 | /b/z.html -> /c/d.html 834 | 835 v 836 /c/d.html 838 In this case the client must follow up three separate 3xx responses 839 before finally reaching the target resource. The server responds to 840 the initial request with a 3xx with Location: /a/y/z.html, and the 841 client resubmits the request to /a/y/z.html. The server responds to 842 this request with a 3xx with Location: /b/z.html, and the client 843 resubmits the request to /b/z.html. The server responds to this 844 request with a 3xx with Location: /c/d.html, and the client resubmits 845 the request to /c/d.html. This final request succeeds. 847 Note: the behavior described above may have a very serious impact 848 on the efficiency of mapping Request-URIs to resources in HTTP 849 request processing. Therefore servers MAY respond with a 404 850 status code if the cost of checking all leading path segments for 851 redirect references seems prohibitive. 853 12. Headers 855 12.1 Redirect-Ref Response Header 857 Redirect-Ref = "Redirect-Ref:" (URI | relative-ref) 858 ; URI: see [RFC3986], Section 3 859 ; relative-ref: see [RFC3986], Section 4.2 861 The Redirect-Ref header is used in all 3xx responses from redirect 862 reference resources. The value is the link target as specified 863 during redirect reference resource creation. 865 12.2 Apply-To-Redirect-Ref Request Header 867 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") 869 The optional Apply-To-Redirect-Ref header can be used on any request 870 to a redirect reference resource. When it is present and set to "T", 871 the request MUST be applied to the reference resource itself, and a 872 3xx response MUST NOT be returned. 874 If the Apply-To-Redirect-Ref header is used on a request to any other 875 sort of resource besides a redirect reference resource, the server 876 MUST ignore it. 878 13. Redirect Reference Resource Properties 880 The properties defined below are REQUIRED on redirect reference 881 resources. A PROPFIND/allprop request SHOULD NOT return any of the 882 properties defined in this document. 884 13.1 DAV:redirect-lifetime (protected) 886 This property provides information about the lifetime of a redirect. 887 It can either be DAV:permanent (HTTP status 301) or DAV:temporary 888 (HTTP status 302). Future protocols may define additional values. 890 891 892 894 13.2 DAV:reftarget (protected) 896 This property provides an efficient way for clients to discover the 897 URI of the target resource. This is a read-only property after its 898 initial creation. Its value can only be set in a MKREDIRECTREF 899 request. The value is a DAV:href element containing the URI of the 900 target resource. 902 904 14. XML Elements 906 14.1 redirectref XML Element 908 Name: redirectref 910 Namespace: DAV: 912 Purpose: Used as the value of the DAV:resourcetype property to 913 specify that the resource type is a redirect reference resource. 915 917 15. Extensions to the DAV:response XML Element for Multi-Status 918 Responses 920 As described in Section 8, the DAV:location element may be returned 921 in the DAV:response element of a 207 Multi-Status response, to allow 922 clients to resubmit their requests to the target resource of a 923 redirect reference resource. 925 Consequently, the definition of the DAV:response XML element changes 926 to the following: 928 930 932 16. Capability Discovery 934 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 935 classes with the DAV header in responses to OPTIONS, to indicate 936 which parts of the WebDAV Distributed Authoring protocols the 937 resource supports. This specification defines an OPTIONAL extension 938 to [RFC2518]. It defines a new compliance class, called 939 redirectrefs, for use with the DAV header in responses to OPTIONS 940 requests. If a resource does support redirect references, its 941 response to an OPTIONS request may indicate that it does, by listing 942 the new redirectrefs compliance class in the DAV header and by 943 listing the MKREDIRECTREF method as one it supports. 945 When responding to an OPTIONS request, any type of resource can 946 include redirectrefs in the value of the DAV header. Doing so 947 indicates that the server permits a redirect reference resource at 948 the Request-URI. 950 16.1 Example: Discovery of Support for Redirect Reference Resources 952 >> Request: 954 OPTIONS /somecollection/someresource HTTP/1.1 955 Host: example.org 957 >> Response: 959 HTTP/1.1 200 OK 960 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 961 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF 962 DAV: 1, 2, redirectrefs 964 The DAV header in the response indicates that the resource 965 /somecollection/someresource is level 1 and level 2 compliant, as 966 defined in [RFC2518]. In addition, /somecollection/someresource 967 supports redirect reference resources. The Allow header indicates 968 that MKREDIRECTREF requests can be submitted to /somecollection/ 969 someresource. 971 17. Security Considerations 973 This section is provided to make applications that implement this 974 protocol aware of the security implications of this protocol. 976 All of the security considerations of HTTP/1.1 and the WebDAV 977 Distributed Authoring Protocol specification also apply to this 978 protocol specification. In addition, redirect reference resources 979 introduce several new security concerns and increase the risk of some 980 existing threats. These issues are detailed below. 982 17.1 Privacy Concerns 984 By creating redirect reference resources on a trusted server, it is 985 possible for a hostile agent to induce users to send private 986 information to a target on an unrelated system. This risk is 987 mitigated somewhat, since clients are required to notify the user of 988 the redirection for any request other than GET or HEAD. (See 989 [RFC2616], Section 10.3.3 302 Found.) 991 17.2 Redirect Loops 993 Although redirect loops were already possible in HTTP 1.1, the 994 introduction of the MKREDIRECTREF method creates a new avenue for 995 clients to create loops accidentally or maliciously. If the 996 reference resource and its target are on the same server, the server 997 may be able to detect MKREDIRECTREF requests that would create loops. 998 See also [RFC2616], Section 10.3 "Redirection 3xx." 1000 17.3 Redirect Reference Resources and Denial of Service 1002 Denial of service attacks were already possible by posting URLs that 1003 were intended for limited use at heavily used Web sites. The 1004 introduction of MKREDIRECTREF creates a new avenue for similar denial 1005 of service attacks. Clients can now create redirect reference 1006 resources at heavily used sites to target locations that were not 1007 designed for heavy usage. 1009 17.4 Revealing Private Locations 1011 There are several ways that redirect reference resources may reveal 1012 information about collection structures. First, the DAV:reftarget 1013 property of every redirect reference resource contains the URI of the 1014 target resource. Anyone who has access to the reference resource can 1015 discover the collection path that leads to the target resource. The 1016 owner of the target resource may have wanted to limit knowledge of 1017 this collection structure. 1019 Sufficiently powerful access control mechanisms can control this risk 1020 to some extent. Property-level access control could prevent users 1021 from examining the DAV:reftarget property. (The Location header 1022 returned in responses to requests on redirect reference resources 1023 reveals the same information, however.) 1025 This risk is no greater than the similar risk posed by HTML links. 1027 18. Internationalization Considerations 1029 All internationalization considerations mentioned in [RFC2518] also 1030 apply to this document. 1032 19. IANA Considerations 1034 All IANA considerations mentioned in [RFC2518] also apply to this 1035 document. 1037 19.1 HTTP headers 1039 This document specifies the two new HTTP headers listed below. 1041 19.1.1 Redirect-Ref 1043 Header field name: Redirect-Ref 1045 Applicable protocol: http 1047 Status: standard 1049 Author/Change controller: IETF 1051 Specification document: this specification (Section 12.1) 1053 19.1.2 Apply-To-Redirect-Ref 1055 Header field name: Apply-To-Redirect-Ref 1057 Applicable protocol: http 1059 Status: standard 1061 Author/Change controller: IETF 1063 Specification document: this specification (Section 12.2) 1065 20. Contributors 1067 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 1068 who can take credit for big parts of the original design of this 1069 specification. 1071 21. Acknowledgements 1073 This document has benefited from thoughtful discussion by Jim Amsden, 1074 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1075 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1076 Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred 1077 Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj 1078 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry 1079 Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen 1080 Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1081 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1083 22. Normative References 1085 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1086 Requirement Levels", BCP 14, RFC 2119, March 1997. 1088 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1089 Jensen, "HTTP Extensions for Distributed Authoring -- 1090 WEBDAV", RFC 2518, February 1999. 1092 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1093 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1094 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1096 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1097 Whitehead, "Versioning Extensions to WebDAV (Web 1098 Distributed Authoring and Versioning)", RFC 3253, 1099 March 2002. 1101 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1102 Resource Identifier (URI): Generic Syntax", STD 66, 1103 RFC 3986, January 2005. 1105 Authors' Addresses 1107 Jim Whitehead 1108 UC Santa Cruz, Dept. of Computer Science 1109 1156 High Street 1110 Santa Cruz, CA 95064 1111 US 1113 Email: ejw@cse.ucsc.edu 1115 Geoff Clemm 1116 IBM 1117 20 Maguire Road 1118 Lexington, MA 02421 1119 US 1121 Email: geoffrey.clemm@us.ibm.com 1122 Julian F. Reschke (editor) 1123 greenbytes GmbH 1124 Salzmannstrasse 152 1125 Muenster, NW 48159 1126 Germany 1128 Phone: +49 251 2807760 1129 Fax: +49 251 2807761 1130 Email: julian.reschke@greenbytes.de 1131 URI: http://greenbytes.de/tech/webdav/ 1133 Appendix A. Change Log (to be removed by RFC Editor before publication) 1135 A.1 Since draft-ietf-webdav-redirectref-protocol-02 1137 Julian Reschke takes editorial role (added to authors list). Cleanup 1138 XML indentation. Start adding all unresolved last call issues. 1139 Update some author's contact information. Update references, split 1140 into "normative" and "informational". Remove non-RFC2616 headers 1141 ("Public") from examples. Fixed width problems in artwork. Start 1142 resolving editorial issues. 1144 A.2 Since draft-ietf-webdav-redirectref-protocol-03 1146 Added Joe Orton and Juergen Reuter to Acknowledgements section. 1147 Close more editorial issues. Remove dependencies on BIND spec. 1149 A.3 Since draft-ietf-webdav-redirectref-protocol-04 1151 More editorial fixes. Clarify that MKRESOURCE can only be used to 1152 create redirect references (switch to new method in a future draft). 1153 Clarify that redirect references do not have bodies. 1155 A.4 Since draft-ietf-webdav-redirectref-protocol-05 1157 Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606- 1158 compliance". Close issues "lc-50-blindredirect", "lc-71-relative", 1159 "lc-74-terminology". Update contact info for Geoff Clemm. Moved 1160 some of the original authors names to new Contributors section. Add 1161 and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72- 1162 trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301" 1163 with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE- 1164 vs-relative-URI was a duplicate of this one). Also remove section 1165 9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue 1166 "11.2-apply-to-redirect-ref-syntax" (header now has values "T" and 1167 "F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add 1168 and resolve "15.1-options-response". 1170 A.5 Since draft-ietf-webdav-redirectref-protocol-06 1172 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc- 1173 44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n" 1174 and "rfc2606-compliance". Start work on index. Add new issue 1175 "old_clients". 1177 A.6 Since draft-ietf-webdav-redirectref-protocol-07 1179 Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in 1180 appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav". 1181 Add issue "5_mkresource" and start work on MKREDIRECTREF (issue 1182 closed, but more work on MKREDIRECTREF needs to be done for updates 1183 and status codes other than 302). Start resolution of "lc-85-301", 1184 replacing "302" by more generic language. Update issue "lc-57- 1185 noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57- 1186 autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S. 1187 Eissing to Acknowledgments section. 1189 A.7 Since draft-ietf-webdav-redirectref-protocol-08 1191 Fix index entries for conditions. Open and resolve issue 1192 "specify_safeness". Rewrite editorial section and parts of intro. 1193 Add more clarifications for issue "lc-85-301" and close it. 1195 A.8 Since draft-ietf-webdav-redirectref-protocol-09 1197 Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57- 1198 noautoupdate". Close issues "lc-48-s6", "12.1-property-name", 1199 "3-terminology-redirectref" and "lc-58-update". Rearrange section 5 1200 and 6. Add some more terms to index (no change tracking). 1202 A.9 Since draft-ietf-webdav-redirectref-protocol-10 1204 Add and resolve issues "13_allprop" and "rfc2396bis". Use the term 1205 "Request-URI" throughout (this is what RFC2616 defines). Center some 1206 of the artwork. Add and resolve issue "abnf". 1208 A.10 Since draft-ietf-webdav-redirectref-protocol-11 1210 Re-open and close issue "anbf" (implied LWS). Raise and close issue 1211 "frag_in_target". Add precondition name for legal reftarget element 1212 contents. Enhance index. Add and close issue "dtd-changes". 1214 A.11 Since draft-ietf-webdav-redirectref-protocol-12 1216 Remove RFC2616 reference from abstract. Add and resolve issue 1217 8.1_deep_lock_complexity. Add and resolve issue headerreg (reg. 1219 template for new HTTP headers in IANA considerations section). 1221 Appendix B. Resolved issues (to be removed by RFC Editor before 1222 publication) 1224 Issues that were either rejected or resolved in this version of this 1225 document. 1227 B.1 8.1_deep_lock_complexity 1229 Type: change 1231 1234 jbaumgarten@apple.com (2005-06-27): ...In particular, the failure of 1235 locking methods that contain redirected resources would confuse our 1236 clients. Instead, we have decided to implement a simpler redirect 1237 capability via a custom property (not a WebDAV resource type) that is 1238 only activated when indicated by the client request. 1240 julian.reschke@greenbytes.de (2005-07-03): Analysis of issue in http: 1241 //lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0005.html. 1243 Resolution (2005-10-01): Make all methods except PROPFIND and REPORT 1244 default to "Apply-To-Redirect-Ref: T". 1246 B.2 headerreg 1248 Type: change 1250 julian.reschke@greenbytes.de (2005-08-24): Add RFC3864 registrations 1251 for new HTTP headers. 1253 Appendix C. Open issues (to be removed by RFC Editor prior to 1254 publication) 1256 C.1 edit 1258 Type: edit 1260 julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for 1261 editorial changes. 1263 Index 1265 A 1266 Apply-To-Redirect-Ref header 21 1268 C 1269 Condition Names 1270 DAV:legal-reftarget (pre) 10-11 1271 DAV:locked-update-allowed (pre) 9, 11 1272 DAV:must-be-redirectref (pre) 11 1273 DAV:name-allowed (pre) 9 1274 DAV:new-redirectref (post) 10 1275 DAV:parent-resource-must-be-non-null (pre) 9 1276 DAV:redirect-lifetime-supported (pre) 10-11 1277 DAV:redirect-lifetime-update-supported (pre) 11 1278 DAV:redirectref-updated (post) 12 1279 DAV:resource-must-be-null (pre) 9 1281 D 1282 DAV header 1283 compliance class 'redirectrefs' 22 1284 DAV:legal-reftarget precondition 10-11 1285 DAV:locked-update-allowed precondition 9, 11 1286 DAV:mkdirectref XML element 9 1287 DAV:mkredirectref-response XML element 9 1288 DAV:must-be-redirectref precondition 11 1289 DAV:name-allowed precondition 9 1290 DAV:new-redirectref postcondition 10 1291 DAV:parent-resource-must-be-non-null precondition 9 1292 DAV:permanent XML element 9, 21 1293 DAV:redirect-lifetime property 21 1294 DAV:redirect-lifetime XML element 9, 21 1295 DAV:redirect-lifetime-supported precondition 10-11 1296 DAV:redirect-lifetime-update-supported precondition 11 1297 DAV:redirectref resource type 22 1298 DAV:redirectref-updated postcondition 12 1299 DAV:reftarget property 22 1300 DAV:reftarget XML element 9 1301 DAV:resource-must-be-null precondition 9 1302 DAV:temporary XML element 9, 21 1303 DAV:updateredirectref-response XML element 11 1305 H 1306 Headers 1307 Apply-To-Redirect-Ref 21 1308 Redirect-Ref 21 1310 M 1311 Methods 1312 MKREDIRECTREF 8 1313 UPDATEREDIRECTREF 10 1314 MKREDIRECTREF method 8 1316 N 1317 Non-Reference Resource 6 1319 P 1320 Properties 1321 DAV:redirect-lifetime 21 1322 DAV:reftarget 22 1324 R 1325 Redirect Reference Resource 6 1326 Redirect-Ref header 21 1327 Resource Types 1328 DAV:redirectref 22 1330 T 1331 Target Resource 7 1333 U 1334 UPDATEREDIRECTREF method 10 1336 X 1337 XML elements 1338 DAV:mkdirectref 9 1339 DAV:mkredirectref-response 9 1340 DAV:permanent 9, 21 1341 DAV:redirect-lifetime 9, 21 1342 DAV:reftarget 9 1343 DAV:temporary 9, 21 1344 DAV:updateredirectref-response 11 1346 Intellectual Property Statement 1348 The IETF takes no position regarding the validity or scope of any 1349 Intellectual Property Rights or other rights that might be claimed to 1350 pertain to the implementation or use of the technology described in 1351 this document or the extent to which any license under such rights 1352 might or might not be available; nor does it represent that it has 1353 made any independent effort to identify any such rights. Information 1354 on the procedures with respect to rights in RFC documents can be 1355 found in BCP 78 and BCP 79. 1357 Copies of IPR disclosures made to the IETF Secretariat and any 1358 assurances of licenses to be made available, or the result of an 1359 attempt made to obtain a general license or permission for the use of 1360 such proprietary rights by implementers or users of this 1361 specification can be obtained from the IETF on-line IPR repository at 1362 http://www.ietf.org/ipr. 1364 The IETF invites any interested party to bring to its attention any 1365 copyrights, patents or patent applications, or other proprietary 1366 rights that may cover technology that may be required to implement 1367 this standard. Please address the information to the IETF at 1368 ietf-ipr@ietf.org. 1370 Disclaimer of Validity 1372 This document and the information contained herein are provided on an 1373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1375 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1376 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1377 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1380 Copyright Statement 1382 Copyright (C) The Internet Society (2005). This document is subject 1383 to the rights, licenses and restrictions contained in BCP 78, and 1384 except as set forth therein, the authors retain all their rights. 1386 Acknowledgment 1388 Funding for the RFC Editor function is currently provided by the 1389 Internet Society.