draft-ietf-webdav-bind-03.txt   draft-ietf-webdav-bind-04.txt 
Network Working Group G. Clemm Network Working Group G. Clemm
Internet-Draft IBM Internet-Draft IBM
Expires: June 10, 2004 J. Crawford Updates: 2518 (if approved) J. Crawford
IBM Research Expires: September 8, 2004 IBM Research
J. Reschke J. Reschke
greenbytes greenbytes
J. Slein
Xerox
J. Whitehead J. Whitehead
U.C. Santa Cruz U.C. Santa Cruz
December 11, 2003 March 10, 2004
Binding Extensions to Web Distributed Authoring and Versioning Binding Extensions to Web Distributed Authoring and Versioning
(WebDAV) (WebDAV)
draft-ietf-webdav-bind-03 draft-ietf-webdav-bind-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 10, 2004. This Internet-Draft will expire on September 8, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Rationale for Distinguishing Bindings from URI Mappings . . . 6 1.2 Rationale for Distinguishing Bindings from URI Mappings . . 6
1.3 Method Preconditions and Postconditions . . . . . . . . . . . 7 1.3 Method Preconditions and Postconditions . . . . . . . . . . 7
2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of Bindings . . . . . . . . . . . . . . . . . . . . 7
2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . . 8 2.1 Bindings to Collections . . . . . . . . . . . . . . . . . . 8
2.2 URI Mappings Created by a new Binding . . . . . . . . . . . . 9 2.2 URI Mappings Created by a new Binding . . . . . . . . . . . 9
2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . . 10 2.3 COPY and Bindings . . . . . . . . . . . . . . . . . . . . . 10
2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . . 11 2.4 DELETE and Bindings . . . . . . . . . . . . . . . . . . . . 11
2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . . 12 2.5 MOVE and Bindings . . . . . . . . . . . . . . . . . . . . . 12
2.6 Determining Whether Two Bindings Are to the Same Resource . . 13 2.6 Determining Whether Two Bindings Are to the Same Resource . 13
2.7 Discovering the Bindings to a Resource . . . . . . . . . . . . 14 2.7 Discovering the Bindings to a Resource . . . . . . . . . . . 14
3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . . 14 3.1 DAV:resource-id Property . . . . . . . . . . . . . . . . . . 14
3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . . 14 3.2 DAV:parent-set Property . . . . . . . . . . . . . . . . . . 14
4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. BIND Method . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Example: BIND . . . . . . . . . . . . . . . . . . . . . . . 17
5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 17 5. UNBIND Method . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Example: UNBIND . . . . . . . . . . . . . . . . . . . . . . 19
6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . . 19 6. REBIND Method . . . . . . . . . . . . . . . . . . . . . . . 19
6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . . 21 6.1 Example: REBIND . . . . . . . . . . . . . . . . . . . . . . 21
7. Additional Status Codes . . . . . . . . . . . . . . . . . . . 21 7. Additional Status Codes . . . . . . . . . . . . . . . . . . 21
7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . . 21 7.1 208 Already Reported . . . . . . . . . . . . . . . . . . . . 21
7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . . 23 7.1.1 Example: PROPFIND by bind-aware client . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7.1.2 Example: PROPFIND by non-bind-aware client . . . . . . . . . 23
8.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . . 24 7.2 506 Loop Detected . . . . . . . . . . . . . . . . . . . . . 24
8.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Capability discovery . . . . . . . . . . . . . . . . . . . . 24
8.3 Bindings, and Denial of Service . . . . . . . . . . . . . . . 24 8.1 OPTIONS method . . . . . . . . . . . . . . . . . . . . . . . 24
8.4 Private Locations May Be Revealed . . . . . . . . . . . . . . 24 8.2 'DAV' request header . . . . . . . . . . . . . . . . . . . . 24
8.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . . 25 8.2.1 Generic syntax . . . . . . . . . . . . . . . . . . . . . . . 24
9. Internationalization Considerations . . . . . . . . . . . . . 25 8.2.2 Client compliance class 'bind' . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 9.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 25
Normative References . . . . . . . . . . . . . . . . . . . . . 25 9.2 Bind Loops . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 9.3 Bindings, and Denial of Service . . . . . . . . . . . . . . 25
A. Change Log (to be removed by RFC Editor before publication) . 27 9.4 Private Locations May Be Revealed . . . . . . . . . . . . . 26
A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . . 27 9.5 DAV:parent-set and Denial of Service . . . . . . . . . . . . 26
10. Internationalization Considerations . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
Normative References . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
A.1 Since draft-ietf-webdav-bind-02 . . . . . . . . . . . . . . 28
A.2 Since draft-ietf-webdav-bind-03 . . . . . . . . . . . . . . 28
B. Resolved issues (to be removed by RFC Editor before B. Resolved issues (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 27 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28
B.1 ED_references . . . . . . . . . . . . . . . . . . . . . . . . 27 B.1 ED_updates . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.2 2.3_COPY_SHARED_BINDINGS . . . . . . . . . . . . . . . . . . . 27 B.2 ED_authors . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.3 2.3_MULTIPLE_COPY . . . . . . . . . . . . . . . . . . . . . . 28 B.3 locking . . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.4 4_507_status . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.4 5.1_LOOP_STATUS . . . . . . . . . . . . . . . . . . . . . . 29
C. Open issues (to be removed by RFC Editor before B.5 5.1_506_STATUS_STREAMING . . . . . . . . . . . . . . . . . . 30
publication) . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.6 9.2_redirect_loops . . . . . . . . . . . . . . . . . . . . . 30
C.1 5.1_LOOP_STATUS . . . . . . . . . . . . . . . . . . . . . . . 28 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 31
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 21, line 48 skipping to change at page 21, line 48
by the URI "http://www.example.com/CollY". Clients can now use the by the URI "http://www.example.com/CollY". Clients can now use the
URI "http://www.example.com/CollX/foo.html" to submit requests to URI "http://www.example.com/CollX/foo.html" to submit requests to
that resource, and requests on the URI "http://www.example.com/CollY/ that resource, and requests on the URI "http://www.example.com/CollY/
bar.html" will fail with a 404 (Not Found) response. bar.html" will fail with a 404 (Not Found) response.
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 indicate that information about the DAV:propstat response element to avoid enumerating the internal
resource has already been reported in a previous DAV:propstat element members of multiple bindings to the same collection repeatedly. For
in that response. The members of the 208 status resource are omitted each binding to a collection inside the request's scope, only one
from the response. will be reported with a 200 status, while subsequent DAV:response
elements for all other bindings will use the 208 status, and no
DAV:response elements for their descendants are included.
Note that the 208 status will only occur for "Depth: infinity"
requests, and that it is of particular importance when the multiple
collection bindings cause a bind loop as discussed in Section 2.2.
A client can request the DAV:resourceid property in a PROPFIND
request to guarantee that they can accurately reconstruct the binding
structure of a collection with multiple bindings to a single
resource.
For backward compatibility with clients not aware of the 208 status
code appearing in multistatus response bodies, it SHOULD NOT be used
unless the client has signalled support for this specification using
the "DAV" request header (see Section 8.2). Instead, a 506 status
should be returned when a binding loop is discovered. This allows the
server to return the 506 as the top level return status, if it
discovers it before it started the response, or in the middle of a
multistatus, if it discovers it in the middle of streaming out a
multistatus response.
7.1.1 Example: PROPFIND by bind-aware client
For example, consider a PROPFIND request on /Coll (bound to For example, consider a PROPFIND request on /Coll (bound to
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
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxx Content-Length: xxx
<?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 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxx Content-Length: xxx
<?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>
skipping to change at page 23, line 41 skipping to change at page 23, line 41
<D:href>http://www.example.com/Coll/Bar</D:href> <D:href>http://www.example.com/Coll/Bar</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:displayname>Loop Demo</D:displayname> <D:displayname>Loop Demo</D:displayname>
</D:prop> </D:prop>
<D:status>HTTP/1.1 208 Already Reported</D:status> <D:status>HTTP/1.1 208 Already Reported</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
A client can request the DAV:resourceid property in a PROPFIND 7.1.2 Example: PROPFIND by non-bind-aware client
request to guarantee that they can accurately reconstruct the binding
structure of a collection with multiple bindings to a single In this example, the client isn't aware of the 208 status code
resource. introduced by this specification. As the "Depth: infinity" PROPFIND
request would cause a loop condition, the whole request is rejected
with a 506 status.
>> Request:
PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop> <D:displayname/> </D:prop>
</D:propfind>
>> Response:
HTTP/1.1 506 Loop Detected
7.2 506 Loop Detected 7.2 506 Loop Detected
The 506 (Loop Detected) status code indicates that the server The 506 (Loop Detected) status code indicates that the server
terminated an operation because it encountered an infinite loop while terminated an operation because it encountered an infinite loop while
processing a request with "Depth: infinity". This status indicates processing a request with "Depth: infinity". This status indicates
that the entire operation failed. that the entire operation failed.
8. Security Considerations 8. Capability discovery
This section is provided to make WebDAV applications aware of the 8.1 OPTIONS method
If the server supports bindings, it MUST return the compliance class
name "bind" as a field in the "DAV" response header (see [RFC2518],
section 9.1) from an OPTIONS request on any resource implemented by
that server. A value of "bind" in the "DAV" header MUST indicate that
the server supports all MUST level requirements and REQUIRED features
specified in this document.
8.2 'DAV' request header
8.2.1 Generic syntax
This specification introduces the 'DAV' request header that allows
clients to signal compliance to specific WebDAV features. It has the
same syntax as the response header defined in [RFC2518], section 9.1,
but MAY be used with any method.
Note that clients MUST NOT submit a specific compliance class name in
the request header unless the specification defining this compliance
class specifically defines it's semantics for clients.
Note that if a server chooses to vary the result of a request based
on values in the "DAV" header, the response either MUST NOT be
cacheable or the server MUST mark the response accordingly using the
"Vary" header (see [RFC2616], section 14.44).
8.2.2 Client compliance class 'bind'
Clients SHOULD signal support for all MUST level requirements and
REQUIRED features by submitting a "DAV" request header containing the
compliance class name "bind". In particular, the client MUST
understand the 208 status code defined in Section 7.1.
9. Security Considerations
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.
8.1 Privacy Concerns 9.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.
8.2 Redirect Loops 9.2 Bind Loops
Although redirect 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".
8.3 Bindings, and Denial of Service 9.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.
8.4 Private Locations May Be Revealed 9.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.
8.5 DAV:parent-set and Denial of Service 9.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.
9. Internationalization Considerations 10. Internationalization Considerations
All internationalization considerations mentioned in [RFC2518] also All internationalization considerations mentioned in [RFC2518] also
apply to this document. apply to this document.
10. IANA Considerations 11. IANA Considerations
All IANA considerations mentioned in [RFC2518] also apply to this All IANA considerations mentioned in [RFC2518] also apply to this
document. document.
11. Acknowledgements 12. Acknowledgements
This draft is the collaborative product of the authors and Tyson This draft is the collaborative product of the authors and Tyson
Chihaya, Jim Davis, and Chuck Fay. This draft has benefited from Chihaya, Jim Davis, Chuck Fay and Judith Slein. This draft has
thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Ken benefited from thoughtful discussion by Jim Amsden, Peter Carlson,
Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer Dawkins, Mark Steve Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun,
Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Stefan
Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James
Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer,
Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick
Turner, Kevin Wiggen, and other members of the WebDAV working group. Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and
other members of the WebDAV working group.
Normative References Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[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.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
skipping to change at page 26, line 6 skipping to change at page 27, line 17
August 1998. August 1998.
[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
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. and E. Maler, [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
REC-xml, October 2000, <http://www.w3.org/TR/2000/ Edition)", W3C REC-xml-20040204, February 2004, <http://
REC-xml-20001006>. www.w3.org/TR/2004/REC-xml-20040204>.
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
skipping to change at page 26, line 34 skipping to change at page 28, line 4
EMail: ccjason@us.ibm.com EMail: ccjason@us.ibm.com
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Salzmannstrasse 152 Salzmannstrasse 152
Muenster, NW 48159 Muenster, NW 48159
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
Judy Slein
Xerox Corporation
800 Phillips Road, 105-50C
Webster, NY 14580
EMail: jslein@crt.xerox.com
Jim Whitehead Jim Whitehead
UC Santa Cruz, Dept. of Computer Science UC Santa Cruz, Dept. of Computer Science
1156 High Street 1156 High Street
Santa Cruz, CA 95064 Santa Cruz, CA 95064
EMail: ejw@cse.ucsc.edu EMail: ejw@cse.ucsc.edu
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1 Since draft-ietf-webdav-bind-02 A.1 Since draft-ietf-webdav-bind-02
Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and Add and resolve issues "2.3_COPY_SHARED_BINDINGS" and
"2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed "2.3_MULTIPLE_COPY". Add issue "5.1_LOOP_STATUS" and proposed
resolution, but keep it open. Add issues "ED_references" and resolution, but keep it open. Add issues "ED_references" and
"4_507_status". Started work on index. Rename document to "Binding "4_507_status". Started work on index. Rename document to "Binding
Extensions to Web Distributed Authoring and Versioning (WebDAV)". Extensions to Web Distributed Authoring and Versioning (WebDAV)".
Rename "References" to "Normative References". Close issue Rename "References" to "Normative References". Close issue
"ED_references". CLose issue "4_507_status". "ED_references". CLose issue "4_507_status".
A.2 Since draft-ietf-webdav-bind-03
Add and close issues "9.2_redirect_loops", "ED_authors" and
"ED_updates". Add section about capability discovery (DAV header).
Close issues "5.1_LOOP_STATUS". Add and resolve new issue
"5.1_506_STATUS_STREAMING". Update XML spec reference. Add issue
"locking" and resolve as invalid.
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 ED_references B.1 ED_updates
Type: edit Type: edit
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/
0283.html> 0306.html>
julian.reschke@greenbytes.de (2003-12-09): (1) Distinguish normative
and informative references, (2) text referring to RFC2119 is missing,
(3) references to RFC2277, RFC2616 and XML not needed.
Resolution (2003-12-11): Editorial changes applied.
B.2 2.3_COPY_SHARED_BINDINGS
Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/
0010.html>
Peter.Nevermann@softwareag.com (2003-07-10): What if a copied julian.reschke@greenbytes.de (2003-12-30): Shouldn't the BIND spec be
collection has two bindings to the same resource. labelled as "updating" RFC2518 and/or RFC3253?
Resolution (2003-08-21): Recommend that only one resource with julian.reschke@greenbytes.de (2004-01-05): It seems that there was
multiple bindings to it be created by the COPY. consensus to say that BIND does update RFC2518, while there's no
consensus about the relationship to RFC3253. As this is a minor
editorial question, I propose to just say "updated 2518" and to close
the issue.
B.3 2.3_MULTIPLE_COPY Resolution (2004-01-09): State "updates 2518".
Type: change B.2 ED_authors
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/ Type: edit
0124.html>
Peter.Nevermann@softwareag.com (2003-08-17): What two resources are julian.reschke@greenbytes.de (2004-01-02): Ensure contact information
copied to the same resource by a single COPY. for all original authors is still correct, and that the authors in
fact support the current draft.
Resolution (2003-08-21): Server decides order of updates. Resolution (2004-01-05): J. Slein removed as author and added to
Acknowledgments.
B.4 4_507_status B.3 locking
Type: change Type: change
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ <http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-03-01.html>
0282.html>
julian.reschke@greenbytes.de (2003-12-09): Section 4 refers to a
definition of a 507 status code in Section 7.1, which doesn't exist.
Should this text be replaced by a reference to the
DAV:cross-server-binding precondition?
Resolution (2003-12-11): Change wording to refer to precondition lisa@xythos.com (2004-03-02): (concerns about the behaviour of
name. multiple bindings to the same resource when the resource was locked
via WebDAV LOCK on one of it's bindings).
Appendix C. Open issues (to be removed by RFC Editor before publication) Resolution (2004-03-06): No issue here: given two URIs "a" and "b"
mapped to the same resource, and a WebDAV LOCK that was requested for
"a", attempts to modify the lockable state of "b" will fail unless
the lock-token is presented. This is because the resource itself is
locked, not only it's URI "a". See RFC2518, section 6.
C.1 5.1_LOOP_STATUS B.4 5.1_LOOP_STATUS
Type: change Type: change
julian.reschke@greenbytes.de (2002-10-11): Should the 506 status in a julian.reschke@greenbytes.de (2002-10-11): Should the 506 status in a
PROPFIND be handled differently? PROPFIND be handled differently?
geoffrey.clemm@us.ibm.com (2003-08-03): Use new 208 status to report geoffrey.clemm@us.ibm.com (2003-08-03): Use new 208 status to report
cycles in PROPFIND. cycles in PROPFIND.
julian.reschke@greenbytes.de (2003-11-16): Proposal: a) import DAV julian.reschke@greenbytes.de (2003-11-16): Proposal: a) import DAV
request header definition from rfc2518bis (note that the definition request header definition from rfc2518bis (note that the definition
in the latest draft probably needs some more work) b) define a DAV in the latest draft probably needs some more work) b) define a DAV
compliance class for the BIND spec c) clarify that 208 should only be compliance class for the BIND spec c) clarify that 208 should only be
returned when the client specifies compliance to the BIND spec in the returned when the client specifies compliance to the BIND spec in the
PROPFIND request (otherwise fail the complete request). PROPFIND request (otherwise fail the complete request).
Resolution (2004-01-02): Define DAV compliance class "bind", define
DAV request header, clarify that 208 must only be used when the
client signals that it knows about this specification.
B.5 5.1_506_STATUS_STREAMING
Type: change
julian.reschke@greenbytes.de (2004-01-12): Take a server that allows
Depth: infinity upon PROPFIND. In general, the only way to implement
this efficiently is to *stream* the multistatus response. However
this means that the server needs to decide about the HTTP status code
to return *prior* to actually doing the recursion. Therefore,
requiring the server to return a 506 status in case there's a bind
loop somewhere below the request URI will not work. An obvious
alternative would be to allow the 506 to be returned inside the
DAV:status element for the resource the server refuses to recurse
into. Of course that would mean that the client essentially would
get a partly incorrect picture of the server state. However, I don't
think there's any way to avoid that (except for rejecting all Depth:
infinity PROPFINDs, like many servers already do).
Resolution (2004-03-06): Allow 506 inside multistatus.
B.6 9.2_redirect_loops
Type: edit
julian.reschke@greenbytes.de (2004-01-09): Avoid confusion with
REDIRECT. Propose rename to "Bind Loops".
Resolution (2004-01-09): Do the rename.
Index Index
2 2
208 Already Reported (status code) 21 208 Already Reported (status code) 21
5 5
506 Loop Detected (status code) 23 506 Loop Detected (status code) 24
B B
BIND method 15 BIND method 15
C C
Condition Names Condition Names
DAV:bind-into-collection (pre) 16 DAV:bind-into-collection (pre) 16
DAV:bind-source-exists (pre) 16 DAV:bind-source-exists (pre) 16
DAV:binding-allowed (pre) 16, 20 DAV:binding-allowed (pre) 16, 20
DAV:binding-deleted (post) 18, 21 DAV:binding-deleted (post) 18, 21
skipping to change at page 29, line 39 skipping to change at page 31, line 39
DAV:new-binding (post) 17, 21 DAV:new-binding (post) 17, 21
DAV:protected-source-url-deletion-allowed (pre) 20 DAV:protected-source-url-deletion-allowed (pre) 20
DAV:protected-url-deletion-allowed (pre) 18 DAV:protected-url-deletion-allowed (pre) 18
DAV:protected-url-modification-allowed (pre) 20 DAV:protected-url-modification-allowed (pre) 20
DAV:rebind-into-collection (pre) 20 DAV:rebind-into-collection (pre) 20
DAV:rebind-source-exists (pre) 20 DAV:rebind-source-exists (pre) 20
DAV:unbind-from-collection (pre) 18 DAV:unbind-from-collection (pre) 18
DAV:unbind-source-exists (pre) 18 DAV:unbind-source-exists (pre) 18
D D
DAV header
compliance class 'bind' 24
DAV:bind-into-collection precondition 16 DAV:bind-into-collection precondition 16
DAV:bind-source-exists precondition 16 DAV:bind-source-exists precondition 16
DAV:binding-allowed precondition 16, 20 DAV:binding-allowed precondition 16, 20
DAV:binding-deleted postcondition 18, 21 DAV:binding-deleted postcondition 18, 21
DAV:can-overwrite precondition 16, 20 DAV:can-overwrite precondition 16, 20
DAV:cross-server-binding precondition 16, 20 DAV:cross-server-binding precondition 16, 20
DAV:cycle-allowed precondition 16, 20 DAV:cycle-allowed precondition 16, 20
DAV:locked-overwrite-allowed precondition 16 DAV:locked-overwrite-allowed precondition 16
DAV:locked-source-collection-update-allowed precondition 20 DAV:locked-source-collection-update-allowed precondition 20
DAV:locked-update-allowed precondition 16, 18, 20 DAV:locked-update-allowed precondition 16, 18, 20
skipping to change at page 30, line 29 skipping to change at page 32, line 31
Properties Properties
DAV:parent-set 14 DAV:parent-set 14
DAV:resource-id 14 DAV:resource-id 14
R R
REBIND method 19 REBIND method 19
S S
Status Codes Status Codes
208 Already Reported 21 208 Already Reported 21
506 Loop Detected 23 506 Loop Detected 24
U U
UNBIND method 17 UNBIND method 17
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 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the IETF's procedures with respect to rights in IETF Documents can
standards-related documentation can be found in BCP-11. Copies of be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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/