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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/