draft-ietf-webdav-redirectref-protocol-03.txt   draft-ietf-webdav-redirectref-protocol-04.txt 
WEBDAV Working Group J. Slein WEBDAV Working Group J. Slein
Internet-Draft Xerox Internet-Draft Xerox
Expires: January 23, 2004 J. Whitehead Expires: March 10, 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
July 25, 2003 September 10, 2003
WebDAV Redirect Reference Resources WebDAV Redirect Reference Resources
draft-ietf-webdav-redirectref-protocol-03.txt draft-ietf-webdav-redirectref-protocol-04
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 January 23, 2004. This Internet-Draft will expire on March 10, 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 is one of a pair of specifications that extend the WebDAV This specification defines redirect reference resources. A redirect
Distributed Authoring Protocol to enable clients to create new access reference resource is a resource whose default response is an HTTP/
paths to existing resources. The two protocol extensions have very 1.1 302 (Found) status code, redirecting the client to a different
different characteristics that make them useful for different sorts resource, the target resource. A redirect reference makes it
of applications. possible to access the target resource indirectly, through any URI
The present specification defines redirect reference resources. A
redirect reference resource is a resource whose default response is
an HTTP/1.1 302 (Found) status code, redirecting the client to a
different resource, the target resource. A redirect reference makes
it possible to access the target resource indirectly, through any URI
mapped to the redirect reference resource. There are no integrity mapped to the redirect reference resource. There are no integrity
guarantees associated with redirect reference resources. guarantees associated with redirect reference resources.
The related specification [B], defines bindings, and the BIND method
for creating them. Creating a new binding to a resource indirectly
creates one or more new URIs mapped to that resource, which can then
be used to access it. Servers are required to insure the integrity
of any bindings that they allow to be created.
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org [1], which may be joined by sending a message w3c-dist-auth@w3.org [1], which may be joined by sending a message
with subject "subscribe" to w3c-dist-auth-request@w3.org [2]. with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL: http:// Discussions of the WEBDAV working group are archived at URL: http://
lists.w3.org/Archives/Public/w3c-dist-auth/. lists.w3.org/Archives/Public/w3c-dist-auth/.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 9 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview of Redirect Reference Resources . . . . . . . . . . 11 4. Overview of Redirect Reference Resources . . . . . . . . . . 9
5. Creating a Redirect Reference Resource . . . . . . . . . . . 12 5. Creating a Redirect Reference Resource . . . . . . . . . . . 10
5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Example: Creating a Redirect Reference Resource with 5.2 Example: Creating a Redirect Reference Resource with
MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 13 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Operations on Redirect Reference Resources . . . . . . . . . 15 6. Operations on Redirect Reference Resources . . . . . . . . . 13
6.1 Example: GET on a Redirect Reference Resource . . . . . . . 16 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 14
6.2 Example: PUT on a Redirect Reference Resource with 6.2 Example: PUT on a Redirect Reference Resource with
Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 16 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 14
6.3 Example: PROPPATCH on a Redirect Reference Resource . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . . 18 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 MOVE and DELETE on Collections That Contain Redirect 7.1 MOVE and DELETE on Collections That Contain Redirect
References . . . . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 LOCK on a Collection That Contains Redirect References . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . 20 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
Reference Resource . . . . . . . . . . . . . . . . . . . . . 22 Reference Resource . . . . . . . . . . . . . . . . . . . . . 20
7.6 Example: LOCK on a Collection That Contains a Redirect 7.6 Example: LOCK on a Collection That Contains a Redirect
Reference Resource . . . . . . . . . . . . . . . . . . . . . 23 Reference Resource . . . . . . . . . . . . . . . . . . . . . 21
8. Operations on Targets of Redirect Reference Resources . . . 26 8. Operations on Targets of Redirect Reference Resources . . . 24
9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 27 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 25
9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 27 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 25
9.2 Example: Resolving a Relative URI in a Multi-Status 9.2 Example: Resolving a Relative URI in a Multi-Status
Response . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Redirect References to Collections . . . . . . . . . . . . . 30 10. Redirect References to Collections . . . . . . . . . . . . . 28
11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 32 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 30
11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 32 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 30
12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 33 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 31
12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 33 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 31
13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 34 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . 35 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 33
15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 36 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 34
15.1 Example: Discovery of Support for Redirect Reference 15.1 Example: Discovery of Support for Redirect Reference
Resources . . . . . . . . . . . . . . . . . . . . . . . . . 36 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 34
16. Security Considerations . . . . . . . . . . . . . . . . . . 37 16. Security Considerations . . . . . . . . . . . . . . . . . . 35
16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 37 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 35
16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 37 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 35
16.3 Redirect Reference Resources and Denial of Service . . . . . 37 16.3 Redirect Reference Resources and Denial of Service . . . . . 35
16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 37 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 35
17. Internationalization Considerations . . . . . . . . . . . . 39 17. Internationalization Considerations . . . . . . . . . . . . 37
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
Normative References . . . . . . . . . . . . . . . . . . . . 42 Normative References . . . . . . . . . . . . . . . . . . . . 40
Informative References . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 A. Changes to the WebDAV Document Type Definition . . . . . . . 42
A. Changes to the WebDAV Document Type Definition . . . . . . . 46 B. Change Log (to be removed by RFC Editor before
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 publication) . . . . . . . . . . . . . . . . . . . . . . . . 43
B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 47 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43
C. Resolved issues . . . . . . . . . . . . . . . . . . . . . . 48 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43
C.1 lc-11-pagination . . . . . . . . . . . . . . . . . . . . . . 48 C. Resolved issues (to be removed by RFC Editor before
C.2 lc-09-notational-after-introduction . . . . . . . . . . . . 48 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44
C.3 lc-13-usually . . . . . . . . . . . . . . . . . . . . . . . 48 C.1 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.4 lc-16-insure . . . . . . . . . . . . . . . . . . . . . . . . 48 C.2 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.5 lc-17-location . . . . . . . . . . . . . . . . . . . . . . . 49 C.3 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.6 lc-21-bind . . . . . . . . . . . . . . . . . . . . . . . . . 49 C.4 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.7 lc-46-bind . . . . . . . . . . . . . . . . . . . . . . . . . 49 C.5 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.8 lc-26-lang . . . . . . . . . . . . . . . . . . . . . . . . . 49 C.6 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.9 lc-03-mkresource-response-cacheability . . . . . . . . . . . 50 C.7 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.10 lc-02-status-codes . . . . . . . . . . . . . . . . . . . . . 50 C.8 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.11 lc-27-lang . . . . . . . . . . . . . . . . . . . . . . . . . 50 C.9 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 46
C.12 lc-30-headers . . . . . . . . . . . . . . . . . . . . . . . 50 C.10 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 46
C.13 lc-32-ORDERPATCH . . . . . . . . . . . . . . . . . . . . . . 51 C.11 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 46
C.14 lc-51-repeat . . . . . . . . . . . . . . . . . . . . . . . . 51 C.12 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 47
C.15 lc-59-depth . . . . . . . . . . . . . . . . . . . . . . . . 51 C.13 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 47
C.16 lc-65-lock . . . . . . . . . . . . . . . . . . . . . . . . . 51 C.14 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 47
C.17 lc-66-depth . . . . . . . . . . . . . . . . . . . . . . . . 52 C.15 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 47
C.18 lc-69-424 . . . . . . . . . . . . . . . . . . . . . . . . . 52 C.16 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.19 lc-68-lock . . . . . . . . . . . . . . . . . . . . . . . . . 52 C.17 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 48
C.20 lc-52-no-relative . . . . . . . . . . . . . . . . . . . . . 53 C.18 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.21 lc-64-reftarget . . . . . . . . . . . . . . . . . . . . . . 53 D. Open issues (to be removed by RFC Editor before
C.22 lc-70-relative . . . . . . . . . . . . . . . . . . . . . . . 53 publication) . . . . . . . . . . . . . . . . . . . . . . . . 49
C.23 lc-73-asciiart . . . . . . . . . . . . . . . . . . . . . . . 53 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 49
C.24 lc-77-webdav-applications . . . . . . . . . . . . . . . . . 54 D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 49
C.25 lc-10-title . . . . . . . . . . . . . . . . . . . . . . . . 54 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 49
C.26 lc-81-typo . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 49
C.27 lc-18-resource-types . . . . . . . . . . . . . . . . . . . . 54 D.5 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 50
C.28 lc-84-ext . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.6 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 50
D. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 56 D.7 3-terminology-redirectref . . . . . . . . . . . . . . . . . 50
D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.8 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 50
D.2 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.9 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 51
D.3 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.10 lc-04-standard-data-container . . . . . . . . . . . . . . . 51
D.4 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56 D.11 lc-05-standard-data-container . . . . . . . . . . . . . . . 51
D.5 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57 D.12 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 51
D.6 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57 D.13 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.7 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57 D.14 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 52
D.8 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 57 D.15 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52
D.9 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 58 D.16 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52
D.10 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 58 D.17 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 53
D.11 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 58 D.18 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.12 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 58 D.19 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 53
D.13 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 59 D.20 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.14 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 59 D.21 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.15 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 59 D.22 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.16 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 59 D.23 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.17 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 60 D.24 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.18 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 60 D.25 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 55
D.19 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 60 D.26 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 56
D.20 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 61 D.27 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 56
D.21 lc-04-standard-data-container . . . . . . . . . . . . . . . 61 D.28 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 56
D.22 lc-05-standard-data-container . . . . . . . . . . . . . . . 61 D.29 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 56
D.23 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 61 D.30 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 57
D.24 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 62 D.31 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 57
D.25 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 62 D.32 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 57
D.26 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 62 D.33 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 58
D.27 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 62 D.34 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 58
D.28 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 63 D.35 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 58
D.29 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 63 D.36 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 59
D.30 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 63 D.37 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 59
D.31 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 64 D.38 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 59
D.32 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 64 D.39 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 59
D.33 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 64 D.40 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.34 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 65 D.41 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.35 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 65 Intellectual Property and Copyright Statements . . . . . . . 61
D.36 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 65
D.37 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.38 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 66
D.39 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 66
D.40 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 66
D.41 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 67
D.42 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.43 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 67
D.44 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 67
D.45 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 68
D.46 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 68
D.47 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 68
D.48 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 69
D.49 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 69
D.50 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 69
D.51 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 70
D.52 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 70
D.53 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 70
D.54 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 70
D.55 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 71
D.56 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 71
D.57 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 71
D.58 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . 72
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 7, 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.
The companion specification [B], defines the BIND method, a different
mechanism for allowing clients to create alternative access paths to
existing WebDAV-compliant resources. The BIND method lets clients
associate a new URI with an existing WebDAV resource. This URI can
then be used to submit requests to the resource. Since URIs of
WebDAV-compliant resources are hierarchical, and correspond to a
hierarchy of collections in resource space, the BIND method also has
the effect of adding the resource to a collection. As new URIs are
associated with the resource, it appears in additional collections.
Redirect references and bindings have very different characteristics:
A redirect reference is a resource, and so can have properties and a A redirect reference is a resource, and so can have properties and a
body of its own. Properties of a redirect reference resource can body of its own. Properties of a redirect reference resource can
contain such information as who created the reference, when, and why. contain such 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.
By contrast, a BIND request does not create a new resource, but
simply makes available a new URI for submitting requests to an
existing resource. The new URI is indistinguishable from any other
URI when submitting a request to a resource. Only one round trip is
needed to submit a request to the intended target. Servers are
required to enforce the integrity of the relationships between the
new URIs and the resources associated with them. Consequently, it
may be very costly for servers to support BIND requests that cross
server boundaries.
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.
Section 6 defines the semantics of existing methods when applied to Section 6 defines the semantics of existing methods when applied to
redirect reference resources, and Section 7 discusses their semantics redirect reference resources, and Section 7 discusses their semantics
when applied to collections that contain redirect reference when applied to collections that contain redirect reference
resources. Sections 8 through 10 discuss several other issues raised resources. Sections 8 through 10 discuss several other issues raised
by the existence of redirect reference resources. Sections 11 by the existence of redirect reference resources. Sections 11
through 14 define the new headers, properties, and XML elements through 14 define the new headers, properties, and XML elements
skipping to change at page 10, line 12 skipping to change at page 8, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
The terminology used here follows and extends that in the WebDAV The terminology used here follows and extends that in the WebDAV
Distributed Authoring Protocol specification [RFC2518]. Definitions Distributed Authoring Protocol specification [RFC2518]. Definitions
of the terms resource, Uniform Resource Identifier (URI), and Uniform of the terms resource, Uniform Resource Identifier (URI), and Uniform
Resource Locator (URL) are provided in [RFC2396]. Resource Locator (URL) are provided in [RFC2396].
Reference Resource
A resource whose purpose is to forward requests to another
resource. Reference resources are an alternative mechanism to
bindings (defined in [B]) for allowing clients to create multiple
URIs that can be used to submit requests to the same resource.
Redirect Reference Resource Redirect Reference Resource
A resource that allows clients to forward requests to another A resource created to redirect all requests made to it, using 302
resource using the HTTP 1.1 302 (Found) response mechanism. The (Found), to a defined target resource.
client is aware that this type of reference resource is mediating
between it and the target resource.
Direct Reference Resource
Direct Reference Resources are out of scope for this
specification, but are defined here for contrast with redirect
reference resources. A direct reference resource automatically
forwards requests to another resource, in a way that is
transparent to the client.
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.
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
to its target resource. It is this characteristic that distinguishes to its target resource. Redirect resources bring the same benefits as
redirect reference resource from direct reference resources and from links in HTML documents. They can be created and maintained without
bindings. It is also what helps to insure that redirect reference the involvement or even knowledge of their target resource. This
resources will be simple to implement and that cross-server reduces the cost of linking between resources."
references will be possible. If the redirect reference resource were
required to forward requests automatically, the server would need
proxy capabilities in order to support cross-server references.
If the client is aware that it is operating on a redirect reference If the client is aware that it is operating on a redirect reference
resource, it can resolve the reference by retrieving the reference resource, it can resolve the reference by retrieving the reference
resource's DAV:reftarget property (defined in Section 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
skipping to change at page 16, line 5 skipping to change at page 14, line 5
The Apply-To-Redirect-Ref header can be used with GET or HEAD to The Apply-To-Redirect-Ref header can be used with GET or HEAD to
retrieve the entity headers of a redirect reference resource. When retrieve the entity headers of a redirect reference resource. When
Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref
entity header MUST be returned. entity header MUST be returned.
A redirect reference resource MAY have a body, though none is defined A redirect reference resource MAY have a body, though none is defined
for it in this specification. The PUT method can be used, with 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 Apply-To-Redirect-Ref, to create or replace the body of a redirect
reference resource. reference resource.
Since MKCOL and MKRESOURCE fail when applied to existing resources,
if the client attempts to resubmit the request to the target
resource, the request MUST fail (unless the reference resource is a
dangling reference). Similarly, if the client attempts to resubmit
the request to the reference resource with an Apply-To-Redirect-Ref
header, the request MUST fail.
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
skipping to change at page 20, line 50 skipping to change at page 18, line 50
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 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
skipping to change at page 22, line 29 skipping to change at page 20, line 29
<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 header is present, the response shows
the properties of the redirect reference resource in the collection the properties of the redirect reference resource in the collection
rather than the properties of its target. The Apply-To-Redirect-Ref rather than reporting a 302 status.
header also prevents a 302 response from being returned for the
redirect reference resource.
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 37, line 46 skipping to change at page 35, line 46
Denial of service attacks were already possible by posting URLs that Denial of service attacks were already possible by posting URLs that
were intended for limited use at heavily used Web sites. The were intended for limited use at heavily used Web sites. The
introduction of MKRESOURCE creates a new avenue for similar denial of introduction of MKRESOURCE creates a new avenue for similar denial of
service attacks. Clients can now create redirect reference resources service attacks. Clients can now create redirect reference resources
at heavily used sites to target locations that were not designed for at heavily used sites to target locations that were not designed for
heavy usage. heavy usage.
16.4 Revealing Private Locations 16.4 Revealing Private Locations
There are several ways that redirect reference resources may reveal There are several ways that redirect reference resources may reveal
information about directory structures. First, the DAV:reftarget information about collection structures. First, the DAV:reftarget
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 directory 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 directory 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.) In some environments, the
owner of a resource might be able to use access control to prevent owner of a resource might be able to use access control to prevent
others from creating references to that resource. 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.
skipping to change at page 40, line 7 skipping to change at page 38, line 7
message in the user's language and character set. message in the user's language and character set.
This specification introduces no new strings that are displayed to This specification introduces no new strings that are displayed to
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
This document uses the namespaces defined by [RFC2518] for properties All IANA considerations mentioned in [RFC2518] also apply to this
and XML elements. All other IANA considerations mentioned in document.
[RFC2518] also apply to this document.
19. Acknowledgements 19. Acknowledgements
This draft has benefited from thoughtful discussion by Jim Amsden, This draft 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, Surendra LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton,
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley
John Stracke, John Tigue, John Turner, Kevin Wiggen, and others. Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
Wiggen, and others.
Normative References Normative References
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
skipping to change at page 43, line 5 skipping to change at page 40, line 30
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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>.
Informative References
[B] Clemm, G., Crawford, J., Reschke, J., Slein, J. and J.
Whitehead, "Binding Extensions to WebDAV", Internet Draft (work
in progress) draft-ietf-webdav-bind-02, June 2003.
URIs
[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> 0266.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> 0266.html>
[5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0286.html>
[6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0359.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/
0266.html> 0287.html>
[9] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [9] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0296.html> 0188.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> 0266.html>
[11] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [11] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0191.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/
0222.html> 0290.html>
[13] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [13] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0291.html>
[14] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [14] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0295.html>
[15] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [15] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0188.html>
[16] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [16] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0301.html> 0266.html>
[17] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [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/ [18] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0304.html>
[19] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [19] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0359.html>
[20] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [20] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0359.html>
[21] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [21] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0289.html>
[22] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [22] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0303.html> 0285.html>
[23] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [23] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0284.html>
[24] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [24] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0306.html>
[25] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [25] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0288.html>
[26] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [26] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0290.html>
[27] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [27] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0294.html>
[28] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [28] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0266.html>
[29] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [29] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0189.html>
[30] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [30] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0189.html>
[31] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [31] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[32] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [32] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[33] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0286.html>
[34] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0287.html>
[35] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html>
[36] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[37] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0289.html>
[38] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0285.html>
[39] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0284.html>
[40] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0306.html>
[41] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0188.html>
[42] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0288.html>
[43] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[44] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[45] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0290.html>
[46] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0291.html>
[47] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0294.html>
[48] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[49] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0295.html>
[50] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0189.html>
[51] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0189.html>
[52] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[53] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [33] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[54] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[55] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [34] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0292.html> 0292.html>
[56] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [35] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0293.html> 0293.html>
[57] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [36] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0308.html> 0308.html>
[58] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [37] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0188.html>
[59] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[60] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [38] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[61] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [39] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0297.html> 0297.html>
[62] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [40] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0298.html> 0298.html>
[63] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [41] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[64] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [42] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html>
[65] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0266.html> 0266.html>
[66] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [43] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0299.html> 0299.html>
[67] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [44] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0302.html> 0302.html>
[68] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [45] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[69] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[70] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [46] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[71] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [47] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[72] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [48] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[73] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [49] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0222.html> 0222.html>
[74] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [50] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0307.html> 0307.html>
[75] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [51] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[76] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [52] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0304.html> 0304.html>
[77] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [53] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[78] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [54] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0304.html>
[79] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0300.html> 0300.html>
[80] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [55] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html>
[81] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0316.html> 0316.html>
[82] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [56] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0316.html>
[83] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [57] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[84] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [58] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[85] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [59] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.html> 0359.html>
[86] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/ [60] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0305.html> 0305.html>
[87] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/
0359.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
Jim Whitehead Jim Whitehead
skipping to change at page 52, line 5 skipping to change at page 47, line 5
<!-- XML Elements from Section 13 --> <!-- XML Elements from Section 13 -->
<!ELEMENT redirectref EMPTY > <!ELEMENT redirectref EMPTY >
<!-- -->Property Elements from Section 12 --> <!-- -->Property Elements from Section 12 -->
<!ELEMENT reftarget href> <!ELEMENT reftarget href>
<!ELEMENT location href> <!ELEMENT location href>
<!-- Changes to the DAV:response Element from Section 14 --> <!-- Changes to the DAV:response Element from Section 14 -->
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), <!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) > responsedescription?) >
Appendix B. Change Log Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1 Since draft-ietf-webdav-redirectref-protocol-02 B.1 Since draft-ietf-webdav-redirectref-protocol-02
Julian Reschke takes editorial role (added to authors list). Cleanup Julian Reschke takes editorial role (added to authors list). Cleanup
XML indentation. Start adding all unresolved last call issues. Update XML indentation. Start adding all unresolved last call issues. Update
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.
Appendix C. Resolved issues B.2 Since draft-ietf-webdav-redirectref-protocol-03
Added Joe Orton and Juergen Reuter to Acknowledgements section. Close
more editorial issues. Remove dependencies on BIND spec.
Appendix C. Resolved issues (to be removed by RFC Editor before
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-11-pagination C.1 lc-07-bind
Type: change Type: change
[3] [3]
reuterj@ira.uka.de (2000-02-07): Don't paginate the review draft. reuterj@ira.uka.de (2000-02-07): Abstract should discuss only
redirect references, not bindings. Expand discussion of redirect
references.
Resolution: We will paginate in accordance with IETF rules, but will Resolution: Abstract will discuss only redirect references. See also
try to produce a nicely formatted review spec as well. issue 34.
C.2 lc-09-notational-after-introduction C.2 lc-08-bind
Type: change Type: change
[4] [4]
reuterj@ira.uka.de (2000-02-07): Move Notational Conventions after reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the
Introduction. binding spec: in the abstract, in the introduction, in the definition
of Reference Resource.
Resolution: Section will be moved. Resolution: Cross-references to bindings will be removed. See also
issue 34.
C.3 lc-13-usually C.3 lc-34-bind
Type: change Type: change
[5] [5]
reuterj@ira.uka.de (2000-02-07): Intro, para 4: Change "usually" to yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all
"possibly" in the sentence "A redirect reference resource is a cross-references to the binding spec. Prefer also removing all
resource in one collection whose purpose is to forward requests to mention of bindings.
another resource (its target), usually in a different collection."
Resolution: Agreed. Resolution: Agreed. See also issues 7, 8, 14
C.4 lc-16-insure C.4 lc-83-bind
Type: change Type: change
[6] [6]
reuterj@ira.uka.de (2000-02-07): Section 4, para 2: Change "It is reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference
also what insures" to "It is also what helps to insure". to the bindings spec.
Resolution: Agreed. Resolution: Agreed.
C.5 lc-17-location C.5 lc-12-bind
Type: change Type: change
[7] [7]
reuterj@ira.uka.de (2000-02-07): Section 4, para 3: Clients should reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction
use the Location header, not the DAV:reftarget property, to find the are identical to those in binding spec. Make sure that any changes
location of the target. The purpose of the DAV:reftarget property made there are also incorporated here.
should be to let the client update its value.
Resolution: We need both Location (which is absolute) and target Resolution: These paragraphs will change as necessary to make the
(which may be relative). See also issue 6, 43. redirect spec completely independent of the rest of WebDAV.
C.6 lc-21-bind C.6 lc-35-bind
Type: change Type: change
[8] [8]
reuterj@ira.uka.de (2000-02-07): Get rid of the binding-dependent yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove
language in the last para of Section 5. paras. 6 and 8 from Intro.
Resolution: Delete all but the first sentence in this paragraph. Resolution: Agreed. See also issue 14.
C.7 lc-46-bind C.7 lc-01-body
Type: change Type: change
[9] [9]
yarong@Exchange.Microsoft.com (2000-02-11): Remove dependency on joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect
bindings from second paragraph of section 5. References: Clarify: Are there 2 resources, one that redirects and
one that responds with its own entity body? Clarify: What is the
Resolution: Agreed. effect of PUT for a URI that currently maps to a redirect reference?
C.8 lc-26-lang Resolution: Redirect resource MUST NOT have a body. See also issue
last call issue 23.
Type: edit C.8 lc-14-bind
Type: change
[10] [10]
reuterj@ira.uka.de (2000-02-07): Change "is not created" to "was not reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to
created" in para 4 under Postconditions of MKRESOURCE. just what is needed to understand the differences from redirect
references. Maybe the paragraph in the Intro that starts "By
contrast, a BIND request . . ." is all that is needed.
Resolution: Editor's discretion. Resolution: Get rid of discussion of bindings altogether. See also
issue 34, 35.
C.9 lc-03-mkresource-response-cacheability C.9 lc-15-direct-ref
Type: change Type: change
[11] [11]
joe@orton.demon.co.uk (2000-01-26): Saying that responses to reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference
MKRESOURCE SHOULD NOT be cached suggests that there are sometimes Resource, since direct references are out of scope. (If you do keep
good reasons to cache responses. Is this the case? the definition, say explicitly that a direct reference resource is a
type of reference resource.)
Resolution: Responses to MKREF MUST NOT be cached. Resolution: Remove definition of Direct Reference Resource. See also
issue 39.
C.10 lc-02-status-codes C.10 lc-39-no-reference-or-direct-resource
Type: change Type: change
[12] [12]
joe@orton.demon.co.uk (2000-01-29): List only new status codes for yarong@Exchange.Microsoft.com (2000-02-11):
MKRESOURCE. Don't discuss previously-defined status codes. NoReferenceOrDirectResource: Remove the definitions of "Reference"
and "Direct Reference Resource." Change the definition of "Redirect
Reference Resource" to be: Redirect Resource: A resource created to
redirect all requests made to it, using 302 (Found), to a defined
target resource.
Resolution: Follow same practice as in binding spec: for existing julian.reschke@greenbytes.de (2003-07-27): (Rename from "redirect
status codes, describe new circumstances that might cause them. Make reference resource" to "redirect resource" delayed for now).
it clear that we are not redefining these codes.
C.11 lc-27-lang Resolution: Agreed. See also issue 15.
Type: edit C.11 lc-40-direct
[13] Type: change
reuterj@ira.uka.de (2000-02-07): Section 6: Change [13]
"non-referencing-aware clients" to "clients not aware of this yarong@Exchange.Microsoft.com (2000-02-11): Assorted changes to
protocol". Section 4, para 2 to get rid of the word "forward" and the word
"server" and remove comparison with direct references.
Resolution: Editor's discretion. Resolution: See also issue 33 (forward). See also issue 36 (server).
Remove discussion of direct references.
C.12 lc-30-headers C.12 lc-45-apply-to-rr
Type: edit Type: change
[14] [14]
reuterj@ira.uka.de (2000-02-07): Section 6, "When Apply-To-RR is used yarong@Exchange.Microsoft.com (2000-02-11): Suggested replacement
with GET or HEAD..." Either give a precise list of the headers that text for this paragraph, which briefly introduces
MUST be returned, or change MUST to SHOULD with the list of examples. Apply-To-Redirect-Ref. Includes a note that even with this header,
the response may be a 302.
Resolution: Delete "along with all HTTP headers that make sense for Resolution: See issue 19 for replacement text. Disagree. Redirect
reference resources (for example, Cache-Control, Age, Etag, Expires, reference will never respond to Apply-To-RR with 302.
and Last-Modified)." See also issue 48.
C.13 lc-32-ORDERPATCH C.13 lc-01A-body
Type: edit Type: change
[15] [15]
reuterj@ira.uka.de (2000-02-07): Section 6. Don't talk about joe@orton.demon.co.uk (2000-01-26): In the definition of MKRESOURCE,
ORDERPATCH, since it hasn't been specified anywhere. "Body" needs to be defined or else terminology changed.
Resolution: Agreed. See also issue 48. Resolution: We will use MKREF instead of MKRESOURCE.
C.14 lc-51-repeat C.14 lc-31-MKCOL
Type: change Type: edit
[16] [16]
yarong@Exchange.Microsoft.com (2000-02-11): The first sentence of reuterj@ira.uka.de (2000-02-07): Section 6, para on MKRESOURCE and
this paragraph says only what's clear from RFC 2518, so will cause MKCOL is obvious and doesn't need to be stated. Maybe show in an
confusion by its presence. Delete it. The last sentence of this example.
paragraph lists methods. That's a bad idea. Remove it.
Resolution: Delete entire paragraph. Resolution: Agreed. See also issue 48.
C.15 lc-59-depth C.15 lc-67-redirectref
Type: change Type: change
[17] [17]
reuterj@ira.uka.de (2000-02-14): Section 7: When a method is being reuterj@ira.uka.de (2000-02-14): 7.4: The explanation should not
applied to a collection with Depth > 0, let Apply-To-Redirect-Ref contrast displaying the properties of the redirect ref with
contain a list of URIs. This way you could have it apply to some displaying the properties of its target, but with returning a 302.
subset of the redirect references in the collection.
Resolution: Declined. Too complex, no use case for it. Resolution: Revise as recommended.
C.16 lc-65-lock C.16 lc-54-s10
Type: change Type: change
[18] [18]
reuterj@ira.uka.de (2000-02-14): "In the case of a redirect reference yarong@Exchange.Microsoft.com (2000-02-11): The Note: in section 10
resource, I think the intended meaning of WebDAV is that the resource has the same problem pointed out in Bindings.NoSlash and needs to be
itself is the internal member to be locked, not the target resource. fixed. It contradicts RFC 2518 and 2616, which both assume that a URL
In so far, I think, the Apply-To-Redirect-Ref header should and the same URL + "/" may map to different resources.
implicitly always be set, and a LOCK request for a collection MUST
fail if in the hierarchy of collections there is an ordinary redirect
reference as internal member."
Resolution: Declined. Behavior will be the same for all methods. No Resolution: Agreed in mailing list discussions that no change is
exceptions. Consistency / simplicity override other considerations needed.
C.17 lc-66-depth C.17 lc-78-directory
Type: change Type: change
[19] [19]
reuterj@ira.uka.de (2000-02-14): 7.3, 7.4: Change "Depth=infinity" to reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to
"Depth: infinity". "collection". Not new to this protocol. Holds for any protocol that
has hierarchical access paths.
Resolution: Agreed.
C.18 lc-69-424 C.18 lc-82-iana
Type: change Type: change
[20] [20]
reuterj@ira.uka.de (2000-02-14): 7.6: Thinks there should not be 424 reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV]
returned for diary.html because it is not an ancestor of a member and say this protocol does not introduce any new considerations.
that caused the lock to fail.
Resolution: No change needed. The interpretation of "dependency" in
the example is correct. It doesn't have to do with ancestor
relationship, only with what caused operation to fail.
C.19 lc-68-lock
Type: change
[21]
reuterj@ira.uka.de (2000-02-14): 7.6: The LOCK example responds with
207, as does the example in RFC 2518, but section 8.10.4 of RFC 2518
says if the lock cannot be granted to all resources the response MUST
be 409 conflict.
Resolution: We'll keep 207 and encourage RFC 2518 to say the same.
(This inconsistency in RFC 2518 is on the WebDAV issues list.)
C.20 lc-52-no-relative
Type: change
[22]
yarong@Exchange.Microsoft.com (2000-02-11): Don't allow relative
URIs. Delete section 9.
Resolution: Declined. Some applications need relative URI.
C.21 lc-64-reftarget
Type: change
[23]
reuterj@ira.uka.de (2000-02-14): Perhaps make DAV:location a real
property, instead of DAV:reftarget, and require it to be an absolute
URI.
Resolution: Declined. Some applications need relative URI. See also
issue 52.
C.22 lc-70-relative
Type: change
[24]
reuterj@ira.uka.de (2000-02-14): Section 9, para 1: Maybe say that
the resulting absolute URI could be any of a number of URIs,
depending on which URI is used in the request to identify the
redirect reference.
Resolution: No change needed.
C.23 lc-73-asciiart
Type: change
[25]
reuterj@ira.uka.de (2000-02-14): Section 10: Replace the ascii art
with Juergen's suggestion (see his message).
Resolution: Replace.
C.24 lc-77-webdav-applications
Type: change
[26]
reuterj@ira.uka.de (2000-02-22): Section 16: Change "WebDAV
applications" to "applications that implement this protocol".
C.25 lc-10-title
Type: change
[27]
reuterj@ira.uka.de (2000-02-07): Change the title of 16.4 so that it
is not a sentence.
Resolution: Change to "Revealing Private Locations".
C.26 lc-81-typo
Type: change
[28]
reuterj@ira.uka.de (2000-02-22): Section 17: Typo "As in [WebDAV}"
Resolution: Fixed.
C.27 lc-18-resource-types
Type: change
[29]
reuterj@ira.uka.de (2000-02-07): Need a registration procedure for
resource types to insure interoperability.
Resolution: We won't hold up this spec to establish a registration
procedure. We will mention in IANA considerations that as the number
of resource types grows the need for a registration procedure
increases, but that there is none at this time.
C.28 lc-84-ext
Type: change
[30]
reuterj@ira.uka.de (2000-02-22): Appendix 24.1: This is not an
extension but a replacement for the WebDAV definition of the response
element.
Resolution: Fixed. Resolution: Simplify, then resolve issue 55.
Appendix D. Open issues 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-07-bind D.2 lc-38-not-hierarchical
Type: change
[31]
reuterj@ira.uka.de (2000-02-07): Abstract should discuss only
redirect references, not bindings. Expand discussion of redirect
references.
Resolution: Abstract will discuss only redirect references. See also
issue 34.
D.3 lc-08-bind
Type: change
[32]
reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the
binding spec: in the abstract, in the introduction, in the definition
of Reference Resource.
Resolution: Cross-references to bindings will be removed. See also
issue 34.
D.4 lc-34-bind
Type: change
[33]
yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all
cross-references to the binding spec. Prefer also removing all
mention of bindings.
Resolution: Agreed. See also issues 7, 8, 14
D.5 lc-35-bind
Type: change
[34]
yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove
paras. 6 and 8 from Intro.
Resolution: Agreed. See also issue 14.
D.6 lc-83-bind
Type: change
[35]
reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference
to the bindings spec.
D.7 lc-12-bind
Type: change
[36]
reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction
are identical to those in binding spec. Make sure that any changes
made there are also incorporated here.
Resolution: These paragraphs will change as necessary to make the
redirect spec completely independent of the rest of WebDAV.
D.8 lc-38-not-hierarchical
Type: change Type: change
[37] [21]
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.9 lc-36-server D.3 lc-36-server
Type: change Type: change
[38] [22]
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.10 lc-33-forwarding D.4 lc-33-forwarding
Type: change Type: change
[39] [23]
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.11 lc-56-notjusthttp D.5 lc-56-notjusthttp
Type: change Type: change
[40] [24]
yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples
and text that the redirection URI could be non-HTTP. and text that the redirection URI could be non-HTTP.
Resolution: We agree that it is possible to create redirect Resolution: We agree that it is possible to create redirect
references to non-HTTP resources. Add example. references to non-HTTP resources. Add example.
D.12 lc-01-body D.6 lc-37-integrity
Type: change
[41]
joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect
References: Clarify: Are there 2 resources, one that redirects and
one that responds with its own entity body? Clarify: What is the
effect of PUT for a URI that currently maps to a redirect reference?
Resolution: Redirect resource MUST NOT have a body. See also issue
last call issue 23.
D.13 lc-37-integrity
Type: change Type: change
[42] [25]
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.14 lc-14-bind D.7 3-terminology-redirectref
Type: change
[43]
reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to
just what is needed to understand the differences from redirect
references. Maybe the paragraph in the Intro that starts "By
contrast, a BIND request . . ." is all that is needed.
Resolution: Get rid of discussion of bindings altogether. See also
issue 34, 35.
D.15 lc-15-direct-ref
Type: change
[44]
reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference
Resource, since direct references are out of scope. (If you do keep
the definition, say explicitly that a direct reference resource is a
type of reference resource.)
Resolution: Remove definition of Direct Reference Resource. See also
issue 39.
D.16 lc-39-no-reference-or-direct-resource
Type: change
[45]
yarong@Exchange.Microsoft.com (2000-02-11):
NoReferenceOrDirectResource: Remove the definitions of "Reference"
and "Direct Reference Resource." Change the definition of "Redirect
Reference Resource" to be: Redirect Resource: A resource created to
redirect all requests made to it, using 302 (Found), to a defined
target resource.
Resolution: Agreed. See also issue 15.
D.17 lc-40-direct
Type: change Type: change
[46] [26]
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). julian.reschke@greenbytes.de (2003-07-27): Consider global rename of
Remove discussion of direct references. "redirect reference resource" to "redirect resource".
D.18 lc-43-webdav D.8 lc-43-webdav
Type: change Type: change
[47] [27]
yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the
DAV:reftarget property. DAV:reftarget property.
Resolution: DAV:reftarget is readonly and is present only for Resolution: DAV:reftarget is readonly and is present only for
redirect references that are also WebDAV resources. We'll also have a redirect references that are also WebDAV resources. We'll also have a
method for setting target; Redirect-Ref header (returned on all 302 method for setting target; Redirect-Ref header (returned on all 302
responses) will have the target as its value. See also issue 6, 17, responses) will have the target as its value. See also issue 6, 17,
50. 50.
D.19 lc-19-direct-ref D.9 lc-19-direct-ref
Type: change Type: change
[48] [28]
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.20 lc-45-apply-to-rr D.10 lc-04-standard-data-container
Type: change
[49]
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.
D.21 lc-04-standard-data-container
Type: change Type: change
[50] [29]
joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs
to be defined in the context of MKRESOURCE to be defined in the context of MKRESOURCE
Resolution: Not relevant once we switch to MKREF. Resolution: Not relevant once we switch to MKREF.
D.22 lc-05-standard-data-container D.11 lc-05-standard-data-container
Type: change Type: change
[51] [30]
joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a
"standard data container" can be created with MKRESOURCE or not. "standard data container" can be created with MKRESOURCE or not.
Resolution: Not relevant once we switch to MKREF. Resolution: Not relevant once we switch to MKREF.
D.23 lc-20-intro-mkresource D.12 lc-20-intro-mkresource
Type: change Type: change
[52] [31]
reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new 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 MKRESOURCE method" to make it clear that it is being introduced for
the first time here. the first time here.
Resolution: Say "The MKREF method defined normatively here . . ." Resolution: Say "The MKREF method defined normatively here . . ."
D.24 lc-22-coll D.13 lc-22-coll
Type: change Type: change
[53] [32]
reuterj@ira.uka.de (2000-02-07): Inconsistency about whether reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
collections can be created with MKRESOURCE. collections can be created with MKRESOURCE.
Resolution: Not relevant for MKREF. Resolution: Not relevant for MKREF.
D.25 lc-25-atomic D.14 lc-25-atomic
Type: change Type: change
[54] [33]
reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a
client? Can another client access the new resource's properties client? Can another client access the new resource's properties
before they have been fully initialized? Maybe the MKRESOURCE request before they have been fully initialized? Maybe the MKRESOURCE request
should let the client ask for it to be atomic. should let the client ask for it to be atomic.
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.26 lc-41-no-webdav D.15 lc-41-no-webdav
Type: change Type: change
[55] [34]
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.27 lc-42-no-webdav D.16 lc-42-no-webdav
Type: change Type: change
[56] [35]
yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method
that creates only redirect references. The MKRESOURCE method hinders that creates only redirect references. The MKRESOURCE method hinders
experiment because a user of a server who wishes to add support for 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 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 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 type. They have to find the code used for MKRESOURCE and change it to
support the new resource type. support the new resource type.
Resolution: We will replace MKRESOURCE with MKREF, which creates only Resolution: We will replace MKRESOURCE with MKREF, which creates only
redirect reference resources. redirect reference resources.
D.28 lc-58-update D.17 lc-58-update
Type: change Type: change
[57] [36]
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.29 lc-01A-body D.18 lc-23-body
Type: change
[58]
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.
D.30 lc-23-body
Type: change Type: change
[59] [37]
reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the 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 statement that the body of the resource is empty (PostConditions). It
would be good if the response to GET included a response body that 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 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 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 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 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 request body. The semantics of the request body is out of scope for
this specification..." Also fix the discussion of example 6.2. this specification..." Also fix the discussion of example 6.2.
Resolution: Redirect references cannot have bodies. GET with Resolution: Redirect references cannot have bodies. GET with
Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
403. See also issue 1. 403. See also issue 1.
D.31 lc-24-properties D.19 lc-24-properties
Type: change Type: change
[60] [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.32 lc-47-207 D.20 lc-47-207
Type: change Type: change
[61] [39]
yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to 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 get rid of the request message body of MKRESOURCE, 207 would not be
an appropriate response code. The description of 409 might lead an appropriate response code. The description of 409 might lead
someone to believe that you can't create redirect references outside someone to believe that you can't create redirect references outside
of WebDAV namespaces. Suggests a different description. of WebDAV namespaces. Suggests a different description.
Resolution: No longer relevant - MKREF can't get a 207 response. Resolution: No longer relevant - MKREF can't get a 207 response.
Revise to make it clear that the first condition will only occur in Revise to make it clear that the first condition will only occur in
WebDAV-compliant namespaces. WebDAV-compliant namespaces.
D.33 lc-48-s6 D.21 lc-48-s6
Type: change Type: change
[62] [40]
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.34 lc-28-lang D.22 lc-28-lang
Type: edit Type: edit
[63] [41]
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.35 lc-29-lang D.23 lc-29-lang
Type: edit Type: edit
[64] [42]
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.36 lc-31-MKCOL D.24 lc-49-put
Type: edit
[65]
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.
D.37 lc-49-put
Type: change Type: change
[66]
[43]
yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence
of Example 6.2, which says that PUT replaces the reference with a of Example 6.2, which says that PUT replaces the reference with a
different resource. different resource.
Resolution: No longer relevant. Deleted this example in response to Resolution: No longer relevant. Deleted this example in response to
issue 48. issue 48.
D.38 lc-44-pseudo D.25 lc-44-pseudo
Type: change Type: change
[67] [44]
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.39 lc-61-pseudo D.26 lc-61-pseudo
Type: change Type: change
[68] [45]
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.40 lc-60-ex D.27 lc-60-ex
Type: change Type: change
[69] [46]
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.41 lc-62-oldclient D.28 lc-62-oldclient
Type: change Type: change
[70] [47]
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.42 lc-63-move D.29 lc-63-move
Type: change Type: change
[71] [48]
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.43 lc-67-redirectref D.30 lc-06-reftarget-relative
Type: change Type: change
[72] [49]
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.
D.44 lc-06-reftarget-relative
Type: change
[73]
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.45 lc-57-noautoupdate D.31 lc-57-noautoupdate
Type: change Type: change
[74] [50]
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.46 lc-71-relative D.32 lc-71-relative
Type: change Type: change
[75] [51]
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.47 lc-53-s10 D.33 lc-53-s10
Type: change Type: change
[76] [52]
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.48 lc-72-trailingslash D.34 lc-72-trailingslash
Type: change Type: change
[77] [53]
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.49 lc-54-s10 D.35 lc-50-blindredirect
Type: change
[78]
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.
D.50 lc-50-blindredirect
Type: change Type: change
[79] [54]
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.51 lc-74-terminology D.36 lc-74-terminology
Type: change Type: change
[80] [55]
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.52 lc-75-ignore D.37 lc-75-ignore
Type: change Type: change
[81] [56]
reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref 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 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 redirect reference resource, the server SHOULD ignore it." Don't need
to say this since HTP already says that any header that is not to say this since HTP already says that any header that is not
understood should be ignored. understood should be ignored.
D.53 lc-76-location D.38 lc-76-location
Type: change Type: change
[82] [57]
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.54 lc-78-directory D.39 lc-79-accesscontrol
Type: change
[83]
reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to
"collection". Not new to this protocol. Holds for any protocol that
has hierarchical access paths.
D.55 lc-79-accesscontrol
Type: change Type: change
[84] [58]
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.56 lc-80-i18n D.40 lc-80-i18n
Type: change Type: change
[85] [59]
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.57 lc-55-iana D.41 lc-55-iana
Type: change Type: change
[86] [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.
D.58 lc-82-iana
Type: change
[87]
reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV]
and say this protocol does not introduce any new considerations.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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