idnits 2.17.1
draft-ietf-webdav-bind-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 11, 2003) is 7442 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 1072, 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group G. Clemm
3 Internet-Draft IBM
4 Expires: June 10, 2004 J. Crawford
5 IBM Research
6 J. Reschke
7 greenbytes
8 J. Slein
9 Xerox
10 J. Whitehead
11 U.C. Santa Cruz
12 December 11, 2003
14 Binding Extensions to Web Distributed Authoring and Versioning
15 (WebDAV)
16 draft-ietf-webdav-bind-03
18 Status of this Memo
20 This document is an Internet-Draft and is in full conformance with
21 all provisions of Section 10 of RFC2026.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that other
25 groups may also distribute working documents as 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 http://
33 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 June 10, 2004.
40 Copyright Notice
42 Copyright (C) The Internet Society (2003). 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.
49 Servers are required to insure the integrity of any bindings that
50 they allow to be created.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
56 1.2 Rationale for Distinguishing Bindings from URI Mappings . . . 6
57 1.3 Method Preconditions and Postconditions . . . . . . . . . . . 7
58 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7
59 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . . 8
60 2.2 URI Mappings Created by a new Binding . . . . . . . . . . . . 9
61 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . . 10
62 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . . 11
63 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . . 12
64 2.6 Determining Whether Two Bindings Are to the Same Resource . . 13
65 2.7 Discovering the Bindings to a Resource . . . . . . . . . . . . 14
66 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 14
67 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . . 14
68 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . . 14
69 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 15
70 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . . 17
71 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 17
72 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . . 19
73 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 19
74 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . . 21
75 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 21
76 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . . 21
77 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . . 23
78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
79 8.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . . 24
80 8.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . . 24
81 8.3 Bindings, and Denial of Service . . . . . . . . . . . . . . . 24
82 8.4 Private Locations May Be Revealed . . . . . . . . . . . . . . 24
83 8.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . . 25
84 9. Internationalization Considerations . . . . . . . . . . . . . 25
85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
87 Normative References . . . . . . . . . . . . . . . . . . . . . 25
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
89 A. Change Log (to be removed by RFC Editor before publication) . 27
90 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . . 27
91 B. Resolved issues (to be removed by RFC Editor before
92 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 27
93 B.1 ED_references . . . . . . . . . . . . . . . . . . . . . . . . 27
94 B.2 2.3_COPY_SHARED_BINDINGS . . . . . . . . . . . . . . . . . . . 27
95 B.3 2.3_MULTIPLE_COPY . . . . . . . . . . . . . . . . . . . . . . 28
96 B.4 4_507_status . . . . . . . . . . . . . . . . . . . . . . . . . 28
97 C. Open issues (to be removed by RFC Editor before
98 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 28
99 C.1 5.1_LOOP_STATUS . . . . . . . . . . . . . . . . . . . . . . . 28
100 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
101 Intellectual Property and Copyright Statements . . . . . . . . 31
103 1. Introduction
105 This specification extends the WebDAV Distributed Authoring Protocol
106 to enable clients to create new access paths to existing resources.
107 This capability is useful for several reasons:
109 URIs of WebDAV-compliant resources are hierarchical and correspond to
110 a hierarchy of collections in resource space. The WebDAV Distributed
111 Authoring Protocol makes it possible to organize these resources into
112 hierarchies, placing them into groupings, known as collections, which
113 are more easily browsed and manipulated than a single flat
114 collection. However, hierarchies require categorization decisions
115 that locate resources at a single location in the hierarchy, a
116 drawback when a resource has multiple valid categories. For example,
117 in a hierarchy of vehicle descriptions containing collections for
118 cars and boats, a description of a combination car/boat vehicle could
119 belong in either collection. Ideally, the description should be
120 accessible from both. Allowing clients to create new URIs that access
121 the existing resource lets them put that resource into multiple
122 collections.
124 Hierarchies also make resource sharing more difficult, since
125 resources that have utility across many collections are still forced
126 into a single collection. For example, the mathematics department at
127 one university might create a collection of information on fractals
128 that contains bindings to some local resources, but also provides
129 access to some resources at other universities. For many reasons, it
130 may be undesirable to make physical copies of the shared resources on
131 the local server: to conserve disk space, to respect copyright
132 constraints, or to make any changes in the shared resources visible
133 automatically. Being able to create new access paths to existing
134 resources in other collections or even on other servers is useful for
135 this sort of case.
137 The BIND method defined here provides a mechanism for allowing
138 clients to create alternative access paths to existing WebDAV
139 resources. HTTP [RFC2616] and WebDAV [RFC2518] methods are able to
140 work because there are mappings between URIs and resources. A method
141 is addressed to a URI, and the server follows the mapping from that
142 URI to a resource, applying the method to that resource. Multiple
143 URIs may be mapped to the same resource, but until now there has been
144 no way for clients to create additional URIs mapped to existing
145 resources.
147 BIND lets clients associate a new URI with an existing WebDAV
148 resource, and this URI can then be used to submit requests to the
149 resource. Since URIs of WebDAV resources are hierarchical, and
150 correspond to a hierarchy of collections in resource space, the BIND
151 method also has the effect of adding the resource to a collection.
152 As new URIs are associated with the resource, it appears in
153 additional collections.
155 A BIND request does not create a new resource, but simply makes
156 available a new URI for submitting requests to an existing resource.
157 The new URI is indistinguishable from any other URI when submitting a
158 request to a resource. Only one round trip is needed to submit a
159 request to the intended target. Servers are required to enforce the
160 integrity of the relationships between the new URIs and the resources
161 associated with them. Consequently, it may be very costly for
162 servers to support BIND requests that cross server boundaries.
164 This specification is organized as follows. Section 1.1 defines
165 terminology used in the rest of the specification, while Section 2
166 overviews bindings. Section 3 defines the new properties needed to
167 support multiple bindings to the same resource. Section 4 specifies
168 the BIND method, used to create multiple bindings to the same
169 resource. Section 5 specifies the UNBIND method, used to remove a
170 binding to a resource. Section 6 specifies the REBIND method, used
171 to move a binding to another collection.
173 1.1 Terminology
175 The terminology used here follows and extends that in the WebDAV
176 Distributed Authoring Protocol specification [RFC2518].
178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
180 document are to be interpreted as described in [RFC2119].
182 This document uses XML DTD fragments ([XML]) as a purely notational
183 convention. WebDAV request and response bodies cannot be validated
184 due to the specific extensibility rules defined in section 23 of
185 [RFC2518] and due to the fact that all XML elements defined by this
186 specification use the XML namespace name "DAV:". In particular:
188 o Element names use the "DAV:" namespace.
190 o Element ordering is irrelevant.
192 o Extension elements/attributes (elements/attributes not already
193 defined as valid child elements) may be added anywhere, except
194 when explicitly stated otherwise.
196 URI Mapping
198 A relation between an absolute URI and a resource. For an
199 absolute URI U and the resource it identifies R, the URI mapping
200 can be thought of as (U => R). Since a resource can represent
201 items that are not network retrievable, as well as those that are,
202 it is possible for a resource to have zero, one, or many URI
203 mappings. Mapping a resource to an "http" scheme URI makes it
204 possible to submit HTTP protocol requests to the resource using
205 the URI.
207 Path Segment
209 Informally, the characters found between slashes ("/") in a URI.
210 Formally, as defined in section 3.3 of [RFC2396].
212 Binding
214 A relation between a single path segment (in a collection) and a
215 resource. A binding is part of the state of a collection. If two
216 different collections contain a binding between the same path
217 segment and the same resource, these are two distinct bindings.
218 So for a collection C, a path segment S, and a resource R, the
219 binding can be thought of as C:(S -> R). Bindings create URI
220 mappings, and hence allow requests to be sent to a single resource
221 from multiple locations in a URI namespace. For example, given a
222 collection C (accessible through the URI http://www.example.com/
223 CollX), a path segment S (equal to "foo.html"), and a resource R,
224 then creating the binding C: (S -> R) makes it possible to use the
225 URI http://www.example.com/CollX/foo.html to access R.
227 Collection
229 A resource that contains, as part of its state, a set of bindings
230 that identify internal member resources.
232 Internal Member URI
234 The URI that identifies an internal member of a collection, and
235 that consists of the URI for the collection, followed by a slash
236 character ('/'), followed by the path segment of the binding for
237 that internal member.
239 1.2 Rationale for Distinguishing Bindings from URI Mappings
241 In [RFC2518], the state of a collection is defined as containing a
242 list of internal member URIs. If there are multiple mappings to a
243 collection, then the state of the collection is different when you
244 refer to it via a different URI. This is undesirable, since ideally a
245 collection's membership should remain the same, independent of which
246 URI was used to reference it.
248 The notion of binding is introduced to separate the final segment of
249 a URI from its parent collection's contribution. This done, a
250 collection can be defined as containing a set of bindings, thus
251 permitting new mappings to a collection without modifying its
252 membership. The authors of this specification anticipate and
253 recommend that future revisions of [RFC2518] will update the
254 definition of the state of a collection to correspond to the
255 definition in this document.
257 1.3 Method Preconditions and Postconditions
259 A "precondition" of a method describes the state on the server that
260 must be true for that method to be performed. A "postcondition" of a
261 method describes the state on the server that must be true after that
262 method has completed. If a method precondition or postcondition for
263 a request is not satisfied, the response status of the request MUST
264 be either 403 (Forbidden) if the request should not be repeated
265 because it will always fail, or 409 (Conflict) if it is expected that
266 the user might be able to resolve the conflict and resubmit the
267 request.
269 In order to allow better client handling of 403 and 409 responses, a
270 distinct XML element type is associated with each method precondition
271 and postcondition of a request. When a particular precondition is
272 not satisfied or a particular postcondition cannot be achieved, the
273 appropriate XML element MUST be returned as the child of a top-level
274 DAV:error element in the response body, unless otherwise negotiated
275 by the request. In a 207 Multi-Status response, the DAV:error
276 element would appear in the appropriate DAV:responsedescription
277 element.
279 2. Overview of Bindings
281 Bindings are part of the state of a collection. They define the
282 internal members of the collection, and the names of those internal
283 members.
285 Bindings are added and removed by a variety of existing HTTP methods.
286 A method that creates a new resource, such as PUT, COPY, and MKCOL,
287 adds a binding. A method that deletes a resource, such as DELETE,
288 removes a binding. A method that moves a resource (e.g. MOVE) both
289 adds a binding (in the destination collection) and removes a binding
290 (in the source collection). The BIND method introduced here provides
291 a mechanism for adding a second binding to an existing resource.
292 There is no difference between an initial binding added by PUT, COPY,
293 or MKCOL, and additional bindings added with BIND.
295 It would be very undesirable if one binding could be destroyed as a
296 side effect of operating on the resource through a different binding.
297 In particular, the removal of one binding to a resource (e.g. with a
298 DELETE or a MOVE) MUST NOT disrupt another binding to that resource,
299 e.g. by turning that binding into a dangling path segment. The
300 server MUST NOT reclaim system resources after removing one binding,
301 while other bindings to the resource remain. In other words, the
302 server MUST maintain the integrity of a binding.
304 2.1 Bindings to Collections
306 Bindings to collections can result in loops, which servers MUST
307 detect when processing "Depth: infinity" requests. It is sometimes
308 possible to complete an operation in spite of the presence of a loop.
309 However, the 506 (Loop Detected) status code is defined in Section 7
310 for use in contexts where an operation is terminated because a loop
311 was encountered.
313 Creating a new binding to a collection makes each resource associated
314 with a binding in that collection accessible via a new URI, and thus
315 creates new URI mappings to those resources but no new bindings.
317 For example, suppose a new binding CollY is created for collection C1
318 in the figure below. It immediately becomes possible to access
319 resource R1 using the URI /CollY/x.gif and to access resource R2
320 using the URI /CollY/y.jpg, but no new bindings for these child
321 resources were created. This is because bindings are part of the
322 state of a collection, and associate a URI that is relative to that
323 collection with its target resource. No change to the bindings in
324 Collection C1 is needed to make its children accessible using /CollY/
325 x.gif and /CollY/y.jpg.
327 +-------------------------+
328 | Root Collection |
329 | bindings: |
330 | CollX CollY |
331 +-------------------------+
332 | /
333 | /
334 | /
335 +------------------+
336 | Collection C1 |
337 | bindings: |
338 | x.gif y.jpg |
339 +------------------+
340 | \
341 | \
342 | \
343 +-------------+ +-------------+
344 | Resource R1 | | Resource R2 |
345 +-------------+ +-------------+
347 2.2 URI Mappings Created by a new Binding
349 Suppose a binding from "Binding-Name" to resource R to be added to a
350 collection, C. Then if C-MAP is the set of URIs that were mapped to
351 C before the BIND request, then for each URI "C-URI" in C-MAP, the
352 URI "C-URI/Binding-Name" is mapped to resource R following the BIND
353 request.
355 For example, if a binding from "foo.html" to R is added to a
356 collection C, and if the following URIs are mapped to C:
358 http://www.example.com/A/1/
359 http://example.com/A/one/
361 then the following new mappings to R are introduced:
363 http://www.example.com/A/1/foo.html
364 http://example.com/A/one/foo.html
366 Note that if R is a collection, additional URI mappings are created
367 to the descendents of R. Also, note that if a binding is made in
368 collection C to C itself (or to a parent of C), an infinite number of
369 mappings are introduced.
371 For example, if a binding from "myself" to C is then added to C, the
372 following infinite number of additional mappings to C are introduced:
374 http://www.example.com/A/1/myself
375 http://www.example.com/A/1/myself/myself
376 ...
378 and the following infinite number of additional mappings to R are
379 introduced:
381 http://www.example.com/A/1/myself/foo.html
382 http://www.example.com/A/1/myself/myself/foo.html
383 ...
385 2.3 COPY and Bindings
387 As defined in Section 8.8 of [RFC2518], COPY causes the resource
388 identified by the Request-URI to be duplicated, and makes the new
389 resource accessible using the URI specified in the Destination
390 header. Upon successful completion of a COPY, a new binding is
391 created between the last path segment of the Destination header, and
392 the destination resource. The new binding is added to its parent
393 collection, identified by the Destination header minus its final
394 segment.
396 The following figure shows an example: Suppose that a COPY is issued
397 to URI-3 for resource R (which is also mapped to URI-1 and URI-2),
398 with the Destination header set to URI-X. After successful
399 completion of the COPY operation, resource R is duplicated to create
400 resource R', and a new binding has been created which creates at
401 least the URI mapping between URI-X and the new resource (although
402 other URI mappings may also have been created).
404 URI-1 URI-2 URI-3 URI-X
405 | | | |
406 | | | <---- URI Mappings ----> |
407 | | | |
408 +---------------------+ +------------------------+
409 | Resource R | | Resource R' |
410 +---------------------+ +------------------------+
412 It might be thought that a COPY request with "Depth: 0" on a
413 collection would duplicate its bindings, since bindings are part of
414 the collection's state. This is not the case, however. The
415 definition of Depth in [RFC2518] makes it clear that a "Depth: 0"
416 request does not apply to a collection's members. Consequently, a
417 COPY with "Depth: 0" does not duplicate the bindings contained by the
418 collection.
420 If a COPY request causes an existing resource to be updated, the
421 bindings to that resource MUST be unaffected by the COPY request.
422 Using the preceding example, suppose that a COPY request is issued to
423 URI-X for resource R', with the Destination header set to URI-2. The
424 content and dead properties of resource R would be updated to be a
425 copy of those of resource R', but the mappings from URI-1, URI-2, and
426 URI-3 to resource R remain unaffected. If because of multiple
427 bindings to a resource, more than one source resource updates a
428 single destination resource, the order of the updates is server
429 defined.
431 If a COPY request would cause a new resource to be created as a copy
432 of an existing resource, and that COPY request has already created a
433 copy of that existing resource, the COPY request instead creates
434 another binding to the previous copy, instead of creating a new
435 resource.
437 2.4 DELETE and Bindings
439 When there are multiple bindings to a resource, a DELETE applied to
440 that resource MUST NOT remove any bindings to that resource other
441 than the one identified by the request URI. For example, suppose the
442 collection identified by the URI "/a" has a binding named "x" to a
443 resource R, and another collection identified by "/b" has a binding
444 named "y" to the same resource R. Then a DELETE applied to "/a/x"
445 removes the binding named "x" from "/a" but MUST NOT remove the
446 binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues
447 to identify the resource R). In particular, although Section 8.6.1
448 of [RFC2518] states that during DELETE processing, a server "MUST
449 remove any URI for the resource identified by the Request-URI from
450 collections which contain it as a member", a server that supports the
451 binding protocol MUST NOT follow this requirement.
453 When DELETE is applied to a collection, it MUST NOT modify the
454 membership of any other collection that is not itself a member of the
455 collection being deleted. For example, if both "/a/.../x" and "/b/
456 .../y" identify the same collection, C, then applying DELETE to "/a"
457 MUST NOT delete an internal member from C or from any other
458 collection that is a member of C, because that would modify the
459 membership of "/b".
461 If a collection supports the UNBIND method (see Section 5), a DELETE
462 of an internal member of a collection MAY be implemented as an UNBIND
463 request. In this case, applying DELETE to a Request-URI has the
464 effect of removing the binding identified by the final segment of the
465 Request-URI from the collection identified by the Request-URI minus
466 its final segment. Although [RFC2518] allows a DELETE to be a
467 non-atomic operation, when the DELETE operation is implemented as an
468 UNBIND, the operation is atomic. In particular, a DELETE on a
469 hierarchy of resources is simply the removal of a binding to the
470 collection identified by the Request-URI.
472 2.5 MOVE and Bindings
474 When MOVE is applied to a resource, the other bindings to that
475 resource MUST be unaffected, and if the resource being moved is a
476 collection, the bindings to any members of that collection MUST be
477 unaffected. Also, if MOVE is used with Overwrite:T to delete an
478 existing resource, the constraints specified for DELETE apply.
480 If the destination collection of a MOVE request supports the REBIND
481 method (see Section 6), a MOVE of a resource into that collection MAY
482 be implemented as a REBIND request. Although [RFC2518] allows a MOVE
483 to be a non-atomic operation, when the MOVE operation is implemented
484 as a REBIND, the operation is atomic. In particular, applying a MOVE
485 to a Request-URI and a Destination URI has the effect of removing a
486 binding to a resource (at the Request-URI), and creating a new
487 binding to that resource (at the Destination URI).
489 As an example, suppose that a MOVE is issued to URI-3 for resource R
490 below (which is also mapped to URI-1 and URI-2), with the Destination
491 header set to URI-X. After successful completion of the MOVE
492 operation, a new binding has been created which creates the URI
493 mapping between URI-X and resource R. The binding corresponding to
494 the final segment of URI-3 has been removed, which also causes the
495 URI mapping between URI-3 and R to be removed. If resource R were a
496 collection, old URI-3 based mappings to members of R would have been
497 removed, and new URI-X based mappings to members of R would have been
498 created.
500 >> Before Request:
502 URI-1 URI-2 URI-3
503 | | |
504 | | | <---- URI Mappings
505 | | |
506 +---------------------+
507 | Resource R |
508 +---------------------+
509 >> After Request:
511 URI-1 URI-2 URI-X
512 | | |
513 | | | <---- URI Mappings
514 | | |
515 +---------------------+
516 | Resource R |
517 +---------------------+
519 Although [RFC2518] allows a MOVE on a collection to be a non-atomic
520 operation, a MOVE implemented as a REBIND MUST be atomic. Even when
521 the Request-URI identifies a collection, the MOVE operation involves
522 only removing one binding to that collection and adding another.
523 There are no operations on bindings to any of its children, so the
524 case of MOVE on a collection is the same as the case of MOVE on a
525 non-collection resource. Both are atomic.
527 2.6 Determining Whether Two Bindings Are to the Same Resource
529 It is useful to have some way of determining whether two bindings are
530 to the same resource. Two resources might have identical contents
531 and properties, but not be the same resource (e.g. an update to one
532 resource does not affect the other resource).
534 The REQUIRED DAV:resource-id property defined in Section 3.1 is a
535 resource identifier, which MUST be unique across all resources for
536 all time. If the values of DAV:resource-id returned by PROPFIND
537 requests through two bindings are identical, the client can be
538 assured that the two bindings are to the same resource.
540 The DAV:resource-id property is created, and its value assigned, when
541 the resource is created. The value of DAV:resource-id MUST NOT be
542 changed. Even after the resource is no longer accessible through any
543 URI, that value MUST NOT be reassigned to another resource's
544 DAV:resource-id property.
546 Any method that creates a new resource MUST assign a new, unique
547 value to its DAV:resource-id property. For example, a PUT or a COPY
548 that creates a new resource must assign a new, unique value to the
549 DAV:resource-id property of that new resource.
551 On the other hand, any method that affects an existing resource MUST
552 NOT change the value of its DAV:resource-id property. For example, a
553 PUT or a COPY that updates an existing resource must not change the
554 value of its DAV:resource-id property. A MOVE, since it does not
555 create a new resource, but only changes the location of an existing
556 resource, must not change the value of the DAV:resource-id property.
558 2.7 Discovering the Bindings to a Resource
560 An OPTIONAL DAV:parent-set property on a resource provides a list of
561 the bindings that associate a collection and a URI segment with that
562 resource. If the DAV:parent-set property exists on a given resource,
563 it MUST contain a complete list of all bindings to that resource that
564 the client is authorized to see. When deciding whether to support
565 the DAV:parent-set property, server implementers / administrators
566 should balance the benefits it provides against the cost of
567 maintaining the property and the security risks enumerated in
568 Sections 8.4 and 8.5.
570 3. Properties
572 The bind feature introduces the following properties for a resource.
574 A DAV:allprop PROPFIND request SHOULD NOT return any of the
575 properties defined by this document. This allows a binding server to
576 perform efficiently when a naive client, which does not understand
577 the cost of asking a server to compute all possible live properties,
578 issues a DAV:allprop PROPFIND request.
580 3.1 DAV:resource-id Property
582 The DAV:resource-id property is a REQUIRED property that enables
583 clients to determine whether two bindings are to the same resource.
584 The value of DAV:resource-id is a URI, and may use any registered URI
585 scheme that guarantees the uniqueness of the value across all
586 resources for all time (e.g. the opaquelocktoken: scheme defined in
587 [RFC2518]).
589
591 3.2 DAV:parent-set Property
593 The DAV:parent-set property is an OPTIONAL property that enables
594 clients to discover what collections contain a binding to this
595 resource (i.e. what collections have that resource as an internal
596 member). It contains an of href/segment pair for each collection
597 that has a binding to the resource. The href identifies the
598 collection, and the segment identifies the binding name of that
599 resource in that collection.
601 A given collection MUST appear only once in the DAV:parent-set for
602 any given binding, even if there are multiple URI mappings to that
603 collection. For example, if collection C1 is mapped to both /CollX
604 and /CollY, and C1 contains a binding named "x.gif" to a resource R1,
605 then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the
606 DAV:parent-set of R1, but not both. But if C1 also had a binding
607 named "y.gif" to R1, then there would be two entries for C1 in the
608 DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX,
609 y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]).
611
612
613
614 PCDATA value: segment, as defined in section 3.3 of [RFC2396]
616 4. BIND Method
618 The BIND method modifies the collection identified by the
619 Request-URI, by adding a new binding from the segment specified in
620 the BIND body to the resource identified in the BIND body.
622 If a server cannot guarantee the integrity of the binding, the BIND
623 request MUST fail. Note that it is especially difficult to maintain
624 the integrity of cross-server bindings. Unless the server where the
625 resource resides knows about all bindings on all servers to that
626 resource, it may unwittingly destroy the resource or make it
627 inaccessible without notifying another server that manages a binding
628 to the resource. For example, if server A permits creation of a
629 binding to a resource on server B, server A must notify server B
630 about its binding and must have an agreement with B that B will not
631 destroy the resource while A's binding exists. Otherwise server B
632 may receive a DELETE request that it thinks removes the last binding
633 to the resource and destroy the resource while A's binding still
634 exists. The precondition DAV:cross-server-binding is defined below
635 for cases where servers fail cross-server BIND requests because they
636 cannot guarantee the integrity of cross-server bindings.
638 By default, if there already is a binding for the specified segment
639 in the collection, the new binding replaces the existing binding.
640 This default binding replacement behavior can be overridden using the
641 Overwrite header defined in Section 9.6 of [RFC2518].
643 Marshalling:
645 The request MAY include an Overwrite header.
647 The request body MUST be a DAV:bind XML element.
649
650 If the request succeeds, the server MUST return 201 (Created) when
651 a new binding was created and 200 (OK) when an existing binding
652 was replaced.
654 If a response body for a successful request is included, it MUST
655 be a DAV:bind-response XML element. Note that this document does
656 not define any elements for the BIND response body, but the
657 DAV:bind-response element is defined to ensure interoperability
658 between future extensions that do define elements for the BIND
659 response body.
661
663 Preconditions:
665 (DAV:bind-into-collection): The Request-URI MUST identify a
666 collection.
668 (DAV:bind-source-exists): The DAV:href element MUST identify a
669 resource.
671 (DAV:binding-allowed): The resource identified by the DAV:href
672 supports multiple bindings to it.
674 (DAV:cross-server-binding): If the resource identified by the
675 DAV:href element in the request body is on another server from the
676 collection identified by the request-URI, the server MUST support
677 cross-server bindings.
679 (DAV:name-allowed): The name specified by the DAV:segment is
680 available for use as a new binding name.
682 (DAV:can-overwrite): If the collection already contains a binding
683 with the specified path segment, and if an Overwrite header is
684 included, the value of the Overwrite header MUST be "T".
686 (DAV:cycle-allowed): If the DAV:href element identifies a
687 collection, and if the request-URI identifies a collection that is
688 a member of that collection, the server MUST support cycles in the
689 URI namespace.
691 (DAV:locked-update-allowed): If the collection identified by the
692 Request-URI is write-locked, then the appropriate token MUST be
693 specified in an If request header.
695 (DAV:locked-overwrite-allowed): If the collection already contains
696 a binding with the specified path segment, and if that binding is
697 protected by a write-lock, then the appropriate token MUST be
698 specified in an If request header.
700 Postconditions:
702 (DAV:new-binding): The collection MUST have a binding that maps
703 the segment specified in the DAV:segment element in the request
704 body, to the resource identified by the DAV:href element in the
705 request body.
707 4.1 Example: BIND
709 >> Request:
711 BIND /CollY HTTP/1.1
712 Host: www.example.com
713 Content-Type: text/xml; charset="utf-8"
714 Content-Length: xxx
716
717
718 bar.html
719 http://www.example.com/CollX/foo.html
720
722 >> Response:
724 HTTP/1.1 201 Created
726 The server added a new binding to the collection, "http://
727 www.example.com/CollY", associating "bar.html" with the resource
728 identified by the URI "http://www.example.com/CollX/foo.html".
729 Clients can now use the URI "http://www.example.com/CollY/bar.html",
730 to submit requests to that resource.
732 5. UNBIND Method
734 The UNBIND method modifies the collection identified by the
735 Request-URI, by removing the binding identified by the segment
736 specified in the UNBIND body.
738 Once a resource is unreachable by any URI mapping, the server MAY
739 reclaim system resources associated with that resource. If UNBIND
740 removes a binding to a resource, but there remain URI mappings to
741 that resource, the server MUST NOT reclaim system resources
742 associated with the resource.
744 Marshalling:
746 The request body MUST be a DAV:unbind XML element.
748
750 If the request succeeds, the server MUST return 200 (OK) when the
751 binding was successfully deleted.
753 If a response body for a successful request is included, it MUST
754 be a DAV:unbind-response XML element. Note that this document
755 does not define any elements for the UNBIND response body, but the
756 DAV:unbind-response element is defined to ensure interoperability
757 between future extensions that do define elements for the UNBIND
758 response body.
760
762 Preconditions:
764 (DAV:unbind-from-collection): The Request-URI MUST identify a
765 collection.
767 (DAV:unbind-source-exists): The DAV:segment element MUST identify
768 a binding in the collection identified by the Request-URI.
770 (DAV:locked-update-allowed): If the collection identified by the
771 Request-URI is write-locked, then the appropriate token MUST be
772 specified in the request.
774 (DAV:protected-url-deletion-allowed): If the binding identified by
775 the segment is protected by a write-lock, then the appropriate
776 token MUST be specified in the request.
778 Postconditions:
780 (DAV:binding-deleted): The collection MUST NOT have a binding for
781 the segment specified in the DAV:segment element in the request
782 body.
784 5.1 Example: UNBIND
786 >> Request:
788 UNBIND /CollX HTTP/1.1
789 Host: www.example.com
790 Content-Type: text/xml; charset="utf-8"
791 Content-Length: xxx
793
794
795 foo.html
796
798 >> Response:
800 HTTP/1.1 200 OK
802 The server removed the binding named "foo.html" from the collection,
803 "http://www.example.com/CollX". A request to the resource named
804 "http://www.example.com/CollX/foo.html" will return a 404 (Not Found)
805 response.
807 6. REBIND Method
809 The REBIND method removes a binding to a resource from one
810 collection, and adds a binding to that resource into another
811 collection. It is effectively an atomic form of a MOVE request.
813 Marshalling:
815 The request MAY include an Overwrite header.
817 The request body MUST be a DAV:rebind XML element.
819
821 If the request succeeds, the server MUST return 201 (Created) when
822 a new binding was created and 200 (OK) when an existing binding
823 was replaced.
825 If a response body for a successful request is included, it MUST
826 be a DAV:rebind-response XML element. Note that this document
827 does not define any elements for the REBIND response body, but the
828 DAV:rebind-response element is defined to ensure interoperability
829 between future extensions that do define elements for the REBIND
830 response body.
832
834 Preconditions:
836 (DAV:rebind-into-collection): The Request-URI MUST identify a
837 collection.
839 (DAV:rebind-source-exists): The DAV:href element MUST identify a
840 resource.
842 (DAV:binding-allowed): The resource identified by the DAV:href
843 supports multiple bindings to it.
845 (DAV:cross-server-binding): If the resource identified by the
846 DAV:href element in the request body is on another server from the
847 collection identified by the request-URI, the server MUST support
848 cross-server bindings.
850 (DAV:name-allowed): The name specified by the DAV:segment is
851 available for use as a new binding name.
853 (DAV:can-overwrite): If the collection already contains a binding
854 with the specified path segment, and if an Overwrite header is
855 included, the value of the Overwrite header MUST be "T".
857 (DAV:cycle-allowed): If the DAV:href element identifies a
858 collection, and if the request-URI identifies a collection that is
859 a member of that collection, the server MUST support cycles in the
860 URI namespace.
862 (DAV:locked-update-allowed): If the collection identified by the
863 Request-URI is write-locked, then the appropriate token MUST be
864 specified in the request.
866 (DAV:protected-url-modification-allowed): If the collection
867 identified by the Request-URI already contains a binding with the
868 specified path segment, and if that binding is protected by a
869 write-lock, then the appropriate token MUST be specified in the
870 request.
872 (DAV:locked-source-collection-update-allowed): If the collection
873 identified by the parent collection prefix of the DAV:href URI is
874 write-locked, then the appropriate token MUST be specified in the
875 request.
877 (DAV:protected-source-url-deletion-allowed): If the DAV:href URI
878 is protected by a write lock, then the appropriate token MUST be
879 specified in the request.
881 Postconditions:
883 (DAV:new-binding): The collection MUST have a binding that maps
884 the segment specified in the DAV:segment element in the request
885 body, to the resource that was identified by the DAV:href element
886 in the request body.
888 (DAV:binding-deleted): The URL specified in the DAV:href element
889 in the request body MUST NOT be mapped to a resource.
891 6.1 Example: REBIND
893 >> Request:
895 REBIND /CollX HTTP/1.1
896 Host: www.example.com
897 Content-Type: text/xml; charset="utf-8"
898 Content-Length: xxx
900
901
902 foo.html
903 http://www.example.com/CollY/bar.html
904
906 >> Response:
908 HTTP/1.1 200 OK
910 The server added a new binding to the collection, "http://
911 www.example.com/CollX", associating "foo.html" with the resource
912 identified by the URI "http://www.example.com/CollY/bar.html", and
913 removes the binding named "bar.html" from the collection identified
914 by the URI "http://www.example.com/CollY". Clients can now use the
915 URI "http://www.example.com/CollX/foo.html" to submit requests to
916 that resource, and requests on the URI "http://www.example.com/CollY/
917 bar.html" will fail with a 404 (Not Found) response.
919 7. Additional Status Codes
921 7.1 208 Already Reported
923 The 208 (Already Reported) status code can be used inside a
924 DAV:propstat response element to indicate that information about the
925 resource has already been reported in a previous DAV:propstat element
926 in that response. The members of the 208 status resource are omitted
927 from the response.
929 For example, consider a PROPFIND request on /Coll (bound to
930 collection C), where the members of /Coll are /Coll/Foo (bound to
931 resource R) and /Coll/Bar (bound to collection C).
933 >> Request:
935 PROPFIND /Coll/ HTTP/1.1
936 Host: www.example.com
937 Depth: infinity
938 Content-Type: text/xml; charset="utf-8"
939 Content-Length: xxx
941
942
943
944
945 >> Response:
947 HTTP/1.1 207 Multi-Status
948 Content-Type: text/xml; charset="utf-8"
949 Content-Length: xxx
951
952
953
954 http://www.example.com/Coll/
955
956
957 Loop Demo
958
959 HTTP/1.1 200 OK
960
961
962
963 http://www.example.com/Coll/Foo
964
965
966 Bird Inventory
967
968 HTTP/1.1 200 OK
969
970
971
972 http://www.example.com/Coll/Bar
973
974
975 Loop Demo
976
977 HTTP/1.1 208 Already Reported
978
979
980
982 A client can request the DAV:resourceid property in a PROPFIND
983 request to guarantee that they can accurately reconstruct the binding
984 structure of a collection with multiple bindings to a single
985 resource.
987 7.2 506 Loop Detected
989 The 506 (Loop Detected) status code indicates that the server
990 terminated an operation because it encountered an infinite loop while
991 processing a request with "Depth: infinity". This status indicates
992 that the entire operation failed.
994 8. Security Considerations
996 This section is provided to make WebDAV applications aware of the
997 security implications of this protocol.
999 All of the security considerations of HTTP/1.1 and the WebDAV
1000 Distributed Authoring Protocol specification also apply to this
1001 protocol specification. In addition, bindings introduce several new
1002 security concerns and increase the risk of some existing threats.
1003 These issues are detailed below.
1005 8.1 Privacy Concerns
1007 In a context where cross-server bindings are supported, creating
1008 bindings on a trusted server may make it possible for a hostile agent
1009 to induce users to send private information to a target on a
1010 different server.
1012 8.2 Redirect Loops
1014 Although redirect loops were already possible in HTTP 1.1, the
1015 introduction of the BIND method creates a new avenue for clients to
1016 create loops accidentally or maliciously. If the binding and its
1017 target are on the same server, the server may be able to detect BIND
1018 requests that would create loops. Servers are required to detect
1019 loops that are caused by bindings to collections during the
1020 processing of any requests with "Depth: infinity".
1022 8.3 Bindings, and Denial of Service
1024 Denial of service attacks were already possible by posting URIs that
1025 were intended for limited use at heavily used Web sites. The
1026 introduction of BIND creates a new avenue for similar denial of
1027 service attacks. If cross-server bindings are supported, clients can
1028 now create bindings at heavily used sites to target locations that
1029 were not designed for heavy usage.
1031 8.4 Private Locations May Be Revealed
1033 If the DAV:parent-set property is maintained on a resource, the
1034 owners of the bindings risk revealing private locations. The
1035 directory structures where bindings are located are available to
1036 anyone who has access to the DAV:parent-set property on the resource.
1037 Moving a binding may reveal its new location to anyone with access to
1038 DAV:parent-set on its resource.
1040 8.5 DAV:parent-set and Denial of Service
1042 If the server maintains the DAV:parent-set property in response to
1043 bindings created in other administrative domains, it is exposed to
1044 hostile attempts to make it devote resources to adding bindings to
1045 the list.
1047 9. Internationalization Considerations
1049 All internationalization considerations mentioned in [RFC2518] also
1050 apply to this document.
1052 10. IANA Considerations
1054 All IANA considerations mentioned in [RFC2518] also apply to this
1055 document.
1057 11. Acknowledgements
1059 This draft is the collaborative product of the authors and Tyson
1060 Chihaya, Jim Davis, and Chuck Fay. This draft has benefited from
1061 thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Ken
1062 Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer Dawkins, Mark
1063 Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred
1064 Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj
1065 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry
1066 Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby,
1067 Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John
1068 Turner, Kevin Wiggen, and other members of the WebDAV working group.
1070 Normative References
1072 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1073 3", BCP 9, RFC 2026, October 1996.
1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1076 Requirement Levels", BCP 14, RFC 2119, March 1997.
1078 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1079 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1080 August 1998.
1082 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1083 Jensen, "HTTP Extensions for Distributed Authoring --
1084 WEBDAV", RFC 2518, February 1999.
1086 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1087 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1088 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1090 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1091 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
1092 REC-xml, October 2000, .
1095 Authors' Addresses
1097 Geoffrey Clemm
1098 IBM
1099 20 Maguire Road
1100 Lexington, MA 02421
1102 EMail: geoffrey.clemm@us.ibm.com
1104 Jason Crawford
1105 IBM Research
1106 P.O. Box 704
1107 Yorktown Heights, NY 10598
1109 EMail: ccjason@us.ibm.com
1111 Julian F. Reschke
1112 greenbytes GmbH
1113 Salzmannstrasse 152
1114 Muenster, NW 48159
1115 Germany
1117 EMail: julian.reschke@greenbytes.de
1119 Judy Slein
1120 Xerox Corporation
1121 800 Phillips Road, 105-50C
1122 Webster, NY 14580
1124 EMail: jslein@crt.xerox.com
1125 Jim Whitehead
1126 UC Santa Cruz, Dept. of Computer Science
1127 1156 High Street
1128 Santa Cruz, CA 95064
1130 EMail: ejw@cse.ucsc.edu
1132 Appendix A. Change Log (to be removed by RFC Editor before publication)
1134 A.1 Since draft-ietf-webdav-bind-02
1136 Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and
1137 "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed
1138 resolution, but keep it open. Add issues "ED_references" and
1139 "4_507_status". Started work on index. Rename document to "Binding
1140 Extensions to Web Distributed Authoring and Versioning (WebDAV)".
1141 Rename "References" to "Normative References". Close issue
1142 "ED_references". CLose issue "4_507_status".
1144 Appendix B. Resolved issues (to be removed by RFC Editor before
1145 publication)
1147 Issues that were either rejected or resolved in this version of this
1148 document.
1150 B.1 ED_references
1152 Type: edit
1154
1157 julian.reschke@greenbytes.de (2003-12-09): (1) Distinguish normative
1158 and informative references, (2) text referring to RFC2119 is missing,
1159 (3) references to RFC2277, RFC2616 and XML not needed.
1161 Resolution (2003-12-11): Editorial changes applied.
1163 B.2 2.3_COPY_SHARED_BINDINGS
1165 Type: change
1167
1170 Peter.Nevermann@softwareag.com (2003-07-10): What if a copied
1171 collection has two bindings to the same resource.
1173 Resolution (2003-08-21): Recommend that only one resource with
1174 multiple bindings to it be created by the COPY.
1176 B.3 2.3_MULTIPLE_COPY
1178 Type: change
1180
1183 Peter.Nevermann@softwareag.com (2003-08-17): What two resources are
1184 copied to the same resource by a single COPY.
1186 Resolution (2003-08-21): Server decides order of updates.
1188 B.4 4_507_status
1190 Type: change
1192
1195 julian.reschke@greenbytes.de (2003-12-09): Section 4 refers to a
1196 definition of a 507 status code in Section 7.1, which doesn't exist.
1197 Should this text be replaced by a reference to the
1198 DAV:cross-server-binding precondition?
1200 Resolution (2003-12-11): Change wording to refer to precondition
1201 name.
1203 Appendix C. Open issues (to be removed by RFC Editor before publication)
1205 C.1 5.1_LOOP_STATUS
1207 Type: change
1209 julian.reschke@greenbytes.de (2002-10-11): Should the 506 status in a
1210 PROPFIND be handled differently?
1212 geoffrey.clemm@us.ibm.com (2003-08-03): Use new 208 status to report
1213 cycles in PROPFIND.
1215 julian.reschke@greenbytes.de (2003-11-16): Proposal: a) import DAV
1216 request header definition from rfc2518bis (note that the definition
1217 in the latest draft probably needs some more work) b) define a DAV
1218 compliance class for the BIND spec c) clarify that 208 should only be
1219 returned when the client specifies compliance to the BIND spec in the
1220 PROPFIND request (otherwise fail the complete request).
1222 Index
1224 2
1225 208 Already Reported (status code) 21
1227 5
1228 506 Loop Detected (status code) 23
1230 B
1231 BIND method 15
1233 C
1234 Condition Names
1235 DAV:bind-into-collection (pre) 16
1236 DAV:bind-source-exists (pre) 16
1237 DAV:binding-allowed (pre) 16, 20
1238 DAV:binding-deleted (post) 18, 21
1239 DAV:can-overwrite (pre) 16, 20
1240 DAV:cross-server-binding (pre) 16, 20
1241 DAV:cycle-allowed (pre) 16, 20
1242 DAV:locked-overwrite-allowed (pre) 16
1243 DAV:locked-source-collection-update-allowed (pre) 20
1244 DAV:locked-update-allowed (pre) 16, 18, 20
1245 DAV:name-allowed (pre) 16, 20
1246 DAV:new-binding (post) 17, 21
1247 DAV:protected-source-url-deletion-allowed (pre) 20
1248 DAV:protected-url-deletion-allowed (pre) 18
1249 DAV:protected-url-modification-allowed (pre) 20
1250 DAV:rebind-into-collection (pre) 20
1251 DAV:rebind-source-exists (pre) 20
1252 DAV:unbind-from-collection (pre) 18
1253 DAV:unbind-source-exists (pre) 18
1255 D
1256 DAV:bind-into-collection precondition 16
1257 DAV:bind-source-exists precondition 16
1258 DAV:binding-allowed precondition 16, 20
1259 DAV:binding-deleted postcondition 18, 21
1260 DAV:can-overwrite precondition 16, 20
1261 DAV:cross-server-binding precondition 16, 20
1262 DAV:cycle-allowed precondition 16, 20
1263 DAV:locked-overwrite-allowed precondition 16
1264 DAV:locked-source-collection-update-allowed precondition 20
1265 DAV:locked-update-allowed precondition 16, 18, 20
1266 DAV:name-allowed precondition 16, 20
1267 DAV:new-binding postcondition 17, 21
1268 DAV:parent-set property 14
1269 DAV:protected-source-url-deletion-allowed precondition 20
1270 DAV:protected-url-deletion-allowed precondition 18
1271 DAV:protected-url-modification-allowed precondition 20
1272 DAV:rebind-into-collection precondition 20
1273 DAV:rebind-source-exists precondition 20
1274 DAV:resource-id property 14
1275 DAV:unbind-from-collection precondition 18
1276 DAV:unbind-source-exists precondition 18
1278 M
1279 Methods
1280 BIND 15
1281 REBIND 19
1282 UNBIND 17
1284 P
1285 Properties
1286 DAV:parent-set 14
1287 DAV:resource-id 14
1289 R
1290 REBIND method 19
1292 S
1293 Status Codes
1294 208 Already Reported 21
1295 506 Loop Detected 23
1297 U
1298 UNBIND method 17
1300 Intellectual Property Statement
1302 The IETF takes no position regarding the validity or scope of any
1303 intellectual property or other rights that might be claimed to
1304 pertain to the implementation or use of the technology described in
1305 this document or the extent to which any license under such rights
1306 might or might not be available; neither does it represent that it
1307 has made any effort to identify any such rights. Information on the
1308 IETF's procedures with respect to rights in standards-track and
1309 standards-related documentation can be found in BCP-11. Copies of
1310 claims of rights made available for publication and any assurances of
1311 licenses to be made available, or the result of an attempt made to
1312 obtain a general license or permission for the use of such
1313 proprietary rights by implementors or users of this specification can
1314 be obtained from the IETF Secretariat.
1316 The IETF invites any interested party to bring to its attention any
1317 copyrights, patents or patent applications, or other proprietary
1318 rights which may cover technology that may be required to practice
1319 this standard. Please address the information to the IETF Executive
1320 Director.
1322 Full Copyright Statement
1324 Copyright (C) The Internet Society (2003). All Rights Reserved.
1326 This document and translations of it may be copied and furnished to
1327 others, and derivative works that comment on or otherwise explain it
1328 or assist in its implementation may be prepared, copied, published
1329 and distributed, in whole or in part, without restriction of any
1330 kind, provided that the above copyright notice and this paragraph are
1331 included on all such copies and derivative works. However, this
1332 document itself may not be modified in any way, such as by removing
1333 the copyright notice or references to the Internet Society or other
1334 Internet organizations, except as needed for the purpose of
1335 developing Internet standards in which case the procedures for
1336 copyrights defined in the Internet Standards process must be
1337 followed, or as required to translate it into languages other than
1338 English.
1340 The limited permissions granted above are perpetual and will not be
1341 revoked by the Internet Society or its successors or assignees.
1343 This document and the information contained herein is provided on an
1344 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1345 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1346 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1347 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1348 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1350 Acknowledgment
1352 Funding for the RFC Editor function is currently provided by the
1353 Internet Society.