draft-ietf-webdav-bind-21.txt   draft-ietf-webdav-bind-22.txt 
Network Working Group G. Clemm Network Working Group G. Clemm
Internet-Draft IBM Internet-Draft IBM
Updates: 4918 (if approved) J. Crawford Updates: 4918 (if approved) J. Crawford
Intended status: Standards Track IBM Research Intended status: Standards Track IBM Research
Expires: April 6, 2009 J. Reschke, Ed. Expires: May 1, 2009 J. Reschke, Ed.
greenbytes greenbytes
J. Whitehead J. Whitehead
U.C. Santa Cruz U.C. Santa Cruz
October 3, 2008 October 28, 2008
Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
draft-ietf-webdav-bind-21 draft-ietf-webdav-bind-22
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 6, 2009. This Internet-Draft will expire on May 1, 2009.
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 11 skipping to change at page 3, line 11
6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 29 6.2. Example: REBIND in Presence of Locks and Bind Loops . . . 29
7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31 7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 31
7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31 7.1. 208 Already Reported . . . . . . . . . . . . . . . . . . . 31
7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32 7.1.1. Example: PROPFIND by Bind-Aware Client . . . . . . . . 32
7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34 7.1.2. Example: PROPFIND by Non-Bind-Aware Client . . . . . . 34
7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34 7.2. 506 Loop Detected . . . . . . . . . . . . . . . . . . . . 34
8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34 8. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 34
8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34 8.1. OPTIONS Method . . . . . . . . . . . . . . . . . . . . . . 34
8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34 8.2. 'DAV' Request Header . . . . . . . . . . . . . . . . . . . 34
9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35 9. Relationship to WebDAV Access Control Protocol . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10. Relationship to Versioning Extensions to WebDAV . . . . . . . 35
10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 35 11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . 38
10.3. Bindings, and Denial of Service . . . . . . . . . . . . . 35 11.2. Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . 38
10.4. Private Locations May Be Revealed . . . . . . . . . . . . 36 11.3. Bindings, and Denial of Service . . . . . . . . . . . . . 38
10.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 36 11.4. Private Locations May Be Revealed . . . . . . . . . . . . 38
11. Internationalization Considerations . . . . . . . . . . . . . 36 11.5. DAV:parent-set and Denial of Service . . . . . . . . . . . 38
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. Internationalization Considerations . . . . . . . . . . . . . 38
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . . 37 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Clarification to RFC2518bis' Usage of the term Appendix A. Clarification to RFC2518bis' Usage of the term
'lock root' . . . . . . . . . . . . . . . . . . . . . 37 'lock root' . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 38
B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 38
B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 38
B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 38
B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 39
B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 39
B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 39
B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 39
B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 39
B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 39
B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 40
B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 40
B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 40
B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 40
B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 41
B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 41
B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 41
B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 41
B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 41
B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 41
Appendix C. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 41 publication) . . . . . . . . . . . . . . . . . . . . 41
C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.1. Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . 41
C.2. status-codes . . . . . . . . . . . . . . . . . . . . . . . 42 B.2. Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . 41
C.3. relation-to-deltav . . . . . . . . . . . . . . . . . . . . 42 B.3. Since draft-ietf-webdav-bind-04 . . . . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 B.4. Since draft-ietf-webdav-bind-05 . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 B.5. Since draft-ietf-webdav-bind-06 . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 46 B.6. Since draft-ietf-webdav-bind-07 . . . . . . . . . . . . . 41
B.7. Since draft-ietf-webdav-bind-08 . . . . . . . . . . . . . 42
B.8. Since draft-ietf-webdav-bind-09 . . . . . . . . . . . . . 42
B.9. Since draft-ietf-webdav-bind-10 . . . . . . . . . . . . . 42
B.10. Since draft-ietf-webdav-bind-11 . . . . . . . . . . . . . 42
B.11. Since draft-ietf-webdav-bind-12 . . . . . . . . . . . . . 42
B.12. Since draft-ietf-webdav-bind-13 . . . . . . . . . . . . . 43
B.13. Since draft-ietf-webdav-bind-14 . . . . . . . . . . . . . 43
B.14. Since draft-ietf-webdav-bind-15 . . . . . . . . . . . . . 43
B.15. Since draft-ietf-webdav-bind-16 . . . . . . . . . . . . . 43
B.16. Since draft-ietf-webdav-bind-17 . . . . . . . . . . . . . 43
B.17. Since draft-ietf-webdav-bind-18 . . . . . . . . . . . . . 44
B.18. Since draft-ietf-webdav-bind-19 . . . . . . . . . . . . . 44
B.19. Since draft-ietf-webdav-bind-20 . . . . . . . . . . . . . 44
B.20. Since draft-ietf-webdav-bind-21 . . . . . . . . . . . . . 44
Appendix C. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . . 44
C.1. status-codes . . . . . . . . . . . . . . . . . . . . . . . 44
C.2. relation-to-deltav . . . . . . . . . . . . . . . . . . . . 45
Appendix D. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 45
D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
This specification extends the WebDAV Distributed Authoring Protocol This specification extends the WebDAV Distributed Authoring Protocol
([RFC4918]) to enable clients to create new access paths to existing ([RFC4918]) to enable clients to create new access paths to existing
resources. This capability is useful for several reasons: resources. 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 19, line 32 skipping to change at page 19, line 32
2.8. 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 10.4 and 10.5. Sections 11.4 and 11.5.
3. Properties 3. Properties
The bind feature introduces the properties defined below. The bind feature introduces the properties defined below.
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 22, line 32 skipping to change at page 22, line 32
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
a new binding was created and 200 (OK) when an existing binding a new binding was created and 200 (OK) or 204 (No Content) when an
was replaced. existing binding was replaced.
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:bind-response XML element. Note that this document does be a DAV:bind-response XML element. Note that this document does
not define any elements for the BIND response body, but the DAV: not define any elements for the BIND response body, but the DAV:
bind-response element is defined to ensure interoperability bind-response element is defined to ensure interoperability
between future extensions that do define elements for the BIND between future extensions that do define elements for the BIND
response body. response body.
<!ELEMENT bind-response ANY> <!ELEMENT bind-response ANY>
skipping to change at page 24, line 12 skipping to change at page 24, line 12
body, to the resource identified by the DAV:href element in the body, to the resource identified by the DAV:href element in the
request body. request body.
4.1. Example: BIND 4.1. Example: BIND
>> Request: >> Request:
BIND /CollY HTTP/1.1 BIND /CollY HTTP/1.1
Host: www.example.com Host: www.example.com
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 172
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:bind xmlns:D="DAV:"> <D:bind xmlns:D="DAV:">
<D:segment>bar.html</D:segment> <D:segment>bar.html</D:segment>
<D:href>http://www.example.com/CollX/foo.html</D:href> <D:href>http://www.example.com/CollX/foo.html</D:href>
</D:bind> </D:bind>
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
Location: http://www.example.com/CollY/bar.html
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 Request- The UNBIND method modifies the collection identified by the Request-
skipping to change at page 25, line 4 skipping to change at page 25, line 8
If an UNBIND request fails, the server state preceding the request If an UNBIND request fails, the server state preceding the request
MUST be restored. This method is unsafe and idempotent (see MUST be restored. This method is unsafe and idempotent (see
[RFC2616], Section 9.1). [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
binding was successfully deleted. If the request succeeds, the server MUST return 200 (OK) or 204
(No Content) when the 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.
<!ELEMENT unbind-response ANY> <!ELEMENT unbind-response ANY>
skipping to change at page 26, line 12 skipping to change at page 26, line 12
request body was protected by a write-lock at the time of the request body was protected by a write-lock at the time of the
request, that write-lock must have been deleted by the request. request, that write-lock must have been deleted by the request.
5.1. Example: UNBIND 5.1. Example: UNBIND
>> Request: >> Request:
UNBIND /CollX HTTP/1.1 UNBIND /CollX HTTP/1.1
Host: www.example.com Host: www.example.com
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 117
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:unbind xmlns:D="DAV:"> <D:unbind xmlns:D="DAV:">
<D:segment>foo.html</D:segment> <D:segment>foo.html</D:segment>
</D:unbind> </D:unbind>
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
skipping to change at page 26, line 50 skipping to change at page 26, line 50
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
a new binding was created and 200 (OK) when an existing binding a new binding was created and 200 (OK) or 204 (No Content) when an
was replaced. existing binding was replaced.
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:rebind-response XML element. Note that this document be a DAV:rebind-response XML element. Note that this document
does not define any elements for the REBIND response body, but the does not define any elements for the REBIND response body, but the
DAV:rebind-response element is defined to ensure interoperability DAV:rebind-response element is defined to ensure interoperability
between future extensions that do define elements for the REBIND between future extensions that do define elements for the REBIND
response body. response body.
<!ELEMENT rebind-response ANY> <!ELEMENT rebind-response ANY>
skipping to change at page 28, line 36 skipping to change at page 28, line 36
the request, that write-lock must have been deleted by the the request, that write-lock must have been deleted by the
request. request.
6.1. Example: REBIND 6.1. Example: REBIND
>> Request: >> Request:
REBIND /CollX HTTP/1.1 REBIND /CollX HTTP/1.1
Host: www.example.com Host: www.example.com
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 176
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:"> <D:rebind xmlns:D="DAV:">
<D:segment>foo.html</D:segment> <D:segment>foo.html</D:segment>
<D:href>http://www.example.com/CollY/bar.html</D:href> <D:href>http://www.example.com/CollY/bar.html</D:href>
</D:rebind> </D:rebind>
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
skipping to change at page 30, line 14 skipping to change at page 30, line 14
containment hierarchy. Servers are not required to support such containment hierarchy. Servers are not required to support such
loops, though the server in this example does. loops, though the server in this example does.
The REBIND request below will remove the segment "CollZ" from C3 and The REBIND request below will remove the segment "CollZ" from C3 and
add a new binding from "CollA" to the collection C2. add a new binding from "CollA" to the collection C2.
REBIND /CollW/CollX HTTP/1.1 REBIND /CollW/CollX HTTP/1.1
Host: www.example.com Host: www.example.com
If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>) If: (<urn:uuid:f92d4fae-7012-11ab-a765-00c0ca1f6bf9>)
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 152
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:rebind xmlns:D="DAV:"> <D:rebind xmlns:D="DAV:">
<D:segment>CollA</D:segment> <D:segment>CollA</D:segment>
<D:href>/CollW/CollY/CollZ</D:href> <D:href>/CollW/CollY/CollZ</D:href>
</D:rebind> </D:rebind>
The outcome of the REBIND operation is: The outcome of the REBIND operation is:
+------------------+ +------------------+
| Root Collection | | Root Collection |
skipping to change at page 32, line 37 skipping to change at page 32, line 37
collection C), where the members of /Coll are /Coll/Foo (bound to collection C), where the members of /Coll are /Coll/Foo (bound to
resource R) and /Coll/Bar (bound to collection C). resource R) and /Coll/Bar (bound to collection C).
>> Request: >> Request:
PROPFIND /Coll/ HTTP/1.1 PROPFIND /Coll/ HTTP/1.1
Host: www.example.com Host: www.example.com
Depth: infinity Depth: infinity
DAV: bind DAV: bind
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 152
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop> <D:prop>
<D:displayname/> <D:displayname/>
<D:resource-id/> <D:resource-id/>
</D:prop> </D:prop>
</D:propfind> </D:propfind>
>> Response: >> Response:
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 1241
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"> <D:multistatus xmlns:D="DAV:">
<D:response> <D:response>
<D:href>http://www.example.com/Coll/</D:href> <D:href>http://www.example.com/Coll/</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:displayname>Loop Demo</D:displayname> <D:displayname>Loop Demo</D:displayname>
<D:resource-id> <D:resource-id>
<D:href <D:href
skipping to change at page 34, line 18 skipping to change at page 34, line 18
introduced by this specification. As the "Depth: infinity" PROPFIND introduced by this specification. As the "Depth: infinity" PROPFIND
request would cause a loop condition, the whole request is rejected request would cause a loop condition, the whole request is rejected
with a 506 status. with a 506 status.
>> Request: >> Request:
PROPFIND /Coll/ HTTP/1.1 PROPFIND /Coll/ HTTP/1.1
Host: www.example.com Host: www.example.com
Depth: infinity Depth: infinity
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxx Content-Length: 125
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop> <D:displayname/> </D:prop> <D:prop> <D:displayname/> </D:prop>
</D:propfind> </D:propfind>
>> Response: >> Response:
HTTP/1.1 506 Loop Detected HTTP/1.1 506 Loop Detected
skipping to change at page 35, line 11 skipping to change at page 35, line 11
Clients SHOULD signal support for all MUST level requirements and Clients SHOULD signal support for all MUST level requirements and
REQUIRED features by submitting a "DAV" request header containing the REQUIRED features by submitting a "DAV" request header containing the
compliance class name "bind". In particular, the client MUST compliance class name "bind". In particular, the client MUST
understand the 208 status code defined in Section 7.1. understand the 208 status code defined in Section 7.1.
9. Relationship to WebDAV Access Control Protocol 9. Relationship to WebDAV Access Control Protocol
BIND and REBIND behave the same as MOVE with respect to the DAV:acl BIND and REBIND behave the same as MOVE with respect to the DAV:acl
property (see [RFC3744], Section 7.3). property (see [RFC3744], Section 7.3).
10. Security Considerations 10. Relationship to Versioning Extensions to WebDAV
Servers that implement Workspaces ([RFC3253], Section 6) and Version
Controlled Collections ([RFC3253], Section 14) already need to
implement BIND-like behaviour in order to handle UPDATE and
UNCHECKOUT semantics.
Consider a workspace "/ws1/", containing the version-controlled,
checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
CollY", and a version-controlled resource R, bound to C1 as "/ws1/
CollX/test":
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | |
| test | | |
+---------------+ +---------------+
|
|
|
+------------------+
| Resource R |
+------------------+
Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but
undoing the checkout on C1 will undo part of the MOVE request, thus
restoring the binding from C1 to R, but keeping the new binding from
C2 to R:
>> Request:
MOVE /ws1/CollX/test HTTP/1.1
Host: www.example.com
Destination: /ws1/CollY/test
>> Response:
HTTP/1.1 204 No Content
>> Request:
CHECKIN /ws1/CollY/ HTTP/1.1
Host: www.example.com
>> Response:
HTTP/1.1 201 Created
Cache-Control: no-cache
Location: http://repo.example.com/his/17/ver/42
>> Request:
UNCHECKOUT /ws1/CollX/ HTTP/1.1
Host: www.example.com
>> Response:
HTTP/1.1 200 OK
Cache-Control: no-cache
As a result, both C1 and C2 would have a binding to R:
+-------------------------+
| Workspace |
| bindings: |
| CollX CollY |
+-------------------------+
| |
| |
| |
+---------------+ +---------------+
| Collection C1 | | Collection C2 |
| bindings: | | bindings: |
| test | | test |
+---------------+ +---------------+
| |
| |
| |
+------------------+
| Resource R |
+------------------+
The MOVE semantics defined in Section 3.15 of [RFC3253] already
require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the
same version history (as exposed in the DAV:version-history
property). Furthermore, the UNCHECKOUT semantics (which in this case
is similar to UPDATE, see Section 14.11 of [RFC3253]) require:
...If a new version-controlled member is in a workspace that
already has a version-controlled resource for that version
history, then the new version-controlled member MUST be just a
binding (i.e., another name for) that existing version-controlled
resource...
Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the
same resource R, and have identical DAV:resource-id properties.
11. Security Considerations
This section is provided to make WebDAV implementors aware of the This section is provided to make WebDAV implementors aware of the
security implications of this protocol. security implications of this protocol.
All of the security considerations of HTTP/1.1 and the WebDAV All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this Distributed Authoring Protocol specification also apply to this
protocol specification. In addition, bindings introduce several new protocol specification. In addition, bindings introduce several new
security concerns and increase the risk of some existing threats. security concerns and increase the risk of some existing threats.
These issues are detailed below. These issues are detailed below.
10.1. Privacy Concerns 11.1. Privacy Concerns
In a context where cross-server bindings are supported, creating In a context where cross-server bindings are supported, creating
bindings on a trusted server may make it possible for a hostile agent bindings on a trusted server may make it possible for a hostile agent
to induce users to send private information to a target on a to induce users to send private information to a target on a
different server. different server.
10.2. Bind Loops 11.2. Bind Loops
Although bind loops were already possible in HTTP 1.1, the Although bind loops were already possible in HTTP 1.1, the
introduction of the BIND method creates a new avenue for clients to introduction of the BIND method creates a new avenue for clients to
create loops accidentally or maliciously. If the binding and its create loops accidentally or maliciously. If the binding and its
target are on the same server, the server may be able to detect BIND target are on the same server, the server may be able to detect BIND
requests that would create loops. Servers are required to detect requests that would create loops. Servers are required to detect
loops that are caused by bindings to collections during the loops that are caused by bindings to collections during the
processing of any requests with "Depth: infinity". processing of any requests with "Depth: infinity".
10.3. Bindings, and Denial of Service 11.3. Bindings, and Denial of Service
Denial of service attacks were already possible by posting URIs that Denial of service attacks were already possible by posting URIs that
were intended for limited use at heavily used Web sites. The were intended for limited use at heavily used Web sites. The
introduction of BIND creates a new avenue for similar denial of introduction of BIND creates a new avenue for similar denial of
service attacks. If cross-server bindings are supported, clients can service attacks. If cross-server bindings are supported, clients can
now create bindings at heavily used sites to target locations that now create bindings at heavily used sites to target locations that
were not designed for heavy usage. were not designed for heavy usage.
10.4. Private Locations May Be Revealed 11.4. Private Locations May Be Revealed
If the DAV:parent-set property is maintained on a resource, the If the DAV:parent-set property is maintained on a resource, the
owners of the bindings risk revealing private locations. The owners of the bindings risk revealing private locations. The
directory structures where bindings are located are available to directory structures where bindings are located are available to
anyone who has access to the DAV:parent-set property on the resource. anyone who has access to the DAV:parent-set property on the resource.
Moving a binding may reveal its new location to anyone with access to Moving a binding may reveal its new location to anyone with access to
DAV:parent-set on its resource. DAV:parent-set on its resource.
10.5. DAV:parent-set and Denial of Service 11.5. DAV:parent-set and Denial of Service
If the server maintains the DAV:parent-set property in response to If the server maintains the DAV:parent-set property in response to
bindings created in other administrative domains, it is exposed to bindings created in other administrative domains, it is exposed to
hostile attempts to make it devote resources to adding bindings to hostile attempts to make it devote resources to adding bindings to
the list. the list.
11. Internationalization Considerations 12. Internationalization Considerations
All internationalization considerations mentioned in [RFC4918] also All internationalization considerations mentioned in [RFC4918] also
apply to this document. apply to this document.
12. IANA Considerations 13. IANA Considerations
Section 7 defines the HTTP status codes 208 (Already Reported) and Section 7 defines the HTTP status codes 208 (Already Reported) and
506 (Loop Detected), to be added to the registry at 506 (Loop Detected), to be added to the registry at
<http://www.iana.org/assignments/http-status-codes>. <http://www.iana.org/assignments/http-status-codes>.
13. Acknowledgements 14. Acknowledgements
This document is the collaborative product of the authors and Tyson This document is the collaborative product of the authors and Tyson
Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited Chihaya, Jim Davis, Chuck Fay and Judith Slein. It has benefited
from thoughtful discussion by Jim Amsden, Peter Carlson, Steve from thoughtful discussion by Jim Amsden, Peter Carlson, Steve
Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer
Dawkins, Mark Day, Werner Donne, Rajiv Dulepet, David Durand, Lisa Dawkins, Mark Day, Werner Donne, 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.
14. References 15. References
14.1. Normative References 15.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.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[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 (Fourth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", W3C REC-xml-20060816, August 2006, Edition)", W3C REC-xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
14.2. Informative References 15.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, Distributed Authoring and Versioning)", RFC 3253,
March 2002. March 2002.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Access Distributed Authoring and Versioning (WebDAV) Access
Control Protocol", RFC 3744, May 2004. Control Protocol", RFC 3744, May 2004.
skipping to change at page 41, line 40 skipping to change at page 44, line 22
creating-cycles", "3.1-clarify-resource-id" and "4-precondition- creating-cycles", "3.1-clarify-resource-id" and "4-precondition-
language". language".
B.19. Since draft-ietf-webdav-bind-20 B.19. Since draft-ietf-webdav-bind-20
Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples. Use "urn:uuid:" instead of "opaquelocktoken:" scheme in examples.
Replace RFC518bis issue link by pointer to RFC Errata Page. Replace RFC518bis issue link by pointer to RFC Errata Page.
Add issues "relation-to-deltav" and "status-codes". Add issues "relation-to-deltav" and "status-codes".
Appendix C. Open issues (to be removed by RFC Editor prior to B.20. Since draft-ietf-webdav-bind-21
publication)
C.1. edit Resolve issues "relation-to-deltav" and "status-codes".
Type: edit Add correct content length values to examples (no change bars).
julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for Appendix C. Resolved issues (to be removed by RFC Editor before
editorial fixes/enhancements. publication)
C.2. status-codes Issues that were either rejected or resolved in this version of this
document.
C.1. status-codes
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/ <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/
0067.html> 0067.html>
julian.reschke@greenbytes.de (2008-09-26): The spec currently micro- julian.reschke@greenbytes.de (2008-09-26): The spec currently micro-
manages HTTP status codes: for instance, for a successful BIND it manages HTTP status codes: for instance, for a successful BIND it
requires status codes of 200 or 201, while - from an HTTP point of requires status codes of 200 or 201, while - from an HTTP point of
view - a 204 should be acceptable as well. Proposal: rephrase the view - a 204 should be acceptable as well. Proposal: rephrase the
text so that other success codes are acceptable as well, or remove text so that other success codes are acceptable as well, or remove
the normative language completely, point to RFC2616, and rely on the normative language completely, point to RFC2616, and rely on
examples. examples.
C.3. relation-to-deltav Resolution (2008-10-05): Also allow 204 where previously only 200 was
allowed. Add Location header to example using status 201.
C.2. relation-to-deltav
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/ <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/
0031.html> 0031.html>
werner.donne@re.be (2008-08-11): ...When supporting version werner.donne@re.be (2008-08-11): ...When supporting version
controlled collections, bindings may be introduced in a server controlled collections, bindings may be introduced in a server
without actually issuing the BIND method. When a MOVE is performed without actually issuing the BIND method. When a MOVE is performed
of a resource from one collection to another, both collections should of a resource from one collection to another, both collections should
be checked out. An additional binding would be the result if one be checked out. An additional binding would be the result if one
collection would be subsequently checked in, while the check-out of collection would be subsequently checked in, while the check-out of
the other is undone. The resulting situation is meaningless if the the other is undone. The resulting situation is meaningless if the
binding model is not supported... binding model is not supported...
Resolution (2008-10-04): Add new section containing that example.
Appendix D. Open issues (to be removed by RFC Editor prior to
publication)
D.1. edit
Type: edit
julian.reschke@greenbytes.de (2004-05-30): Umbrella issue for
editorial fixes/enhancements.
Index Index
2 2
208 Already Reported (status code) 31, 36 208 Already Reported (status code) 31, 39
5 5
506 Loop Detected (status code) 34, 36 506 Loop Detected (status code) 34, 39
B B
BIND method 21 BIND method 21
Marshalling 22 Marshalling 22
Postconditions 23 Postconditions 23
Preconditions 22 Preconditions 22
Binding 7 Binding 7
C C
Collection 7 Collection 7
skipping to change at page 44, line 27 skipping to change at page 47, line 26
DAV:resource-id 19 DAV:resource-id 19
R R
REBIND method 26 REBIND method 26
Marshalling 26 Marshalling 26
Postconditions 28 Postconditions 28
Preconditions 27 Preconditions 27
S S
Status Codes Status Codes
208 Already Reported 31, 36 208 Already Reported 31, 39
506 Loop Detected 34, 36 506 Loop Detected 34, 39
U U
UNBIND method 24 UNBIND method 24
Marshalling 24 Marshalling 24
Postconditions 25 Postconditions 25
Preconditions 25 Preconditions 25
URI Mapping 6 URI Mapping 6
Authors' Addresses Authors' Addresses
 End of changes. 42 change blocks. 
82 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/