draft-ietf-webdav-bind-08.txt   draft-ietf-webdav-bind-09.txt 
Network Working Group G. Clemm Network Working Group G. Clemm
Internet-Draft IBM Internet-Draft IBM
Updates: 2518 (if approved) J. Crawford Updates: 2518 (if approved) J. Crawford
Expires: May 26, 2005 IBM Research Expires: June 9, 2005 IBM Research
J. Reschke J. Reschke
greenbytes greenbytes
J. Whitehead J. Whitehead
U.C. Santa Cruz U.C. Santa Cruz
November 25, 2004 December 9, 2004
Binding Extensions to Web Distributed Authoring and Versioning Binding Extensions to Web Distributed Authoring and Versioning
(WebDAV) (WebDAV)
draft-ietf-webdav-bind-08 draft-ietf-webdav-bind-09
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 41 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 26, 2005. This Internet-Draft will expire on June 9, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This specification defines bindings, and the BIND method for creating This specification defines bindings, and the BIND method for creating
multiple bindings to the same resource. Creating a new binding to a multiple bindings to the same resource. Creating a new binding to a
resource causes at least one new URI to be mapped to that resource. resource causes at least one new URI to be mapped to that resource.
skipping to change at page 3, line 13 skipping to change at page 3, line 13
all registered issues since draft 02. all registered issues since draft 02.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Rationale for Distinguishing Bindings from URI Mappings . 7 1.2 Rationale for Distinguishing Bindings from URI Mappings . 7
1.3 Method Preconditions and Postconditions . . . . . . . . . 8 1.3 Method Preconditions and Postconditions . . . . . . . . . 8
2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 8
2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9
2.1.1 Bind loops . . . . . . . . . . . . . . . . . . . . . . 10
2.2 URI Mappings Created by a new Binding . . . . . . . . . . 10 2.2 URI Mappings Created by a new Binding . . . . . . . . . . 10
2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 11 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . 11
2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 12 2.3.1 Example: COPY with 'Depth: infinity' in presence
2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 13 of bind loops . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Example: COPY with 'Depth: infinity' with multiple
bindings to a leaf resource . . . . . . . . . . . . . 14
2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15
2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15
2.6 Determining Whether Two Bindings Are to the Same 2.6 Determining Whether Two Bindings Are to the Same
Resource . . . . . . . . . . . . . . . . . . . . . . . . . 14 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Discovering the Bindings to a Resource . . . . . . . . . . 14 2.7 Discovering the Bindings to a Resource . . . . . . . . . . 17
3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 15 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 17
3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 15 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 18
4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Example for DAV:parent-set property . . . . . . . . . 18
4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 18 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 22
5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 20 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 22
6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 24
6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 22 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 23 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 26
7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 23 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 27
7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 23 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 27
7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 25 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 27
7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 25 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 29
8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 26 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 29
8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 26 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 30
8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 26 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 30
8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 26 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 30
8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 26 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 30
9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 31
9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 27 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 31
9.4 Private Locations May Be Revealed . . . . . . . . . . . . 27 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 31
9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 27 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 31
10. Internationalization Considerations . . . . . . . . . . . . 27 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 10. Internationalization Considerations . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
13. Normative References . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
A. Change Log (to be removed by RFC Editor before publication) . 29 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 32
A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 29 13.2 Informative References . . . . . . . . . . . . . . . . . . . 32
A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 30 A. Change Log (to be removed by RFC Editor before publication) . 33
A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 30 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 33
A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 30 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 34
A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 30 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 34
A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 34
A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 34
A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 34
A.7 Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 34
B. Resolved issues (to be removed by RFC Editor before B. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 30 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 35
B.1 rfc2396bis . . . . . . . . . . . . . . . . . . . . . . . . 30 B.1 2_allow_destroy . . . . . . . . . . . . . . . . . . . . . 35
B.2 bind_vs_ACL . . . . . . . . . . . . . . . . . . . . . . . 31 B.2 2.1_separate_loop_discussion . . . . . . . . . . . . . . . 35
B.3 bind_properties . . . . . . . . . . . . . . . . . . . . . 31 B.3 2.1.1_bind_loops_vs_locks . . . . . . . . . . . . . . . . 35
B.4 2.3_copy_to_same . . . . . . . . . . . . . . . . . . . . . 31 B.4 2.3_copy_depth_infinity . . . . . . . . . . . . . . . . . 36
B.5 6_rebind_intro . . . . . . . . . . . . . . . . . . . . . . 32 B.5 2.3_copy_vs_loops . . . . . . . . . . . . . . . . . . . . 36
B.6 2.3_copy_example . . . . . . . . . . . . . . . . . . . . . 37
B.7 2.6_resource-id_vs_versions . . . . . . . . . . . . . . . 37
B.8 3.2_example . . . . . . . . . . . . . . . . . . . . . . . 37
B.9 atomicity . . . . . . . . . . . . . . . . . . . . . . . . 38
B.10 6_rebind_intro . . . . . . . . . . . . . . . . . . . . . . 38
B.11 6_rebind_premissions . . . . . . . . . . . . . . . . . . . 38
C. Open issues (to be removed by RFC Editor prior to C. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 32 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 39
C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 C.2 2.6_when_do_ids_change . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 35 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 42
1. Introduction 1. Introduction
This specification extends the WebDAV Distributed Authoring Protocol This specification extends the WebDAV Distributed Authoring Protocol
to enable clients to create new access paths to existing resources. to enable clients to create new access paths to existing resources.
This capability is useful for several reasons: This capability is useful for several reasons:
URIs of WebDAV-compliant resources are hierarchical and correspond to URIs of WebDAV-compliant resources are hierarchical and correspond to
a hierarchy of collections in resource space. The WebDAV Distributed a hierarchy of collections in resource space. The WebDAV Distributed
Authoring Protocol makes it possible to organize these resources into Authoring Protocol makes it possible to organize these resources into
skipping to change at page 9, line 15 skipping to change at page 9, line 15
There is no difference between an initial binding added by PUT, COPY, There is no difference between an initial binding added by PUT, COPY,
or MKCOL, and additional bindings added with BIND. or MKCOL, and additional bindings added with BIND.
It would be very undesirable if one binding could be destroyed as a It would be very undesirable if one binding could be destroyed as a
side effect of operating on the resource through a different binding. side effect of operating on the resource through a different binding.
In particular, the removal of one binding to a resource (e.g. with a In particular, the removal of one binding to a resource (e.g. with a
DELETE or a MOVE) MUST NOT disrupt another binding to that resource, DELETE or a MOVE) MUST NOT disrupt another binding to that resource,
e.g. by turning that binding into a dangling path segment. The e.g. by turning that binding into a dangling path segment. The
server MUST NOT reclaim system resources after removing one binding, server MUST NOT reclaim system resources after removing one binding,
while other bindings to the resource remain. In other words, the while other bindings to the resource remain. In other words, the
server MUST maintain the integrity of a binding. server MUST maintain the integrity of a binding. It is permissible,
however, for future method definitions (e.g., a DESTROY method) to
have semantics that explicitly remove all bindings and/or immediately
reclaim system resources.
2.1 Bindings to Collections 2.1 Bindings to Collections
Bindings to collections can result in loops, which servers MUST
detect when processing "Depth: infinity" requests. It is sometimes
possible to complete an operation in spite of the presence of a loop.
However, the 506 (Loop Detected) status code is defined in Section 7
for use in contexts where an operation is terminated because a loop
was encountered.
Creating a new binding to a collection makes each resource associated Creating a new binding to a collection makes each resource associated
with a binding in that collection accessible via a new URI, and thus with a binding in that collection accessible via a new URI, and thus
creates new URI mappings to those resources but no new bindings. creates new URI mappings to those resources but no new bindings.
For example, suppose a new binding CollY is created for collection C1 For example, suppose a new binding CollY is created for collection C1
in the figure below. It immediately becomes possible to access in the figure below. It immediately becomes possible to access
resource R1 using the URI /CollY/x.gif and to access resource R2 resource R1 using the URI /CollY/x.gif and to access resource R2
using the URI /CollY/y.jpg, but no new bindings for these child using the URI /CollY/y.jpg, but no new bindings for these child
resources were created. This is because bindings are part of the resources were created. This is because bindings are part of the
state of a collection, and associate a URI that is relative to that state of a collection, and associate a URI that is relative to that
skipping to change at page 10, line 25 skipping to change at page 10, line 7
| bindings: | | bindings: |
| x.gif y.jpg | | x.gif y.jpg |
+------------------+ +------------------+
| \ | \
| \ | \
| \ | \
+-------------+ +-------------+ +-------------+ +-------------+
| Resource R1 | | Resource R2 | | Resource R1 | | Resource R2 |
+-------------+ +-------------+ +-------------+ +-------------+
2.1.1 Bind loops
Bindings to collections can result in loops, which servers MUST
detect when processing "Depth: infinity" requests. It is sometimes
possible to complete an operation in spite of the presence of a loop.
For instance, a PROPFIND can still succeed if the server uses the new
status code 208 (Already Reported) defined in Section 7.1.
However, the 506 (Loop Detected) status code is defined in Section
7.2 for use in contexts where an operation is terminated because a
loop was encountered.
2.2 URI Mappings Created by a new Binding 2.2 URI Mappings Created by a new Binding
Suppose a binding from "Binding-Name" to resource R is to be added to Suppose a binding from "Binding-Name" to resource R is to be added to
a collection, C. Then if C-MAP is the set of URIs that were mapped a collection, C. Then if C-MAP is the set of URIs that were mapped
to C before the BIND request, then for each URI "C-URI" in C-MAP, the to C before the BIND request, then for each URI "C-URI" in C-MAP, the
URI "C-URI/Binding-Name" is mapped to resource R following the BIND URI "C-URI/Binding-Name" is mapped to resource R following the BIND
request. request.
For example, if a binding from "foo.html" to R is added to a For example, if a binding from "foo.html" to R is added to a
collection C, and if the following URIs are mapped to C: collection C, and if the following URIs are mapped to C:
skipping to change at page 12, line 23 skipping to change at page 12, line 16
bindings to a resource, more than one source resource updates a bindings to a resource, more than one source resource updates a
single destination resource, the order of the updates is server single destination resource, the order of the updates is server
defined. defined.
If a COPY request would cause a new resource to be created as a copy If a COPY request would cause a new resource to be created as a copy
of an existing resource, and that COPY request has already created a of an existing resource, and that COPY request has already created a
copy of that existing resource, the COPY request instead creates copy of that existing resource, the COPY request instead creates
another binding to the previous copy, instead of creating a new another binding to the previous copy, instead of creating a new
resource. resource.
2.3.1 Example: COPY with 'Depth: infinity' in presence of bind loops
As an example of how COPY with Depth infinity would work in the
presence of bindings, consider the following collection:
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
+-------------------------------+
| Collection C1 |<-------+
| bindings: | |
| x.gif CollY | |
+-------------------------------+ |
| \ (creates loop) |
| \ |
+-------------+ +------------------+ |
| Resource R1 | | Collection C2 | |
+-------------+ | bindings: | |
| y.gif CollZ | |
+------------------+ |
| | |
| +--------+
|
+-------------+
| Resource R2 |
+-------------+
If a COPY with Depth inifinity is submitted to /CollX, with
destination of /CollA, the outcome of the copy operation is:
+------------------+
| Root Collection |
| bindings: |
| CollX CollA |
+------------------+
| |
| +---------------------------+
| |
+-------------------+ |
| Collection C1 |<------------------+ |
| bindings: | | |
| x.gif CollY | | |
+-------------------+ | |
| \ (creates loop) | |
| \ | |
+-------------+ +-----------------+ | |
| Resource R1 | | Collection C2 | | |
+-------------+ | bindings: | | |
| y.gif CollZ | | |
+-----------------+ | |
| | | |
| +-------+ |
| |
+-------------+ |
| Resource R2 | |
+-------------+ |
|
+-------------------------------+
|
+-------------------+
| Collection C3 |<------------------+
| bindings: | |
| x.gif CollY | |
+-------------------+ |
| \ (creates loop) |
| \ |
+-------------+ +-----------------+ |
| Resource R3 | | Collection C4 | |
+-------------+ | bindings: | |
| y.gif CollZ | |
+-----------------+ |
| | |
| +-------+
|
+-------------+
| Resource R4 |
+-------------+
2.3.2 Example: COPY with 'Depth: infinity' with multiple bindings to a
leaf resource
Given the following collection hierarchy:
+------------------+
| Root Collection |
| bindings: |
| CollX |
+------------------+
|
|
|
+----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+----------------+
| |
| |
+-------------+
| Resource R1 |
+-------------+
A COPY of /CollX with Depth infinity to /CollY results in the
following collection hierarchy:
+------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+------------------+
| \
| \
| \
+----------------+ +-----------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| x.gif y.gif | | x.gif y.gif |
+----------------+ +-----------------+
| | | |
| | | |
+-------------+ +-------------+
| Resource R1 | | Resource R2 |
+-------------+ +-------------+
2.4 DELETE and Bindings 2.4 DELETE and Bindings
When there are multiple bindings to a resource, a DELETE applied to When there are multiple bindings to a resource, a DELETE applied to
that resource MUST NOT remove any bindings to that resource other that resource MUST NOT remove any bindings to that resource other
than the one identified by the Request-URI. For example, suppose the than the one identified by the Request-URI. For example, suppose the
collection identified by the URI "/a" has a binding named "x" to a collection identified by the URI "/a" has a binding named "x" to a
resource R, and another collection identified by "/b" has a binding resource R, and another collection identified by "/b" has a binding
named "y" to the same resource R. Then a DELETE applied to "/a/x" named "y" to the same resource R. Then a DELETE applied to "/a/x"
removes the binding named "x" from "/a" but MUST NOT remove the removes the binding named "x" from "/a" but MUST NOT remove the
binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues
to identify the resource R). In particular, although Section 8.6.1 to identify the resource R). In particular, although Section 8.6.1
of [RFC2518] states that during DELETE processing, a server "MUST of [RFC2518] states that during DELETE processing, a server "MUST
remove any URI for the resource identified by the Request-URI from remove any URI for the resource identified by the Request-URI from
collections which contain it as a member", a server that supports the collections which contain it as a member", a server that supports the
binding protocol MUST NOT follow this requirement. binding protocol MUST NOT follow this requirement.
When DELETE is applied to a collection, it MUST NOT modify the When DELETE is applied to a collection, it MUST NOT modify the
membership of any other collection that is not itself a member of the membership of any other collection that is not itself a member of the
collection being deleted. For example, if both "/a/.../x" and collection being deleted. For example, if both "/a/.../x" and
"/b/.../y" identify the same collection, C, then applying DELETE to "/b/.../y" identify the same collection, C, then applying DELETE to
"/a" MUST NOT delete an internal member from C or from any other "/a" must not delete an internal member from C or from any other
collection that is a member of C, because that would modify the collection that is a member of C, because that would modify the
membership of "/b". membership of "/b".
If a collection supports the UNBIND method (see Section 5), a DELETE If a collection supports the UNBIND method (see Section 5), a DELETE
of an internal member of a collection MAY be implemented as an UNBIND of an internal member of a collection MAY be implemented as an UNBIND
request. In this case, applying DELETE to a Request-URI has the request. In this case, applying DELETE to a Request-URI has the
effect of removing the binding identified by the final segment of the effect of removing the binding identified by the final segment of the
Request-URI from the collection identified by the Request-URI minus Request-URI from the collection identified by the Request-URI minus
its final segment. Although [RFC2518] allows a DELETE to be a its final segment. Although [RFC2518] allows a DELETE to be a
non-atomic operation, when the DELETE operation is implemented as an non-atomic operation, when the DELETE operation is implemented as an
skipping to change at page 14, line 35 skipping to change at page 17, line 15
the client can be assured that the two bindings are to the same the client can be assured that the two bindings are to the same
resource. resource.
The DAV:resource-id property is created, and its value assigned, when The DAV:resource-id property is created, and its value assigned, when
the resource is created. The value of DAV:resource-id MUST NOT be the resource is created. The value of DAV:resource-id MUST NOT be
changed. Even after the resource is no longer accessible through any changed. Even after the resource is no longer accessible through any
URI, that value MUST NOT be reassigned to another resource's URI, that value MUST NOT be reassigned to another resource's
DAV:resource-id property. DAV:resource-id property.
Any method that creates a new resource MUST assign a new, unique Any method that creates a new resource MUST assign a new, unique
value to its DAV:resource-id property. For example, a PUT or a COPY value to its DAV:resource-id property. For example, a PUT applied to
that creates a new resource must assign a new, unique value to the a null resource, COPY (when not overwriting an existing target) and
DAV:resource-id property of that new resource. CHECKIN (see [RFC3253], section 4.4) must assign a new, unique value
to the DAV:resource-id property of the new resource they create.
On the other hand, any method that affects an existing resource MUST On the other hand, any method that affects an existing resource must
NOT change the value of its DAV:resource-id property. For example, a not change the value of its DAV:resource-id property. Specifically,
PUT or a COPY that updates an existing resource must not change the a PUT or a COPY that updates an existing resource must not change the
value of its DAV:resource-id property. A MOVE, since it does not value of its DAV:resource-id property. A REBIND, since it does not
create a new resource, but only changes the location of an existing create a new resource, but only changes the location of an existing
resource, must not change the value of the DAV:resource-id property. resource, must not change the value of the DAV:resource-id property.
2.7 Discovering the Bindings to a Resource 2.7 Discovering the Bindings to a Resource
An OPTIONAL DAV:parent-set property on a resource provides a list of An OPTIONAL DAV:parent-set property on a resource provides a list of
the bindings that associate a collection and a URI segment with that the bindings that associate a collection and a URI segment with that
resource. If the DAV:parent-set property exists on a given resource, resource. If the DAV:parent-set property exists on a given resource,
it MUST contain a complete list of all bindings to that resource that it MUST contain a complete list of all bindings to that resource that
the client is authorized to see. When deciding whether to support the client is authorized to see. When deciding whether to support
the DAV:parent-set property, server implementers / administrators the DAV:parent-set property, server implementers / administrators
should balance the benefits it provides against the cost of should balance the benefits it provides against the cost of
maintaining the property and the security risks enumerated in maintaining the property and the security risks enumerated in
Sections 8.4 and 8.5. Sections 9.4 and 9.5.
3. Properties 3. Properties
The bind feature introduces the following properties for a resource. The bind feature introduces the following properties for a resource.
A DAV:allprop PROPFIND request SHOULD NOT return any of the A DAV:allprop PROPFIND request SHOULD NOT return any of the
properties defined by this document. This allows a binding server to properties defined by this document. This allows a binding server to
perform efficiently when a naive client, which does not understand perform efficiently when a naive client, which does not understand
the cost of asking a server to compute all possible live properties, the cost of asking a server to compute all possible live properties,
issues a DAV:allprop PROPFIND request. issues a DAV:allprop PROPFIND request.
skipping to change at page 15, line 44 skipping to change at page 18, line 24
The DAV:parent-set property is an OPTIONAL property that enables The DAV:parent-set property is an OPTIONAL property that enables
clients to discover what collections contain a binding to this clients to discover what collections contain a binding to this
resource (i.e. what collections have that resource as an internal resource (i.e. what collections have that resource as an internal
member). It contains an of href/segment pair for each collection member). It contains an of href/segment pair for each collection
that has a binding to the resource. The href identifies the that has a binding to the resource. The href identifies the
collection, and the segment identifies the binding name of that collection, and the segment identifies the binding name of that
resource in that collection. resource in that collection.
A given collection MUST appear only once in the DAV:parent-set for A given collection MUST appear only once in the DAV:parent-set for
any given binding, even if there are multiple URI mappings to that any given binding, even if there are multiple URI mappings to that
collection. For example, if collection C1 is mapped to both /CollX collection.
and /CollY, and C1 contains a binding named "x.gif" to a resource R1,
then either [/CollX, x.gif] or [/CollY, x.gif] can appear in the
DAV:parent-set of R1, but not both. But if C1 also had a binding
named "y.gif" to R1, then there would be two entries for C1 in the
DAV:binding-set of R1 (i.e. either both [/CollX, x.gif] and [/CollX,
y.gif] or alternatively, both [/CollY, x.gif] and [/CollY, y.gif]).
<!ELEMENT parent-set (parent)*> <!ELEMENT parent-set (parent)*>
<!ELEMENT parent (href, segment)> <!ELEMENT parent (href, segment)>
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
<!-- PCDATA value: segment, as defined in section 3.3 of <!-- PCDATA value: segment, as defined in section 3.3 of
[draft-fielding-rfc2396bis] --> [draft-fielding-rfc2396bis] -->
3.2.1 Example for DAV:parent-set property
For example, if collection C1 is mapped to both /CollX and /CollY,
and C1 contains a binding named "x.gif" to a resource R1, then either
[/CollX, x.gif] or [/CollY, x.gif] can appear in the DAV:parent-set
of R1, but not both. But if C1 also had a binding named "y.gif" to
R1, then there would be two entries for C1 in the DAV:binding-set of
R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively,
both [/CollY, x.gif] and [/CollY, y.gif]).
+-------------------------+
| Root Collection |
| bindings: |
| CollX CollY |
+-------------------------+
| /
| /
| /
+-----------------+
| Collection C1 |
| bindings: |
| x.gif y.gif |
+-----------------+
| |
| |
| |
+--------------+
| Resource R1 |
+--------------+
In this case, one possible value for DAV:parent-set property on
"/CollX/x.gif" would be:
<parent-set xmlns="DAV:">
<parent>
<href>/CollX</href>
<segment>x.gif</segment>
</parent>
<parent>
<href>/CollX</href>
<segment>y.gif</segment>
</parent>
</parent-set>
4. BIND Method 4. BIND Method
The BIND method modifies the collection identified by the The BIND method modifies the collection identified by the
Request-URI, by adding a new binding from the segment specified in Request-URI, by adding a new binding from the segment specified in
the BIND body to the resource identified in the BIND body. the BIND body to the resource identified in the BIND body.
If a server cannot guarantee the integrity of the binding, the BIND If a server cannot guarantee the integrity of the binding, the BIND
request MUST fail. Note that it is especially difficult to maintain request MUST fail. Note that it is especially difficult to maintain
the integrity of cross-server bindings. Unless the server where the the integrity of cross-server bindings. Unless the server where the
resource resides knows about all bindings on all servers to that resource resides knows about all bindings on all servers to that
skipping to change at page 16, line 38 skipping to change at page 20, line 18
to the resource and destroy the resource while A's binding still to the resource and destroy the resource while A's binding still
exists. The precondition DAV:cross-server-binding is defined below exists. The precondition DAV:cross-server-binding is defined below
for cases where servers fail cross-server BIND requests because they for cases where servers fail cross-server BIND requests because they
cannot guarantee the integrity of cross-server bindings. cannot guarantee the integrity of cross-server bindings.
By default, if there already is a binding for the specified segment By default, if there already is a binding for the specified segment
in the collection, the new binding replaces the existing binding. in the collection, the new binding replaces the existing binding.
This default binding replacement behavior can be overridden using the This default binding replacement behavior can be overridden using the
Overwrite header defined in Section 9.6 of [RFC2518]. Overwrite header defined in Section 9.6 of [RFC2518].
This method is unsafe and idempotent (see [RFC2616], section 9.1). If a BIND request fails, the server state preceding the request MUST
be restored. This method is unsafe and idempotent (see [RFC2616],
section 9.1).
Marshalling: Marshalling:
The request MAY include an Overwrite header. The request MAY include an Overwrite header.
The request body MUST be a DAV:bind XML element. The request body MUST be a DAV:bind XML element.
<!ELEMENT bind (segment, href)> <!ELEMENT bind (segment, href)>
If the request succeeds, the server MUST return 201 (Created) when If the request succeeds, the server MUST return 201 (Created) when
skipping to change at page 18, line 33 skipping to change at page 22, line 28
</D:bind> </D:bind>
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
The server added a new binding to the collection, The server added a new binding to the collection,
"http://www.example.com/CollY", associating "bar.html" with the "http://www.example.com/CollY", associating "bar.html" with the
resource identified by the URI resource identified by the URI
"http://www.example.com/CollX/foo.html". Clients can now use the URI "http://www.example.com/CollX/foo.html". Clients can now use the URI
"http://www.example.com/CollY/bar.html", to submit requests to that "http://www.example.com/CollY/bar.html" to submit requests to that
resource. resource.
5. UNBIND Method 5. UNBIND Method
The UNBIND method modifies the collection identified by the The UNBIND method modifies the collection identified by the
Request-URI, by removing the binding identified by the segment Request-URI, by removing the binding identified by the segment
specified in the UNBIND body. specified in the UNBIND body.
Once a resource is unreachable by any URI mapping, the server MAY Once a resource is unreachable by any URI mapping, the server MAY
reclaim system resources associated with that resource. If UNBIND reclaim system resources associated with that resource. If UNBIND
removes a binding to a resource, but there remain URI mappings to removes a binding to a resource, but there remain URI mappings to
that resource, the server MUST NOT reclaim system resources that resource, the server MUST NOT reclaim system resources
associated with the resource. associated with the resource.
This method is unsafe and idempotent (see [RFC2616], section 9.1). If an UNBIND request fails, the server state preceding the request
MUST be restored. This method is unsafe and idempotent (see
[RFC2616], section 9.1).
Marshalling: Marshalling:
The request body MUST be a DAV:unbind XML element. The request body MUST be a DAV:unbind XML element.
<!ELEMENT unbind (segment)> <!ELEMENT unbind (segment)>
If the request succeeds, the server MUST return 200 (OK) when the If the request succeeds, the server MUST return 200 (OK) when the
binding was successfully deleted. binding was successfully deleted.
If a response body for a successful request is included, it MUST If a response body for a successful request is included, it MUST
be a DAV:unbind-response XML element. Note that this document be a DAV:unbind-response XML element. Note that this document
does not define any elements for the UNBIND response body, but the does not define any elements for the UNBIND response body, but the
DAV:unbind-response element is defined to ensure interoperability DAV:unbind-response element is defined to ensure interoperability
between future extensions that do define elements for the UNBIND between future extensions that do define elements for the UNBIND
response body. response body.
skipping to change at page 20, line 30 skipping to change at page 24, line 30
HTTP/1.1 200 OK HTTP/1.1 200 OK
The server removed the binding named "foo.html" from the collection, The server removed the binding named "foo.html" from the collection,
"http://www.example.com/CollX". A request to the resource named "http://www.example.com/CollX". A request to the resource named
"http://www.example.com/CollX/foo.html" will return a 404 (Not Found) "http://www.example.com/CollX/foo.html" will return a 404 (Not Found)
response. response.
6. REBIND Method 6. REBIND Method
The REBIND method removes a binding to a resource from the collection The REBIND method removes a binding to a resource from a collection,
identified by the Request-URI, and adds a binding to that resource and adds a binding to that resource into the collection identified by
into another collection. The request body specifies the binding to the Request-URI. The request body specifies the binding to be added
be removed (segment) and the new binding to be created (href). It is (segment) and the old binding to be removed (href). It is
effectively an atomic form of a MOVE request. effectively an atomic form of a MOVE request, and MUST be treated the
same way as MOVE for the purpose of determining access permissions.
This method is unsafe and idempotent (see [RFC2616], section 9.1). If a REBIND request fails, the server state preceding the request
MUST be restored. This method is unsafe and idempotent (see
[RFC2616], section 9.1).
Marshalling: Marshalling:
The request MAY include an Overwrite header. The request MAY include an Overwrite header.
The request body MUST be a DAV:rebind XML element. The request body MUST be a DAV:rebind XML element.
<!ELEMENT rebind (segment, href)> <!ELEMENT rebind (segment, href)>
If the request succeeds, the server MUST return 201 (Created) when If the request succeeds, the server MUST return 201 (Created) when
skipping to change at page 28, line 25 skipping to change at page 32, line 25
Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun,
Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa
Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Joe
Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Hildebrand, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris
Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel Kaler, Manoj Kasichainula, Rohit Khare, Brian Korver, Daniel
LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,
John Stracke, John Tigue, John Turner, Kevin Wiggen, and other John Stracke, John Tigue, John Turner, Kevin Wiggen, and other
members of the WebDAV working group. members of the WebDAV working group.
13 Normative References 13. References
13.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring -- Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999. WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
skipping to change at page 29, line 5 skipping to change at page 32, line 50
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC-xml-20040204, February 2004, Edition)", W3C REC-xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>. <http://www.w3.org/TR/2004/REC-xml-20040204>.
[draft-fielding-rfc2396bis] [draft-fielding-rfc2396bis]
Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", ID Resource Identifier (URI): Generic Syntax", ID
draft-fielding-rfc2396bis-07, September 2004. draft-fielding-rfc2396bis-07, September 2004.
13.2 Informative References
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
Whitehead, "Versioning Extensions to WebDAV (Web
Distributed Authoring and Versioning)", RFC 3253, March
2002.
Authors' Addresses Authors' Addresses
Geoffrey Clemm Geoffrey Clemm
IBM IBM
20 Maguire Road 20 Maguire Road
Lexington, MA 02421 Lexington, MA 02421
EMail: geoffrey.clemm@us.ibm.com EMail: geoffrey.clemm@us.ibm.com
Jason Crawford Jason Crawford
skipping to change at page 30, line 38 skipping to change at page 34, line 41
"specify_safeness_and_idempotence" and "ED_rfc2026_ref". "specify_safeness_and_idempotence" and "ED_rfc2026_ref".
A.6 Since draft-ietf-webdav-bind-07 A.6 Since draft-ietf-webdav-bind-07
Add more index items (no change tracking). Add and resolve issues Add more index items (no change tracking). Add and resolve issues
"2.3_copy_to_same", "bind_properties", "bind_vs_ACL", "2.3_copy_to_same", "bind_properties", "bind_vs_ACL",
"6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML "6_rebind_intro" and "rfc2396bis" (actually an action item). Fix XML
DTD fragment in section 3.3. Make spelling of "Request-URI" DTD fragment in section 3.3. Make spelling of "Request-URI"
consistent. consistent.
A.7 Since draft-ietf-webdav-bind-08
Resolved editorial issues raised by Jim Whitehead in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>. Add and resolve issues "atomicity", "2_allow_destroy",
"2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks",
"2.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops",
"2.6_resource-id_vs_versions", "3.2_example" and
"6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open
and resolve "6_rebind_intro".
Appendix B. Resolved issues (to be removed by RFC Editor before Appendix B. Resolved issues (to be removed by RFC Editor before
publication) publication)
Issues that were either rejected or resolved in this version of this Issues that were either rejected or resolved in this version of this
document. document.
B.1 rfc2396bis B.1 2_allow_destroy
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): The language here would preclude the
future definition of a DESTROY method which had the semantics of
removing the state of a resource from a server, irregardless of any
containment relationships that may hold it. Such a method could be
quite useful for records management functionality, in order to
implement a records disposition policy that specified deletion at a
certain time. My recommended tweak to the language of section 2 is
minor: add the following sentence to the end of the paragraph: "It is
permissible, however, for future method definitions (e.g., a DESTROY
method) to have semantics that remove all bindings and/or immediately
reclaim system resources."
Resolution (2004-11-30): Agreed to add statement about methods that
explicitly have that semantics.
B.2 2.1_separate_loop_discussion
Type: edit Type: edit
julian.reschke@greenbytes.de (2004-10-21): Update references to <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
RFC2396 with draft-fielding-uri-rfc2396bis-07. ml>
Resolution (2004-11-06): Done. ejw@cs.ucsc.edu (2004-11-29): I think it would be more clear to
separate out the discussion of loops and bindings, and make it a
separate section (say, 2.2) This issue comes up frequently enough
that it would be good to make it easy to find this issue in the TOC.
Also, a mention of the Already Reported status code would be good to
have here, since it also mentions 506.
B.2 bind_vs_ACL Resolution (2004-11-30): Agreed to move 1st paragraph into separate
subsection.
Type: change B.3 2.1.1_bind_loops_vs_locks
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0149.ht Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0217.ht
ml> ml>
lisa@osafoundation.org (2004-03-24): What permissions are required in ejw@cs.ucsc.edu (2004-12-03): ...The other is the semantics of the
order to perform a BIND request? I would think that permissions for lock operation in the presence of loopback bindings. I think the
UNBIND and REBIND are identical to permissions for DELETE and MOVE handling of If headers is relatively straightforward. The semantics
respectively, but this should be stated. of locking are not....
Resolution (2004-10-16): BIND and UNBIND are controlled by the Resolution (2004-12-09): After some discussion, the working group
privileges DAV:bind and DAV:unbind. REBIND is an atomic form of agreed that we don't want to define special semantics for
MOVE, those the same privileges apply. The authors feel that this depth:infinity locks, thus the standard lock sematics apply (see
does not need to be explicitly stated (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0271.htm
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0150.htm
l). l).
B.3 bind_properties B.4 2.3_copy_depth_infinity
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.ht <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml> ml>
lisa@osafoundation.org (2004-03-24): (Issues with BIND semantics vs ejw@cs.ucsc.edu (2004-11-29): This section doesn't clearly address
servers that compute properties based on request-URI, see the semantics of COPY with Depth infinity. My recommendation is to
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.htm add, after paragraph 3, text like this: "As specified in [RFC2518], a
l and COPY with Depth infinity causes the collection resource to be
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0154.htm duplicated, all of its bound children to be duplicated, and their
children's bound children, and so on, to the bottom of the
containment hierarchy. All of the segments of the bindings of the
destination collection are the same as for the destination
collection. However, the destination resource for all bindings in
the destination collection are different from those of the source
collection, since all resources have been duplicated, creating new
resources with distinct DAV:resource-id properties."
Resolution (2004-12-02): Example added.
B.5 2.3_copy_vs_loops
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): There should also be some text
addressing COPY depth infinity and loops -- in some instances during
a COPY with Depth infinity, the server really wants to recreate the
binding that causes the loop, rather than continuing to make
duplicate resources. This is somewhat addressed by the final
paragraph in Section 2.3, but not exactly.
Resolution (2004-12-02): Can be closed after copy/depth:infinity
example was added (see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0181.htm
l). l).
Resolution (2004-10-16): The authors feel that in the WebDAV data B.6 2.3_copy_example
model, properties are part of the state of the resource, thus should
not vary on request URI. A server that implements properties as
state of a binding instead of the resource to which it binds would be
inherently incompatible with both WebDAV and BIND semantics. It's
unclear why this would matter - a server that can't implement BIND
semantics simply can't support this specification (likely for more Type: change
reasons than this one). See also summary at
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0022.htm
l.
B.4 2.3_copy_to_same <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): It might make sense to create an
example covering the situation described in the final paragraph of
Section 2.3. I'm not 100% sure I know what scenario this paragraph
addresses, other reading the spec. for the first time would
presumably have a tougher time.
Resolution (2004-12-02): Example added.
B.7 2.6_resource-id_vs_versions
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0140.ht
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml> ml>
lisa@osafoundation.org (2004-03-24): When a user does a COPY or MOVE ejw@cs.ucsc.edu (2004-11-29): There needs to be some discussion on
from one binding to another binding to the same resource, this should the interactions of DAV:resource-id and versioning. As near as I can
be flagged as an error. Since this has to interoperate with existing tell, the intent is that every revision will have a unique
clients that won't look at the error body, the status code would have DAV:resource-id value.
to stand alone. 409 is already used for non-existent parent
collections, so that can't be reused. Possibly 403 which in 2518 for
COPY means "_ The source and destination URIs are the same."
Resolution (2004-10-16): Copying/moving to a binding identifying the Resolution (2004-12-01): Mention in an example.
same resource is harmless (see explanation in
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0143.htm
l) and does not need to be rejected by the server.
B.5 6_rebind_intro B.8 3.2_example
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): I think it would be helpful to have an
example of this property. I'd be happy to help develop such an
example.
Resolution (2004-11-30): Example added, including diagram.
B.9 atomicity
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): The intent of the BIND method is for
its behavior to be atomic. However, this is never actually stated
explicitly in the specification. Seems like it should be.
Resolution (2004-11-30): Agreed. Steal text from RFC3253 (applies to
all method definitions).
B.10 6_rebind_intro
Type: edit Type: edit
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0044.ht <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0044.ht
ml> ml>
ejw@cs.ucsc.edu (2004-11-12): I'm reading through the BIND ejw@cs.ucsc.edu (2004-11-12): I'm reading through the BIND
specification, and the description of the REBIND method's operands is specification, and the description of the REBIND method's operands is
a bit unclear to me. I'm assuming the intent is similar to BIND and a bit unclear to me. I'm assuming the intent is similar to BIND and
UNBIND, each of which clearly state in the first sentence what role UNBIND, each of which clearly state in the first sentence what role
the Request-URI, segment, and href fields play. In my reading I just the Request-URI, segment, and href fields play. In my reading I just
jumped right into the spec. at this method (typical reference jumped right into the spec. at this method (typical reference
reading pattern), and hence I didn't initially see the similarity reading pattern), and hence I didn't initially see the similarity
with the BIND and UNBIND method operands. with the BIND and UNBIND method operands.
Resolution (2004-11-12): Agreed and fixed. Resolution (2004-12-02): Agreed and fixed (fixed again after it was
broken in -08).
B.11 6_rebind_premissions
Type: edit
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0218.ht
ml>
ejw@cs.ucsc.edu (2004-12-03): I agree with Lisa that the access
control implications of REBIND should be made explicit. My
suggestion is to add the following language to Section 6. Change:
"It is effectively an atomic form of a MOVE request." To: "It is
effectively an atomic form of a MOVE request, and MUST be treated as
a MOVE for the purpose of determining access permissions (see RFC
3744, Appendix B)."
Resolution (2004-12-03): Make that statement, but avoid the
unnecessary normative reference to RFC3744.
Appendix C. Open issues (to be removed by RFC Editor prior to Appendix C. Open issues (to be removed by RFC Editor prior to
publication) publication)
C.1 edit C.1 edit
Type: edit Type: edit
julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for
editorial fixes/enhancements. editorial fixes/enhancements.
C.2 2.6_when_do_ids_change
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): Change "must not" to "MUST NOT" (and
eliminate the "For example" at the start of the sentence -- perhaps
change to "Specifically,"
julian.reschke@greenbytes.de (2004-11-30): Fix language, replace MOVE
by REBIND (because MOVE may be implemented as COPY/DELETE). Unclear
whether we need more changes.
Index Index
2 2
208 Already Reported (status code) 23 208 Already Reported (status code) 27
5 5
506 Loop Detected (status code) 25 506 Loop Detected (status code) 29
B B
BIND method 16 BIND method 19
Binding 7 Binding 7
C C
Collection 7 Collection 7
Condition Names Condition Names
DAV:bind-into-collection (pre) 17 DAV:bind-into-collection (pre) 20
DAV:bind-source-exists (pre) 17 DAV:bind-source-exists (pre) 20
DAV:binding-allowed (pre) 17 DAV:binding-allowed (pre) 20
DAV:binding-deleted (post) 19, 22 DAV:binding-deleted (post) 23, 26
DAV:can-overwrite (pre) 17, 21 DAV:can-overwrite (pre) 21, 25
DAV:cross-server-binding (pre) 17, 21 DAV:cross-server-binding (pre) 21, 25
DAV:cycle-allowed (pre) 17, 21 DAV:cycle-allowed (pre) 21, 25
DAV:lock-deleted (post) 19, 22 DAV:lock-deleted (post) 23, 26
DAV:locked-overwrite-allowed (pre) 17 DAV:locked-overwrite-allowed (pre) 21
DAV:locked-source-collection-update-allowed (pre) 21 DAV:locked-source-collection-update-allowed (pre) 25
DAV:locked-update-allowed (pre) 17, 19, 21 DAV:locked-update-allowed (pre) 21, 23, 25
DAV:name-allowed (pre) 17, 21 DAV:name-allowed (pre) 21, 25
DAV:new-binding (post) 18, 22 DAV:new-binding (post) 21, 26
DAV:protected-source-url-deletion-allowed (pre) 21 DAV:protected-source-url-deletion-allowed (pre) 26
DAV:protected-url-deletion-allowed (pre) 19 DAV:protected-url-deletion-allowed (pre) 23
DAV:protected-url-modification-allowed (pre) 21 DAV:protected-url-modification-allowed (pre) 25
DAV:rebind-into-collection (pre) 21 DAV:rebind-from-collection (pre) 25
DAV:rebind-source-exists (pre) 21 DAV:rebind-source-exists (pre) 25
DAV:unbind-from-collection (pre) 19 DAV:unbind-from-collection (pre) 23
DAV:unbind-source-exists (pre) 19 DAV:unbind-source-exists (pre) 23
D D
DAV header DAV header
compliance class 'bind' 26 compliance class 'bind' 30
DAV:bind-into-collection precondition 17 DAV:bind-into-collection precondition 20
DAV:bind-source-exists precondition 17 DAV:bind-source-exists precondition 20
DAV:binding-allowed precondition 17 DAV:binding-allowed precondition 20
DAV:binding-deleted postcondition 19, 22 DAV:binding-deleted postcondition 23, 26
DAV:can-overwrite precondition 17, 21 DAV:can-overwrite precondition 21, 25
DAV:cross-server-binding precondition 17, 21 DAV:cross-server-binding precondition 21, 25
DAV:cycle-allowed precondition 17, 21 DAV:cycle-allowed precondition 21, 25
DAV:lock-deleted postcondition 19, 22 DAV:lock-deleted postcondition 23, 26
DAV:locked-overwrite-allowed precondition 17 DAV:locked-overwrite-allowed precondition 21
DAV:locked-source-collection-update-allowed precondition 21 DAV:locked-source-collection-update-allowed precondition 25
DAV:locked-update-allowed precondition 17, 19, 21 DAV:locked-update-allowed precondition 21, 23, 25
DAV:name-allowed precondition 17, 21 DAV:name-allowed precondition 21, 25
DAV:new-binding postcondition 18, 22 DAV:new-binding postcondition 21, 26
DAV:parent-set property 15 DAV:parent-set property 18
DAV:protected-source-url-deletion-allowed precondition 21 DAV:protected-source-url-deletion-allowed precondition 26
DAV:protected-url-deletion-allowed precondition 19 DAV:protected-url-deletion-allowed precondition 23
DAV:protected-url-modification-allowed precondition 21 DAV:protected-url-modification-allowed precondition 25
DAV:rebind-into-collection precondition 21 DAV:rebind-from-collection precondition 25
DAV:rebind-source-exists precondition 21 DAV:rebind-source-exists precondition 25
DAV:resource-id property 15 DAV:resource-id property 17
DAV:unbind-from-collection precondition 19 DAV:unbind-from-collection precondition 23
DAV:unbind-source-exists precondition 19 DAV:unbind-source-exists precondition 23
I I
Internal Member URI 7 Internal Member URI 7
M M
Methods Methods
BIND 16 BIND 19
REBIND 20 REBIND 24
UNBIND 18 UNBIND 22
P P
Path Segment 7 Path Segment 7
Properties Properties
DAV:parent-set 15 DAV:parent-set 18
DAV:resource-id 15 DAV:resource-id 17
R R
REBIND method 20 REBIND method 24
S S
Status Codes Status Codes
208 Already Reported 23 208 Already Reported 27
506 Loop Detected 25 506 Loop Detected 29
U U
UNBIND method 18 UNBIND method 22
URI Mapping 6 URI Mapping 6
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/