draft-ietf-webdav-redirectref-protocol-04.txt   draft-ietf-webdav-redirectref-protocol-05.txt 
WEBDAV Working Group J. Slein WEBDAV Working Group J. Slein
Internet-Draft Xerox Internet-Draft Xerox
Expires: March 10, 2004 J. Whitehead Expires: March 31, 2004 J. Whitehead
U.C. Santa Cruz U.C. Santa Cruz
J. Davis J. Davis
CourseNet CourseNet
G. Clemm G. Clemm
Rational Rational
C. Fay C. Fay
FileNet FileNet
J. Crawford J. Crawford
IBM IBM
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
September 10, 2003 October 1, 2003
WebDAV Redirect Reference Resources WebDAV Redirect Reference Resources
draft-ietf-webdav-redirectref-protocol-04 draft-ietf-webdav-redirectref-protocol-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 March 10, 2004. This Internet-Draft will expire on March 31, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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 HTTP/
1.1 302 (Found) status code, redirecting the client to a different 1.1 302 (Found) status code, redirecting the client to a different
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview of Redirect Reference Resources . . . . . . . . . . 9 4. Overview of Redirect Reference Resources . . . . . . . . . . 9
5. Creating a Redirect Reference Resource . . . . . . . . . . . 10 5. Creating a Redirect Reference Resource . . . . . . . . . . . 10
5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Example: Creating a Redirect Reference Resource with 5.2 Example: Creating a Redirect Reference Resource with
MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 11 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Operations on Redirect Reference Resources . . . . . . . . . 13 6. Operations on Redirect Reference Resources . . . . . . . . . 13
6.1 Example: GET on a Redirect Reference Resource . . . . . . . 14 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 13
6.2 Example: PUT on a Redirect Reference Resource with 6.2 Example: PROPPATCH on a Redirect Reference Resource . . . . 14
Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 14
6.3 Example: PROPPATCH on a Redirect Reference Resource . . . . 15
7. Operations on Collections That Contain Redirect Reference 7. Operations on Collections That Contain Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 MOVE and DELETE on Collections That Contain Redirect 7.1 MOVE and DELETE on Collections That Contain Redirect
References . . . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 LOCK on a Collection That Contains Redirect References . . . 17 7.2 LOCK on a Collection That Contains Redirect References . . . 17
7.3 Example: PROPFIND on a Collection with Redirect Reference 7.3 Example: PROPFIND on a Collection with Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a
Collection with Redirect Reference Resources . . . . . . . . 18 Collection with Redirect Reference Resources . . . . . . . . 18
7.5 Example: COPY on a Collection That Contains a Redirect 7.5 Example: COPY on a Collection That Contains a Redirect
skipping to change at page 3, line 33 skipping to change at page 3, line 31
17. Internationalization Considerations . . . . . . . . . . . . 37 17. Internationalization Considerations . . . . . . . . . . . . 37
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
Normative References . . . . . . . . . . . . . . . . . . . . 40 Normative References . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
A. Changes to the WebDAV Document Type Definition . . . . . . . 42 A. Changes to the WebDAV Document Type Definition . . . . . . . 42
B. Change Log (to be removed by RFC Editor before B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 43 publication) . . . . . . . . . . . . . . . . . . . . . . . . 43
B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43
B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43
B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . . 43
C. Resolved issues (to be removed by RFC Editor before C. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 44 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44
C.1 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.1 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 44
C.2 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.2 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 44
C.3 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.3 lc-04-standard-data-container . . . . . . . . . . . . . . . 44
C.4 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.4 lc-05-standard-data-container . . . . . . . . . . . . . . . 44
C.5 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.5 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 45
C.6 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.6 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.7 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.7 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 45
C.8 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.8 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 45
C.9 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 46 C.9 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.10 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 46 C.10 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.11 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 46 C.11 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.12 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 47 C.12 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 47
C.13 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 47
C.14 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 47
C.15 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 47
C.16 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.17 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 48
C.18 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 48
D. Open issues (to be removed by RFC Editor before D. Open issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 49 publication) . . . . . . . . . . . . . . . . . . . . . . . . 48
D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 49 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 48
D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 49 D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 48
D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 49 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 48
D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 49 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 48
D.5 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 50 D.5 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 49
D.6 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 50 D.6 3-terminology-redirectref . . . . . . . . . . . . . . . . . 49
D.7 3-terminology-redirectref . . . . . . . . . . . . . . . . . 50 D.7 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 49
D.8 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 50 D.8 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 49
D.9 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 51 D.9 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 50
D.10 lc-04-standard-data-container . . . . . . . . . . . . . . . 51 D.10 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 50
D.11 lc-05-standard-data-container . . . . . . . . . . . . . . . 51 D.11 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D.12 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 51 D.12 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.13 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.13 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.14 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 52 D.14 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 51
D.15 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52 D.15 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 51
D.16 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52 D.16 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.17 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 53 D.17 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 52
D.18 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 53 D.18 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.19 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 53 D.19 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 53
D.20 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.20 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 53
D.21 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.21 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 53
D.22 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55 D.22 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.23 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55 D.23 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 54
D.24 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 55 D.24 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 54
D.25 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 55 D.25 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 55
D.26 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 56 D.26 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 55
D.27 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.27 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 55
D.28 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 56 D.28 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.29 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.29 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.30 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . 57
D.31 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 57
D.32 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 57
D.33 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 58
D.34 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 58
D.35 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 58
D.36 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 59
D.37 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 59
D.38 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 59
D.39 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 59
D.40 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.41 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . 61
1. Introduction 1. Introduction
This is one of a pair of specifications that extend the WebDAV This is one of a pair of specifications that extend the WebDAV
Distributed Authoring Protocol to enable clients to create new access Distributed Authoring Protocol to enable clients to create new access
paths to existing resources. This capability is useful for several paths to existing resources. This capability is useful for several
reasons: reasons:
URIs of WebDAV-compliant resources are hierarchical and correspond to URIs of WebDAV-compliant resources are hierarchical and correspond to
a hierarchy of collections in resource space. The WebDAV Distributed a hierarchy of collections in resource space. The WebDAV Distributed
skipping to change at page 5, line 50 skipping to change at page 5, line 50
The redirect reference resources defined here provide a mechanism for The redirect reference resources defined here provide a mechanism for
creating alternative access paths to existing resources. A redirect creating alternative access paths to existing resources. A redirect
reference resource is a resource in one collection whose purpose is reference resource is a resource in one collection whose purpose is
to forward requests to another resource (its target), possibly in a to forward requests to another resource (its target), possibly in a
different collection. In this way, it allows clients to submit different collection. In this way, it allows clients to submit
requests to the target resource from another collection. It requests to the target resource from another collection. It
redirects most requests to the target resource using the HTTP 302 redirects most requests to the target resource using the HTTP 302
(Found) status code, thereby providing a form of mediated access to (Found) status code, thereby providing a form of mediated access to
the target resource. the target resource.
A redirect reference is a resource, and so can have properties and a A redirect reference is a resource with properties but no body of its
body of its own. Properties of a redirect reference resource can own. Properties of a redirect reference resource can contain such
contain such information as who created the reference, when, and why. information as who created the reference, when, and why. Since
redirect reference resources are implemented using HTTP 302
Since redirect reference resources are implemented using HTTP 302
responses, it generally takes two round trips to submit a request to responses, it generally takes two round trips to submit a request to
the intended resource. Servers are not required to enforce the the intended resource. Servers are not required to enforce the
integrity of redirect references. Redirect references work equally integrity of redirect references. Redirect references work equally
well for local resources and for resources that reside on a different well for local resources and for resources that reside on a different
server from the reference. server from the reference.
The remainder of this document is structured as follows: Section 3 The remainder of this document is structured as follows: Section 3
defines terms that will be used throughout the specification. defines terms that will be used throughout the specification.
Section 4 provides an overview of redirect reference resources. Section 4 provides an overview of redirect reference resources.
Section 5 discusses how to create a redirect reference resource. Section 5 discusses how to create a redirect reference resource.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
A resource created to redirect all requests made to it, using 302 A resource created to redirect all requests made to it, using 302
(Found), to a defined target resource. (Found), 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 forwarded by a reference The resource to which requests are forwarded by a reference
resource. resource. A target resource can be anything that can be identified
by an absolute URI (see [RFC2396], "absoluteURI").
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 11.1 below) and the Location header set to header (defined in Section 11.1 below) and the Location header set to
the URI of the target resource. With this information, the client the URI of the target resource. With this information, the client
can resubmit the request to the URI of the target resource. 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
skipping to change at page 9, line 30 skipping to change at page 9, line 30
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 12.1 below), resource's DAV:reftarget property (defined in Section 12.1 below),
whose value contains the URI of the target resource. It can then whose value contains the URI of the target resource. It can then
submit requests to the target resource. submit requests to the target resource.
A redirect reference resource is a new type of resource. To A redirect reference resource is a new type of resource. To
distinguish redirect reference resources from non-reference distinguish redirect reference resources from non-reference
resources, a new value of the DAV:resourcetype property (defined in resources, a new value of the DAV:resourcetype property (defined in
[RFC2518]), DAV:redirectref, is defined in Section 13.1 below. [RFC2518]), DAV:redirectref, is defined in Section 13.1 below.
Since a redirect reference resource is a resource, it can have its Since a redirect reference resource is a resource, methods can be
own properties and body, and methods can be applied to the reference applied to the reference resource as well as to its target resource.
resource as well as to its target resource. The The Apply-To-Redirect-Ref request header (defined in Section 11.2
Apply-To-Redirect-Ref request header (defined in Section 11.2 below) below) is provided so that referencing-aware clients can control
is provided so that referencing-aware clients can control whether an whether an operation is applied to the redirect reference resource or
operation is applied to the redirect reference resource or to its to its target resource. The Apply-To-Redirect-Ref header can be used
target resource. The Apply-To-Redirect-Ref header can be used with with most requests to redirect reference resources. This header is
most requests to redirect reference resources. This header is
particularly useful with PROPFIND, to retrieve the reference particularly useful with PROPFIND, to retrieve the reference
resource's own properties. resource's own properties.
5. Creating a Redirect Reference Resource 5. Creating a Redirect Reference Resource
The MKRESOURCE method is used to create new redirect reference The new MKRESOURCE method is used to create new redirect reference
resources. As defined in Section 5.1, MKRESOURCE can be used to resources. In order to create a redirect reference resource using
create a resource of any type other than standard data containers and
collections. In order to create a redirect reference resource using
MKRESOURCE, the values of two properties must be set in the body of MKRESOURCE, the values of two properties must be set in the body of
the MKRESOURCE request. The value of DAV:resourcetype MUST be set to the MKRESOURCE request. The value of DAV:resourcetype MUST be set to
DAV:redirectref, a new value of DAV:resourcetype defined in Section DAV:redirectref, a new value of DAV:resourcetype defined in Section
13.1. The value of DAV:reftarget MUST be set to the URI of the target 13.1. The value of DAV:reftarget MUST be set to the URI of the target
resource. resource.
Used in this way, the MKRESOURCE method creates a redirect reference Used in this way, the MKRESOURCE method creates a redirect reference
resource whose target is identified by the DAV:reftarget property. resource whose target is identified by the DAV:reftarget property.
5.1 MKRESOURCE 5.1 MKRESOURCE
The MKRESOURCE method requests the creation of a resource and The MKRESOURCE method requests the creation of a redirect reference
initialization of its properties. It allows resources other than resource and initialization of its properties in one atomic
standard data containers and collections to be created and their operation.
properties initialized in one atomic operation.
Preconditions: Preconditions:
A resource MUST NOT exist at the Request-URI. A resource MUST NOT exist at the Request-URI.
Request Marshalling: Request Marshalling:
The location of the new resource to be created is specified by the The location of the new resource to be created is specified by the
Request-URI. Request-URI.
The request body of the MKRESOURCE method MUST consist of the The request body of the MKRESOURCE method MUST consist of the
DAV:propertyupdate XML element defined in Section 12.13 of DAV:propertyupdate XML element defined in Section 12.13 of
[RFC2518]. [RFC2518], specifying a DAV:resourcetype of "DAV:redirectref".
Postconditions: Postconditions:
If the response status code is 201, a new resource exists at the If the response status code is 201, a new resource exists at the
Request-URI. Request-URI.
The body of the new resource is empty.
The properties of the new resource are as specified by the The properties of the new resource are as specified by the
DAV:propertyupdate request body, using PROPPATCH semantics. If the DAV:propertyupdate request body, using PROPPATCH semantics.
DAV:propertyupdate does not specify a DAV:resourcetype, the
resource will be a standard data container.
If the response status code is not 201, then a new resource is not If the response status code is not 201, then a new resource is not
created at the Request-URI, and any existing resource at the created at the Request-URI, and any existing resource at the
Request-URI is unaffected. Request-URI is unaffected.
Response Marshalling: Response Marshalling:
Responses from a MKRESOURCE request MUST NOT be cached, as Responses from a MKRESOURCE request MUST NOT be cached, as
MKRESOURCE has non-idempotent semantics. MKRESOURCE has non-idempotent semantics.
The following status codes can be expected in responses to The following status codes can be expected in responses to
MKRESOURCE: MKRESOURCE:
201 (Created): The new resource was successfully created. 201 (Created): The new resource was successfully created.
207 (Multi-Status): This response is generated if an error was
encountered while initializing the properties of the resource, in
which case the response is as defined in Section 8.2.1 of
[RFC2518].
403 (Forbidden): The server does not allow the creation of the 403 (Forbidden): The server does not allow the creation of the
requested resource type at the requested location, or the parent requested resource type at the requested location, or the parent
collection of the Request-URI exists but cannot accept members. collection of the Request-URI exists but cannot accept members.
409 (Conflict): A resource cannot be created at the Request-URI 409 (Conflict): A resource cannot be created at the Request-URI
because the parent collection for the resource does not exist, or because the parent collection for the resource does not exist, or
because there is already a resource at that request-URL. because there is already a resource at that request-URL.
423 (Locked): The Request-URI is locked, and the lock token was 423 (Locked): The Request-URI is locked, and the lock token was
not passed with the request. not passed with the request.
skipping to change at page 13, line 42 skipping to change at page 13, line 42
to the reference resource itself, and a 302 response MUST NOT be to the reference resource itself, and a 302 response MUST NOT be
returned. returned.
A reference-aware client may know before submitting its request that A reference-aware client may know before submitting its request that
the Request-URI identifies a redirect reference resource. In this the Request-URI identifies a redirect reference resource. In this
case, if the client wants to apply the method to the reference case, if the client wants to apply the method to the reference
resource, it can save the round trip caused by the 302 response by resource, it can save the round trip caused by the 302 response by
using an Apply-To-Redirect-Ref header in its initial request to the using an Apply-To-Redirect-Ref header in its initial request to the
URI. URI.
A few methods need additional explanation: As redirect references do not have bodies, GET and PUT requests with
Apply-To-Redirect-Ref MUST fail with status 403 (forbidden).
The Apply-To-Redirect-Ref header can be used with GET or HEAD to
retrieve the entity headers of a redirect reference resource. When
Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref
entity header MUST be returned.
A redirect reference resource MAY have a body, though none is defined
for it in this specification. The PUT method can be used, with
Apply-To-Redirect-Ref, to create or replace the body of a redirect
reference resource.
6.1 Example: GET on a Redirect Reference Resource 6.1 Example: GET on a Redirect Reference Resource
>> Request: >> Request:
GET /bar.html HTTP/1.1 GET /bar.html HTTP/1.1
Host: www.foo.com Host: www.foo.com
>> Response: >> Response:
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: http://www.svr.com/Internet/xxspec08.html Location: http://www.svr.com/Internet/xxspec08.html
Redirect-Ref: Redirect-Ref:
Since /bar.html is a redirect reference resource and the Since /bar.html is a redirect reference resource and the
Apply-To-Redirect-Ref header is not included in the request, the Apply-To-Redirect-Ref header is not included in the request, the
response is a 302 (Found). The Redirect-Ref header informs a response is a 302 (Found). The Redirect-Ref header informs a
reference-aware client that this is not an ordinary HTTP 1.1 reference-aware client that this is not an ordinary HTTP 1.1
skipping to change at page 14, line 26 skipping to change at page 14, line 18
Redirect-Ref: Redirect-Ref:
Since /bar.html is a redirect reference resource and the Since /bar.html is a redirect reference resource and the
Apply-To-Redirect-Ref header is not included in the request, the Apply-To-Redirect-Ref header is not included in the request, the
response is a 302 (Found). The Redirect-Ref header informs a response is a 302 (Found). The Redirect-Ref header informs a
reference-aware client that this is not an ordinary HTTP 1.1 reference-aware client that this is not an ordinary HTTP 1.1
redirect, but is a redirect reference resource. The URI of the redirect, but is a redirect reference resource. The URI of the
target resource is provided in the Location header so that the client target resource is provided in the Location header so that the client
can resubmit the request to the target resource. can resubmit the request to the target resource.
6.2 Example: PUT on a Redirect Reference Resource with 6.2 Example: PROPPATCH on a Redirect Reference Resource
Apply-To-Redirect-Ref
>> Request:
PUT /bar.html HTTP/1.1
Host: www.foo.com
Apply-To-Redirect-Ref:
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
. . . some content . . .
>> Response:
HTTP/1.1 200 OK
Although /bar.html is a redirect reference resource, the presence of
the Apply-To-Redirect-Ref header prevents a 302 response, and instead
causes the request to be applied to the reference resource. The
result in this case is that the reference resource is replaced by a
non-reference resource having the content submitted with the request.
6.3 Example: PROPPATCH on a Redirect Reference Resource
>> Request: >> Request:
PROPPATCH /bar.html HTTP/1.1 PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com Host: www.foo.com
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:" <D:propertyupdate xmlns:D="DAV:"
skipping to change at page 30, line 27 skipping to change at page 30, line 27
Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":"
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 used, the request MUST to a redirect reference resource. When it is used, the request MUST
be applied to the reference resource itself, and a 302 response MUST be applied to the reference resource itself, and a 302 response MUST
NOT be returned. 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
SHOULD ignore it. MUST ignore it.
12. Properties 12. Properties
12.1 reftarget Property 12.1 reftarget Property
Name: reftarget Name: reftarget
Namespace: DAV: Namespace: DAV:
Purpose: A property of redirect reference resources that provides an Purpose: A property of redirect reference resources that provides an
skipping to change at page 40, line 35 skipping to change at page 40, line 35
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
REC-xml, October 2000, <http://www.w3.org/TR/2000/ REC-xml, October 2000, <http://www.w3.org/TR/2000/
REC-xml-20001006>. REC-xml-20001006>.
[1] <mailto:w3c-dist-auth@w3.org> [1] <mailto:w3c-dist-auth@w3.org>
[2] <mailto:w3c-dist-auth-request@w3.org?subject=subscribe> [2] <mailto:w3c-dist-auth-request@w3.org?subject=subscribe>
[3] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [3] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0306.html>
[4] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [4] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0294.html>
[5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0286.html> 0189.html>
[6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0189.html>
[7] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [7] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[8] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [8] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0287.html> 0266.html>
[9] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [9] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0188.html> 0266.html>
[10] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [10] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0293.html>
[11] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [11] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[12] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [12] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0290.html> 0297.html>
[13] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [13] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0291.html> 0299.html>
[14] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [14] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0295.html>
[15] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0188.html>
[16] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[17] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[18] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [15] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0304.html>
[19] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html>
[20] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html>
[21] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0289.html> 0289.html>
[22] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [16] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0285.html> 0285.html>
[23] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [17] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0284.html> 0284.html>
[24] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [18] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0306.html>
[25] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0288.html> 0288.html>
[26] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [19] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0290.html> 0290.html>
[27] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [20] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0294.html>
[28] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[29] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0189.html>
[30] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0189.html>
[31] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[32] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[33] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[34] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [21] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0292.html> 0292.html>
[35] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [22] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0293.html>
[36] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0308.html> 0308.html>
[37] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [23] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[38] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[39] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [24] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0297.html>
[40] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0298.html> 0298.html>
[41] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [25] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[42] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [26] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[43] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [27] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0299.html>
[44] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0302.html> 0302.html>
[45] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [28] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[46] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [29] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[47] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [30] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[48] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [31] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[49] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [32] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0222.html> 0222.html>
[50] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [33] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0307.html> 0307.html>
[51] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [34] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[52] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [35] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0304.html> 0304.html>
[53] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [36] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[54] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [37] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0300.html> 0300.html>
[55] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [38] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[56] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[57] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [39] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[58] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [40] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[59] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [41] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[60] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [42] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0305.html> 0305.html>
Authors' Addresses Authors' Addresses
J. Slein J. Slein
Xerox Corporation Xerox Corporation
800 Phillips Road, 105-50C 800 Phillips Road, 105-50C
Webster, NY 14580 Webster, NY 14580
EMail: jslein@crt.xerox.com EMail: jslein@crt.xerox.com
skipping to change at page 48, line 5 skipping to change at page 46, line 21
some author's contact information. Update references, split into some author's contact information. Update references, split into
"normative" and "informational". Remove non-RFC2616 headers "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 B.2 Since draft-ietf-webdav-redirectref-protocol-03
Added Joe Orton and Juergen Reuter to Acknowledgements section. Close Added Joe Orton and Juergen Reuter to Acknowledgements section. Close
more editorial issues. Remove dependencies on BIND spec. more editorial issues. Remove dependencies on BIND spec.
B.3 Since draft-ietf-webdav-redirectref-protocol-04
More editorial fixes. Clarify that MKRESOURCE can only be used to
create redirect references (switch to new method in a future draft).
Clarify that redirect references do not have bodies.
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-07-bind C.1 lc-56-notjusthttp
Type: change Type: change
[3] [3]
reuterj@ira.uka.de (2000-02-07): Abstract should discuss only yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples
redirect references, not bindings. Expand discussion of redirect and text that the redirection URI could be non-HTTP.
references.
Resolution: Abstract will discuss only redirect references. See also Resolution: We agree that it is possible to create redirect
issue 34. references to non-HTTP resources. Add example. (actually it was added
to the definition of "target resource").
C.2 lc-08-bind C.2 lc-43-webdav
Type: change Type: change
[4] [4]
reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the
binding spec: in the abstract, in the introduction, in the definition DAV:reftarget property.
of Reference Resource.
Resolution: Cross-references to bindings will be removed. See also Resolution: DAV:reftarget is readonly and is present only for
issue 34. redirect references that are also WebDAV resources. We'll also have a
method for setting target; Redirect-Ref header (returned on all 302
responses) will have the target as its value. See also issue 6, 17,
50.
C.3 lc-34-bind C.3 lc-04-standard-data-container
Type: change Type: change
[5] [5]
yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs
cross-references to the binding spec. Prefer also removing all to be defined in the context of MKRESOURCE
mention of bindings.
Resolution: Agreed. See also issues 7, 8, 14 Resolution: Not relevant once we switch to MKREF.
C.4 lc-83-bind C.4 lc-05-standard-data-container
Type: change Type: change
[6] [6]
reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a
to the bindings spec. "standard data container" can be created with MKRESOURCE or not.
Resolution: Agreed. Resolution: Not relevant once we switch to MKREF.
C.5 lc-12-bind C.5 lc-20-intro-mkresource
Type: change Type: change
[7] [7]
reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new
are identical to those in binding spec. Make sure that any changes MKRESOURCE method" to make it clear that it is being introduced for
made there are also incorporated here. the first time here.
Resolution: These paragraphs will change as necessary to make the Resolution: Say "The MKREF method defined normatively here . . ."
redirect spec completely independent of the rest of WebDAV.
C.6 lc-35-bind C.6 lc-22-coll
Type: change Type: change
[8] [8]
yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
paras. 6 and 8 from Intro. collections can be created with MKRESOURCE.
Resolution: Agreed. See also issue 14. Resolution: (1) Strip all non-redirect-ref functionality from
MKRESOURCE, then (2) later switch to a new method.
C.7 lc-01-body C.7 lc-25-atomic
Type: change Type: change
[9] [9]
joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a
References: Clarify: Are there 2 resources, one that redirects and client? Can another client access the new resource's properties
one that responds with its own entity body? Clarify: What is the before they have been fully initialized? Maybe the MKRESOURCE request
effect of PUT for a URI that currently maps to a redirect reference? should let the client ask for it to be atomic.
Resolution: Redirect resource MUST NOT have a body. See also issue
last call issue 23.
C.8 lc-14-bind Resolution: No longer relevant once we switch to MKREF with no
request body. Also, as an intermediate step MKRESOURCE is defined to
be atomic.
C.8 lc-42-no-webdav
Type: change Type: change
[10] [10]
reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method
just what is needed to understand the differences from redirect that creates only redirect references. The MKRESOURCE method hinders
references. Maybe the paragraph in the Intro that starts "By experiment because a user of a server who wishes to add support for
contrast, a BIND request . . ." is all that is needed. the creation of a new resource type can't simply throw in another
Apache module and allow it to provide the code for the new resource
type. They have to find the code used for MKRESOURCE and change it to
support the new resource type.
Resolution: Get rid of discussion of bindings altogether. See also Resolution: We will replace MKRESOURCE with MKREF, which creates only
issue 34, 35. redirect reference resources.
C.9 lc-15-direct-ref C.9 lc-23-body
Type: change Type: change
[11] [11]
reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the
Resource, since direct references are out of scope. (If you do keep statement that the body of the resource is empty (PostConditions). It
the definition, say explicitly that a direct reference resource is a would be good if the response to GET included a response body that
type of reference resource.) could be shown to a user by a client that doesn't do automatic
redirection. There is a related problem in Section 6 on PUT. It is
wrong to assume that what is PUT to a resource is what GET will
return. In Section 6, say "A PUT with Apply-To-RR MAY contain a
request body. The semantics of the request body is out of scope for
this specification..." Also fix the discussion of example 6.2.
Resolution: Remove definition of Direct Reference Resource. See also Resolution: Redirect references cannot have bodies. GET with
issue 39. Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
403. See also issue 1.
C.10 lc-39-no-reference-or-direct-resource C.10 lc-47-207
Type: change Type: change
[12] [12]
yarong@Exchange.Microsoft.com (2000-02-11): yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to
NoReferenceOrDirectResource: Remove the definitions of "Reference" get rid of the request message body of MKRESOURCE, 207 would not be
and "Direct Reference Resource." Change the definition of "Redirect an appropriate response code. The description of 409 might lead
Reference Resource" to be: Redirect Resource: A resource created to someone to believe that you can't create redirect references outside
redirect all requests made to it, using 302 (Found), to a defined of WebDAV namespaces. Suggests a different description.
target resource.
julian.reschke@greenbytes.de (2003-07-27): (Rename from "redirect Resolution: No longer relevant - MKREF can't get a 207 response.
reference resource" to "redirect resource" delayed for now).
Resolution: Agreed. See also issue 15. Revise to make it clear that the first condition will only occur in
WebDAV-compliant namespaces.
C.11 lc-40-direct C.11 lc-49-put
Type: change Type: change
[13] [13]
yarong@Exchange.Microsoft.com (2000-02-11): Assorted changes to
Section 4, para 2 to get rid of the word "forward" and the word
"server" and remove comparison with direct references.
Resolution: See also issue 33 (forward). See also issue 36 (server).
Remove discussion of direct references.
C.12 lc-45-apply-to-rr
Type: change
[14]
yarong@Exchange.Microsoft.com (2000-02-11): Suggested replacement
text for this paragraph, which briefly introduces
Apply-To-Redirect-Ref. Includes a note that even with this header,
the response may be a 302.
Resolution: See issue 19 for replacement text. Disagree. Redirect
reference will never respond to Apply-To-RR with 302.
C.13 lc-01A-body
Type: change
[15]
joe@orton.demon.co.uk (2000-01-26): In the definition of MKRESOURCE,
"Body" needs to be defined or else terminology changed.
Resolution: We will use MKREF instead of MKRESOURCE.
C.14 lc-31-MKCOL
Type: edit
[16]
reuterj@ira.uka.de (2000-02-07): Section 6, para on MKRESOURCE and
MKCOL is obvious and doesn't need to be stated. Maybe show in an
example.
Resolution: Agreed. See also issue 48.
C.15 lc-67-redirectref
Type: change
[17]
reuterj@ira.uka.de (2000-02-14): 7.4: The explanation should not
contrast displaying the properties of the redirect ref with
displaying the properties of its target, but with returning a 302.
Resolution: Revise as recommended.
C.16 lc-54-s10
Type: change yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence
of Example 6.2, which says that PUT replaces the reference with a
[18] different resource.
yarong@Exchange.Microsoft.com (2000-02-11): The Note: in section 10
has the same problem pointed out in Bindings.NoSlash and needs to be
fixed. It contradicts RFC 2518 and 2616, which both assume that a URL
and the same URL + "/" may map to different resources.
Resolution: Agreed in mailing list discussions that no change is
needed.
C.17 lc-78-directory
Type: change
[19]
reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to Resolution: No longer relevant. Deleted this example in response to
"collection". Not new to this protocol. Holds for any protocol that issue 48.
has hierarchical access paths.
C.18 lc-82-iana C.12 lc-75-ignore
Type: change Type: change
[20] [14]
reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV] reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref
and say this protocol does not introduce any new considerations. header is used on a request to any other sort of resource besides a
redirect reference resource, the server SHOULD ignore it." Don't need
to say this since HTP already says that any header that is not
understood should be ignored.
Resolution: Simplify, then resolve issue 55. Resolution: Need to keep this to specify what a server that does
support this protocol needs to do when the header appears in a
request to a non-redirect-ref resource. However, say "MUST".
Appendix D. Open issues (to be removed by RFC Editor before publication) Appendix D. Open issues (to be removed by RFC Editor before publication)
D.1 lc-85-301 D.1 lc-85-301
Type: change Type: change
ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302
redirects, especially 301. redirects, especially 301.
D.2 lc-38-not-hierarchical D.2 lc-38-not-hierarchical
Type: change Type: change
[21] [15]
yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The
first sentence of the second paragraph of the introduction of the first sentence of the second paragraph of the introduction of the
redirect spec asserts that the URIs of WebDAV compliant resources redirect spec asserts that the URIs of WebDAV compliant resources
match to collections. The WebDAV standard makes no such requirement. match to collections. The WebDAV standard makes no such requirement.
I therefore move that this sentence be stricken. I therefore move that this sentence be stricken.
Resolution: State the more general HTTP rationale first (alternative Resolution: State the more general HTTP rationale first (alternative
names for the same resource), then introduce the collection hierarchy names for the same resource), then introduce the collection hierarchy
rationale, which applies only if you are in a WebDAV-compliant space. rationale, which applies only if you are in a WebDAV-compliant space.
D.3 lc-36-server D.3 lc-36-server
Type: change Type: change
[22] [16]
yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"
with "unrelated system" throughout. with "unrelated system" throughout.
Resolution: Try replacing "server" with "host" in some contexts, Resolution: Try replacing "server" with "host" in some contexts,
rephrasing in passive voice in others. See also issue 40. rephrasing in passive voice in others. See also issue 40.
D.4 lc-33-forwarding D.4 lc-33-forwarding
Type: change Type: change
[23] [17]
yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace
"forward" with "redirect" throughout. "forward" with "redirect" throughout.
Resolution: Use "redirect" for the behavior redirect resources do Resolution: Use "redirect" for the behavior redirect resources do
exhibit. Use "forward" for the contrasting behavior (passing a method exhibit. Use "forward" for the contrasting behavior (passing a method
on to the target with no client action needed). Define these two on to the target with no client action needed). Define these two
terms. See also issue 40. terms. See also issue 40.
D.5 lc-56-notjusthttp D.5 lc-37-integrity
Type: change
[24]
yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples
and text that the redirection URI could be non-HTTP.
Resolution: We agree that it is possible to create redirect
references to non-HTTP resources. Add example.
D.6 lc-37-integrity
Type: change Type: change
[25] [18]
yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7
"Servers are not required to enforce the integrity of redirect "Servers are not required to enforce the integrity of redirect
references." Integrity is not defined. Replace with something references." Integrity is not defined. Replace with something
clearer. clearer.
Resolution: Rewrite to say that the server MUST NOT update the target Resolution: Rewrite to say that the server MUST NOT update the target
See also issue 6. See also issue 6.
D.7 3-terminology-redirectref D.6 3-terminology-redirectref
Type: change Type: change
[26] [19]
julian.reschke@greenbytes.de (2003-07-27): Consider global rename of julian.reschke@greenbytes.de (2003-07-27): Consider global rename of
"redirect reference resource" to "redirect resource". "redirect reference resource" to "redirect resource".
D.8 lc-43-webdav D.7 lc-19-direct-ref
Type: change
[27]
yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the
DAV:reftarget property.
Resolution: DAV:reftarget is readonly and is present only for
redirect references that are also WebDAV resources. We'll also have a
method for setting target; Redirect-Ref header (returned on all 302
responses) will have the target as its value. See also issue 6, 17,
50.
D.9 lc-19-direct-ref
Type: change Type: change
[28] [20]
reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6, reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6,
para 3 discussions of the Apply-to-Redirect-Ref header make it sound para 3 discussions of the Apply-to-Redirect-Ref header make it sound
as if we are specifying direct reference behavior. as if we are specifying direct reference behavior.
Resolution: Change these passages so that the contrast is between Resolution: Change these passages so that the contrast is between
applying the method to the redirect reference and responding with a applying the method to the redirect reference and responding with a
302. 302.
D.10 lc-04-standard-data-container D.8 lc-41-no-webdav
Type: change
[29]
joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs
to be defined in the context of MKRESOURCE
Resolution: Not relevant once we switch to MKREF.
D.11 lc-05-standard-data-container
Type: change
[30]
joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a
"standard data container" can be created with MKRESOURCE or not.
Resolution: Not relevant once we switch to MKREF.
D.12 lc-20-intro-mkresource
Type: change
[31]
reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new
MKRESOURCE method" to make it clear that it is being introduced for
the first time here.
Resolution: Say "The MKREF method defined normatively here . . ."
D.13 lc-22-coll
Type: change
[32]
reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
collections can be created with MKRESOURCE.
Resolution: Not relevant for MKREF.
D.14 lc-25-atomic
Type: change
[33]
reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a
client? Can another client access the new resource's properties
before they have been fully initialized? Maybe the MKRESOURCE request
should let the client ask for it to be atomic.
Resolution: No longer relevant once we switch to MKREF with no
request body.
D.15 lc-41-no-webdav
Type: change Type: change
[34] [21]
yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references
independent of the rest of WebDAV. The creation method for redirect independent of the rest of WebDAV. The creation method for redirect
references shouldn't require an XML request body. references shouldn't require an XML request body.
Resolution: We will make redirect references independent of the rest Resolution: We will make redirect references independent of the rest
of WebDAV. MKREF will not have an XML request body. of WebDAV. MKREF will not have an XML request body.
D.16 lc-42-no-webdav D.9 lc-58-update
Type: change
[35]
yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method
that creates only redirect references. The MKRESOURCE method hinders
experiment because a user of a server who wishes to add support for
the creation of a new resource type can't simply throw in another
Apache module and allow it to provide the code for the new resource
type. They have to find the code used for MKRESOURCE and change it to
support the new resource type.
Resolution: We will replace MKRESOURCE with MKREF, which creates only
redirect reference resources.
D.17 lc-58-update
Type: change Type: change
[36] [22]
yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way
to update the target of a redirect reference. to update the target of a redirect reference.
Resolution: Agreed. See also issues 6, 43. Resolution: Agreed. See also issues 6, 43.
D.18 lc-23-body D.10 lc-24-properties
Type: change Type: change
[37] [23]
reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the
statement that the body of the resource is empty (PostConditions). It
would be good if the response to GET included a response body that
could be shown to a user by a client that doesn't do automatic
redirection. There is a related problem in Section 6 on PUT. It is
wrong to assume that what is PUT to a resource is what GET will
return. In Section 6, say "A PUT with Apply-To-RR MAY contain a
request body. The semantics of the request body is out of scope for
this specification..." Also fix the discussion of example 6.2.
Resolution: Redirect references cannot have bodies. GET with
Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
403. See also issue 1.
D.19 lc-24-properties
Type: change
[38]
reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence
"The properties of the new resource are as specified by the "The properties of the new resource are as specified by the
DAV:propertyupdate request body, using PROPPATCH semantics" with the DAV:propertyupdate request body, using PROPPATCH semantics" with the
following: "The MKRESOURCE request MAY contain a DAV:propertyupdate following: "The MKRESOURCE request MAY contain a DAV:propertyupdate
request body to initialize resource properties. Herein, the semantics request body to initialize resource properties. Herein, the semantics
is the same as when sending a MKRESOURCE request without a request is the same as when sending a MKRESOURCE request without a request
body, followed by a PROPPATCH with the DAV:propertyupdate request body, followed by a PROPPATCH with the DAV:propertyupdate request
body." body."
Resolution: No longer relevant once we switch to MKREF with no Resolution: No longer relevant once we switch to MKREF with no
request body. request body.
D.20 lc-47-207 D.11 lc-48-s6
Type: change
[39]
yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to
get rid of the request message body of MKRESOURCE, 207 would not be
an appropriate response code. The description of 409 might lead
someone to believe that you can't create redirect references outside
of WebDAV namespaces. Suggests a different description.
Resolution: No longer relevant - MKREF can't get a 207 response.
Revise to make it clear that the first condition will only occur in
WebDAV-compliant namespaces.
D.21 lc-48-s6
Type: change Type: change
[40] [24]
yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6
with just this: A redirect resource, upon receiving a request without with just this: A redirect resource, upon receiving a request without
an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)
response. The 302 (Found) response MUST include a location header response. The 302 (Found) response MUST include a location header
identifying the target and a Redirect-Ref header. If a redirect identifying the target and a Redirect-Ref header. If a redirect
resource receives a request with an Apply-To-Redirect-Ref header then resource receives a request with an Apply-To-Redirect-Ref header then
the redirect reference resource MUST apply the method to itself the redirect reference resource MUST apply the method to itself
rather than blindly returning a 302 (Found) response. rather than blindly returning a 302 (Found) response.
Resolution: Keep a summary along the lines of Yaron's proposal (don't Resolution: Keep a summary along the lines of Yaron's proposal (don't
use the word "blindly"). Keep the bullets detailing the headers to be use the word "blindly"). Keep the bullets detailing the headers to be
returned. Delete the rest, including the examples. See also issue 28, returned. Delete the rest, including the examples. See also issue 28,
29, 30, 31, 32. 29, 30, 31, 32.
D.22 lc-28-lang D.12 lc-28-lang
Type: edit Type: edit
[41] [25]
reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence
"A reference-aware WebDAV client can act on this response in one of "A reference-aware WebDAV client can act on this response in one of
two ways." A client can act on the response in any way it wants. two ways." A client can act on the response in any way it wants.
Resolution: Agreed. See also issue 48. Resolution: Agreed. See also issue 48.
D.23 lc-29-lang D.13 lc-29-lang
Type: edit Type: edit
[42] [26]
reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't
need to be stated. Maybe note in an example. need to be stated. Maybe note in an example.
Resolution: Agreed. See also issue 48. Resolution: Agreed. See also issue 48.
D.24 lc-49-put D.14 lc-44-pseudo
Type: change
[43]
yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence
of Example 6.2, which says that PUT replaces the reference with a
different resource.
Resolution: No longer relevant. Deleted this example in response to
issue 48.
D.25 lc-44-pseudo
Type: change Type: change
[44] [27]
yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an
optional prop XML element to the response element in 207 responses, optional prop XML element to the response element in 207 responses,
define a new location XML element and a new refresource XML element. define a new location XML element and a new refresource XML element.
Resolution: Agree to define new XML elements that are not Resolution: Agree to define new XML elements that are not
pseudo-properties. Disagreement about whether refresource is needed. pseudo-properties. Disagreement about whether refresource is needed.
See issue 61. See issue 61.
D.26 lc-61-pseudo D.15 lc-61-pseudo
Type: change Type: change
[45] [28]
reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to
ask future editors of RFC 2518 to define DAV:location with the ask future editors of RFC 2518 to define DAV:location with the
semantics it has here. RFC 2518 should provide the information in the semantics it has here. RFC 2518 should provide the information in the
Location header somehow in multistatus responses, but not by using Location header somehow in multistatus responses, but not by using
properties. properties.
Resolution: Define an XML element for location that is not a Resolution: Define an XML element for location that is not a
pseudo-property. We'll keep the recommendation that RFC 2518 add this pseudo-property. We'll keep the recommendation that RFC 2518 add this
for 302 responses. See also issue 44. for 302 responses. See also issue 44.
D.27 lc-60-ex D.16 lc-60-ex
Type: change Type: change
[46] [29]
reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear
that these are just examples of client behavior, and are not meant to that these are just examples of client behavior, and are not meant to
limit the client's behavior to these options. limit the client's behavior to these options.
Resolution: Agreed to delete this paragraph. Continue discussion of Resolution: Agreed to delete this paragraph. Continue discussion of
what information should be returned with 302 in multistatus. Just what information should be returned with 302 in multistatus. Just
location? Also redirectref? location? Also redirectref?
D.28 lc-62-oldclient D.17 lc-62-oldclient
Type: change Type: change
[47] [30]
reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim
that non-referencing clients can't process 302 responses occurring in that non-referencing clients can't process 302 responses occurring in
Multi-Status responses. They just have an extra round trip for each Multi-Status responses. They just have an extra round trip for each
302. 302.
Resolution: Remove last sentence of the paragraph that recommends Resolution: Remove last sentence of the paragraph that recommends
changes to RFC 2518. changes to RFC 2518.
D.29 lc-63-move D.18 lc-63-move
Type: change Type: change
[48] [31]
reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the
perspective of a client? Agrees that there should be no 302s for perspective of a client? Agrees that there should be no 302s for
member redirect references, but finds the rationale dubious. member redirect references, but finds the rationale dubious.
Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses
special problems" and "due to atomicity". special problems" and "due to atomicity".
D.30 lc-06-reftarget-relative D.19 lc-06-reftarget-relative
Type: change Type: change
[49] [32]
joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about
relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server
required to resolve the relative URI and store it as absolute? Is the required to resolve the relative URI and store it as absolute? Is the
server required to keep DAV:reftarget pointing to the target resource server required to keep DAV:reftarget pointing to the target resource
as the reference / target move, or is DAV:reftarget a dead property? as the reference / target move, or is DAV:reftarget a dead property?
Resolution: DAV:reftarget is readonly and present only on redirect Resolution: DAV:reftarget is readonly and present only on redirect
references that are also WebDAV resources. Add a method for setting references that are also WebDAV resources. Add a method for setting
the target. Change definition of Redirect-Ref header so that it has the target. Change definition of Redirect-Ref header so that it has
the target as its value (comes back on all 302 responses). Server the target as its value (comes back on all 302 responses). Server
MUST store the target exactly as it is set. It MUST NOT resolve MUST store the target exactly as it is set. It MUST NOT resolve
relatives to absolutes and MUST NOT update if target resource moves. relatives to absolutes and MUST NOT update if target resource moves.
See also issue 17, 43, 50, 57 See also issue 17, 43, 50, 57
D.31 lc-57-noautoupdate D.20 lc-57-noautoupdate
Type: change Type: change
[50] [33]
yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid
servers from automatically updating redirect resources when their servers from automatically updating redirect resources when their
targets move. targets move.
Resolution: Agreed. See also issue 6. Resolution: Agreed. See also issue 6.
D.32 lc-71-relative D.21 lc-71-relative
Type: change Type: change
[51] [34]
reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the
Request-URI or href minus its final segment. Request-URI or href minus its final segment.
Resolution: Fix this. Resolution: Fix this.
D.33 lc-53-s10 D.22 lc-53-s10
Type: change Type: change
[52] [35]
yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in
this section would have a very serious impact on the efficiency of this section would have a very serious impact on the efficiency of
mapping Request-URIs to resources in HTTP request processing. Also mapping Request-URIs to resources in HTTP request processing. Also
specify another type of redirect resource that does not behave as in specify another type of redirect resource that does not behave as in
section 10, but instead would "expose the behavior we see today in section 10, but instead would "expose the behavior we see today in
various HTTP servers that allow their users to create 300 resources." various HTTP servers that allow their users to create 300 resources."
Be sure we know what behavior will be if the redirect location is not Be sure we know what behavior will be if the redirect location is not
an HTTP URL, but, say ftp. an HTTP URL, but, say ftp.
Resolution: We won't define 2 sorts of redirect references here. Resolution: We won't define 2 sorts of redirect references here.
Servers SHOULD respond with 302 as described here, but if they can't Servers SHOULD respond with 302 as described here, but if they can't
do that, respond with 404 Not Found. (It's hard to modularize the do that, respond with 404 Not Found. (It's hard to modularize the
behavior specified - it impacts processing Not Found cases of all behavior specified - it impacts processing Not Found cases of all
methods, so you can't just add it to an HTTP server in a redirect ref methods, so you can't just add it to an HTTP server in a redirect ref
module.) module.)
D.34 lc-72-trailingslash D.23 lc-72-trailingslash
Type: change Type: change
[53] [36]
reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget
from ending in "/" from ending in "/"
Resolution: Make the note warn about the possibility of two slashes Resolution: Make the note warn about the possibility of two slashes
in a row, recommend against ending target with a slash, since that in a row, recommend against ending target with a slash, since that
could result in two slashes in a row. could result in two slashes in a row.
D.35 lc-50-blindredirect D.24 lc-50-blindredirect
Type: change Type: change
[54] [37]
yarong@Exchange.Microsoft.com (2000-02-11): Replace current language yarong@Exchange.Microsoft.com (2000-02-11): Replace current language
explaining the purpose of the Redirect-Ref header with language that explaining the purpose of the Redirect-Ref header with language that
simply states that it marks blind 302 responses from redirect simply states that it marks blind 302 responses from redirect
resources. (Section 6.3, 11.1) resources. (Section 6.3, 11.1)
Resolution: Section 6.3 was removed in response to issue 48. In 11.1, Resolution: Section 6.3 was removed in response to issue 48. In 11.1,
change the definition of the Redirect-Ref header to have the value of change the definition of the Redirect-Ref header to have the value of
the target (relative URI) as its value. Then we don't need a method the target (relative URI) as its value. Then we don't need a method
for retrieving the target's relative URI. Presence of the for retrieving the target's relative URI. Presence of the
Redirect-Ref header lets the client know that the resource accepts Redirect-Ref header lets the client know that the resource accepts
Apply-To-RR header and the new method for updating target. Reject Apply-To-RR header and the new method for updating target. Reject
Yaron's suggested language, but make the above changes. Yaron's suggested language, but make the above changes.
D.36 lc-74-terminology D.25 lc-74-terminology
Type: change Type: change
[55] [38]
reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find
some good name for this an use it consistently some good name for this an use it consistently
D.37 lc-75-ignore D.26 lc-76-location
Type: change
[56]
reuterj@ira.uka.de (2000-02-14): 11.2: "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 SHOULD ignore it." Don't need
to say this since HTP already says that any header that is not
understood should be ignored.
D.38 lc-76-location
Type: change Type: change
[57] [39]
reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real
(live) property, get rid of the DAV:reftarget property (live) property, get rid of the DAV:reftarget property
D.39 lc-79-accesscontrol D.27 lc-79-accesscontrol
Type: change Type: change
[58] [40]
reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments, reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments,
the owner of a resource might be able to use access control to the owner of a resource might be able to use access control to
prevent others from creating references to that resource." That would prevent others from creating references to that resource." That would
not be consistent with the concept of redirect references as weak not be consistent with the concept of redirect references as weak
links (e.g. think of moving a resource to a different locationo that links (e.g. think of moving a resource to a different locationo that
is already the target of some redirection reference. is already the target of some redirection reference.
D.40 lc-80-i18n D.28 lc-80-i18n
Type: change Type: change
[59] [41]
reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot
of this section, since this protocol extends WebDAV. Just reference of this section, since this protocol extends WebDAV. Just reference
[WebDAV]. [WebDAV].
D.41 lc-55-iana D.29 lc-55-iana
Type: change Type: change
[42]
[60]
yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section
to list all methods, headers, XML elements, MIME types, URL schemes, to list all methods, headers, XML elements, MIME types, URL schemes,
etc., defined by the spec. etc., defined by the spec.
Resolution: Agreed. Resolution: Agreed.
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
 End of changes. 

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