draft-ietf-webdav-redirectref-protocol-11.txt   draft-ietf-webdav-redirectref-protocol-12.txt 
WEBDAV Working Group J. Whitehead WEBDAV Working Group J. Whitehead
Internet-Draft U.C. Santa Cruz Internet-Draft U.C. Santa Cruz
Expires: August 13, 2005 G. Clemm Expires: November 8, 2005 G. Clemm
IBM IBM
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
February 9, 2005 May 7, 2005
Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Web Distributed Authoring and Versioning (WebDAV) Redirect Reference
Resources Resources
draft-ietf-webdav-redirectref-protocol-11 draft-ietf-webdav-redirectref-protocol-12
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
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 Internet- other groups may also distribute working documents as 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 August 13, 2005. This Internet-Draft will expire on November 8, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 HTTP/ reference resource is a resource whose default response is an
1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), HTTP/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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
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
MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10 MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 10
7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10 7. UPDATEREDIRECTREF Method . . . . . . . . . . . . . . . . . . 10
7.1 Example: Updating a Redirect Reference Resource with 7.1 Example: Updating a Redirect Reference Resource with
UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12 UPDATEREDIRECTREF . . . . . . . . . . . . . . . . . . . . 12
8. Operations on Collections That Contain Redirect Reference 8. Operations on Collections That Contain Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1 LOCK on a Collection That Contains Redirect References . . 12 8.1 LOCK on a Collection That Contains Redirect References . . 13
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 references in DAV:reftarget . . . . . . . . . . . . 19 10. Relative references in DAV:reftarget . . . . . . . . . . . . 19
skipping to change at page 3, line 48 skipping to change at page 3, line 48
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 . . . . . . . . . . . . . . . . . . . . 25 17.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24
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. Change Log (to be removed by RFC Editor before
B. Change Log (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . . . . . 27
publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 A.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 27
B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 28 A.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 27
B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 28 A.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28
B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 28 A.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28
B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 28 A.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28
B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 28 A.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 28
B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 29 A.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 28
B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 29 A.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29
B.8 Since draft-ietf-webdav-redirectref-protocol-09 . . . . . 29 A.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29
B.9 Since draft-ietf-webdav-redirectref-protocol-10 . . . . . 29 A.10 Since draft-ietf-webdav-redirectref-protocol-11 . . . . 29
C. Resolved issues (to be removed by RFC Editor before B. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . . . . . 29 publication) . . . . . . . . . . . . . . . . . . . . . . . . 29
C.1 abnf . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 B.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.2 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.3 13_allprop . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . 32
D. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . . . . . 30
D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 30
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
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 [RFC3986]. 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
skipping to change at page 7, line 14 skipping to change at page 7, line 20
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
header (defined in Section 12.1 below) and the Location header set to header (defined in Section 12.1 below) and the Location header
the URI of the target resource. With this information, the client ([RFC2616], Section 14.30) set to the URI of the target resource.
can resubmit the request to the URI of the target resource. With this information, the client can resubmit the request to the URI
of the target resource.
A redirect reference resource never automatically forwards requests A redirect reference resource never automatically forwards requests
to its target resource. Redirect resources bring the same benefits to its target resource. Redirect resources bring the same benefits
as links in HTML documents. They can be created and maintained as links in HTML documents. They can be created and maintained
without the involvement or even knowledge of their target resource. without the involvement or even knowledge of their target resource.
This reduces the cost of linking between resources. This reduces the cost of linking between resources.
If the client is aware that it is operating on a redirect reference If the client is aware that it is operating on a redirect reference
resource, it can resolve the reference by retrieving the reference resource, it can resolve the reference by retrieving the reference
resource's DAV:reftarget property (defined in Section 13.2 below), resource's DAV:reftarget property (defined in Section 13.2 below),
skipping to change at page 8, line 17 skipping to change at page 8, line 23
Although non-referencing-aware clients cannot create reference Although non-referencing-aware clients cannot create reference
resources, they should be able to submit requests through the resources, they should be able to submit requests through the
reference resources created by reference-aware WebDAV clients. They reference resources created by reference-aware WebDAV clients. They
should be able to follow any references to their targets. To make should be able to follow any references to their targets. To make
this possible, a server that receives any request made via a redirect this possible, a server that receives any request made via a redirect
reference resource MUST return a 3xx range (Redirection) status code, reference resource MUST return a 3xx range (Redirection) status code,
unless the request includes an Apply-To-Redirect-Ref header unless the request includes an Apply-To-Redirect-Ref header
specifying "T". The client and server MUST follow [RFC2616] Section specifying "T". The client and server MUST follow [RFC2616] Section
10.3, but with these additional rules: 10.3, but with these additional rules:
o The Location response header MUST contain an absolute URI that o The Location response header MUST contain an URI (see [RFC3986],
identifies the target of the reference resource. Section 3) that identifies the target of the reference resource.
o The response MUST include the Redirect-Ref header. This header o The response MUST include the Redirect-Ref header. This header
allows reference-aware WebDAV clients to recognize the resource as allows reference-aware WebDAV clients to recognize the resource as
a reference resource and understand the reason for the a reference resource and understand the reason for the
redirection. redirection.
A reference-aware WebDAV client can, like a non-referencing client, A reference-aware WebDAV client can, like a non-referencing client,
resubmit the request to the URI in the Location header in order to resubmit the request to the URI in the Location header in order to
operate on the target resource. Alternatively, it can resubmit the operate on the target resource. Alternatively, it can resubmit the
request to the URI of the redirect reference resource with the request to the URI of the redirect reference resource with the
skipping to change at page 9, line 12 skipping to change at page 9, line 17
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 absolute-URI or a relative-ref (without MUST contain either an URI or a relative-ref (see [RFC3986],
fragment), see [RFC3986], Sections 4.2 and 4.3). Sections 3 and 4.2).
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
skipping to change at page 9, line 50 skipping to change at page 10, line 10
(DAV:locked-update-allowed): If the collection identified by the (DAV:locked-update-allowed): If the collection identified by the
Request-URI 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.
(DAV:legal-reftarget): The specified is a legal URI or relative-
ref.
Postconditions: Postconditions:
(DAV:new-redirectref): a new redirect reference resource is (DAV:new-redirectref): a new redirect reference resource is
created whose DAV:reftarget property has the value specified in created whose DAV:reftarget property has the value specified in
the request body. the request body.
6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF 6.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF
>> Request: >> Request:
skipping to change at page 11, line 41 skipping to change at page 11, line 50
(DAV:must-be-redirectref): the resource identified by the Request- (DAV:must-be-redirectref): the resource identified by the Request-
URI must be a redirect reference resource as defined by this URI must be a redirect reference resource as defined by 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.
(DAV:legal-reftarget): see Section 6.
Postconditions: Postconditions:
(DAV:redirectref-updated): the DAV:reftarget and DAV:redirect- (DAV:redirectref-updated): the DAV:reftarget and DAV:redirect-
lifetime properties of the redirect reference have been updated lifetime properties of the redirect reference have 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:
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:" (absolute-URI | Redirect-Ref = "Redirect-Ref:" (URI | relative-ref)
relative-part [ "?" query ]) ; URI: see [RFC3986], Section 3
; absolute-URI: see [RFC3986], section 4.3 ; relative-ref: see [RFC3986], Section 4.2
; 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 link target as specified reference resources. The value is the 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
skipping to change at page 26, line 34 skipping to change at page 26, line 33
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.
[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 -- 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
skipping to change at page 27, line 35 skipping to change at page 27, line 34
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. Change Log (to be removed by RFC Editor before publication)
<!-- Property Elements from Section 13 -->
<!ELEMENT reftarget href>
<!ELEMENT location href>
<!-- XML Elements from Section 14 -->
<!ELEMENT redirectref EMPTY >
<!-- Changes to the DAV:response Element from Section 15 -->
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?, location?) >
<!ELEMENT location (href) >
Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1 Since draft-ietf-webdav-redirectref-protocol-02 A.1 Since draft-ietf-webdav-redirectref-protocol-02
Julian Reschke takes editorial role (added to authors list). Cleanup Julian Reschke takes editorial role (added to authors list). Cleanup
XML indentation. Start adding all unresolved last call issues. XML indentation. Start adding all unresolved last call issues.
Update some author's contact information. Update references, split Update some author's contact information. Update references, split
into "normative" and "informational". Remove non-RFC2616 headers into "normative" and "informational". Remove non-RFC2616 headers
("Public") from examples. Fixed width problems in artwork. Start ("Public") from examples. Fixed width problems in artwork. Start
resolving editorial issues. resolving editorial issues.
B.2 Since draft-ietf-webdav-redirectref-protocol-03 A.2 Since draft-ietf-webdav-redirectref-protocol-03
Added Joe Orton and Juergen Reuter to Acknowledgements section. Added Joe Orton and Juergen Reuter to Acknowledgements section.
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 A.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 A.4 Since draft-ietf-webdav-redirectref-protocol-05
Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606- Close (accept) issue "lc-79-accesscontrol". Add issue "rfc2606-
compliance". Close issues "lc-50-blindredirect", "lc-71-relative", compliance". Close issues "lc-50-blindredirect", "lc-71-relative",
"lc-74-terminology". Update contact info for Geoff Clemm. Moved "lc-74-terminology". Update contact info for Geoff Clemm. Moved
some of the original authors names to new Contributors section. Add some of the original authors names to new Contributors section. Add
and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72- and close issue "9-MKRESOURCE-vs-relative-URI". Close issue "lc-72-
trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301" trailingslash". Close issue "lc-60-ex". Update issue "lc-85-301"
with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE- with proposal. Close issue "lc-06-reftarget-relative" (9-MKRESOURCE-
vs-relative-URI was a duplicate of this one). Also remove section vs-relative-URI was a duplicate of this one). Also remove section
9.1 (example for MKRESOURCE vs relative URIs). Add and resolve issue 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 "11.2-apply-to-redirect-ref-syntax" (header now has values "T" and
"F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add "F"). Also some cleanup for "rfc2606-compliance". Typo fixes. Add
and resolve "15.1-options-response". and resolve "15.1-options-response".
B.5 Since draft-ietf-webdav-redirectref-protocol-06 A.5 Since draft-ietf-webdav-redirectref-protocol-06
Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", "lc- 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" 44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", "lc-80-i18n"
and "rfc2606-compliance". Start work on index. Add new issue and "rfc2606-compliance". Start work on index. Add new issue
"old_clients". "old_clients".
B.6 Since draft-ietf-webdav-redirectref-protocol-07 A.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 "lc-57- replacing "302" by more generic language. Update issue "lc-57-
noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57- noautoupdate". Close issue "lc-37-integrity" (duplicate of "lc-57-
autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S. autoupdate"). Started work on "lc-85-301". Add L. Dusseault and S.
Eissing to Acknowledgments section. Eissing to Acknowledgments section.
B.7 Since draft-ietf-webdav-redirectref-protocol-08 A.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 A.8 Since draft-ietf-webdav-redirectref-protocol-09
Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57- Resolve issues "lc-33-forwarding", "lc-36-server" and "lc-57-
noautoupdate". Close issues "lc-48-s6", "12.1-property-name", "3- noautoupdate". Close issues "lc-48-s6", "12.1-property-name",
terminology-redirectref" and "lc-58-update". Rearrange section 5 and "3-terminology-redirectref" and "lc-58-update". Rearrange section 5
6. Add some more terms to index (no change tracking). and 6. Add some more terms to index (no change tracking).
B.9 Since draft-ietf-webdav-redirectref-protocol-10 A.9 Since draft-ietf-webdav-redirectref-protocol-10
Add and resolve issues "13_allprop" and "rfc2396bis". Use the term Add and resolve issues "13_allprop" and "rfc2396bis". Use the term
"Request-URI" throughout (this is what RFC2616 defines). Center some "Request-URI" throughout (this is what RFC2616 defines). Center some
of the artwork. Add and resolve issue "abnf". of the artwork. Add and resolve issue "abnf".
Appendix C. Resolved issues (to be removed by RFC Editor before A.10 Since draft-ietf-webdav-redirectref-protocol-11
publication)
Issues that were either rejected or resolved in this version of this
document.
C.1 abnf
Type: change
julian.reschke@greenbytes.de (2005-02-09): Use ABNF syntax from
RFC2234.
Resolution (2005-02-09): Done.
C.2 rfc2396bis
Type: change
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 (2005-01-25): Agreed (draft-rfc2396bis has been published
as RFC3986).
C.3 13_allprop
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/
0051.html>
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-11-13): Add statement about PROPFIND/allprop Re-open and close issue "anbf" (implied LWS). Raise and close issue
behaviour. "frag_in_target". Add precondition name for legal reftarget element
contents. Enhance index. Add and close issue "dtd-changes".
Appendix D. Open issues (to be removed by RFC Editor prior to Appendix B. Open issues (to be removed by RFC Editor prior to
publication) publication)
D.1 edit B.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
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/
0180.html>
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
that the request indeed should be applied to the redirect reference
resource itself. #2: Maximum usability with existing clients. For
instance, the Microsoft Webfolder client will not be able to DELETE a
redirect reference resource unless the server deviates from #1.
Right now I'm not sure about the best way to resolve this. Currently
the spec chooses #1 (back when this decision was made, there was
probably the assumption that existing clients would quickly be
updated -- something that probably isn't true today). However this
may result in implementers either just ignoring these rules, or
adding special workarounds based on "User Agent" detection.
Index Index
A A
Apply-To-Redirect-Ref header 22 Apply-To-Redirect-Ref header 22
C C
Condition Names Condition Names
DAV:legal-reftarget (pre) 10-11
DAV:locked-update-allowed (pre) 9, 11 DAV:locked-update-allowed (pre) 9, 11
DAV:must-be-redirectref (pre) 11 DAV:must-be-redirectref (pre) 11
DAV:name-allowed (pre) 9 DAV:name-allowed (pre) 9
DAV:new-redirectref (post) 10 DAV:new-redirectref (post) 10
DAV:parent-resource-must-be-non-null (pre) 9 DAV:parent-resource-must-be-non-null (pre) 9
DAV:redirect-lifetime-supported (pre) 9, 11 DAV:redirect-lifetime-supported (pre) 10-11
DAV:redirect-lifetime-update-supported (pre) 11 DAV:redirect-lifetime-update-supported (pre) 11
DAV:redirectref-updated (post) 11 DAV:redirectref-updated (post) 12
DAV:resource-must-be-null (pre) 9 DAV:resource-must-be-null (pre) 9
D D
DAV header DAV header
compliance class 'redirectrefs' 23 compliance class 'redirectrefs' 23
DAV:legal-reftarget precondition 10-11
DAV:locked-update-allowed precondition 9, 11 DAV:locked-update-allowed precondition 9, 11
DAV:mkdirectref XML element 9
DAV:mkredirectref-response XML element 9
DAV:must-be-redirectref precondition 11 DAV:must-be-redirectref precondition 11
DAV:name-allowed precondition 9 DAV:name-allowed precondition 9
DAV:new-redirectref postcondition 10 DAV:new-redirectref postcondition 10
DAV:parent-resource-must-be-non-null precondition 9 DAV:parent-resource-must-be-non-null precondition 9
DAV:permanent XML element 9, 22
DAV:redirect-lifetime property 22 DAV:redirect-lifetime property 22
DAV:redirect-lifetime-supported precondition 9, 11 DAV:redirect-lifetime XML element 9, 22
DAV:redirect-lifetime-supported precondition 10-11
DAV:redirect-lifetime-update-supported precondition 11 DAV:redirect-lifetime-update-supported precondition 11
DAV:redirectref resource type 23 DAV:redirectref resource type 23
DAV:redirectref-updated postcondition 11 DAV:redirectref-updated postcondition 12
DAV:reftarget property 23 DAV:reftarget property 23
DAV:reftarget XML element 9
DAV:resource-must-be-null precondition 9 DAV:resource-must-be-null precondition 9
DAV:temporary XML element 9, 22
DAV:updateredirectref-response XML element 11
H H
Headers Headers
Apply-To-Redirect-Ref 22 Apply-To-Redirect-Ref 22
Redirect-Ref 22 Redirect-Ref 22
M M
Methods Methods
MKREDIRECTREF 8 MKREDIRECTREF 8
UPDATEREDIRECTREF 10 UPDATEREDIRECTREF 10
skipping to change at page 33, line 9 skipping to change at page 31, line 18
N N
Non-Reference Resource 6 Non-Reference Resource 6
P P
Properties Properties
DAV:redirect-lifetime 22 DAV:redirect-lifetime 22
DAV:reftarget 23 DAV:reftarget 23
R R
Redirect Reference Resource 6
Redirect-Ref header 22 Redirect-Ref header 22
Rediret Reference Resource 6
Resource Types Resource Types
DAV:redirectref 23 DAV:redirectref 23
T T
Target Resource 6 Target Resource 7
U U
UPDATEREDIRECTREF method 10 UPDATEREDIRECTREF method 10
X
XML elements
DAV:mkdirectref 9
DAV:mkredirectref-response 9
DAV:permanent 9, 22
DAV:redirect-lifetime 9, 22
DAV:reftarget 9
DAV:temporary 9, 22
DAV:updateredirectref-response 11
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
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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