idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-03.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], [B], [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 (July 25, 2003) is 7575 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 2908, 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' == Outdated reference: A later version (-27) exists of draft-ietf-webdav-bind-02 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 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: January 23, 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 July 25, 2003 18 WebDAV Redirect Reference Resources 19 draft-ietf-webdav-redirectref-protocol-03.txt 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 January 23, 2004. 43 Copyright Notice 45 Copyright (C) The Internet Society (2003). All Rights Reserved. 47 Abstract 49 This is one of a pair of specifications that extend the WebDAV 50 Distributed Authoring Protocol to enable clients to create new access 51 paths to existing resources. The two protocol extensions have very 52 different characteristics that make them useful for different sorts 53 of applications. 55 The present specification defines redirect reference resources. A 56 redirect reference resource is a resource whose default response is 57 an HTTP/1.1 302 (Found) status code, redirecting the client to a 58 different resource, the target resource. A redirect reference makes 59 it possible to access the target resource indirectly, through any URI 60 mapped to the redirect reference resource. There are no integrity 61 guarantees associated with redirect reference resources. 63 The related specification [B], defines bindings, and the BIND method 64 for creating them. Creating a new binding to a resource indirectly 65 creates one or more new URIs mapped to that resource, which can then 66 be used to access it. Servers are required to insure the integrity 67 of any bindings that they allow to be created. 69 Distribution of this document is unlimited. Please send comments to 70 the Distributed Authoring and Versioning (WebDAV) working group at 71 w3c-dist-auth@w3.org [1], which may be joined by sending a message 72 with subject "subscribe" to w3c-dist-auth-request@w3.org [2]. 74 Discussions of the WEBDAV working group are archived at URL: http:// 75 lists.w3.org/Archives/Public/w3c-dist-auth/. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 80 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 9 81 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 10 82 4. Overview of Redirect Reference Resources . . . . . . . . . . 11 83 5. Creating a Redirect Reference Resource . . . . . . . . . . . 12 84 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5.2 Example: Creating a Redirect Reference Resource with 86 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6. Operations on Redirect Reference Resources . . . . . . . . . 15 88 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 16 89 6.2 Example: PUT on a Redirect Reference Resource with 90 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 16 91 6.3 Example: PROPPATCH on a Redirect Reference Resource . . . . 17 92 7. Operations on Collections That Contain Redirect Reference 93 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 7.1 MOVE and DELETE on Collections That Contain Redirect 95 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 7.2 LOCK on a Collection That Contains Redirect References . . . 19 97 7.3 Example: PROPFIND on a Collection with Redirect Reference 98 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a 100 Collection with Redirect Reference Resources . . . . . . . . 20 101 7.5 Example: COPY on a Collection That Contains a Redirect 102 Reference Resource . . . . . . . . . . . . . . . . . . . . . 22 103 7.6 Example: LOCK on a Collection That Contains a Redirect 104 Reference Resource . . . . . . . . . . . . . . . . . . . . . 23 105 8. Operations on Targets of Redirect Reference Resources . . . 26 106 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 27 107 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 27 108 9.2 Example: Resolving a Relative URI in a Multi-Status 109 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 10. Redirect References to Collections . . . . . . . . . . . . . 30 111 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 32 113 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 32 114 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 33 115 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 33 116 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 33 117 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 34 118 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 34 119 14. Extensions to the DAV:response XML Element for 120 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 35 121 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 36 122 15.1 Example: Discovery of Support for Redirect Reference 123 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 36 124 16. Security Considerations . . . . . . . . . . . . . . . . . . 37 125 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 37 126 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 37 127 16.3 Redirect Reference Resources and Denial of Service . . . . . 37 128 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 37 129 17. Internationalization Considerations . . . . . . . . . . . . 39 130 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 131 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 132 Normative References . . . . . . . . . . . . . . . . . . . . 42 133 Informative References . . . . . . . . . . . . . . . . . . . 43 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 135 A. Changes to the WebDAV Document Type Definition . . . . . . . 46 136 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 137 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 47 138 C. Resolved issues . . . . . . . . . . . . . . . . . . . . . . 48 139 C.1 lc-11-pagination . . . . . . . . . . . . . . . . . . . . . . 48 140 C.2 lc-09-notational-after-introduction . . . . . . . . . . . . 48 141 C.3 lc-13-usually . . . . . . . . . . . . . . . . . . . . . . . 48 142 C.4 lc-16-insure . . . . . . . . . . . . . . . . . . . . . . . . 48 143 C.5 lc-17-location . . . . . . . . . . . . . . . . . . . . . . . 49 144 C.6 lc-21-bind . . . . . . . . . . . . . . . . . . . . . . . . . 49 145 C.7 lc-46-bind . . . . . . . . . . . . . . . . . . . . . . . . . 49 146 C.8 lc-26-lang . . . . . . . . . . . . . . . . . . . . . . . . . 49 147 C.9 lc-03-mkresource-response-cacheability . . . . . . . . . . . 50 148 C.10 lc-02-status-codes . . . . . . . . . . . . . . . . . . . . . 50 149 C.11 lc-27-lang . . . . . . . . . . . . . . . . . . . . . . . . . 50 150 C.12 lc-30-headers . . . . . . . . . . . . . . . . . . . . . . . 50 151 C.13 lc-32-ORDERPATCH . . . . . . . . . . . . . . . . . . . . . . 51 152 C.14 lc-51-repeat . . . . . . . . . . . . . . . . . . . . . . . . 51 153 C.15 lc-59-depth . . . . . . . . . . . . . . . . . . . . . . . . 51 154 C.16 lc-65-lock . . . . . . . . . . . . . . . . . . . . . . . . . 51 155 C.17 lc-66-depth . . . . . . . . . . . . . . . . . . . . . . . . 52 156 C.18 lc-69-424 . . . . . . . . . . . . . . . . . . . . . . . . . 52 157 C.19 lc-68-lock . . . . . . . . . . . . . . . . . . . . . . . . . 52 158 C.20 lc-52-no-relative . . . . . . . . . . . . . . . . . . . . . 53 159 C.21 lc-64-reftarget . . . . . . . . . . . . . . . . . . . . . . 53 160 C.22 lc-70-relative . . . . . . . . . . . . . . . . . . . . . . . 53 161 C.23 lc-73-asciiart . . . . . . . . . . . . . . . . . . . . . . . 53 162 C.24 lc-77-webdav-applications . . . . . . . . . . . . . . . . . 54 163 C.25 lc-10-title . . . . . . . . . . . . . . . . . . . . . . . . 54 164 C.26 lc-81-typo . . . . . . . . . . . . . . . . . . . . . . . . . 54 165 C.27 lc-18-resource-types . . . . . . . . . . . . . . . . . . . . 54 166 C.28 lc-84-ext . . . . . . . . . . . . . . . . . . . . . . . . . 54 167 D. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 56 168 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 56 169 D.2 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56 170 D.3 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56 171 D.4 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56 172 D.5 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57 173 D.6 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57 174 D.7 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57 175 D.8 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 57 176 D.9 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 58 177 D.10 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 58 178 D.11 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 58 179 D.12 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 58 180 D.13 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 59 181 D.14 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 59 182 D.15 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 59 183 D.16 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 59 184 D.17 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 60 185 D.18 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 60 186 D.19 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 60 187 D.20 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 61 188 D.21 lc-04-standard-data-container . . . . . . . . . . . . . . . 61 189 D.22 lc-05-standard-data-container . . . . . . . . . . . . . . . 61 190 D.23 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 61 191 D.24 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 62 192 D.25 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 62 193 D.26 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 62 194 D.27 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 62 195 D.28 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 63 196 D.29 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 63 197 D.30 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 63 198 D.31 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 64 199 D.32 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 64 200 D.33 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 64 201 D.34 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 65 202 D.35 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 65 203 D.36 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 65 204 D.37 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 65 205 D.38 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 66 206 D.39 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 66 207 D.40 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 66 208 D.41 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 67 209 D.42 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 67 210 D.43 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 67 211 D.44 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 67 212 D.45 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 68 213 D.46 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 68 214 D.47 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 68 215 D.48 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 69 216 D.49 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 69 217 D.50 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 69 218 D.51 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 70 219 D.52 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 70 220 D.53 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 70 221 D.54 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 70 222 D.55 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 71 223 D.56 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 71 224 D.57 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 71 225 D.58 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 71 226 Intellectual Property and Copyright Statements . . . . . . . 72 228 1. Introduction 230 This is one of a pair of specifications that extend the WebDAV 231 Distributed Authoring Protocol to enable clients to create new access 232 paths to existing resources. This capability is useful for several 233 reasons: 235 URIs of WebDAV-compliant resources are hierarchical and correspond to 236 a hierarchy of collections in resource space. The WebDAV Distributed 237 Authoring Protocol makes it possible to organize these resources into 238 hierarchies, placing them into groupings, known as collections, which 239 are more easily browsed and manipulated than a single flat 240 collection. However, hierarchies require categorization decisions 241 that locate resources at a single location in the hierarchy, a 242 drawback when a resource has multiple valid categories. For example, 243 in a hierarchy of vehicle descriptions containing collections for 244 cars and boats, a description of a combination car/boat vehicle could 245 belong in either collection. Ideally, the description should be 246 accessible from both. Allowing clients to create new URIs that access 247 the existing resource lets them put that resource into multiple 248 collections. 250 Hierarchies also make resource sharing more difficult, since 251 resources that have utility across many collections are still forced 252 into a single collection. For example, the mathematics department at 253 one university might create a collection of information on fractals 254 that contains bindings to some local resources, but also provides 255 access to some resources at other universities. For many reasons, it 256 may be undesirable to make physical copies of the shared resources on 257 the local server: to conserve disk space, to respect copyright 258 constraints, or to make any changes in the shared resources visible 259 automatically. Being able to create new access paths to existing 260 resources in other collections or even on other servers is useful for 261 this sort of case. 263 The redirect reference resources defined here provide a mechanism for 264 creating alternative access paths to existing resources. A redirect 265 reference resource is a resource in one collection whose purpose is 266 to forward requests to another resource (its target), possibly in a 267 different collection. In this way, it allows clients to submit 268 requests to the target resource from another collection. It 269 redirects most requests to the target resource using the HTTP 302 270 (Found) status code, thereby providing a form of mediated access to 271 the target resource. 273 The companion specification [B], defines the BIND method, a different 274 mechanism for allowing clients to create alternative access paths to 275 existing WebDAV-compliant resources. The BIND method lets clients 276 associate a new URI with an existing WebDAV resource. This URI can 277 then be used to submit requests to the resource. Since URIs of 278 WebDAV-compliant resources are hierarchical, and correspond to a 279 hierarchy of collections in resource space, the BIND method also has 280 the effect of adding the resource to a collection. As new URIs are 281 associated with the resource, it appears in additional collections. 283 Redirect references and bindings have very different characteristics: 285 A redirect reference is a resource, and so can have properties and a 286 body of its own. Properties of a redirect reference resource can 287 contain such information as who created the reference, when, and why. 288 Since redirect reference resources are implemented using HTTP 302 289 responses, it generally takes two round trips to submit a request to 290 the intended resource. Servers are not required to enforce the 291 integrity of redirect references. Redirect references work equally 292 well for local resources and for resources that reside on a different 293 server from the reference. 295 By contrast, a BIND request does not create a new resource, but 296 simply makes available a new URI for submitting requests to an 297 existing resource. The new URI is indistinguishable from any other 298 URI when submitting a request to a resource. Only one round trip is 299 needed to submit a request to the intended target. Servers are 300 required to enforce the integrity of the relationships between the 301 new URIs and the resources associated with them. Consequently, it 302 may be very costly for servers to support BIND requests that cross 303 server boundaries. 305 The remainder of this document is structured as follows: Section 3 306 defines terms that will be used throughout the specification. 307 Section 4 provides an overview of redirect reference resources. 308 Section 5 discusses how to create a redirect reference resource. 309 Section 6 defines the semantics of existing methods when applied to 310 redirect reference resources, and Section 7 discusses their semantics 311 when applied to collections that contain redirect reference 312 resources. Sections 8 through 10 discuss several other issues raised 313 by the existence of redirect reference resources. Sections 11 314 through 14 define the new headers, properties, and XML elements 315 required to support redirect reference resources. Section 15 316 discusses capability discovery. Sections 16 through 18 present the 317 security, internationalization, and IANA concerns raised by this 318 specification. The remaining sections provide a variety of supporting 319 information. 321 2. Notational Conventions 323 Since this document describes a set of extensions to the WebDAV 324 Distributed Authoring Protocol [RFC2518], itself an extension to the 325 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 326 elements is exactly the same as described in Section 2.1 of 327 [RFC2616]. Since this augmented BNF uses the basic production rules 328 provided in Section 2.2 of [RFC2616], these rules apply to this 329 document as well. 331 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 332 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 333 document are to be interpreted as described in [RFC2119]. 335 3. Terminology 337 The terminology used here follows and extends that in the WebDAV 338 Distributed Authoring Protocol specification [RFC2518]. Definitions 339 of the terms resource, Uniform Resource Identifier (URI), and Uniform 340 Resource Locator (URL) are provided in [RFC2396]. 342 Reference Resource 344 A resource whose purpose is to forward requests to another 345 resource. Reference resources are an alternative mechanism to 346 bindings (defined in [B]) for allowing clients to create multiple 347 URIs that can be used to submit requests to the same resource. 349 Redirect Reference Resource 351 A resource that allows clients to forward requests to another 352 resource using the HTTP 1.1 302 (Found) response mechanism. The 353 client is aware that this type of reference resource is mediating 354 between it and the target resource. 356 Direct Reference Resource 358 Direct Reference Resources are out of scope for this 359 specification, but are defined here for contrast with redirect 360 reference resources. A direct reference resource automatically 361 forwards requests to another resource, in a way that is 362 transparent to the client. 364 Non-Reference Resource 366 A resource that is not a reference to another resource. 368 Target Resource 370 The resource to which requests are forwarded by a reference 371 resource. 373 4. Overview of Redirect Reference Resources 375 For all operations submitted to a redirect reference resource, the 376 default response is a 302 (Found), accompanied by the Redirect-Ref 377 header (defined in Section 11.1 below) and the Location header set to 378 the URI of the target resource. With this information, the client 379 can resubmit the request to the URI of the target resource. 381 A redirect reference resource never automatically forwards requests 382 to its target resource. It is this characteristic that distinguishes 383 redirect reference resource from direct reference resources and from 384 bindings. It is also what helps to insure that redirect reference 385 resources will be simple to implement and that cross-server 386 references will be possible. If the redirect reference resource were 387 required to forward requests automatically, the server would need 388 proxy capabilities in order to support cross-server references. 390 If the client is aware that it is operating on a redirect reference 391 resource, it can resolve the reference by retrieving the reference 392 resource's DAV:reftarget property (defined in Section 12.1 below), 393 whose value contains the URI of the target resource. It can then 394 submit requests to the target resource. 396 A redirect reference resource is a new type of resource. To 397 distinguish redirect reference resources from non-reference 398 resources, a new value of the DAV:resourcetype property (defined in 399 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below. 401 Since a redirect reference resource is a resource, it can have its 402 own properties and body, and methods can be applied to the reference 403 resource as well as to its target resource. The 404 Apply-To-Redirect-Ref request header (defined in Section 11.2 below) 405 is provided so that referencing-aware clients can control whether an 406 operation is applied to the redirect reference resource or to its 407 target resource. The Apply-To-Redirect-Ref header can be used with 408 most requests to redirect reference resources. This header is 409 particularly useful with PROPFIND, to retrieve the reference 410 resource's own properties. 412 5. Creating a Redirect Reference Resource 414 The MKRESOURCE method is used to create new redirect reference 415 resources. As defined in Section 5.1, MKRESOURCE can be used to 416 create a resource of any type other than standard data containers and 417 collections. In order to create a redirect reference resource using 418 MKRESOURCE, the values of two properties must be set in the body of 419 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to 420 DAV:redirectref, a new value of DAV:resourcetype defined in Section 421 13.1. The value of DAV:reftarget MUST be set to the URI of the target 422 resource. 424 Used in this way, the MKRESOURCE method creates a redirect reference 425 resource whose target is identified by the DAV:reftarget property. 427 5.1 MKRESOURCE 429 The MKRESOURCE method requests the creation of a resource and 430 initialization of its properties. It allows resources other than 431 standard data containers and collections to be created and their 432 properties initialized in one atomic operation. 434 Preconditions: 436 A resource MUST NOT exist at the Request-URI. 438 Request Marshalling: 440 The location of the new resource to be created is specified by the 441 Request-URI. 443 The request body of the MKRESOURCE method MUST consist of the 444 DAV:propertyupdate XML element defined in Section 12.13 of 445 [RFC2518]. 447 Postconditions: 449 If the response status code is 201, a new resource exists at the 450 Request-URI. 452 The body of the new resource is empty. 454 The properties of the new resource are as specified by the 455 DAV:propertyupdate request body, using PROPPATCH semantics. If the 456 DAV:propertyupdate does not specify a DAV:resourcetype, the 457 resource will be a standard data container. 459 If the response status code is not 201, then a new resource is not 460 created at the Request-URI, and any existing resource at the 461 Request-URI is unaffected. 463 Response Marshalling: 465 Responses from a MKRESOURCE request MUST NOT be cached, as 466 MKRESOURCE has non-idempotent semantics. 468 The following status codes can be expected in responses to 469 MKRESOURCE: 471 201 (Created): The new resource was successfully created. 473 207 (Multi-Status): This response is generated if an error was 474 encountered while initializing the properties of the resource, in 475 which case the response is as defined in Section 8.2.1 of 476 [RFC2518]. 478 403 (Forbidden): The server does not allow the creation of the 479 requested resource type at the requested location, or the parent 480 collection of the Request-URI exists but cannot accept members. 482 409 (Conflict): A resource cannot be created at the Request-URI 483 because the parent collection for the resource does not exist, or 484 because there is already a resource at that request-URL. 486 423 (Locked): The Request-URI is locked, and the lock token was 487 not passed with the request. 489 507 (Insufficient Storage): The server does not have sufficient 490 space to record the state of the resource. 492 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE 494 >> Request: 496 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 497 Host: www.ics.uci.edu 498 Content-Type: text/xml; charset="utf-8" 499 Content-Length: xxx 501 502 503 504 505 506 507 /i-d/draft-webdav-protocol-08.txt 508 509 510 511 513 >> Response: 515 HTTP/1.1 201 Created 517 This request resulted in the creation of a new redirect reference 518 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points 519 to the resource identified by the DAV:reftarget property. In this 520 example, the target resource is identified by the URI http:// 521 www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt. The redirect 522 reference resource's DAV:resourcetype property is set to 523 DAV:redirectref. 525 6. Operations on Redirect Reference Resources 527 Although non-referencing-aware clients cannot create reference 528 resources, they should be able to submit requests through the 529 reference resources created by reference-aware WebDAV clients. They 530 should be able to follow any references to their targets. To make 531 this possible, a server that receives any request made via a redirect 532 reference resource MUST return a 302 (Found) status code, unless the 533 request includes an Apply-To-Redirect-Ref header. The client and 534 server MUST follow [RFC2616] Section 10.3.3 "302 Found," but with 535 these additional rules: 537 o The Location response header MUST contain an absolute URI that 538 identifies the target of the reference resource. 540 o The response MUST include the Redirect-Ref header. This header 541 allows reference-aware WebDAV clients to recognize the resource as 542 a reference resource and understand the reason for the 543 redirection. 545 A reference-aware WebDAV client can act on this response in one of 546 two ways. It can, like a non-referencing client, resubmit the 547 request to the URI in the Location header in order to operate on the 548 target resource. Alternatively, it can resubmit the request to the 549 URI of the redirect reference resource with the Apply-To-Redirect-Ref 550 header in order to operate on the reference resource itself. If the 551 Apply-To-Redirect-Ref header is present, the request MUST be applied 552 to the reference resource itself, and a 302 response MUST NOT be 553 returned. 555 A reference-aware client may know before submitting its request that 556 the Request-URI identifies a redirect reference resource. In this 557 case, if the client wants to apply the method to the reference 558 resource, it can save the round trip caused by the 302 response by 559 using an Apply-To-Redirect-Ref header in its initial request to the 560 URI. 562 A few methods need additional explanation: 564 The Apply-To-Redirect-Ref header can be used with GET or HEAD to 565 retrieve the entity headers of a redirect reference resource. When 566 Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref 567 entity header MUST be returned. 569 A redirect reference resource MAY have a body, though none is defined 570 for it in this specification. The PUT method can be used, with 571 Apply-To-Redirect-Ref, to create or replace the body of a redirect 572 reference resource. 574 Since MKCOL and MKRESOURCE fail when applied to existing resources, 575 if the client attempts to resubmit the request to the target 576 resource, the request MUST fail (unless the reference resource is a 577 dangling reference). Similarly, if the client attempts to resubmit 578 the request to the reference resource with an Apply-To-Redirect-Ref 579 header, the request MUST fail. 581 6.1 Example: GET on a Redirect Reference Resource 583 >> Request: 585 GET /bar.html HTTP/1.1 586 Host: www.foo.com 588 >> Response: 590 HTTP/1.1 302 Found 591 Location: http://www.svr.com/Internet/xxspec08.html 592 Redirect-Ref: 594 Since /bar.html is a redirect reference resource and the 595 Apply-To-Redirect-Ref header is not included in the request, the 596 response is a 302 (Found). The Redirect-Ref header informs a 597 reference-aware client that this is not an ordinary HTTP 1.1 598 redirect, but is a redirect reference resource. The URI of the 599 target resource is provided in the Location header so that the client 600 can resubmit the request to the target resource. 602 6.2 Example: PUT on a Redirect Reference Resource with 603 Apply-To-Redirect-Ref 605 >> Request: 607 PUT /bar.html HTTP/1.1 608 Host: www.foo.com 609 Apply-To-Redirect-Ref: 610 Content-Type: text/xml; charset="utf-8" 611 Content-Length: xxxx 613 . . . some content . . . 615 >> Response: 617 HTTP/1.1 200 OK 619 Although /bar.html is a redirect reference resource, the presence of 620 the Apply-To-Redirect-Ref header prevents a 302 response, and instead 621 causes the request to be applied to the reference resource. The 622 result in this case is that the reference resource is replaced by a 623 non-reference resource having the content submitted with the request. 625 6.3 Example: PROPPATCH on a Redirect Reference Resource 627 >> Request: 629 PROPPATCH /bar.html HTTP/1.1 630 Host: www.foo.com 631 Content-Type: text/xml; charset="utf-8" 632 Content-Length: xxxx 634 635 637 638 639 640 Jim Whitehead 641 Roy Fielding 642 643 644 645 646 647 648 649 650 652 >> Response: 654 HTTP/1.1 302 Found 655 Location: http://www.svr.com/Internet/xxspec08.html 656 Redirect-Ref: 658 Since /bar.html is a redirect reference resource and the 659 Apply-To-Redirect-Ref header is not included in the request, the 660 response is a 302 (Found). The Redirect-Ref header informs a 661 reference-aware client that this is not an ordinary HTTP 1.1 662 redirect, but is a redirect reference resource. The URI of the 663 target resource is provided in the Location header so that the client 664 can resubmit the request to the target resource. 666 7. Operations on Collections That Contain Redirect Reference Resources 668 Consistent with the rules in Section 6, the response for each 669 redirect reference encountered while processing a collection MUST be 670 a 302 (Found) unless a Apply-To-Redirect-Ref header is included with 671 the request. The overall response will therefore be a 207 672 (Multi-Status). Since a Location header and Redirect-Ref header 673 cannot be returned for each redirect reference encountered, the same 674 information is provided using properties in the response elements for 675 those resources. The DAV:location pseudo-property and the 676 DAV:resourcetype property MUST be included with the 302 status code. 677 This necessitates an extension to the syntax of the DAV:response 678 element that was defined in [RFC2518]. The extension is defined in 679 Section 14 below. 681 A referencing-aware client can tell from the DAV:resourcetype 682 property that the collection contains a redirect reference resource. 683 The DAV:location pseudo-property contains the absolute URI of the 684 target resource. A referencing-aware client can either use the URI 685 value of the DAV:location pseudo-property to resubmit its request to 686 the target resource, or it can submit the request to the redirect 687 reference resource with Apply-To-Redirect-Ref. 689 It is recommended that future editors of [RFC2518] define the 690 DAV:location pseudo-property in [RFC2518], so that non-referencing 691 clients will also be able to use the response to operate on the 692 target resource. (This will also enable clients to operate on 693 traditional HTTP/1.1 302 responses in Multi-Status responses.) Until 694 then, non- referencing clients will not be able to process 302 695 responses from redirect reference resources encountered while 696 processing a collection. 698 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be 699 used with any request on a collection. If present, it will be 700 applied to all redirect reference resources encountered while 701 processing the collection. 703 7.1 MOVE and DELETE on Collections That Contain Redirect References 705 DELETE removes the binding that corresponds to the Request-URI. MOVE 706 removes that binding and creates a new binding to the same resource. 707 In cases where DELETE and MOVE are applied to a collection, these 708 operations affect all the descendents of the collection, but they do 709 so indirectly. There is no need to visit each descendent in order to 710 process the request. Consequently, even if there are redirect 711 reference resources in a tree that is being deleted or moved, there 712 will be no 302 responses from the redirect reference resources. 714 7.2 LOCK on a Collection That Contains Redirect References 716 LOCK poses special problems because it is atomic. An attempt to lock 717 (with Depth: infinity) a collection that contains redirect references 718 will always fail. The Multi-Status response will contain a 302 719 response for each redirect reference. 721 Reference-aware clients can lock the collection by using 722 Apply-To-Redirect-Ref, and, if desired, lock the targets of the 723 redirect references individually. 725 Non-referencing clients must resort to locking each resource 726 individually. 728 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources 730 Suppose a PROPFIND request with Depth: infinity is submitted to the 731 following collection, with the members shown here: 733 http://www.svr.com/MyCollection/ 734 (non-reference resource) diary.html 735 (redirect reference resource) nunavut 737 >> Request: 739 PROPFIND /MyCollection/ HTTP/1.1 740 Host: www.svr.com 741 Depth: infinity 742 Content-Type: text/xml 743 Content-Length: xxxx 745 746 747 748 749 750 751 753 >> Response: 755 HTTP/1.1 207 Multi-Status 756 Content-Type: text/xml 757 Content-Length: xxxx 759 760 761 762 http://www.svr.com/MyCollection/ 763 764 765 766 diary, interests, hobbies 767 768 HTTP/1.1 200 OK 769 770 771 772 http://www.svr.com/MyCollection/diary.html 773 774 775 776 diary, travel, family, history 777 778 HTTP/1.1 200 OK 779 780 781 782 http://www.svr.com/MyCollection/nunavut 783 HTTP/1.1 302 Found 784 785 786 http://www.inac.gc.ca/art/inuit/ 787 788 789 790 791 793 In this example the Depth header is set to infinity, and the 794 Apply-To-Redirect-Ref header is not used. The collection contains 795 one URI that identifies a redirect reference resource. The response 796 element for the redirect reference resource has a status of 302 797 (Found), and includes a DAV:prop element with the DAV:location 798 pseudo-property and the DAV:resourcetype property to allow clients to 799 retrieve the properties of its target resource. (The response 800 element for the redirect reference resource does not include the 801 requested properties. The client can submit another PROPFIND request 802 to the URI in the DAV:location pseudo-property to retrieve those 803 properties.) 805 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 806 Redirect Reference Resources 808 Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth = 809 infinity is submitted to the following collection, with the members 810 shown here: 812 /MyCollection/ 813 (non-reference resource) diary.html 814 (redirect reference resource) nunavut 816 >> Request: 818 PROPFIND /MyCollection/ HTTP/1.1 819 Host: www.svr.com 820 Depth: infinity 821 Apply-To-Redirect-Ref: 822 Content-Type: text/xml 823 Content-Length: xxxx 825 826 827 828 829 830 831 833 >> Response: 835 HTTP/1.1 207 Multi-Status 836 Content-Type: text/xml 837 Content-Length: xxxx 839 840 841 842 http://www.svr.com/MyCollection/ 843 844 845 846 847 HTTP/1.1 200 OK 848 849 850 851 HTTP/1.1 404 Not Found 852 853 854 855 http://www.svr.com/MyCollection/diary.html 856 857 858 859 860 HTTP/1.1 200 OK 861 862 863 864 HTTP/1.1 404 Not Found 865 866 867 868 http://www.svr.com/MyCollection/nunavut 869 870 871 872 873 http://www.inac.gc.ca/art/inuit/ 874 875 876 HTTP/1.1 200 OK 877 878 879 881 Since the Apply-To-Redirect-Ref header is present, the response shows 882 the properties of the redirect reference resource in the collection 883 rather than the properties of its target. The Apply-To-Redirect-Ref 884 header also prevents a 302 response from being returned for the 885 redirect reference resource. 887 7.5 Example: COPY on a Collection That Contains a Redirect Reference 888 Resource 890 Suppose a COPY request is submitted to the following collection, with 891 the members shown: 893 /MyCollection/ 894 (non-reference resource) diary.html 895 (redirect reference resource) nunavut with target 896 /Someplace/nunavut.map 898 >> Request: 900 COPY /MyCollection/ HTTP/1.1 901 Host: www.svr.com 902 Depth: infinity 903 Destination: http://www.svr.com/OtherCollection/ 904 >> Response: 906 HTTP/1.1 207 Multi-Status 907 Content-Type: text/xml; charset="utf-8" 908 Content-Length: xxx 910 911 912 913 http://www.svr.com/MyCollection/nunavut 914 HTTP/1.1 302 Found 915 916 917 http://www.svr.com//Someplace/nunavut.map 918 919 920 921 922 924 In this case, since /MyCollection/nunavut is a redirect reference 925 resource, the COPY operation was only a partial success. The 926 redirect reference resource was not copied, but a 302 response was 927 returned for it. So the resulting collection is as follows: 929 /OtherCollection/ 930 (non-reference resource) diary.html 932 7.6 Example: LOCK on a Collection That Contains a Redirect Reference 933 Resource 935 Suppose a LOCK request is submitted to the following collection, with 936 the members shown: 938 /MyCollection/ 939 (non-reference resource) diary.html 940 (redirect reference resource) nunavut 942 >> Request: 944 LOCK /MyCollection/ HTTP/1.1 945 Host: www.svr.com 946 Content-Type: text/xml 947 Content-Length: nnnn 948 Authorizaton: Digest username="jas", 949 realm=jas@webdav.sb.aol.com, nonce=". . . ", 950 uri="/MyCollection/tuva", 951 response=". . . ", opaque=". . . " 953 954 955 956 957 958 http://www.svr.com/~jas/contact.html 959 960 962 >> Response: 964 HTTP/1.1 207 Multi-Status 965 Content-Type: text/xml 966 Content-Length: nnnn 968 969 970 971 http://www.svr.com/MyCollection/ 972 973 974 HTTP/1.1 424 Failed Dependency 975 976 977 978 http://www.svr.com/MyCollection/diary.html 979 HTTP/1.1 424 Failed Dependency 980 981 982 http://www.svr.com/MyCollection/nunavut 983 HTTP/1.1 302 Found 984 985 986 http://www.inac.gc.ca/art/inuit/ 987 988 989 990 991 993 The server returns a 302 response code for the redirect reference 994 resource in the collection. Consequently, neither the collection nor 995 any of the resources identified by its internal member URIs were 996 locked. A referencing-aware client can submit a separate LOCK request 997 to the URI in the DAV:location pseudo-property returned for the 998 redirect reference resource, and can resubmit the LOCK request with 999 the Apply-To-Redirect-Ref header to the collection. At that point 1000 both the reference resource and its target resource will be locked 1001 (as well as the collection and all the resources identified by its 1002 other members). 1004 8. Operations on Targets of Redirect Reference Resources 1006 Operations on targets of redirect reference resources have no effect 1007 on the reference resource. 1009 9. Relative URIs in DAV:reftarget 1011 The URI in the href in a DAV:reftarget property MAY be a relative 1012 URI. In this case, the base URI to be used for resolving the relative 1013 URI to absolute form is the URI used in the HTTP message to identify 1014 the redirect reference resource to which the DAV:reftarget property 1015 belongs. 1017 When DAV:reftarget occurs in the body of a MKRESOURCE request, the 1018 base URI is constructed as follows: Its scheme component is "http", 1019 its authority component is the value of the Host header in the 1020 request, and its path component is the Request-URI in the request. 1021 See Section 5 of [RFC2396] for a discussion of relative URI 1022 references and how to resolve them. 1024 When DAV:reftarget appears in the context of a Multi-Status response, 1025 it is in a DAV:response element that contains a single DAV:href 1026 element. The value of this DAV:href element serves as the base URI 1027 for resolving a relative URI in DAV:reftarget. The value of DAV:href 1028 may itself be relative, in which case it must be resolved first in 1029 order to serve as the base URI for the relative URI in DAV:reftarget. 1030 If the DAV:href element is relative, its base URI is constructed from 1031 the scheme component "http", the value of the Host header in the 1032 request, and the request-URI. 1034 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request 1036 >> Request: 1038 MKRESOURCE /north/inuvik HTTP/1.1 1039 Host: www.somehost.edu 1040 Content-Type: text/xml; charset="utf-8" 1041 Content-Length: xxx 1043 1044 1045 1046 1047 1048 1049 mapcollection/inuvik.gif 1050 1051 1052 1053 1055 >> Response: 1057 HTTP/1.1 201 Created 1059 In this example, the base URI is http://www.somehost.edu/north/ 1060 inuvik. Then, following the rules in [RFC2396] Section 5, the 1061 relative URI in DAV:reftarget resolves to the absolute URI http:// 1062 www.somehost.edu/north/mapcollection/inuvik.gif. 1064 9.2 Example: Resolving a Relative URI in a Multi-Status Response 1066 >> Request: 1068 PROPFIND /geog/ HTTP/1.1 1069 Host: www.xxsvr.com 1070 Apply-To-Redirect-Ref: 1071 Depth: 1 1072 Content-Type: text/xml 1073 Content-Length: nnn 1075 1076 1077 1078 1079 1080 1081 1083 >> Response: 1085 HTTP/1.1 207 Multi-Status 1086 Content-Type: text/xml 1087 Content-Length: nnn 1089 1090 1091 1092 /geog/ 1093 1094 1095 1096 1097 HTTP/1.1 200 OK 1098 1099 1100 1101 HTTP/1.1 404 Not Found 1102 1103 1104 1105 /geog/stats.html 1106 1107 1108 1109 1110 statistics/population/1997.html 1111 1112 1113 HTTP/1.1 200 OK 1114 1115 1116 1118 In this example, the relative URI statistics/population/1997.html is 1119 returned as the value of reftarget for the reference resource 1120 identified by href /geog/stats.html. The href is itself a relative 1121 URI, which resolves to http://www.xxsrv.com/geog/stats.html. This is 1122 the base URI for resolving the relative URI in reftarget. The 1123 absolute URI of reftarget is http://www.xxsrv.com/geog/statistics/ 1124 population/1997.html. 1126 10. Redirect References to Collections 1128 In a Request-URI /segment1/segment2/segment3, any of the three 1129 segments may identify a redirect reference resource. (See [RFC2396], 1130 Section 3.3, for definitions of "path" and "segment".) If any 1131 segment in a Request- URI identifies a redirect reference resource, 1132 the response is a 302. The value of the Location header in the 302 1133 response is as follows: 1135 The leftmost path segment of the request-URI that identifies a 1136 redirect reference resource, together with all path segments and 1137 separators to the left of it, is replaced by the value of the 1138 redirect reference resource's DAV:reftarget property (resolved to an 1139 absolute URI). The remainder of the request-URI is concatenated to 1140 this path. 1142 Note: If the DAV:reftarget property ends with a "/" and the remainder 1143 of the Request-URI is non-empty (and therefore must begin with a "/ 1144 "), the final "/" in the DAV:reftarget property is dropped before the 1145 remainder of the Request-URI is appended. 1147 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 1148 reference resource whose target resource is collection /a/, which 1149 contains redirect reference resource y whose target resource is 1150 collection /b/, which contains redirect reference resource z.html 1151 whose target resource is /c/d.html. 1153 /x/y/z.html 1154 | 1155 | /x -> /a 1156 | 1157 v 1158 /a/y/z.html 1159 | 1160 | /a/y -> /b 1161 | 1162 v 1163 /b/z.html 1164 | 1165 | /b/z.html -> /c/d.html 1166 | 1167 v 1168 /c/d.html 1170 In this case the client must follow up three separate 302 responses 1171 before finally reaching the target resource. The server responds to 1172 the initial request with a 302 with Location: /a/y/z.html, and the 1173 client resubmits the request to /a/y/z.html. The server responds to 1174 this request with a 302 with Location: /b/z.html, and the client 1175 resubmits the request to /b/z.html. The server responds to this 1176 request with a 302 with Location: /c/d.html, and the client resubmits 1177 the request to /c/d.html. This final request succeeds. 1179 11. Headers 1181 11.1 Redirect-Ref Response Header 1183 Redirect-Ref = "Redirect-Ref:" 1185 The Redirect-Ref header is used in all 302 responses from redirect 1186 reference resources. Its presence informs reference-aware clients 1187 that the response is not a plain HTTP/1.1 redirect, but is a response 1188 from a redirect reference resource. 1190 11.2 Apply-To-Redirect-Ref Request Header 1192 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" 1194 The optional Apply-To-Redirect-Ref header can be used on any request 1195 to a redirect reference resource. When it is used, the request MUST 1196 be applied to the reference resource itself, and a 302 response MUST 1197 NOT be returned. 1199 If the Apply-To-Redirect-Ref header is used on a request to any other 1200 sort of resource besides a redirect reference resource, the server 1201 SHOULD ignore it. 1203 12. Properties 1205 12.1 reftarget Property 1207 Name: reftarget 1209 Namespace: DAV: 1211 Purpose: A property of redirect reference resources that provides an 1212 efficient way for clients to discover the URI of the target 1213 resource. This is a read-only property after its initial 1214 creation. Its value can only be set in a MKRESOURCE request. 1216 Value: href containing the URI of the target resource. This value 1217 MAY be a relative URI. The reftarget property can occur in the 1218 entity bodies of MKRESOURCE requests and of responses to PROPFIND 1219 requests. 1221 1223 12.2 location Pseudo-Property 1225 Name: location 1227 Namespace: DAV: 1229 Purpose: For use with 302 (Found) response codes in Multi-Status 1230 responses. It contains the absolute URI of the temporary location 1231 of the resource. In the context of redirect reference resources, 1232 this value is the absolute URI of the target resource. It is 1233 analogous to the Location header in HTTP 302 responses defined in 1234 [RFC2616] Section 10.3.3 "302 Found." Including the location 1235 pseudo-property in a Multi- Status response requires an extension 1236 to the syntax of the DAV:response element defined in [RFC2518], 1237 which is defined in Section 14 below. This pseudo-property is not 1238 expected to be stored on the reference resource. It is modeled as 1239 a property only so that it can be returned inside a DAV:prop 1240 element in a Multi-Status response. 1242 Value: href containing the absolute URI of the target resource. 1244 1246 13. XML Elements 1248 13.1 redirectref XML Element 1250 Name: redirectref 1252 Namespace: DAV: 1254 Purpose: Used as the value of the DAV:resourcetype property to 1255 specify that the resource type is a redirect reference resource. 1257 1259 14. Extensions to the DAV:response XML Element for Multi-Status 1260 Responses 1262 As described in Section 7, the DAV:location pseudo-property and the 1263 DAV:resourcetype property may be returned in the DAV:response element 1264 of a 207 Multi-Status response, to allow clients to resubmit their 1265 requests to the target resource of a redirect reference resource. 1267 Whenever these properties are included in a Multi-Status response, 1268 they are placed in a DAV:prop element associated with the href to 1269 which they apply. This structure provides a framework for future 1270 extensions by other standards that may need to include additional 1271 properties in their responses. 1273 Consequently, the definition of the DAV:response XML element changes 1274 to the following: 1276 1279 15. Capability Discovery 1281 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 1282 classes with the DAV header in responses to OPTIONS, to indicate 1283 which parts of the WebDAV Distributed Authoring protocols the 1284 resource supports. This specification defines an OPTIONAL extension 1285 to [RFC2518]. It defines a new compliance class, called 1286 redirectrefs, for use with the DAV header in responses to OPTIONS 1287 requests. If a resource does support redirect references, its 1288 response to an OPTIONS request may indicate that it does, by listing 1289 the new redirectrefs compliance class in the DAV headerand by listing 1290 the MKRESOURCE method as one it supports. 1292 When responding to an OPTIONS request, any type of resource can 1293 include redirectrefs in the value of the DAV header. Doing so 1294 indicates that the server permits a redirect reference resource at 1295 the request URI. 1297 15.1 Example: Discovery of Support for Redirect Reference Resources 1299 >> Request: 1301 OPTIONS /somecollection/someresource HTTP/1.1 1302 HOST: somehost.org 1304 >> Response: 1306 HTTP/1.1 200 OK 1307 Date: Tue, 20 Jan 1998 20:52:29 GMT 1308 Connection: close 1309 Accept-Ranges: none 1310 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, 1311 MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE 1312 DAV: 1, 2, redirectrefs 1314 The DAV header in the response indicates that the resource / 1315 somecollection/someresource is level 1 and level 2 compliant, as 1316 defined in [RFC2518]. In addition, /somecollection/someresource 1317 supports redirect reference resources. The Allow header indicates 1318 that MKRESOURCE requests can be submitted to /somecollection/ 1319 someresource. The Public header shows that other Request-URIs on the 1320 server support additional methods. 1322 16. Security Considerations 1324 This section is provided to make applications that implement this 1325 protocol aware of the security implications of this protocol. 1327 All of the security considerations of HTTP/1.1 and the WebDAV 1328 Distributed Authoring Protocol specification also apply to this 1329 protocol specification. In addition, redirect reference resources 1330 introduce several new security concerns and increase the risk of some 1331 existing threats. These issues are detailed below. 1333 16.1 Privacy Concerns 1335 By creating redirect reference resources on a trusted server, it is 1336 possible for a hostile agent to induce users to send private 1337 information to a target on a different server. This risk is 1338 mitigated somewhat, since clients are required to notify the user of 1339 the redirection for any request other than GET or HEAD. (See 1340 [RFC2616], Section 10.3.3 302 Found.) 1342 16.2 Redirect Loops 1344 Although redirect loops were already possible in HTTP 1.1, the 1345 introduction of the MKRESOURCE method creates a new avenue for 1346 clients to create loops accidentally or maliciously. If the 1347 reference resource and its target are on the same server, the server 1348 may be able to detect MKRESOURCE requests that would create loops. 1349 See also [RFC2616], Section 10.3 "Redirection 3xx." 1351 16.3 Redirect Reference Resources and Denial of Service 1353 Denial of service attacks were already possible by posting URLs that 1354 were intended for limited use at heavily used Web sites. The 1355 introduction of MKRESOURCE creates a new avenue for similar denial of 1356 service attacks. Clients can now create redirect reference resources 1357 at heavily used sites to target locations that were not designed for 1358 heavy usage. 1360 16.4 Revealing Private Locations 1362 There are several ways that redirect reference resources may reveal 1363 information about directory structures. First, the DAV:reftarget 1364 property of every redirect reference resource contains the URI of the 1365 target resource. Anyone who has access to the reference resource can 1366 discover the directory path that leads to the target resource. The 1367 owner of the target resource may have wanted to limit knowledge of 1368 this directory structure. 1370 Sufficiently powerful access control mechanisms can control this risk 1371 to some extent. Property-level access control could prevent users 1372 from examining the DAV:reftarget property. (The Location header 1373 returned in responses to requests on redirect reference resources 1374 reveals the same information, however.) In some environments, the 1375 owner of a resource might be able to use access control to prevent 1376 others from creating references to that resource. 1378 This risk is no greater than the similar risk posed by HTML links. 1380 17. Internationalization Considerations 1382 This specification follows the practices of [RFC2518] in encoding all 1383 human-readable content using XML [XML] and in the treatment of names. 1384 Consequently, this specification complies with the IETF Character Set 1385 Policy [RFC2277]. 1387 WebDAV applications MUST support the character set tagging, character 1388 set encoding, and the language tagging functionality of the XML 1389 specification. This constraint ensures that the human-readable 1390 content of this specification complies with [RFC2277]. 1392 As in [RFC2518], names in this specification fall into three 1393 categories: names of protocol elements such as methods and headers, 1394 names of XML elements, and names of properties. Naming of protocol 1395 elements follows the precedent of HTTP, using English names encoded 1396 in USASCII for methods and headers. The names of XML elements used 1397 in this specification are English names encoded in UTF-8. 1399 For error reporting, [RFC2518] follows the convention of HTTP/1.1 1400 status codes, including with each status code a short, English 1401 description of the code (e.g., 423 Locked). Internationalized 1402 applications will ignore this message, and display an appropriate 1403 message in the user's language and character set. 1405 This specification introduces no new strings that are displayed to 1406 users as part of normal, error-free operation of the protocol. 1408 For rationales for these decisions and advice for application 1409 implementors, see [RFC2518]. 1411 18. IANA Considerations 1413 This document uses the namespaces defined by [RFC2518] for properties 1414 and XML elements. All other IANA considerations mentioned in 1415 [RFC2518] also apply to this document. 1417 19. Acknowledgements 1419 This draft has benefited from thoughtful discussion by Jim Amsden, 1420 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1421 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1422 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, 1423 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel 1424 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1425 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1426 John Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1428 Normative References 1430 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1431 Languages", BCP 18, RFC 2277, January 1998. 1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, March 1997. 1436 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1437 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1438 August 1998. 1440 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1441 Jensen, "HTTP Extensions for Distributed Authoring -- 1442 WEBDAV", RFC 2518, February 1999. 1444 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1445 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1446 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1448 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1449 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C 1450 REC-xml, October 2000, . 1453 Informative References 1455 [B] Clemm, G., Crawford, J., Reschke, J., Slein, J. and J. 1456 Whitehead, "Binding Extensions to WebDAV", Internet Draft (work 1457 in progress) draft-ietf-webdav-bind-02, June 2003. 1459 URIs 1461 [1] 1463 [2] 1465 [3] 1468 [4] 1471 [5] 1474 [6] 1477 [7] 1480 [8] 1483 [9] 1486 [10] 1489 [11] 1492 [12] 1495 [13] 1498 [14] 1501 [15] 1504 [16] 1507 [17] 1510 [18] 1513 [19] 1516 [20] 1519 [21] 1522 [22] 1525 [23] 1528 [24] 1531 [25] 1534 [26] 1537 [27] 1540 [28] 1543 [29] 1546 [30] 1549 [31] 1552 [32] 1555 [33] 1558 [34] 1561 [35] 1564 [36] 1567 [37] 1570 [38] 1573 [39] 1576 [40] 1579 [41] 1582 [42] 1585 [43] 1588 [44] 1591 [45] 1594 [46] 1597 [47] 1600 [48] 1603 [49] 1606 [50] 1609 [51] 1612 [52] 1615 [53] 1618 [54] 1621 [55] 1624 [56] 1627 [57] 1630 [58] 1633 [59] 1636 [60] 1639 [61] 1642 [62] 1645 [63] 1648 [64] 1651 [65] 1654 [66] 1657 [67] 1660 [68] 1663 [69] 1666 [70] 1669 [71] 1672 [72] 1675 [73] 1678 [74] 1681 [75] 1684 [76] 1687 [77] 1690 [78] 1693 [79] 1696 [80] 1699 [81] 1702 [82] 1705 [83] 1708 [84] 1711 [85] 1714 [86] 1717 [87] 1720 Authors' Addresses 1722 J. Slein 1723 Xerox Corporation 1724 800 Phillips Road, 105-50C 1725 Webster, NY 14580 1727 EMail: jslein@crt.xerox.com 1729 Jim Whitehead 1730 UC Santa Cruz, Dept. of Computer Science 1731 1156 High Street 1732 Santa Cruz, CA 95064 1733 US 1735 EMail: ejw@cse.ucsc.edu 1737 J. Davis 1738 CourseNet Systems 1739 170 Capp Street 1740 San Francisco, CA 94110 1742 EMail: jrd3@alum.mit.edu 1743 G. Clemm 1744 Rational Software Corporation 1745 20 Maguire Road 1746 Lexington, MA 02173-3104 1748 EMail: geoffrey.clemm@us.ibm.com 1750 C. Fay 1751 FileNet Corporation 1752 3565 Harbor Boulevard 1753 Costa Mesa, CA 92626-1420 1755 EMail: cfay@filenet.com 1757 J. Crawford 1758 IBM Research 1759 P.O. Box 704 1760 Yorktown Heights, NY 10598 1762 EMail: ccjason@us.ibm.com 1764 Julian F. Reschke (editor) 1765 greenbytes GmbH 1766 Salzmannstrasse 152 1767 Muenster, NW 48159 1768 Germany 1770 Phone: +49 251 2807760 1771 Fax: +49 251 2807761 1772 EMail: julian.reschke@greenbytes.de 1773 URI: http://greenbytes.de/tech/webdav/ 1775 Appendix A. Changes to the WebDAV Document Type Definition 1777 1778 1779 Property Elements from Section 12 --> 1780 1781 1782 1783 1786 Appendix B. Change Log 1788 B.1 Since draft-ietf-webdav-redirectref-protocol-02 1790 Julian Reschke takes editorial role (added to authors list). Cleanup 1791 XML indentation. Start adding all unresolved last call issues. Update 1792 some author's contact information. Update references, split into 1793 "normative" and "informational". Remove non-RFC2616 headers 1794 ("Public") from examples. Fixed width problems in artwork. Start 1795 resolving editorial issues. 1797 Appendix C. Resolved issues 1799 Issues that were either rejected or resolved in this version of this 1800 document. 1802 C.1 lc-11-pagination 1804 Type: change 1806 [3] 1808 reuterj@ira.uka.de (2000-02-07): Don't paginate the review draft. 1810 Resolution: We will paginate in accordance with IETF rules, but will 1811 try to produce a nicely formatted review spec as well. 1813 C.2 lc-09-notational-after-introduction 1815 Type: change 1817 [4] 1819 reuterj@ira.uka.de (2000-02-07): Move Notational Conventions after 1820 Introduction. 1822 Resolution: Section will be moved. 1824 C.3 lc-13-usually 1826 Type: change 1828 [5] 1830 reuterj@ira.uka.de (2000-02-07): Intro, para 4: Change "usually" to 1831 "possibly" in the sentence "A redirect reference resource is a 1832 resource in one collection whose purpose is to forward requests to 1833 another resource (its target), usually in a different collection." 1835 Resolution: Agreed. 1837 C.4 lc-16-insure 1839 Type: change 1841 [6] 1843 reuterj@ira.uka.de (2000-02-07): Section 4, para 2: Change "It is 1844 also what insures" to "It is also what helps to insure". 1846 Resolution: Agreed. 1848 C.5 lc-17-location 1850 Type: change 1852 [7] 1854 reuterj@ira.uka.de (2000-02-07): Section 4, para 3: Clients should 1855 use the Location header, not the DAV:reftarget property, to find the 1856 location of the target. The purpose of the DAV:reftarget property 1857 should be to let the client update its value. 1859 Resolution: We need both Location (which is absolute) and target 1860 (which may be relative). See also issue 6, 43. 1862 C.6 lc-21-bind 1864 Type: change 1866 [8] 1868 reuterj@ira.uka.de (2000-02-07): Get rid of the binding-dependent 1869 language in the last para of Section 5. 1871 Resolution: Delete all but the first sentence in this paragraph. 1873 C.7 lc-46-bind 1875 Type: change 1877 [9] 1879 yarong@Exchange.Microsoft.com (2000-02-11): Remove dependency on 1880 bindings from second paragraph of section 5. 1882 Resolution: Agreed. 1884 C.8 lc-26-lang 1886 Type: edit 1888 [10] 1890 reuterj@ira.uka.de (2000-02-07): Change "is not created" to "was not 1891 created" in para 4 under Postconditions of MKRESOURCE. 1893 Resolution: Editor's discretion. 1895 C.9 lc-03-mkresource-response-cacheability 1897 Type: change 1899 [11] 1901 joe@orton.demon.co.uk (2000-01-26): Saying that responses to 1902 MKRESOURCE SHOULD NOT be cached suggests that there are sometimes 1903 good reasons to cache responses. Is this the case? 1905 Resolution: Responses to MKREF MUST NOT be cached. 1907 C.10 lc-02-status-codes 1909 Type: change 1911 [12] 1913 joe@orton.demon.co.uk (2000-01-29): List only new status codes for 1914 MKRESOURCE. Don't discuss previously-defined status codes. 1916 Resolution: Follow same practice as in binding spec: for existing 1917 status codes, describe new circumstances that might cause them. Make 1918 it clear that we are not redefining these codes. 1920 C.11 lc-27-lang 1922 Type: edit 1924 [13] 1926 reuterj@ira.uka.de (2000-02-07): Section 6: Change 1927 "non-referencing-aware clients" to "clients not aware of this 1928 protocol". 1930 Resolution: Editor's discretion. 1932 C.12 lc-30-headers 1934 Type: edit 1936 [14] 1938 reuterj@ira.uka.de (2000-02-07): Section 6, "When Apply-To-RR is used 1939 with GET or HEAD..." Either give a precise list of the headers that 1940 MUST be returned, or change MUST to SHOULD with the list of examples. 1942 Resolution: Delete "along with all HTTP headers that make sense for 1943 reference resources (for example, Cache-Control, Age, Etag, Expires, 1944 and Last-Modified)." See also issue 48. 1946 C.13 lc-32-ORDERPATCH 1948 Type: edit 1950 [15] 1952 reuterj@ira.uka.de (2000-02-07): Section 6. Don't talk about 1953 ORDERPATCH, since it hasn't been specified anywhere. 1955 Resolution: Agreed. See also issue 48. 1957 C.14 lc-51-repeat 1959 Type: change 1961 [16] 1963 yarong@Exchange.Microsoft.com (2000-02-11): The first sentence of 1964 this paragraph says only what's clear from RFC 2518, so will cause 1965 confusion by its presence. Delete it. The last sentence of this 1966 paragraph lists methods. That's a bad idea. Remove it. 1968 Resolution: Delete entire paragraph. 1970 C.15 lc-59-depth 1972 Type: change 1974 [17] 1976 reuterj@ira.uka.de (2000-02-14): Section 7: When a method is being 1977 applied to a collection with Depth > 0, let Apply-To-Redirect-Ref 1978 contain a list of URIs. This way you could have it apply to some 1979 subset of the redirect references in the collection. 1981 Resolution: Declined. Too complex, no use case for it. 1983 C.16 lc-65-lock 1985 Type: change 1987 [18] 1989 reuterj@ira.uka.de (2000-02-14): "In the case of a redirect reference 1990 resource, I think the intended meaning of WebDAV is that the resource 1991 itself is the internal member to be locked, not the target resource. 1992 In so far, I think, the Apply-To-Redirect-Ref header should 1993 implicitly always be set, and a LOCK request for a collection MUST 1994 fail if in the hierarchy of collections there is an ordinary redirect 1995 reference as internal member." 1997 Resolution: Declined. Behavior will be the same for all methods. No 1998 exceptions. Consistency / simplicity override other considerations 2000 C.17 lc-66-depth 2002 Type: change 2004 [19] 2006 reuterj@ira.uka.de (2000-02-14): 7.3, 7.4: Change "Depth=infinity" to 2007 "Depth: infinity". 2009 Resolution: Agreed. 2011 C.18 lc-69-424 2013 Type: change 2015 [20] 2017 reuterj@ira.uka.de (2000-02-14): 7.6: Thinks there should not be 424 2018 returned for diary.html because it is not an ancestor of a member 2019 that caused the lock to fail. 2021 Resolution: No change needed. The interpretation of "dependency" in 2022 the example is correct. It doesn't have to do with ancestor 2023 relationship, only with what caused operation to fail. 2025 C.19 lc-68-lock 2027 Type: change 2029 [21] 2031 reuterj@ira.uka.de (2000-02-14): 7.6: The LOCK example responds with 2032 207, as does the example in RFC 2518, but section 8.10.4 of RFC 2518 2033 says if the lock cannot be granted to all resources the response MUST 2034 be 409 conflict. 2036 Resolution: We'll keep 207 and encourage RFC 2518 to say the same. 2037 (This inconsistency in RFC 2518 is on the WebDAV issues list.) 2039 C.20 lc-52-no-relative 2041 Type: change 2043 [22] 2045 yarong@Exchange.Microsoft.com (2000-02-11): Don't allow relative 2046 URIs. Delete section 9. 2048 Resolution: Declined. Some applications need relative URI. 2050 C.21 lc-64-reftarget 2052 Type: change 2054 [23] 2056 reuterj@ira.uka.de (2000-02-14): Perhaps make DAV:location a real 2057 property, instead of DAV:reftarget, and require it to be an absolute 2058 URI. 2060 Resolution: Declined. Some applications need relative URI. See also 2061 issue 52. 2063 C.22 lc-70-relative 2065 Type: change 2067 [24] 2069 reuterj@ira.uka.de (2000-02-14): Section 9, para 1: Maybe say that 2070 the resulting absolute URI could be any of a number of URIs, 2071 depending on which URI is used in the request to identify the 2072 redirect reference. 2074 Resolution: No change needed. 2076 C.23 lc-73-asciiart 2078 Type: change 2080 [25] 2082 reuterj@ira.uka.de (2000-02-14): Section 10: Replace the ascii art 2083 with Juergen's suggestion (see his message). 2085 Resolution: Replace. 2087 C.24 lc-77-webdav-applications 2089 Type: change 2091 [26] 2093 reuterj@ira.uka.de (2000-02-22): Section 16: Change "WebDAV 2094 applications" to "applications that implement this protocol". 2096 C.25 lc-10-title 2098 Type: change 2100 [27] 2102 reuterj@ira.uka.de (2000-02-07): Change the title of 16.4 so that it 2103 is not a sentence. 2105 Resolution: Change to "Revealing Private Locations". 2107 C.26 lc-81-typo 2109 Type: change 2111 [28] 2113 reuterj@ira.uka.de (2000-02-22): Section 17: Typo "As in [WebDAV}" 2115 Resolution: Fixed. 2117 C.27 lc-18-resource-types 2119 Type: change 2121 [29] 2123 reuterj@ira.uka.de (2000-02-07): Need a registration procedure for 2124 resource types to insure interoperability. 2126 Resolution: We won't hold up this spec to establish a registration 2127 procedure. We will mention in IANA considerations that as the number 2128 of resource types grows the need for a registration procedure 2129 increases, but that there is none at this time. 2131 C.28 lc-84-ext 2133 Type: change 2135 [30] 2137 reuterj@ira.uka.de (2000-02-22): Appendix 24.1: This is not an 2138 extension but a replacement for the WebDAV definition of the response 2139 element. 2141 Resolution: Fixed. 2143 Appendix D. Open issues 2145 D.1 lc-85-301 2147 Type: change 2149 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302 2150 redirects, especially 301. 2152 D.2 lc-07-bind 2154 Type: change 2156 [31] 2158 reuterj@ira.uka.de (2000-02-07): Abstract should discuss only 2159 redirect references, not bindings. Expand discussion of redirect 2160 references. 2162 Resolution: Abstract will discuss only redirect references. See also 2163 issue 34. 2165 D.3 lc-08-bind 2167 Type: change 2169 [32] 2171 reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the 2172 binding spec: in the abstract, in the introduction, in the definition 2173 of Reference Resource. 2175 Resolution: Cross-references to bindings will be removed. See also 2176 issue 34. 2178 D.4 lc-34-bind 2180 Type: change 2182 [33] 2184 yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all 2185 cross-references to the binding spec. Prefer also removing all 2186 mention of bindings. 2188 Resolution: Agreed. See also issues 7, 8, 14 2190 D.5 lc-35-bind 2192 Type: change 2194 [34] 2196 yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove 2197 paras. 6 and 8 from Intro. 2199 Resolution: Agreed. See also issue 14. 2201 D.6 lc-83-bind 2203 Type: change 2205 [35] 2207 reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference 2208 to the bindings spec. 2210 D.7 lc-12-bind 2212 Type: change 2214 [36] 2216 reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction 2217 are identical to those in binding spec. Make sure that any changes 2218 made there are also incorporated here. 2220 Resolution: These paragraphs will change as necessary to make the 2221 redirect spec completely independent of the rest of WebDAV. 2223 D.8 lc-38-not-hierarchical 2225 Type: change 2227 [37] 2229 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The 2230 first sentence of the second paragraph of the introduction of the 2231 redirect spec asserts that the URIs of WebDAV compliant resources 2232 match to collections. The WebDAV standard makes no such requirement. 2233 I therefore move that this sentence be stricken. 2235 Resolution: State the more general HTTP rationale first (alternative 2236 names for the same resource), then introduce the collection hierarchy 2237 rationale, which applies only if you are in a WebDAV-compliant space. 2239 D.9 lc-36-server 2241 Type: change 2243 [38] 2245 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" 2246 with "unrelated system" throughout. 2248 Resolution: Try replacing "server" with "host" in some contexts, 2249 rephrasing in passive voice in others. See also issue 40. 2251 D.10 lc-33-forwarding 2253 Type: change 2255 [39] 2257 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace 2258 "forward" with "redirect" throughout. 2260 Resolution: Use "redirect" for the behavior redirect resources do 2261 exhibit. Use "forward" for the contrasting behavior (passing a method 2262 on to the target with no client action needed). Define these two 2263 terms. See also issue 40. 2265 D.11 lc-56-notjusthttp 2267 Type: change 2269 [40] 2271 yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples 2272 and text that the redirection URI could be non-HTTP. 2274 Resolution: We agree that it is possible to create redirect 2275 references to non-HTTP resources. Add example. 2277 D.12 lc-01-body 2279 Type: change 2281 [41] 2283 joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect 2284 References: Clarify: Are there 2 resources, one that redirects and 2285 one that responds with its own entity body? Clarify: What is the 2286 effect of PUT for a URI that currently maps to a redirect reference? 2287 Resolution: Redirect resource MUST NOT have a body. See also issue 2288 last call issue 23. 2290 D.13 lc-37-integrity 2292 Type: change 2294 [42] 2296 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7 2297 "Servers are not required to enforce the integrity of redirect 2298 references." Integrity is not defined. Replace with something 2299 clearer. 2301 Resolution: Rewrite to say that the server MUST NOT update the target 2302 See also issue 6. 2304 D.14 lc-14-bind 2306 Type: change 2308 [43] 2310 reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to 2311 just what is needed to understand the differences from redirect 2312 references. Maybe the paragraph in the Intro that starts "By 2313 contrast, a BIND request . . ." is all that is needed. 2315 Resolution: Get rid of discussion of bindings altogether. See also 2316 issue 34, 35. 2318 D.15 lc-15-direct-ref 2320 Type: change 2322 [44] 2324 reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference 2325 Resource, since direct references are out of scope. (If you do keep 2326 the definition, say explicitly that a direct reference resource is a 2327 type of reference resource.) 2329 Resolution: Remove definition of Direct Reference Resource. See also 2330 issue 39. 2332 D.16 lc-39-no-reference-or-direct-resource 2334 Type: change 2336 [45] 2338 yarong@Exchange.Microsoft.com (2000-02-11): 2339 NoReferenceOrDirectResource: Remove the definitions of "Reference" 2340 and "Direct Reference Resource." Change the definition of "Redirect 2341 Reference Resource" to be: Redirect Resource: A resource created to 2342 redirect all requests made to it, using 302 (Found), to a defined 2343 target resource. 2345 Resolution: Agreed. See also issue 15. 2347 D.17 lc-40-direct 2349 Type: change 2351 [46] 2353 yarong@Exchange.Microsoft.com (2000-02-11): Assorted changes to 2354 Section 4, para 2 to get rid of the word "forward" and the word 2355 "server" and remove comparison with direct references. 2357 Resolution: See also issue 33 (forward). See also issue 36 (server). 2358 Remove discussion of direct references. 2360 D.18 lc-43-webdav 2362 Type: change 2364 [47] 2366 yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the 2367 DAV:reftarget property. 2369 Resolution: DAV:reftarget is readonly and is present only for 2370 redirect references that are also WebDAV resources. We'll also have a 2371 method for setting target; Redirect-Ref header (returned on all 302 2372 responses) will have the target as its value. See also issue 6, 17, 2373 50. 2375 D.19 lc-19-direct-ref 2377 Type: change 2379 [48] 2381 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6, 2382 para 3 discussions of the Apply-to-Redirect-Ref header make it sound 2383 as if we are specifying direct reference behavior. 2385 Resolution: Change these passages so that the contrast is between 2386 applying the method to the redirect reference and responding with a 2387 302. 2389 D.20 lc-45-apply-to-rr 2391 Type: change 2393 [49] 2395 yarong@Exchange.Microsoft.com (2000-02-11): Suggested replacement 2396 text for this paragraph, which briefly introduces 2397 Apply-To-Redirect-Ref. Includes a note that even with this header, 2398 the response may be a 302. 2400 Resolution: See issue 19 for replacement text. Disagree. Redirect 2401 reference will never respond to Apply-To-RR with 302. 2403 D.21 lc-04-standard-data-container 2405 Type: change 2407 [50] 2409 joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs 2410 to be defined in the context of MKRESOURCE 2412 Resolution: Not relevant once we switch to MKREF. 2414 D.22 lc-05-standard-data-container 2416 Type: change 2418 [51] 2420 joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a 2421 "standard data container" can be created with MKRESOURCE or not. 2423 Resolution: Not relevant once we switch to MKREF. 2425 D.23 lc-20-intro-mkresource 2427 Type: change 2429 [52] 2431 reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new 2432 MKRESOURCE method" to make it clear that it is being introduced for 2433 the first time here. 2435 Resolution: Say "The MKREF method defined normatively here . . ." 2437 D.24 lc-22-coll 2439 Type: change 2441 [53] 2443 reuterj@ira.uka.de (2000-02-07): Inconsistency about whether 2444 collections can be created with MKRESOURCE. 2446 Resolution: Not relevant for MKREF. 2448 D.25 lc-25-atomic 2450 Type: change 2452 [54] 2454 reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a 2455 client? Can another client access the new resource's properties 2456 before they have been fully initialized? Maybe the MKRESOURCE request 2457 should let the client ask for it to be atomic. 2459 Resolution: No longer relevant once we switch to MKREF with no 2460 request body. 2462 D.26 lc-41-no-webdav 2464 Type: change 2466 [55] 2468 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references 2469 independent of the rest of WebDAV. The creation method for redirect 2470 references shouldn't require an XML request body. 2472 Resolution: We will make redirect references independent of the rest 2473 of WebDAV. MKREF will not have an XML request body. 2475 D.27 lc-42-no-webdav 2477 Type: change 2479 [56] 2480 yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method 2481 that creates only redirect references. The MKRESOURCE method hinders 2482 experiment because a user of a server who wishes to add support for 2483 the creation of a new resource type can't simply throw in another 2484 Apache module and allow it to provide the code for the new resource 2485 type. They have to find the code used for MKRESOURCE and change it to 2486 support the new resource type. 2488 Resolution: We will replace MKRESOURCE with MKREF, which creates only 2489 redirect reference resources. 2491 D.28 lc-58-update 2493 Type: change 2495 [57] 2497 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way 2498 to update the target of a redirect reference. 2500 Resolution: Agreed. See also issues 6, 43. 2502 D.29 lc-01A-body 2504 Type: change 2506 [58] 2508 joe@orton.demon.co.uk (2000-01-26): In the definition of MKRESOURCE, 2509 "Body" needs to be defined or else terminology changed. 2511 Resolution: We will use MKREF instead of MKRESOURCE. 2513 D.30 lc-23-body 2515 Type: change 2517 [59] 2519 reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the 2520 statement that the body of the resource is empty (PostConditions). It 2521 would be good if the response to GET included a response body that 2522 could be shown to a user by a client that doesn't do automatic 2523 redirection. There is a related problem in Section 6 on PUT. It is 2524 wrong to assume that what is PUT to a resource is what GET will 2525 return. In Section 6, say "A PUT with Apply-To-RR MAY contain a 2526 request body. The semantics of the request body is out of scope for 2527 this specification..." Also fix the discussion of example 6.2. 2529 Resolution: Redirect references cannot have bodies. GET with 2530 Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with 2531 403. See also issue 1. 2533 D.31 lc-24-properties 2535 Type: change 2537 [60] 2539 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence 2540 "The properties of the new resource are as specified by the 2541 DAV:propertyupdate request body, using PROPPATCH semantics" with the 2542 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate 2543 request body to initialize resource properties. Herein, the semantics 2544 is the same as when sending a MKRESOURCE request without a request 2545 body, followed by a PROPPATCH with the DAV:propertyupdate request 2546 body." 2548 Resolution: No longer relevant once we switch to MKREF with no 2549 request body. 2551 D.32 lc-47-207 2553 Type: change 2555 [61] 2557 yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to 2558 get rid of the request message body of MKRESOURCE, 207 would not be 2559 an appropriate response code. The description of 409 might lead 2560 someone to believe that you can't create redirect references outside 2561 of WebDAV namespaces. Suggests a different description. 2563 Resolution: No longer relevant - MKREF can't get a 207 response. 2564 Revise to make it clear that the first condition will only occur in 2565 WebDAV-compliant namespaces. 2567 D.33 lc-48-s6 2569 Type: change 2571 [62] 2573 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 2574 with just this: A redirect resource, upon receiving a request without 2575 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) 2576 response. The 302 (Found) response MUST include a location header 2577 identifying the target and a Redirect-Ref header. If a redirect 2578 resource receives a request with an Apply-To-Redirect-Ref header then 2579 the redirect reference resource MUST apply the method to itself 2580 rather than blindly returning a 302 (Found) response. 2582 Resolution: Keep a summary along the lines of Yaron's proposal (don't 2583 use the word "blindly"). Keep the bullets detailing the headers to be 2584 returned. Delete the rest, including the examples. See also issue 28, 2585 29, 30, 31, 32. 2587 D.34 lc-28-lang 2589 Type: edit 2591 [63] 2593 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence 2594 "A reference-aware WebDAV client can act on this response in one of 2595 two ways." A client can act on the response in any way it wants. 2597 Resolution: Agreed. See also issue 48. 2599 D.35 lc-29-lang 2601 Type: edit 2603 [64] 2605 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't 2606 need to be stated. Maybe note in an example. 2608 Resolution: Agreed. See also issue 48. 2610 D.36 lc-31-MKCOL 2612 Type: edit 2614 [65] 2616 reuterj@ira.uka.de (2000-02-07): Section 6, para on MKRESOURCE and 2617 MKCOL is obvious and doesn't need to be stated. Maybe show in an 2618 example. 2620 Resolution: Agreed. See also issue 48. 2622 D.37 lc-49-put 2624 Type: change 2626 [66] 2628 yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence 2629 of Example 6.2, which says that PUT replaces the reference with a 2630 different resource. 2632 Resolution: No longer relevant. Deleted this example in response to 2633 issue 48. 2635 D.38 lc-44-pseudo 2637 Type: change 2639 [67] 2641 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an 2642 optional prop XML element to the response element in 207 responses, 2643 define a new location XML element and a new refresource XML element. 2645 Resolution: Agree to define new XML elements that are not 2646 pseudo-properties. Disagreement about whether refresource is needed. 2647 See issue 61. 2649 D.39 lc-61-pseudo 2651 Type: change 2653 [68] 2655 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to 2656 ask future editors of RFC 2518 to define DAV:location with the 2657 semantics it has here. RFC 2518 should provide the information in the 2658 Location header somehow in multistatus responses, but not by using 2659 properties. 2661 Resolution: Define an XML element for location that is not a 2662 pseudo-property. We'll keep the recommendation that RFC 2518 add this 2663 for 302 responses. See also issue 44. 2665 D.40 lc-60-ex 2667 Type: change 2669 [69] 2671 reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear 2672 that these are just examples of client behavior, and are not meant to 2673 limit the client's behavior to these options. 2675 Resolution: Agreed to delete this paragraph. Continue discussion of 2676 what information should be returned with 302 in multistatus. Just 2677 location? Also redirectref? 2679 D.41 lc-62-oldclient 2681 Type: change 2683 [70] 2685 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim 2686 that non-referencing clients can't process 302 responses occurring in 2687 Multi-Status responses. They just have an extra round trip for each 2688 302. 2690 Resolution: Remove last sentence of the paragraph that recommends 2691 changes to RFC 2518. 2693 D.42 lc-63-move 2695 Type: change 2697 [71] 2699 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the 2700 perspective of a client? Agrees that there should be no 302s for 2701 member redirect references, but finds the rationale dubious. 2703 Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses 2704 special problems" and "due to atomicity". 2706 D.43 lc-67-redirectref 2708 Type: change 2710 [72] 2712 reuterj@ira.uka.de (2000-02-14): 7.4: The explanation should not 2713 contrast displaying the properties of the redirect ref with 2714 displaying the properties of its target, but with returning a 302. 2716 Resolution: Revise as recommended. 2718 D.44 lc-06-reftarget-relative 2720 Type: change 2722 [73] 2723 joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about 2724 relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server 2725 required to resolve the relative URI and store it as absolute? Is the 2726 server required to keep DAV:reftarget pointing to the target resource 2727 as the reference / target move, or is DAV:reftarget a dead property? 2729 Resolution: DAV:reftarget is readonly and present only on redirect 2730 references that are also WebDAV resources. Add a method for setting 2731 the target. Change definition of Redirect-Ref header so that it has 2732 the target as its value (comes back on all 302 responses). Server 2733 MUST store the target exactly as it is set. It MUST NOT resolve 2734 relatives to absolutes and MUST NOT update if target resource moves. 2735 See also issue 17, 43, 50, 57 2737 D.45 lc-57-noautoupdate 2739 Type: change 2741 [74] 2743 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid 2744 servers from automatically updating redirect resources when their 2745 targets move. 2747 Resolution: Agreed. See also issue 6. 2749 D.46 lc-71-relative 2751 Type: change 2753 [75] 2755 reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the 2756 Request-URI or href minus its final segment. 2758 Resolution: Fix this. 2760 D.47 lc-53-s10 2762 Type: change 2764 [76] 2766 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in 2767 this section would have a very serious impact on the efficiency of 2768 mapping Request-URIs to resources in HTTP request processing. Also 2769 specify another type of redirect resource that does not behave as in 2770 section 10, but instead would "expose the behavior we see today in 2771 various HTTP servers that allow their users to create 300 resources." 2772 Be sure we know what behavior will be if the redirect location is not 2773 an HTTP URL, but, say ftp. 2775 Resolution: We won't define 2 sorts of redirect references here. 2776 Servers SHOULD respond with 302 as described here, but if they can't 2777 do that, respond with 404 Not Found. (It's hard to modularize the 2778 behavior specified - it impacts processing Not Found cases of all 2779 methods, so you can't just add it to an HTTP server in a redirect ref 2780 module.) 2782 D.48 lc-72-trailingslash 2784 Type: change 2786 [77] 2788 reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget 2789 from ending in "/" 2791 Resolution: Make the note warn about the possibility of two slashes 2792 in a row, recommend against ending target with a slash, since that 2793 could result in two slashes in a row. 2795 D.49 lc-54-s10 2797 Type: change 2799 [78] 2801 yarong@Exchange.Microsoft.com (2000-02-11): The Note: in section 10 2802 has the same problem pointed out in Bindings.NoSlash and needs to be 2803 fixed. It contradicts RFC 2518 and 2616, which both assume that a URL 2804 and the same URL + "/" may map to different resources. 2806 Resolution: Agreed in mailing list discussions that no change is 2807 needed. 2809 D.50 lc-50-blindredirect 2811 Type: change 2813 [79] 2815 yarong@Exchange.Microsoft.com (2000-02-11): Replace current language 2816 explaining the purpose of the Redirect-Ref header with language that 2817 simply states that it marks blind 302 responses from redirect 2818 resources. (Section 6.3, 11.1) 2819 Resolution: Section 6.3 was removed in response to issue 48. In 11.1, 2820 change the definition of the Redirect-Ref header to have the value of 2821 the target (relative URI) as its value. Then we don't need a method 2822 for retrieving the target's relative URI. Presence of the 2823 Redirect-Ref header lets the client know that the resource accepts 2824 Apply-To-RR header and the new method for updating target. Reject 2825 Yaron's suggested language, but make the above changes. 2827 D.51 lc-74-terminology 2829 Type: change 2831 [80] 2833 reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find 2834 some good name for this an use it consistently 2836 D.52 lc-75-ignore 2838 Type: change 2840 [81] 2842 reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref 2843 header is used on a request to any other sort of resource besides a 2844 redirect reference resource, the server SHOULD ignore it." Don't need 2845 to say this since HTP already says that any header that is not 2846 understood should be ignored. 2848 D.53 lc-76-location 2850 Type: change 2852 [82] 2854 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real 2855 (live) property, get rid of the DAV:reftarget property 2857 D.54 lc-78-directory 2859 Type: change 2861 [83] 2863 reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to 2864 "collection". Not new to this protocol. Holds for any protocol that 2865 has hierarchical access paths. 2867 D.55 lc-79-accesscontrol 2869 Type: change 2871 [84] 2873 reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments, 2874 the owner of a resource might be able to use access control to 2875 prevent others from creating references to that resource." That would 2876 not be consistent with the concept of redirect references as weak 2877 links (e.g. think of moving a resource to a different locationo that 2878 is already the target of some redirection reference. 2880 D.56 lc-80-i18n 2882 Type: change 2884 [85] 2886 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot 2887 of this section, since this protocol extends WebDAV. Just reference 2888 [WebDAV]. 2890 D.57 lc-55-iana 2892 Type: change 2894 [86] 2896 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section 2897 to list all methods, headers, XML elements, MIME types, URL schemes, 2898 etc., defined by the spec. 2900 Resolution: Agreed. 2902 D.58 lc-82-iana 2904 Type: change 2906 [87] 2908 reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV] 2909 and say this protocol does not introduce any new considerations. 2911 Intellectual Property Statement 2913 The IETF takes no position regarding the validity or scope of any 2914 intellectual property or other rights that might be claimed to 2915 pertain to the implementation or use of the technology described in 2916 this document or the extent to which any license under such rights 2917 might or might not be available; neither does it represent that it 2918 has made any effort to identify any such rights. Information on the 2919 IETF's procedures with respect to rights in standards-track and 2920 standards-related documentation can be found in BCP-11. Copies of 2921 claims of rights made available for publication and any assurances of 2922 licenses to be made available, or the result of an attempt made to 2923 obtain a general license or permission for the use of such 2924 proprietary rights by implementors or users of this specification can 2925 be obtained from the IETF Secretariat. 2927 The IETF invites any interested party to bring to its attention any 2928 copyrights, patents or patent applications, or other proprietary 2929 rights which may cover technology that may be required to practice 2930 this standard. Please address the information to the IETF Executive 2931 Director. 2933 Full Copyright Statement 2935 Copyright (C) The Internet Society (2003). All Rights Reserved. 2937 This document and translations of it may be copied and furnished to 2938 others, and derivative works that comment on or otherwise explain it 2939 or assist in its implementation may be prepared, copied, published 2940 and distributed, in whole or in part, without restriction of any 2941 kind, provided that the above copyright notice and this paragraph are 2942 included on all such copies and derivative works. However, this 2943 document itself may not be modified in any way, such as by removing 2944 the copyright notice or references to the Internet Society or other 2945 Internet organizations, except as needed for the purpose of 2946 developing Internet standards in which case the procedures for 2947 copyrights defined in the Internet Standards process must be 2948 followed, or as required to translate it into languages other than 2949 English. 2951 The limited permissions granted above are perpetual and will not be 2952 revoked by the Internet Society or its successors or assignees. 2954 This document and the information contained herein is provided on an 2955 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2956 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2957 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2958 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2959 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2961 Acknowledgment 2963 Funding for the RFC Editor function is currently provided by the 2964 Internet Society.