draft-ietf-webdav-redirectref-protocol-05.txt   draft-ietf-webdav-redirectref-protocol-06.txt 
WEBDAV Working Group J. Slein WEBDAV Working Group J. Whitehead
Internet-Draft Xerox Internet-Draft U.C. Santa Cruz
Expires: March 31, 2004 J. Whitehead Expires: April 19, 2004 G. Clemm
U.C. Santa Cruz
J. Davis
CourseNet
G. Clemm
Rational
C. Fay
FileNet
J. Crawford
IBM IBM
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 1, 2003 October 20, 2003
WebDAV Redirect Reference Resources WebDAV Redirect Reference Resources
draft-ietf-webdav-redirectref-protocol-05 draft-ietf-webdav-redirectref-protocol-06
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 34
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 31, 2004. This Internet-Draft will expire on April 19, 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 22
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 . . . . . . . 13
6.2 Example: PROPPATCH on a Redirect Reference Resource . . . . 14
7. Operations on Collections That Contain Redirect Reference 7. Operations on Collections That Contain Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 MOVE and DELETE on Collections That Contain Redirect 7.1 MOVE and DELETE on Collections That Contain Redirect
References . . . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 LOCK on a Collection That Contains Redirect References . . . 17 7.2 LOCK on a Collection That Contains Redirect References . . . 14
7.3 Example: PROPFIND on a Collection with Redirect Reference 7.3 Example: PROPFIND on a Collection with Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . 16
7.5 Example: COPY on a Collection That Contains a Redirect 7.5 Example: COPY on a Collection That Contains a Redirect
Reference Resource . . . . . . . . . . . . . . . . . . . . . 20 Reference Resource . . . . . . . . . . . . . . . . . . . . . 18
7.6 Example: LOCK on a Collection That Contains a Redirect 7.6 Example: LOCK on a Collection That Contains a Redirect
Reference Resource . . . . . . . . . . . . . . . . . . . . . 21 Reference Resource . . . . . . . . . . . . . . . . . . . . . 19
8. Operations on Targets of Redirect Reference Resources . . . 24 8. Operations on Targets of Redirect Reference Resources . . . 22
9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 25 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 23
9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 25 9.1 Example: Resolving a Relative URI in a Multi-Status
9.2 Example: Resolving a Relative URI in a Multi-Status Response . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Response . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Redirect References to Collections . . . . . . . . . . . . . 25
10. Redirect References to Collections . . . . . . . . . . . . . 28 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 27
11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 30 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 27
11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 30 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 28
12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 31 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 28
12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 31 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 29
13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 32 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 29
13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 32
14. Extensions to the DAV:response XML Element for 14. Extensions to the DAV:response XML Element for
Multi-Status Responses . . . . . . . . . . . . . . . . . . . 33 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 30
15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 34 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 31
15.1 Example: Discovery of Support for Redirect Reference 15.1 Example: Discovery of Support for Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 34 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . 35 16. Security Considerations . . . . . . . . . . . . . . . . . . 32
16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 35 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 32
16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 35 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 32
16.3 Redirect Reference Resources and Denial of Service . . . . . 35 16.3 Redirect Reference Resources and Denial of Service . . . . . 32
16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 35 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 32
17. Internationalization Considerations . . . . . . . . . . . . 37 17. Internationalization Considerations . . . . . . . . . . . . 34
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . . 40 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 Normative References . . . . . . . . . . . . . . . . . . . . 38
A. Changes to the WebDAV Document Type Definition . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
A. Changes to the WebDAV Document Type Definition . . . . . . . 40
B. Change Log (to be removed by RFC Editor before B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 43 publication) . . . . . . . . . . . . . . . . . . . . . . . . 41
B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 41
B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 41
B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . . 43 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . . 41
B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . . 41
C. Resolved issues (to be removed by RFC Editor before C. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 44 publication) . . . . . . . . . . . . . . . . . . . . . . . . 42
C.1 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 44 C.1 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 42
C.2 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 44 C.2 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 42
C.3 lc-04-standard-data-container . . . . . . . . . . . . . . . 44 C.3 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 42
C.4 lc-05-standard-data-container . . . . . . . . . . . . . . . 44 C.4 9-MKRESOURCE-vs-relative-URI . . . . . . . . . . . . . . . . 43
C.5 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 45 C.5 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 43
C.6 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.6 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 43
C.7 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 45 C.7 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 44
C.8 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 45 C.8 11.2-apply-to-redirect-ref-syntax . . . . . . . . . . . . . 44
C.9 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 46 C.9 15.1-options-response . . . . . . . . . . . . . . . . . . . 44
C.10 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 46 C.10 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 44
C.11 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.12 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 47
D. Open issues (to be removed by RFC Editor before D. Open issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 48 publication) . . . . . . . . . . . . . . . . . . . . . . . . 46
D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 48 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 46
D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 48 D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 46
D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 48 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 46
D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 48 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 47
D.5 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 49 D.5 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 47
D.6 3-terminology-redirectref . . . . . . . . . . . . . . . . . 49 D.6 3-terminology-redirectref . . . . . . . . . . . . . . . . . 47
D.7 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 49 D.7 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 47
D.8 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 49 D.8 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 48
D.9 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 50 D.9 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 48
D.10 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 50 D.10 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 48
D.11 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 50 D.11 rfc2606-compliance . . . . . . . . . . . . . . . . . . . . . 49
D.12 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.12 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.13 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.13 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.14 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 51 D.14 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.15 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 51 D.15 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 50
D.16 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.16 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 50
D.17 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 52 D.17 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 50
D.18 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.18 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.19 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 53 D.19 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 51
D.20 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 53 D.20 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.21 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 53 D.21 12.1-property-name . . . . . . . . . . . . . . . . . . . . . 52
D.22 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 53 D.22 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 52
D.23 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 54 D.23 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.24 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 54 D.24 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.25 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . 53
D.26 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 55
D.27 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 55
D.28 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.29 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 57
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 13, line 13 skipping to change at page 13, line 13
DAV:redirectref. DAV:redirectref.
6. Operations on Redirect Reference Resources 6. Operations on Redirect Reference Resources
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 302 (Found) status code, unless the reference resource MUST return a 302 (Found) status code, unless the
request includes an Apply-To-Redirect-Ref header. The client and request includes an Apply-To-Redirect-Ref header specifying "T". The
server MUST follow [RFC2616] Section 10.3.3 "302 Found," but with client and server MUST follow [RFC2616] Section 10.3.3 "302 Found",
these additional rules: but with these additional rules:
o The Location response header MUST contain an absolute URI that o The Location response header MUST contain an absolute URI that
identifies the target of the reference resource. 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 act on this response in one of A reference-aware WebDAV client can act on this response in one of
two ways. It can, like a non-referencing client, resubmit the two ways. It can, like a non-referencing client, resubmit the
request to the URI in the Location header in order to operate on the request to the URI in the Location header in order to operate on the
target resource. Alternatively, it can resubmit the request to the target resource. Alternatively, it can resubmit the request to the
URI of the redirect reference resource with the Apply-To-Redirect-Ref URI of the redirect reference resource with the
header in order to operate on the reference resource itself. If the "Apply-To-Redirect-Ref: T" header in order to operate on the
Apply-To-Redirect-Ref header is present, the request MUST be applied reference resource itself. In this case, the request MUST be applied
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.
As redirect references do not have bodies, GET and PUT requests with As redirect references do not have bodies, GET and PUT requests with
Apply-To-Redirect-Ref MUST fail with status 403 (forbidden). "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
6.1 Example: GET on a Redirect Reference Resource
>> Request:
GET /bar.html HTTP/1.1
Host: www.foo.com
>> Response:
HTTP/1.1 302 Found
Location: http://www.svr.com/Internet/xxspec08.html
Redirect-Ref:
Since /bar.html is a redirect reference resource and the
Apply-To-Redirect-Ref header is not included in the request, the
response is a 302 (Found). The Redirect-Ref header informs a
reference-aware client that this is not an ordinary HTTP 1.1
redirect, but is a redirect reference resource. The URI of the
target resource is provided in the Location header so that the client
can resubmit the request to the target resource.
6.2 Example: PROPPATCH on a Redirect Reference Resource
>> Request:
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</D:prop>
</D:set>
<D:remove>
<D:prop>
<Z:Copyright-Owner/>
</D:prop>
</D:remove>
</D:propertyupdate>
>> Response:
HTTP/1.1 302 Found
Location: http://www.svr.com/Internet/xxspec08.html
Redirect-Ref:
Since /bar.html is a redirect reference resource and the
Apply-To-Redirect-Ref header is not included in the request, the
response is a 302 (Found). The Redirect-Ref header informs a
reference-aware client that this is not an ordinary HTTP 1.1
redirect, but is a redirect reference resource. The URI of the
target resource is provided in the Location header so that the client
can resubmit the request to the target resource.
7. Operations on Collections That Contain Redirect Reference Resources 7. Operations on Collections That Contain Redirect Reference Resources
Consistent with the rules in Section 6, the response for each Consistent with the rules in Section 6, the response for each
redirect reference encountered while processing a collection MUST be redirect reference encountered while processing a collection MUST be
a 302 (Found) unless a Apply-To-Redirect-Ref header is included with a 302 (Found) unless a "Apply-To-Redirect-Ref: T" header is included
the request. The overall response will therefore be a 207 with the request. The overall response will therefore be a 207
(Multi-Status). Since a Location header and Redirect-Ref header (Multi-Status). Since a Location header and Redirect-Ref header
cannot be returned for each redirect reference encountered, the same cannot be returned for each redirect reference encountered, the same
information is provided using properties in the response elements for information is provided using properties in the response elements for
those resources. The DAV:location pseudo-property and the those resources. The DAV:location pseudo-property and the
DAV:resourcetype property MUST be included with the 302 status code. DAV:resourcetype property MUST be included with the 302 status code.
This necessitates an extension to the syntax of the DAV:response This necessitates an extension to the syntax of the DAV:response
element that was defined in [RFC2518]. The extension is defined in element that was defined in [RFC2518]. The extension is defined in
Section 14 below. Section 14 below.
A referencing-aware client can tell from the DAV:resourcetype
property that the collection contains a redirect reference resource.
The DAV:location pseudo-property contains the absolute URI of the
target resource. A referencing-aware client can either use the URI
value of the DAV:location pseudo-property to resubmit its request to
the target resource, or it can submit the request to the redirect
reference resource with Apply-To-Redirect-Ref.
It is recommended that future editors of [RFC2518] define the It is recommended that future editors of [RFC2518] define the
DAV:location pseudo-property in [RFC2518], so that non-referencing DAV:location pseudo-property in [RFC2518], so that non-referencing
clients will also be able to use the response to operate on the clients will also be able to use the response to operate on the
target resource. (This will also enable clients to operate on target resource. (This will also enable clients to operate on
traditional HTTP/1.1 302 responses in Multi-Status responses.) Until traditional HTTP/1.1 302 responses in Multi-Status responses.) Until
then, non-referencing clients will not be able to process 302 then, non-referencing clients will not be able to process 302
responses from redirect reference resources encountered while responses from redirect reference resources encountered while
processing a collection. processing a collection.
The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be
skipping to change at page 18, line 50 skipping to change at page 16, line 42
pseudo-property and the DAV:resourcetype property to allow clients to pseudo-property and the DAV:resourcetype property to allow clients to
retrieve the properties of its target resource. (The response retrieve the properties of its target resource. (The response
element for the redirect reference resource does not include the element for the redirect reference resource does not include the
requested properties. The client can submit another PROPFIND request requested properties. The client can submit another PROPFIND request
to the URI in the DAV:location pseudo-property to retrieve those to the URI in the DAV:location pseudo-property to retrieve those
properties.) properties.)
7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
Redirect Reference Resources Redirect Reference Resources
Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth: Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:
infinity is submitted to the following collection, with the members infinity is submitted to the following collection, with the members
shown here: shown here:
/MyCollection/ /MyCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut (redirect reference resource) nunavut
>> Request: >> Request:
PROPFIND /MyCollection/ HTTP/1.1 PROPFIND /MyCollection/ HTTP/1.1
Host: www.svr.com Host: example.com
Depth: infinity Depth: infinity
Apply-To-Redirect-Ref: Apply-To-Redirect-Ref: T
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<D:reftarget/> <D:reftarget/>
</D:prop> </D:prop>
</D:propfind> </D:propfind>
>> Response: >> Response:
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:"> <D:multistatus xmlns:D="DAV:">
<D:response> <D:response>
<D:href>http://www.svr.com/MyCollection/</D:href> <D:href>/MyCollection/</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype><D:collection/></D:resourcetype> <D:resourcetype><D:collection/></D:resourcetype>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
<D:propstat> <D:propstat>
<D:prop><D:reftarget/></D:prop> <D:prop><D:reftarget/></D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://www.svr.com/MyCollection/diary.html</D:href> <D:href>/MyCollection/diary.html</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
<D:propstat> <D:propstat>
<D:prop><D:reftarget/></D:prop> <D:prop><D:reftarget/></D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status> <D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://www.svr.com/MyCollection/nunavut</D:href> <D:href>/MyCollection/nunavut</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype><D:redirectref/></D:resourcetype> <D:resourcetype><D:redirectref/></D:resourcetype>
<D:reftarget> <D:reftarget>
<D:href>http://www.inac.gc.ca/art/inuit/</D:href> <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
</D:reftarget> </D:reftarget>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
Since the Apply-To-Redirect-Ref header is present, the response shows Since the "Apply-To-Redirect-Ref: T" header is present, the response
the properties of the redirect reference resource in the collection shows the properties of the redirect reference resource in the
rather than reporting a 302 status. collection rather than reporting a 302 status.
7.5 Example: COPY on a Collection That Contains a Redirect Reference 7.5 Example: COPY on a Collection That Contains a Redirect Reference
Resource Resource
Suppose a COPY request is submitted to the following collection, with Suppose a COPY request is submitted to the following collection, with
the members shown: the members shown:
/MyCollection/ /MyCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut with target (redirect reference resource) nunavut with target
skipping to change at page 25, line 13 skipping to change at page 23, line 13
on the reference resource. on the reference resource.
9. Relative URIs in DAV:reftarget 9. Relative URIs in DAV:reftarget
The URI in the href in a DAV:reftarget property MAY be a relative The URI in the href in a DAV:reftarget property MAY be a relative
URI. In this case, the base URI to be used for resolving the relative URI. In this case, the base URI to be used for resolving the relative
URI to absolute form is the URI used in the HTTP message to identify URI to absolute form is the URI used in the HTTP message to identify
the redirect reference resource to which the DAV:reftarget property the redirect reference resource to which the DAV:reftarget property
belongs. belongs.
When DAV:reftarget occurs in the body of a MKRESOURCE request, the
base URI is constructed as follows: Its scheme component is "http",
its authority component is the value of the Host header in the
request, and its path component is the Request-URI in the request.
See Section 5 of [RFC2396] for a discussion of relative URI
references and how to resolve them.
When DAV:reftarget appears in the context of a Multi-Status response, When DAV:reftarget appears in the context of a Multi-Status response,
it is in a DAV:response element that contains a single DAV:href it is in a DAV:response element that contains a single DAV:href
element. The value of this DAV:href element serves as the base URI element. The value of this DAV:href element serves as the base URI
for resolving a relative URI in DAV:reftarget. The value of DAV:href for resolving a relative URI in DAV:reftarget. The value of DAV:href
may itself be relative, in which case it must be resolved first in may itself be relative, in which case it must be resolved first in
order to serve as the base URI for the relative URI in DAV:reftarget. order to serve as the base URI for the relative URI in DAV:reftarget.
If the DAV:href element is relative, its base URI is constructed from If the DAV:href element is relative, its base URI is constructed from
the scheme component "http", the value of the Host header in the the scheme component "http", the value of the Host header in the
request, and the request-URI. request, and the request-URI.
9.1 Example: Resolving a Relative URI in a MKRESOURCE Request 9.1 Example: Resolving a Relative URI in a Multi-Status Response
>> Request:
MKRESOURCE /north/inuvik HTTP/1.1
Host: www.somehost.edu
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<D:resourcetype><D:redirectref/></D:resourcetype>
<D:reftarget>
<D:href>mapcollection/inuvik.gif</D:href>
</D:reftarget>
</D:prop>
</D:set>
</D:propertyupdate>
>> Response:
HTTP/1.1 201 Created
In this example, the base URI is http://www.somehost.edu/north/
inuvik. Then, following the rules in [RFC2396] Section 5, the
relative URI in DAV:reftarget resolves to the absolute URI http://
www.somehost.edu/north/mapcollection/inuvik.gif.
9.2 Example: Resolving a Relative URI in a Multi-Status Response
>> Request: >> Request:
PROPFIND /geog/ HTTP/1.1 PROPFIND /geog/ HTTP/1.1
Host: www.xxsvr.com Host: example.com
Apply-To-Redirect-Ref: Apply-To-Redirect-Ref: T
Depth: 1 Depth: 1
Content-Type: text/xml Content-Type: text/xml
Content-Length: nnn Content-Length: nnn
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<D:reftarget/> <D:reftarget/>
</D:prop> </D:prop>
skipping to change at page 27, line 20 skipping to change at page 24, line 42
</D:reftarget> </D:reftarget>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
In this example, the relative URI statistics/population/1997.html is In this example, the relative URI statistics/population/1997.html is
returned as the value of reftarget for the reference resource returned as the value of reftarget for the reference resource
identified by href /geog/stats.html. The href is itself a relative identified by href /geog/stats.html. The href is itself a relative
URI, which resolves to http://www.xxsrv.com/geog/stats.html. This is URI, which resolves to http://example.com/geog/stats.html. This is
the base URI for resolving the relative URI in reftarget. The the base URI for resolving the relative URI in reftarget. The
absolute URI of reftarget is http://www.xxsrv.com/geog/statistics/ absolute URI of reftarget is http://example.com/geog/statistics/
population/1997.html. population/1997.html.
10. Redirect References to Collections 10. Redirect References to Collections
In a Request-URI /segment1/segment2/segment3, any of the three In a Request-URI /segment1/segment2/segment3, any of the three
segments may identify a redirect reference resource. (See [RFC2396], segments may identify a redirect reference resource. (See [RFC2396],
Section 3.3, for definitions of "path" and "segment".) If any Section 3.3, for definitions of "path" and "segment".) If any
segment in a Request- URI identifies a redirect reference resource, segment in a Request- URI identifies a redirect reference resource,
the response is a 302. The value of the Location header in the 302 the response is a 302. The value of the Location header in the 302
response is as follows: response is as follows:
skipping to change at page 30, line 9 skipping to change at page 27, line 9
client resubmits the request to /a/y/z.html. The server responds to client resubmits the request to /a/y/z.html. The server responds to
this request with a 302 with Location: /b/z.html, and the client this request with a 302 with Location: /b/z.html, and the client
resubmits the request to /b/z.html. The server responds to this resubmits the request to /b/z.html. The server responds to this
request with a 302 with Location: /c/d.html, and the client resubmits request with a 302 with Location: /c/d.html, and the client resubmits
the request to /c/d.html. This final request succeeds. the request to /c/d.html. This final request succeeds.
11. Headers 11. Headers
11.1 Redirect-Ref Response Header 11.1 Redirect-Ref Response Header
Redirect-Ref = "Redirect-Ref:" Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI)
; see sections 3 and 5 of [RFC2396]
The Redirect-Ref header is used in all 302 responses from redirect The Redirect-Ref header is used in all 302 responses from redirect
reference resources. Its presence informs reference-aware clients reference resources. The value is the (possibly relative) URI of the
that the response is not a plain HTTP/1.1 redirect, but is a response link target as specified during redirect reference resource creation.
from a redirect reference resource.
11.2 Apply-To-Redirect-Ref Request Header 11.2 Apply-To-Redirect-Ref Request Header
Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
The optional Apply-To-Redirect-Ref header can be used on any request The optional Apply-To-Redirect-Ref header can be used on any request
to a redirect reference resource. When it is used, the request MUST to a redirect reference resource. When it is present and set to "T",
be applied to the reference resource itself, and a 302 response MUST the request MUST be applied to the reference resource itself, and a
NOT be returned. 302 response MUST NOT be returned.
If the Apply-To-Redirect-Ref header is used on a request to any other If the Apply-To-Redirect-Ref header is used on a request to any other
sort of resource besides a redirect reference resource, the server sort of resource besides a redirect reference resource, the server
MUST ignore it. MUST ignore it.
12. Properties 12. Properties
12.1 reftarget Property 12.1 reftarget Property
Name: reftarget Name: reftarget
skipping to change at page 34, line 15 skipping to change at page 31, line 15
15. Capability Discovery 15. Capability Discovery
Sections 9.1 and 15 of [RFC2518] describe the use of compliance Sections 9.1 and 15 of [RFC2518] describe the use of compliance
classes with the DAV header in responses to OPTIONS, to indicate classes with the DAV header in responses to OPTIONS, to indicate
which parts of the WebDAV Distributed Authoring protocols the which parts of the WebDAV Distributed Authoring protocols the
resource supports. This specification defines an OPTIONAL extension resource supports. This specification defines an OPTIONAL extension
to [RFC2518]. It defines a new compliance class, called to [RFC2518]. It defines a new compliance class, called
redirectrefs, for use with the DAV header in responses to OPTIONS redirectrefs, for use with the DAV header in responses to OPTIONS
requests. If a resource does support redirect references, its requests. If a resource does support redirect references, its
response to an OPTIONS request may indicate that it does, by listing response to an OPTIONS request may indicate that it does, by listing
the new redirectrefs compliance class in the DAV headerand by listing the new redirectrefs compliance class in the DAV header and by
the MKRESOURCE method as one it supports. listing the MKRESOURCE method as one it supports.
When responding to an OPTIONS request, any type of resource can When responding to an OPTIONS request, any type of resource can
include redirectrefs in the value of the DAV header. Doing so include redirectrefs in the value of the DAV header. Doing so
indicates that the server permits a redirect reference resource at indicates that the server permits a redirect reference resource at
the request URI. the request URI.
15.1 Example: Discovery of Support for Redirect Reference Resources 15.1 Example: Discovery of Support for Redirect Reference Resources
>> Request: >> Request:
OPTIONS /somecollection/someresource HTTP/1.1 OPTIONS /somecollection/someresource HTTP/1.1
HOST: somehost.org Host: example.org
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Connection: close Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
DAV: 1, 2, redirectrefs DAV: 1, 2, redirectrefs
The DAV header in the response indicates that the resource / The DAV header in the response indicates that the resource /
somecollection/someresource is level 1 and level 2 compliant, as somecollection/someresource is level 1 and level 2 compliant, as
defined in [RFC2518]. In addition, /somecollection/someresource defined in [RFC2518]. In addition, /somecollection/someresource
supports redirect reference resources. The Allow header indicates supports redirect reference resources. The Allow header indicates
that MKRESOURCE requests can be submitted to /somecollection/ that MKRESOURCE requests can be submitted to /somecollection/
someresource. The Public header shows that other Request-URIs on the someresource.
server support additional methods.
16. Security Considerations 16. Security Considerations
This section is provided to make applications that implement this This section is provided to make applications that implement this
protocol aware of the security implications of this protocol. protocol aware of the security implications of this protocol.
All of the security considerations of HTTP/1.1 and the WebDAV All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this Distributed Authoring Protocol specification also apply to this
protocol specification. In addition, redirect reference resources protocol specification. In addition, redirect reference resources
introduce several new security concerns and increase the risk of some introduce several new security concerns and increase the risk of some
skipping to change at page 36, line 9 skipping to change at page 33, line 9
property of every redirect reference resource contains the URI of the property of every redirect reference resource contains the URI of the
target resource. Anyone who has access to the reference resource can target resource. Anyone who has access to the reference resource can
discover the collection path that leads to the target resource. The discover the collection path that leads to the target resource. The
owner of the target resource may have wanted to limit knowledge of owner of the target resource may have wanted to limit knowledge of
this collection structure. this collection structure.
Sufficiently powerful access control mechanisms can control this risk Sufficiently powerful access control mechanisms can control this risk
to some extent. Property-level access control could prevent users to some extent. Property-level access control could prevent users
from examining the DAV:reftarget property. (The Location header from examining the DAV:reftarget property. (The Location header
returned in responses to requests on redirect reference resources returned in responses to requests on redirect reference resources
reveals the same information, however.) In some environments, the reveals the same information, however.)
owner of a resource might be able to use access control to prevent
others from creating references to that resource.
This risk is no greater than the similar risk posed by HTML links. This risk is no greater than the similar risk posed by HTML links.
17. Internationalization Considerations 17. Internationalization Considerations
This specification follows the practices of [RFC2518] in encoding all This specification follows the practices of [RFC2518] in encoding all
human-readable content using XML [XML] and in the treatment of names. human-readable content using XML [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set Consequently, this specification complies with the IETF Character Set
Policy [RFC2277]. Policy [RFC2277].
skipping to change at page 39, line 5 skipping to change at page 36, line 5
users as part of normal, error-free operation of the protocol. users as part of normal, error-free operation of the protocol.
For rationales for these decisions and advice for application For rationales for these decisions and advice for application
implementors, see [RFC2518]. implementors, see [RFC2518].
18. IANA Considerations 18. IANA Considerations
All IANA considerations mentioned in [RFC2518] also apply to this All IANA considerations mentioned in [RFC2518] also apply to this
document. document.
19. Acknowledgements 19. Contributors
This draft has benefited from thoughtful discussion by Jim Amsden, Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein
who can take credit for big parts of the original design of this
specification.
20. Acknowledgements
This document has benefited from thoughtful discussion by Jim Amsden,
Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt,
Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton, LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton,
Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley
Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
Wiggen, and others. Wiggen, and others.
Normative References Normative References
skipping to change at page 40, line 35 skipping to change at page 38, 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/
0306.html> 0316.html>
[4] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [4] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0294.html> 0222.html>
[5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0189.html> 0316.html>
[6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0189.html> 0316.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> 0300.html>
[8] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [8] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0316.html>
[9] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [9] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0359.html>
[10] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [10] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0293.html> 0289.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> 0285.html>
[12] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [12] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0297.html> 0284.html>
[13] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [13] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0299.html> 0288.html>
[14] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [14] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0290.html>
[15] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [15] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0289.html> 0266.html>
[16] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [16] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0285.html> 0292.html>
[17] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [17] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0284.html> 0308.html>
[18] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [18] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0288.html> 0266.html>
[19] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [19] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0290.html> 0298.html>
[20] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [20] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[21] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [21] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0292.html>
[22] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0308.html>
[23] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[24] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0298.html>
[25] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[26] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[27] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [22] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0302.html> 0302.html>
[28] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [23] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[29] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[30] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [24] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[31] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [25] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[32] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [26] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0222.html>
[33] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0307.html> 0307.html>
[34] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [27] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[35] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0304.html> 0304.html>
[36] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [28] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[37] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0300.html>
[38] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[39] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html>
[40] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[41] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [29] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[42] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [30] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0305.html> 0305.html>
Authors' Addresses Authors' Addresses
J. Slein
Xerox Corporation
800 Phillips Road, 105-50C
Webster, NY 14580
EMail: jslein@crt.xerox.com
Jim Whitehead Jim Whitehead
UC Santa Cruz, Dept. of Computer Science UC Santa Cruz, Dept. of Computer Science
1156 High Street 1156 High Street
Santa Cruz, CA 95064 Santa Cruz, CA 95064
US US
EMail: ejw@cse.ucsc.edu EMail: ejw@cse.ucsc.edu
J. Davis Geoff Clemm
CourseNet Systems IBM
170 Capp Street
San Francisco, CA 94110
EMail: jrd3@alum.mit.edu
G. Clemm
Rational Software Corporation
20 Maguire Road 20 Maguire Road
Lexington, MA 02173-3104 Lexington, MA 02421
US
EMail: geoffrey.clemm@us.ibm.com EMail: geoffrey.clemm@us.ibm.com
C. Fay
FileNet Corporation
3565 Harbor Boulevard
Costa Mesa, CA 92626-1420
EMail: cfay@filenet.com
J. Crawford
IBM Research
P.O. Box 704
Yorktown Heights, NY 10598
EMail: ccjason@us.ibm.com
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Salzmannstrasse 152 Salzmannstrasse 152
Muenster, NW 48159 Muenster, NW 48159
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
skipping to change at page 47, line 5 skipping to change at page 42, line 27
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 B.3 Since draft-ietf-webdav-redirectref-protocol-04
More editorial fixes. Clarify that MKRESOURCE can only be used to More editorial fixes. Clarify that MKRESOURCE can only be used to
create redirect references (switch to new method in a future draft). create redirect references (switch to new method in a future draft).
Clarify that redirect references do not have bodies. Clarify that redirect references do not have bodies.
B.4 Since draft-ietf-webdav-redirectref-protocol-05
Close (accept) issue "lc-79-accesscontrol". Add issue
"rfc2606-compliance". Close issues "lc-50-blindredirect",
"lc-71-relative", "lc-74-terminology". Update contact info for Geoff
Clemm. Moved some of the original authors names to new Contributors
section. Add and close issue "9-MKRESOURCE-vs-relative-URI". Close
issue "lc-72-trailingslash". Close issue "lc-60-ex". Update issue
"lc-85-301" with proposal. Close issue "lc-06-reftarget-relative"
(9-MKRESOURCE-vs-relative-URI was a duplicate of this one). Also
remove section 9.1 (example for MKRESOURCE vs relative URIs). Add
and resolve issue "11.2-apply-to-redirect-ref-syntax" (header now has
values "T" and "F"). Also some cleanup for "rfc2606-compliance".
Typo fixes. Add and resolve "15.1-options-response".
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-56-notjusthttp C.1 lc-60-ex
Type: change Type: change
[3] [3]
yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear
and text that the redirection URI could be non-HTTP. that these are just examples of client behavior, and are not meant to
limit the client's behavior to these options.
Resolution: We agree that it is possible to create redirect Resolution (2003-10-13): Agreed to delete this paragraph. Continue
references to non-HTTP resources. Add example. (actually it was added discussion of what information should be returned with 302 in
to the definition of "target resource"). multistatus. Just location? Also redirectref? Update: ret gid of
pseudo-property and special response format, define new response
element instead. See ossue lc-61-pseudo.
C.2 lc-43-webdav C.2 lc-06-reftarget-relative
Type: change Type: change
[4] [4]
yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about
DAV:reftarget property. relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server
required to resolve the relative URI and store it as absolute? Is the
server required to keep DAV:reftarget pointing to the target resource
as the reference / target move, or is DAV:reftarget a dead property?
Resolution: DAV:reftarget is readonly and is present only for Resolution (2003-10-13): DAV:reftarget is readonly and present only
redirect references that are also WebDAV resources. We'll also have a on redirect references that are also WebDAV resources. Add a method
method for setting target; Redirect-Ref header (returned on all 302 for setting the target. Change definition of Redirect-Ref header so
responses) will have the target as its value. See also issue 6, 17, that it has the target as its value (comes back on all 302
50. responses). Server MUST store the target exactly as it is set. It
MUST NOT resolve relatives to absolutes and MUST NOT update if target
resource moves. See also issue 17, 43, 50, 57
C.3 lc-04-standard-data-container C.3 lc-71-relative
Type: change Type: change
[5] [5]
reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the
Request-URI or href minus its final segment.
joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs Resolution (2003-10-08): Original WG comment: Fix this. However, this
to be defined in the context of MKRESOURCE is just a misunderstanding. The process of resolving a relative URI
against a hierarchical base URI already involves removal of the last
Resolution: Not relevant once we switch to MKREF. path segment, so the draft is correct here.
C.4 lc-05-standard-data-container
Type: change
[6]
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.
C.5 lc-20-intro-mkresource C.4 9-MKRESOURCE-vs-relative-URI
Type: change Type: change
[7] julian.reschke@greenbytes.de (2003-10-08): Do not say anything about
MKRESOURCE vs relative URIs. The server is supposed to store the
reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new relative URI, thus the issue of resolving the URI does only apply
MKRESOURCE method" to make it clear that it is being introduced for upon retrieval, not creation.
the first time here.
Resolution: Say "The MKREF method defined normatively here . . ."
C.6 lc-22-coll C.5 lc-72-trailingslash
Type: change Type: change
[8] [6]
reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
collections can be created with MKRESOURCE.
Resolution: (1) Strip all non-redirect-ref functionality from
MKRESOURCE, then (2) later switch to a new method.
C.7 lc-25-atomic
Type: change reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget
from ending in "/"
[9] julian.reschke@greenbytes.de (): (last call WG response): Make the
note warn about the possibility of two slashes in a row, recommend
against ending target with a slash, since that could result in two
slashes in a row.
reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a Resolution (2003-10-09): It seems that the rule in the 3rd paragraph
client? Can another client access the new resource's properties already explains how to deal with this situation. No change.
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 C.6 lc-50-blindredirect
request body. Also, as an intermediate step MKRESOURCE is defined to
be atomic.
C.8 lc-42-no-webdav
Type: change Type: change
[10] [7]
yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method yarong@Exchange.Microsoft.com (2000-02-11): Replace current language
that creates only redirect references. The MKRESOURCE method hinders explaining the purpose of the Redirect-Ref header with language that
experiment because a user of a server who wishes to add support for simply states that it marks blind 302 responses from redirect
the creation of a new resource type can't simply throw in another resources. (Section 6.3, 11.1)
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 Resolution (2003-10-02): Section 6.3 was removed in response to issue
redirect reference resources. 48. In 11.1, 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 for retrieving the target's relative URI. Presence of
the Redirect-Ref header lets the client know that the resource
accepts Apply-To-RR header and the new method for updating target.
Reject Yaron's suggested language, but make the above changes.
C.9 lc-23-body C.7 lc-74-terminology
Type: change Type: change
[11] [8]
reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find
statement that the body of the resource is empty (PostConditions). It some good name for this an use it consistently
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 Resolution (2003-10-02): Remove the whole sentence.
Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
403. See also issue 1.
C.10 lc-47-207 C.8 11.2-apply-to-redirect-ref-syntax
Type: change Type: change
[12] julian.reschke@greenbytes.de (2003-10-17): Many toolkits have
problems sending empty HTTP headers (optimizing them away).
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 Resolution (2003-10-17): Define values "T" and "F" (similar to WevDAV
WebDAV-compliant namespaces. Overwrite header). This will also allow clients to express that they
are aware of redirect extensions without also having to apply the
request to the reference resource.
C.11 lc-49-put C.9 15.1-options-response
Type: change Type: change
[13] julian.reschke@greenbytes.de (2003-10-20): Fix OPTIONS response
("Public" header mentioned, "Allow" header value line break). Remove
yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence irrelevant response headers.
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 Resolution (2003-10-20): Fix.
issue 48.
C.12 lc-75-ignore C.10 lc-79-accesscontrol
Type: change Type: change
[14] [9]
reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments,
header is used on a request to any other sort of resource besides a the owner of a resource might be able to use access control to
redirect reference resource, the server SHOULD ignore it." Don't need prevent others from creating references to that resource." That would
to say this since HTP already says that any header that is not not be consistent with the concept of redirect references as weak
understood should be ignored. links (e.g. think of moving a resource to a different locationo that
is already the target of some redirection reference.
Resolution: Need to keep this to specify what a server that does Resolution (2003-10-02): Remove the statement.
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.
julian.reschke@greenbytes.de (2003-10-13): HTTP seems to distinguish
the following use cases: (a) permanent redirect (301), (b) temporary
redirect (302 or 307), (c) redirect to a GET location after POST
(303) and (d) agent-driven negotiation (300). Among these, (a) and
(b) seem to be well understood, so we should support both. (c)
doesn't seem to be applicable. (d) may become interesting when user
agents start supporting it, so the spec should be flexible enough to
support a feature extension for that. For now I propose that the
client is able to specify the redirection type as a resource type,
such as "DAV:permanent-redirect-reference" and
"DAV:temporary-redirect-reference". This spec would only define the
behaviour for these two resource types and would allow future
extensions using new resource types and suggested response codes.
D.2 lc-38-not-hierarchical D.2 lc-38-not-hierarchical
Type: change Type: change
[15] [10]
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
[16] [11]
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
[17] [12]
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-37-integrity D.5 lc-37-integrity
Type: change Type: change
[18] [13]
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.6 3-terminology-redirectref D.6 3-terminology-redirectref
Type: change Type: change
[19] [14]
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.7 lc-19-direct-ref D.7 lc-19-direct-ref
Type: change Type: change
[20] [15]
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.8 lc-41-no-webdav D.8 lc-41-no-webdav
Type: change Type: change
[21] [16]
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.9 lc-58-update D.9 lc-58-update
Type: change Type: change
[22] [17]
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.10 lc-24-properties D.10 lc-24-properties
Type: change Type: change
[23] [18]
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.11 lc-48-s6 D.11 rfc2606-compliance
Type: editor
julian.reschke@greenbytes.de (2003-10-02): Ensure that examples use
only sample domains as per RFC2606.
D.12 lc-48-s6
Type: change Type: change
[24] [19]
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.12 lc-28-lang D.13 lc-28-lang
Type: edit Type: edit
[25] [20]
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.13 lc-29-lang D.14 lc-29-lang
Type: edit Type: edit
[26] [21]
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.14 lc-44-pseudo D.15 lc-44-pseudo
Type: change Type: change
[27] [22]
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.15 lc-61-pseudo D.16 lc-61-pseudo
Type: change Type: change
[28] [23]
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.16 lc-60-ex
Type: change
[29]
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
limit the client's behavior to these options.
Resolution: Agreed to delete this paragraph. Continue discussion of
what information should be returned with 302 in multistatus. Just
location? Also redirectref?
D.17 lc-62-oldclient D.17 lc-62-oldclient
Type: change Type: change
[30] [24]
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.18 lc-63-move D.18 lc-63-move
Type: change Type: change
[31] [25]
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.19 lc-06-reftarget-relative D.19 lc-57-noautoupdate
Type: change
[32]
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
required to resolve the relative URI and store it as absolute? Is the
server required to keep DAV:reftarget pointing to the target resource
as the reference / target move, or is DAV:reftarget a dead property?
Resolution: DAV:reftarget is readonly and present only on redirect
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 as its value (comes back on all 302 responses). Server
MUST store the target exactly as it is set. It MUST NOT resolve
relatives to absolutes and MUST NOT update if target resource moves.
See also issue 17, 43, 50, 57
D.20 lc-57-noautoupdate
Type: change Type: change
[33] [26]
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.21 lc-71-relative D.20 lc-53-s10
Type: change
[34]
reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the
Request-URI or href minus its final segment.
Resolution: Fix this.
D.22 lc-53-s10
Type: change Type: change
[35] [27]
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.23 lc-72-trailingslash D.21 12.1-property-name
Type: change
[36]
reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget
from ending in "/"
Resolution: Make the note warn about the possibility of two slashes
in a row, recommend against ending target with a slash, since that
could result in two slashes in a row.
D.24 lc-50-blindredirect
Type: change
[37]
yarong@Exchange.Microsoft.com (2000-02-11): Replace current language
explaining the purpose of the Redirect-Ref header with language that
simply states that it marks blind 302 responses from redirect
resources. (Section 6.3, 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
the target (relative URI) as its value. Then we don't need a method
for retrieving the target's relative URI. Presence of the
Redirect-Ref header lets the client know that the resource accepts
Apply-To-RR header and the new method for updating target. Reject
Yaron's suggested language, but make the above changes.
D.25 lc-74-terminology
Type: change Type: change
[38] julian.reschke@greenbytes.de (2003-10-06): Sync names for
DAV:reftarget property and "Redirect-Ref" response headers.
reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find
some good name for this an use it consistently
D.26 lc-76-location D.22 lc-76-location
Type: change Type: change
[39] [28]
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.27 lc-79-accesscontrol D.23 lc-80-i18n
Type: change
[40]
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
prevent others from creating references to that resource." That would
not be consistent with the concept of redirect references as weak
links (e.g. think of moving a resource to a different locationo that
is already the target of some redirection reference.
D.28 lc-80-i18n
Type: change Type: change
[41] [29]
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.29 lc-55-iana julian.reschke@greenbytes.de (2003-10-02): True, but I note that
other specs have re-stated these considerations as well. Opinions?
D.24 lc-55-iana
Type: change Type: change
[42]
[30]
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/