idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 10, 2003) is 7535 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'WebDAV' is mentioned on line 2405, but not defined ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Possible downref: Non-RFC (?) normative reference: ref. '34' -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '37' -- Possible downref: Non-RFC (?) normative reference: ref. '38' -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' -- Possible downref: Non-RFC (?) normative reference: ref. '41' -- Possible downref: Non-RFC (?) normative reference: ref. '42' -- Possible downref: Non-RFC (?) normative reference: ref. '43' -- Possible downref: Non-RFC (?) normative reference: ref. '44' -- Possible downref: Non-RFC (?) normative reference: ref. '45' -- Possible downref: Non-RFC (?) normative reference: ref. '46' -- Possible downref: Non-RFC (?) normative reference: ref. '47' -- Possible downref: Non-RFC (?) normative reference: ref. '48' -- Possible downref: Non-RFC (?) normative reference: ref. '49' -- Possible downref: Non-RFC (?) normative reference: ref. '50' -- Possible downref: Non-RFC (?) normative reference: ref. '51' -- Possible downref: Non-RFC (?) normative reference: ref. '52' -- Possible downref: Non-RFC (?) normative reference: ref. '53' -- Possible downref: Non-RFC (?) normative reference: ref. '54' -- Possible downref: Non-RFC (?) normative reference: ref. '55' -- Possible downref: Non-RFC (?) normative reference: ref. '56' -- Possible downref: Non-RFC (?) normative reference: ref. '57' -- Possible downref: Non-RFC (?) normative reference: ref. '58' -- Possible downref: Non-RFC (?) normative reference: ref. '59' -- Possible downref: Non-RFC (?) normative reference: ref. '60' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 63 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group J. Slein 3 Internet-Draft Xerox 4 Expires: March 10, 2004 J. Whitehead 5 U.C. Santa Cruz 6 J. Davis 7 CourseNet 8 G. Clemm 9 Rational 10 C. Fay 11 FileNet 12 J. Crawford 13 IBM 14 J. Reschke, Ed. 15 greenbytes 16 September 10, 2003 18 WebDAV Redirect Reference Resources 19 draft-ietf-webdav-redirectref-protocol-04 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at http:// 36 www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on March 10, 2004. 43 Copyright Notice 45 Copyright (C) The Internet Society (2003). All Rights Reserved. 47 Abstract 49 This specification defines redirect reference resources. A redirect 50 reference resource is a resource whose default response is an HTTP/ 51 1.1 302 (Found) status code, redirecting the client to a different 52 resource, the target resource. A redirect reference makes it 53 possible to access the target resource indirectly, through any URI 54 mapped to the redirect reference resource. There are no integrity 55 guarantees associated with redirect reference resources. 57 Distribution of this document is unlimited. Please send comments to 58 the Distributed Authoring and Versioning (WebDAV) working group at 59 w3c-dist-auth@w3.org [1], which may be joined by sending a message 60 with subject "subscribe" to w3c-dist-auth-request@w3.org [2]. 62 Discussions of the WEBDAV working group are archived at URL: http:// 63 lists.w3.org/Archives/Public/w3c-dist-auth/. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Overview of Redirect Reference Resources . . . . . . . . . . 9 71 5. Creating a Redirect Reference Resource . . . . . . . . . . . 10 72 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.2 Example: Creating a Redirect Reference Resource with 74 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Operations on Redirect Reference Resources . . . . . . . . . 13 76 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 14 77 6.2 Example: PUT on a Redirect Reference Resource with 78 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 14 79 6.3 Example: PROPPATCH on a Redirect Reference Resource . . . . 15 80 7. Operations on Collections That Contain Redirect Reference 81 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 7.1 MOVE and DELETE on Collections That Contain Redirect 83 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.2 LOCK on a Collection That Contains Redirect References . . . 17 85 7.3 Example: PROPFIND on a Collection with Redirect Reference 86 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a 88 Collection with Redirect Reference Resources . . . . . . . . 18 89 7.5 Example: COPY on a Collection That Contains a Redirect 90 Reference Resource . . . . . . . . . . . . . . . . . . . . . 20 91 7.6 Example: LOCK on a Collection That Contains a Redirect 92 Reference Resource . . . . . . . . . . . . . . . . . . . . . 21 93 8. Operations on Targets of Redirect Reference Resources . . . 24 94 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 25 95 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 25 96 9.2 Example: Resolving a Relative URI in a Multi-Status 97 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 10. Redirect References to Collections . . . . . . . . . . . . . 28 100 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 30 102 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 30 103 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 31 105 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 31 106 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 32 107 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 32 108 14. Extensions to the DAV:response XML Element for 109 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 33 110 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 34 111 15.1 Example: Discovery of Support for Redirect Reference 112 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 16. Security Considerations . . . . . . . . . . . . . . . . . . 35 114 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 35 115 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 35 116 16.3 Redirect Reference Resources and Denial of Service . . . . . 35 117 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 35 118 17. Internationalization Considerations . . . . . . . . . . . . 37 119 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 120 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 121 Normative References . . . . . . . . . . . . . . . . . . . . 40 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 123 A. Changes to the WebDAV Document Type Definition . . . . . . . 42 124 B. Change Log (to be removed by RFC Editor before 125 publication) . . . . . . . . . . . . . . . . . . . . . . . . 43 126 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43 127 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43 128 C. Resolved issues (to be removed by RFC Editor before 129 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44 130 C.1 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 131 C.2 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 132 C.3 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 133 C.4 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 134 C.5 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45 135 C.6 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45 136 C.7 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 45 137 C.8 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45 138 C.9 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 46 139 C.10 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 46 140 C.11 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 46 141 C.12 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 47 142 C.13 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 47 143 C.14 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 47 144 C.15 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 47 145 C.16 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 48 146 C.17 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 48 147 C.18 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 48 148 D. Open issues (to be removed by RFC Editor before 149 publication) . . . . . . . . . . . . . . . . . . . . . . . . 49 150 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 49 151 D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 49 152 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 49 153 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 49 154 D.5 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 50 155 D.6 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 50 156 D.7 3-terminology-redirectref . . . . . . . . . . . . . . . . . 50 157 D.8 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 50 158 D.9 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 51 159 D.10 lc-04-standard-data-container . . . . . . . . . . . . . . . 51 160 D.11 lc-05-standard-data-container . . . . . . . . . . . . . . . 51 161 D.12 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 51 162 D.13 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 52 163 D.14 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 52 164 D.15 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52 165 D.16 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52 166 D.17 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 53 167 D.18 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 53 168 D.19 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 53 169 D.20 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 54 170 D.21 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 54 171 D.22 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55 172 D.23 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55 173 D.24 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 55 174 D.25 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 55 175 D.26 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 56 176 D.27 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 56 177 D.28 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 56 178 D.29 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 56 179 D.30 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 57 180 D.31 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 57 181 D.32 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 57 182 D.33 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 58 183 D.34 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 58 184 D.35 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 58 185 D.36 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 59 186 D.37 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 59 187 D.38 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 59 188 D.39 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 59 189 D.40 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 60 190 D.41 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 60 191 Intellectual Property and Copyright Statements . . . . . . . 61 193 1. Introduction 195 This is one of a pair of specifications that extend the WebDAV 196 Distributed Authoring Protocol to enable clients to create new access 197 paths to existing resources. This capability is useful for several 198 reasons: 200 URIs of WebDAV-compliant resources are hierarchical and correspond to 201 a hierarchy of collections in resource space. The WebDAV Distributed 202 Authoring Protocol makes it possible to organize these resources into 203 hierarchies, placing them into groupings, known as collections, which 204 are more easily browsed and manipulated than a single flat 205 collection. However, hierarchies require categorization decisions 206 that locate resources at a single location in the hierarchy, a 207 drawback when a resource has multiple valid categories. For example, 208 in a hierarchy of vehicle descriptions containing collections for 209 cars and boats, a description of a combination car/boat vehicle could 210 belong in either collection. Ideally, the description should be 211 accessible from both. Allowing clients to create new URIs that access 212 the existing resource lets them put that resource into multiple 213 collections. 215 Hierarchies also make resource sharing more difficult, since 216 resources that have utility across many collections are still forced 217 into a single collection. For example, the mathematics department at 218 one university might create a collection of information on fractals 219 that contains bindings to some local resources, but also provides 220 access to some resources at other universities. For many reasons, it 221 may be undesirable to make physical copies of the shared resources on 222 the local server: to conserve disk space, to respect copyright 223 constraints, or to make any changes in the shared resources visible 224 automatically. Being able to create new access paths to existing 225 resources in other collections or even on other servers is useful for 226 this sort of case. 228 The redirect reference resources defined here provide a mechanism for 229 creating alternative access paths to existing resources. A redirect 230 reference resource is a resource in one collection whose purpose is 231 to forward requests to another resource (its target), possibly in a 232 different collection. In this way, it allows clients to submit 233 requests to the target resource from another collection. It 234 redirects most requests to the target resource using the HTTP 302 235 (Found) status code, thereby providing a form of mediated access to 236 the target resource. 238 A redirect reference is a resource, and so can have properties and a 239 body of its own. Properties of a redirect reference resource can 240 contain such information as who created the reference, when, and why. 242 Since redirect reference resources are implemented using HTTP 302 243 responses, it generally takes two round trips to submit a request to 244 the intended resource. Servers are not required to enforce the 245 integrity of redirect references. Redirect references work equally 246 well for local resources and for resources that reside on a different 247 server from the reference. 249 The remainder of this document is structured as follows: Section 3 250 defines terms that will be used throughout the specification. 251 Section 4 provides an overview of redirect reference resources. 252 Section 5 discusses how to create a redirect reference resource. 253 Section 6 defines the semantics of existing methods when applied to 254 redirect reference resources, and Section 7 discusses their semantics 255 when applied to collections that contain redirect reference 256 resources. Sections 8 through 10 discuss several other issues raised 257 by the existence of redirect reference resources. Sections 11 258 through 14 define the new headers, properties, and XML elements 259 required to support redirect reference resources. Section 15 260 discusses capability discovery. Sections 16 through 18 present the 261 security, internationalization, and IANA concerns raised by this 262 specification. The remaining sections provide a variety of supporting 263 information. 265 2. Notational Conventions 267 Since this document describes a set of extensions to the WebDAV 268 Distributed Authoring Protocol [RFC2518], itself an extension to the 269 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 270 elements is exactly the same as described in Section 2.1 of 271 [RFC2616]. Since this augmented BNF uses the basic production rules 272 provided in Section 2.2 of [RFC2616], these rules apply to this 273 document as well. 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 277 document are to be interpreted as described in [RFC2119]. 279 3. Terminology 281 The terminology used here follows and extends that in the WebDAV 282 Distributed Authoring Protocol specification [RFC2518]. Definitions 283 of the terms resource, Uniform Resource Identifier (URI), and Uniform 284 Resource Locator (URL) are provided in [RFC2396]. 286 Redirect Reference Resource 288 A resource created to redirect all requests made to it, using 302 289 (Found), to a defined target resource. 291 Non-Reference Resource 293 A resource that is not a reference to another resource. 295 Target Resource 297 The resource to which requests are forwarded by a reference 298 resource. 300 4. Overview of Redirect Reference Resources 302 For all operations submitted to a redirect reference resource, the 303 default response is a 302 (Found), accompanied by the Redirect-Ref 304 header (defined in Section 11.1 below) and the Location header set to 305 the URI of the target resource. With this information, the client 306 can resubmit the request to the URI of the target resource. 308 A redirect reference resource never automatically forwards requests 309 to its target resource. Redirect resources bring the same benefits as 310 links in HTML documents. They can be created and maintained without 311 the involvement or even knowledge of their target resource. This 312 reduces the cost of linking between resources." 314 If the client is aware that it is operating on a redirect reference 315 resource, it can resolve the reference by retrieving the reference 316 resource's DAV:reftarget property (defined in Section 12.1 below), 317 whose value contains the URI of the target resource. It can then 318 submit requests to the target resource. 320 A redirect reference resource is a new type of resource. To 321 distinguish redirect reference resources from non-reference 322 resources, a new value of the DAV:resourcetype property (defined in 323 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below. 325 Since a redirect reference resource is a resource, it can have its 326 own properties and body, and methods can be applied to the reference 327 resource as well as to its target resource. The 328 Apply-To-Redirect-Ref request header (defined in Section 11.2 below) 329 is provided so that referencing-aware clients can control whether an 330 operation is applied to the redirect reference resource or to its 331 target resource. The Apply-To-Redirect-Ref header can be used with 332 most requests to redirect reference resources. This header is 333 particularly useful with PROPFIND, to retrieve the reference 334 resource's own properties. 336 5. Creating a Redirect Reference Resource 338 The MKRESOURCE method is used to create new redirect reference 339 resources. As defined in Section 5.1, MKRESOURCE can be used to 340 create a resource of any type other than standard data containers and 341 collections. In order to create a redirect reference resource using 342 MKRESOURCE, the values of two properties must be set in the body of 343 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to 344 DAV:redirectref, a new value of DAV:resourcetype defined in Section 345 13.1. The value of DAV:reftarget MUST be set to the URI of the target 346 resource. 348 Used in this way, the MKRESOURCE method creates a redirect reference 349 resource whose target is identified by the DAV:reftarget property. 351 5.1 MKRESOURCE 353 The MKRESOURCE method requests the creation of a resource and 354 initialization of its properties. It allows resources other than 355 standard data containers and collections to be created and their 356 properties initialized in one atomic operation. 358 Preconditions: 360 A resource MUST NOT exist at the Request-URI. 362 Request Marshalling: 364 The location of the new resource to be created is specified by the 365 Request-URI. 367 The request body of the MKRESOURCE method MUST consist of the 368 DAV:propertyupdate XML element defined in Section 12.13 of 369 [RFC2518]. 371 Postconditions: 373 If the response status code is 201, a new resource exists at the 374 Request-URI. 376 The body of the new resource is empty. 378 The properties of the new resource are as specified by the 379 DAV:propertyupdate request body, using PROPPATCH semantics. If the 380 DAV:propertyupdate does not specify a DAV:resourcetype, the 381 resource will be a standard data container. 383 If the response status code is not 201, then a new resource is not 384 created at the Request-URI, and any existing resource at the 385 Request-URI is unaffected. 387 Response Marshalling: 389 Responses from a MKRESOURCE request MUST NOT be cached, as 390 MKRESOURCE has non-idempotent semantics. 392 The following status codes can be expected in responses to 393 MKRESOURCE: 395 201 (Created): The new resource was successfully created. 397 207 (Multi-Status): This response is generated if an error was 398 encountered while initializing the properties of the resource, in 399 which case the response is as defined in Section 8.2.1 of 400 [RFC2518]. 402 403 (Forbidden): The server does not allow the creation of the 403 requested resource type at the requested location, or the parent 404 collection of the Request-URI exists but cannot accept members. 406 409 (Conflict): A resource cannot be created at the Request-URI 407 because the parent collection for the resource does not exist, or 408 because there is already a resource at that request-URL. 410 423 (Locked): The Request-URI is locked, and the lock token was 411 not passed with the request. 413 507 (Insufficient Storage): The server does not have sufficient 414 space to record the state of the resource. 416 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE 418 >> Request: 420 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 421 Host: www.ics.uci.edu 422 Content-Type: text/xml; charset="utf-8" 423 Content-Length: xxx 425 426 427 428 429 430 431 /i-d/draft-webdav-protocol-08.txt 432 433 434 435 437 >> Response: 439 HTTP/1.1 201 Created 441 This request resulted in the creation of a new redirect reference 442 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points 443 to the resource identified by the DAV:reftarget property. In this 444 example, the target resource is identified by the URI http:// 445 www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt. The redirect 446 reference resource's DAV:resourcetype property is set to 447 DAV:redirectref. 449 6. Operations on Redirect Reference Resources 451 Although non-referencing-aware clients cannot create reference 452 resources, they should be able to submit requests through the 453 reference resources created by reference-aware WebDAV clients. They 454 should be able to follow any references to their targets. To make 455 this possible, a server that receives any request made via a redirect 456 reference resource MUST return a 302 (Found) status code, unless the 457 request includes an Apply-To-Redirect-Ref header. The client and 458 server MUST follow [RFC2616] Section 10.3.3 "302 Found," but with 459 these additional rules: 461 o The Location response header MUST contain an absolute URI that 462 identifies the target of the reference resource. 464 o The response MUST include the Redirect-Ref header. This header 465 allows reference-aware WebDAV clients to recognize the resource as 466 a reference resource and understand the reason for the 467 redirection. 469 A reference-aware WebDAV client can act on this response in one of 470 two ways. It can, like a non-referencing client, resubmit the 471 request to the URI in the Location header in order to operate on the 472 target resource. Alternatively, it can resubmit the request to the 473 URI of the redirect reference resource with the Apply-To-Redirect-Ref 474 header in order to operate on the reference resource itself. If the 475 Apply-To-Redirect-Ref header is present, the request MUST be applied 476 to the reference resource itself, and a 302 response MUST NOT be 477 returned. 479 A reference-aware client may know before submitting its request that 480 the Request-URI identifies a redirect reference resource. In this 481 case, if the client wants to apply the method to the reference 482 resource, it can save the round trip caused by the 302 response by 483 using an Apply-To-Redirect-Ref header in its initial request to the 484 URI. 486 A few methods need additional explanation: 488 The Apply-To-Redirect-Ref header can be used with GET or HEAD to 489 retrieve the entity headers of a redirect reference resource. When 490 Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref 491 entity header MUST be returned. 493 A redirect reference resource MAY have a body, though none is defined 494 for it in this specification. The PUT method can be used, with 495 Apply-To-Redirect-Ref, to create or replace the body of a redirect 496 reference resource. 498 6.1 Example: GET on a Redirect Reference Resource 500 >> Request: 502 GET /bar.html HTTP/1.1 503 Host: www.foo.com 505 >> Response: 507 HTTP/1.1 302 Found 508 Location: http://www.svr.com/Internet/xxspec08.html 509 Redirect-Ref: 511 Since /bar.html is a redirect reference resource and the 512 Apply-To-Redirect-Ref header is not included in the request, the 513 response is a 302 (Found). The Redirect-Ref header informs a 514 reference-aware client that this is not an ordinary HTTP 1.1 515 redirect, but is a redirect reference resource. The URI of the 516 target resource is provided in the Location header so that the client 517 can resubmit the request to the target resource. 519 6.2 Example: PUT on a Redirect Reference Resource with 520 Apply-To-Redirect-Ref 522 >> Request: 524 PUT /bar.html HTTP/1.1 525 Host: www.foo.com 526 Apply-To-Redirect-Ref: 527 Content-Type: text/xml; charset="utf-8" 528 Content-Length: xxxx 530 . . . some content . . . 532 >> Response: 534 HTTP/1.1 200 OK 536 Although /bar.html is a redirect reference resource, the presence of 537 the Apply-To-Redirect-Ref header prevents a 302 response, and instead 538 causes the request to be applied to the reference resource. The 539 result in this case is that the reference resource is replaced by a 540 non-reference resource having the content submitted with the request. 542 6.3 Example: PROPPATCH on a Redirect Reference Resource 544 >> Request: 546 PROPPATCH /bar.html HTTP/1.1 547 Host: www.foo.com 548 Content-Type: text/xml; charset="utf-8" 549 Content-Length: xxxx 551 552 554 555 556 557 Jim Whitehead 558 Roy Fielding 559 560 561 562 563 564 565 566 567 569 >> Response: 571 HTTP/1.1 302 Found 572 Location: http://www.svr.com/Internet/xxspec08.html 573 Redirect-Ref: 575 Since /bar.html is a redirect reference resource and the 576 Apply-To-Redirect-Ref header is not included in the request, the 577 response is a 302 (Found). The Redirect-Ref header informs a 578 reference-aware client that this is not an ordinary HTTP 1.1 579 redirect, but is a redirect reference resource. The URI of the 580 target resource is provided in the Location header so that the client 581 can resubmit the request to the target resource. 583 7. Operations on Collections That Contain Redirect Reference Resources 585 Consistent with the rules in Section 6, the response for each 586 redirect reference encountered while processing a collection MUST be 587 a 302 (Found) unless a Apply-To-Redirect-Ref header is included with 588 the request. The overall response will therefore be a 207 589 (Multi-Status). Since a Location header and Redirect-Ref header 590 cannot be returned for each redirect reference encountered, the same 591 information is provided using properties in the response elements for 592 those resources. The DAV:location pseudo-property and the 593 DAV:resourcetype property MUST be included with the 302 status code. 594 This necessitates an extension to the syntax of the DAV:response 595 element that was defined in [RFC2518]. The extension is defined in 596 Section 14 below. 598 A referencing-aware client can tell from the DAV:resourcetype 599 property that the collection contains a redirect reference resource. 600 The DAV:location pseudo-property contains the absolute URI of the 601 target resource. A referencing-aware client can either use the URI 602 value of the DAV:location pseudo-property to resubmit its request to 603 the target resource, or it can submit the request to the redirect 604 reference resource with Apply-To-Redirect-Ref. 606 It is recommended that future editors of [RFC2518] define the 607 DAV:location pseudo-property in [RFC2518], so that non-referencing 608 clients will also be able to use the response to operate on the 609 target resource. (This will also enable clients to operate on 610 traditional HTTP/1.1 302 responses in Multi-Status responses.) Until 611 then, non-referencing clients will not be able to process 302 612 responses from redirect reference resources encountered while 613 processing a collection. 615 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be 616 used with any request on a collection. If present, it will be 617 applied to all redirect reference resources encountered while 618 processing the collection. 620 7.1 MOVE and DELETE on Collections That Contain Redirect References 622 DELETE removes the binding that corresponds to the Request-URI. MOVE 623 removes that binding and creates a new binding to the same resource. 624 In cases where DELETE and MOVE are applied to a collection, these 625 operations affect all the descendents of the collection, but they do 626 so indirectly. There is no need to visit each descendent in order to 627 process the request. Consequently, even if there are redirect 628 reference resources in a tree that is being deleted or moved, there 629 will be no 302 responses from the redirect reference resources. 631 7.2 LOCK on a Collection That Contains Redirect References 633 LOCK poses special problems because it is atomic. An attempt to lock 634 (with Depth: infinity) a collection that contains redirect references 635 will always fail. The Multi-Status response will contain a 302 636 response for each redirect reference. 638 Reference-aware clients can lock the collection by using 639 Apply-To-Redirect-Ref, and, if desired, lock the targets of the 640 redirect references individually. 642 Non-referencing clients must resort to locking each resource 643 individually. 645 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources 647 Suppose a PROPFIND request with Depth: infinity is submitted to the 648 following collection, with the members shown here: 650 http://www.svr.com/MyCollection/ 651 (non-reference resource) diary.html 652 (redirect reference resource) nunavut 654 >> Request: 656 PROPFIND /MyCollection/ HTTP/1.1 657 Host: www.svr.com 658 Depth: infinity 659 Content-Type: text/xml 660 Content-Length: xxxx 662 663 664 665 666 667 668 670 >> Response: 672 HTTP/1.1 207 Multi-Status 673 Content-Type: text/xml 674 Content-Length: xxxx 676 677 678 679 http://www.svr.com/MyCollection/ 680 681 682 683 diary, interests, hobbies 684 685 HTTP/1.1 200 OK 686 687 688 689 http://www.svr.com/MyCollection/diary.html 690 691 692 693 diary, travel, family, history 694 695 HTTP/1.1 200 OK 696 697 698 699 http://www.svr.com/MyCollection/nunavut 700 HTTP/1.1 302 Found 701 702 703 http://www.inac.gc.ca/art/inuit/ 704 705 706 707 708 710 In this example the Depth header is set to infinity, and the 711 Apply-To-Redirect-Ref header is not used. The collection contains 712 one URI that identifies a redirect reference resource. The response 713 element for the redirect reference resource has a status of 302 714 (Found), and includes a DAV:prop element with the DAV:location 715 pseudo-property and the DAV:resourcetype property to allow clients to 716 retrieve the properties of its target resource. (The response 717 element for the redirect reference resource does not include the 718 requested properties. The client can submit another PROPFIND request 719 to the URI in the DAV:location pseudo-property to retrieve those 720 properties.) 722 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 723 Redirect Reference Resources 725 Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth: 726 infinity is submitted to the following collection, with the members 727 shown here: 729 /MyCollection/ 730 (non-reference resource) diary.html 731 (redirect reference resource) nunavut 733 >> Request: 735 PROPFIND /MyCollection/ HTTP/1.1 736 Host: www.svr.com 737 Depth: infinity 738 Apply-To-Redirect-Ref: 739 Content-Type: text/xml 740 Content-Length: xxxx 742 743 744 745 746 747 748 750 >> Response: 752 HTTP/1.1 207 Multi-Status 753 Content-Type: text/xml 754 Content-Length: xxxx 756 757 758 759 http://www.svr.com/MyCollection/ 760 761 762 763 764 HTTP/1.1 200 OK 765 766 767 768 HTTP/1.1 404 Not Found 769 770 771 772 http://www.svr.com/MyCollection/diary.html 773 774 775 776 777 HTTP/1.1 200 OK 778 779 780 781 HTTP/1.1 404 Not Found 782 783 784 785 http://www.svr.com/MyCollection/nunavut 786 787 788 789 790 http://www.inac.gc.ca/art/inuit/ 791 792 793 HTTP/1.1 200 OK 794 795 796 798 Since the Apply-To-Redirect-Ref header is present, the response shows 799 the properties of the redirect reference resource in the collection 800 rather than reporting a 302 status. 802 7.5 Example: COPY on a Collection That Contains a Redirect Reference 803 Resource 805 Suppose a COPY request is submitted to the following collection, with 806 the members shown: 808 /MyCollection/ 809 (non-reference resource) diary.html 810 (redirect reference resource) nunavut with target 811 /Someplace/nunavut.map 813 >> Request: 815 COPY /MyCollection/ HTTP/1.1 816 Host: www.svr.com 817 Depth: infinity 818 Destination: http://www.svr.com/OtherCollection/ 820 >> Response: 822 HTTP/1.1 207 Multi-Status 823 Content-Type: text/xml; charset="utf-8" 824 Content-Length: xxx 826 827 828 829 http://www.svr.com/MyCollection/nunavut 830 HTTP/1.1 302 Found 831 832 833 http://www.svr.com//Someplace/nunavut.map 834 835 836 837 838 840 In this case, since /MyCollection/nunavut is a redirect reference 841 resource, the COPY operation was only a partial success. The 842 redirect reference resource was not copied, but a 302 response was 843 returned for it. So the resulting collection is as follows: 845 /OtherCollection/ 846 (non-reference resource) diary.html 848 7.6 Example: LOCK on a Collection That Contains a Redirect Reference 849 Resource 851 Suppose a LOCK request is submitted to the following collection, with 852 the members shown: 854 /MyCollection/ 855 (non-reference resource) diary.html 856 (redirect reference resource) nunavut 858 >> Request: 860 LOCK /MyCollection/ HTTP/1.1 861 Host: www.svr.com 862 Content-Type: text/xml 863 Content-Length: nnnn 864 Authorizaton: Digest username="jas", 865 realm=jas@webdav.sb.aol.com, nonce=". . . ", 866 uri="/MyCollection/tuva", 867 response=". . . ", opaque=". . . " 869 870 871 872 873 874 http://www.svr.com/~jas/contact.html 875 876 878 >> Response: 880 HTTP/1.1 207 Multi-Status 881 Content-Type: text/xml 882 Content-Length: nnnn 884 885 886 887 http://www.svr.com/MyCollection/ 888 889 890 HTTP/1.1 424 Failed Dependency 891 892 893 894 http://www.svr.com/MyCollection/diary.html 895 HTTP/1.1 424 Failed Dependency 896 897 898 http://www.svr.com/MyCollection/nunavut 899 HTTP/1.1 302 Found 900 901 902 http://www.inac.gc.ca/art/inuit/ 903 904 905 906 907 909 The server returns a 302 response code for the redirect reference 910 resource in the collection. Consequently, neither the collection nor 911 any of the resources identified by its internal member URIs were 912 locked. A referencing-aware client can submit a separate LOCK request 913 to the URI in the DAV:location pseudo-property returned for the 914 redirect reference resource, and can resubmit the LOCK request with 915 the Apply-To-Redirect-Ref header to the collection. At that point 916 both the reference resource and its target resource will be locked 917 (as well as the collection and all the resources identified by its 918 other members). 920 8. Operations on Targets of Redirect Reference Resources 922 Operations on targets of redirect reference resources have no effect 923 on the reference resource. 925 9. Relative URIs in DAV:reftarget 927 The URI in the href in a DAV:reftarget property MAY be a relative 928 URI. In this case, the base URI to be used for resolving the relative 929 URI to absolute form is the URI used in the HTTP message to identify 930 the redirect reference resource to which the DAV:reftarget property 931 belongs. 933 When DAV:reftarget occurs in the body of a MKRESOURCE request, the 934 base URI is constructed as follows: Its scheme component is "http", 935 its authority component is the value of the Host header in the 936 request, and its path component is the Request-URI in the request. 937 See Section 5 of [RFC2396] for a discussion of relative URI 938 references and how to resolve them. 940 When DAV:reftarget appears in the context of a Multi-Status response, 941 it is in a DAV:response element that contains a single DAV:href 942 element. The value of this DAV:href element serves as the base URI 943 for resolving a relative URI in DAV:reftarget. The value of DAV:href 944 may itself be relative, in which case it must be resolved first in 945 order to serve as the base URI for the relative URI in DAV:reftarget. 946 If the DAV:href element is relative, its base URI is constructed from 947 the scheme component "http", the value of the Host header in the 948 request, and the request-URI. 950 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request 952 >> Request: 954 MKRESOURCE /north/inuvik HTTP/1.1 955 Host: www.somehost.edu 956 Content-Type: text/xml; charset="utf-8" 957 Content-Length: xxx 959 960 961 962 963 964 965 mapcollection/inuvik.gif 966 967 968 969 971 >> Response: 973 HTTP/1.1 201 Created 975 In this example, the base URI is http://www.somehost.edu/north/ 976 inuvik. Then, following the rules in [RFC2396] Section 5, the 977 relative URI in DAV:reftarget resolves to the absolute URI http:// 978 www.somehost.edu/north/mapcollection/inuvik.gif. 980 9.2 Example: Resolving a Relative URI in a Multi-Status Response 982 >> Request: 984 PROPFIND /geog/ HTTP/1.1 985 Host: www.xxsvr.com 986 Apply-To-Redirect-Ref: 987 Depth: 1 988 Content-Type: text/xml 989 Content-Length: nnn 991 992 993 994 995 996 997 999 >> Response: 1001 HTTP/1.1 207 Multi-Status 1002 Content-Type: text/xml 1003 Content-Length: nnn 1005 1006 1007 1008 /geog/ 1009 1010 1011 1012 1013 HTTP/1.1 200 OK 1014 1015 1016 1017 HTTP/1.1 404 Not Found 1018 1019 1020 1021 /geog/stats.html 1022 1023 1024 1025 1026 statistics/population/1997.html 1027 1028 1029 HTTP/1.1 200 OK 1030 1031 1032 1034 In this example, the relative URI statistics/population/1997.html is 1035 returned as the value of reftarget for the reference resource 1036 identified by href /geog/stats.html. The href is itself a relative 1037 URI, which resolves to http://www.xxsrv.com/geog/stats.html. This is 1038 the base URI for resolving the relative URI in reftarget. The 1039 absolute URI of reftarget is http://www.xxsrv.com/geog/statistics/ 1040 population/1997.html. 1042 10. Redirect References to Collections 1044 In a Request-URI /segment1/segment2/segment3, any of the three 1045 segments may identify a redirect reference resource. (See [RFC2396], 1046 Section 3.3, for definitions of "path" and "segment".) If any 1047 segment in a Request- URI identifies a redirect reference resource, 1048 the response is a 302. The value of the Location header in the 302 1049 response is as follows: 1051 The leftmost path segment of the request-URI that identifies a 1052 redirect reference resource, together with all path segments and 1053 separators to the left of it, is replaced by the value of the 1054 redirect reference resource's DAV:reftarget property (resolved to an 1055 absolute URI). The remainder of the request-URI is concatenated to 1056 this path. 1058 Note: If the DAV:reftarget property ends with a "/" and the remainder 1059 of the Request-URI is non-empty (and therefore must begin with a "/ 1060 "), the final "/" in the DAV:reftarget property is dropped before the 1061 remainder of the Request-URI is appended. 1063 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 1064 reference resource whose target resource is collection /a/, which 1065 contains redirect reference resource y whose target resource is 1066 collection /b/, which contains redirect reference resource z.html 1067 whose target resource is /c/d.html. 1069 /x/y/z.html 1070 | 1071 | /x -> /a 1072 | 1073 v 1074 /a/y/z.html 1075 | 1076 | /a/y -> /b 1077 | 1078 v 1079 /b/z.html 1080 | 1081 | /b/z.html -> /c/d.html 1082 | 1083 v 1084 /c/d.html 1086 In this case the client must follow up three separate 302 responses 1087 before finally reaching the target resource. The server responds to 1088 the initial request with a 302 with Location: /a/y/z.html, and the 1089 client resubmits the request to /a/y/z.html. The server responds to 1090 this request with a 302 with Location: /b/z.html, and the client 1091 resubmits the request to /b/z.html. The server responds to this 1092 request with a 302 with Location: /c/d.html, and the client resubmits 1093 the request to /c/d.html. This final request succeeds. 1095 11. Headers 1097 11.1 Redirect-Ref Response Header 1099 Redirect-Ref = "Redirect-Ref:" 1101 The Redirect-Ref header is used in all 302 responses from redirect 1102 reference resources. Its presence informs reference-aware clients 1103 that the response is not a plain HTTP/1.1 redirect, but is a response 1104 from a redirect reference resource. 1106 11.2 Apply-To-Redirect-Ref Request Header 1108 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" 1110 The optional Apply-To-Redirect-Ref header can be used on any request 1111 to a redirect reference resource. When it is used, the request MUST 1112 be applied to the reference resource itself, and a 302 response MUST 1113 NOT be returned. 1115 If the Apply-To-Redirect-Ref header is used on a request to any other 1116 sort of resource besides a redirect reference resource, the server 1117 SHOULD ignore it. 1119 12. Properties 1121 12.1 reftarget Property 1123 Name: reftarget 1125 Namespace: DAV: 1127 Purpose: A property of redirect reference resources that provides an 1128 efficient way for clients to discover the URI of the target 1129 resource. This is a read-only property after its initial 1130 creation. Its value can only be set in a MKRESOURCE request. 1132 Value: href containing the URI of the target resource. This value 1133 MAY be a relative URI. The reftarget property can occur in the 1134 entity bodies of MKRESOURCE requests and of responses to PROPFIND 1135 requests. 1137 1139 12.2 location Pseudo-Property 1141 Name: location 1143 Namespace: DAV: 1145 Purpose: For use with 302 (Found) response codes in Multi-Status 1146 responses. It contains the absolute URI of the temporary location 1147 of the resource. In the context of redirect reference resources, 1148 this value is the absolute URI of the target resource. It is 1149 analogous to the Location header in HTTP 302 responses defined in 1150 [RFC2616] Section 10.3.3 "302 Found." Including the location 1151 pseudo-property in a Multi- Status response requires an extension 1152 to the syntax of the DAV:response element defined in [RFC2518], 1153 which is defined in Section 14 below. This pseudo-property is not 1154 expected to be stored on the reference resource. It is modeled as 1155 a property only so that it can be returned inside a DAV:prop 1156 element in a Multi-Status response. 1158 Value: href containing the absolute URI of the target resource. 1160 1162 13. XML Elements 1164 13.1 redirectref XML Element 1166 Name: redirectref 1168 Namespace: DAV: 1170 Purpose: Used as the value of the DAV:resourcetype property to 1171 specify that the resource type is a redirect reference resource. 1173 1175 14. Extensions to the DAV:response XML Element for Multi-Status 1176 Responses 1178 As described in Section 7, the DAV:location pseudo-property and the 1179 DAV:resourcetype property may be returned in the DAV:response element 1180 of a 207 Multi-Status response, to allow clients to resubmit their 1181 requests to the target resource of a redirect reference resource. 1183 Whenever these properties are included in a Multi-Status response, 1184 they are placed in a DAV:prop element associated with the href to 1185 which they apply. This structure provides a framework for future 1186 extensions by other standards that may need to include additional 1187 properties in their responses. 1189 Consequently, the definition of the DAV:response XML element changes 1190 to the following: 1192 1195 15. Capability Discovery 1197 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 1198 classes with the DAV header in responses to OPTIONS, to indicate 1199 which parts of the WebDAV Distributed Authoring protocols the 1200 resource supports. This specification defines an OPTIONAL extension 1201 to [RFC2518]. It defines a new compliance class, called 1202 redirectrefs, for use with the DAV header in responses to OPTIONS 1203 requests. If a resource does support redirect references, its 1204 response to an OPTIONS request may indicate that it does, by listing 1205 the new redirectrefs compliance class in the DAV headerand by listing 1206 the MKRESOURCE method as one it supports. 1208 When responding to an OPTIONS request, any type of resource can 1209 include redirectrefs in the value of the DAV header. Doing so 1210 indicates that the server permits a redirect reference resource at 1211 the request URI. 1213 15.1 Example: Discovery of Support for Redirect Reference Resources 1215 >> Request: 1217 OPTIONS /somecollection/someresource HTTP/1.1 1218 HOST: somehost.org 1220 >> Response: 1222 HTTP/1.1 200 OK 1223 Date: Tue, 20 Jan 1998 20:52:29 GMT 1224 Connection: close 1225 Accept-Ranges: none 1226 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, 1227 MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE 1228 DAV: 1, 2, redirectrefs 1230 The DAV header in the response indicates that the resource / 1231 somecollection/someresource is level 1 and level 2 compliant, as 1232 defined in [RFC2518]. In addition, /somecollection/someresource 1233 supports redirect reference resources. The Allow header indicates 1234 that MKRESOURCE requests can be submitted to /somecollection/ 1235 someresource. The Public header shows that other Request-URIs on the 1236 server support additional methods. 1238 16. Security Considerations 1240 This section is provided to make applications that implement this 1241 protocol aware of the security implications of this protocol. 1243 All of the security considerations of HTTP/1.1 and the WebDAV 1244 Distributed Authoring Protocol specification also apply to this 1245 protocol specification. In addition, redirect reference resources 1246 introduce several new security concerns and increase the risk of some 1247 existing threats. These issues are detailed below. 1249 16.1 Privacy Concerns 1251 By creating redirect reference resources on a trusted server, it is 1252 possible for a hostile agent to induce users to send private 1253 information to a target on a different server. This risk is 1254 mitigated somewhat, since clients are required to notify the user of 1255 the redirection for any request other than GET or HEAD. (See 1256 [RFC2616], Section 10.3.3 302 Found.) 1258 16.2 Redirect Loops 1260 Although redirect loops were already possible in HTTP 1.1, the 1261 introduction of the MKRESOURCE method creates a new avenue for 1262 clients to create loops accidentally or maliciously. If the 1263 reference resource and its target are on the same server, the server 1264 may be able to detect MKRESOURCE requests that would create loops. 1265 See also [RFC2616], Section 10.3 "Redirection 3xx." 1267 16.3 Redirect Reference Resources and Denial of Service 1269 Denial of service attacks were already possible by posting URLs that 1270 were intended for limited use at heavily used Web sites. The 1271 introduction of MKRESOURCE creates a new avenue for similar denial of 1272 service attacks. Clients can now create redirect reference resources 1273 at heavily used sites to target locations that were not designed for 1274 heavy usage. 1276 16.4 Revealing Private Locations 1278 There are several ways that redirect reference resources may reveal 1279 information about collection structures. First, the DAV:reftarget 1280 property of every redirect reference resource contains the URI of the 1281 target resource. Anyone who has access to the reference resource can 1282 discover the collection path that leads to the target resource. The 1283 owner of the target resource may have wanted to limit knowledge of 1284 this collection structure. 1286 Sufficiently powerful access control mechanisms can control this risk 1287 to some extent. Property-level access control could prevent users 1288 from examining the DAV:reftarget property. (The Location header 1289 returned in responses to requests on redirect reference resources 1290 reveals the same information, however.) In some environments, the 1291 owner of a resource might be able to use access control to prevent 1292 others from creating references to that resource. 1294 This risk is no greater than the similar risk posed by HTML links. 1296 17. Internationalization Considerations 1298 This specification follows the practices of [RFC2518] in encoding all 1299 human-readable content using XML [XML] and in the treatment of names. 1300 Consequently, this specification complies with the IETF Character Set 1301 Policy [RFC2277]. 1303 WebDAV applications MUST support the character set tagging, character 1304 set encoding, and the language tagging functionality of the XML 1305 specification. This constraint ensures that the human-readable 1306 content of this specification complies with [RFC2277]. 1308 As in [RFC2518], names in this specification fall into three 1309 categories: names of protocol elements such as methods and headers, 1310 names of XML elements, and names of properties. Naming of protocol 1311 elements follows the precedent of HTTP, using English names encoded 1312 in USASCII for methods and headers. The names of XML elements used 1313 in this specification are English names encoded in UTF-8. 1315 For error reporting, [RFC2518] follows the convention of HTTP/1.1 1316 status codes, including with each status code a short, English 1317 description of the code (e.g., 423 Locked). Internationalized 1318 applications will ignore this message, and display an appropriate 1319 message in the user's language and character set. 1321 This specification introduces no new strings that are displayed to 1322 users as part of normal, error-free operation of the protocol. 1324 For rationales for these decisions and advice for application 1325 implementors, see [RFC2518]. 1327 18. IANA Considerations 1329 All IANA considerations mentioned in [RFC2518] also apply to this 1330 document. 1332 19. Acknowledgements 1334 This draft has benefited from thoughtful discussion by Jim Amsden, 1335 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1336 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1337 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, 1338 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel 1339 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton, 1340 Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley 1341 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin 1342 Wiggen, and others. 1344 Normative References 1346 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1347 Languages", BCP 18, RFC 2277, January 1998. 1349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1350 Requirement Levels", BCP 14, RFC 2119, March 1997. 1352 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1353 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1354 August 1998. 1356 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1357 Jensen, "HTTP Extensions for Distributed Authoring -- 1358 WEBDAV", RFC 2518, February 1999. 1360 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1361 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1362 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1364 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1365 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C 1366 REC-xml, October 2000, . 1369 [1] 1371 [2] 1373 [3] 1376 [4] 1379 [5] 1382 [6] 1385 [7] 1388 [8] 1391 [9] 1394 [10] 1397 [11] 1400 [12] 1403 [13] 1406 [14] 1409 [15] 1412 [16] 1415 [17] 1418 [18] 1421 [19] 1424 [20] 1427 [21] 1430 [22] 1433 [23] 1436 [24] 1439 [25] 1442 [26] 1445 [27] 1448 [28] 1451 [29] 1454 [30] 1457 [31] 1460 [32] 1463 [33] 1466 [34] 1469 [35] 1472 [36] 1475 [37] 1478 [38] 1481 [39] 1484 [40] 1487 [41] 1490 [42] 1493 [43] 1496 [44] 1499 [45] 1502 [46] 1505 [47] 1508 [48] 1511 [49] 1514 [50] 1517 [51] 1520 [52] 1523 [53] 1526 [54] 1529 [55] 1532 [56] 1535 [57] 1538 [58] 1541 [59] 1544 [60] 1547 Authors' Addresses 1549 J. Slein 1550 Xerox Corporation 1551 800 Phillips Road, 105-50C 1552 Webster, NY 14580 1554 EMail: jslein@crt.xerox.com 1556 Jim Whitehead 1557 UC Santa Cruz, Dept. of Computer Science 1558 1156 High Street 1559 Santa Cruz, CA 95064 1560 US 1562 EMail: ejw@cse.ucsc.edu 1564 J. Davis 1565 CourseNet Systems 1566 170 Capp Street 1567 San Francisco, CA 94110 1569 EMail: jrd3@alum.mit.edu 1571 G. Clemm 1572 Rational Software Corporation 1573 20 Maguire Road 1574 Lexington, MA 02173-3104 1576 EMail: geoffrey.clemm@us.ibm.com 1577 C. Fay 1578 FileNet Corporation 1579 3565 Harbor Boulevard 1580 Costa Mesa, CA 92626-1420 1582 EMail: cfay@filenet.com 1584 J. Crawford 1585 IBM Research 1586 P.O. Box 704 1587 Yorktown Heights, NY 10598 1589 EMail: ccjason@us.ibm.com 1591 Julian F. Reschke (editor) 1592 greenbytes GmbH 1593 Salzmannstrasse 152 1594 Muenster, NW 48159 1595 Germany 1597 Phone: +49 251 2807760 1598 Fax: +49 251 2807761 1599 EMail: julian.reschke@greenbytes.de 1600 URI: http://greenbytes.de/tech/webdav/ 1602 Appendix A. Changes to the WebDAV Document Type Definition 1604 1605 1606 Property Elements from Section 12 --> 1607 1608 1609 1610 1613 Appendix B. Change Log (to be removed by RFC Editor before publication) 1615 B.1 Since draft-ietf-webdav-redirectref-protocol-02 1617 Julian Reschke takes editorial role (added to authors list). Cleanup 1618 XML indentation. Start adding all unresolved last call issues. Update 1619 some author's contact information. Update references, split into 1620 "normative" and "informational". Remove non-RFC2616 headers 1621 ("Public") from examples. Fixed width problems in artwork. Start 1622 resolving editorial issues. 1624 B.2 Since draft-ietf-webdav-redirectref-protocol-03 1626 Added Joe Orton and Juergen Reuter to Acknowledgements section. Close 1627 more editorial issues. Remove dependencies on BIND spec. 1629 Appendix C. Resolved issues (to be removed by RFC Editor before 1630 publication) 1632 Issues that were either rejected or resolved in this version of this 1633 document. 1635 C.1 lc-07-bind 1637 Type: change 1639 [3] 1641 reuterj@ira.uka.de (2000-02-07): Abstract should discuss only 1642 redirect references, not bindings. Expand discussion of redirect 1643 references. 1645 Resolution: Abstract will discuss only redirect references. See also 1646 issue 34. 1648 C.2 lc-08-bind 1650 Type: change 1652 [4] 1654 reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the 1655 binding spec: in the abstract, in the introduction, in the definition 1656 of Reference Resource. 1658 Resolution: Cross-references to bindings will be removed. See also 1659 issue 34. 1661 C.3 lc-34-bind 1663 Type: change 1665 [5] 1667 yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all 1668 cross-references to the binding spec. Prefer also removing all 1669 mention of bindings. 1671 Resolution: Agreed. See also issues 7, 8, 14 1673 C.4 lc-83-bind 1675 Type: change 1677 [6] 1679 reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference 1680 to the bindings spec. 1682 Resolution: Agreed. 1684 C.5 lc-12-bind 1686 Type: change 1688 [7] 1690 reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction 1691 are identical to those in binding spec. Make sure that any changes 1692 made there are also incorporated here. 1694 Resolution: These paragraphs will change as necessary to make the 1695 redirect spec completely independent of the rest of WebDAV. 1697 C.6 lc-35-bind 1699 Type: change 1701 [8] 1703 yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove 1704 paras. 6 and 8 from Intro. 1706 Resolution: Agreed. See also issue 14. 1708 C.7 lc-01-body 1710 Type: change 1712 [9] 1714 joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect 1715 References: Clarify: Are there 2 resources, one that redirects and 1716 one that responds with its own entity body? Clarify: What is the 1717 effect of PUT for a URI that currently maps to a redirect reference? 1719 Resolution: Redirect resource MUST NOT have a body. See also issue 1720 last call issue 23. 1722 C.8 lc-14-bind 1724 Type: change 1726 [10] 1728 reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to 1729 just what is needed to understand the differences from redirect 1730 references. Maybe the paragraph in the Intro that starts "By 1731 contrast, a BIND request . . ." is all that is needed. 1733 Resolution: Get rid of discussion of bindings altogether. See also 1734 issue 34, 35. 1736 C.9 lc-15-direct-ref 1738 Type: change 1740 [11] 1742 reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference 1743 Resource, since direct references are out of scope. (If you do keep 1744 the definition, say explicitly that a direct reference resource is a 1745 type of reference resource.) 1747 Resolution: Remove definition of Direct Reference Resource. See also 1748 issue 39. 1750 C.10 lc-39-no-reference-or-direct-resource 1752 Type: change 1754 [12] 1756 yarong@Exchange.Microsoft.com (2000-02-11): 1757 NoReferenceOrDirectResource: Remove the definitions of "Reference" 1758 and "Direct Reference Resource." Change the definition of "Redirect 1759 Reference Resource" to be: Redirect Resource: A resource created to 1760 redirect all requests made to it, using 302 (Found), to a defined 1761 target resource. 1763 julian.reschke@greenbytes.de (2003-07-27): (Rename from "redirect 1764 reference resource" to "redirect resource" delayed for now). 1766 Resolution: Agreed. See also issue 15. 1768 C.11 lc-40-direct 1770 Type: change 1772 [13] 1773 yarong@Exchange.Microsoft.com (2000-02-11): Assorted changes to 1774 Section 4, para 2 to get rid of the word "forward" and the word 1775 "server" and remove comparison with direct references. 1777 Resolution: See also issue 33 (forward). See also issue 36 (server). 1778 Remove discussion of direct references. 1780 C.12 lc-45-apply-to-rr 1782 Type: change 1784 [14] 1786 yarong@Exchange.Microsoft.com (2000-02-11): Suggested replacement 1787 text for this paragraph, which briefly introduces 1788 Apply-To-Redirect-Ref. Includes a note that even with this header, 1789 the response may be a 302. 1791 Resolution: See issue 19 for replacement text. Disagree. Redirect 1792 reference will never respond to Apply-To-RR with 302. 1794 C.13 lc-01A-body 1796 Type: change 1798 [15] 1800 joe@orton.demon.co.uk (2000-01-26): In the definition of MKRESOURCE, 1801 "Body" needs to be defined or else terminology changed. 1803 Resolution: We will use MKREF instead of MKRESOURCE. 1805 C.14 lc-31-MKCOL 1807 Type: edit 1809 [16] 1811 reuterj@ira.uka.de (2000-02-07): Section 6, para on MKRESOURCE and 1812 MKCOL is obvious and doesn't need to be stated. Maybe show in an 1813 example. 1815 Resolution: Agreed. See also issue 48. 1817 C.15 lc-67-redirectref 1819 Type: change 1821 [17] 1823 reuterj@ira.uka.de (2000-02-14): 7.4: The explanation should not 1824 contrast displaying the properties of the redirect ref with 1825 displaying the properties of its target, but with returning a 302. 1827 Resolution: Revise as recommended. 1829 C.16 lc-54-s10 1831 Type: change 1833 [18] 1835 yarong@Exchange.Microsoft.com (2000-02-11): The Note: in section 10 1836 has the same problem pointed out in Bindings.NoSlash and needs to be 1837 fixed. It contradicts RFC 2518 and 2616, which both assume that a URL 1838 and the same URL + "/" may map to different resources. 1840 Resolution: Agreed in mailing list discussions that no change is 1841 needed. 1843 C.17 lc-78-directory 1845 Type: change 1847 [19] 1849 reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to 1850 "collection". Not new to this protocol. Holds for any protocol that 1851 has hierarchical access paths. 1853 C.18 lc-82-iana 1855 Type: change 1857 [20] 1859 reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV] 1860 and say this protocol does not introduce any new considerations. 1862 Resolution: Simplify, then resolve issue 55. 1864 Appendix D. Open issues (to be removed by RFC Editor before publication) 1866 D.1 lc-85-301 1868 Type: change 1870 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302 1871 redirects, especially 301. 1873 D.2 lc-38-not-hierarchical 1875 Type: change 1877 [21] 1879 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The 1880 first sentence of the second paragraph of the introduction of the 1881 redirect spec asserts that the URIs of WebDAV compliant resources 1882 match to collections. The WebDAV standard makes no such requirement. 1883 I therefore move that this sentence be stricken. 1885 Resolution: State the more general HTTP rationale first (alternative 1886 names for the same resource), then introduce the collection hierarchy 1887 rationale, which applies only if you are in a WebDAV-compliant space. 1889 D.3 lc-36-server 1891 Type: change 1893 [22] 1895 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" 1896 with "unrelated system" throughout. 1898 Resolution: Try replacing "server" with "host" in some contexts, 1899 rephrasing in passive voice in others. See also issue 40. 1901 D.4 lc-33-forwarding 1903 Type: change 1905 [23] 1907 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace 1908 "forward" with "redirect" throughout. 1910 Resolution: Use "redirect" for the behavior redirect resources do 1911 exhibit. Use "forward" for the contrasting behavior (passing a method 1912 on to the target with no client action needed). Define these two 1913 terms. See also issue 40. 1915 D.5 lc-56-notjusthttp 1917 Type: change 1919 [24] 1921 yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples 1922 and text that the redirection URI could be non-HTTP. 1924 Resolution: We agree that it is possible to create redirect 1925 references to non-HTTP resources. Add example. 1927 D.6 lc-37-integrity 1929 Type: change 1931 [25] 1933 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7 1934 "Servers are not required to enforce the integrity of redirect 1935 references." Integrity is not defined. Replace with something 1936 clearer. 1938 Resolution: Rewrite to say that the server MUST NOT update the target 1939 See also issue 6. 1941 D.7 3-terminology-redirectref 1943 Type: change 1945 [26] 1947 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of 1948 "redirect reference resource" to "redirect resource". 1950 D.8 lc-43-webdav 1952 Type: change 1954 [27] 1956 yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the 1957 DAV:reftarget property. 1959 Resolution: DAV:reftarget is readonly and is present only for 1960 redirect references that are also WebDAV resources. We'll also have a 1961 method for setting target; Redirect-Ref header (returned on all 302 1962 responses) will have the target as its value. See also issue 6, 17, 1963 50. 1965 D.9 lc-19-direct-ref 1967 Type: change 1969 [28] 1971 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6, 1972 para 3 discussions of the Apply-to-Redirect-Ref header make it sound 1973 as if we are specifying direct reference behavior. 1975 Resolution: Change these passages so that the contrast is between 1976 applying the method to the redirect reference and responding with a 1977 302. 1979 D.10 lc-04-standard-data-container 1981 Type: change 1983 [29] 1985 joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs 1986 to be defined in the context of MKRESOURCE 1988 Resolution: Not relevant once we switch to MKREF. 1990 D.11 lc-05-standard-data-container 1992 Type: change 1994 [30] 1996 joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a 1997 "standard data container" can be created with MKRESOURCE or not. 1999 Resolution: Not relevant once we switch to MKREF. 2001 D.12 lc-20-intro-mkresource 2003 Type: change 2005 [31] 2007 reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new 2008 MKRESOURCE method" to make it clear that it is being introduced for 2009 the first time here. 2011 Resolution: Say "The MKREF method defined normatively here . . ." 2013 D.13 lc-22-coll 2015 Type: change 2017 [32] 2019 reuterj@ira.uka.de (2000-02-07): Inconsistency about whether 2020 collections can be created with MKRESOURCE. 2022 Resolution: Not relevant for MKREF. 2024 D.14 lc-25-atomic 2026 Type: change 2028 [33] 2030 reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a 2031 client? Can another client access the new resource's properties 2032 before they have been fully initialized? Maybe the MKRESOURCE request 2033 should let the client ask for it to be atomic. 2035 Resolution: No longer relevant once we switch to MKREF with no 2036 request body. 2038 D.15 lc-41-no-webdav 2040 Type: change 2042 [34] 2044 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references 2045 independent of the rest of WebDAV. The creation method for redirect 2046 references shouldn't require an XML request body. 2048 Resolution: We will make redirect references independent of the rest 2049 of WebDAV. MKREF will not have an XML request body. 2051 D.16 lc-42-no-webdav 2053 Type: change 2055 [35] 2056 yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method 2057 that creates only redirect references. The MKRESOURCE method hinders 2058 experiment because a user of a server who wishes to add support for 2059 the creation of a new resource type can't simply throw in another 2060 Apache module and allow it to provide the code for the new resource 2061 type. They have to find the code used for MKRESOURCE and change it to 2062 support the new resource type. 2064 Resolution: We will replace MKRESOURCE with MKREF, which creates only 2065 redirect reference resources. 2067 D.17 lc-58-update 2069 Type: change 2071 [36] 2073 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way 2074 to update the target of a redirect reference. 2076 Resolution: Agreed. See also issues 6, 43. 2078 D.18 lc-23-body 2080 Type: change 2082 [37] 2084 reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the 2085 statement that the body of the resource is empty (PostConditions). It 2086 would be good if the response to GET included a response body that 2087 could be shown to a user by a client that doesn't do automatic 2088 redirection. There is a related problem in Section 6 on PUT. It is 2089 wrong to assume that what is PUT to a resource is what GET will 2090 return. In Section 6, say "A PUT with Apply-To-RR MAY contain a 2091 request body. The semantics of the request body is out of scope for 2092 this specification..." Also fix the discussion of example 6.2. 2094 Resolution: Redirect references cannot have bodies. GET with 2095 Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with 2096 403. See also issue 1. 2098 D.19 lc-24-properties 2100 Type: change 2102 [38] 2103 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence 2104 "The properties of the new resource are as specified by the 2105 DAV:propertyupdate request body, using PROPPATCH semantics" with the 2106 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate 2107 request body to initialize resource properties. Herein, the semantics 2108 is the same as when sending a MKRESOURCE request without a request 2109 body, followed by a PROPPATCH with the DAV:propertyupdate request 2110 body." 2112 Resolution: No longer relevant once we switch to MKREF with no 2113 request body. 2115 D.20 lc-47-207 2117 Type: change 2119 [39] 2121 yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to 2122 get rid of the request message body of MKRESOURCE, 207 would not be 2123 an appropriate response code. The description of 409 might lead 2124 someone to believe that you can't create redirect references outside 2125 of WebDAV namespaces. Suggests a different description. 2127 Resolution: No longer relevant - MKREF can't get a 207 response. 2128 Revise to make it clear that the first condition will only occur in 2129 WebDAV-compliant namespaces. 2131 D.21 lc-48-s6 2133 Type: change 2135 [40] 2137 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 2138 with just this: A redirect resource, upon receiving a request without 2139 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) 2140 response. The 302 (Found) response MUST include a location header 2141 identifying the target and a Redirect-Ref header. If a redirect 2142 resource receives a request with an Apply-To-Redirect-Ref header then 2143 the redirect reference resource MUST apply the method to itself 2144 rather than blindly returning a 302 (Found) response. 2146 Resolution: Keep a summary along the lines of Yaron's proposal (don't 2147 use the word "blindly"). Keep the bullets detailing the headers to be 2148 returned. Delete the rest, including the examples. See also issue 28, 2149 29, 30, 31, 32. 2151 D.22 lc-28-lang 2153 Type: edit 2155 [41] 2157 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence 2158 "A reference-aware WebDAV client can act on this response in one of 2159 two ways." A client can act on the response in any way it wants. 2161 Resolution: Agreed. See also issue 48. 2163 D.23 lc-29-lang 2165 Type: edit 2167 [42] 2169 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't 2170 need to be stated. Maybe note in an example. 2172 Resolution: Agreed. See also issue 48. 2174 D.24 lc-49-put 2176 Type: change 2178 [43] 2180 yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence 2181 of Example 6.2, which says that PUT replaces the reference with a 2182 different resource. 2184 Resolution: No longer relevant. Deleted this example in response to 2185 issue 48. 2187 D.25 lc-44-pseudo 2189 Type: change 2191 [44] 2193 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an 2194 optional prop XML element to the response element in 207 responses, 2195 define a new location XML element and a new refresource XML element. 2197 Resolution: Agree to define new XML elements that are not 2198 pseudo-properties. Disagreement about whether refresource is needed. 2200 See issue 61. 2202 D.26 lc-61-pseudo 2204 Type: change 2206 [45] 2208 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to 2209 ask future editors of RFC 2518 to define DAV:location with the 2210 semantics it has here. RFC 2518 should provide the information in the 2211 Location header somehow in multistatus responses, but not by using 2212 properties. 2214 Resolution: Define an XML element for location that is not a 2215 pseudo-property. We'll keep the recommendation that RFC 2518 add this 2216 for 302 responses. See also issue 44. 2218 D.27 lc-60-ex 2220 Type: change 2222 [46] 2224 reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear 2225 that these are just examples of client behavior, and are not meant to 2226 limit the client's behavior to these options. 2228 Resolution: Agreed to delete this paragraph. Continue discussion of 2229 what information should be returned with 302 in multistatus. Just 2230 location? Also redirectref? 2232 D.28 lc-62-oldclient 2234 Type: change 2236 [47] 2238 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim 2239 that non-referencing clients can't process 302 responses occurring in 2240 Multi-Status responses. They just have an extra round trip for each 2241 302. 2243 Resolution: Remove last sentence of the paragraph that recommends 2244 changes to RFC 2518. 2246 D.29 lc-63-move 2247 Type: change 2249 [48] 2251 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the 2252 perspective of a client? Agrees that there should be no 302s for 2253 member redirect references, but finds the rationale dubious. 2255 Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses 2256 special problems" and "due to atomicity". 2258 D.30 lc-06-reftarget-relative 2260 Type: change 2262 [49] 2264 joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about 2265 relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server 2266 required to resolve the relative URI and store it as absolute? Is the 2267 server required to keep DAV:reftarget pointing to the target resource 2268 as the reference / target move, or is DAV:reftarget a dead property? 2270 Resolution: DAV:reftarget is readonly and present only on redirect 2271 references that are also WebDAV resources. Add a method for setting 2272 the target. Change definition of Redirect-Ref header so that it has 2273 the target as its value (comes back on all 302 responses). Server 2274 MUST store the target exactly as it is set. It MUST NOT resolve 2275 relatives to absolutes and MUST NOT update if target resource moves. 2276 See also issue 17, 43, 50, 57 2278 D.31 lc-57-noautoupdate 2280 Type: change 2282 [50] 2284 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid 2285 servers from automatically updating redirect resources when their 2286 targets move. 2288 Resolution: Agreed. See also issue 6. 2290 D.32 lc-71-relative 2292 Type: change 2294 [51] 2295 reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the 2296 Request-URI or href minus its final segment. 2298 Resolution: Fix this. 2300 D.33 lc-53-s10 2302 Type: change 2304 [52] 2306 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in 2307 this section would have a very serious impact on the efficiency of 2308 mapping Request-URIs to resources in HTTP request processing. Also 2309 specify another type of redirect resource that does not behave as in 2310 section 10, but instead would "expose the behavior we see today in 2311 various HTTP servers that allow their users to create 300 resources." 2312 Be sure we know what behavior will be if the redirect location is not 2313 an HTTP URL, but, say ftp. 2315 Resolution: We won't define 2 sorts of redirect references here. 2316 Servers SHOULD respond with 302 as described here, but if they can't 2317 do that, respond with 404 Not Found. (It's hard to modularize the 2318 behavior specified - it impacts processing Not Found cases of all 2319 methods, so you can't just add it to an HTTP server in a redirect ref 2320 module.) 2322 D.34 lc-72-trailingslash 2324 Type: change 2326 [53] 2328 reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget 2329 from ending in "/" 2331 Resolution: Make the note warn about the possibility of two slashes 2332 in a row, recommend against ending target with a slash, since that 2333 could result in two slashes in a row. 2335 D.35 lc-50-blindredirect 2337 Type: change 2339 [54] 2341 yarong@Exchange.Microsoft.com (2000-02-11): Replace current language 2342 explaining the purpose of the Redirect-Ref header with language that 2343 simply states that it marks blind 302 responses from redirect 2344 resources. (Section 6.3, 11.1) 2346 Resolution: Section 6.3 was removed in response to issue 48. In 11.1, 2347 change the definition of the Redirect-Ref header to have the value of 2348 the target (relative URI) as its value. Then we don't need a method 2349 for retrieving the target's relative URI. Presence of the 2350 Redirect-Ref header lets the client know that the resource accepts 2351 Apply-To-RR header and the new method for updating target. Reject 2352 Yaron's suggested language, but make the above changes. 2354 D.36 lc-74-terminology 2356 Type: change 2358 [55] 2360 reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find 2361 some good name for this an use it consistently 2363 D.37 lc-75-ignore 2365 Type: change 2367 [56] 2369 reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref 2370 header is used on a request to any other sort of resource besides a 2371 redirect reference resource, the server SHOULD ignore it." Don't need 2372 to say this since HTP already says that any header that is not 2373 understood should be ignored. 2375 D.38 lc-76-location 2377 Type: change 2379 [57] 2381 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real 2382 (live) property, get rid of the DAV:reftarget property 2384 D.39 lc-79-accesscontrol 2386 Type: change 2388 [58] 2390 reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments, 2391 the owner of a resource might be able to use access control to 2392 prevent others from creating references to that resource." That would 2393 not be consistent with the concept of redirect references as weak 2394 links (e.g. think of moving a resource to a different locationo that 2395 is already the target of some redirection reference. 2397 D.40 lc-80-i18n 2399 Type: change 2401 [59] 2403 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot 2404 of this section, since this protocol extends WebDAV. Just reference 2405 [WebDAV]. 2407 D.41 lc-55-iana 2409 Type: change 2411 [60] 2413 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section 2414 to list all methods, headers, XML elements, MIME types, URL schemes, 2415 etc., defined by the spec. 2417 Resolution: Agreed. 2419 Intellectual Property Statement 2421 The IETF takes no position regarding the validity or scope of any 2422 intellectual property or other rights that might be claimed to 2423 pertain to the implementation or use of the technology described in 2424 this document or the extent to which any license under such rights 2425 might or might not be available; neither does it represent that it 2426 has made any effort to identify any such rights. Information on the 2427 IETF's procedures with respect to rights in standards-track and 2428 standards-related documentation can be found in BCP-11. Copies of 2429 claims of rights made available for publication and any assurances of 2430 licenses to be made available, or the result of an attempt made to 2431 obtain a general license or permission for the use of such 2432 proprietary rights by implementors or users of this specification can 2433 be obtained from the IETF Secretariat. 2435 The IETF invites any interested party to bring to its attention any 2436 copyrights, patents or patent applications, or other proprietary 2437 rights which may cover technology that may be required to practice 2438 this standard. Please address the information to the IETF Executive 2439 Director. 2441 Full Copyright Statement 2443 Copyright (C) The Internet Society (2003). All Rights Reserved. 2445 This document and translations of it may be copied and furnished to 2446 others, and derivative works that comment on or otherwise explain it 2447 or assist in its implementation may be prepared, copied, published 2448 and distributed, in whole or in part, without restriction of any 2449 kind, provided that the above copyright notice and this paragraph are 2450 included on all such copies and derivative works. However, this 2451 document itself may not be modified in any way, such as by removing 2452 the copyright notice or references to the Internet Society or other 2453 Internet organizations, except as needed for the purpose of 2454 developing Internet standards in which case the procedures for 2455 copyrights defined in the Internet Standards process must be 2456 followed, or as required to translate it into languages other than 2457 English. 2459 The limited permissions granted above are perpetual and will not be 2460 revoked by the Internet Society or its successors or assignees. 2462 This document and the information contained herein is provided on an 2463 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2464 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2465 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2466 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2467 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2469 Acknowledgment 2471 Funding for the RFC Editor function is currently provided by the 2472 Internet Society.