idnits 2.17.1
draft-ietf-webdav-bind-06.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 3667, Section 5.1 on line 20.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1489.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1466.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1473.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1479.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1495), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 42.
** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== Mismatching filename: the document gives the document name as
'draft-ietf-webdav-bind-latest-06', but the file name used is
'draft-ietf-webdav-bind-06'
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 5 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- 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
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (July 2, 2004) is 7236 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 1195, 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'
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 10 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: December 31, 2004 IBM Research
5 J. Reschke
6 greenbytes
7 J. Whitehead
8 U.C. Santa Cruz
9 July 2, 2004
11 Binding Extensions to Web Distributed Authoring and Versioning
12 (WebDAV)
13 draft-ietf-webdav-bind-latest-06
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 3668.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as
25 Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on December 31, 2004.
40 Copyright Notice
42 Copyright (C) The Internet Society (2004). All Rights Reserved.
44 Abstract
46 This specification defines bindings, and the BIND method for creating
47 multiple bindings to the same resource. Creating a new binding to a
48 resource causes at least one new URI to be mapped to that resource.
50 Servers are required to insure the integrity of any bindings that
51 they allow to be created.
53 Editorial Note
55 *(To be removed before publication as RFC):*
57 Please send comments to the Distributed Authoring and Versioning
58 (WebDAV) working group at w3c-dist-auth@w3.org [1], which may be
59 joined by sending a message with subject "subscribe" to
60 w3c-dist-auth-request@w3.org [2]. Discussions of the WEBDAV working
61 group are archived at .
63 lists all registered issues since draft 02.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
69 1.2 Rationale for Distinguishing Bindings from URI Mappings . 6
70 1.3 Method Preconditions and Postconditions . . . . . . . . . 7
71 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7
72 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 8
73 2.2 URI Mappings Created by a new Binding . . . . . . . . . . 9
74 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 10
75 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 11
76 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 12
77 2.6 Determining Whether Two Bindings Are to the Same
78 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 13
79 2.7 Discovering the Bindings to a Resource . . . . . . . . . . 13
80 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 14
81 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 14
82 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 14
83 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 15
84 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 17
85 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 17
86 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 19
87 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 19
88 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 21
89 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 21
90 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 21
91 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 22
92 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 24
93 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 24
94 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 24
95 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 24
96 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 24
97 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 24
98 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 25
99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
100 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 25
101 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 25
102 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 26
103 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 26
104 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 26
105 10. Internationalization Considerations . . . . . . . . . . . . 26
106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
107 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
108 13. Normative References . . . . . . . . . . . . . . . . . . . . 27
109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
110 A. Change Log (to be removed by RFC Editor before publication) . 28
111 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 28
112 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 28
113 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 28
114 A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 28
115 B. Resolved issues (to be removed by RFC Editor before
116 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 29
117 B.1 4_LOCK_BEHAVIOR . . . . . . . . . . . . . . . . . . . . . 29
118 B.2 1.3_error_negotiation . . . . . . . . . . . . . . . . . . 29
119 B.3 2.5_language . . . . . . . . . . . . . . . . . . . . . . . 30
120 B.4 7.1.1_add_resource_id . . . . . . . . . . . . . . . . . . 30
121 C. Open issues (to be removed by RFC Editor prior to
122 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30
123 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
124 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
125 Intellectual Property and Copyright Statements . . . . . . . . 33
127 1. Introduction
129 This specification extends the WebDAV Distributed Authoring Protocol
130 to enable clients to create new access paths to existing resources.
131 This capability is useful for several reasons:
133 URIs of WebDAV-compliant resources are hierarchical and correspond to
134 a hierarchy of collections in resource space. The WebDAV Distributed
135 Authoring Protocol makes it possible to organize these resources into
136 hierarchies, placing them into groupings, known as collections, which
137 are more easily browsed and manipulated than a single flat
138 collection. However, hierarchies require categorization decisions
139 that locate resources at a single location in the hierarchy, a
140 drawback when a resource has multiple valid categories. For example,
141 in a hierarchy of vehicle descriptions containing collections for
142 cars and boats, a description of a combination car/boat vehicle could
143 belong in either collection. Ideally, the description should be
144 accessible from both. Allowing clients to create new URIs that
145 access the existing resource lets them put that resource into
146 multiple collections.
148 Hierarchies also make resource sharing more difficult, since
149 resources that have utility across many collections are still forced
150 into a single collection. For example, the mathematics department at
151 one university might create a collection of information on fractals
152 that contains bindings to some local resources, but also provides
153 access to some resources at other universities. For many reasons, it
154 may be undesirable to make physical copies of the shared resources on
155 the local server: to conserve disk space, to respect copyright
156 constraints, or to make any changes in the shared resources visible
157 automatically. Being able to create new access paths to existing
158 resources in other collections or even on other servers is useful for
159 this sort of case.
161 The BIND method defined here provides a mechanism for allowing
162 clients to create alternative access paths to existing WebDAV
163 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to
164 work because there are mappings between URIs and resources. A method
165 is addressed to a URI, and the server follows the mapping from that
166 URI to a resource, applying the method to that resource. Multiple
167 URIs may be mapped to the same resource, but until now there has been
168 no way for clients to create additional URIs mapped to existing
169 resources.
171 BIND lets clients associate a new URI with an existing WebDAV
172 resource, and this URI can then be used to submit requests to the
173 resource. Since URIs of WebDAV resources are hierarchical, and
174 correspond to a hierarchy of collections in resource space, the BIND
175 method also has the effect of adding the resource to a collection.
176 As new URIs are associated with the resource, it appears in
177 additional collections.
179 A BIND request does not create a new resource, but simply makes
180 available a new URI for submitting requests to an existing resource.
181 The new URI is indistinguishable from any other URI when submitting a
182 request to a resource. Only one round trip is needed to submit a
183 request to the intended target. Servers are required to enforce the
184 integrity of the relationships between the new URIs and the resources
185 associated with them. Consequently, it may be very costly for
186 servers to support BIND requests that cross server boundaries.
188 This specification is organized as follows. Section 1.1 defines
189 terminology used in the rest of the specification, while Section 2
190 overviews bindings. Section 3 defines the new properties needed to
191 support multiple bindings to the same resource. Section 4 specifies
192 the BIND method, used to create multiple bindings to the same
193 resource. Section 5 specifies the UNBIND method, used to remove a
194 binding to a resource. Section 6 specifies the REBIND method, used
195 to move a binding to another collection.
197 1.1 Terminology
199 The terminology used here follows and extends that in the WebDAV
200 Distributed Authoring Protocol specification [RFC2518].
202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
204 document are to be interpreted as described in [RFC2119].
206 This document uses XML DTD fragments ([XML]) as a purely notational
207 convention. WebDAV request and response bodies cannot be validated
208 due to the specific extensibility rules defined in section 23 of
209 [RFC2518] and due to the fact that all XML elements defined by this
210 specification use the XML namespace name "DAV:". In particular:
212 o Element names use the "DAV:" namespace.
214 o Element ordering is irrelevant.
216 o Extension elements/attributes (elements/attributes not already
217 defined as valid child elements) may be added anywhere, except
218 when explicitly stated otherwise.
220 URI Mapping
222 A relation between an absolute URI and a resource. For an
223 absolute URI U and the resource it identifies R, the URI mapping
224 can be thought of as (U => R). Since a resource can represent
225 items that are not network retrievable, as well as those that are,
226 it is possible for a resource to have zero, one, or many URI
227 mappings. Mapping a resource to an "http" scheme URI makes it
228 possible to submit HTTP protocol requests to the resource using
229 the URI.
231 Path Segment
233 Informally, the characters found between slashes ("/") in a URI.
234 Formally, as defined in section 3.3 of [RFC2396].
236 Binding
238 A relation between a single path segment (in a collection) and a
239 resource. A binding is part of the state of a collection. If two
240 different collections contain a binding between the same path
241 segment and the same resource, these are two distinct bindings.
242 So for a collection C, a path segment S, and a resource R, the
243 binding can be thought of as C:(S -> R). Bindings create URI
244 mappings, and hence allow requests to be sent to a single resource
245 from multiple locations in a URI namespace. For example, given a
246 collection C (accessible through the URI
247 http://www.example.com/CollX), a path segment S (equal to
248 "foo.html"), and a resource R, then creating the binding C: (S ->
249 R) makes it possible to use the URI
250 http://www.example.com/CollX/foo.html to access R.
252 Collection
254 A resource that contains, as part of its state, a set of bindings
255 that identify internal member resources.
257 Internal Member URI
259 The URI that identifies an internal member of a collection, and
260 that consists of the URI for the collection, followed by a slash
261 character ('/'), followed by the path segment of the binding for
262 that internal member.
264 1.2 Rationale for Distinguishing Bindings from URI Mappings
266 In [RFC2518], the state of a collection is defined as containing a
267 list of internal member URIs. If there are multiple mappings to a
268 collection, then the state of the collection is different when you
269 refer to it via a different URI. This is undesirable, since ideally
270 a collection's membership should remain the same, independent of
271 which URI was used to reference it.
273 The notion of binding is introduced to separate the final segment of
274 a URI from its parent collection's contribution. This done, a
275 collection can be defined as containing a set of bindings, thus
276 permitting new mappings to a collection without modifying its
277 membership. The authors of this specification anticipate and
278 recommend that future revisions of [RFC2518] will update the
279 definition of the state of a collection to correspond to the
280 definition in this document.
282 1.3 Method Preconditions and Postconditions
284 A "precondition" of a method describes the state on the server that
285 must be true for that method to be performed. A "postcondition" of a
286 method describes the state on the server that must be true after that
287 method has completed. If a method precondition or postcondition for
288 a request is not satisfied, the response status of the request MUST
289 be either 403 (Forbidden) if the request should not be repeated
290 because it will always fail, or 409 (Conflict) if it is expected that
291 the user might be able to resolve the conflict and resubmit the
292 request.
294 In order to allow better client handling of 403 and 409 responses, a
295 distinct XML element type is associated with each method precondition
296 and postcondition of a request. When a particular precondition is
297 not satisfied or a particular postcondition cannot be achieved, the
298 appropriate XML element MUST be returned as the child of a top-level
299 DAV:error element in the response body, unless otherwise negotiated
300 by the request. In a 207 Multi-Status response, the DAV:error
301 element would appear in the appropriate DAV:responsedescription
302 element.
304 2. Overview of Bindings
306 Bindings are part of the state of a collection. They define the
307 internal members of the collection, and the names of those internal
308 members.
310 Bindings are added and removed by a variety of existing HTTP methods.
311 A method that creates a new resource, such as PUT, COPY, and MKCOL,
312 adds a binding. A method that deletes a resource, such as DELETE,
313 removes a binding. A method that moves a resource (e.g. MOVE) both
314 adds a binding (in the destination collection) and removes a binding
315 (in the source collection). The BIND method introduced here provides
316 a mechanism for adding a second binding to an existing resource.
317 There is no difference between an initial binding added by PUT, COPY,
318 or MKCOL, and additional bindings added with BIND.
320 It would be very undesirable if one binding could be destroyed as a
321 side effect of operating on the resource through a different binding.
322 In particular, the removal of one binding to a resource (e.g. with a
323 DELETE or a MOVE) MUST NOT disrupt another binding to that resource,
324 e.g. by turning that binding into a dangling path segment. The
325 server MUST NOT reclaim system resources after removing one binding,
326 while other bindings to the resource remain. In other words, the
327 server MUST maintain the integrity of a binding.
329 2.1 Bindings to Collections
331 Bindings to collections can result in loops, which servers MUST
332 detect when processing "Depth: infinity" requests. It is sometimes
333 possible to complete an operation in spite of the presence of a loop.
334 However, the 506 (Loop Detected) status code is defined in Section 7
335 for use in contexts where an operation is terminated because a loop
336 was encountered.
338 Creating a new binding to a collection makes each resource associated
339 with a binding in that collection accessible via a new URI, and thus
340 creates new URI mappings to those resources but no new bindings.
342 For example, suppose a new binding CollY is created for collection C1
343 in the figure below. It immediately becomes possible to access
344 resource R1 using the URI /CollY/x.gif and to access resource R2
345 using the URI /CollY/y.jpg, but no new bindings for these child
346 resources were created. This is because bindings are part of the
347 state of a collection, and associate a URI that is relative to that
348 collection with its target resource. No change to the bindings in
349 Collection C1 is needed to make its children accessible using /CollY/
350 x.gif and /CollY/y.jpg.
352 +-------------------------+
353 | Root Collection |
354 | bindings: |
355 | CollX CollY |
356 +-------------------------+
357 | /
358 | /
359 | /
360 +------------------+
361 | Collection C1 |
362 | bindings: |
363 | x.gif y.jpg |
364 +------------------+
365 | \
366 | \
367 | \
368 +-------------+ +-------------+
369 | Resource R1 | | Resource R2 |
370 +-------------+ +-------------+
372 2.2 URI Mappings Created by a new Binding
374 Suppose a binding from "Binding-Name" to resource R is to be added to
375 a collection, C. Then if C-MAP is the set of URIs that were mapped
376 to C before the BIND request, then for each URI "C-URI" in C-MAP, the
377 URI "C-URI/Binding-Name" is mapped to resource R following the BIND
378 request.
380 For example, if a binding from "foo.html" to R is added to a
381 collection C, and if the following URIs are mapped to C:
383 http://www.example.com/A/1/
384 http://example.com/A/one/
386 then the following new mappings to R are introduced:
388 http://www.example.com/A/1/foo.html
389 http://example.com/A/one/foo.html
391 Note that if R is a collection, additional URI mappings are created
392 to the descendents of R. Also, note that if a binding is made in
393 collection C to C itself (or to a parent of C), an infinite number of
394 mappings are introduced.
396 For example, if a binding from "myself" to C is then added to C, the
397 following infinite number of additional mappings to C are introduced:
399 http://www.example.com/A/1/myself
400 http://www.example.com/A/1/myself/myself
401 ...
403 and the following infinite number of additional mappings to R are
404 introduced:
406 http://www.example.com/A/1/myself/foo.html
407 http://www.example.com/A/1/myself/myself/foo.html
408 ...
410 2.3 COPY and Bindings
412 As defined in Section 8.8 of [RFC2518], COPY causes the resource
413 identified by the Request-URI to be duplicated, and makes the new
414 resource accessible using the URI specified in the Destination
415 header. Upon successful completion of a COPY, a new binding is
416 created between the last path segment of the Destination header, and
417 the destination resource. The new binding is added to its parent
418 collection, identified by the Destination header minus its final
419 segment.
421 The following figure shows an example: Suppose that a COPY is issued
422 to URI-3 for resource R (which is also mapped to URI-1 and URI-2),
423 with the Destination header set to URI-X. After successful
424 completion of the COPY operation, resource R is duplicated to create
425 resource R', and a new binding has been created which creates at
426 least the URI mapping between URI-X and the new resource (although
427 other URI mappings may also have been created).
429 URI-1 URI-2 URI-3 URI-X
430 | | | |
431 | | | <---- URI Mappings ----> |
432 | | | |
433 +---------------------+ +------------------------+
434 | Resource R | | Resource R' |
435 +---------------------+ +------------------------+
437 It might be thought that a COPY request with "Depth: 0" on a
438 collection would duplicate its bindings, since bindings are part of
439 the collection's state. This is not the case, however. The
440 definition of Depth in [RFC2518] makes it clear that a "Depth: 0"
441 request does not apply to a collection's members. Consequently, a
442 COPY with "Depth: 0" does not duplicate the bindings contained by the
443 collection.
445 If a COPY request causes an existing resource to be updated, the
446 bindings to that resource MUST be unaffected by the COPY request.
447 Using the preceding example, suppose that a COPY request is issued to
448 URI-X for resource R', with the Destination header set to URI-2. The
449 content and dead properties of resource R would be updated to be a
450 copy of those of resource R', but the mappings from URI-1, URI-2, and
451 URI-3 to resource R remain unaffected. If because of multiple
452 bindings to a resource, more than one source resource updates a
453 single destination resource, the order of the updates is server
454 defined.
456 If a COPY request would cause a new resource to be created as a copy
457 of an existing resource, and that COPY request has already created a
458 copy of that existing resource, the COPY request instead creates
459 another binding to the previous copy, instead of creating a new
460 resource.
462 2.4 DELETE and Bindings
464 When there are multiple bindings to a resource, a DELETE applied to
465 that resource MUST NOT remove any bindings to that resource other
466 than the one identified by the request URI. For example, suppose the
467 collection identified by the URI "/a" has a binding named "x" to a
468 resource R, and another collection identified by "/b" has a binding
469 named "y" to the same resource R. Then a DELETE applied to "/a/x"
470 removes the binding named "x" from "/a" but MUST NOT remove the
471 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues
472 to identify the resource R). In particular, although Section 8.6.1
473 of [RFC2518] states that during DELETE processing, a server "MUST
474 remove any URI for the resource identified by the Request-URI from
475 collections which contain it as a member", a server that supports the
476 binding protocol MUST NOT follow this requirement.
478 When DELETE is applied to a collection, it MUST NOT modify the
479 membership of any other collection that is not itself a member of the
480 collection being deleted. For example, if both "/a/.../x" and "/b/
481 .../y" identify the same collection, C, then applying DELETE to "/a"
482 MUST NOT delete an internal member from C or from any other
483 collection that is a member of C, because that would modify the
484 membership of "/b".
486 If a collection supports the UNBIND method (see Section 5), a DELETE
487 of an internal member of a collection MAY be implemented as an UNBIND
488 request. In this case, applying DELETE to a Request-URI has the
489 effect of removing the binding identified by the final segment of the
490 Request-URI from the collection identified by the Request-URI minus
491 its final segment. Although [RFC2518] allows a DELETE to be a
492 non-atomic operation, when the DELETE operation is implemented as an
493 UNBIND, the operation is atomic. In particular, a DELETE on a
494 hierarchy of resources is simply the removal of a binding to the
495 collection identified by the Request-URI.
497 2.5 MOVE and Bindings
499 When MOVE is applied to a resource, the other bindings to that
500 resource MUST be unaffected, and if the resource being moved is a
501 collection, the bindings to any members of that collection MUST be
502 unaffected. Also, if MOVE is used with Overwrite:T to delete an
503 existing resource, the constraints specified for DELETE apply.
505 If the destination collection of a MOVE request supports the REBIND
506 method (see Section 6), a MOVE of a resource into that collection MAY
507 be implemented as a REBIND request. Although [RFC2518] allows a MOVE
508 to be a non-atomic operation, when the MOVE operation is implemented
509 as a REBIND, the operation is atomic. In particular, applying a MOVE
510 to a Request-URI and a Destination URI has the effect of removing a
511 binding to a resource (at the Request-URI), and creating a new
512 binding to that resource (at the Destination URI). Even when the
513 Request-URI identifies a collection, the MOVE operation involves only
514 removing one binding to that collection and adding another.
516 As an example, suppose that a MOVE is issued to URI-3 for resource R
517 below (which is also mapped to URI-1 and URI-2), with the Destination
518 header set to URI-X. After successful completion of the MOVE
519 operation, a new binding has been created which creates the URI
520 mapping between URI-X and resource R. The binding corresponding to
521 the final segment of URI-3 has been removed, which also causes the
522 URI mapping between URI-3 and R to be removed. If resource R were a
523 collection, old URI-3 based mappings to members of R would have been
524 removed, and new URI-X based mappings to members of R would have been
525 created.
527 >> Before Request:
529 URI-1 URI-2 URI-3
530 | | |
531 | | | <---- URI Mappings
532 | | |
533 +---------------------+
534 | Resource R |
535 +---------------------+
536 >> After Request:
538 URI-1 URI-2 URI-X
539 | | |
540 | | | <---- URI Mappings
541 | | |
542 +---------------------+
543 | Resource R |
544 +---------------------+
546 2.6 Determining Whether Two Bindings Are to the Same Resource
548 It is useful to have some way of determining whether two bindings are
549 to the same resource. Two resources might have identical contents
550 and properties, but not be the same resource (e.g. an update to one
551 resource does not affect the other resource).
553 The REQUIRED DAV:resource-id property defined in Section 3.1 is a
554 resource identifier, which MUST be unique across all resources for
555 all time. If the values of DAV:resource-id returned by PROPFIND
556 requests through two bindings are identical, the client can be
557 assured that the two bindings are to the same resource.
559 The DAV:resource-id property is created, and its value assigned, when
560 the resource is created. The value of DAV:resource-id MUST NOT be
561 changed. Even after the resource is no longer accessible through any
562 URI, that value MUST NOT be reassigned to another resource's
563 DAV:resource-id property.
565 Any method that creates a new resource MUST assign a new, unique
566 value to its DAV:resource-id property. For example, a PUT or a COPY
567 that creates a new resource must assign a new, unique value to the
568 DAV:resource-id property of that new resource.
570 On the other hand, any method that affects an existing resource MUST
571 NOT change the value of its DAV:resource-id property. For example, a
572 PUT or a COPY that updates an existing resource must not change the
573 value of its DAV:resource-id property. A MOVE, since it does not
574 create a new resource, but only changes the location of an existing
575 resource, must not change the value of the DAV:resource-id property.
577 2.7 Discovering the Bindings to a Resource
579 An OPTIONAL DAV:parent-set property on a resource provides a list of
580 the bindings that associate a collection and a URI segment with that
581 resource. If the DAV:parent-set property exists on a given resource,
582 it MUST contain a complete list of all bindings to that resource that
583 the client is authorized to see. When deciding whether to support
584 the DAV:parent-set property, server implementers / administrators
585 should balance the benefits it provides against the cost of
586 maintaining the property and the security risks enumerated in
587 Sections 8.4 and 8.5.
589 3. Properties
591 The bind feature introduces the following properties for a resource.
593 A DAV:allprop PROPFIND request SHOULD NOT return any of the
594 properties defined by this document. This allows a binding server to
595 perform efficiently when a naive client, which does not understand
596 the cost of asking a server to compute all possible live properties,
597 issues a DAV:allprop PROPFIND request.
599 3.1 DAV:resource-id Property
601 The DAV:resource-id property is a REQUIRED property that enables
602 clients to determine whether two bindings are to the same resource.
603 The value of DAV:resource-id is a URI, and may use any registered URI
604 scheme that guarantees the uniqueness of the value across all
605 resources for all time (e.g. the opaquelocktoken: scheme defined in
606 [RFC2518]).
608
610 3.2 DAV:parent-set Property
612 The DAV:parent-set property is an OPTIONAL property that enables
613 clients to discover what collections contain a binding to this
614 resource (i.e. what collections have that resource as an internal
615 member). It contains an of href/segment pair for each collection
616 that has a binding to the resource. The href identifies the
617 collection, and the segment identifies the binding name of that
618 resource in that collection.
620 A given collection MUST appear only once in the DAV:parent-set for
621 any given binding, even if there are multiple URI mappings to that
622 collection. For example, if collection C1 is mapped to both /CollX
623 and /CollY, and C1 contains a binding named "x.gif" to a resource R1,
624 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the
625 DAV:parent-set of R1, but not both. But if C1 also had a binding
626 named "y.gif" to R1, then there would be two entries for C1 in the
627 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX,
628 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]).
630
631
632
633 PCDATA value: segment, as defined in section 3.3 of [RFC2396]
635 4. BIND Method
637 The BIND method modifies the collection identified by the
638 Request-URI, by adding a new binding from the segment specified in
639 the BIND body to the resource identified in the BIND body.
641 If a server cannot guarantee the integrity of the binding, the BIND
642 request MUST fail. Note that it is especially difficult to maintain
643 the integrity of cross-server bindings. Unless the server where the
644 resource resides knows about all bindings on all servers to that
645 resource, it may unwittingly destroy the resource or make it
646 inaccessible without notifying another server that manages a binding
647 to the resource. For example, if server A permits creation of a
648 binding to a resource on server B, server A must notify server B
649 about its binding and must have an agreement with B that B will not
650 destroy the resource while A's binding exists. Otherwise server B
651 may receive a DELETE request that it thinks removes the last binding
652 to the resource and destroy the resource while A's binding still
653 exists. The precondition DAV:cross-server-binding is defined below
654 for cases where servers fail cross-server BIND requests because they
655 cannot guarantee the integrity of cross-server bindings.
657 By default, if there already is a binding for the specified segment
658 in the collection, the new binding replaces the existing binding.
659 This default binding replacement behavior can be overridden using the
660 Overwrite header defined in Section 9.6 of [RFC2518].
662 Marshalling:
664 The request MAY include an Overwrite header.
666 The request body MUST be a DAV:bind XML element.
668
670 If the request succeeds, the server MUST return 201 (Created) when
671 a new binding was created and 200 (OK) when an existing binding
672 was replaced.
674 If a response body for a successful request is included, it MUST
675 be a DAV:bind-response XML element. Note that this document does
676 not define any elements for the BIND response body, but the
677 DAV:bind-response element is defined to ensure interoperability
678 between future extensions that do define elements for the BIND
679 response body.
681
683 Preconditions:
685 (DAV:bind-into-collection): The Request-URI MUST identify a
686 collection.
688 (DAV:bind-source-exists): The DAV:href element MUST identify a
689 resource.
691 (DAV:binding-allowed): The resource identified by the DAV:href
692 supports multiple bindings to it.
694 (DAV:cross-server-binding): If the resource identified by the
695 DAV:href element in the request body is on another server from the
696 collection identified by the request-URI, the server MUST support
697 cross-server bindings.
699 (DAV:name-allowed): The name specified by the DAV:segment is
700 available for use as a new binding name.
702 (DAV:can-overwrite): If the collection already contains a binding
703 with the specified path segment, and if an Overwrite header is
704 included, the value of the Overwrite header MUST be "T".
706 (DAV:cycle-allowed): If the DAV:href element identifies a
707 collection, and if the request-URI identifies a collection that is
708 a member of that collection, the server MUST support cycles in the
709 URI namespace.
711 (DAV:locked-update-allowed): If the collection identified by the
712 Request-URI is write-locked, then the appropriate token MUST be
713 specified in an If request header.
715 (DAV:locked-overwrite-allowed): If the collection already contains
716 a binding with the specified path segment, and if that binding is
717 protected by a write-lock, then the appropriate token MUST be
718 specified in an If request header.
720 Postconditions:
722 (DAV:new-binding): The collection MUST have a binding that maps
723 the segment specified in the DAV:segment element in the request
724 body, to the resource identified by the DAV:href element in the
725 request body.
727 4.1 Example: BIND
729 >> Request:
731 BIND /CollY HTTP/1.1
732 Host: www.example.com
733 Content-Type: text/xml; charset="utf-8"
734 Content-Length: xxx
736
737
738 bar.html
739 http://www.example.com/CollX/foo.html
740
742 >> Response:
744 HTTP/1.1 201 Created
746 The server added a new binding to the collection,
747 "http://www.example.com/CollY", associating "bar.html" with the
748 resource identified by the URI
749 "http://www.example.com/CollX/foo.html". Clients can now use the URI
750 "http://www.example.com/CollY/bar.html", to submit requests to that
751 resource.
753 5. UNBIND Method
755 The UNBIND method modifies the collection identified by the
756 Request-URI, by removing the binding identified by the segment
757 specified in the UNBIND body.
759 Once a resource is unreachable by any URI mapping, the server MAY
760 reclaim system resources associated with that resource. If UNBIND
761 removes a binding to a resource, but there remain URI mappings to
762 that resource, the server MUST NOT reclaim system resources
763 associated with the resource.
765 Marshalling:
767 The request body MUST be a DAV:unbind XML element.
769
770 If the request succeeds, the server MUST return 200 (OK) when the
771 binding was successfully deleted.
773 If a response body for a successful request is included, it MUST
774 be a DAV:unbind-response XML element. Note that this document
775 does not define any elements for the UNBIND response body, but the
776 DAV:unbind-response element is defined to ensure interoperability
777 between future extensions that do define elements for the UNBIND
778 response body.
780
782 Preconditions:
784 (DAV:unbind-from-collection): The Request-URI MUST identify a
785 collection.
787 (DAV:unbind-source-exists): The DAV:segment element MUST identify
788 a binding in the collection identified by the Request-URI.
790 (DAV:locked-update-allowed): If the collection identified by the
791 Request-URI is write-locked, then the appropriate token MUST be
792 specified in the request.
794 (DAV:protected-url-deletion-allowed): If the binding identified by
795 the segment is protected by a write-lock, then the appropriate
796 token MUST be specified in the request.
798 Postconditions:
800 (DAV:binding-deleted): The collection MUST NOT have a binding for
801 the segment specified in the DAV:segment element in the request
802 body.
804 (DAV:lock-deleted): If the internal member URI of the binding
805 specified by the Request-URI and the DAV:segment element in the
806 request body was protected by a write-lock at the time of the
807 request, that write-lock must have been deleted by the request.
809 5.1 Example: UNBIND
811 >> Request:
813 UNBIND /CollX HTTP/1.1
814 Host: www.example.com
815 Content-Type: text/xml; charset="utf-8"
816 Content-Length: xxx
818
819
820 foo.html
821
823 >> Response:
825 HTTP/1.1 200 OK
827 The server removed the binding named "foo.html" from the collection,
828 "http://www.example.com/CollX". A request to the resource named
829 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found)
830 response.
832 6. REBIND Method
834 The REBIND method removes a binding to a resource from one
835 collection, and adds a binding to that resource into another
836 collection. It is effectively an atomic form of a MOVE request.
838 Marshalling:
840 The request MAY include an Overwrite header.
842 The request body MUST be a DAV:rebind XML element.
844
846 If the request succeeds, the server MUST return 201 (Created) when
847 a new binding was created and 200 (OK) when an existing binding
848 was replaced.
850 If a response body for a successful request is included, it MUST
851 be a DAV:rebind-response XML element. Note that this document
852 does not define any elements for the REBIND response body, but the
853 DAV:rebind-response element is defined to ensure interoperability
854 between future extensions that do define elements for the REBIND
855 response body.
857
859 Preconditions:
861 (DAV:rebind-into-collection): The Request-URI MUST identify a
862 collection.
864 (DAV:rebind-source-exists): The DAV:href element MUST identify a
865 resource.
867 (DAV:cross-server-binding): If the resource identified by the
868 DAV:href element in the request body is on another server from the
869 collection identified by the request-URI, the server MUST support
870 cross-server bindings.
872 (DAV:name-allowed): The name specified by the DAV:segment is
873 available for use as a new binding name.
875 (DAV:can-overwrite): If the collection already contains a binding
876 with the specified path segment, and if an Overwrite header is
877 included, the value of the Overwrite header MUST be "T".
879 (DAV:cycle-allowed): If the DAV:href element identifies a
880 collection, and if the request-URI identifies a collection that is
881 a member of that collection, the server MUST support cycles in the
882 URI namespace.
884 (DAV:locked-update-allowed): If the collection identified by the
885 Request-URI is write-locked, then the appropriate token MUST be
886 specified in the request.
888 (DAV:protected-url-modification-allowed): If the collection
889 identified by the Request-URI already contains a binding with the
890 specified path segment, and if that binding is protected by a
891 write-lock, then the appropriate token MUST be specified in the
892 request.
894 (DAV:locked-source-collection-update-allowed): If the collection
895 identified by the parent collection prefix of the DAV:href URI is
896 write-locked, then the appropriate token MUST be specified in the
897 request.
899 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI
900 is protected by a write lock, then the appropriate token MUST be
901 specified in the request.
903 Postconditions:
905 (DAV:new-binding): The collection MUST have a binding that maps
906 the segment specified in the DAV:segment element in the request
907 body, to the resource that was identified by the DAV:href element
908 in the request body.
910 (DAV:binding-deleted): The URL specified in the DAV:href element
911 in the request body MUST NOT be mapped to a resource.
913 (DAV:lock-deleted): If the URL specified in the DAV:href element
914 in the request body was protected by a write-lock at the time of
915 the request, that write-lock must have been deleted by the
916 request.
918 6.1 Example: REBIND
920 >> Request:
922 REBIND /CollX HTTP/1.1
923 Host: www.example.com
924 Content-Type: text/xml; charset="utf-8"
925 Content-Length: xxx
927
928
929 foo.html
930 http://www.example.com/CollY/bar.html
931
933 >> Response:
935 HTTP/1.1 200 OK
937 The server added a new binding to the collection,
938 "http://www.example.com/CollX", associating "foo.html" with the
939 resource identified by the URI
940 "http://www.example.com/CollY/bar.html", and removes the binding
941 named "bar.html" from the collection identified by the URI
942 "http://www.example.com/CollY". Clients can now use the URI "http://
943 www.example.com/CollX/foo.html" to submit requests to that resource,
944 and requests on the URI "http://www.example.com/CollY/bar.html" will
945 fail with a 404 (Not Found) response.
947 7. Additional Status Codes
949 7.1 208 Already Reported
951 The 208 (Already Reported) status code can be used inside a
952 DAV:propstat response element to avoid enumerating the internal
953 members of multiple bindings to the same collection repeatedly. For
954 each binding to a collection inside the request's scope, only one
955 will be reported with a 200 status, while subsequent DAV:response
956 elements for all other bindings will use the 208 status, and no
957 DAV:response elements for their descendants are included.
959 Note that the 208 status will only occur for "Depth: infinity"
960 requests, and that it is of particular importance when the multiple
961 collection bindings cause a bind loop as discussed in Section 2.2.
963 A client can request the DAV:resourceid property in a PROPFIND
964 request to guarantee that they can accurately reconstruct the binding
965 structure of a collection with multiple bindings to a single
966 resource.
968 For backward compatibility with clients not aware of the 208 status
969 code appearing in multistatus response bodies, it SHOULD NOT be used
970 unless the client has signalled support for this specification using
971 the "DAV" request header (see Section 8.2). Instead, a 506 status
972 should be returned when a binding loop is discovered. This allows
973 the server to return the 506 as the top level return status, if it
974 discovers it before it started the response, or in the middle of a
975 multistatus, if it discovers it in the middle of streaming out a
976 multistatus response.
978 7.1.1 Example: PROPFIND by bind-aware client
980 For example, consider a PROPFIND request on /Coll (bound to
981 collection C), where the members of /Coll are /Coll/Foo (bound to
982 resource R) and /Coll/Bar (bound to collection C).
984 >> Request:
986 PROPFIND /Coll/ HTTP/1.1
987 Host: www.example.com
988 Depth: infinity
989 DAV: bind
990 Content-Type: text/xml; charset="utf-8"
991 Content-Length: xxx
993
994
995
996
997
998
999
1000 >> Response:
1002 HTTP/1.1 207 Multi-Status
1003 Content-Type: text/xml; charset="utf-8"
1004 Content-Length: xxx
1006
1007
1008
1009 http://www.example.com/Coll/
1010
1011
1012 Loop Demo
1013
1014 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8
1016
1017
1018 HTTP/1.1 200 OK
1019
1020
1021
1022 http://www.example.com/Coll/Foo
1023
1024
1025 Bird Inventory
1026
1027 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf9
1029
1030
1031 HTTP/1.1 200 OK
1032
1033
1034
1035 http://www.example.com/Coll/Bar
1036
1037
1038 Loop Demo
1039
1040 opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8
1042
1043
1044 HTTP/1.1 208 Already Reported
1045
1046
1047
1049 7.1.2 Example: PROPFIND by non-bind-aware client
1051 In this example, the client isn't aware of the 208 status code
1052 introduced by this specification. As the "Depth: infinity" PROPFIND
1053 request would cause a loop condition, the whole request is rejected
1054 with a 506 status.
1056 >> Request:
1058 PROPFIND /Coll/ HTTP/1.1
1059 Host: www.example.com
1060 Depth: infinity
1061 Content-Type: text/xml; charset="utf-8"
1062 Content-Length: xxx
1064
1065
1066
1067
1069 >> Response:
1071 HTTP/1.1 506 Loop Detected
1073 7.2 506 Loop Detected
1075 The 506 (Loop Detected) status code indicates that the server
1076 terminated an operation because it encountered an infinite loop while
1077 processing a request with "Depth: infinity". This status indicates
1078 that the entire operation failed.
1080 8. Capability discovery
1082 8.1 OPTIONS method
1084 If the server supports bindings, it MUST return the compliance class
1085 name "bind" as a field in the "DAV" response header (see [RFC2518],
1086 section 9.1) from an OPTIONS request on any resource implemented by
1087 that server. A value of "bind" in the "DAV" header MUST indicate
1088 that the server supports all MUST level requirements and REQUIRED
1089 features specified in this document.
1091 8.2 'DAV' request header
1093 8.2.1 Generic syntax
1095 This specification introduces the 'DAV' request header that allows
1096 clients to signal compliance to specific WebDAV features. It has the
1097 same syntax as the response header defined in [RFC2518], section 9.1,
1098 but MAY be used with any method.
1100 Note that clients MUST NOT submit a specific compliance class name in
1101 the request header unless the specification defining this compliance
1102 class specifically defines its semantics for clients.
1104 Note that if a server chooses to vary the result of a request based
1105 on values in the "DAV" header, the response either MUST NOT be
1106 cacheable or the server MUST mark the response accordingly using the
1107 "Vary" header (see [RFC2616], section 14.44).
1109 8.2.2 Client compliance class 'bind'
1111 Clients SHOULD signal support for all MUST level requirements and
1112 REQUIRED features by submitting a "DAV" request header containing the
1113 compliance class name "bind". In particular, the client MUST
1114 understand the 208 status code defined in Section 7.1.
1116 9. Security Considerations
1118 This section is provided to make WebDAV implementors aware of the
1119 security implications of this protocol.
1121 All of the security considerations of HTTP/1.1 and the WebDAV
1122 Distributed Authoring Protocol specification also apply to this
1123 protocol specification. In addition, bindings introduce several new
1124 security concerns and increase the risk of some existing threats.
1125 These issues are detailed below.
1127 9.1 Privacy Concerns
1129 In a context where cross-server bindings are supported, creating
1130 bindings on a trusted server may make it possible for a hostile agent
1131 to induce users to send private information to a target on a
1132 different server.
1134 9.2 Bind Loops
1136 Although bind loops were already possible in HTTP 1.1, the
1137 introduction of the BIND method creates a new avenue for clients to
1138 create loops accidentally or maliciously. If the binding and its
1139 target are on the same server, the server may be able to detect BIND
1140 requests that would create loops. Servers are required to detect
1141 loops that are caused by bindings to collections during the
1142 processing of any requests with "Depth: infinity".
1144 9.3 Bindings, and Denial of Service
1146 Denial of service attacks were already possible by posting URIs that
1147 were intended for limited use at heavily used Web sites. The
1148 introduction of BIND creates a new avenue for similar denial of
1149 service attacks. If cross-server bindings are supported, clients can
1150 now create bindings at heavily used sites to target locations that
1151 were not designed for heavy usage.
1153 9.4 Private Locations May Be Revealed
1155 If the DAV:parent-set property is maintained on a resource, the
1156 owners of the bindings risk revealing private locations. The
1157 directory structures where bindings are located are available to
1158 anyone who has access to the DAV:parent-set property on the resource.
1159 Moving a binding may reveal its new location to anyone with access to
1160 DAV:parent-set on its resource.
1162 9.5 DAV:parent-set and Denial of Service
1164 If the server maintains the DAV:parent-set property in response to
1165 bindings created in other administrative domains, it is exposed to
1166 hostile attempts to make it devote resources to adding bindings to
1167 the list.
1169 10. Internationalization Considerations
1171 All internationalization considerations mentioned in [RFC2518] also
1172 apply to this document.
1174 11. IANA Considerations
1176 All IANA considerations mentioned in [RFC2518] also apply to this
1177 document.
1179 12. Acknowledgements
1181 This document is the collaborative product of the authors and Tyson
1182 Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has
1183 benefited from thoughtful discussion by Jim Amsden, Peter Carlson,
1184 Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun,
1185 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan
1186 Eissing, Roy Fielding, Yaron Goland, Joe Hildebrand, Fred Hitt, Alex
1187 Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula,
1188 Rohit Khare, Brian Korver, Daniel LaLiberte Steve Martin, Larry
1189 Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby,
1190 Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John
1191 Turner, Kevin Wiggen, and other members of the WebDAV working group.
1193 13 Normative References
1195 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1196 3", BCP 9, RFC 2026, October 1996.
1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1199 Requirement Levels", BCP 14, RFC 2119, March 1997.
1201 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1202 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1203 August 1998.
1205 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1206 Jensen, "HTTP Extensions for Distributed Authoring --
1207 WEBDAV", RFC 2518, February 1999.
1209 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1210 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1211 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1213 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
1214 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
1215 Edition)", W3C REC-xml-20040204, February 2004,
1216 .
1218 [1]
1220 [2]
1222 Authors' Addresses
1224 Geoffrey Clemm
1225 IBM
1226 20 Maguire Road
1227 Lexington, MA 02421
1229 EMail: geoffrey.clemm@us.ibm.com
1231 Jason Crawford
1232 IBM Research
1233 P.O. Box 704
1234 Yorktown Heights, NY 10598
1236 EMail: ccjason@us.ibm.com
1237 Julian F. Reschke
1238 greenbytes GmbH
1239 Salzmannstrasse 152
1240 Muenster, NW 48159
1241 Germany
1243 EMail: julian.reschke@greenbytes.de
1245 Jim Whitehead
1246 UC Santa Cruz, Dept. of Computer Science
1247 1156 High Street
1248 Santa Cruz, CA 95064
1250 EMail: ejw@cse.ucsc.edu
1252 Appendix A. Change Log (to be removed by RFC Editor before publication)
1254 A.1 Since draft-ietf-webdav-bind-02
1256 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and
1257 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed
1258 resolution, but keep it open. Add issues "ED_references" and
1259 "4_507_status". Started work on index. Rename document to "Binding
1260 Extensions to Web Distributed Authoring and Versioning (WebDAV)".
1261 Rename "References" to "Normative References". Close issue
1262 "ED_references". Close issue "4_507_status".
1264 A.2 Since draft-ietf-webdav-bind-03
1266 Add and close issues "9.2_redirect_loops", "ED_authors" and
1267 "ED_updates". Add section about capability discovery (DAV header).
1268 Close issues "5.1_LOOP_STATUS". Add and resolve new issue
1269 "5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue
1270 "locking" and resolve as invalid.
1272 A.3 Since draft-ietf-webdav-bind-04
1274 Add and close issues "6_precondition_binding_allowed" and
1275 "6_lock_behaviour". Add mailing list and issues list pointers to
1276 front.
1278 A.4 Since draft-ietf-webdav-bind-05
1280 Editorial fixes. Add and resolve issues "1.3_error_negotiation",
1281 "2.5_language" and "7.1.1_add_resource_id". Add historical issue
1282 "4_LOCK_BEHAVIOR" and it's resolution for better tracking.
1284 Appendix B. Resolved issues (to be removed by RFC Editor before
1285 publication)
1287 Issues that were either rejected or resolved in this version of this
1288 document.
1290 B.1 4_LOCK_BEHAVIOR
1292 Type: change
1294
1296 briank@xythos.com (2003-02-28): Define "Resource": The term
1297 "resource" should be defined in the draft. I imagine the definition
1298 is something along the lines of "all content and all properties
1299 associated with that content (including live and dead properties),
1300 but which does not include properties associated with URIs." Bindings
1301 and Locks: The relationship between bindings and locks is missing
1302 from the draft. I think the behavior of locks and the lock methods
1303 should be fully specified in this draft. URL Properties: The
1304 behavior of other URL properties (in addition to locks) should be
1305 fully specified, for instance the display-name property. Move and
1306 Delete: The spec states that move and delete are merely operations on
1307 bindings. At the very least, this is inconsistent with 2518, but I
1308 also think that the draft doesn't adequately address any of the
1309 issues that come up when the server goes to "reclaim system
1310 resources." I would expect most servers to reclaim said resources
1311 during move and delete. Operations not Atomic: None of the
1312 operations specified should be required to be atomic. I'd prefer
1313 SHOULD NOT myself. This is especially true for any operation that
1314 involves deleting collections.
1316 Resolution: This was closed in draft 02. Some comments: (1) It's up
1317 to RFC2396 and RFC2616 to define what a "resource" is. We don't
1318 change that here. (2) There is no such thing as URL properties.
1319 WebDAV properties are part of the state of a WebDAV/HTTP resource;
1320 and a URI by itself is not a resource. (3) Bindings vs Locks: see
1321 other issues. (4) MOVE and DELETE are allowed to work the same way
1322 as in RFC2518 (except for Delete not removing all bindings). (5) The
1323 new methods are all atomic on purpose. If a server can't implement
1324 UNBIND on collections; that is fine. It can still implement DELETE
1325 with the classic non-atomic behaviour.
1327 B.2 1.3_error_negotiation
1329 Type: change
1330
1332 joe@cursive.net (2004-06-22): Second paragraph: how might I otherwise
1333 negotiate? The DAV:bind header?
1335 Resolution: No change. Summary: this is to allow future extensions
1336 where different error marsahlling mechanisms would be used. See also
1337 http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0210.html.
1339 B.3 2.5_language
1341 Type: change
1343
1345 joe@cursive.net (2004-06-22): Last paragraph is a repeat of text two
1346 paragraphs before.
1348 Resolution (2004-06-24): Just move the second sentence of the last
1349 paragraph to the end of the second paragraph, and then delete the
1350 rest of the last paragraph.
1352 B.4 7.1.1_add_resource_id
1354 Type: change
1356
1358 joe@cursive.net (2004-06-22): I think this would be clearer if it
1359 included D:resource-id in the request and response, so you could tell
1360 where the loop happened. Are resource-id's likely to be costly to
1361 return?
1363 Resolution (2004-06-23): No, they should be cheap. Update example.
1365 Appendix C. Open issues (to be removed by RFC Editor prior to
1366 publication)
1368 C.1 edit
1370 Type: edit
1372 julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for
1373 editorial fixes/enhancements.
1375 Index
1377 2
1378 208 Already Reported (status code) 21
1380 5
1381 506 Loop Detected (status code) 24
1383 B
1384 BIND method 15
1386 C
1387 Condition Names
1388 DAV:bind-into-collection (pre) 16
1389 DAV:bind-source-exists (pre) 16
1390 DAV:binding-allowed (pre) 16
1391 DAV:binding-deleted (post) 18, 21
1392 DAV:can-overwrite (pre) 16, 20
1393 DAV:cross-server-binding (pre) 16, 20
1394 DAV:cycle-allowed (pre) 16, 20
1395 DAV:lock-deleted (post) 18, 21
1396 DAV:locked-overwrite-allowed (pre) 16
1397 DAV:locked-source-collection-update-allowed (pre) 20
1398 DAV:locked-update-allowed (pre) 16, 18, 20
1399 DAV:name-allowed (pre) 16, 20
1400 DAV:new-binding (post) 16, 21
1401 DAV:protected-source-url-deletion-allowed (pre) 20
1402 DAV:protected-url-deletion-allowed (pre) 18
1403 DAV:protected-url-modification-allowed (pre) 20
1404 DAV:rebind-into-collection (pre) 20
1405 DAV:rebind-source-exists (pre) 20
1406 DAV:unbind-from-collection (pre) 18
1407 DAV:unbind-source-exists (pre) 18
1409 D
1410 DAV header
1411 compliance class 'bind' 24
1412 DAV:bind-into-collection precondition 16
1413 DAV:bind-source-exists precondition 16
1414 DAV:binding-allowed precondition 16
1415 DAV:binding-deleted postcondition 18, 21
1416 DAV:can-overwrite precondition 16, 20
1417 DAV:cross-server-binding precondition 16, 20
1418 DAV:cycle-allowed precondition 16, 20
1419 DAV:lock-deleted postcondition 18, 21
1420 DAV:locked-overwrite-allowed precondition 16
1421 DAV:locked-source-collection-update-allowed precondition 20
1422 DAV:locked-update-allowed precondition 16, 18, 20
1423 DAV:name-allowed precondition 16, 20
1424 DAV:new-binding postcondition 16, 21
1425 DAV:parent-set property 14
1426 DAV:protected-source-url-deletion-allowed precondition 20
1427 DAV:protected-url-deletion-allowed precondition 18
1428 DAV:protected-url-modification-allowed precondition 20
1429 DAV:rebind-into-collection precondition 20
1430 DAV:rebind-source-exists precondition 20
1431 DAV:resource-id property 14
1432 DAV:unbind-from-collection precondition 18
1433 DAV:unbind-source-exists precondition 18
1435 M
1436 Methods
1437 BIND 15
1438 REBIND 19
1439 UNBIND 17
1441 P
1442 Properties
1443 DAV:parent-set 14
1444 DAV:resource-id 14
1446 R
1447 REBIND method 19
1449 S
1450 Status Codes
1451 208 Already Reported 21
1452 506 Loop Detected 24
1454 U
1455 UNBIND method 17
1457 Intellectual Property Statement
1459 The IETF takes no position regarding the validity or scope of any
1460 Intellectual Property Rights or other rights that might be claimed to
1461 pertain to the implementation or use of the technology described in
1462 this document or the extent to which any license under such rights
1463 might or might not be available; nor does it represent that it has
1464 made any independent effort to identify any such rights. Information
1465 on the procedures with respect to rights in RFC documents can be
1466 found in BCP 78 and BCP 79.
1468 Copies of IPR disclosures made to the IETF Secretariat and any
1469 assurances of licenses to be made available, or the result of an
1470 attempt made to obtain a general license or permission for the use of
1471 such proprietary rights by implementers or users of this
1472 specification can be obtained from the IETF on-line IPR repository at
1473 http://www.ietf.org/ipr.
1475 The IETF invites any interested party to bring to its attention any
1476 copyrights, patents or patent applications, or other proprietary
1477 rights that may cover technology that may be required to implement
1478 this standard. Please address the information to the IETF at
1479 ietf-ipr@ietf.org.
1481 Disclaimer of Validity
1483 This document and the information contained herein are provided on an
1484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1486 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1487 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1488 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1491 Copyright Statement
1493 Copyright (C) The Internet Society (2004). This document is subject
1494 to the rights, licenses and restrictions contained in BCP 78, and
1495 except as set forth therein, the authors retain all their rights.
1497 Acknowledgment
1499 Funding for the RFC Editor function is currently provided by the
1500 Internet Society.