idnits 2.17.1
draft-ietf-webdav-redirectref-protocol-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 913 has weird spacing: '...ment of a 207...'
== Line 914 has weird spacing: '...equests to th...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 17, 2003) is 7459 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'WebDAV' is mentioned on line 1308, but not defined
** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 WEBDAV Working Group J. Whitehead
3 Internet-Draft U.C. Santa Cruz
4 Expires: May 17, 2004 G. Clemm
5 IBM
6 J. Reschke, Ed.
7 greenbytes
8 November 17, 2003
10 WebDAV Redirect Reference Resources
11 draft-ietf-webdav-redirectref-protocol-07
13 Status of this Memo
15 This document is an Internet-Draft and is in full conformance with
16 all provisions of Section 10 of RFC2026.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that other
20 groups may also distribute working documents as Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at http://
28 www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on May 17, 2004.
35 Copyright Notice
37 Copyright (C) The Internet Society (2003). All Rights Reserved.
39 Abstract
41 This specification defines redirect reference resources. A redirect
42 reference resource is a resource whose default response is an HTTP/
43 1.1 302 (Found) status code, redirecting the client to a different
44 resource, the target resource. A redirect reference makes it
45 possible to access the target resource indirectly, through any URI
46 mapped to the redirect reference resource. There are no integrity
47 guarantees associated with redirect reference resources.
49 Distribution of this document is unlimited. Please send comments to
50 the Distributed Authoring and Versioning (WebDAV) working group at
51 w3c-dist-auth@w3.org [1], which may be joined by sending a message
52 with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
54 Discussions of the WEBDAV working group are archived at URL: http://
55 lists.w3.org/Archives/Public/w3c-dist-auth/.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6
61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
62 4. Overview of Redirect Reference Resources . . . . . . . . . . 8
63 5. Creating a Redirect Reference Resource . . . . . . . . . . . 9
64 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 9
65 5.2 Example: Creating a Redirect Reference Resource with
66 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10
67 6. Operations on Redirect Reference Resources . . . . . . . . . 12
68 7. Operations on Collections That Contain Redirect Reference
69 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 13
70 7.1 LOCK on a Collection That Contains Redirect References . . . 13
71 7.2 Example: PROPFIND on a Collection with Redirect Reference
72 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 13
73 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a
74 Collection with Redirect Reference Resources . . . . . . . . 16
75 7.4 Example: COPY on a Collection That Contains a Redirect
76 Reference Resource . . . . . . . . . . . . . . . . . . . . . 17
77 7.5 Example: LOCK on a Collection That Contains a Redirect
78 Reference Resource . . . . . . . . . . . . . . . . . . . . . 18
79 8. Operations on Targets of Redirect Reference Resources . . . 20
80 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 21
81 9.1 Example: Resolving a Relative URI in a Multi-Status
82 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 21
83 10. Redirect References to Collections . . . . . . . . . . . . . 23
84 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 25
85 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 25
86 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 25
87 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 26
88 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 26
89 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 27
90 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 27
91 14. Extensions to the DAV:response XML Element for
92 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 28
93 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 29
94 15.1 Example: Discovery of Support for Redirect Reference
95 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 29
96 16. Security Considerations . . . . . . . . . . . . . . . . . . 30
97 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 30
98 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 30
99 16.3 Redirect Reference Resources and Denial of Service . . . . . 30
100 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 30
101 17. Internationalization Considerations . . . . . . . . . . . . 32
102 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
103 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
104 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
105 Normative References . . . . . . . . . . . . . . . . . . . . 36
106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
107 A. Changes to the WebDAV Document Type Definition . . . . . . . 38
108 B. Change Log (to be removed by RFC Editor before
109 publication) . . . . . . . . . . . . . . . . . . . . . . . . 39
110 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 39
111 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 39
112 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . . 39
113 B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . . 39
114 B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . . 39
115 C. Resolved issues (to be removed by RFC Editor before
116 publication) . . . . . . . . . . . . . . . . . . . . . . . . 40
117 C.1 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 40
118 C.2 rfc2606-compliance . . . . . . . . . . . . . . . . . . . . . 40
119 C.3 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 40
120 C.4 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 40
121 C.5 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 41
122 C.6 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 41
123 C.7 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 41
124 C.8 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 42
125 C.9 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 42
126 C.10 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 42
127 C.11 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 43
128 D. Open issues (to be removed by RFC Editor before
129 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44
130 D.1 old_clients . . . . . . . . . . . . . . . . . . . . . . . . 44
131 D.2 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 44
132 D.3 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 45
133 D.4 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 45
134 D.5 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 45
135 D.6 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 46
136 D.7 3-terminology-redirectref . . . . . . . . . . . . . . . . . 46
137 D.8 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 46
138 D.9 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 46
139 D.10 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 47
140 D.11 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
141 D.12 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 47
142 D.13 12.1-property-name . . . . . . . . . . . . . . . . . . . . . 48
143 D.14 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 48
144 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
145 Intellectual Property and Copyright Statements . . . . . . . 50
147 1. Introduction
149 This is one of a pair of specifications that extend the WebDAV
150 Distributed Authoring Protocol to enable clients to create new access
151 paths to existing resources. This capability is useful for several
152 reasons:
154 URIs of WebDAV-compliant resources are hierarchical and correspond to
155 a hierarchy of collections in resource space. The WebDAV Distributed
156 Authoring Protocol makes it possible to organize these resources into
157 hierarchies, placing them into groupings, known as collections, which
158 are more easily browsed and manipulated than a single flat
159 collection. However, hierarchies require categorization decisions
160 that locate resources at a single location in the hierarchy, a
161 drawback when a resource has multiple valid categories. For example,
162 in a hierarchy of vehicle descriptions containing collections for
163 cars and boats, a description of a combination car/boat vehicle could
164 belong in either collection. Ideally, the description should be
165 accessible from both. Allowing clients to create new URIs that access
166 the existing resource lets them put that resource into multiple
167 collections.
169 Hierarchies also make resource sharing more difficult, since
170 resources that have utility across many collections are still forced
171 into a single collection. For example, the mathematics department at
172 one university might create a collection of information on fractals
173 that contains bindings to some local resources, but also provides
174 access to some resources at other universities. For many reasons, it
175 may be undesirable to make physical copies of the shared resources on
176 the local server: to conserve disk space, to respect copyright
177 constraints, or to make any changes in the shared resources visible
178 automatically. Being able to create new access paths to existing
179 resources in other collections or even on other servers is useful for
180 this sort of case.
182 The redirect reference resources defined here provide a mechanism for
183 creating alternative access paths to existing resources. A redirect
184 reference resource is a resource in one collection whose purpose is
185 to forward requests to another resource (its target), possibly in a
186 different collection. In this way, it allows clients to submit
187 requests to the target resource from another collection. It
188 redirects most requests to the target resource using the HTTP 302
189 (Found) status code, thereby providing a form of mediated access to
190 the target resource.
192 A redirect reference is a resource with properties but no body of its
193 own. Properties of a redirect reference resource can contain such
194 information as who created the reference, when, and why. Since
195 redirect reference resources are implemented using HTTP 302
196 responses, it generally takes two round trips to submit a request to
197 the intended resource. Servers are not required to enforce the
198 integrity of redirect references. Redirect references work equally
199 well for local resources and for resources that reside on a different
200 server from the reference.
202 The remainder of this document is structured as follows: Section 3
203 defines terms that will be used throughout the specification.
204 Section 4 provides an overview of redirect reference resources.
205 Section 5 discusses how to create a redirect reference resource.
206 Section 6 defines the semantics of existing methods when applied to
207 redirect reference resources, and Section 7 discusses their semantics
208 when applied to collections that contain redirect reference
209 resources. Sections 8 through 10 discuss several other issues raised
210 by the existence of redirect reference resources. Sections 11
211 through 14 define the new headers, properties, and XML elements
212 required to support redirect reference resources. Section 15
213 discusses capability discovery. Sections 16 through 18 present the
214 security, internationalization, and IANA concerns raised by this
215 specification. The remaining sections provide a variety of supporting
216 information.
218 2. Notational Conventions
220 Since this document describes a set of extensions to the WebDAV
221 Distributed Authoring Protocol [RFC2518], itself an extension to the
222 HTTP/1.1 protocol, the augmented BNF used here to describe protocol
223 elements is exactly the same as described in Section 2.1 of
224 [RFC2616]. Since this augmented BNF uses the basic production rules
225 provided in Section 2.2 of [RFC2616], these rules apply to this
226 document as well.
228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
230 document are to be interpreted as described in [RFC2119].
232 3. Terminology
234 The terminology used here follows and extends that in the WebDAV
235 Distributed Authoring Protocol specification [RFC2518]. Definitions
236 of the terms resource, Uniform Resource Identifier (URI), and Uniform
237 Resource Locator (URL) are provided in [RFC2396].
239 Redirect Reference Resource
241 A resource created to redirect all requests made to it, using 302
242 (Found), to a defined target resource.
244 Non-Reference Resource
246 A resource that is not a reference to another resource.
248 Target Resource
250 The resource to which requests are forwarded by a reference
251 resource. A target resource can be anything that can be identified
252 by an absolute URI (see [RFC2396], "absoluteURI").
254 4. Overview of Redirect Reference Resources
256 For all operations submitted to a redirect reference resource, the
257 default response is a 302 (Found), accompanied by the Redirect-Ref
258 header (defined in Section 11.1 below) and the Location header set to
259 the URI of the target resource. With this information, the client
260 can resubmit the request to the URI of the target resource.
262 A redirect reference resource never automatically forwards requests
263 to its target resource. Redirect resources bring the same benefits as
264 links in HTML documents. They can be created and maintained without
265 the involvement or even knowledge of their target resource. This
266 reduces the cost of linking between resources."
268 If the client is aware that it is operating on a redirect reference
269 resource, it can resolve the reference by retrieving the reference
270 resource's DAV:reftarget property (defined in Section 12.1 below),
271 whose value contains the URI of the target resource. It can then
272 submit requests to the target resource.
274 A redirect reference resource is a new type of resource. To
275 distinguish redirect reference resources from non-reference
276 resources, a new value of the DAV:resourcetype property (defined in
277 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below.
279 Since a redirect reference resource is a resource, methods can be
280 applied to the reference resource as well as to its target resource.
281 The Apply-To-Redirect-Ref request header (defined in Section 11.2
282 below) is provided so that referencing-aware clients can control
283 whether an operation is applied to the redirect reference resource or
284 standard HTTP/WebDAV behaviour (redirection with a 3xx status code)
285 should occur. The Apply-To-Redirect-Ref header can be used with most
286 requests to redirect reference resources. This header is
287 particularly useful with PROPFIND, to retrieve the reference
288 resource's own properties.
290 5. Creating a Redirect Reference Resource
292 The new MKRESOURCE method is used to create new redirect reference
293 resources. In order to create a redirect reference resource using
294 MKRESOURCE, the values of two properties must be set in the body of
295 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to
296 DAV:redirectref, a new value of DAV:resourcetype defined in Section
297 13.1. The value of DAV:reftarget MUST be set to the URI of the target
298 resource.
300 Used in this way, the MKRESOURCE method creates a redirect reference
301 resource whose target is identified by the DAV:reftarget property.
303 5.1 MKRESOURCE
305 The MKRESOURCE method requests the creation of a redirect reference
306 resource and initialization of its properties in one atomic
307 operation.
309 Preconditions:
311 A resource MUST NOT exist at the Request-URI.
313 Request Marshalling:
315 The location of the new resource to be created is specified by the
316 Request-URI.
318 The request body of the MKRESOURCE method MUST consist of the
319 DAV:propertyupdate XML element defined in Section 12.13 of
320 [RFC2518], specifying a DAV:resourcetype of "DAV:redirectref".
322 Postconditions:
324 If the response status code is 201, a new resource exists at the
325 Request-URI.
327 The properties of the new resource are as specified by the
328 DAV:propertyupdate request body, using PROPPATCH semantics.
330 If the response status code is not 201, then a new resource is not
331 created at the Request-URI, and any existing resource at the
332 Request-URI is unaffected.
334 Response Marshalling:
336 Responses from a MKRESOURCE request MUST NOT be cached, as
337 MKRESOURCE has non-idempotent semantics.
339 The following status codes can be expected in responses to
340 MKRESOURCE:
342 201 (Created): The new resource was successfully created.
344 403 (Forbidden): The server does not allow the creation of the
345 requested resource type at the requested location, or the parent
346 collection of the Request-URI exists but cannot accept members.
348 409 (Conflict): A resource cannot be created at the Request-URI
349 because the parent collection for the resource does not exist, or
350 because there is already a resource at that request-URL.
352 423 (Locked): The Request-URI is locked, and the lock token was
353 not passed with the request.
355 507 (Insufficient Storage): The server does not have sufficient
356 space to record the state of the resource.
358 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE
360 >> Request:
362 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
363 Host: www.example.com
364 Content-Type: text/xml; charset="utf-8"
365 Content-Length: xxx
367
368
369
370
371
372
373 /i-d/draft-webdav-protocol-08.txt
374
375
376
377
379 >> Response:
381 HTTP/1.1 201 Created
383 This request resulted in the creation of a new redirect reference
384 resource at http://www.example.com/~whitehead/dav/spec08.ref, which
385 points to the resource identified by the DAV:reftarget property. In
386 this example, the target resource is identified by the URI http://
387 www.example.com/i-d/draft-webdav-protocol-08.txt. The redirect
388 reference resource's DAV:resourcetype property is set to
389 DAV:redirectref.
391 6. Operations on Redirect Reference Resources
393 Although non-referencing-aware clients cannot create reference
394 resources, they should be able to submit requests through the
395 reference resources created by reference-aware WebDAV clients. They
396 should be able to follow any references to their targets. To make
397 this possible, a server that receives any request made via a redirect
398 reference resource MUST return a 302 (Found) status code, unless the
399 request includes an Apply-To-Redirect-Ref header specifying "T". The
400 client and server MUST follow [RFC2616] Section 10.3.3 "302 Found",
401 but with these additional rules:
403 o The Location response header MUST contain an absolute URI that
404 identifies the target of the reference resource.
406 o The response MUST include the Redirect-Ref header. This header
407 allows reference-aware WebDAV clients to recognize the resource as
408 a reference resource and understand the reason for the
409 redirection.
411 A reference-aware WebDAV client can, like a non-referencing client,
412 resubmit the request to the URI in the Location header in order to
413 operate on the target resource. Alternatively, it can resubmit the
414 request to the URI of the redirect reference resource with the
415 "Apply-To-Redirect-Ref: T" header in order to operate on the
416 reference resource itself. In this case, the request MUST be applied
417 to the reference resource itself, and a 302 response MUST NOT be
418 returned.
420 As redirect references do not have bodies, GET and PUT requests with
421 "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
423 7. Operations on Collections That Contain Redirect Reference Resources
425 Consistent with the rules in Section 6, the response for each
426 redirect reference encountered while processing a collection MUST be
427 a 302 (Found) unless a "Apply-To-Redirect-Ref: T" header is included
428 with the request. The overall response will therefore be a 207
429 (Multi-Status). For each DAV:response element representing a redirect
430 reference, the server MUST include an additional DAV:location
431 element, specifying the value of the "Location" header that would be
432 returned otherwise. The extension is defined in Section 14 below.
434 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be
435 used with any request on a collection. If present, it will be
436 applied to all redirect reference resources encountered while
437 processing the collection.
439 7.1 LOCK on a Collection That Contains Redirect References
441 An attempt to lock (with Depth: infinity) a collection that contains
442 redirect references without specifying "Apply-To-Redirect-Ref: T"
443 will always fail. The Multi-Status response will contain a 302
444 response for each redirect reference.
446 Reference-aware clients can lock the collection by using
447 Apply-To-Redirect-Ref, and, if desired, lock the targets of the
448 redirect references individually.
450 Non-referencing clients must resort to locking each resource
451 individually.
453 7.2 Example: PROPFIND on a Collection with Redirect Reference Resources
455 Suppose a PROPFIND request with Depth: infinity is submitted to the
456 following collection, with the members shown here:
458 /MyCollection/
459 (non-reference resource) diary.html
460 (redirect reference resource) nunavut
462 >> Request:
464 PROPFIND /MyCollection/ HTTP/1.1
465 Host: example.com
466 Depth: infinity
467 Apply-To-Redirect-Ref: F
468 Content-Type: text/xml
469 Content-Length: xxxx
471
472
473
474
475
476
477
478 >> Response:
480 HTTP/1.1 207 Multi-Status
481 Content-Type: text/xml
482 Content-Length: xxxx
484
485
486
487 /MyCollection/
488
489
490
491 diary, interests, hobbies
492
493 HTTP/1.1 200 OK
494
495
496
497 /MyCollection/diary.html
498
499
500
501 diary, travel, family, history
502
503 HTTP/1.1 200 OK
504
505
506
507 /MyCollection/nunavut
508 HTTP/1.1 302 Found
509
510 http://example.ca/art/inuit/
511
512
513
515 In this example the Depth header is set to infinity, and the
516 Apply-To-Redirect-Ref header is set to "F". The collection contains
517 one URI that identifies a redirect reference resource. The response
518 element for the redirect reference resource has a status of 302
519 (Found), and includes a DAV:location extension element to allow
520 clients to retrieve the properties of its target resource. (The
521 response element for the redirect reference resource does not include
522 the requested properties. The client can submit another PROPFIND
523 request to the URI in the DAV:location pseudo-property to retrieve
524 those properties.)
526 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
527 Redirect Reference Resources
529 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:
530 infinity is submitted to the following collection, with the members
531 shown here:
533 /MyCollection/
534 (non-reference resource) diary.html
535 (redirect reference resource) nunavut
537 >> Request:
539 PROPFIND /MyCollection/ HTTP/1.1
540 Host: example.com
541 Depth: infinity
542 Apply-To-Redirect-Ref: T
543 Content-Type: text/xml
544 Content-Length: xxxx
546
547
548
549
550
551
552
554 >> Response:
556 HTTP/1.1 207 Multi-Status
557 Content-Type: text/xml
558 Content-Length: xxxx
560
561
562
563 /MyCollection/
564
565
566
567
568 HTTP/1.1 200 OK
569
570
571
572 HTTP/1.1 404 Not Found
573
575
576
577 /MyCollection/diary.html
578
579
580
581
582 HTTP/1.1 200 OK
583
584
585
586 HTTP/1.1 404 Not Found
587
588
589
590 /MyCollection/nunavut
591
592
593
594
595 http://example.ca/art/inuit/
596
597
598 HTTP/1.1 200 OK
599
600
601
603 Since the "Apply-To-Redirect-Ref: T" header is present, the response
604 shows the properties of the redirect reference resource in the
605 collection rather than reporting a 302 status.
607 7.4 Example: COPY on a Collection That Contains a Redirect Reference
608 Resource
610 Suppose a COPY request is submitted to the following collection, with
611 the members shown:
613 /MyCollection/
614 (non-reference resource) diary.html
615 (redirect reference resource) nunavut with target
616 /Someplace/nunavut.map
618 >> Request:
620 COPY /MyCollection/ HTTP/1.1
621 Host: example.com
622 Depth: infinity
623 Destination: http://example.com/OtherCollection/
625 >> Response:
627 HTTP/1.1 207 Multi-Status
628 Content-Type: text/xml; charset="utf-8"
629 Content-Length: xxx
631
632
633
634 /MyCollection/nunavut
635 HTTP/1.1 302 Found
636
637 http://example.com//Someplace/nunavut.map
638
639
640
642 In this case, since /MyCollection/nunavut is a redirect reference
643 resource, the COPY operation was only a partial success. The
644 redirect reference resource was not copied, but a 302 response was
645 returned for it. So the resulting collection is as follows:
647 /OtherCollection/
648 (non-reference resource) diary.html
650 7.5 Example: LOCK on a Collection That Contains a Redirect Reference
651 Resource
653 Suppose a LOCK request is submitted to the following collection, with
654 the members shown:
656 /MyCollection/
657 (non-reference resource) diary.html
658 (redirect reference resource) nunavut
660 >> Request:
662 LOCK /MyCollection/ HTTP/1.1
663 Host: example.com
664 Apply-To-Redirect-Ref: F
665 Content-Type: text/xml
667
668
669
670
671
673 >> Response:
675 HTTP/1.1 207 Multi-Status
676 Content-Type: text/xml
677 Content-Length: nnnn
679
680
681
682 /MyCollection/
683 HTTP/1.1 424 Failed Dependency
684
685
686 /MyCollection/diary.html
687 HTTP/1.1 424 Failed Dependency
688
689
690 /MyCollection/nunavut
691 HTTP/1.1 302 Found
692
693 http://example.ca/art/inuit/
694
695
696
698 The server returns a 302 response code for the redirect reference
699 resource in the collection. Consequently, neither the collection nor
700 any of the resources identified by its internal member URIs were
701 locked. A referencing-aware client can submit a separate LOCK request
702 to the URI in the DAV:location element returned for the redirect
703 reference resource, and can resubmit the LOCK request with the
704 Apply-To-Redirect-Ref header to the collection. At that point both
705 the reference resource and its target resource will be locked (as
706 well as the collection and all the resources identified by its other
707 members).
709 8. Operations on Targets of Redirect Reference Resources
711 Operations on targets of redirect reference resources have no effect
712 on the reference resource.
714 9. Relative URIs in DAV:reftarget
716 The URI in the href in a DAV:reftarget property MAY be a relative
717 URI. In this case, the base URI to be used for resolving the relative
718 URI to absolute form is the URI used in the HTTP message to identify
719 the redirect reference resource to which the DAV:reftarget property
720 belongs.
722 When DAV:reftarget appears in the context of a Multi-Status response,
723 it is in a DAV:response element that contains a single DAV:href
724 element. The value of this DAV:href element serves as the base URI
725 for resolving a relative URI in DAV:reftarget. The value of DAV:href
726 may itself be relative, in which case it must be resolved first in
727 order to serve as the base URI for the relative URI in DAV:reftarget.
728 If the DAV:href element is relative, its base URI is constructed from
729 the scheme component "http", the value of the Host header in the
730 request, and the request-URI.
732 9.1 Example: Resolving a Relative URI in a Multi-Status Response
734 >> Request:
736 PROPFIND /geog/ HTTP/1.1
737 Host: example.com
738 Apply-To-Redirect-Ref: T
739 Depth: 1
740 Content-Type: text/xml
741 Content-Length: nnn
743
744
745
746
747
748
749
750 >> Response:
752 HTTP/1.1 207 Multi-Status
753 Content-Type: text/xml
754 Content-Length: nnn
756
757
758
759 /geog/
760
761
762
763
764 HTTP/1.1 200 OK
765
766
767
768 HTTP/1.1 404 Not Found
769
770
771
772 /geog/stats.html
773
774
775
776
777 statistics/population/1997.html
778
779
780 HTTP/1.1 200 OK
781
782
783
785 In this example, the relative URI statistics/population/1997.html is
786 returned as the value of reftarget for the reference resource
787 identified by href /geog/stats.html. The href is itself a relative
788 URI, which resolves to http://example.com/geog/stats.html. This is
789 the base URI for resolving the relative URI in reftarget. The
790 absolute URI of reftarget is http://example.com/geog/statistics/
791 population/1997.html.
793 10. Redirect References to Collections
795 In a Request-URI /segment1/segment2/segment3, any of the three
796 segments may identify a redirect reference resource. (See [RFC2396],
797 Section 3.3, for definitions of "path" and "segment".) If any
798 segment in a Request-URI identifies a redirect reference resource,
799 the response SHOULD be a 302. The value of the Location header in the
800 302 response is as follows:
802 The leftmost path segment of the request-URI that identifies a
803 redirect reference resource, together with all path segments and
804 separators to the left of it, is replaced by the value of the
805 redirect reference resource's DAV:reftarget property (resolved to an
806 absolute URI). The remainder of the request-URI is concatenated to
807 this path.
809 Note: If the DAV:reftarget property ends with a "/" and the remainder
810 of the Request-URI is non-empty (and therefore must begin with a "/
811 "), the final "/" in the DAV:reftarget property is dropped before the
812 remainder of the Request-URI is appended.
814 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect
815 reference resource whose target resource is collection /a/, which
816 contains redirect reference resource y whose target resource is
817 collection /b/, which contains redirect reference resource z.html
818 whose target resource is /c/d.html.
820 /x/y/z.html
821 |
822 | /x -> /a
823 |
824 v
825 /a/y/z.html
826 |
827 | /a/y -> /b
828 |
829 v
830 /b/z.html
831 |
832 | /b/z.html -> /c/d.html
833 |
834 v
835 /c/d.html
837 In this case the client must follow up three separate 302 responses
838 before finally reaching the target resource. The server responds to
839 the initial request with a 302 with Location: /a/y/z.html, and the
840 client resubmits the request to /a/y/z.html. The server responds to
841 this request with a 302 with Location: /b/z.html, and the client
842 resubmits the request to /b/z.html. The server responds to this
843 request with a 302 with Location: /c/d.html, and the client resubmits
844 the request to /c/d.html. This final request succeeds.
846 Note: the behavior described above may have a very serious impact
847 on the efficiency of mapping Request-URIs to resources in HTTP
848 request processing. Therefore servers MAY respond with a 404
849 status code if the cost of checking all leading path segments for
850 redirect references seems prohibitive.
852 11. Headers
854 11.1 Redirect-Ref Response Header
856 Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI)
857 ; see sections 3 and 5 of [RFC2396]
859 The Redirect-Ref header is used in all 302 responses from redirect
860 reference resources. The value is the (possibly relative) URI of the
861 link target as specified during redirect reference resource creation.
863 11.2 Apply-To-Redirect-Ref Request Header
865 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
867 The optional Apply-To-Redirect-Ref header can be used on any request
868 to a redirect reference resource. When it is present and set to "T",
869 the request MUST be applied to the reference resource itself, and a
870 302 response MUST NOT be returned.
872 If the Apply-To-Redirect-Ref header is used on a request to any other
873 sort of resource besides a redirect reference resource, the server
874 MUST ignore it.
876 12. Properties
878 12.1 reftarget Property
880 Name: reftarget
882 Namespace: DAV:
884 Purpose: A property of redirect reference resources that provides an
885 efficient way for clients to discover the URI of the target
886 resource. This is a read-only property after its initial
887 creation. Its value can only be set in a MKRESOURCE request.
889 Value: href containing the URI of the target resource. This value
890 MAY be a relative URI. The reftarget property can occur in the
891 entity bodies of MKRESOURCE requests and of responses to PROPFIND
892 requests.
894
896 13. XML Elements
898 13.1 redirectref XML Element
900 Name: redirectref
902 Namespace: DAV:
904 Purpose: Used as the value of the DAV:resourcetype property to
905 specify that the resource type is a redirect reference resource.
907
909 14. Extensions to the DAV:response XML Element for Multi-Status
910 Responses
912 As described in Section 7, the DAV:location element may be returned
913 in the DAV:response element of a 207 Multi-Status response, to allow
914 clients to resubmit their requests to the target resource of a
915 redirect reference resource.
917 Consequently, the definition of the DAV:response XML element changes
918 to the following:
920
922
924 15. Capability Discovery
926 Sections 9.1 and 15 of [RFC2518] describe the use of compliance
927 classes with the DAV header in responses to OPTIONS, to indicate
928 which parts of the WebDAV Distributed Authoring protocols the
929 resource supports. This specification defines an OPTIONAL extension
930 to [RFC2518]. It defines a new compliance class, called
931 redirectrefs, for use with the DAV header in responses to OPTIONS
932 requests. If a resource does support redirect references, its
933 response to an OPTIONS request may indicate that it does, by listing
934 the new redirectrefs compliance class in the DAV header and by
935 listing the MKRESOURCE method as one it supports.
937 When responding to an OPTIONS request, any type of resource can
938 include redirectrefs in the value of the DAV header. Doing so
939 indicates that the server permits a redirect reference resource at
940 the request URI.
942 15.1 Example: Discovery of Support for Redirect Reference Resources
944 >> Request:
946 OPTIONS /somecollection/someresource HTTP/1.1
947 Host: example.org
949 >> Response:
951 HTTP/1.1 200 OK
952 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
953 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
954 DAV: 1, 2, redirectrefs
956 The DAV header in the response indicates that the resource /
957 somecollection/someresource is level 1 and level 2 compliant, as
958 defined in [RFC2518]. In addition, /somecollection/someresource
959 supports redirect reference resources. The Allow header indicates
960 that MKRESOURCE requests can be submitted to /somecollection/
961 someresource.
963 16. Security Considerations
965 This section is provided to make applications that implement this
966 protocol aware of the security implications of this protocol.
968 All of the security considerations of HTTP/1.1 and the WebDAV
969 Distributed Authoring Protocol specification also apply to this
970 protocol specification. In addition, redirect reference resources
971 introduce several new security concerns and increase the risk of some
972 existing threats. These issues are detailed below.
974 16.1 Privacy Concerns
976 By creating redirect reference resources on a trusted server, it is
977 possible for a hostile agent to induce users to send private
978 information to a target on a different server. This risk is
979 mitigated somewhat, since clients are required to notify the user of
980 the redirection for any request other than GET or HEAD. (See
981 [RFC2616], Section 10.3.3 302 Found.)
983 16.2 Redirect Loops
985 Although redirect loops were already possible in HTTP 1.1, the
986 introduction of the MKRESOURCE method creates a new avenue for
987 clients to create loops accidentally or maliciously. If the
988 reference resource and its target are on the same server, the server
989 may be able to detect MKRESOURCE requests that would create loops.
990 See also [RFC2616], Section 10.3 "Redirection 3xx."
992 16.3 Redirect Reference Resources and Denial of Service
994 Denial of service attacks were already possible by posting URLs that
995 were intended for limited use at heavily used Web sites. The
996 introduction of MKRESOURCE creates a new avenue for similar denial of
997 service attacks. Clients can now create redirect reference resources
998 at heavily used sites to target locations that were not designed for
999 heavy usage.
1001 16.4 Revealing Private Locations
1003 There are several ways that redirect reference resources may reveal
1004 information about collection structures. First, the DAV:reftarget
1005 property of every redirect reference resource contains the URI of the
1006 target resource. Anyone who has access to the reference resource can
1007 discover the collection path that leads to the target resource. The
1008 owner of the target resource may have wanted to limit knowledge of
1009 this collection structure.
1011 Sufficiently powerful access control mechanisms can control this risk
1012 to some extent. Property-level access control could prevent users
1013 from examining the DAV:reftarget property. (The Location header
1014 returned in responses to requests on redirect reference resources
1015 reveals the same information, however.)
1017 This risk is no greater than the similar risk posed by HTML links.
1019 17. Internationalization Considerations
1021 All internationalization considerations mentioned in [RFC2518] also
1022 apply to this document.
1024 18. IANA Considerations
1026 All IANA considerations mentioned in [RFC2518] also apply to this
1027 document.
1029 19. Contributors
1031 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein
1032 who can take credit for big parts of the original design of this
1033 specification.
1035 20. Acknowledgements
1037 This document has benefited from thoughtful discussion by Jim Amsden,
1038 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
1039 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
1040 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt,
1041 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
1042 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton,
1043 Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley
1044 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
1045 Wiggen, and others.
1047 Normative References
1049 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1050 Requirement Levels", BCP 14, RFC 2119, March 1997.
1052 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1053 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1054 August 1998.
1056 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1057 Jensen, "HTTP Extensions for Distributed Authoring --
1058 WEBDAV", RFC 2518, February 1999.
1060 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1061 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1062 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1064 [1]
1066 [2]
1068 Authors' Addresses
1070 Jim Whitehead
1071 UC Santa Cruz, Dept. of Computer Science
1072 1156 High Street
1073 Santa Cruz, CA 95064
1074 US
1076 EMail: ejw@cse.ucsc.edu
1078 Geoff Clemm
1079 IBM
1080 20 Maguire Road
1081 Lexington, MA 02421
1082 US
1084 EMail: geoffrey.clemm@us.ibm.com
1085 Julian F. Reschke (editor)
1086 greenbytes GmbH
1087 Salzmannstrasse 152
1088 Muenster, NW 48159
1089 Germany
1091 Phone: +49 251 2807760
1092 Fax: +49 251 2807761
1093 EMail: julian.reschke@greenbytes.de
1094 URI: http://greenbytes.de/tech/webdav/
1096 Appendix A. Changes to the WebDAV Document Type Definition
1098
1099
1100 Property Elements from Section 12 -->
1101
1102
1103
1104
1107 Appendix B. Change Log (to be removed by RFC Editor before publication)
1109 B.1 Since draft-ietf-webdav-redirectref-protocol-02
1111 Julian Reschke takes editorial role (added to authors list). Cleanup
1112 XML indentation. Start adding all unresolved last call issues. Update
1113 some author's contact information. Update references, split into
1114 "normative" and "informational". Remove non-RFC2616 headers
1115 ("Public") from examples. Fixed width problems in artwork. Start
1116 resolving editorial issues.
1118 B.2 Since draft-ietf-webdav-redirectref-protocol-03
1120 Added Joe Orton and Juergen Reuter to Acknowledgements section. Close
1121 more editorial issues. Remove dependencies on BIND spec.
1123 B.3 Since draft-ietf-webdav-redirectref-protocol-04
1125 More editorial fixes. Clarify that MKRESOURCE can only be used to
1126 create redirect references (switch to new method in a future draft).
1127 Clarify that redirect references do not have bodies.
1129 B.4 Since draft-ietf-webdav-redirectref-protocol-05
1131 Close (accept) issue "lc-79-accesscontrol". Add issue
1132 "rfc2606-compliance". Close issues "lc-50-blindredirect",
1133 "lc-71-relative", "lc-74-terminology". Update contact info for Geoff
1134 Clemm. Moved some of the original authors names to new Contributors
1135 section. Add and close issue "9-MKRESOURCE-vs-relative-URI". Close
1136 issue "lc-72-trailingslash". Close issue "lc-60-ex". Update issue
1137 "lc-85-301" with proposal. Close issue "lc-06-reftarget-relative"
1138 (9-MKRESOURCE-vs-relative-URI was a duplicate of this one). Also
1139 remove section 9.1 (example for MKRESOURCE vs relative URIs). Add
1140 and resolve issue "11.2-apply-to-redirect-ref-syntax" (header now has
1141 values "T" and "F"). Also some cleanup for "rfc2606-compliance".
1142 Typo fixes. Add and resolve "15.1-options-response".
1144 B.5 Since draft-ietf-webdav-redirectref-protocol-06
1146 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang",
1147 "lc-44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move",
1148 "lc-80-i18n" and "rfc2606-compliance". Start work on index. Add new
1149 issue "old_clients".
1151 Appendix C. Resolved issues (to be removed by RFC Editor before
1152 publication)
1154 Issues that were either rejected or resolved in this version of this
1155 document.
1157 C.1 lc-19-direct-ref
1159 Type: change
1161
1164 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6,
1165 para 3 discussions of the Apply-to-Redirect-Ref header make it sound
1166 as if we are specifying direct reference behavior.
1168 Resolution (2003-11-04): Change these passages so that the contrast
1169 is between applying the method to the redirect reference and
1170 responding with a 302.
1172 C.2 rfc2606-compliance
1174 Type: editor
1176 julian.reschke@greenbytes.de (2003-10-02): Ensure that examples use
1177 only sample domains as per RFC2606.
1179 C.3 lc-28-lang
1181 Type: edit
1183
1186 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence
1187 "A reference-aware WebDAV client can act on this response in one of
1188 two ways." A client can act on the response in any way it wants.
1190 Resolution (2003-11-04): Agreed. See also issue 48.
1192 C.4 lc-29-lang
1194 Type: edit
1196
1198 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't
1199 need to be stated. Maybe note in an example.
1201 Resolution (2003-11-04): Agreed. See also issue 48.
1203 C.5 lc-44-pseudo
1205 Type: change
1207
1210 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an
1211 optional prop XML element to the response element in 207 responses,
1212 define a new location XML element and a new refresource XML element.
1214 Resolution: Agree to define new XML elements that are not
1215 pseudo-properties. Disagreement about whether refresource is needed.
1216 See issue 61.
1218 C.6 lc-61-pseudo
1220 Type: change
1222
1225 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to
1226 ask future editors of RFC 2518 to define DAV:location with the
1227 semantics it has here. RFC 2518 should provide the information in the
1228 Location header somehow in multistatus responses, but not by using
1229 properties.
1231 Resolution (2003-10-31): Define an XML element for location that is
1232 not a pseudo-property. We'll keep the recommendation that RFC 2518
1233 add this for 302 responses. See also issue 44.
1235 C.7 lc-62-oldclient
1237 Type: change
1239
1242 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim
1243 that non-referencing clients can't process 302 responses occurring in
1244 Multi-Status responses. They just have an extra round trip for each
1245 302.
1247 Resolution (2003-10-31): Remove last sentence of the paragraph that
1248 recommends changes to RFC 2518.
1250 C.8 lc-63-move
1252 Type: change
1254
1257 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the
1258 perspective of a client? Agrees that there should be no 302s for
1259 member redirect references, but finds the rationale dubious.
1261 Resolution (2003-11-11): Remove 7.1. Reword 7.2 to avoid concerns
1262 with "poses special problems" and "due to atomicity".
1264 C.9 lc-53-s10
1266 Type: change
1268
1271 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in
1272 this section would have a very serious impact on the efficiency of
1273 mapping Request-URIs to resources in HTTP request processing. Also
1274 specify another type of redirect resource that does not behave as in
1275 section 10, but instead would "expose the behavior we see today in
1276 various HTTP servers that allow their users to create 300 resources."
1277 Be sure we know what behavior will be if the redirect location is not
1278 an HTTP URL, but, say ftp.
1280 Resolution (2003-11-04): We won't define 2 sorts of redirect
1281 references here. Servers SHOULD respond with 302 as described here,
1282 but if they can't do that, respond with 404 Not Found. (It's hard to
1283 modularize the behavior specified - it impacts processing Not Found
1284 cases of all methods, so you can't just add it to an HTTP server in a
1285 redirect ref module.)
1287 C.10 lc-76-location
1289 Type: change
1291
1294 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real
1295 (live) property, get rid of the DAV:reftarget property
1297 Resolution (2003-10-31): Pseudo-property was removed.
1299 C.11 lc-80-i18n
1301 Type: change
1303
1306 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot
1307 of this section, since this protocol extends WebDAV. Just reference
1308 [WebDAV].
1310 julian.reschke@greenbytes.de (2003-10-02): True, but I note that
1311 other specs have re-stated these considerations as well. Opinions?
1313 Resolution (2003-11-11): Just point to RFC2518. Remove RFC2277 and
1314 XML from references (not needed anymore).
1316 Appendix D. Open issues (to be removed by RFC Editor before publication)
1318 D.1 old_clients
1320 Type: change
1322
1325 julian.reschke@greenbytes.de (2003-11-10): There are (at least) two
1326 major design goals, but unfortunately both are in direct
1327 contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This
1328 means that any request that addresses a redirect reference resource
1329 MUST result in a 3xx status code (obviously the whole point is that
1330 GET MUST result in a redirection, and if it does, it's hard to say
1331 why other methods such as PUT or DELETE should behave differently).
1332 Therefore, the redirect reference protocol introduces a new request
1333 header ("Apply-To-Redirect-Ref") through which a client can indicate
1334 that the request indeed should be applied to the redirect reference
1335 resource itself. #2: Maximum usability with existing clients. For
1336 instance, the Microsoft Webfolder client will not be able to DELETE a
1337 redirect reference resource unless the server deviates from #1. Right
1338 now I'm not sure about the best way to resolve this. Currently the
1339 spec chooses #1 (back when this decision was made, there was probably
1340 the assumption that existing clients would quickly be updated --
1341 something that probably isn't true today). However this may result in
1342 implementers either just ignoring these rules, or adding special
1343 workarounds based on "User Agent" detection.
1345 D.2 lc-85-301
1347 Type: change
1349 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302
1350 redirects, especially 301.
1352 julian.reschke@greenbytes.de (2003-10-13): HTTP seems to distinguish
1353 the following use cases: (a) permanent redirect (301), (b) temporary
1354 redirect (302 or 307), (c) redirect to a GET location after POST
1355 (303) and (d) agent-driven negotiation (300). Among these, (a) and
1356 (b) seem to be well understood, so we should support both. (c)
1357 doesn't seem to be applicable. (d) may become interesting when user
1358 agents start supporting it, so the spec should be flexible enough to
1359 support a feature extension for that. For now I propose that the
1360 client is able to specify the redirection type as a resource type,
1361 such as "DAV:permanent-redirect-reference" and
1362 "DAV:temporary-redirect-reference". This spec would only define the
1363 behaviour for these two resource types and would allow future
1364 extensions using new resource types and suggested response codes.
1366 D.3 lc-38-not-hierarchical
1368 Type: change
1370
1373 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The
1374 first sentence of the second paragraph of the introduction of the
1375 redirect spec asserts that the URIs of WebDAV compliant resources
1376 match to collections. The WebDAV standard makes no such requirement.
1377 I therefore move that this sentence be stricken.
1379 Resolution: State the more general HTTP rationale first (alternative
1380 names for the same resource), then introduce the collection hierarchy
1381 rationale, which applies only if you are in a WebDAV-compliant space.
1383 D.4 lc-36-server
1385 Type: change
1387
1390 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"
1391 with "unrelated system" throughout.
1393 Resolution: Try replacing "server" with "host" in some contexts,
1394 rephrasing in passive voice in others. See also issue 40.
1396 D.5 lc-33-forwarding
1398 Type: change
1400
1403 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace
1404 "forward" with "redirect" throughout.
1406 Resolution: Use "redirect" for the behavior redirect resources do
1407 exhibit. Use "forward" for the contrasting behavior (passing a method
1408 on to the target with no client action needed). Define these two
1409 terms. See also issue 40.
1411 D.6 lc-37-integrity
1413 Type: change
1415
1418 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7
1419 "Servers are not required to enforce the integrity of redirect
1420 references." Integrity is not defined. Replace with something
1421 clearer.
1423 Resolution: Rewrite to say that the server MUST NOT update the target
1424 See also issue 6.
1426 D.7 3-terminology-redirectref
1428 Type: change
1430
1433 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of
1434 "redirect reference resource" to "redirect resource".
1436 D.8 lc-41-no-webdav
1438 Type: change
1440
1443 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references
1444 independent of the rest of WebDAV. The creation method for redirect
1445 references shouldn't require an XML request body.
1447 Resolution: We will make redirect references independent of the rest
1448 of WebDAV. MKREF will not have an XML request body.
1450 D.9 lc-58-update
1452 Type: change
1454
1457 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way
1458 to update the target of a redirect reference.
1460 Resolution: Agreed. See also issues 6, 43.
1462 D.10 lc-24-properties
1464 Type: change
1466
1469 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence
1470 "The properties of the new resource are as specified by the
1471 DAV:propertyupdate request body, using PROPPATCH semantics" with the
1472 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate
1473 request body to initialize resource properties. Herein, the semantics
1474 is the same as when sending a MKRESOURCE request without a request
1475 body, followed by a PROPPATCH with the DAV:propertyupdate request
1476 body."
1478 Resolution: No longer relevant once we switch to MKREF with no
1479 request body.
1481 D.11 lc-48-s6
1483 Type: change
1485
1488 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6
1489 with just this: A redirect resource, upon receiving a request without
1490 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)
1491 response. The 302 (Found) response MUST include a location header
1492 identifying the target and a Redirect-Ref header. If a redirect
1493 resource receives a request with an Apply-To-Redirect-Ref header then
1494 the redirect reference resource MUST apply the method to itself
1495 rather than blindly returning a 302 (Found) response.
1497 Resolution: Keep a summary along the lines of Yaron's proposal (don't
1498 use the word "blindly"). Keep the bullets detailing the headers to be
1499 returned. Delete the rest, including the examples. See also issue 28,
1500 29, 30, 31, 32.
1502 D.12 lc-57-noautoupdate
1504 Type: change
1506
1508 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid
1509 servers from automatically updating redirect resources when their
1510 targets move.
1512 Resolution: Agreed. See also issue 6.
1514 D.13 12.1-property-name
1516 Type: change
1518 julian.reschke@greenbytes.de (2003-10-06): Sync names for
1519 DAV:reftarget property and "Redirect-Ref" response headers.
1521 D.14 lc-55-iana
1523 Type: change
1525
1528 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section
1529 to list all methods, headers, XML elements, MIME types, URL schemes,
1530 etc., defined by the spec.
1532 Resolution: Agreed.
1534 Index
1536 A
1537 Apply-To-Redirect-Ref header 25
1539 D
1540 DAV header
1541 compliance class 'redirectrefs' 29
1542 DAV:redirectref resource type 27
1543 DAV:reftarget property 26
1545 H
1546 Headers
1547 Apply-To-Redirect-Ref 25
1548 Redirect-Ref 25
1550 M
1551 Methods
1552 MKRESOURCE 9
1553 MKRESOURCE method 9
1555 P
1556 Properties
1557 DAV:reftarget 26
1559 R
1560 Redirect-Ref header 25
1561 Resource Types
1562 DAV:redirectref 27
1564 Intellectual Property Statement
1566 The IETF takes no position regarding the validity or scope of any
1567 intellectual property or other rights that might be claimed to
1568 pertain to the implementation or use of the technology described in
1569 this document or the extent to which any license under such rights
1570 might or might not be available; neither does it represent that it
1571 has made any effort to identify any such rights. Information on the
1572 IETF's procedures with respect to rights in standards-track and
1573 standards-related documentation can be found in BCP-11. Copies of
1574 claims of rights made available for publication and any assurances of
1575 licenses to be made available, or the result of an attempt made to
1576 obtain a general license or permission for the use of such
1577 proprietary rights by implementors or users of this specification can
1578 be obtained from the IETF Secretariat.
1580 The IETF invites any interested party to bring to its attention any
1581 copyrights, patents or patent applications, or other proprietary
1582 rights which may cover technology that may be required to practice
1583 this standard. Please address the information to the IETF Executive
1584 Director.
1586 Full Copyright Statement
1588 Copyright (C) The Internet Society (2003). All Rights Reserved.
1590 This document and translations of it may be copied and furnished to
1591 others, and derivative works that comment on or otherwise explain it
1592 or assist in its implementation may be prepared, copied, published
1593 and distributed, in whole or in part, without restriction of any
1594 kind, provided that the above copyright notice and this paragraph are
1595 included on all such copies and derivative works. However, this
1596 document itself may not be modified in any way, such as by removing
1597 the copyright notice or references to the Internet Society or other
1598 Internet organizations, except as needed for the purpose of
1599 developing Internet standards in which case the procedures for
1600 copyrights defined in the Internet Standards process must be
1601 followed, or as required to translate it into languages other than
1602 English.
1604 The limited permissions granted above are perpetual and will not be
1605 revoked by the Internet Society or its successors or assignees.
1607 This document and the information contained herein is provided on an
1608 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1609 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1610 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1611 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1612 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1614 Acknowledgment
1616 Funding for the RFC Editor function is currently provided by the
1617 Internet Society.