idnits 2.17.1
draft-ietf-webdav-bind-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1448.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1432.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1438.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1454), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 41.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
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 draft header indicates that this document updates RFC2518, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
(Using the creation date from RFC2518, updated by this document, for
RFC5378 checks: 1997-07-21)
-- 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 (March 10, 2004) is 7351 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)
== Unused Reference: 'RFC2026' is defined on line 1162, but no explicit
reference was found in the text
** 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'
Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group G. Clemm
2 Internet-Draft IBM
3 Updates: 2518 (if approved) J. Crawford
4 Expires: September 8, 2004 IBM Research
5 J. Reschke
6 greenbytes
7 J. Whitehead
8 U.C. Santa Cruz
9 March 10, 2004
11 Binding Extensions to Web Distributed Authoring and Versioning
12 (WebDAV)
13 draft-ietf-webdav-bind-04
15 Status of this Memo
17 By submitting this Internet-Draft, I certify that any applicable
18 patent or other IPR claims of which I am aware have been disclosed,
19 and any of which I become aware will be disclosed, in accordance with
20 RFC 3667.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that other
24 groups may also distribute working documents as Internet-Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at http://
32 www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on September 8, 2004.
39 Copyright Notice
41 Copyright (C) The Internet Society (2004). All Rights Reserved.
43 Abstract
45 This specification defines bindings, and the BIND method for creating
46 multiple bindings to the same resource. Creating a new binding to a
47 resource causes at least one new URI to be mapped to that resource.
48 Servers are required to insure the integrity of any bindings that
49 they allow to be created.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
54 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
55 1.2 Rationale for Distinguishing Bindings from URI Mappings . . 6
56 1.3 Method Preconditions and Postconditions . . . . . . . . . . 7
57 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . 7
58 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . 8
59 2.2 URI Mappings Created by a new Binding . . . . . . . . . . . 9
60 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . 10
61 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . 11
62 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . 12
63 2.6 Determining Whether Two Bindings Are to the Same Resource . 13
64 2.7 Discovering the Bindings to a Resource . . . . . . . . . . . 14
65 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 14
66 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . 14
67 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . 14
68 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . 15
69 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . 17
70 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . 17
71 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . 19
72 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . 19
73 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . 21
74 7. Additional Status Codes . . . . . . . . . . . . . . . . . . 21
75 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . 21
76 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . . . . 22
77 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . . . . 23
78 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . 24
79 8. Capability discovery . . . . . . . . . . . . . . . . . . . . 24
80 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . . 24
81 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . . 24
82 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . . . . 24
83 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . . . . 25
84 9. Security Considerations . . . . . . . . . . . . . . . . . . 25
85 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 25
86 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . . 25
87 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . . 25
88 9.4 Private Locations May Be Revealed . . . . . . . . . . . . . 26
89 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . 26
90 10. Internationalization Considerations . . . . . . . . . . . . 26
91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
93 Normative References . . . . . . . . . . . . . . . . . . . . 26
94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
95 A. Change Log (to be removed by RFC Editor before
96 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
98 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . 28
99 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . . 28
100 B. Resolved issues (to be removed by RFC Editor before
101 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
102 B.1 ED_updates . . . . . . . . . . . . . . . . . . . . . . . . . 28
103 B.2 ED_authors . . . . . . . . . . . . . . . . . . . . . . . . . 29
104 B.3 locking . . . . . . . . . . . . . . . . . . . . . . . . . . 29
105 B.4 5.1_LOOP_STATUS . . . . . . . . . . . . . . . . . . . . . . 29
106 B.5 5.1_506_STATUS_STREAMING . . . . . . . . . . . . . . . . . . 30
107 B.6 9.2_redirect_loops . . . . . . . . . . . . . . . . . . . . . 30
108 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
109 Intellectual Property and Copyright Statements . . . . . . . 33
111 1. Introduction
113 This specification extends the WebDAV Distributed Authoring Protocol
114 to enable clients to create new access paths to existing resources.
115 This capability is useful for several reasons:
117 URIs of WebDAV-compliant resources are hierarchical and correspond to
118 a hierarchy of collections in resource space. The WebDAV Distributed
119 Authoring Protocol makes it possible to organize these resources into
120 hierarchies, placing them into groupings, known as collections, which
121 are more easily browsed and manipulated than a single flat
122 collection. However, hierarchies require categorization decisions
123 that locate resources at a single location in the hierarchy, a
124 drawback when a resource has multiple valid categories. For example,
125 in a hierarchy of vehicle descriptions containing collections for
126 cars and boats, a description of a combination car/boat vehicle could
127 belong in either collection. Ideally, the description should be
128 accessible from both. Allowing clients to create new URIs that access
129 the existing resource lets them put that resource into multiple
130 collections.
132 Hierarchies also make resource sharing more difficult, since
133 resources that have utility across many collections are still forced
134 into a single collection. For example, the mathematics department at
135 one university might create a collection of information on fractals
136 that contains bindings to some local resources, but also provides
137 access to some resources at other universities. For many reasons, it
138 may be undesirable to make physical copies of the shared resources on
139 the local server: to conserve disk space, to respect copyright
140 constraints, or to make any changes in the shared resources visible
141 automatically. Being able to create new access paths to existing
142 resources in other collections or even on other servers is useful for
143 this sort of case.
145 The BIND method defined here provides a mechanism for allowing
146 clients to create alternative access paths to existing WebDAV
147 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to
148 work because there are mappings between URIs and resources. A method
149 is addressed to a URI, and the server follows the mapping from that
150 URI to a resource, applying the method to that resource. Multiple
151 URIs may be mapped to the same resource, but until now there has been
152 no way for clients to create additional URIs mapped to existing
153 resources.
155 BIND lets clients associate a new URI with an existing WebDAV
156 resource, and this URI can then be used to submit requests to the
157 resource. Since URIs of WebDAV resources are hierarchical, and
158 correspond to a hierarchy of collections in resource space, the BIND
159 method also has the effect of adding the resource to a collection.
160 As new URIs are associated with the resource, it appears in
161 additional collections.
163 A BIND request does not create a new resource, but simply makes
164 available a new URI for submitting requests to an existing resource.
165 The new URI is indistinguishable from any other URI when submitting a
166 request to a resource. Only one round trip is needed to submit a
167 request to the intended target. Servers are required to enforce the
168 integrity of the relationships between the new URIs and the resources
169 associated with them. Consequently, it may be very costly for
170 servers to support BIND requests that cross server boundaries.
172 This specification is organized as follows. Section 1.1 defines
173 terminology used in the rest of the specification, while Section 2
174 overviews bindings. Section 3 defines the new properties needed to
175 support multiple bindings to the same resource. Section 4 specifies
176 the BIND method, used to create multiple bindings to the same
177 resource. Section 5 specifies the UNBIND method, used to remove a
178 binding to a resource. Section 6 specifies the REBIND method, used
179 to move a binding to another collection.
181 1.1 Terminology
183 The terminology used here follows and extends that in the WebDAV
184 Distributed Authoring Protocol specification [RFC2518].
186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
188 document are to be interpreted as described in [RFC2119].
190 This document uses XML DTD fragments ([XML]) as a purely notational
191 convention. WebDAV request and response bodies cannot be validated
192 due to the specific extensibility rules defined in section 23 of
193 [RFC2518] and due to the fact that all XML elements defined by this
194 specification use the XML namespace name "DAV:". In particular:
196 o Element names use the "DAV:" namespace.
198 o Element ordering is irrelevant.
200 o Extension elements/attributes (elements/attributes not already
201 defined as valid child elements) may be added anywhere, except
202 when explicitly stated otherwise.
204 URI Mapping
206 A relation between an absolute URI and a resource. For an
207 absolute URI U and the resource it identifies R, the URI mapping
208 can be thought of as (U => R). Since a resource can represent
209 items that are not network retrievable, as well as those that are,
210 it is possible for a resource to have zero, one, or many URI
211 mappings. Mapping a resource to an "http" scheme URI makes it
212 possible to submit HTTP protocol requests to the resource using
213 the URI.
215 Path Segment
217 Informally, the characters found between slashes ("/") in a URI.
218 Formally, as defined in section 3.3 of [RFC2396].
220 Binding
222 A relation between a single path segment (in a collection) and a
223 resource. A binding is part of the state of a collection. If two
224 different collections contain a binding between the same path
225 segment and the same resource, these are two distinct bindings.
226 So for a collection C, a path segment S, and a resource R, the
227 binding can be thought of as C:(S -> R). Bindings create URI
228 mappings, and hence allow requests to be sent to a single resource
229 from multiple locations in a URI namespace. For example, given a
230 collection C (accessible through the URI http://www.example.com/
231 CollX), a path segment S (equal to "foo.html"), and a resource R,
232 then creating the binding C: (S -> R) makes it possible to use the
233 URI http://www.example.com/CollX/foo.html to access R.
235 Collection
237 A resource that contains, as part of its state, a set of bindings
238 that identify internal member resources.
240 Internal Member URI
242 The URI that identifies an internal member of a collection, and
243 that consists of the URI for the collection, followed by a slash
244 character ('/'), followed by the path segment of the binding for
245 that internal member.
247 1.2 Rationale for Distinguishing Bindings from URI Mappings
249 In [RFC2518], the state of a collection is defined as containing a
250 list of internal member URIs. If there are multiple mappings to a
251 collection, then the state of the collection is different when you
252 refer to it via a different URI. This is undesirable, since ideally a
253 collection's membership should remain the same, independent of which
254 URI was used to reference it.
256 The notion of binding is introduced to separate the final segment of
257 a URI from its parent collection's contribution. This done, a
258 collection can be defined as containing a set of bindings, thus
259 permitting new mappings to a collection without modifying its
260 membership. The authors of this specification anticipate and
261 recommend that future revisions of [RFC2518] will update the
262 definition of the state of a collection to correspond to the
263 definition in this document.
265 1.3 Method Preconditions and Postconditions
267 A "precondition" of a method describes the state on the server that
268 must be true for that method to be performed. A "postcondition" of a
269 method describes the state on the server that must be true after that
270 method has completed. If a method precondition or postcondition for
271 a request is not satisfied, the response status of the request MUST
272 be either 403 (Forbidden) if the request should not be repeated
273 because it will always fail, or 409 (Conflict) if it is expected that
274 the user might be able to resolve the conflict and resubmit the
275 request.
277 In order to allow better client handling of 403 and 409 responses, a
278 distinct XML element type is associated with each method precondition
279 and postcondition of a request. When a particular precondition is
280 not satisfied or a particular postcondition cannot be achieved, the
281 appropriate XML element MUST be returned as the child of a top-level
282 DAV:error element in the response body, unless otherwise negotiated
283 by the request. In a 207 Multi-Status response, the DAV:error
284 element would appear in the appropriate DAV:responsedescription
285 element.
287 2. Overview of Bindings
289 Bindings are part of the state of a collection. They define the
290 internal members of the collection, and the names of those internal
291 members.
293 Bindings are added and removed by a variety of existing HTTP methods.
294 A method that creates a new resource, such as PUT, COPY, and MKCOL,
295 adds a binding. A method that deletes a resource, such as DELETE,
296 removes a binding. A method that moves a resource (e.g. MOVE) both
297 adds a binding (in the destination collection) and removes a binding
298 (in the source collection). The BIND method introduced here provides
299 a mechanism for adding a second binding to an existing resource.
300 There is no difference between an initial binding added by PUT, COPY,
301 or MKCOL, and additional bindings added with BIND.
303 It would be very undesirable if one binding could be destroyed as a
304 side effect of operating on the resource through a different binding.
305 In particular, the removal of one binding to a resource (e.g. with a
306 DELETE or a MOVE) MUST NOT disrupt another binding to that resource,
307 e.g. by turning that binding into a dangling path segment. The
308 server MUST NOT reclaim system resources after removing one binding,
309 while other bindings to the resource remain. In other words, the
310 server MUST maintain the integrity of a binding.
312 2.1 Bindings to Collections
314 Bindings to collections can result in loops, which servers MUST
315 detect when processing "Depth: infinity" requests. It is sometimes
316 possible to complete an operation in spite of the presence of a loop.
317 However, the 506 (Loop Detected) status code is defined in Section 7
318 for use in contexts where an operation is terminated because a loop
319 was encountered.
321 Creating a new binding to a collection makes each resource associated
322 with a binding in that collection accessible via a new URI, and thus
323 creates new URI mappings to those resources but no new bindings.
325 For example, suppose a new binding CollY is created for collection C1
326 in the figure below. It immediately becomes possible to access
327 resource R1 using the URI /CollY/x.gif and to access resource R2
328 using the URI /CollY/y.jpg, but no new bindings for these child
329 resources were created. This is because bindings are part of the
330 state of a collection, and associate a URI that is relative to that
331 collection with its target resource. No change to the bindings in
332 Collection C1 is needed to make its children accessible using /CollY/
333 x.gif and /CollY/y.jpg.
335 +-------------------------+
336 | Root Collection |
337 | bindings: |
338 | CollX CollY |
339 +-------------------------+
340 | /
341 | /
342 | /
343 +------------------+
344 | Collection C1 |
345 | bindings: |
346 | x.gif y.jpg |
347 +------------------+
348 | \
349 | \
350 | \
351 +-------------+ +-------------+
352 | Resource R1 | | Resource R2 |
353 +-------------+ +-------------+
355 2.2 URI Mappings Created by a new Binding
357 Suppose a binding from "Binding-Name" to resource R to be added to a
358 collection, C. Then if C-MAP is the set of URIs that were mapped to
359 C before the BIND request, then for each URI "C-URI" in C-MAP, the
360 URI "C-URI/Binding-Name" is mapped to resource R following the BIND
361 request.
363 For example, if a binding from "foo.html" to R is added to a
364 collection C, and if the following URIs are mapped to C:
366 http://www.example.com/A/1/
367 http://example.com/A/one/
369 then the following new mappings to R are introduced:
371 http://www.example.com/A/1/foo.html
372 http://example.com/A/one/foo.html
374 Note that if R is a collection, additional URI mappings are created
375 to the descendents of R. Also, note that if a binding is made in
376 collection C to C itself (or to a parent of C), an infinite number of
377 mappings are introduced.
379 For example, if a binding from "myself" to C is then added to C, the
380 following infinite number of additional mappings to C are introduced:
382 http://www.example.com/A/1/myself
383 http://www.example.com/A/1/myself/myself
384 ...
386 and the following infinite number of additional mappings to R are
387 introduced:
389 http://www.example.com/A/1/myself/foo.html
390 http://www.example.com/A/1/myself/myself/foo.html
391 ...
393 2.3 COPY and Bindings
395 As defined in Section 8.8 of [RFC2518], COPY causes the resource
396 identified by the Request-URI to be duplicated, and makes the new
397 resource accessible using the URI specified in the Destination
398 header. Upon successful completion of a COPY, a new binding is
399 created between the last path segment of the Destination header, and
400 the destination resource. The new binding is added to its parent
401 collection, identified by the Destination header minus its final
402 segment.
404 The following figure shows an example: Suppose that a COPY is issued
405 to URI-3 for resource R (which is also mapped to URI-1 and URI-2),
406 with the Destination header set to URI-X. After successful
407 completion of the COPY operation, resource R is duplicated to create
408 resource R', and a new binding has been created which creates at
409 least the URI mapping between URI-X and the new resource (although
410 other URI mappings may also have been created).
412 URI-1 URI-2 URI-3 URI-X
413 | | | |
414 | | | <---- URI Mappings ----> |
415 | | | |
416 +---------------------+ +------------------------+
417 | Resource R | | Resource R' |
418 +---------------------+ +------------------------+
420 It might be thought that a COPY request with "Depth: 0" on a
421 collection would duplicate its bindings, since bindings are part of
422 the collection's state. This is not the case, however. The
423 definition of Depth in [RFC2518] makes it clear that a "Depth: 0"
424 request does not apply to a collection's members. Consequently, a
425 COPY with "Depth: 0" does not duplicate the bindings contained by the
426 collection.
428 If a COPY request causes an existing resource to be updated, the
429 bindings to that resource MUST be unaffected by the COPY request.
430 Using the preceding example, suppose that a COPY request is issued to
431 URI-X for resource R', with the Destination header set to URI-2. The
432 content and dead properties of resource R would be updated to be a
433 copy of those of resource R', but the mappings from URI-1, URI-2, and
434 URI-3 to resource R remain unaffected. If because of multiple
435 bindings to a resource, more than one source resource updates a
436 single destination resource, the order of the updates is server
437 defined.
439 If a COPY request would cause a new resource to be created as a copy
440 of an existing resource, and that COPY request has already created a
441 copy of that existing resource, the COPY request instead creates
442 another binding to the previous copy, instead of creating a new
443 resource.
445 2.4 DELETE and Bindings
447 When there are multiple bindings to a resource, a DELETE applied to
448 that resource MUST NOT remove any bindings to that resource other
449 than the one identified by the request URI. For example, suppose the
450 collection identified by the URI "/a" has a binding named "x" to a
451 resource R, and another collection identified by "/b" has a binding
452 named "y" to the same resource R. Then a DELETE applied to "/a/x"
453 removes the binding named "x" from "/a" but MUST NOT remove the
454 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues
455 to identify the resource R). In particular, although Section 8.6.1
456 of [RFC2518] states that during DELETE processing, a server "MUST
457 remove any URI for the resource identified by the Request-URI from
458 collections which contain it as a member", a server that supports the
459 binding protocol MUST NOT follow this requirement.
461 When DELETE is applied to a collection, it MUST NOT modify the
462 membership of any other collection that is not itself a member of the
463 collection being deleted. For example, if both "/a/.../x" and "/b/
464 .../y" identify the same collection, C, then applying DELETE to "/a"
465 MUST NOT delete an internal member from C or from any other
466 collection that is a member of C, because that would modify the
467 membership of "/b".
469 If a collection supports the UNBIND method (see Section 5), a DELETE
470 of an internal member of a collection MAY be implemented as an UNBIND
471 request. In this case, applying DELETE to a Request-URI has the
472 effect of removing the binding identified by the final segment of the
473 Request-URI from the collection identified by the Request-URI minus
474 its final segment. Although [RFC2518] allows a DELETE to be a
475 non-atomic operation, when the DELETE operation is implemented as an
476 UNBIND, the operation is atomic. In particular, a DELETE on a
477 hierarchy of resources is simply the removal of a binding to the
478 collection identified by the Request-URI.
480 2.5 MOVE and Bindings
482 When MOVE is applied to a resource, the other bindings to that
483 resource MUST be unaffected, and if the resource being moved is a
484 collection, the bindings to any members of that collection MUST be
485 unaffected. Also, if MOVE is used with Overwrite:T to delete an
486 existing resource, the constraints specified for DELETE apply.
488 If the destination collection of a MOVE request supports the REBIND
489 method (see Section 6), a MOVE of a resource into that collection MAY
490 be implemented as a REBIND request. Although [RFC2518] allows a MOVE
491 to be a non-atomic operation, when the MOVE operation is implemented
492 as a REBIND, the operation is atomic. In particular, applying a MOVE
493 to a Request-URI and a Destination URI has the effect of removing a
494 binding to a resource (at the Request-URI), and creating a new
495 binding to that resource (at the Destination URI).
497 As an example, suppose that a MOVE is issued to URI-3 for resource R
498 below (which is also mapped to URI-1 and URI-2), with the Destination
499 header set to URI-X. After successful completion of the MOVE
500 operation, a new binding has been created which creates the URI
501 mapping between URI-X and resource R. The binding corresponding to
502 the final segment of URI-3 has been removed, which also causes the
503 URI mapping between URI-3 and R to be removed. If resource R were a
504 collection, old URI-3 based mappings to members of R would have been
505 removed, and new URI-X based mappings to members of R would have been
506 created.
508 >> Before Request:
510 URI-1 URI-2 URI-3
511 | | |
512 | | | <---- URI Mappings
513 | | |
514 +---------------------+
515 | Resource R |
516 +---------------------+
517 >> After Request:
519 URI-1 URI-2 URI-X
520 | | |
521 | | | <---- URI Mappings
522 | | |
523 +---------------------+
524 | Resource R |
525 +---------------------+
527 Although [RFC2518] allows a MOVE on a collection to be a non-atomic
528 operation, a MOVE implemented as a REBIND MUST be atomic. Even when
529 the Request-URI identifies a collection, the MOVE operation involves
530 only removing one binding to that collection and adding another.
531 There are no operations on bindings to any of its children, so the
532 case of MOVE on a collection is the same as the case of MOVE on a
533 non-collection resource. Both are atomic.
535 2.6 Determining Whether Two Bindings Are to the Same Resource
537 It is useful to have some way of determining whether two bindings are
538 to the same resource. Two resources might have identical contents
539 and properties, but not be the same resource (e.g. an update to one
540 resource does not affect the other resource).
542 The REQUIRED DAV:resource-id property defined in Section 3.1 is a
543 resource identifier, which MUST be unique across all resources for
544 all time. If the values of DAV:resource-id returned by PROPFIND
545 requests through two bindings are identical, the client can be
546 assured that the two bindings are to the same resource.
548 The DAV:resource-id property is created, and its value assigned, when
549 the resource is created. The value of DAV:resource-id MUST NOT be
550 changed. Even after the resource is no longer accessible through any
551 URI, that value MUST NOT be reassigned to another resource's
552 DAV:resource-id property.
554 Any method that creates a new resource MUST assign a new, unique
555 value to its DAV:resource-id property. For example, a PUT or a COPY
556 that creates a new resource must assign a new, unique value to the
557 DAV:resource-id property of that new resource.
559 On the other hand, any method that affects an existing resource MUST
560 NOT change the value of its DAV:resource-id property. For example, a
561 PUT or a COPY that updates an existing resource must not change the
562 value of its DAV:resource-id property. A MOVE, since it does not
563 create a new resource, but only changes the location of an existing
564 resource, must not change the value of the DAV:resource-id property.
566 2.7 Discovering the Bindings to a Resource
568 An OPTIONAL DAV:parent-set property on a resource provides a list of
569 the bindings that associate a collection and a URI segment with that
570 resource. If the DAV:parent-set property exists on a given resource,
571 it MUST contain a complete list of all bindings to that resource that
572 the client is authorized to see. When deciding whether to support
573 the DAV:parent-set property, server implementers / administrators
574 should balance the benefits it provides against the cost of
575 maintaining the property and the security risks enumerated in
576 Sections 8.4 and 8.5.
578 3. Properties
580 The bind feature introduces the following properties for a resource.
582 A DAV:allprop PROPFIND request SHOULD NOT return any of the
583 properties defined by this document. This allows a binding server to
584 perform efficiently when a naive client, which does not understand
585 the cost of asking a server to compute all possible live properties,
586 issues a DAV:allprop PROPFIND request.
588 3.1 DAV:resource-id Property
590 The DAV:resource-id property is a REQUIRED property that enables
591 clients to determine whether two bindings are to the same resource.
592 The value of DAV:resource-id is a URI, and may use any registered URI
593 scheme that guarantees the uniqueness of the value across all
594 resources for all time (e.g. the opaquelocktoken: scheme defined in
595 [RFC2518]).
597
599 3.2 DAV:parent-set Property
601 The DAV:parent-set property is an OPTIONAL property that enables
602 clients to discover what collections contain a binding to this
603 resource (i.e. what collections have that resource as an internal
604 member). It contains an of href/segment pair for each collection
605 that has a binding to the resource. The href identifies the
606 collection, and the segment identifies the binding name of that
607 resource in that collection.
609 A given collection MUST appear only once in the DAV:parent-set for
610 any given binding, even if there are multiple URI mappings to that
611 collection. For example, if collection C1 is mapped to both /CollX
612 and /CollY, and C1 contains a binding named "x.gif" to a resource R1,
613 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the
614 DAV:parent-set of R1, but not both. But if C1 also had a binding
615 named "y.gif" to R1, then there would be two entries for C1 in the
616 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX,
617 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]).
619
620
621
622 PCDATA value: segment, as defined in section 3.3 of [RFC2396]
624 4. BIND Method
626 The BIND method modifies the collection identified by the
627 Request-URI, by adding a new binding from the segment specified in
628 the BIND body to the resource identified in the BIND body.
630 If a server cannot guarantee the integrity of the binding, the BIND
631 request MUST fail. Note that it is especially difficult to maintain
632 the integrity of cross-server bindings. Unless the server where the
633 resource resides knows about all bindings on all servers to that
634 resource, it may unwittingly destroy the resource or make it
635 inaccessible without notifying another server that manages a binding
636 to the resource. For example, if server A permits creation of a
637 binding to a resource on server B, server A must notify server B
638 about its binding and must have an agreement with B that B will not
639 destroy the resource while A's binding exists. Otherwise server B
640 may receive a DELETE request that it thinks removes the last binding
641 to the resource and destroy the resource while A's binding still
642 exists. The precondition DAV:cross-server-binding is defined below
643 for cases where servers fail cross-server BIND requests because they
644 cannot guarantee the integrity of cross-server bindings.
646 By default, if there already is a binding for the specified segment
647 in the collection, the new binding replaces the existing binding.
648 This default binding replacement behavior can be overridden using the
649 Overwrite header defined in Section 9.6 of [RFC2518].
651 Marshalling:
653 The request MAY include an Overwrite header.
655 The request body MUST be a DAV:bind XML element.
657
658 If the request succeeds, the server MUST return 201 (Created) when
659 a new binding was created and 200 (OK) when an existing binding
660 was replaced.
662 If a response body for a successful request is included, it MUST
663 be a DAV:bind-response XML element. Note that this document does
664 not define any elements for the BIND response body, but the
665 DAV:bind-response element is defined to ensure interoperability
666 between future extensions that do define elements for the BIND
667 response body.
669
671 Preconditions:
673 (DAV:bind-into-collection): The Request-URI MUST identify a
674 collection.
676 (DAV:bind-source-exists): The DAV:href element MUST identify a
677 resource.
679 (DAV:binding-allowed): The resource identified by the DAV:href
680 supports multiple bindings to it.
682 (DAV:cross-server-binding): If the resource identified by the
683 DAV:href element in the request body is on another server from the
684 collection identified by the request-URI, the server MUST support
685 cross-server bindings.
687 (DAV:name-allowed): The name specified by the DAV:segment is
688 available for use as a new binding name.
690 (DAV:can-overwrite): If the collection already contains a binding
691 with the specified path segment, and if an Overwrite header is
692 included, the value of the Overwrite header MUST be "T".
694 (DAV:cycle-allowed): If the DAV:href element identifies a
695 collection, and if the request-URI identifies a collection that is
696 a member of that collection, the server MUST support cycles in the
697 URI namespace.
699 (DAV:locked-update-allowed): If the collection identified by the
700 Request-URI is write-locked, then the appropriate token MUST be
701 specified in an If request header.
703 (DAV:locked-overwrite-allowed): If the collection already contains
704 a binding with the specified path segment, and if that binding is
705 protected by a write-lock, then the appropriate token MUST be
706 specified in an If request header.
708 Postconditions:
710 (DAV:new-binding): The collection MUST have a binding that maps
711 the segment specified in the DAV:segment element in the request
712 body, to the resource identified by the DAV:href element in the
713 request body.
715 4.1 Example: BIND
717 >> Request:
719 BIND /CollY HTTP/1.1
720 Host: www.example.com
721 Content-Type: text/xml; charset="utf-8"
722 Content-Length: xxx
724
725
726 bar.html
727 http://www.example.com/CollX/foo.html
728
730 >> Response:
732 HTTP/1.1 201 Created
734 The server added a new binding to the collection, "http://
735 www.example.com/CollY", associating "bar.html" with the resource
736 identified by the URI "http://www.example.com/CollX/foo.html".
737 Clients can now use the URI "http://www.example.com/CollY/bar.html",
738 to submit requests to that resource.
740 5. UNBIND Method
742 The UNBIND method modifies the collection identified by the
743 Request-URI, by removing the binding identified by the segment
744 specified in the UNBIND body.
746 Once a resource is unreachable by any URI mapping, the server MAY
747 reclaim system resources associated with that resource. If UNBIND
748 removes a binding to a resource, but there remain URI mappings to
749 that resource, the server MUST NOT reclaim system resources
750 associated with the resource.
752 Marshalling:
754 The request body MUST be a DAV:unbind XML element.
756
758 If the request succeeds, the server MUST return 200 (OK) when the
759 binding was successfully deleted.
761 If a response body for a successful request is included, it MUST
762 be a DAV:unbind-response XML element. Note that this document
763 does not define any elements for the UNBIND response body, but the
764 DAV:unbind-response element is defined to ensure interoperability
765 between future extensions that do define elements for the UNBIND
766 response body.
768
770 Preconditions:
772 (DAV:unbind-from-collection): The Request-URI MUST identify a
773 collection.
775 (DAV:unbind-source-exists): The DAV:segment element MUST identify
776 a binding in the collection identified by the Request-URI.
778 (DAV:locked-update-allowed): If the collection identified by the
779 Request-URI is write-locked, then the appropriate token MUST be
780 specified in the request.
782 (DAV:protected-url-deletion-allowed): If the binding identified by
783 the segment is protected by a write-lock, then the appropriate
784 token MUST be specified in the request.
786 Postconditions:
788 (DAV:binding-deleted): The collection MUST NOT have a binding for
789 the segment specified in the DAV:segment element in the request
790 body.
792 5.1 Example: UNBIND
794 >> Request:
796 UNBIND /CollX HTTP/1.1
797 Host: www.example.com
798 Content-Type: text/xml; charset="utf-8"
799 Content-Length: xxx
801
802
803 foo.html
804
806 >> Response:
808 HTTP/1.1 200 OK
810 The server removed the binding named "foo.html" from the collection,
811 "http://www.example.com/CollX". A request to the resource named
812 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found)
813 response.
815 6. REBIND Method
817 The REBIND method removes a binding to a resource from one
818 collection, and adds a binding to that resource into another
819 collection. It is effectively an atomic form of a MOVE request.
821 Marshalling:
823 The request MAY include an Overwrite header.
825 The request body MUST be a DAV:rebind XML element.
827
829 If the request succeeds, the server MUST return 201 (Created) when
830 a new binding was created and 200 (OK) when an existing binding
831 was replaced.
833 If a response body for a successful request is included, it MUST
834 be a DAV:rebind-response XML element. Note that this document
835 does not define any elements for the REBIND response body, but the
836 DAV:rebind-response element is defined to ensure interoperability
837 between future extensions that do define elements for the REBIND
838 response body.
840
842 Preconditions:
844 (DAV:rebind-into-collection): The Request-URI MUST identify a
845 collection.
847 (DAV:rebind-source-exists): The DAV:href element MUST identify a
848 resource.
850 (DAV:binding-allowed): The resource identified by the DAV:href
851 supports multiple bindings to it.
853 (DAV:cross-server-binding): If the resource identified by the
854 DAV:href element in the request body is on another server from the
855 collection identified by the request-URI, the server MUST support
856 cross-server bindings.
858 (DAV:name-allowed): The name specified by the DAV:segment is
859 available for use as a new binding name.
861 (DAV:can-overwrite): If the collection already contains a binding
862 with the specified path segment, and if an Overwrite header is
863 included, the value of the Overwrite header MUST be "T".
865 (DAV:cycle-allowed): If the DAV:href element identifies a
866 collection, and if the request-URI identifies a collection that is
867 a member of that collection, the server MUST support cycles in the
868 URI namespace.
870 (DAV:locked-update-allowed): If the collection identified by the
871 Request-URI is write-locked, then the appropriate token MUST be
872 specified in the request.
874 (DAV:protected-url-modification-allowed): If the collection
875 identified by the Request-URI already contains a binding with the
876 specified path segment, and if that binding is protected by a
877 write-lock, then the appropriate token MUST be specified in the
878 request.
880 (DAV:locked-source-collection-update-allowed): If the collection
881 identified by the parent collection prefix of the DAV:href URI is
882 write-locked, then the appropriate token MUST be specified in the
883 request.
885 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI
886 is protected by a write lock, then the appropriate token MUST be
887 specified in the request.
889 Postconditions:
891 (DAV:new-binding): The collection MUST have a binding that maps
892 the segment specified in the DAV:segment element in the request
893 body, to the resource that was identified by the DAV:href element
894 in the request body.
896 (DAV:binding-deleted): The URL specified in the DAV:href element
897 in the request body MUST NOT be mapped to a resource.
899 6.1 Example: REBIND
901 >> Request:
903 REBIND /CollX HTTP/1.1
904 Host: www.example.com
905 Content-Type: text/xml; charset="utf-8"
906 Content-Length: xxx
908
909
910 foo.html
911 http://www.example.com/CollY/bar.html
912
914 >> Response:
916 HTTP/1.1 200 OK
918 The server added a new binding to the collection, "http://
919 www.example.com/CollX", associating "foo.html" with the resource
920 identified by the URI "http://www.example.com/CollY/bar.html", and
921 removes the binding named "bar.html" from the collection identified
922 by the URI "http://www.example.com/CollY". Clients can now use the
923 URI "http://www.example.com/CollX/foo.html" to submit requests to
924 that resource, and requests on the URI "http://www.example.com/CollY/
925 bar.html" will fail with a 404 (Not Found) response.
927 7. Additional Status Codes
929 7.1 208 Already Reported
931 The 208 (Already Reported) status code can be used inside a
932 DAV:propstat response element to avoid enumerating the internal
933 members of multiple bindings to the same collection repeatedly. For
934 each binding to a collection inside the request's scope, only one
935 will be reported with a 200 status, while subsequent DAV:response
936 elements for all other bindings will use the 208 status, and no
937 DAV:response elements for their descendants are included.
939 Note that the 208 status will only occur for "Depth: infinity"
940 requests, and that it is of particular importance when the multiple
941 collection bindings cause a bind loop as discussed in Section 2.2.
943 A client can request the DAV:resourceid property in a PROPFIND
944 request to guarantee that they can accurately reconstruct the binding
945 structure of a collection with multiple bindings to a single
946 resource.
948 For backward compatibility with clients not aware of the 208 status
949 code appearing in multistatus response bodies, it SHOULD NOT be used
950 unless the client has signalled support for this specification using
951 the "DAV" request header (see Section 8.2). Instead, a 506 status
952 should be returned when a binding loop is discovered. This allows the
953 server to return the 506 as the top level return status, if it
954 discovers it before it started the response, or in the middle of a
955 multistatus, if it discovers it in the middle of streaming out a
956 multistatus response.
958 7.1.1 Example: PROPFIND by bind-aware client
960 For example, consider a PROPFIND request on /Coll (bound to
961 collection C), where the members of /Coll are /Coll/Foo (bound to
962 resource R) and /Coll/Bar (bound to collection C).
964 >> Request:
966 PROPFIND /Coll/ HTTP/1.1
967 Host: www.example.com
968 Depth: infinity
969 DAV: bind
970 Content-Type: text/xml; charset="utf-8"
971 Content-Length: xxx
973
974
975
976
977
978
979 >> Response:
981 HTTP/1.1 207 Multi-Status
982 Content-Type: text/xml; charset="utf-8"
983 Content-Length: xxx
985
986
987
988 http://www.example.com/Coll/
989
990
991 Loop Demo
992
993 HTTP/1.1 200 OK
994
995
996
997 http://www.example.com/Coll/Foo
998
999
1000 Bird Inventory
1001
1002 HTTP/1.1 200 OK
1003
1004
1005
1006 http://www.example.com/Coll/Bar
1007
1008
1009 Loop Demo
1010
1011 HTTP/1.1 208 Already Reported
1012
1013
1014
1016 7.1.2 Example: PROPFIND by non-bind-aware client
1018 In this example, the client isn't aware of the 208 status code
1019 introduced by this specification. As the "Depth: infinity" PROPFIND
1020 request would cause a loop condition, the whole request is rejected
1021 with a 506 status.
1023 >> Request:
1025 PROPFIND /Coll/ HTTP/1.1
1026 Host: www.example.com
1027 Depth: infinity
1028 Content-Type: text/xml; charset="utf-8"
1029 Content-Length: xxx
1031
1032
1033
1034
1036 >> Response:
1038 HTTP/1.1 506 Loop Detected
1040 7.2 506 Loop Detected
1042 The 506 (Loop Detected) status code indicates that the server
1043 terminated an operation because it encountered an infinite loop while
1044 processing a request with "Depth: infinity". This status indicates
1045 that the entire operation failed.
1047 8. Capability discovery
1049 8.1 OPTIONS method
1051 If the server supports bindings, it MUST return the compliance class
1052 name "bind" as a field in the "DAV" response header (see [RFC2518],
1053 section 9.1) from an OPTIONS request on any resource implemented by
1054 that server. A value of "bind" in the "DAV" header MUST indicate that
1055 the server supports all MUST level requirements and REQUIRED features
1056 specified in this document.
1058 8.2 'DAV' request header
1060 8.2.1 Generic syntax
1062 This specification introduces the 'DAV' request header that allows
1063 clients to signal compliance to specific WebDAV features. It has the
1064 same syntax as the response header defined in [RFC2518], section 9.1,
1065 but MAY be used with any method.
1067 Note that clients MUST NOT submit a specific compliance class name in
1068 the request header unless the specification defining this compliance
1069 class specifically defines it's semantics for clients.
1071 Note that if a server chooses to vary the result of a request based
1072 on values in the "DAV" header, the response either MUST NOT be
1073 cacheable or the server MUST mark the response accordingly using the
1074 "Vary" header (see [RFC2616], section 14.44).
1076 8.2.2 Client compliance class 'bind'
1078 Clients SHOULD signal support for all MUST level requirements and
1079 REQUIRED features by submitting a "DAV" request header containing the
1080 compliance class name "bind". In particular, the client MUST
1081 understand the 208 status code defined in Section 7.1.
1083 9. Security Considerations
1085 This section is provided to make WebDAV implementors aware of the
1086 security implications of this protocol.
1088 All of the security considerations of HTTP/1.1 and the WebDAV
1089 Distributed Authoring Protocol specification also apply to this
1090 protocol specification. In addition, bindings introduce several new
1091 security concerns and increase the risk of some existing threats.
1092 These issues are detailed below.
1094 9.1 Privacy Concerns
1096 In a context where cross-server bindings are supported, creating
1097 bindings on a trusted server may make it possible for a hostile agent
1098 to induce users to send private information to a target on a
1099 different server.
1101 9.2 Bind Loops
1103 Although bind loops were already possible in HTTP 1.1, the
1104 introduction of the BIND method creates a new avenue for clients to
1105 create loops accidentally or maliciously. If the binding and its
1106 target are on the same server, the server may be able to detect BIND
1107 requests that would create loops. Servers are required to detect
1108 loops that are caused by bindings to collections during the
1109 processing of any requests with "Depth: infinity".
1111 9.3 Bindings, and Denial of Service
1113 Denial of service attacks were already possible by posting URIs that
1114 were intended for limited use at heavily used Web sites. The
1115 introduction of BIND creates a new avenue for similar denial of
1116 service attacks. If cross-server bindings are supported, clients can
1117 now create bindings at heavily used sites to target locations that
1118 were not designed for heavy usage.
1120 9.4 Private Locations May Be Revealed
1122 If the DAV:parent-set property is maintained on a resource, the
1123 owners of the bindings risk revealing private locations. The
1124 directory structures where bindings are located are available to
1125 anyone who has access to the DAV:parent-set property on the resource.
1126 Moving a binding may reveal its new location to anyone with access to
1127 DAV:parent-set on its resource.
1129 9.5 DAV:parent-set and Denial of Service
1131 If the server maintains the DAV:parent-set property in response to
1132 bindings created in other administrative domains, it is exposed to
1133 hostile attempts to make it devote resources to adding bindings to
1134 the list.
1136 10. Internationalization Considerations
1138 All internationalization considerations mentioned in [RFC2518] also
1139 apply to this document.
1141 11. IANA Considerations
1143 All IANA considerations mentioned in [RFC2518] also apply to this
1144 document.
1146 12. Acknowledgements
1148 This draft is the collaborative product of the authors and Tyson
1149 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has
1150 benefited from thoughtful discussion by Jim Amsden, Peter Carlson,
1151 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun,
1152 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan
1153 Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James
1154 Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
1155 Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer,
1156 Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick
1157 Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and
1158 other members of the WebDAV working group.
1160 Normative References
1162 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1163 3", BCP 9, RFC 2026, October 1996.
1165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1166 Requirement Levels", BCP 14, RFC 2119, March 1997.
1168 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1169 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1170 August 1998.
1172 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1173 Jensen, "HTTP Extensions for Distributed Authoring --
1174 WEBDAV", RFC 2518, February 1999.
1176 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1177 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1178 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1180 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
1181 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
1182 Edition)", W3C REC-xml-20040204, February 2004, .
1185 Authors' Addresses
1187 Geoffrey Clemm
1188 IBM
1189 20 Maguire Road
1190 Lexington, MA 02421
1192 EMail: geoffrey.clemm@us.ibm.com
1194 Jason Crawford
1195 IBM Research
1196 P.O. Box 704
1197 Yorktown Heights, NY 10598
1199 EMail: ccjason@us.ibm.com
1201 Julian F. Reschke
1202 greenbytes GmbH
1203 Salzmannstrasse 152
1204 Muenster, NW 48159
1205 Germany
1207 EMail: julian.reschke@greenbytes.de
1208 Jim Whitehead
1209 UC Santa Cruz, Dept. of Computer Science
1210 1156 High Street
1211 Santa Cruz, CA 95064
1213 EMail: ejw@cse.ucsc.edu
1215 Appendix A. Change Log (to be removed by RFC Editor before publication)
1217 A.1 Since draft-ietf-webdav-bind-02
1219 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and
1220 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed
1221 resolution, but keep it open. Add issues "ED_references" and
1222 "4_507_status". Started work on index. Rename document to "Binding
1223 Extensions to Web Distributed Authoring and Versioning (WebDAV)".
1224 Rename "References" to "Normative References". Close issue
1225 "ED_references". CLose issue "4_507_status".
1227 A.2 Since draft-ietf-webdav-bind-03
1229 Add and close issues "9.2_redirect_loops", "ED_authors" and
1230 "ED_updates". Add section about capability discovery (DAV header).
1231 Close issues "5.1_LOOP_STATUS". Add and resolve new issue
1232 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue
1233 "locking" and resolve as invalid.
1235 Appendix B. Resolved issues (to be removed by RFC Editor before
1236 publication)
1238 Issues that were either rejected or resolved in this version of this
1239 document.
1241 B.1 ED_updates
1243 Type: edit
1245
1248 julian.reschke@greenbytes.de (2003-12-30): Shouldn't the BIND spec be
1249 labelled as "updating" RFC2518 and/or RFC3253?
1251 julian.reschke@greenbytes.de (2004-01-05): It seems that there was
1252 consensus to say that BIND does update RFC2518, while there's no
1253 consensus about the relationship to RFC3253. As this is a minor
1254 editorial question, I propose to just say "updated 2518" and to close
1255 the issue.
1257 Resolution (2004-01-09): State "updates 2518".
1259 B.2 ED_authors
1261 Type: edit
1263 julian.reschke@greenbytes.de (2004-01-02): Ensure contact information
1264 for all original authors is still correct, and that the authors in
1265 fact support the current draft.
1267 Resolution (2004-01-05): J. Slein removed as author and added to
1268 Acknowledgments.
1270 B.3 locking
1272 Type: change
1274
1276 lisa@xythos.com (2004-03-02): (concerns about the behaviour of
1277 multiple bindings to the same resource when the resource was locked
1278 via WebDAV LOCK on one of it's bindings).
1280 Resolution (2004-03-06): No issue here: given two URIs "a" and "b"
1281 mapped to the same resource, and a WebDAV LOCK that was requested for
1282 "a", attempts to modify the lockable state of "b" will fail unless
1283 the lock-token is presented. This is because the resource itself is
1284 locked, not only it's URI "a". See RFC2518, section 6.
1286 B.4 5.1_LOOP_STATUS
1288 Type: change
1290 julian.reschke@greenbytes.de (2002-10-11): Should the 506 status in a
1291 PROPFIND be handled differently?
1293 geoffrey.clemm@us.ibm.com (2003-08-03): Use new 208 status to report
1294 cycles in PROPFIND.
1296 julian.reschke@greenbytes.de (2003-11-16): Proposal: a) import DAV
1297 request header definition from rfc2518bis (note that the definition
1298 in the latest draft probably needs some more work) b) define a DAV
1299 compliance class for the BIND spec c) clarify that 208 should only be
1300 returned when the client specifies compliance to the BIND spec in the
1301 PROPFIND request (otherwise fail the complete request).
1303 Resolution (2004-01-02): Define DAV compliance class "bind", define
1304 DAV request header, clarify that 208 must only be used when the
1305 client signals that it knows about this specification.
1307 B.5 5.1_506_STATUS_STREAMING
1309 Type: change
1311 julian.reschke@greenbytes.de (2004-01-12): Take a server that allows
1312 Depth: infinity upon PROPFIND. In general, the only way to implement
1313 this efficiently is to *stream* the multistatus response. However
1314 this means that the server needs to decide about the HTTP status code
1315 to return *prior* to actually doing the recursion. Therefore,
1316 requiring the server to return a 506 status in case there's a bind
1317 loop somewhere below the request URI will not work. An obvious
1318 alternative would be to allow the 506 to be returned inside the
1319 DAV:status element for the resource the server refuses to recurse
1320 into. Of course that would mean that the client essentially would
1321 get a partly incorrect picture of the server state. However, I don't
1322 think there's any way to avoid that (except for rejecting all Depth:
1323 infinity PROPFINDs, like many servers already do).
1325 Resolution (2004-03-06): Allow 506 inside multistatus.
1327 B.6 9.2_redirect_loops
1329 Type: edit
1331 julian.reschke@greenbytes.de (2004-01-09): Avoid confusion with
1332 REDIRECT. Propose rename to "Bind Loops".
1334 Resolution (2004-01-09): Do the rename.
1336 Index
1338 2
1339 208 Already Reported (status code) 21
1341 5
1342 506 Loop Detected (status code) 24
1344 B
1345 BIND method 15
1347 C
1348 Condition Names
1349 DAV:bind-into-collection (pre) 16
1350 DAV:bind-source-exists (pre) 16
1351 DAV:binding-allowed (pre) 16, 20
1352 DAV:binding-deleted (post) 18, 21
1353 DAV:can-overwrite (pre) 16, 20
1354 DAV:cross-server-binding (pre) 16, 20
1355 DAV:cycle-allowed (pre) 16, 20
1356 DAV:locked-overwrite-allowed (pre) 16
1357 DAV:locked-source-collection-update-allowed (pre) 20
1358 DAV:locked-update-allowed (pre) 16, 18, 20
1359 DAV:name-allowed (pre) 16, 20
1360 DAV:new-binding (post) 17, 21
1361 DAV:protected-source-url-deletion-allowed (pre) 20
1362 DAV:protected-url-deletion-allowed (pre) 18
1363 DAV:protected-url-modification-allowed (pre) 20
1364 DAV:rebind-into-collection (pre) 20
1365 DAV:rebind-source-exists (pre) 20
1366 DAV:unbind-from-collection (pre) 18
1367 DAV:unbind-source-exists (pre) 18
1369 D
1370 DAV header
1371 compliance class 'bind' 24
1372 DAV:bind-into-collection precondition 16
1373 DAV:bind-source-exists precondition 16
1374 DAV:binding-allowed precondition 16, 20
1375 DAV:binding-deleted postcondition 18, 21
1376 DAV:can-overwrite precondition 16, 20
1377 DAV:cross-server-binding precondition 16, 20
1378 DAV:cycle-allowed precondition 16, 20
1379 DAV:locked-overwrite-allowed precondition 16
1380 DAV:locked-source-collection-update-allowed precondition 20
1381 DAV:locked-update-allowed precondition 16, 18, 20
1382 DAV:name-allowed precondition 16, 20
1383 DAV:new-binding postcondition 17, 21
1384 DAV:parent-set property 14
1385 DAV:protected-source-url-deletion-allowed precondition 20
1386 DAV:protected-url-deletion-allowed precondition 18
1387 DAV:protected-url-modification-allowed precondition 20
1388 DAV:rebind-into-collection precondition 20
1389 DAV:rebind-source-exists precondition 20
1390 DAV:resource-id property 14
1391 DAV:unbind-from-collection precondition 18
1392 DAV:unbind-source-exists precondition 18
1394 M
1395 Methods
1396 BIND 15
1397 REBIND 19
1398 UNBIND 17
1400 P
1401 Properties
1402 DAV:parent-set 14
1403 DAV:resource-id 14
1405 R
1406 REBIND method 19
1408 S
1409 Status Codes
1410 208 Already Reported 21
1411 506 Loop Detected 24
1413 U
1414 UNBIND method 17
1416 Intellectual Property Statement
1418 The IETF takes no position regarding the validity or scope of any
1419 Intellectual Property Rights or other rights that might be claimed to
1420 pertain to the implementation or use of the technology described in
1421 this document or the extent to which any license under such rights
1422 might or might not be available; nor does it represent that it has
1423 made any independent effort to identify any such rights. Information
1424 on the IETF's procedures with respect to rights in IETF Documents can
1425 be found in BCP 78 and BCP 79.
1427 Copies of IPR disclosures made to the IETF Secretariat and any
1428 assurances of licenses to be made available, or the result of an
1429 attempt made to obtain a general license or permission for the use of
1430 such proprietary rights by implementers or users of this
1431 specification can be obtained from the IETF on-line IPR repository at
1432 http://www.ietf.org/ipr.
1434 The IETF invites any interested party to bring to its attention any
1435 copyrights, patents or patent applications, or other proprietary
1436 rights that may cover technology that may be required to implement
1437 this standard. Please address the information to the IETF at
1438 ietf-ipr@ietf.org.
1440 Disclaimer of Validity
1442 This document and the information contained herein are provided on an
1443 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1444 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1445 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1446 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1447 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1448 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1450 Copyright Statement
1452 Copyright (C) The Internet Society (2004). This document is subject
1453 to the rights, licenses and restrictions contained in BCP 78, and
1454 except as set forth therein, the authors retain all their rights.
1456 Acknowledgment
1458 Funding for the RFC Editor function is currently provided by the
1459 Internet Society.