--- 1/draft-ietf-webdav-redirectref-protocol-10.txt 2006-02-05 02:11:39.000000000 +0100 +++ 2/draft-ietf-webdav-redirectref-protocol-11.txt 2006-02-05 02:11:39.000000000 +0100 @@ -1,78 +1,78 @@ + WEBDAV Working Group J. Whitehead Internet-Draft U.C. Santa Cruz -Expires: April 21, 2005 G. Clemm +Expires: August 13, 2005 G. Clemm IBM J. Reschke, Ed. greenbytes - October 21, 2004 + February 9, 2005 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources - draft-ietf-webdav-redirectref-protocol-10 + draft-ietf-webdav-redirectref-protocol-11 Status of this Memo This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each + of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 21, 2005. + This Internet-Draft will expire on August 13, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract This specification defines redirect reference resources. A redirect - reference resource is a resource whose default response is an - HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), + reference resource is a resource whose default response is an HTTP/ + 1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. Editorial Note (To be removed by RFC Editor before publication) Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . An issues list and XML and HTML versions of this draft are available - from - . + from . Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Redirect Reference Resources . . . . . . . . . . 7 5. Operations on Redirect Reference Resources . . . . . . . . . 8 6. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8 6.1 Example: Creating a Redirect Reference Resource with @@ -85,74 +85,71 @@ 8.1 LOCK on a Collection That Contains Redirect References . . 12 8.2 Example: PROPFIND on a Collection with Redirect Reference Resources . . . . . . . . . . . . . . . . . . . 13 8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with Redirect Reference Resources . . . . . . . 15 8.4 Example: COPY on a Collection That Contains a Redirect Reference Resource . . . . . . . . . . . . . . . . . . . . 16 8.5 Example: LOCK on a Collection That Contains a Redirect Reference Resource . . . . . . . . . . . . . . . . . . . . 17 9. Operations on Targets of Redirect Reference Resources . . . 19 - 10. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 19 - 10.1 Example: Resolving a Relative URI in a Multi-Status - Response . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Relative references in DAV:reftarget . . . . . . . . . . . . 19 + 10.1 Example: Resolving a Relative Reference in a + Multi-Status Response . . . . . . . . . . . . . . . . . 19 11. Redirect References to Collections . . . . . . . . . . . . . 20 12. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 22 12.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 22 13. Redirect Reference Resource Properties . . . . . . . . . . . 22 13.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 22 13.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 23 14. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 23 14.1 redirectref XML Element . . . . . . . . . . . . . . . . 23 15. Extensions to the DAV:response XML Element for Multi-Status Responses . . . . . . . . . . . . . . . . . . . 23 16. Capability Discovery . . . . . . . . . . . . . . . . . . . . 23 16.1 Example: Discovery of Support for Redirect Reference Resources . . . . . . . . . . . . . . . . . . . . . . . 24 17. Security Considerations . . . . . . . . . . . . . . . . . . 24 - 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24 + 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 25 17.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 25 17.3 Redirect Reference Resources and Denial of Service . . . 25 17.4 Revealing Private Locations . . . . . . . . . . . . . . 25 18. Internationalization Considerations . . . . . . . . . . . . 25 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 22. Normative References . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 A. Changes to the WebDAV Document Type Definition . . . . . . . 27 B. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 28 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 28 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28 B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28 B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28 - B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28 + B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 29 B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 29 B.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29 + B.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29 C. Resolved issues (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . . . . . 29 - C.1 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . 29 - C.2 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . 29 - C.3 3-terminology-redirectref . . . . . . . . . . . . . . . . 30 - C.4 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . 30 - C.5 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . 31 - C.6 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . 31 - C.7 12.1-property-name . . . . . . . . . . . . . . . . . . . . 31 + C.1 abnf . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + C.2 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30 + C.3 13_allprop . . . . . . . . . . . . . . . . . . . . . . . . 30 D. Open issues (to be removed by RFC Editor prior to - publication) . . . . . . . . . . . . . . . . . . . . . . . . 32 - D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 32 - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - Intellectual Property and Copyright Statements . . . . . . . 35 + publication) . . . . . . . . . . . . . . . . . . . . . . . . 30 + D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 30 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + Intellectual Property and Copyright Statements . . . . . . . 34 1. Introduction This specification extends the Web Distributed Authoring Protocol (WebDAV) to enable clients to create new access paths to existing resources. This capability is useful for several reasons: WebDAV makes it possible to organize HTTP resources into hierarchies, placing them into groupings, known as collections, which are more easily browsed and manipulated than a single flat collection. @@ -208,53 +205,48 @@ Sections 9 through 11 discuss several other issues raised by the existence of redirect reference resources. Sections 12 through 15 define the new headers, properties, and XML elements required to support redirect reference resources. Section 16 discusses capability discovery. Sections 17 through 19 present the security, internationalization, and IANA concerns raised by this specification. The remaining sections provide a variety of supporting information. 2. Notational Conventions - Since this document describes a set of extensions to the WebDAV - Distributed Authoring Protocol [RFC2518], itself an extension to the - HTTP/1.1 protocol, the augmented BNF used here to describe protocol - elements is exactly the same as described in Section 2.1 of - [RFC2616]. Since this augmented BNF uses the basic production rules - provided in Section 2.2 of [RFC2616], these rules apply to this - document as well. - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC2234]. + 3. Terminology The terminology used here follows and extends that in the WebDAV Distributed Authoring Protocol specification [RFC2518]. Definitions of the terms resource, Uniform Resource Identifier (URI), and Uniform - Resource Locator (URL) are provided in [RFC2396]. + Resource Locator (URL) are provided in [RFC3986]. Redirect Reference Resource A resource created to redirect all requests made to it, using an HTTP status code from the 3xx range, to a defined target resource. Non-Reference Resource A resource that is not a reference to another resource. Target Resource The resource to which requests are redirected by a redirect reference resource. A target resource can be anything that can be - identified by an absolute URI (see [RFC2396], "absoluteURI"). + identified by an absolute URI (see [RFC3986], "absolute-URI"). This document uses the terms "precondition", "postcondition" and "protected property" as defined in [RFC3253]. Servers MUST report pre-/postcondition failures as described in section 1.6 of this document. 4. Overview of Redirect Reference Resources For all operations submitted to a redirect reference resource, the default response is a 302 (Found), accompanied by the Redirect-Ref @@ -344,51 +336,51 @@ The request body MUST be a DAV:mkredirectref XML element. The DAV:href element is defined in [RFC2518] (Section 12.3) and - MUST contain either an absoluteURI or a relativeURI (see - [RFC2396], Section 3 and 5). + MUST contain either an absolute-URI or a relative-ref (without + fragment), see [RFC3986], Sections 4.2 and 4.3). If no DAV:redirect-lifetime element is specified, the server MUST behave as if a value of DAV:temporary was specified. If the request succeeds, the server MUST return 201 (Created) status. If a response body for a successful request is included, it MUST be a DAV:mkredirectref-response XML element. Note that this document does not define any elements for the MKREDIRECTREF response body, but the DAV:mkredirectref-response element is defined to ensure interoperability between future extensions that do define elements for the response body. Preconditions: (DAV:resource-must-be-null): A resource MUST NOT exist at the - request-URL. + Request-URI. - (DAV:parent-resource-must-be-non-null): The request-URL minus the + (DAV:parent-resource-must-be-non-null): The Request-URI minus the last past segment MUST identify a collection. - (DAV:name-allowed): The last segment of the request URL is + (DAV:name-allowed): The last segment of the Request-URI is available for use as a resource name. (DAV:locked-update-allowed): If the collection identified by the - Request-URL minus the last path segment is write-locked, then the + Request-URI minus the last path segment is write-locked, then the appropriate token MUST be specified in an If request header. (DAV:redirect-lifetime-supported): If the request body contains a DAV:redirect-lifetime element, the server MUST support the specified lifetime. Support for DAV:temporary is REQUIRED, while support for DAV:permanent is OPTIONAL. Postconditions: (DAV:new-redirectref): a new redirect reference resource is @@ -434,22 +426,22 @@ Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], section 9.1). Marshalling: The request body MUST be a DAV:updateredirectref XML element. - See Section 6 for a definition of DAV:reftarget and - DAV:redirect-lifetime. + See Section 6 for a definition of DAV:reftarget and DAV:redirect- + lifetime. If no DAV:reftarget element is specified, the server MUST NOT change the target of the redirect reference. If no DAV:redirect-lifetime element is specified, the server MUST NOT change the lifetime of the redirect reference. If a response body for a successful request is included, it MUST be a DAV:updateredirectref-response XML element. Note that this document does not define any elements for the UPDATEREDIRECTREF @@ -457,35 +449,35 @@ defined to ensure interoperability between future extensions that do define elements for the response body. Preconditions: (DAV:locked-update-allowed): if the resource is write-locked, then the appropriate token MUST be specified in an If request header. - (DAV:must-be-redirectref): the resource identified by the - request-URI must be a redirect reference resource as defined by - this specification. + (DAV:must-be-redirectref): the resource identified by the Request- + URI must be a redirect reference resource as defined by this + specification. (DAV:redirect-lifetime-supported): see Section 6. (DAV:redirect-lifetime-update-supported): servers MAY support changing the DAV:redirect-lifetime property; if they don't, this condition code can be used to signal failure. Postconditions: - (DAV:redirectref-updated): the DAV:reftarget and - DAV:redirect-lifetime properties of the redirect reference have - been updated accordingly. + (DAV:redirectref-updated): the DAV:reftarget and DAV:redirect- + lifetime properties of the redirect reference have been updated + accordingly. 7.1 Example: Updating a Redirect Reference Resource with UPDATEREDIRECTREF >> Request: UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.example.com Apply-To-Redirect-Ref: T Content-Type: text/xml; charset="utf-8" @@ -497,51 +489,51 @@ /i-d/draft-webdav-protocol-08b.txt >> Response: HTTP/1.1 200 OK This request has updated the redirect reference's DAV:reftarget property to "/i-d/draft-webdav-protocol-08b.txt", and has not changed - the DAV:redirect-lifetime value. Note that the - "Apply-To-Redirect-Ref" request header must be used, otherwise the - request would result in a redirect (3xx) response status. + the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect- + Ref" request header must be used, otherwise the request would result + in a redirect (3xx) response status. 8. Operations on Collections That Contain Redirect Reference Resources Consistent with the rules in Section 5, the response for each redirect reference encountered while processing a collection MUST be a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is included with the request. The overall response will therefore be a 207 (Multi-Status). For each DAV:response element representing a - redirect reference, the server MUST include an additional - DAV:location element, specifying the value of the "Location" header - that would be returned otherwise. The extension is defined in - Section 15 below. + redirect reference, the server MUST include an additional DAV: + location element, specifying the value of the "Location" header that + would be returned otherwise. The extension is defined in Section 15 + below. The Apply-To-Redirect-Ref header (defined in Section 12.2) MAY be used with any request on a collection. If present, it will be applied to all redirect reference resources encountered while processing the collection. 8.1 LOCK on a Collection That Contains Redirect References An attempt to lock (with Depth: infinity) a collection that contains redirect references without specifying "Apply-To-Redirect-Ref: T" will always fail. The Multi-Status response will contain a 3xx response for each redirect reference. - Reference-aware clients can lock the collection by using - Apply-To-Redirect-Ref, and, if desired, lock the targets of the - redirect references individually. + Reference-aware clients can lock the collection by using Apply-To- + Redirect-Ref, and, if desired, lock the targets of the redirect + references individually. Non-referencing clients must resort to locking each resource individually. 8.2 Example: PROPFIND on a Collection with Redirect Reference Resources Suppose a PROPFIND request with Depth: infinity is submitted to the following collection, with the members shown here: /MyCollection/ @@ -594,23 +586,23 @@ /MyCollection/nunavut HTTP/1.1 302 Found http://example.ca/art/inuit/ - In this example the Depth header is set to infinity, and the - Apply-To-Redirect-Ref header is set to "F". The collection contains - one URI that identifies a redirect reference resource. The response + In this example the Depth header is set to infinity, and the Apply- + To-Redirect-Ref header is set to "F". The collection contains one + URI that identifies a redirect reference resource. The response element for the redirect reference resource has a status of 302 (Found), and includes a DAV:location extension element to allow clients to retrieve the properties of its target resource. (The response element for the redirect reference resource does not include the requested properties. The client can submit another PROPFIND request to the URI in the DAV:location pseudo-property to retrieve those properties.) 8.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with Redirect Reference Resources @@ -799,39 +791,39 @@ the Apply-To-Redirect-Ref header to the collection. At that point both the reference resource and its target resource will be locked (as well as the collection and all the resources identified by its other members). 9. Operations on Targets of Redirect Reference Resources Operations on targets of redirect reference resources have no effect on the reference resource. -10. Relative URIs in DAV:reftarget +10. Relative references in DAV:reftarget The URI in the href in a DAV:reftarget property MAY be a relative - URI. In this case, the base URI to be used for resolving the - relative URI to absolute form is the URI used in the HTTP message to - identify the redirect reference resource to which the DAV:reftarget - property belongs. + reference. In this case, the base URI to be used for resolving it to + absolute form is the URI used in the HTTP message to identify the + redirect reference resource to which the DAV:reftarget property + belongs. When DAV:reftarget appears in the context of a Multi-Status response, it is in a DAV:response element that contains a single DAV:href element. The value of this DAV:href element serves as the base URI - for resolving a relative URI in DAV:reftarget. The value of DAV:href - may itself be relative, in which case it must be resolved first in - order to serve as the base URI for the relative URI in DAV:reftarget. - If the DAV:href element is relative, its base URI is constructed from - the scheme component "http", the value of the Host header in the - request, and the request-URI. + for resolving a relative reference in DAV:reftarget. The value of + DAV:href may itself be relative, in which case it must be resolved + first in order to serve as the base URI for the relative reference in + DAV:reftarget. If the DAV:href element is relative, its base URI is + constructed from the scheme component "http", the value of the Host + header in the request, and the Request-URI. -10.1 Example: Resolving a Relative URI in a Multi-Status Response +10.1 Example: Resolving a Relative Reference in a Multi-Status Response >> Request: PROPFIND /geog/ HTTP/1.1 Host: example.com Apply-To-Redirect-Ref: T Depth: 1 Content-Type: text/xml Content-Length: nnn @@ -870,42 +862,42 @@ statistics/population/1997.html HTTP/1.1 200 OK - In this example, the relative URI statistics/population/1997.html is - returned as the value of reftarget for the reference resource - identified by href /geog/stats.html. The href is itself a relative - URI, which resolves to http://example.com/geog/stats.html. This is - the base URI for resolving the relative URI in reftarget. The - absolute URI of reftarget is - http://example.com/geog/statistics/population/1997.html. + In this example, the relative reference "statistics/population/ + 1997.html" is returned as the value of the DAV:reftarget property for + the reference resource identified by href /geog/stats.html. The href + is itself a relative reference, which resolves to + http://example.com/geog/stats.html. This is the base URI for + resolving the relative reference in reftarget. The absolute URI of + reftarget is http://example.com/geog/statistics/population/1997.html. 11. Redirect References to Collections In a Request-URI /segment1/segment2/segment3, any of the three - segments may identify a redirect reference resource. (See [RFC2396], + segments may identify a redirect reference resource. (See [RFC3986], Section 3.3, for definitions of "path" and "segment".) If any segment in a Request-URI identifies a redirect reference resource, the response SHOULD be a 3xx. The value of the Location header in the response is as follows: - The leftmost path segment of the request-URI that identifies a + The leftmost path segment of the Request-URI that identifies a redirect reference resource, together with all path segments and separators to the left of it, is replaced by the value of the redirect reference resource's DAV:reftarget property (resolved to an - absolute URI). The remainder of the request-URI is concatenated to + absolute URI). The remainder of the Request-URI is concatenated to this path. Note: If the DAV:reftarget property ends with a "/" and the remainder of the Request-URI is non-empty (and therefore must begin with a "/"), the final "/" in the DAV:reftarget property is dropped before the remainder of the Request-URI is appended. Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect reference resource whose target resource is collection /a/, which contains redirect reference resource y whose target resource is @@ -941,44 +933,48 @@ Note: the behavior described above may have a very serious impact on the efficiency of mapping Request-URIs to resources in HTTP request processing. Therefore servers MAY respond with a 404 status code if the cost of checking all leading path segments for redirect references seems prohibitive. 12. Headers 12.1 Redirect-Ref Response Header - Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI) - ; see sections 3 and 5 of [RFC2396] + Redirect-Ref = "Redirect-Ref:" (absolute-URI | + relative-part [ "?" query ]) + ; absolute-URI: see [RFC3986], section 4.3 + ; query: see [RFC3986], section 3.4 + ; relative-part: see [RFC3986], section 4.2 The Redirect-Ref header is used in all 3xx responses from redirect - reference resources. The value is the (possibly relative) URI of the - link target as specified during redirect reference resource creation. + reference resources. The value is the link target as specified + during redirect reference resource creation. 12.2 Apply-To-Redirect-Ref Request Header Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") The optional Apply-To-Redirect-Ref header can be used on any request to a redirect reference resource. When it is present and set to "T", the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned. If the Apply-To-Redirect-Ref header is used on a request to any other sort of resource besides a redirect reference resource, the server MUST ignore it. 13. Redirect Reference Resource Properties The properties defined below are REQUIRED on redirect reference - resources. + resources. A PROPFIND/allprop request SHOULD NOT return any of the + properties defined in this document. 13.1 DAV:redirect-lifetime (protected) This property provides information about the lifetime of a redirect. It can either be DAV:permanent (HTTP status 301) or DAV:temporary (HTTP status 302). Future protocols may define additional values. @@ -1030,42 +1026,42 @@ to [RFC2518]. It defines a new compliance class, called redirectrefs, for use with the DAV header in responses to OPTIONS requests. If a resource does support redirect references, its response to an OPTIONS request may indicate that it does, by listing the new redirectrefs compliance class in the DAV header and by listing the MKREDIRECTREF method as one it supports. When responding to an OPTIONS request, any type of resource can include redirectrefs in the value of the DAV header. Doing so indicates that the server permits a redirect reference resource at - the request URI. + the Request-URI. 16.1 Example: Discovery of Support for Redirect Reference Resources >> Request: OPTIONS /somecollection/someresource HTTP/1.1 Host: example.org >> Response: HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF DAV: 1, 2, redirectrefs The DAV header in the response indicates that the resource /somecollection/someresource is level 1 and level 2 compliant, as defined in [RFC2518]. In addition, /somecollection/someresource supports redirect reference resources. The Allow header indicates - that MKREDIRECTREF requests can be submitted to - /somecollection/someresource. + that MKREDIRECTREF requests can be submitted to /somecollection/ + someresource. 17. Security Considerations This section is provided to make applications that implement this protocol aware of the security implications of this protocol. All of the security considerations of HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification also apply to this protocol specification. In addition, redirect reference resources introduce several new security concerns and increase the risk of some @@ -1137,69 +1133,72 @@ This document has benefited from thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and others. -22 Normative References +22. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. + [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. - [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. + [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web - Distributed Authoring and Versioning)", RFC 3253, March - 2002. + Distributed Authoring and Versioning)", RFC 3253, + March 2002. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. Authors' Addresses Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064 US - EMail: ejw@cse.ucsc.edu + Email: ejw@cse.ucsc.edu Geoff Clemm IBM 20 Maguire Road Lexington, MA 02421 US - EMail: geoffrey.clemm@us.ibm.com + Email: geoffrey.clemm@us.ibm.com Julian F. Reschke (editor) greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany Phone: +49 251 2807760 Fax: +49 251 2807761 - EMail: julian.reschke@greenbytes.de + Email: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/ Appendix A. Changes to the WebDAV Document Type Definition @@ -1229,210 +1227,127 @@ Close more editorial issues. Remove dependencies on BIND spec. B.3 Since draft-ietf-webdav-redirectref-protocol-04 More editorial fixes. Clarify that MKRESOURCE can only be used to create redirect references (switch to new method in a future draft). Clarify that redirect references do not have bodies. B.4 Since draft-ietf-webdav-redirectref-protocol-05 - Close (accept) issue "lc-79-accesscontrol". Add issue - "rfc2606-compliance". Close issues "lc-50-blindredirect", - "lc-71-relative", "lc-74-terminology". Update contact info for Geoff - Clemm. Moved some of the original authors names to new Contributors - section. Add and close issue "9-MKRESOURCE-vs-relative-URI". Close - issue "lc-72-trailingslash". Close issue "lc-60-ex". Update issue - "lc-85-301" with proposal. Close issue "lc-06-reftarget-relative" - (9-MKRESOURCE-vs-relative-URI was a duplicate of this one). Also - remove section 9.1 (example for MKRESOURCE vs relative URIs). Add - and resolve issue "11.2-apply-to-redirect-ref-syntax" (header now has - values "T" and "F"). Also some cleanup for "rfc2606-compliance". - Typo fixes. Add and resolve "15.1-options-response". + Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606- + compliance". Close issues "lc-50-blindredirect", "lc-71-relative", + "lc-74-terminology". Update contact info for Geoff Clemm. Moved + some of the original authors names to new Contributors section. Add + and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72- + trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301" + with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE- + vs-relative-URI was a duplicate of this one). Also remove section + 9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue + "11.2-apply-to-redirect-ref-syntax" (header now has values "T" and + "F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add + and resolve "15.1-options-response". B.5 Since draft-ietf-webdav-redirectref-protocol-06 - Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", - "lc-44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", - "lc-80-i18n" and "rfc2606-compliance". Start work on index. Add new - issue "old_clients". + Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc- + 44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n" + and "rfc2606-compliance". Start work on index. Add new issue + "old_clients". B.6 Since draft-ietf-webdav-redirectref-protocol-07 Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav". - Add issue "5_mkresource" and start work on MKREDIRECTREF (issue closed, but more work on MKREDIRECTREF needs to be done for updates and status codes other than 302). Start resolution of "lc-85-301", - replacing "302" by more generic language. Update issue - "lc-57-noautoupdate". Close issue "lc-37-integrity" (duplicate of - "lc-57-autoupdate"). Started work on "lc-85-301". Add L. Dusseault - and S. Eissing to Acknowledgments section. + replacing "302" by more generic language. Update issue "lc-57- + noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57- + autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S. + Eissing to Acknowledgments section. B.7 Since draft-ietf-webdav-redirectref-protocol-08 Fix index entries for conditions. Open and resolve issue "specify_safeness". Rewrite editorial section and parts of intro. Add more clarifications for issue "lc-85-301" and close it. B.8 Since draft-ietf-webdav-redirectref-protocol-09 - Resolve issues "lc-33-forwarding", "lc-36-server" and - "lc-57-noautoupdate". Close issues "lc-48-s6", "12.1-property-name", - "3-terminology-redirectref" and "lc-58-update". Rearrange section 5 - and 6. Add some more terms to index (no change tracking). + Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57- + noautoupdate". Close issues "lc-48-s6", "12.1-property-name", "3- + terminology-redirectref" and "lc-58-update". Rearrange section 5 and + 6. Add some more terms to index (no change tracking). + +B.9 Since draft-ietf-webdav-redirectref-protocol-10 + + Add and resolve issues "13_allprop" and "rfc2396bis". Use the term + "Request-URI" throughout (this is what RFC2616 defines). Center some + of the artwork. Add and resolve issue "abnf". Appendix C. Resolved issues (to be removed by RFC Editor before publication) Issues that were either rejected or resolved in this version of this document. -C.1 lc-36-server - - Type: change - - - - yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" - with "unrelated system" throughout. - - Resolution (2004-10-06): Originally proposed resolution: Try - replacing "server" with "host" in some contexts, rephrasing in - passive voice in others. See also issue 40. Actual resolution: - replace or remove on a case-by-case basis; use "system" or "unrelated - system" (host in RFC2616 terminology is something different). - -C.2 lc-33-forwarding - - Type: change - - - - yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace - "forward" with "redirect" throughout. - - Resolution (2004-10-07): Original Resolution: Use "redirect" for the - behavior redirect resources do exhibit. Use "forward" for the - contrasting behavior (passing a method on to the target with no - client action needed). Define these two terms. See also issue 40. - Actual Resolution: change the text so that it always says "redirect" - when we mean "redirect" and "forward" when we mean "forward"; do not - add new definitions, though. - -C.3 3-terminology-redirectref - - Type: change - - - - julian.reschke@greenbytes.de (2003-07-27): Consider global rename of - "redirect reference resource" to "redirect resource". - - Resolution (2004-10-08): Retracted (see - http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0009.htm - l). - -C.4 lc-57-noautoupdate +C.1 abnf Type: change - - - yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid - servers from automatically updating redirect resources when their - targets move. - - julian.reschke@greenbytes.de (2004-01-05): I don't think we can - forbid that. This spec consists of (a) clarifications of how a - server that supports redirects should behave for specific WebDAV - methods, and (b) extensions to explicitly create them (or to apply a - method to the redirect itself). As such, we shouldn't add any - requirements that HTTP doesn't add. What we could do is (1) note why - auto-update may be a bad idea, and possibly (2) define that redirects - created by MKREDIRECTREF should not behave that way (or alternatively - define more specific resource types). + julian.reschke@greenbytes.de (2005-02-09): Use ABNF syntax from + RFC2234. - Resolution (2004-10-07): State that operations on the target of a - redirect reference usually will not affect the redirect itself; but - also that clients should not rely on that in general (see also - http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0004.htm - l). + Resolution (2005-02-09): Done. -C.5 lc-48-s6 +C.2 rfc2396bis Type: change - - - yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 - with just this: A redirect resource, upon receiving a request without - an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) - response. The 302 (Found) response MUST include a location header - identifying the target and a Redirect-Ref header. If a redirect - resource receives a request with an Apply-To-Redirect-Ref header then - the redirect reference resource MUST apply the method to itself - rather than blindly returning a 302 (Found) response. + julian.reschke@greenbytes.de (2004-10-22): Update to RFC2396bis (this + needs to be done carefully because we are using the term "relative + URI reference" which does not exist in RFC2396bis anymore). - Resolution (2004-10-06): Original resolution: Keep a summary along - the lines of Yaron's proposal (don't use the word "blindly"). Keep - the bullets detailing the headers to be returned. Delete the rest, - including the examples. See also issue 28, 29, 30, 31, 32. Actual - resolution: the current wording seems to be in line with what Yaron - proposed back in 2000. + Resolution (2005-01-25): Agreed (draft-rfc2396bis has been published + as RFC3986). -C.6 lc-58-update +C.3 13_allprop Type: change - - - yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way - to update the target of a redirect reference. - - Resolution (2004-10-19): Agreed. See also issues 6, 43. See new - method UPDATEREDIRECTREF. - -C.7 12.1-property-name - - Type: change + - julian.reschke@greenbytes.de (2003-10-06): Sync names for - DAV:reftarget property and "Redirect-Ref" response headers. + julian.reschke@greenbytes.de (2004-11-13): Make the spec consistent + with RFC3253, RFC3648 and RFC3744 (new properties not returned upon + PROPFIND/allprop requests). - Resolution (2004-10-08): Retracted (see - http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0010.htm - l). + Resolution (2004-11-13): Add statement about PROPFIND/allprop + behaviour. Appendix D. Open issues (to be removed by RFC Editor prior to publication) D.1 edit Type: edit julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for editorial changes. D.2 old_clients Type: change - + julian.reschke@greenbytes.de (2003-11-10): There are (at least) two major design goals, but unfortunately both are in direct contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any request that addresses a redirect reference resource MUST result in a 3xx status code (obviously the whole point is that GET MUST result in a redirection, and if it does, it's hard to say why other methods such as PUT or DELETE should behave differently). Therefore, the redirect reference protocol introduces a new request header ("Apply-To-Redirect-Ref") through which a client can indicate @@ -1499,21 +1414,21 @@ DAV:redirect-lifetime 22 DAV:reftarget 23 R Redirect-Ref header 22 Rediret Reference Resource 6 Resource Types DAV:redirectref 23 T - Target Resource 7 + Target Resource 6 U UPDATEREDIRECTREF method 10 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights @@ -1540,18 +1455,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.