idnits 2.17.1
draft-ietf-webdav-redirectref-protocol-05.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.
== There are 12 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- 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 (October 1, 2003) is 7513 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 2070, 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. 'XML'
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
-- Possible downref: Non-RFC (?) normative reference: ref. '12'
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
-- Possible downref: Non-RFC (?) normative reference: ref. '15'
-- Possible downref: Non-RFC (?) normative reference: ref. '16'
-- Possible downref: Non-RFC (?) normative reference: ref. '17'
-- Possible downref: Non-RFC (?) normative reference: ref. '18'
-- Possible downref: Non-RFC (?) normative reference: ref. '19'
-- Possible downref: Non-RFC (?) normative reference: ref. '20'
-- Possible downref: Non-RFC (?) normative reference: ref. '21'
-- Possible downref: Non-RFC (?) normative reference: ref. '22'
-- Possible downref: Non-RFC (?) normative reference: ref. '23'
-- Possible downref: Non-RFC (?) normative reference: ref. '24'
-- Possible downref: Non-RFC (?) normative reference: ref. '25'
-- Possible downref: Non-RFC (?) normative reference: ref. '26'
-- Possible downref: Non-RFC (?) normative reference: ref. '27'
-- Possible downref: Non-RFC (?) normative reference: ref. '28'
-- Possible downref: Non-RFC (?) normative reference: ref. '29'
-- Possible downref: Non-RFC (?) normative reference: ref. '30'
-- Possible downref: Non-RFC (?) normative reference: ref. '31'
-- Possible downref: Non-RFC (?) normative reference: ref. '32'
-- Possible downref: Non-RFC (?) normative reference: ref. '33'
-- Possible downref: Non-RFC (?) normative reference: ref. '34'
-- Possible downref: Non-RFC (?) normative reference: ref. '35'
-- Possible downref: Non-RFC (?) normative reference: ref. '36'
-- Possible downref: Non-RFC (?) normative reference: ref. '37'
-- Possible downref: Non-RFC (?) normative reference: ref. '38'
-- Possible downref: Non-RFC (?) normative reference: ref. '39'
-- Possible downref: Non-RFC (?) normative reference: ref. '40'
-- Possible downref: Non-RFC (?) normative reference: ref. '41'
-- Possible downref: Non-RFC (?) normative reference: ref. '42'
Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 45 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 WEBDAV Working Group J. Slein
3 Internet-Draft Xerox
4 Expires: March 31, 2004 J. Whitehead
5 U.C. Santa Cruz
6 J. Davis
7 CourseNet
8 G. Clemm
9 Rational
10 C. Fay
11 FileNet
12 J. Crawford
13 IBM
14 J. Reschke, Ed.
15 greenbytes
16 October 1, 2003
18 WebDAV Redirect Reference Resources
19 draft-ietf-webdav-redirectref-protocol-05
21 Status of this Memo
23 This document is an Internet-Draft and is in full conformance with
24 all provisions of Section 10 of RFC2026.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that other
28 groups may also distribute working documents as Internet-Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at http://
36 www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on March 31, 2004.
43 Copyright Notice
45 Copyright (C) The Internet Society (2003). All Rights Reserved.
47 Abstract
49 This specification defines redirect reference resources. A redirect
50 reference resource is a resource whose default response is an HTTP/
51 1.1 302 (Found) status code, redirecting the client to a different
52 resource, the target resource. A redirect reference makes it
53 possible to access the target resource indirectly, through any URI
54 mapped to the redirect reference resource. There are no integrity
55 guarantees associated with redirect reference resources.
57 Distribution of this document is unlimited. Please send comments to
58 the Distributed Authoring and Versioning (WebDAV) working group at
59 w3c-dist-auth@w3.org [1], which may be joined by sending a message
60 with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
62 Discussions of the WEBDAV working group are archived at URL: http://
63 lists.w3.org/Archives/Public/w3c-dist-auth/.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
68 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7
69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8
70 4. Overview of Redirect Reference Resources . . . . . . . . . . 9
71 5. Creating a Redirect Reference Resource . . . . . . . . . . . 10
72 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10
73 5.2 Example: Creating a Redirect Reference Resource with
74 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 11
75 6. Operations on Redirect Reference Resources . . . . . . . . . 13
76 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 13
77 6.2 Example: PROPPATCH on a Redirect Reference Resource . . . . 14
78 7. Operations on Collections That Contain Redirect Reference
79 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16
80 7.1 MOVE and DELETE on Collections That Contain Redirect
81 References . . . . . . . . . . . . . . . . . . . . . . . . . 16
82 7.2 LOCK on a Collection That Contains Redirect References . . . 17
83 7.3 Example: PROPFIND on a Collection with Redirect Reference
84 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17
85 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a
86 Collection with Redirect Reference Resources . . . . . . . . 18
87 7.5 Example: COPY on a Collection That Contains a Redirect
88 Reference Resource . . . . . . . . . . . . . . . . . . . . . 20
89 7.6 Example: LOCK on a Collection That Contains a Redirect
90 Reference Resource . . . . . . . . . . . . . . . . . . . . . 21
91 8. Operations on Targets of Redirect Reference Resources . . . 24
92 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 25
93 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 25
94 9.2 Example: Resolving a Relative URI in a Multi-Status
95 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 26
96 10. Redirect References to Collections . . . . . . . . . . . . . 28
97 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 30
98 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 30
99 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 30
100 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 31
101 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 31
102 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 31
103 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 32
104 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 32
105 14. Extensions to the DAV:response XML Element for
106 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 33
107 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 34
108 15.1 Example: Discovery of Support for Redirect Reference
109 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 34
110 16. Security Considerations . . . . . . . . . . . . . . . . . . 35
111 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 35
112 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 35
113 16.3 Redirect Reference Resources and Denial of Service . . . . . 35
114 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 35
115 17. Internationalization Considerations . . . . . . . . . . . . 37
116 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
117 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
118 Normative References . . . . . . . . . . . . . . . . . . . . 40
119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
120 A. Changes to the WebDAV Document Type Definition . . . . . . . 42
121 B. Change Log (to be removed by RFC Editor before
122 publication) . . . . . . . . . . . . . . . . . . . . . . . . 43
123 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43
124 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43
125 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . . 43
126 C. Resolved issues (to be removed by RFC Editor before
127 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44
128 C.1 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 44
129 C.2 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 44
130 C.3 lc-04-standard-data-container . . . . . . . . . . . . . . . 44
131 C.4 lc-05-standard-data-container . . . . . . . . . . . . . . . 44
132 C.5 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 45
133 C.6 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 45
134 C.7 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 45
135 C.8 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 45
136 C.9 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 46
137 C.10 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 46
138 C.11 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 47
139 C.12 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 47
140 D. Open issues (to be removed by RFC Editor before
141 publication) . . . . . . . . . . . . . . . . . . . . . . . . 48
142 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 48
143 D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 48
144 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 48
145 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 48
146 D.5 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 49
147 D.6 3-terminology-redirectref . . . . . . . . . . . . . . . . . 49
148 D.7 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 49
149 D.8 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 49
150 D.9 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 50
151 D.10 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 50
152 D.11 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 50
153 D.12 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 51
154 D.13 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 51
155 D.14 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 51
156 D.15 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 51
157 D.16 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 52
158 D.17 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 52
159 D.18 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 52
160 D.19 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 53
161 D.20 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 53
162 D.21 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 53
163 D.22 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 53
164 D.23 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 54
165 D.24 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 54
166 D.25 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 55
167 D.26 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 55
168 D.27 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 55
169 D.28 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 55
170 D.29 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 55
171 Intellectual Property and Copyright Statements . . . . . . . 57
173 1. Introduction
175 This is one of a pair of specifications that extend the WebDAV
176 Distributed Authoring Protocol to enable clients to create new access
177 paths to existing resources. This capability is useful for several
178 reasons:
180 URIs of WebDAV-compliant resources are hierarchical and correspond to
181 a hierarchy of collections in resource space. The WebDAV Distributed
182 Authoring Protocol makes it possible to organize these resources into
183 hierarchies, placing them into groupings, known as collections, which
184 are more easily browsed and manipulated than a single flat
185 collection. However, hierarchies require categorization decisions
186 that locate resources at a single location in the hierarchy, a
187 drawback when a resource has multiple valid categories. For example,
188 in a hierarchy of vehicle descriptions containing collections for
189 cars and boats, a description of a combination car/boat vehicle could
190 belong in either collection. Ideally, the description should be
191 accessible from both. Allowing clients to create new URIs that access
192 the existing resource lets them put that resource into multiple
193 collections.
195 Hierarchies also make resource sharing more difficult, since
196 resources that have utility across many collections are still forced
197 into a single collection. For example, the mathematics department at
198 one university might create a collection of information on fractals
199 that contains bindings to some local resources, but also provides
200 access to some resources at other universities. For many reasons, it
201 may be undesirable to make physical copies of the shared resources on
202 the local server: to conserve disk space, to respect copyright
203 constraints, or to make any changes in the shared resources visible
204 automatically. Being able to create new access paths to existing
205 resources in other collections or even on other servers is useful for
206 this sort of case.
208 The redirect reference resources defined here provide a mechanism for
209 creating alternative access paths to existing resources. A redirect
210 reference resource is a resource in one collection whose purpose is
211 to forward requests to another resource (its target), possibly in a
212 different collection. In this way, it allows clients to submit
213 requests to the target resource from another collection. It
214 redirects most requests to the target resource using the HTTP 302
215 (Found) status code, thereby providing a form of mediated access to
216 the target resource.
218 A redirect reference is a resource with properties but no body of its
219 own. Properties of a redirect reference resource can contain such
220 information as who created the reference, when, and why. Since
221 redirect reference resources are implemented using HTTP 302
222 responses, it generally takes two round trips to submit a request to
223 the intended resource. Servers are not required to enforce the
224 integrity of redirect references. Redirect references work equally
225 well for local resources and for resources that reside on a different
226 server from the reference.
228 The remainder of this document is structured as follows: Section 3
229 defines terms that will be used throughout the specification.
230 Section 4 provides an overview of redirect reference resources.
231 Section 5 discusses how to create a redirect reference resource.
232 Section 6 defines the semantics of existing methods when applied to
233 redirect reference resources, and Section 7 discusses their semantics
234 when applied to collections that contain redirect reference
235 resources. Sections 8 through 10 discuss several other issues raised
236 by the existence of redirect reference resources. Sections 11
237 through 14 define the new headers, properties, and XML elements
238 required to support redirect reference resources. Section 15
239 discusses capability discovery. Sections 16 through 18 present the
240 security, internationalization, and IANA concerns raised by this
241 specification. The remaining sections provide a variety of supporting
242 information.
244 2. Notational Conventions
246 Since this document describes a set of extensions to the WebDAV
247 Distributed Authoring Protocol [RFC2518], itself an extension to the
248 HTTP/1.1 protocol, the augmented BNF used here to describe protocol
249 elements is exactly the same as described in Section 2.1 of
250 [RFC2616]. Since this augmented BNF uses the basic production rules
251 provided in Section 2.2 of [RFC2616], these rules apply to this
252 document as well.
254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
256 document are to be interpreted as described in [RFC2119].
258 3. Terminology
260 The terminology used here follows and extends that in the WebDAV
261 Distributed Authoring Protocol specification [RFC2518]. Definitions
262 of the terms resource, Uniform Resource Identifier (URI), and Uniform
263 Resource Locator (URL) are provided in [RFC2396].
265 Redirect Reference Resource
267 A resource created to redirect all requests made to it, using 302
268 (Found), to a defined target resource.
270 Non-Reference Resource
272 A resource that is not a reference to another resource.
274 Target Resource
276 The resource to which requests are forwarded by a reference
277 resource. A target resource can be anything that can be identified
278 by an absolute URI (see [RFC2396], "absoluteURI").
280 4. Overview of Redirect Reference Resources
282 For all operations submitted to a redirect reference resource, the
283 default response is a 302 (Found), accompanied by the Redirect-Ref
284 header (defined in Section 11.1 below) and the Location header set to
285 the URI of the target resource. With this information, the client
286 can resubmit the request to the URI of the target resource.
288 A redirect reference resource never automatically forwards requests
289 to its target resource. Redirect resources bring the same benefits as
290 links in HTML documents. They can be created and maintained without
291 the involvement or even knowledge of their target resource. This
292 reduces the cost of linking between resources."
294 If the client is aware that it is operating on a redirect reference
295 resource, it can resolve the reference by retrieving the reference
296 resource's DAV:reftarget property (defined in Section 12.1 below),
297 whose value contains the URI of the target resource. It can then
298 submit requests to the target resource.
300 A redirect reference resource is a new type of resource. To
301 distinguish redirect reference resources from non-reference
302 resources, a new value of the DAV:resourcetype property (defined in
303 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below.
305 Since a redirect reference resource is a resource, methods can be
306 applied to the reference resource as well as to its target resource.
307 The Apply-To-Redirect-Ref request header (defined in Section 11.2
308 below) is provided so that referencing-aware clients can control
309 whether an operation is applied to the redirect reference resource or
310 to its target resource. The Apply-To-Redirect-Ref header can be used
311 with most requests to redirect reference resources. This header is
312 particularly useful with PROPFIND, to retrieve the reference
313 resource's own properties.
315 5. Creating a Redirect Reference Resource
317 The new MKRESOURCE method is used to create new redirect reference
318 resources. In order to create a redirect reference resource using
319 MKRESOURCE, the values of two properties must be set in the body of
320 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to
321 DAV:redirectref, a new value of DAV:resourcetype defined in Section
322 13.1. The value of DAV:reftarget MUST be set to the URI of the target
323 resource.
325 Used in this way, the MKRESOURCE method creates a redirect reference
326 resource whose target is identified by the DAV:reftarget property.
328 5.1 MKRESOURCE
330 The MKRESOURCE method requests the creation of a redirect reference
331 resource and initialization of its properties in one atomic
332 operation.
334 Preconditions:
336 A resource MUST NOT exist at the Request-URI.
338 Request Marshalling:
340 The location of the new resource to be created is specified by the
341 Request-URI.
343 The request body of the MKRESOURCE method MUST consist of the
344 DAV:propertyupdate XML element defined in Section 12.13 of
345 [RFC2518], specifying a DAV:resourcetype of "DAV:redirectref".
347 Postconditions:
349 If the response status code is 201, a new resource exists at the
350 Request-URI.
352 The properties of the new resource are as specified by the
353 DAV:propertyupdate request body, using PROPPATCH semantics.
355 If the response status code is not 201, then a new resource is not
356 created at the Request-URI, and any existing resource at the
357 Request-URI is unaffected.
359 Response Marshalling:
361 Responses from a MKRESOURCE request MUST NOT be cached, as
362 MKRESOURCE has non-idempotent semantics.
364 The following status codes can be expected in responses to
365 MKRESOURCE:
367 201 (Created): The new resource was successfully created.
369 403 (Forbidden): The server does not allow the creation of the
370 requested resource type at the requested location, or the parent
371 collection of the Request-URI exists but cannot accept members.
373 409 (Conflict): A resource cannot be created at the Request-URI
374 because the parent collection for the resource does not exist, or
375 because there is already a resource at that request-URL.
377 423 (Locked): The Request-URI is locked, and the lock token was
378 not passed with the request.
380 507 (Insufficient Storage): The server does not have sufficient
381 space to record the state of the resource.
383 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE
385 >> Request:
387 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
388 Host: www.ics.uci.edu
389 Content-Type: text/xml; charset="utf-8"
390 Content-Length: xxx
392
393
394
395
396
397
398 /i-d/draft-webdav-protocol-08.txt
399
400
401
402
404 >> Response:
406 HTTP/1.1 201 Created
408 This request resulted in the creation of a new redirect reference
409 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points
410 to the resource identified by the DAV:reftarget property. In this
411 example, the target resource is identified by the URI http://
412 www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt. The redirect
413 reference resource's DAV:resourcetype property is set to
414 DAV:redirectref.
416 6. Operations on Redirect Reference Resources
418 Although non-referencing-aware clients cannot create reference
419 resources, they should be able to submit requests through the
420 reference resources created by reference-aware WebDAV clients. They
421 should be able to follow any references to their targets. To make
422 this possible, a server that receives any request made via a redirect
423 reference resource MUST return a 302 (Found) status code, unless the
424 request includes an Apply-To-Redirect-Ref header. The client and
425 server MUST follow [RFC2616] Section 10.3.3 "302 Found," but with
426 these additional rules:
428 o The Location response header MUST contain an absolute URI that
429 identifies the target of the reference resource.
431 o The response MUST include the Redirect-Ref header. This header
432 allows reference-aware WebDAV clients to recognize the resource as
433 a reference resource and understand the reason for the
434 redirection.
436 A reference-aware WebDAV client can act on this response in one of
437 two ways. It can, like a non-referencing client, resubmit the
438 request to the URI in the Location header in order to operate on the
439 target resource. Alternatively, it can resubmit the request to the
440 URI of the redirect reference resource with the Apply-To-Redirect-Ref
441 header in order to operate on the reference resource itself. If the
442 Apply-To-Redirect-Ref header is present, the request MUST be applied
443 to the reference resource itself, and a 302 response MUST NOT be
444 returned.
446 A reference-aware client may know before submitting its request that
447 the Request-URI identifies a redirect reference resource. In this
448 case, if the client wants to apply the method to the reference
449 resource, it can save the round trip caused by the 302 response by
450 using an Apply-To-Redirect-Ref header in its initial request to the
451 URI.
453 As redirect references do not have bodies, GET and PUT requests with
454 Apply-To-Redirect-Ref MUST fail with status 403 (forbidden).
456 6.1 Example: GET on a Redirect Reference Resource
458 >> Request:
460 GET /bar.html HTTP/1.1
461 Host: www.foo.com
462 >> Response:
464 HTTP/1.1 302 Found
465 Location: http://www.svr.com/Internet/xxspec08.html
466 Redirect-Ref:
468 Since /bar.html is a redirect reference resource and the
469 Apply-To-Redirect-Ref header is not included in the request, the
470 response is a 302 (Found). The Redirect-Ref header informs a
471 reference-aware client that this is not an ordinary HTTP 1.1
472 redirect, but is a redirect reference resource. The URI of the
473 target resource is provided in the Location header so that the client
474 can resubmit the request to the target resource.
476 6.2 Example: PROPPATCH on a Redirect Reference Resource
478 >> Request:
480 PROPPATCH /bar.html HTTP/1.1
481 Host: www.foo.com
482 Content-Type: text/xml; charset="utf-8"
483 Content-Length: xxxx
485
486
488
489
490
491 Jim Whitehead
492 Roy Fielding
493
494
495
496
497
498
499
500
501
503 >> Response:
505 HTTP/1.1 302 Found
506 Location: http://www.svr.com/Internet/xxspec08.html
507 Redirect-Ref:
509 Since /bar.html is a redirect reference resource and the
510 Apply-To-Redirect-Ref header is not included in the request, the
511 response is a 302 (Found). The Redirect-Ref header informs a
512 reference-aware client that this is not an ordinary HTTP 1.1
513 redirect, but is a redirect reference resource. The URI of the
514 target resource is provided in the Location header so that the client
515 can resubmit the request to the target resource.
517 7. Operations on Collections That Contain Redirect Reference Resources
519 Consistent with the rules in Section 6, the response for each
520 redirect reference encountered while processing a collection MUST be
521 a 302 (Found) unless a Apply-To-Redirect-Ref header is included with
522 the request. The overall response will therefore be a 207
523 (Multi-Status). Since a Location header and Redirect-Ref header
524 cannot be returned for each redirect reference encountered, the same
525 information is provided using properties in the response elements for
526 those resources. The DAV:location pseudo-property and the
527 DAV:resourcetype property MUST be included with the 302 status code.
528 This necessitates an extension to the syntax of the DAV:response
529 element that was defined in [RFC2518]. The extension is defined in
530 Section 14 below.
532 A referencing-aware client can tell from the DAV:resourcetype
533 property that the collection contains a redirect reference resource.
534 The DAV:location pseudo-property contains the absolute URI of the
535 target resource. A referencing-aware client can either use the URI
536 value of the DAV:location pseudo-property to resubmit its request to
537 the target resource, or it can submit the request to the redirect
538 reference resource with Apply-To-Redirect-Ref.
540 It is recommended that future editors of [RFC2518] define the
541 DAV:location pseudo-property in [RFC2518], so that non-referencing
542 clients will also be able to use the response to operate on the
543 target resource. (This will also enable clients to operate on
544 traditional HTTP/1.1 302 responses in Multi-Status responses.) Until
545 then, non-referencing clients will not be able to process 302
546 responses from redirect reference resources encountered while
547 processing a collection.
549 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be
550 used with any request on a collection. If present, it will be
551 applied to all redirect reference resources encountered while
552 processing the collection.
554 7.1 MOVE and DELETE on Collections That Contain Redirect References
556 DELETE removes the binding that corresponds to the Request-URI. MOVE
557 removes that binding and creates a new binding to the same resource.
558 In cases where DELETE and MOVE are applied to a collection, these
559 operations affect all the descendents of the collection, but they do
560 so indirectly. There is no need to visit each descendent in order to
561 process the request. Consequently, even if there are redirect
562 reference resources in a tree that is being deleted or moved, there
563 will be no 302 responses from the redirect reference resources.
565 7.2 LOCK on a Collection That Contains Redirect References
567 LOCK poses special problems because it is atomic. An attempt to lock
568 (with Depth: infinity) a collection that contains redirect references
569 will always fail. The Multi-Status response will contain a 302
570 response for each redirect reference.
572 Reference-aware clients can lock the collection by using
573 Apply-To-Redirect-Ref, and, if desired, lock the targets of the
574 redirect references individually.
576 Non-referencing clients must resort to locking each resource
577 individually.
579 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources
581 Suppose a PROPFIND request with Depth: infinity is submitted to the
582 following collection, with the members shown here:
584 http://www.svr.com/MyCollection/
585 (non-reference resource) diary.html
586 (redirect reference resource) nunavut
588 >> Request:
590 PROPFIND /MyCollection/ HTTP/1.1
591 Host: www.svr.com
592 Depth: infinity
593 Content-Type: text/xml
594 Content-Length: xxxx
596
597
598
599
600
601
602
604 >> Response:
606 HTTP/1.1 207 Multi-Status
607 Content-Type: text/xml
608 Content-Length: xxxx
610
611
612
613 http://www.svr.com/MyCollection/
614
615
616
617 diary, interests, hobbies
618
619 HTTP/1.1 200 OK
620
621
622
623 http://www.svr.com/MyCollection/diary.html
624
625
626
627 diary, travel, family, history
628
629 HTTP/1.1 200 OK
630
631
632
633 http://www.svr.com/MyCollection/nunavut
634 HTTP/1.1 302 Found
635
636
637 http://www.inac.gc.ca/art/inuit/
638
639
640
641
642
644 In this example the Depth header is set to infinity, and the
645 Apply-To-Redirect-Ref header is not used. The collection contains
646 one URI that identifies a redirect reference resource. The response
647 element for the redirect reference resource has a status of 302
648 (Found), and includes a DAV:prop element with the DAV:location
649 pseudo-property and the DAV:resourcetype property to allow clients to
650 retrieve the properties of its target resource. (The response
651 element for the redirect reference resource does not include the
652 requested properties. The client can submit another PROPFIND request
653 to the URI in the DAV:location pseudo-property to retrieve those
654 properties.)
656 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
657 Redirect Reference Resources
659 Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth:
660 infinity is submitted to the following collection, with the members
661 shown here:
663 /MyCollection/
664 (non-reference resource) diary.html
665 (redirect reference resource) nunavut
667 >> Request:
669 PROPFIND /MyCollection/ HTTP/1.1
670 Host: www.svr.com
671 Depth: infinity
672 Apply-To-Redirect-Ref:
673 Content-Type: text/xml
674 Content-Length: xxxx
676
677
678
679
680
681
682
684 >> Response:
686 HTTP/1.1 207 Multi-Status
687 Content-Type: text/xml
688 Content-Length: xxxx
690
691
692
693 http://www.svr.com/MyCollection/
694
695
696
697
698 HTTP/1.1 200 OK
699
700
701
702 HTTP/1.1 404 Not Found
703
704
705
706 http://www.svr.com/MyCollection/diary.html
707
708
709
710
711 HTTP/1.1 200 OK
712
713
714
715 HTTP/1.1 404 Not Found
716
717
718
719 http://www.svr.com/MyCollection/nunavut
720
721
722
723
724 http://www.inac.gc.ca/art/inuit/
725
726
727 HTTP/1.1 200 OK
728
729
730
732 Since the Apply-To-Redirect-Ref header is present, the response shows
733 the properties of the redirect reference resource in the collection
734 rather than reporting a 302 status.
736 7.5 Example: COPY on a Collection That Contains a Redirect Reference
737 Resource
739 Suppose a COPY request is submitted to the following collection, with
740 the members shown:
742 /MyCollection/
743 (non-reference resource) diary.html
744 (redirect reference resource) nunavut with target
745 /Someplace/nunavut.map
747 >> Request:
749 COPY /MyCollection/ HTTP/1.1
750 Host: www.svr.com
751 Depth: infinity
752 Destination: http://www.svr.com/OtherCollection/
754 >> Response:
756 HTTP/1.1 207 Multi-Status
757 Content-Type: text/xml; charset="utf-8"
758 Content-Length: xxx
760
761
762
763 http://www.svr.com/MyCollection/nunavut
764 HTTP/1.1 302 Found
765
766
767 http://www.svr.com//Someplace/nunavut.map
768
769
770
771
772
774 In this case, since /MyCollection/nunavut is a redirect reference
775 resource, the COPY operation was only a partial success. The
776 redirect reference resource was not copied, but a 302 response was
777 returned for it. So the resulting collection is as follows:
779 /OtherCollection/
780 (non-reference resource) diary.html
782 7.6 Example: LOCK on a Collection That Contains a Redirect Reference
783 Resource
785 Suppose a LOCK request is submitted to the following collection, with
786 the members shown:
788 /MyCollection/
789 (non-reference resource) diary.html
790 (redirect reference resource) nunavut
792 >> Request:
794 LOCK /MyCollection/ HTTP/1.1
795 Host: www.svr.com
796 Content-Type: text/xml
797 Content-Length: nnnn
798 Authorizaton: Digest username="jas",
799 realm=jas@webdav.sb.aol.com, nonce=". . . ",
800 uri="/MyCollection/tuva",
801 response=". . . ", opaque=". . . "
803
804
805
806
807
808 http://www.svr.com/~jas/contact.html
809
810
812 >> Response:
814 HTTP/1.1 207 Multi-Status
815 Content-Type: text/xml
816 Content-Length: nnnn
818
819
820
821 http://www.svr.com/MyCollection/
822
823
824 HTTP/1.1 424 Failed Dependency
825
826
827
828 http://www.svr.com/MyCollection/diary.html
829 HTTP/1.1 424 Failed Dependency
830
831
832 http://www.svr.com/MyCollection/nunavut
833 HTTP/1.1 302 Found
834
835
836 http://www.inac.gc.ca/art/inuit/
837
838
839
840
841
843 The server returns a 302 response code for the redirect reference
844 resource in the collection. Consequently, neither the collection nor
845 any of the resources identified by its internal member URIs were
846 locked. A referencing-aware client can submit a separate LOCK request
847 to the URI in the DAV:location pseudo-property returned for the
848 redirect reference resource, and can resubmit the LOCK request with
849 the Apply-To-Redirect-Ref header to the collection. At that point
850 both the reference resource and its target resource will be locked
851 (as well as the collection and all the resources identified by its
852 other members).
854 8. Operations on Targets of Redirect Reference Resources
856 Operations on targets of redirect reference resources have no effect
857 on the reference resource.
859 9. Relative URIs in DAV:reftarget
861 The URI in the href in a DAV:reftarget property MAY be a relative
862 URI. In this case, the base URI to be used for resolving the relative
863 URI to absolute form is the URI used in the HTTP message to identify
864 the redirect reference resource to which the DAV:reftarget property
865 belongs.
867 When DAV:reftarget occurs in the body of a MKRESOURCE request, the
868 base URI is constructed as follows: Its scheme component is "http",
869 its authority component is the value of the Host header in the
870 request, and its path component is the Request-URI in the request.
871 See Section 5 of [RFC2396] for a discussion of relative URI
872 references and how to resolve them.
874 When DAV:reftarget appears in the context of a Multi-Status response,
875 it is in a DAV:response element that contains a single DAV:href
876 element. The value of this DAV:href element serves as the base URI
877 for resolving a relative URI in DAV:reftarget. The value of DAV:href
878 may itself be relative, in which case it must be resolved first in
879 order to serve as the base URI for the relative URI in DAV:reftarget.
880 If the DAV:href element is relative, its base URI is constructed from
881 the scheme component "http", the value of the Host header in the
882 request, and the request-URI.
884 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request
886 >> Request:
888 MKRESOURCE /north/inuvik HTTP/1.1
889 Host: www.somehost.edu
890 Content-Type: text/xml; charset="utf-8"
891 Content-Length: xxx
893
894
895
896
897
898
899 mapcollection/inuvik.gif
900
901
902
903
905 >> Response:
907 HTTP/1.1 201 Created
909 In this example, the base URI is http://www.somehost.edu/north/
910 inuvik. Then, following the rules in [RFC2396] Section 5, the
911 relative URI in DAV:reftarget resolves to the absolute URI http://
912 www.somehost.edu/north/mapcollection/inuvik.gif.
914 9.2 Example: Resolving a Relative URI in a Multi-Status Response
916 >> Request:
918 PROPFIND /geog/ HTTP/1.1
919 Host: www.xxsvr.com
920 Apply-To-Redirect-Ref:
921 Depth: 1
922 Content-Type: text/xml
923 Content-Length: nnn
925
926
927
928
929
930
931
933 >> Response:
935 HTTP/1.1 207 Multi-Status
936 Content-Type: text/xml
937 Content-Length: nnn
939
940
941
942 /geog/
943
944
945
946
947 HTTP/1.1 200 OK
948
949
950
951 HTTP/1.1 404 Not Found
952
953
954
955 /geog/stats.html
956
957
958
959
960 statistics/population/1997.html
961
962
963 HTTP/1.1 200 OK
964
965
966
968 In this example, the relative URI statistics/population/1997.html is
969 returned as the value of reftarget for the reference resource
970 identified by href /geog/stats.html. The href is itself a relative
971 URI, which resolves to http://www.xxsrv.com/geog/stats.html. This is
972 the base URI for resolving the relative URI in reftarget. The
973 absolute URI of reftarget is http://www.xxsrv.com/geog/statistics/
974 population/1997.html.
976 10. Redirect References to Collections
978 In a Request-URI /segment1/segment2/segment3, any of the three
979 segments may identify a redirect reference resource. (See [RFC2396],
980 Section 3.3, for definitions of "path" and "segment".) If any
981 segment in a Request- URI identifies a redirect reference resource,
982 the response is a 302. The value of the Location header in the 302
983 response is as follows:
985 The leftmost path segment of the request-URI that identifies a
986 redirect reference resource, together with all path segments and
987 separators to the left of it, is replaced by the value of the
988 redirect reference resource's DAV:reftarget property (resolved to an
989 absolute URI). The remainder of the request-URI is concatenated to
990 this path.
992 Note: If the DAV:reftarget property ends with a "/" and the remainder
993 of the Request-URI is non-empty (and therefore must begin with a "/
994 "), the final "/" in the DAV:reftarget property is dropped before the
995 remainder of the Request-URI is appended.
997 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect
998 reference resource whose target resource is collection /a/, which
999 contains redirect reference resource y whose target resource is
1000 collection /b/, which contains redirect reference resource z.html
1001 whose target resource is /c/d.html.
1003 /x/y/z.html
1004 |
1005 | /x -> /a
1006 |
1007 v
1008 /a/y/z.html
1009 |
1010 | /a/y -> /b
1011 |
1012 v
1013 /b/z.html
1014 |
1015 | /b/z.html -> /c/d.html
1016 |
1017 v
1018 /c/d.html
1020 In this case the client must follow up three separate 302 responses
1021 before finally reaching the target resource. The server responds to
1022 the initial request with a 302 with Location: /a/y/z.html, and the
1023 client resubmits the request to /a/y/z.html. The server responds to
1024 this request with a 302 with Location: /b/z.html, and the client
1025 resubmits the request to /b/z.html. The server responds to this
1026 request with a 302 with Location: /c/d.html, and the client resubmits
1027 the request to /c/d.html. This final request succeeds.
1029 11. Headers
1031 11.1 Redirect-Ref Response Header
1033 Redirect-Ref = "Redirect-Ref:"
1035 The Redirect-Ref header is used in all 302 responses from redirect
1036 reference resources. Its presence informs reference-aware clients
1037 that the response is not a plain HTTP/1.1 redirect, but is a response
1038 from a redirect reference resource.
1040 11.2 Apply-To-Redirect-Ref Request Header
1042 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":"
1044 The optional Apply-To-Redirect-Ref header can be used on any request
1045 to a redirect reference resource. When it is used, the request MUST
1046 be applied to the reference resource itself, and a 302 response MUST
1047 NOT be returned.
1049 If the Apply-To-Redirect-Ref header is used on a request to any other
1050 sort of resource besides a redirect reference resource, the server
1051 MUST ignore it.
1053 12. Properties
1055 12.1 reftarget Property
1057 Name: reftarget
1059 Namespace: DAV:
1061 Purpose: A property of redirect reference resources that provides an
1062 efficient way for clients to discover the URI of the target
1063 resource. This is a read-only property after its initial
1064 creation. Its value can only be set in a MKRESOURCE request.
1066 Value: href containing the URI of the target resource. This value
1067 MAY be a relative URI. The reftarget property can occur in the
1068 entity bodies of MKRESOURCE requests and of responses to PROPFIND
1069 requests.
1071
1073 12.2 location Pseudo-Property
1075 Name: location
1077 Namespace: DAV:
1079 Purpose: For use with 302 (Found) response codes in Multi-Status
1080 responses. It contains the absolute URI of the temporary location
1081 of the resource. In the context of redirect reference resources,
1082 this value is the absolute URI of the target resource. It is
1083 analogous to the Location header in HTTP 302 responses defined in
1084 [RFC2616] Section 10.3.3 "302 Found." Including the location
1085 pseudo-property in a Multi- Status response requires an extension
1086 to the syntax of the DAV:response element defined in [RFC2518],
1087 which is defined in Section 14 below. This pseudo-property is not
1088 expected to be stored on the reference resource. It is modeled as
1089 a property only so that it can be returned inside a DAV:prop
1090 element in a Multi-Status response.
1092 Value: href containing the absolute URI of the target resource.
1094
1096 13. XML Elements
1098 13.1 redirectref XML Element
1100 Name: redirectref
1102 Namespace: DAV:
1104 Purpose: Used as the value of the DAV:resourcetype property to
1105 specify that the resource type is a redirect reference resource.
1107
1109 14. Extensions to the DAV:response XML Element for Multi-Status
1110 Responses
1112 As described in Section 7, the DAV:location pseudo-property and the
1113 DAV:resourcetype property may be returned in the DAV:response element
1114 of a 207 Multi-Status response, to allow clients to resubmit their
1115 requests to the target resource of a redirect reference resource.
1117 Whenever these properties are included in a Multi-Status response,
1118 they are placed in a DAV:prop element associated with the href to
1119 which they apply. This structure provides a framework for future
1120 extensions by other standards that may need to include additional
1121 properties in their responses.
1123 Consequently, the definition of the DAV:response XML element changes
1124 to the following:
1126
1129 15. Capability Discovery
1131 Sections 9.1 and 15 of [RFC2518] describe the use of compliance
1132 classes with the DAV header in responses to OPTIONS, to indicate
1133 which parts of the WebDAV Distributed Authoring protocols the
1134 resource supports. This specification defines an OPTIONAL extension
1135 to [RFC2518]. It defines a new compliance class, called
1136 redirectrefs, for use with the DAV header in responses to OPTIONS
1137 requests. If a resource does support redirect references, its
1138 response to an OPTIONS request may indicate that it does, by listing
1139 the new redirectrefs compliance class in the DAV headerand by listing
1140 the MKRESOURCE method as one it supports.
1142 When responding to an OPTIONS request, any type of resource can
1143 include redirectrefs in the value of the DAV header. Doing so
1144 indicates that the server permits a redirect reference resource at
1145 the request URI.
1147 15.1 Example: Discovery of Support for Redirect Reference Resources
1149 >> Request:
1151 OPTIONS /somecollection/someresource HTTP/1.1
1152 HOST: somehost.org
1154 >> Response:
1156 HTTP/1.1 200 OK
1157 Date: Tue, 20 Jan 1998 20:52:29 GMT
1158 Connection: close
1159 Accept-Ranges: none
1160 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
1161 MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
1162 DAV: 1, 2, redirectrefs
1164 The DAV header in the response indicates that the resource /
1165 somecollection/someresource is level 1 and level 2 compliant, as
1166 defined in [RFC2518]. In addition, /somecollection/someresource
1167 supports redirect reference resources. The Allow header indicates
1168 that MKRESOURCE requests can be submitted to /somecollection/
1169 someresource. The Public header shows that other Request-URIs on the
1170 server support additional methods.
1172 16. Security Considerations
1174 This section is provided to make applications that implement this
1175 protocol aware of the security implications of this protocol.
1177 All of the security considerations of HTTP/1.1 and the WebDAV
1178 Distributed Authoring Protocol specification also apply to this
1179 protocol specification. In addition, redirect reference resources
1180 introduce several new security concerns and increase the risk of some
1181 existing threats. These issues are detailed below.
1183 16.1 Privacy Concerns
1185 By creating redirect reference resources on a trusted server, it is
1186 possible for a hostile agent to induce users to send private
1187 information to a target on a different server. This risk is
1188 mitigated somewhat, since clients are required to notify the user of
1189 the redirection for any request other than GET or HEAD. (See
1190 [RFC2616], Section 10.3.3 302 Found.)
1192 16.2 Redirect Loops
1194 Although redirect loops were already possible in HTTP 1.1, the
1195 introduction of the MKRESOURCE method creates a new avenue for
1196 clients to create loops accidentally or maliciously. If the
1197 reference resource and its target are on the same server, the server
1198 may be able to detect MKRESOURCE requests that would create loops.
1199 See also [RFC2616], Section 10.3 "Redirection 3xx."
1201 16.3 Redirect Reference Resources and Denial of Service
1203 Denial of service attacks were already possible by posting URLs that
1204 were intended for limited use at heavily used Web sites. The
1205 introduction of MKRESOURCE creates a new avenue for similar denial of
1206 service attacks. Clients can now create redirect reference resources
1207 at heavily used sites to target locations that were not designed for
1208 heavy usage.
1210 16.4 Revealing Private Locations
1212 There are several ways that redirect reference resources may reveal
1213 information about collection structures. First, the DAV:reftarget
1214 property of every redirect reference resource contains the URI of the
1215 target resource. Anyone who has access to the reference resource can
1216 discover the collection path that leads to the target resource. The
1217 owner of the target resource may have wanted to limit knowledge of
1218 this collection structure.
1220 Sufficiently powerful access control mechanisms can control this risk
1221 to some extent. Property-level access control could prevent users
1222 from examining the DAV:reftarget property. (The Location header
1223 returned in responses to requests on redirect reference resources
1224 reveals the same information, however.) In some environments, the
1225 owner of a resource might be able to use access control to prevent
1226 others from creating references to that resource.
1228 This risk is no greater than the similar risk posed by HTML links.
1230 17. Internationalization Considerations
1232 This specification follows the practices of [RFC2518] in encoding all
1233 human-readable content using XML [XML] and in the treatment of names.
1234 Consequently, this specification complies with the IETF Character Set
1235 Policy [RFC2277].
1237 WebDAV applications MUST support the character set tagging, character
1238 set encoding, and the language tagging functionality of the XML
1239 specification. This constraint ensures that the human-readable
1240 content of this specification complies with [RFC2277].
1242 As in [RFC2518], names in this specification fall into three
1243 categories: names of protocol elements such as methods and headers,
1244 names of XML elements, and names of properties. Naming of protocol
1245 elements follows the precedent of HTTP, using English names encoded
1246 in USASCII for methods and headers. The names of XML elements used
1247 in this specification are English names encoded in UTF-8.
1249 For error reporting, [RFC2518] follows the convention of HTTP/1.1
1250 status codes, including with each status code a short, English
1251 description of the code (e.g., 423 Locked). Internationalized
1252 applications will ignore this message, and display an appropriate
1253 message in the user's language and character set.
1255 This specification introduces no new strings that are displayed to
1256 users as part of normal, error-free operation of the protocol.
1258 For rationales for these decisions and advice for application
1259 implementors, see [RFC2518].
1261 18. IANA Considerations
1263 All IANA considerations mentioned in [RFC2518] also apply to this
1264 document.
1266 19. Acknowledgements
1268 This draft has benefited from thoughtful discussion by Jim Amsden,
1269 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
1270 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
1271 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt,
1272 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
1273 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton,
1274 Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley
1275 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
1276 Wiggen, and others.
1278 Normative References
1280 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
1281 Languages", BCP 18, RFC 2277, January 1998.
1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1284 Requirement Levels", BCP 14, RFC 2119, March 1997.
1286 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1287 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1288 August 1998.
1290 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1291 Jensen, "HTTP Extensions for Distributed Authoring --
1292 WEBDAV", RFC 2518, February 1999.
1294 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1295 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1296 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1298 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1299 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
1300 REC-xml, October 2000, .
1303 [1]
1305 [2]
1307 [3]
1310 [4]
1313 [5]
1316 [6]
1319 [7]
1322 [8]
1325 [9]
1328 [10]
1331 [11]
1334 [12]
1337 [13]
1340 [14]
1343 [15]
1346 [16]
1349 [17]
1352 [18]
1355 [19]
1358 [20]
1361 [21]
1364 [22]
1367 [23]
1370 [24]
1373 [25]
1376 [26]
1379 [27]
1382 [28]
1385 [29]
1388 [30]
1391 [31]
1394 [32]
1397 [33]
1400 [34]
1403 [35]
1406 [36]
1409 [37]
1412 [38]
1415 [39]
1418 [40]
1421 [41]
1424 [42]
1427 Authors' Addresses
1429 J. Slein
1430 Xerox Corporation
1431 800 Phillips Road, 105-50C
1432 Webster, NY 14580
1434 EMail: jslein@crt.xerox.com
1436 Jim Whitehead
1437 UC Santa Cruz, Dept. of Computer Science
1438 1156 High Street
1439 Santa Cruz, CA 95064
1440 US
1442 EMail: ejw@cse.ucsc.edu
1444 J. Davis
1445 CourseNet Systems
1446 170 Capp Street
1447 San Francisco, CA 94110
1449 EMail: jrd3@alum.mit.edu
1451 G. Clemm
1452 Rational Software Corporation
1453 20 Maguire Road
1454 Lexington, MA 02173-3104
1456 EMail: geoffrey.clemm@us.ibm.com
1458 C. Fay
1459 FileNet Corporation
1460 3565 Harbor Boulevard
1461 Costa Mesa, CA 92626-1420
1463 EMail: cfay@filenet.com
1464 J. Crawford
1465 IBM Research
1466 P.O. Box 704
1467 Yorktown Heights, NY 10598
1469 EMail: ccjason@us.ibm.com
1471 Julian F. Reschke (editor)
1472 greenbytes GmbH
1473 Salzmannstrasse 152
1474 Muenster, NW 48159
1475 Germany
1477 Phone: +49 251 2807760
1478 Fax: +49 251 2807761
1479 EMail: julian.reschke@greenbytes.de
1480 URI: http://greenbytes.de/tech/webdav/
1482 Appendix A. Changes to the WebDAV Document Type Definition
1484
1485
1486 Property Elements from Section 12 -->
1487
1488
1489
1490
1493 Appendix B. Change Log (to be removed by RFC Editor before publication)
1495 B.1 Since draft-ietf-webdav-redirectref-protocol-02
1497 Julian Reschke takes editorial role (added to authors list). Cleanup
1498 XML indentation. Start adding all unresolved last call issues. Update
1499 some author's contact information. Update references, split into
1500 "normative" and "informational". Remove non-RFC2616 headers
1501 ("Public") from examples. Fixed width problems in artwork. Start
1502 resolving editorial issues.
1504 B.2 Since draft-ietf-webdav-redirectref-protocol-03
1506 Added Joe Orton and Juergen Reuter to Acknowledgements section. Close
1507 more editorial issues. Remove dependencies on BIND spec.
1509 B.3 Since draft-ietf-webdav-redirectref-protocol-04
1511 More editorial fixes. Clarify that MKRESOURCE can only be used to
1512 create redirect references (switch to new method in a future draft).
1513 Clarify that redirect references do not have bodies.
1515 Appendix C. Resolved issues (to be removed by RFC Editor before
1516 publication)
1518 Issues that were either rejected or resolved in this version of this
1519 document.
1521 C.1 lc-56-notjusthttp
1523 Type: change
1525 [3]
1527 yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples
1528 and text that the redirection URI could be non-HTTP.
1530 Resolution: We agree that it is possible to create redirect
1531 references to non-HTTP resources. Add example. (actually it was added
1532 to the definition of "target resource").
1534 C.2 lc-43-webdav
1536 Type: change
1538 [4]
1540 yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the
1541 DAV:reftarget property.
1543 Resolution: DAV:reftarget is readonly and is present only for
1544 redirect references that are also WebDAV resources. We'll also have a
1545 method for setting target; Redirect-Ref header (returned on all 302
1546 responses) will have the target as its value. See also issue 6, 17,
1547 50.
1549 C.3 lc-04-standard-data-container
1551 Type: change
1553 [5]
1555 joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs
1556 to be defined in the context of MKRESOURCE
1558 Resolution: Not relevant once we switch to MKREF.
1560 C.4 lc-05-standard-data-container
1562 Type: change
1564 [6]
1566 joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a
1567 "standard data container" can be created with MKRESOURCE or not.
1569 Resolution: Not relevant once we switch to MKREF.
1571 C.5 lc-20-intro-mkresource
1573 Type: change
1575 [7]
1577 reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new
1578 MKRESOURCE method" to make it clear that it is being introduced for
1579 the first time here.
1581 Resolution: Say "The MKREF method defined normatively here . . ."
1583 C.6 lc-22-coll
1585 Type: change
1587 [8]
1589 reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
1590 collections can be created with MKRESOURCE.
1592 Resolution: (1) Strip all non-redirect-ref functionality from
1593 MKRESOURCE, then (2) later switch to a new method.
1595 C.7 lc-25-atomic
1597 Type: change
1599 [9]
1601 reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a
1602 client? Can another client access the new resource's properties
1603 before they have been fully initialized? Maybe the MKRESOURCE request
1604 should let the client ask for it to be atomic.
1606 Resolution: No longer relevant once we switch to MKREF with no
1607 request body. Also, as an intermediate step MKRESOURCE is defined to
1608 be atomic.
1610 C.8 lc-42-no-webdav
1611 Type: change
1613 [10]
1615 yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method
1616 that creates only redirect references. The MKRESOURCE method hinders
1617 experiment because a user of a server who wishes to add support for
1618 the creation of a new resource type can't simply throw in another
1619 Apache module and allow it to provide the code for the new resource
1620 type. They have to find the code used for MKRESOURCE and change it to
1621 support the new resource type.
1623 Resolution: We will replace MKRESOURCE with MKREF, which creates only
1624 redirect reference resources.
1626 C.9 lc-23-body
1628 Type: change
1630 [11]
1632 reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the
1633 statement that the body of the resource is empty (PostConditions). It
1634 would be good if the response to GET included a response body that
1635 could be shown to a user by a client that doesn't do automatic
1636 redirection. There is a related problem in Section 6 on PUT. It is
1637 wrong to assume that what is PUT to a resource is what GET will
1638 return. In Section 6, say "A PUT with Apply-To-RR MAY contain a
1639 request body. The semantics of the request body is out of scope for
1640 this specification..." Also fix the discussion of example 6.2.
1642 Resolution: Redirect references cannot have bodies. GET with
1643 Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
1644 403. See also issue 1.
1646 C.10 lc-47-207
1648 Type: change
1650 [12]
1652 yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to
1653 get rid of the request message body of MKRESOURCE, 207 would not be
1654 an appropriate response code. The description of 409 might lead
1655 someone to believe that you can't create redirect references outside
1656 of WebDAV namespaces. Suggests a different description.
1658 Resolution: No longer relevant - MKREF can't get a 207 response.
1660 Revise to make it clear that the first condition will only occur in
1661 WebDAV-compliant namespaces.
1663 C.11 lc-49-put
1665 Type: change
1667 [13]
1669 yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence
1670 of Example 6.2, which says that PUT replaces the reference with a
1671 different resource.
1673 Resolution: No longer relevant. Deleted this example in response to
1674 issue 48.
1676 C.12 lc-75-ignore
1678 Type: change
1680 [14]
1682 reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref
1683 header is used on a request to any other sort of resource besides a
1684 redirect reference resource, the server SHOULD ignore it." Don't need
1685 to say this since HTP already says that any header that is not
1686 understood should be ignored.
1688 Resolution: Need to keep this to specify what a server that does
1689 support this protocol needs to do when the header appears in a
1690 request to a non-redirect-ref resource. However, say "MUST".
1692 Appendix D. Open issues (to be removed by RFC Editor before publication)
1694 D.1 lc-85-301
1696 Type: change
1698 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302
1699 redirects, especially 301.
1701 D.2 lc-38-not-hierarchical
1703 Type: change
1705 [15]
1707 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The
1708 first sentence of the second paragraph of the introduction of the
1709 redirect spec asserts that the URIs of WebDAV compliant resources
1710 match to collections. The WebDAV standard makes no such requirement.
1711 I therefore move that this sentence be stricken.
1713 Resolution: State the more general HTTP rationale first (alternative
1714 names for the same resource), then introduce the collection hierarchy
1715 rationale, which applies only if you are in a WebDAV-compliant space.
1717 D.3 lc-36-server
1719 Type: change
1721 [16]
1723 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"
1724 with "unrelated system" throughout.
1726 Resolution: Try replacing "server" with "host" in some contexts,
1727 rephrasing in passive voice in others. See also issue 40.
1729 D.4 lc-33-forwarding
1731 Type: change
1733 [17]
1735 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace
1736 "forward" with "redirect" throughout.
1738 Resolution: Use "redirect" for the behavior redirect resources do
1739 exhibit. Use "forward" for the contrasting behavior (passing a method
1740 on to the target with no client action needed). Define these two
1741 terms. See also issue 40.
1743 D.5 lc-37-integrity
1745 Type: change
1747 [18]
1749 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7
1750 "Servers are not required to enforce the integrity of redirect
1751 references." Integrity is not defined. Replace with something
1752 clearer.
1754 Resolution: Rewrite to say that the server MUST NOT update the target
1755 See also issue 6.
1757 D.6 3-terminology-redirectref
1759 Type: change
1761 [19]
1763 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of
1764 "redirect reference resource" to "redirect resource".
1766 D.7 lc-19-direct-ref
1768 Type: change
1770 [20]
1772 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6,
1773 para 3 discussions of the Apply-to-Redirect-Ref header make it sound
1774 as if we are specifying direct reference behavior.
1776 Resolution: Change these passages so that the contrast is between
1777 applying the method to the redirect reference and responding with a
1778 302.
1780 D.8 lc-41-no-webdav
1782 Type: change
1784 [21]
1786 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references
1787 independent of the rest of WebDAV. The creation method for redirect
1788 references shouldn't require an XML request body.
1790 Resolution: We will make redirect references independent of the rest
1791 of WebDAV. MKREF will not have an XML request body.
1793 D.9 lc-58-update
1795 Type: change
1797 [22]
1799 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way
1800 to update the target of a redirect reference.
1802 Resolution: Agreed. See also issues 6, 43.
1804 D.10 lc-24-properties
1806 Type: change
1808 [23]
1810 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence
1811 "The properties of the new resource are as specified by the
1812 DAV:propertyupdate request body, using PROPPATCH semantics" with the
1813 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate
1814 request body to initialize resource properties. Herein, the semantics
1815 is the same as when sending a MKRESOURCE request without a request
1816 body, followed by a PROPPATCH with the DAV:propertyupdate request
1817 body."
1819 Resolution: No longer relevant once we switch to MKREF with no
1820 request body.
1822 D.11 lc-48-s6
1824 Type: change
1826 [24]
1828 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6
1829 with just this: A redirect resource, upon receiving a request without
1830 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)
1831 response. The 302 (Found) response MUST include a location header
1832 identifying the target and a Redirect-Ref header. If a redirect
1833 resource receives a request with an Apply-To-Redirect-Ref header then
1834 the redirect reference resource MUST apply the method to itself
1835 rather than blindly returning a 302 (Found) response.
1837 Resolution: Keep a summary along the lines of Yaron's proposal (don't
1838 use the word "blindly"). Keep the bullets detailing the headers to be
1839 returned. Delete the rest, including the examples. See also issue 28,
1840 29, 30, 31, 32.
1842 D.12 lc-28-lang
1844 Type: edit
1846 [25]
1848 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence
1849 "A reference-aware WebDAV client can act on this response in one of
1850 two ways." A client can act on the response in any way it wants.
1852 Resolution: Agreed. See also issue 48.
1854 D.13 lc-29-lang
1856 Type: edit
1858 [26]
1860 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't
1861 need to be stated. Maybe note in an example.
1863 Resolution: Agreed. See also issue 48.
1865 D.14 lc-44-pseudo
1867 Type: change
1869 [27]
1871 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an
1872 optional prop XML element to the response element in 207 responses,
1873 define a new location XML element and a new refresource XML element.
1875 Resolution: Agree to define new XML elements that are not
1876 pseudo-properties. Disagreement about whether refresource is needed.
1877 See issue 61.
1879 D.15 lc-61-pseudo
1881 Type: change
1883 [28]
1884 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to
1885 ask future editors of RFC 2518 to define DAV:location with the
1886 semantics it has here. RFC 2518 should provide the information in the
1887 Location header somehow in multistatus responses, but not by using
1888 properties.
1890 Resolution: Define an XML element for location that is not a
1891 pseudo-property. We'll keep the recommendation that RFC 2518 add this
1892 for 302 responses. See also issue 44.
1894 D.16 lc-60-ex
1896 Type: change
1898 [29]
1900 reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear
1901 that these are just examples of client behavior, and are not meant to
1902 limit the client's behavior to these options.
1904 Resolution: Agreed to delete this paragraph. Continue discussion of
1905 what information should be returned with 302 in multistatus. Just
1906 location? Also redirectref?
1908 D.17 lc-62-oldclient
1910 Type: change
1912 [30]
1914 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim
1915 that non-referencing clients can't process 302 responses occurring in
1916 Multi-Status responses. They just have an extra round trip for each
1917 302.
1919 Resolution: Remove last sentence of the paragraph that recommends
1920 changes to RFC 2518.
1922 D.18 lc-63-move
1924 Type: change
1926 [31]
1928 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the
1929 perspective of a client? Agrees that there should be no 302s for
1930 member redirect references, but finds the rationale dubious.
1932 Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses
1933 special problems" and "due to atomicity".
1935 D.19 lc-06-reftarget-relative
1937 Type: change
1939 [32]
1941 joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about
1942 relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server
1943 required to resolve the relative URI and store it as absolute? Is the
1944 server required to keep DAV:reftarget pointing to the target resource
1945 as the reference / target move, or is DAV:reftarget a dead property?
1947 Resolution: DAV:reftarget is readonly and present only on redirect
1948 references that are also WebDAV resources. Add a method for setting
1949 the target. Change definition of Redirect-Ref header so that it has
1950 the target as its value (comes back on all 302 responses). Server
1951 MUST store the target exactly as it is set. It MUST NOT resolve
1952 relatives to absolutes and MUST NOT update if target resource moves.
1953 See also issue 17, 43, 50, 57
1955 D.20 lc-57-noautoupdate
1957 Type: change
1959 [33]
1961 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid
1962 servers from automatically updating redirect resources when their
1963 targets move.
1965 Resolution: Agreed. See also issue 6.
1967 D.21 lc-71-relative
1969 Type: change
1971 [34]
1973 reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the
1974 Request-URI or href minus its final segment.
1976 Resolution: Fix this.
1978 D.22 lc-53-s10
1979 Type: change
1981 [35]
1983 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in
1984 this section would have a very serious impact on the efficiency of
1985 mapping Request-URIs to resources in HTTP request processing. Also
1986 specify another type of redirect resource that does not behave as in
1987 section 10, but instead would "expose the behavior we see today in
1988 various HTTP servers that allow their users to create 300 resources."
1989 Be sure we know what behavior will be if the redirect location is not
1990 an HTTP URL, but, say ftp.
1992 Resolution: We won't define 2 sorts of redirect references here.
1993 Servers SHOULD respond with 302 as described here, but if they can't
1994 do that, respond with 404 Not Found. (It's hard to modularize the
1995 behavior specified - it impacts processing Not Found cases of all
1996 methods, so you can't just add it to an HTTP server in a redirect ref
1997 module.)
1999 D.23 lc-72-trailingslash
2001 Type: change
2003 [36]
2005 reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget
2006 from ending in "/"
2008 Resolution: Make the note warn about the possibility of two slashes
2009 in a row, recommend against ending target with a slash, since that
2010 could result in two slashes in a row.
2012 D.24 lc-50-blindredirect
2014 Type: change
2016 [37]
2018 yarong@Exchange.Microsoft.com (2000-02-11): Replace current language
2019 explaining the purpose of the Redirect-Ref header with language that
2020 simply states that it marks blind 302 responses from redirect
2021 resources. (Section 6.3, 11.1)
2023 Resolution: Section 6.3 was removed in response to issue 48. In 11.1,
2024 change the definition of the Redirect-Ref header to have the value of
2025 the target (relative URI) as its value. Then we don't need a method
2026 for retrieving the target's relative URI. Presence of the
2027 Redirect-Ref header lets the client know that the resource accepts
2028 Apply-To-RR header and the new method for updating target. Reject
2029 Yaron's suggested language, but make the above changes.
2031 D.25 lc-74-terminology
2033 Type: change
2035 [38]
2037 reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find
2038 some good name for this an use it consistently
2040 D.26 lc-76-location
2042 Type: change
2044 [39]
2046 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real
2047 (live) property, get rid of the DAV:reftarget property
2049 D.27 lc-79-accesscontrol
2051 Type: change
2053 [40]
2055 reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments,
2056 the owner of a resource might be able to use access control to
2057 prevent others from creating references to that resource." That would
2058 not be consistent with the concept of redirect references as weak
2059 links (e.g. think of moving a resource to a different locationo that
2060 is already the target of some redirection reference.
2062 D.28 lc-80-i18n
2064 Type: change
2066 [41]
2068 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot
2069 of this section, since this protocol extends WebDAV. Just reference
2070 [WebDAV].
2072 D.29 lc-55-iana
2074 Type: change
2076 [42]
2078 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section
2079 to list all methods, headers, XML elements, MIME types, URL schemes,
2080 etc., defined by the spec.
2082 Resolution: Agreed.
2084 Intellectual Property Statement
2086 The IETF takes no position regarding the validity or scope of any
2087 intellectual property or other rights that might be claimed to
2088 pertain to the implementation or use of the technology described in
2089 this document or the extent to which any license under such rights
2090 might or might not be available; neither does it represent that it
2091 has made any effort to identify any such rights. Information on the
2092 IETF's procedures with respect to rights in standards-track and
2093 standards-related documentation can be found in BCP-11. Copies of
2094 claims of rights made available for publication and any assurances of
2095 licenses to be made available, or the result of an attempt made to
2096 obtain a general license or permission for the use of such
2097 proprietary rights by implementors or users of this specification can
2098 be obtained from the IETF Secretariat.
2100 The IETF invites any interested party to bring to its attention any
2101 copyrights, patents or patent applications, or other proprietary
2102 rights which may cover technology that may be required to practice
2103 this standard. Please address the information to the IETF Executive
2104 Director.
2106 Full Copyright Statement
2108 Copyright (C) The Internet Society (2003). All Rights Reserved.
2110 This document and translations of it may be copied and furnished to
2111 others, and derivative works that comment on or otherwise explain it
2112 or assist in its implementation may be prepared, copied, published
2113 and distributed, in whole or in part, without restriction of any
2114 kind, provided that the above copyright notice and this paragraph are
2115 included on all such copies and derivative works. However, this
2116 document itself may not be modified in any way, such as by removing
2117 the copyright notice or references to the Internet Society or other
2118 Internet organizations, except as needed for the purpose of
2119 developing Internet standards in which case the procedures for
2120 copyrights defined in the Internet Standards process must be
2121 followed, or as required to translate it into languages other than
2122 English.
2124 The limited permissions granted above are perpetual and will not be
2125 revoked by the Internet Society or its successors or assignees.
2127 This document and the information contained herein is provided on an
2128 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2129 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2130 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2131 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2132 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2134 Acknowledgment
2136 Funding for the RFC Editor function is currently provided by the
2137 Internet Society.