draft-ietf-webdav-bind-09.txt   draft-ietf-webdav-bind-10.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: June 9, 2005 IBM Research Expires: July 6, 2005 IBM Research
J. Reschke J. Reschke
greenbytes greenbytes
J. Whitehead J. Whitehead
U.C. Santa Cruz U.C. Santa Cruz
December 9, 2004 January 5, 2005
Binding Extensions to Web Distributed Authoring and Versioning Binding Extensions to Web Distributed Authoring and Versioning
(WebDAV) (WebDAV)
draft-ietf-webdav-bind-09 draft-ietf-webdav-bind-10
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 42 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 June 9, 2005. This Internet-Draft will expire on July 6, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
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.
Servers are required to insure the integrity of any bindings that Servers are required to insure the integrity of any bindings that
they allow to be created. they allow to be created.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . 9
2.1.1 Bind loops . . . . . . . . . . . . . . . . . . . . . . 10 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.3.1 Example: COPY with 'Depth: infinity' in presence 2.3.1 Example: COPY with 'Depth: infinity' in presence
of bind loops . . . . . . . . . . . . . . . . . . . . 12 of bind loops . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Example: COPY with 'Depth: infinity' with multiple 2.3.2 Example: COPY with 'Depth: infinity' with multiple
bindings to a leaf resource . . . . . . . . . . . . . 14 bindings to a leaf resource . . . . . . . . . . . . . 14
2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . 15
2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . 15
2.6 Determining Whether Two Bindings Are to the Same 2.6 PROPFIND and Bindings . . . . . . . . . . . . . . . . . . 16
2.7 Determining Whether Two Bindings Are to the Same
Resource . . . . . . . . . . . . . . . . . . . . . . . . . 16 Resource . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Discovering the Bindings to a Resource . . . . . . . . . . 17 2.8 Discovering the Bindings to a Resource . . . . . . . . . . 17
3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 17 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . 18
3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 18 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . 18
3.2.1 Example for DAV:parent-set property . . . . . . . . . 18 3.2.1 Example for DAV:parent-set property . . . . . . . . . 18
4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 22 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . 22
5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 22 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 24 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . 24
6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 26 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . 26
7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 27 6.2 Example: REBIND in presence of locks and bind loops . . . 27
7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 27 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 29
7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 27 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . 29
7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 29 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . 30
7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 29 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . 31
8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 30 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 32
8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 30 8. Capability discovery . . . . . . . . . . . . . . . . . . . . . 32
8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 30 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . 32
8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 30 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . 32
8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 30 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . 33
9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 33
9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 31 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 33
9.4 Private Locations May Be Revealed . . . . . . . . . . . . 31 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . 33
9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 31 9.4 Private Locations May Be Revealed . . . . . . . . . . . . 34
10. Internationalization Considerations . . . . . . . . . . . . 31 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 10. Internationalization Considerations . . . . . . . . . . . . 34
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.2 Informative References . . . . . . . . . . . . . . . . . . . 32 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 13.2 Informative References . . . . . . . . . . . . . . . . . . . 35
A. Change Log (to be removed by RFC Editor before publication) . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 33 A. Change Log (to be removed by RFC Editor before publication) . 36
A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 34 A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 36
A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 34 A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 36
A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 34 A.3 Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 36
A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 34 A.4 Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 37
A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 34 A.5 Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 37
A.7 Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 34 A.6 Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 37
A.7 Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 37
A.8 Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 37
B. Resolved issues (to be removed by RFC Editor before B. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 35 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.1 2_allow_destroy . . . . . . . . . . . . . . . . . . . . . 35 B.1 uri_draft_ref . . . . . . . . . . . . . . . . . . . . . . 37
B.2 2.1_separate_loop_discussion . . . . . . . . . . . . . . . 35 B.2 2.6_bindings_vs_properties . . . . . . . . . . . . . . . . 38
B.3 2.1.1_bind_loops_vs_locks . . . . . . . . . . . . . . . . 35 B.3 2.6_when_do_ids_change . . . . . . . . . . . . . . . . . . 38
B.4 2.3_copy_depth_infinity . . . . . . . . . . . . . . . . . 36 B.4 6.1_rebind_vs_locks . . . . . . . . . . . . . . . . . . . 38
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) . . . . . . . . . . . . . . . . . . . . . . . . . 39 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 39
C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
C.2 2.6_when_do_ids_change . . . . . . . . . . . . . . . . . . 39 C.2 3.1_uuids . . . . . . . . . . . . . . . . . . . . . . . . 39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 42 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
skipping to change at page 7, line 16 skipping to change at page 7, line 16
items that are not network retrievable, as well as those that are, items that are not network retrievable, as well as those that are,
it is possible for a resource to have zero, one, or many URI it is possible for a resource to have zero, one, or many URI
mappings. Mapping a resource to an "http" scheme URI makes it mappings. Mapping a resource to an "http" scheme URI makes it
possible to submit HTTP protocol requests to the resource using possible to submit HTTP protocol requests to the resource using
the URI. the URI.
Path Segment Path Segment
Informally, the characters found between slashes ("/") in a URI. Informally, the characters found between slashes ("/") in a URI.
Formally, as defined in section 3.3 of Formally, as defined in section 3.3 of
[draft-fielding-rfc2396bis]. [draft-fielding-uri-rfc2396bis].
Binding Binding
A relation between a single path segment (in a collection) and a A relation between a single path segment (in a collection) and a
resource. A binding is part of the state of a collection. If two resource. A binding is part of the state of a collection. If two
different collections contain a binding between the same path different collections contain a binding between the same path
segment and the same resource, these are two distinct bindings. segment and the same resource, these are two distinct bindings.
So for a collection C, a path segment S, and a resource R, the So for a collection C, a path segment S, and a resource R, the
binding can be thought of as C:(S -> R). Bindings create URI binding can be thought of as C:(S -> R). Bindings create URI
mappings, and hence allow requests to be sent to a single resource mappings, and hence allow requests to be sent to a single resource
skipping to change at page 16, line 41 skipping to change at page 16, line 41
>> After Request: >> After Request:
URI-1 URI-2 URI-X URI-1 URI-2 URI-X
| | | | | |
| | | <---- URI Mappings | | | <---- URI Mappings
| | | | | |
+---------------------+ +---------------------+
| Resource R | | Resource R |
+---------------------+ +---------------------+
2.6 Determining Whether Two Bindings Are to the Same Resource 2.6 PROPFIND and Bindings
Consistent with [RFC2518] the value of a dead property MUST be, and
the value of a live property SHOULD be, independent of the number of
bindings to its host resource or of the path submitted to PROPFIND.
2.7 Determining Whether Two Bindings Are to the Same Resource
It is useful to have some way of determining whether two bindings are It is useful to have some way of determining whether two bindings are
to the same resource. Two resources might have identical contents to the same resource. Two resources might have identical contents
and properties, but not be the same resource (e.g. an update to one and properties, but not be the same resource (e.g. an update to one
resource does not affect the other resource). resource does not affect the other resource).
The REQUIRED DAV:resource-id property defined in Section 3.1 is a The REQUIRED DAV:resource-id property defined in Section 3.1 is a
resource identifier, which MUST be unique across all resources for resource identifier, which MUST be unique across all resources for
all time. If the values of DAV:resource-id returned by PROPFIND all time. If the values of DAV:resource-id returned by PROPFIND
requests through two bindings are identical character by character, requests through two bindings are identical character by character,
skipping to change at page 17, line 27 skipping to change at page 17, line 33
CHECKIN (see [RFC3253], section 4.4) must assign a new, unique value CHECKIN (see [RFC3253], section 4.4) must assign a new, unique value
to the DAV:resource-id property of the new resource they create. 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. Specifically, not change the value of its DAV:resource-id property. Specifically,
a 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 REBIND, 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.8 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 9.4 and 9.5. Sections 9.4 and 9.5.
skipping to change at page 18, line 30 skipping to change at page 18, line 36
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. collection.
<!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-uri-rfc2396bis] -->
3.2.1 Example for DAV:parent-set property 3.2.1 Example for DAV:parent-set property
For example, if collection C1 is mapped to both /CollX and /CollY, 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 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 [/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 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, 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, R1 (i.e. both [/CollX, x.gif] and [/CollX, y.gif] or, alternatively,
both [/CollY, x.gif] and [/CollY, y.gif]). both [/CollY, x.gif] and [/CollY, y.gif]).
skipping to change at page 27, line 6 skipping to change at page 27, line 6
"http://www.example.com/CollX", associating "foo.html" with the "http://www.example.com/CollX", associating "foo.html" with the
resource identified by the URI resource identified by the URI
"http://www.example.com/CollY/bar.html", and removes the binding "http://www.example.com/CollY/bar.html", and removes the binding
named "bar.html" from the collection identified by the URI named "bar.html" from the collection identified by the URI
"http://www.example.com/CollY". Clients can now use the URI "http://www.example.com/CollY". Clients can now use the URI
"http://www.example.com/CollX/foo.html" to submit requests to that "http://www.example.com/CollX/foo.html" to submit requests to that
resource, and requests on the URI resource, and requests on the URI
"http://www.example.com/CollY/bar.html" will fail with a 404 (Not "http://www.example.com/CollY/bar.html" will fail with a 404 (Not
Found) response. Found) response.
6.2 Example: REBIND in presence of locks and bind loops
To illustrate the effects of locks and bind loops on a REBIND
operation, consider the following collection:
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |<--------+
| LOCKED infinity | |
| (lock token L1) | |
| bindings: | |
| CollX CollY | |
+-------------------------------+ |
| | |
| | (creates loop) |
| | |
+-----------------+ +------------------+ |
| Collection C2 | | Collection C3 | |
| (inherit lock) | | (inherit lock) | |
| (lock token L1) | | (lock token L1) | |
| bindings: | | bindings: | |
| {none} | | y.gif CollZ | |
+-----------------+ +------------------+ |
| | |
| +-----+
|
+---------------------------+
| Resource R2 |
| (lock inherited from C1) |
| (lock token L1) |
+---------------------------+
(where L1 is "opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9").
Note that the binding between CollZ and C1 creates a loop in the
containment hierarchy. Servers are not required to support such
loops, though the server in this example does.
The REBIND request below will remove the segment "CollZ" from C3 and
add a new binding from "CollA" to the collection C2.
REBIND /CollW/CollX HTTP/1.1
Host: www.example.com
If: (<opaquelocktoken:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>)
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:">
<D:segment>CollA</D:segment>
<D:href>/CollW/CollY/CollZ</D:href>
</D:rebind>
The outcome of the REBIND operation is:
+------------------+
| Root Collection |
| bindings: |
| CollW |
+------------------+
|
|
|
+-------------------------------+
| Collection C1 |
| LOCKED infinity |
| (lock token L1) |
| bindings: |
| CollX CollY |
+-------------------------------+
| ^ |
| | |
+-----------------+ | +------------------+
| Collection C2 | | | Collection C3 |
|(inherited lock) | | | (inherited lock) |
|(lock token L1) | | | (lock token L1) |
| bindings: | | | bindings: |
| CollA | | | y.gif |
+-----------------+ | +------------------+
| | |
+---------------+ |
(creates loop) |
+---------------------------+
| Resource R2 |
| (inherited lock from C1) |
| (lock token L1) |
+---------------------------+
7. Additional Status Codes 7. Additional Status Codes
7.1 208 Already Reported 7.1 208 Already Reported
The 208 (Already Reported) status code can be used inside a The 208 (Already Reported) status code can be used inside a
DAV:propstat response element to avoid enumerating the internal DAV:propstat response element to avoid enumerating the internal
members of multiple bindings to the same collection repeatedly. For members of multiple bindings to the same collection repeatedly. For
each binding to a collection inside the request's scope, only one each binding to a collection inside the request's scope, only one
will be reported with a 200 status, while subsequent DAV:response will be reported with a 200 status, while subsequent DAV:response
elements for all other bindings will use the 208 status, and no elements for all other bindings will use the 208 status, and no
skipping to change at page 32, line 45 skipping to change at page 35, line 25
[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
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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-uri-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",
draft-fielding-rfc2396bis-07, September 2004. draft-fielding-uri-rfc2396bis-07 (work in progress),
September 2004.
13.2 Informative References 13.2 Informative References
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
Whitehead, "Versioning Extensions to WebDAV (Web Whitehead, "Versioning Extensions to WebDAV (Web
Distributed Authoring and Versioning)", RFC 3253, March Distributed Authoring and Versioning)", RFC 3253, March
2002. 2002.
Authors' Addresses Authors' Addresses
Geoffrey Clemm Geoffrey Clemm
IBM IBM
20 Maguire Road 20 Maguire Road
Lexington, MA 02421 Lexington, MA 02421
skipping to change at page 35, line 5 skipping to change at page 37, line 36
Resolved editorial issues raised by Jim Whitehead in Resolved editorial issues raised by Jim Whitehead in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>. Add and resolve issues "atomicity", "2_allow_destroy", ml>. Add and resolve issues "atomicity", "2_allow_destroy",
"2.1_separate_loop_discussion", "2.1.1_bind_loops_vs_locks", "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.3_copy_depth_infinity", "2.3_copy_example", "2.3_copy_vs_loops",
"2.6_resource-id_vs_versions", "3.2_example" and "2.6_resource-id_vs_versions", "3.2_example" and
"6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open "6_rebind_premissions". Add issue "2.6_when_do_ids_change". Re-open
and resolve "6_rebind_intro". and resolve "6_rebind_intro".
A.8 Since draft-ietf-webdav-bind-09
Add and resolve issue "6.1_rebind_vs_locks", adding proposed example
text. Add action item "3.1_uuids". Close issue
"2.6_when_do_ids_change". Add and resolve issues
"2.6_bindings_vs_properties" and "uri_draft_ref".
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 2_allow_destroy B.1 uri_draft_ref
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 (2005-01-01): Fix reference to
draft-fielding-uri-rfc2396bis-07
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht B.2 2.6_bindings_vs_properties
ml>
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.
Resolution (2004-11-30): Agreed to move 1st paragraph into separate
subsection.
B.3 2.1.1_bind_loops_vs_locks
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0217.ht
ml>
ejw@cs.ucsc.edu (2004-12-03): ...The other is the semantics of the
lock operation in the presence of loopback bindings. I think the
handling of If headers is relatively straightforward. The semantics
of locking are not....
Resolution (2004-12-09): After some discussion, the working group
agreed that we don't want to define special semantics for
depth:infinity locks, thus the standard lock sematics apply (see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0271.htm
l).
B.4 2.3_copy_depth_infinity
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml>
ejw@cs.ucsc.edu (2004-11-29): This section doesn't clearly address
the semantics of COPY with Depth infinity. My recommendation is to
add, after paragraph 3, text like this: "As specified in [RFC2518], a
COPY with Depth infinity causes the collection resource to be
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).
B.6 2.3_copy_example
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0248.ht
ml> ml>
ejw@cs.ucsc.edu (2004-11-29): It might make sense to create an ejw@cs.ucsc.edu (2004-12-06): I think it would be good to include the
example covering the situation described in the final paragraph of following language in the bind specification: Note that, consistent
Section 2.3. I'm not 100% sure I know what scenario this paragraph with [RFC2518], the value of a dead property is independent of the
addresses, other reading the spec. for the first time would number of bindings to its host resource, and of the path submitted to
presumably have a tougher time. PROPFIND. Since live properties can be aribtrary computational
processes, they MAY vary depending on path or number of bindings, but
SHOULD NOT do this unless the definition of the live property
explicitly includes this dependency. Here I avoided adding new
requirements in areas already covered by 2518, but did add
requirements for the new situation raised by the BIND specification.
Resolution (2004-12-02): Example added. Resolution (2004-12-14): Add that statement (see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0299.htm
l and subsequent messages).
B.7 2.6_resource-id_vs_versions B.3 2.6_when_do_ids_change
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.ht
ml> ml>
ejw@cs.ucsc.edu (2004-11-29): There needs to be some discussion on ejw@cs.ucsc.edu (2004-11-29): Change "must not" to "MUST NOT" (and
the interactions of DAV:resource-id and versioning. As near as I can eliminate the "For example" at the start of the sentence -- perhaps
tell, the intent is that every revision will have a unique change to "Specifically,"
DAV:resource-id value.
Resolution (2004-12-01): Mention in an example.
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 julian.reschke@greenbytes.de (2004-11-30): Fix language, replace MOVE
example of this property. I'd be happy to help develop such an by REBIND (because MOVE may be implemented as COPY/DELETE). Unclear
example. whether we need more changes.
Resolution (2004-11-30): Example added, including diagram. Resolution (2004-12-13): Closed (see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0300.htm
l).
B.9 atomicity B.4 6.1_rebind_vs_locks
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0281.ht
<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
<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-12-09): (Request to add a REBIND example that
specification, and the description of the REBIND method's operands is requires submitting a lock token)
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
the Request-URI, segment, and href fields play. In my reading I just
jumped right into the spec. at this method (typical reference
reading pattern), and hence I didn't initially see the similarity
with the BIND and UNBIND method operands.
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 Resolution (2004-12-21): Example added.
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 C.2 3.1_uuids
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 Type: edit
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 julian.reschke@greenbytes.de (2004-12-11): Action item: if
by REBIND (because MOVE may be implemented as COPY/DELETE). Unclear draft-mealling-uuid-urn gets accepted in time, consider referencing
whether we need more changes. it and using urn:uuid URIs instead of opaquelocktoken URIs. See IETF
I-D Tracker.
Index Index
2 2
208 Already Reported (status code) 27 208 Already Reported (status code) 29
5 5
506 Loop Detected (status code) 29 506 Loop Detected (status code) 32
B B
BIND method 19 BIND method 19
Binding 7 Binding 7
C C
Collection 7 Collection 7
Condition Names Condition Names
DAV:bind-into-collection (pre) 20 DAV:bind-into-collection (pre) 20
DAV:bind-source-exists (pre) 20 DAV:bind-source-exists (pre) 20
skipping to change at page 40, line 43 skipping to change at page 40, line 43
DAV:protected-source-url-deletion-allowed (pre) 26 DAV:protected-source-url-deletion-allowed (pre) 26
DAV:protected-url-deletion-allowed (pre) 23 DAV:protected-url-deletion-allowed (pre) 23
DAV:protected-url-modification-allowed (pre) 25 DAV:protected-url-modification-allowed (pre) 25
DAV:rebind-from-collection (pre) 25 DAV:rebind-from-collection (pre) 25
DAV:rebind-source-exists (pre) 25 DAV:rebind-source-exists (pre) 25
DAV:unbind-from-collection (pre) 23 DAV:unbind-from-collection (pre) 23
DAV:unbind-source-exists (pre) 23 DAV:unbind-source-exists (pre) 23
D D
DAV header DAV header
compliance class 'bind' 30 compliance class 'bind' 32
DAV:bind-into-collection precondition 20 DAV:bind-into-collection precondition 20
DAV:bind-source-exists precondition 20 DAV:bind-source-exists precondition 20
DAV:binding-allowed precondition 20 DAV:binding-allowed precondition 20
DAV:binding-deleted postcondition 23, 26 DAV:binding-deleted postcondition 23, 26
DAV:can-overwrite precondition 21, 25 DAV:can-overwrite precondition 21, 25
DAV:cross-server-binding precondition 21, 25 DAV:cross-server-binding precondition 21, 25
DAV:cycle-allowed precondition 21, 25 DAV:cycle-allowed precondition 21, 25
DAV:lock-deleted postcondition 23, 26 DAV:lock-deleted postcondition 23, 26
DAV:locked-overwrite-allowed precondition 21 DAV:locked-overwrite-allowed precondition 21
DAV:locked-source-collection-update-allowed precondition 25 DAV:locked-source-collection-update-allowed precondition 25
DAV:locked-update-allowed precondition 21, 23, 25 DAV:locked-update-allowed precondition 21, 23, 25
DAV:name-allowed precondition 21, 25 DAV:name-allowed precondition 21, 25
DAV:new-binding postcondition 21, 26 DAV:new-binding postcondition 21, 26
DAV:parent-set property 18 DAV:parent-set property 18
DAV:protected-source-url-deletion-allowed precondition 26 DAV:protected-source-url-deletion-allowed precondition 26
DAV:protected-url-deletion-allowed precondition 23 DAV:protected-url-deletion-allowed precondition 23
DAV:protected-url-modification-allowed precondition 25 DAV:protected-url-modification-allowed precondition 25
DAV:rebind-from-collection precondition 25 DAV:rebind-from-collection precondition 25
DAV:rebind-source-exists precondition 25 DAV:rebind-source-exists precondition 25
DAV:resource-id property 17 DAV:resource-id property 18
DAV:unbind-from-collection precondition 23 DAV:unbind-from-collection precondition 23
DAV:unbind-source-exists precondition 23 DAV:unbind-source-exists precondition 23
I I
Internal Member URI 7 Internal Member URI 7
M M
Methods Methods
BIND 19 BIND 19
REBIND 24 REBIND 24
UNBIND 22 UNBIND 22
P P
Path Segment 7 Path Segment 7
Properties Properties
DAV:parent-set 18 DAV:parent-set 18
DAV:resource-id 17 DAV:resource-id 18
R R
REBIND method 24 REBIND method 24
S S
Status Codes Status Codes
208 Already Reported 27 208 Already Reported 29
506 Loop Detected 29 506 Loop Detected 32
U U
UNBIND method 22 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
skipping to change at page 42, line 41 skipping to change at page 42, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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