draft-ietf-webdav-binding-protocol-00.txt   draft-ietf-webdav-binding-protocol-01.txt 
WEBDAV Working Group J. Slein, Xerox WEBDAV Working Group J. Slein, Xerox
INTERNET DRAFT E.J. Whitehead Jr., UC Irvine INTERNET DRAFT E.J. Whitehead Jr., UC Irvine
<draft-ietf-webdav-binding-protocol-00.txt> J. Davis, CourseNet <draft-ietf-webdav-binding-protocol-01.txt> J. Davis, CourseNet
G. Clemm, Rational G. Clemm, Rational
C. Fay, FileNet C. Fay, FileNet
J. Crawford, IBM J. Crawford, IBM
T. Chihaya, DataChannel T. Chihaya, DataChannel
August 20, 1999 October 15, 1999
Expires February 20, 2000 Expires April 15, 2000
WebDAV Bindings WebDAV Bindings
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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.
Distribution of this document is unlimited. Please send comments to the Distribution of this document is unlimited. Please send comments to the
Distributed Authoring and Versioning (WebDAV) working group at <w3c- Distributed Authoring and Versioning (WebDAV) working group at <w3c-
dist-auth@w3.org>, which may be joined by sending a message with subject dist-auth@w3.org>, which may be joined by sending a message with subject
"subscribe" to <w3c-dist-auth-request@w3.org>. "subscribe" to <w3c-dist-auth-request@w3.org>.
skipping to change at line 47 skipping to change at line 52
The WebDAV Distributed Authoring Protocol provides basic support for The WebDAV Distributed Authoring Protocol provides basic support for
collections, offering the ability to create and list unordered collections, offering the ability to create and list unordered
collections. collections.
This specification is one of a group of three specifications that This specification is one of a group of three specifications that
supplement the WebDAV Distributed Authoring Protocol to increase the supplement the WebDAV Distributed Authoring Protocol to increase the
power of WebDAV collections. This specification defines bindings, one power of WebDAV collections. This specification defines bindings, one
mechanism for allowing a single resource to appear in more than one mechanism for allowing a single resource to appear in more than one
collection. Bindings make this possible by creating mappings of URIs to collection. Bindings make this possible by creating mappings of URIs to
resources. The BIND method defined here gives clients the ability to resources. The BIND method defined here gives clients the ability to
create new bindings to existing resources. [RR] defines redirect create new bindings to existing resources. The second specification,
references, another approach to allowing a single resource to be "WebDAV Redirect Reference Resources"[RR], defines redirect references,
accessed from multiple collections. [OC] provides ordered collections. another approach to allowing a single resource to be accessed from
multiple collections. The third specification, "WebDAV Ordered
Collections Protocol"[OC], provides a mechanism for ordering
collections.
Table of Contents Table of Contents
1 Notational Conventions.......................................2 1 Notational Conventions.......................................2
2 Introduction.................................................2 2 Introduction.................................................3
3 Terminology..................................................4 3 Terminology..................................................4
3.1 Rationale for Distinguishing Bindings from URI Mappings......7
4 Overview of Bindings.........................................7 4 Overview of Bindings.........................................8
5 BIND Method..................................................8 5 BIND Method..................................................8
5.1 Overview of BIND.............................................8 5.1 Overview of BIND.............................................8
5.2 Bindings to Collections......................................9 5.2 Bindings to Collections......................................9
5.3 URI Mappings Created by BIND.................................9 5.3 URI Mappings Created by a BIND..............................10
5.4 Example: Generating the Set of URI Mappings.................10 5.4 Example: URI Mappings Created by a BIND.....................10
5.5 BIND Status Codes...........................................11 5.5 BIND Status Codes...........................................11
5.6 Example: BIND...............................................11 5.6 Example: BIND...............................................11
5.7 Example: BIND Conflict......................................11 6 DELETE and Bindings.........................................11
6 DELETE and Bindings.........................................12
7 COPY and Bindings...........................................12 7 COPY and Bindings...........................................12
8 MOVE and Bindings...........................................13 8 MOVE and Bindings...........................................13
8.1 Implementation Note.........................................14 8.1 Implementation Note.........................................14
9 LOCK and UNLOCK.............................................15 8.2 MOVE and Locks..............................................15
10 Bindings and Other Methods..................................15 9 LOCK and UNLOCK.............................................16
11 Discovering the Bindings to a Resource......................16 10 Bindings and Other Methods..................................17
12 Headers.....................................................16 11 Determining Whether Two Bindings Are to the Same
12.1 All-Bindings Request Header.................................17 Resource....................................................17
13 Status Codes................................................17 11.1 davresourceid URI Scheme....................................17
13.1 506 Loop Detected...........................................17 12 Discovering the Bindings to a Resource......................18
14 Properties..................................................17 13 Status Codes................................................18
14.1 bindings Property...........................................17 13.1 506 Loop Detected...........................................18
15 XML Elements................................................17 13.2 507 Loop Forbidden..........................................20
15.1 segment XML Element.........................................17 13.3 508 Cross-Server Binding Forbidden..........................20
16 Capability Discovery........................................17 14 Headers.....................................................20
16.1 Example: Discovery of Support for Bindings..................18 14.1 All-Bindings Request Header.................................20
17 Security Considerations.....................................18 14.2 Loop Header.................................................20
17.1 Privacy Concerns............................................18 15 Properties..................................................20
17.2 Redirect Loops..............................................19 15.1 bindings Property...........................................20
17.3 Bindings, and Denial of Service.............................19 15.2 guid Property...............................................21
17.4 Private Locations May Be Revealed...........................19 16 XML Elements................................................21
17.5 DAV:bindings and Denial of Service..........................19 16.1 segment XML Element.........................................21
18 Internationalization Considerations.........................19 17 Capability Discovery........................................21
19 IANA Considerations.........................................20 17.1 Example: Discovery of Support for Bindings..................21
20 Copyright...................................................20 18 Security Considerations.....................................22
21 Intellectual Property.......................................20 18.1 Privacy Concerns............................................22
22 Acknowledgements............................................20 18.2 Redirect Loops..............................................22
23 References..................................................20 18.3 Bindings, and Denial of Service.............................22
24 Authors' Addresses..........................................21 18.4 Private Locations May Be Revealed...........................22
25 Appendices..................................................21 18.5 DAV:bindings and Denial of Service..........................23
25.1 Appendix 1: Extensions to the WebDAV Document Type 19 Internationalization Considerations.........................23
Definition..................................................21 20 IANA Considerations.........................................23
21 Copyright...................................................23
22 Intellectual Property.......................................23
23 Acknowledgements............................................24
24 References..................................................24
25 Authors' Addresses..........................................24
26 Appendices..................................................25
26.1 Appendix 1: Extensions to the WebDAV Document Type
Definition..................................................25
1 Notational Conventions 1 Notational Conventions
Since this document describes a set of extensions to the HTTP/1.1 Since this document describes a set of extensions to the WebDAV
protocol, the augmented BNF used here to describe protocol elements is Distributed Authoring Protocol [WebDAV], itself an extension to the
exactly the same as described in Section 2.1 of [HTTP]. Since this HTTP/1.1 protocol, the augmented BNF used here to describe protocol
augmented BNF uses the basic production rules provided in Section 2.2 of elements is exactly the same as described in Section 2.1 of [HTTP].
[HTTP], these rules apply to this document as well. Since this augmented BNF uses the basic production rules provided in
Section 2.2 of [HTTP], these rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2 Introduction 2 Introduction
The simple collections that the WebDAV Distributed Authoring Protocol The simple collections that the WebDAV Distributed Authoring Protocol
specification supports are powerful enough to be widely useful. They supports are powerful enough to be widely useful. They provide for the
provide for the hierarchical organization of resources, with mechanisms hierarchical organization of resources, with mechanisms for creating and
for creating and deleting collections, copying and moving them, locking deleting collections, copying and moving them, locking them, adding
them, adding members to them and removing members from them, and getting members to them and removing members from them, and getting listings of
listings of their members. Delete, copy, move, list, and lock their members. Delete, copy, move, list, and lock operations can be
operations can be applied recursively, so that a client can operate on applied recursively, so that a client can operate on whole hierarchies
whole hierarchies with a single request. with a single request.
This specification is one of a family of three specifications that build This specification is one of a family of three specifications that build
on the infrastructure defined in [HTTP] and [WebDAV] to extend the on the infrastructure defined in [HTTP] and [WebDAV] to extend the
capabilities of collections. The companion specification [OC] defines capabilities of collections. The companion specification, "WebDAV
protocol extensions to support ordered collections. The present Ordered Collections Protocol"[OC], defines protocol extensions to
specification and the companion specification [RR] define mechanisms for support ordered collections. The present specification and the
allowing the same resource to appear in multiple collections. This companion specification, "WebDAV Redirect Reference Resources"[RR],
capability is useful for several reasons: define mechanisms for allowing the same resource to appear in multiple
collections. This capability is useful for several reasons:
Organizing resources into hierarchies places them into smaller Organizing resources into hierarchies places them into smaller
groupings, known as collections, which are more easily browsed and groupings, known as collections, which are more easily browsed and
manipulated than a flat namespace. However, hierarchies require manipulated than a flat namespace. However, hierarchies require
categorization decisions that locate resources at a single location in categorization decisions that locate resources at a single location in
the hierarchy, a drawback when a resource has multiple valid categories. the hierarchy, a drawback when a resource has multiple valid categories.
For example, in a hierarchy of vehicle descriptions containing For example, in a hierarchy of vehicle descriptions containing
collections for cars and boats, a description of a combination car/boat collections for cars and boats, a description of a combination car/boat
vehicle could belong in either collection. Ideally, the description vehicle could belong in either collection. Ideally, the description
should be accessible from both. should be accessible from both.
Hierarchies also make resource sharing more difficult, since resources Hierarchies also make resource sharing more difficult, since resources
that have utility across many collections are still forced into a single that have utility across many collections are still forced into a single
collection. For example, the mathematics department at one university collection. For example, the mathematics department at one university
might create a collection of information on fractals that contains might create a collection of information on fractals that contains
bindings to some local resources, but also provides access to some bindings to some local resources, but also provides access to some
resources at other universities. For many reasons, it may be resources at other universities. For many reasons, it may be
undesirable to make physical copies of the shared resources on the local undesirable to make physical copies of the shared resources on the local
server - to conserve disk space, to respect copyright constraints, or to server û to conserve disk space, to respect copyright constraints, or to
make any changes in the shared resources visible automatically. make any changes in the shared resources visible automatically.
The companion specification [RR] defines redirect references, one The companion specification [RR] defines redirect references, one
mechanism for providing access to a single resource from multiple mechanism for providing access to a single resource from multiple
collections. A redirect reference is a resource in one collection whose collections. A redirect reference is a resource in one collection whose
purpose is to forward requests to another resource (its target), usually purpose is to forward requests to another resource (its target), usually
in a different collection. In this way, it provides access to the in a different collection. In this way, it provides access to the
target resource from another collection. It redirects most requests to target resource from another collection. It redirects most requests to
the target resource using the HTTP 302 (Moved Temporarily) status code, the target resource using the HTTP 302 (Moved Temporarily) status code,
thereby providing a form of mediated access to the target resource. thereby providing a form of mediated access to the target resource.
The BIND method defined here provides a different mechanism for allowing The BIND method defined here provides a different mechanism for allowing
a single resource to appear in multiple collections. It lets clients a single resource to appear in multiple collections. BIND lets clients
associate a new URI with an existing resource. This URI can then be associate a new URI with an existing resource, and this URI can then be
used to submit requests to the resource. Since URIs in WebDAV are used to submit requests to the resource. Since URIs in WebDAV are
hierarchical, and correspond to a hierarchy of collections in resource hierarchical, and correspond to a hierarchy of collections in resource
space, the BIND method also has the effect of adding the resource to a space, the BIND method also has the effect of adding the resource to a
collection. As new URIs are associated with the resource, it appears in collection. As new URIs are associated with the resource, it appears in
additional collections. additional collections.
These two approaches to allowing clients to add a single resource to These two approaches to allowing clients to add a single resource to
multiple collections have very different characteristics: multiple collections have very different characteristics:
A redirect reference is a resource, and so can have properties of its A redirect reference is a resource, and so can have properties of its
own. Such information as who created the reference, when, and why can own. Such information as who created the reference, when, and why can
be stored on the redirect reference resource. Since redirect references be stored on the redirect reference resource. Since redirect references
are implemented using HTTP 302 responses, it generally takes two round are implemented using HTTP 302 responses, it generally takes two round
trips to submit a request to the intended resource. Servers are not trips to submit a request to the intended resource. Servers are not
required to enforce the integrity of redirect references. Redirect required to enforce the integrity of redirect references. Redirect
references work equally well for local resources and for resources that references work equally well for local resources and for resources that
reside on a different server from the reference. reside on a different server from the reference.
By contrast, a BIND request does not create a new resource, but simply By contrast, a BIND request does not create a new resource, but simply
makes available a new URI for submitting requests to an existing makes available a new URI for submitting requests to an existing
resource. The new URI can be used like any other URI to submit a resource. The new URI can be used like any other URI when submitting a
request to a resource. Only one round trip is needed to submit a request to a resource. Only one round trip is needed to submit a
request to the intended target. Servers are required to enforce the request to the intended target. Servers are required to enforce the
integrity of the relationships between the new URIs clients create and integrity of the relationships between the new URIs clients create and
the resources associated with them. Consequently, it is unlikely that the resources associated with them. Consequently, it is unlikely that
servers will support BIND requests that cross server boundaries. servers will support BIND requests that cross server boundaries.
The remainder of this specification is organized as follows. Section 3
defines terminology used in the rest of the specification, while Section
4 briefly overviews bindings. Section 5 specified the BIND method, used
to create bindings. Sections 6 through 10 discuss the relationships
between bindings and other HTTP and WebDAV methods. Sections 11 and 12
define mechanisms for tracking bindings. Sections 13 through 16 define
the new status codes, headers, properties, and XML elements needed to
support bindings. Section 17 discusses compliance and capability
discovery. Security concerns, internationalization issues, and IANA
considerations are described in Sections 18 through 20. The remaining
sections provide other supporting information.
3 Terminology 3 Terminology
The terminology used here follows and extends that in the WebDAV The terminology used here follows and extends that in the WebDAV
Distributed Authoring Protocol specification [WebDAV]. Definitions of Distributed Authoring Protocol specification [WebDAV]. Definitions of
the terms resource, Uniform Resource Identifier (URI), and Uniform the terms resource, Uniform Resource Identifier (URI), and Uniform
Resource Locator (URL) are provided in [URI]. Resource Locator (URL) are provided in [URI].
URI Mapping URI Mapping
A relation between an absolute URI and a resource. For an A relation between an absolute URI and a resource. For an
absolute URI U and the resource it identifies R, the URI mapping absolute URI U and the resource it identifies R, the URI mapping
can be thought of as the ordered pair (U,R). Since a resource can can be thought of as (U => R). Since a resource can represent
represent items that are not network retrievable, as well as those items that are not network retrievable, as well as those that are,
that are, it is possible for a resource to have zero, one, or many it is possible for a resource to have zero, one, or many URI
URI mappings. Mapping a resource to an "http" scheme URL makes it mappings. Mapping a resource to an "http" scheme URL makes it
possible to submit HTTP protocol requests to the resource using possible to submit HTTP protocol requests to the resource using
the URL. the URL.
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 [URI]. Formally, as defined in section 3.3 of [URI].
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 relative to that So for a collection C, a path segment S, and a resource R, the
collection, and a resource R, the binding can be thought of as the binding can be thought of as C:(S -> R). Bindings create URI
ordered triple (C,S,R). Bindings create URI mappings, and hence mappings, and hence allow requests to be sent to a single resource
allow requests to be sent to a single resource from multiple from multiple locations in a URI namespace.
locations in a URI namespace.
The following figure can be used to illustrate how bindings create The following figure can be used to illustrate how bindings create
URI mappings. URI mappings.
+-----------------------------+ +-----------------------------+
| root collection | | root collection |
|-----------------------------| |-----------------------------|
| bindings: | | bindings: |
| | | |
| Coll1 Coll2 Coll3 | | Coll1 Coll2 Coll3 |
skipping to change at line 251 skipping to change at line 280
| | \ | | / | | | \ | | / |
+--|------\---------+ +-/--------------------+ +--|------\---------+ +-/--------------------+
| \ / | \ /
| \ / | \ /
| \ / | \ /
| \ / | \ /
+--------------+ +---------------+ +--------------+ +---------------+
| resource R1 | | resource R2 | | resource R1 | | resource R2 |
+--------------+ +---------------+ +--------------+ +---------------+
Figure 1 Figure 2
Since there are two bindings in the root collection, Coll1 and
The binding (C1,foo,R1) between foo and resource R1 in collection Coll2, to collection C1, the single binding C1:(foo -> R1) between
C1 creates the URI mappings /Coll1/foo and /Coll2/foo to resource foo and resource R1 in collection C1 creates two URI mappings,
R1. Each of these URI mappings can be used to submit requests to /Coll1/foo and /Coll2/foo, to resource R1. Each of these URI
R1. The binding (C1,bar,R2) between bar and resource R2 in mappings can be used to submit requests to R1. The binding
collection C1 and the binding (C2,foo,R2) between foo and resource C1:(bar -> R2) between bar and resource R2 in collection C1 and
R2 in collection C2 create altogether 3 URI mappings to resource the binding C2:(foo -> R2) between foo and resource R2 in
R2: /Coll1/bar, /Coll2/bar, and /Coll3/foo. All 3 URI mappings collection C2 create altogether 3 URI mappings to resource R2:
can be used to submit requests to resource R2. /Coll1/bar, /Coll2/bar, and /Coll3/foo. All 3 URI mappings can be
used to submit requests to resource R2.
Collection Collection
A resource that contains, as part of its state, a set of bindings A resource that contains, as part of its state, a set of bindings
that identify member resources. that identify member resources.
Internal Member URI Internal Member URI
The URI element U of a URI mapping (U,R), created by a binding Informally, the complete set of URLs by which a collectionÆs
that is contained in a collection. The following figure member is known. Formally, the URI element U of a URI mapping
illustrates the relationship between bindings and internal member (U => R), created by a binding that is contained in a collection.
URIs in a collection: The following figure illustrates the relationship between bindings
and internal member URIs in a collection:
+-----------------------------+ +-----------------------------+
| root collection | | root collection |
|-----------------------------| |-----------------------------|
| internal member URIs: | | internal member URIs: |
| | | |
| /Coll1/ | | /Coll1/ |
| /Coll2/ | | /Coll2/ |
| /Coll3/ | | /Coll3/ |
|-----------------------------| |-----------------------------|
skipping to change at line 311 skipping to change at line 342
| | \ | / | | \ | /
+--|------\------------+ / +--|------\------------+ /
| \ / | \ /
| \ / | \ /
| \ / | \ /
| \ / | \ /
+--------------+ +---------------+ +--------------+ +---------------+
| resource R1 | | resource R2 | | resource R1 | | resource R2 |
+--------------+ +---------------+ +--------------+ +---------------+
Figure 2 Figure 3
The URI elements of all URI mappings created by a collection's The URI elements of all URI mappings created by a collection's
bindings are internal member URIs of the collection. bindings are internal member URIs of the collection.
However, for a given request, only the URIs from those URI However, for a given request, only the URIs from those URI
mappings that incorporate the Request-URI are treated as internal mappings that incorporate the Request-URI are treated as internal
member URIs. For example, in Figure 2 above, if a PROPFIND member URIs. For example, in Figure 3 above, if a PROPFIND
request with "Depth: infinity" is submitted to collection C1 using request with "Depth: infinity" is submitted to collection C1 using
the Request-URI /Coll1/, only the URI mappings starting with the the Request-URI /Coll1/, only the URI mappings starting with the
Request-URI would be listed as internal member URIs. The response Request-URI would be listed as internal member URIs. The response
would include only /Coll1/ itself and the internal member URIs would include only /Coll1/ itself and the internal member URIs
/Coll1/foo and /Coll1/bar. /Coll1/foo and /Coll1/bar. This is done to prevent large amounts
of duplicate information from being returned for operations on
collections.
In [WebDAV], a collection is defined as containing a list of In [WebDAV], a collection is defined as containing a list of
internal member URIs, where an internal member URI is the URI of internal member URIs, where an internal member URI is the URI of
the collection, plus a single path segment. This definition the collection, plus a single path segment. This definition
combines the two concepts of binding and URI mapping that are combines the two concepts of binding and URI mapping that are
separated in this specification. As a result, this specification separated in this specification. As a result, this specification
redefines a collection's state to be a set of bindings, and redefines a collection's state to be a set of bindings, and
redefines an internal member URI to be the URI of a URI mapping redefines an internal member URI to be the URI of a URI mapping
derived from a binding. After this redefinition, an internal derived from a binding. After this redefinition, an internal
member URI can be used when reading [WebDAV] without loss of member URI can be used when reading [WebDAV] without loss of
meaning. For purposes of interpretation, when [WebDAV] discusses a meaning. For purposes of interpretation, when [WebDAV] discusses a
collection "containing" an internal member URI, this should be collection "containing" an internal member URI, this should be
read as the collection containing a binding whose mapping to a URI read as the collection containing a binding whose mapping to a URI
creates an internal member URI, in this sense "containing" the creates an internal member URI, in this sense "containing" the
internal member URI. The authors of this specification anticipate internal member URI. The authors of this specification anticipate
and recommend that future revisions of [WebDAV] perform a full and recommend that future revisions of [WebDAV] perform a full
reconciliation of terms between these two specifications. reconciliation of terms between these two specifications.
3.1 Rationale for Distinguishing Bindings from URI Mappings
Consider again collection C1 in Figure 3. If we had only the notion of
URI mappings, we would be forced to say that C1's membership was defined
by the list of internal member URIs. If these URIs identify the
membership, and are part of the state of the collection, then the act of
making the collection available via a new URI has the effect of changing
the collectionÆs membership, hence changing the collectionÆs state. This
is undesirable, since ideally a collectionÆs membership should remain
the same, no matter what URIs can be used to access the collection. What
is needed is a way to separate the final segment of a URI from the
collectionÆs URI contribution.
The notion of binding is introduced to separate the final segment of a
URI from its parent collectionÆs contribution. This done, a collection
can be defined as containing a set of bindings, thus permitting a new
mapping to be defined to a collection without modifying its membership
state. We introduce the concept of URI mapping to combine together the
collectionÆs URI and a bindingÆs segment to create a full URI that can
be used in protocol requests. Finally, the internal member URI, first
defined in [WebDAV], is redefined here to maintain backward
compatibility with that specification.
4 Overview of Bindings 4 Overview of Bindings
Bindings are part of the state of a collection. In general, there is a Bindings are part of the state of a collection. In general, there is a
one-to-many correspondence between a collection's bindings and its one-to-many correspondence between a collection's bindings and its
internal member URIs, as illustrated in Figure 2 above. The URI segment internal member URIs, as illustrated in Figure 3 above. The URI segment
associated with a resource by one of a collection's bindings is also the associated with a resource by one of a collection's bindings is also the
final segment of one or more of the collection's internal member URIs. final segment of one or more of the collection's internal member URIs.
The final segment of each internal member URI identifies one of the The final segment of each internal member URI identifies one of the
bindings that is part of the collection's state, unless the internal bindings that is part of the collection's state.
member URI is not mapped to a resource.
Even though a binding is just a relation between a path segment in a
collection and a resource, a binding creates one or more URI mappings of
a URI to a resource. For example, if the segment "foo.html" is being
bound to a resource in a collection with URL "http://www.foo.net/A/",
the binding creates a URI mapping of URL "http://www.foo.net/A/foo.html"
to the HTML resource. If the parent collection is then bound to the
segment "B", this creates two URI mappings, "http://www.foo.net/B/" to
the collection resource, and "http://www.foo.net/B/foo.html" to the HTML
resource. Both the collection and the HTML resource are now accessible
via two URLs apiece.
For a resource implemented by a computer, the relationship between a URI
mapping and a resource is highlighted in Figure 1:
URI 1 URI 2 ... URI N
| | |
| | | <------- URI Mappings
| | |
+---------------------+
| Resource R |
+---------------------+
Figure 3
This resource can have multiple URIs mapped to it.
Bindings are not unique to advanced collections, although the BIND Bindings are not unique to advanced collections, although the BIND
method for explicitly creating bindings is introduced here. Existing method for explicitly creating bindings is introduced here. Existing
methods that create resources, such as PUT, MOVE, COPY, and MKCOL, methods that create resources, such as PUT, MOVE, COPY, and MKCOL,
implicitly create bindings. There is no difference between implicitly implicitly create bindings. There is no difference between implicitly
created bindings and bindings created with BIND. created bindings and bindings created with BIND.
The identity of a binding (C,S,R) is determined by the URI segment (in The identity of a binding C:(S -> R) is determined by the URI segment
its collection) and the resource that the binding associates. If the (in its collection) and the resource that the binding associates. If
resource goes out of existence (as a result of some out-of-band the resource goes out of existence (as a result of some out-of-band
operation), the binding also goes out of existence. If the URI segment operation), the binding also goes out of existence. If the URI segment
comes to be associated with a different resource, the original binding comes to be associated with a different resource, the original binding
ceases to exist and another binding is created. ceases to exist and another binding is created.
Since a binding is a relation between a path segment in a collection and Since a binding is a relation between a path segment in a collection and
a resource, it would be very undesirable if one binding could be a resource, it would be very undesirable if one binding could be
destroyed as a side effect of operating on the resource through a destroyed as a side effect of operating on the resource through a
different binding. It is not acceptable for a MOVE through one binding different binding. It is not acceptable for a MOVE through one binding
to fail to update another binding, turning that binding into a dangling to disrupt another binding, turning that binding into a dangling path
path segment. Nor is it acceptable for a server, after performing a segment. Nor is it acceptable for a server, after performing a DELETE
DELETE through one binding, to reclaim the system resources associated through one binding, to reclaim the system resources associated with its
with its resource while other bindings to the resource remain. resource while other bindings to the resource remain. Implementations
Implementations MUST act to ensure the integrity of bindings. MUST ensure the integrity of bindings.
It is especially difficult to maintain the integrity of cross-server
bindings. Unless the server where the resource resides knows about all
bindings on all servers to that resource, it may unwittingly destroy the
resource or move it without notifying another server that manages a
binding to the resource. For example, if server A permits creation of a
binding to a resource on server B, server A must notify server B about
its binding and must have an agreement with B that B will not destroy
the resource while A's binding exists. Otherwise server B may receive a
DELETE request that it thinks removes the last binding to the resource
and destroy the resource while A's binding still exists.
Consequently, support for cross-server bindings is OPTIONAL.
5 BIND Method 5 BIND Method
5.1 Overview of BIND 5.1 Overview of BIND
The BIND method creates a new binding from the final segment of the The BIND method creates a new binding between the resource identified by
Request-URI (minus any trailing slash) to the resource identified the Request-URI and the final segment of the Destination header (minus
by the Destination header. This binding is added to the collection any trailing slash). This binding is added to the collection identified
identified by the Request-URI minus its trailing slash (if present) and by the Destination header minus its trailing slash (if present) and
final segment. The Destination header is defined in Section 9.3 of final segment. The Destination header is defined in Section 9.3 of
[WebDAV]. [WebDAV].
If a server cannot guarantee the binding behavior specified for GET If a server cannot guarantee the binding behavior specified here,
(Section 10), DELETE (Section 6), and MOVE (Section 8), the BIND request including the guarantee of the integrity of the binding, the BIND
MUST fail with a 501 (Not Implemented) status code. request MUST fail.
If the Request-URI ends in a slash ("/") (i.e., the Request-URI Note: It is especially difficult to maintain the integrity of cross-
identifies a collection), the resource identified by the Destination server bindings. Unless the server where the resource resides knows
header MUST be a collection resource, or the request fails with a 409 about all bindings on all servers to that resource, it may unwittingly
(Conflict) status code. This ensures that URIs ending in a slash are destroy the resource or move it without notifying another server that
always bound to collections. If the Request-URI does not contain a path manages a binding to the resource. For example, if server A permits
segment (i.e., it consists simply of a slash "/"), the BIND operation creation of a binding to a resource on server B, server A must notify
MUST fail and report a 409 (Conflict) status code. server B about its binding and must have an agreement with B that B will
not destroy the resource while A's binding exists. Otherwise server B
may receive a DELETE request that it thinks removes the last binding to
the resource and destroy the resource while A's binding still exists.
Since most servers will be forced to fail cross-server BIND requests
because they are unable to guarantee the integrity of cross-server
bindings, status code 508 (Cross-server Binding Forbidden) is defined in
Section 13.3.
After successful processing of a BIND request, it MUST be possible for If the Destination header does not contain a path segment (i.e., it
clients to use the Request-URI to submit requests to the resource consists simply of a slash "/"), the BIND operation MUST fail and report
identified by the Destination header. a 400 (Bad Request) status code. A binding consists of a (collection,
segment, resource) triple, and the Destination header is required to
specify the collection and segment of this triple.
By default, if the Request-URI identifies an existing binding, the new After successful processing of a BIND request, it MUST be possible for
clients to use the URI in the Destination header to submit requests to
the resource identified by the Request-URI.
binding replaces the existing binding. This default binding replacement By default, if the Destination header identifies an existing binding,
behavior can be overridden using the Overwrite header defined in Section the new binding replaces the existing binding. This default binding
9.6 of [WebDAV]. replacement behavior can be overridden using the Overwrite header
defined in Section 9.6 of [WebDAV].
5.2 Bindings to Collections 5.2 Bindings to Collections
BIND can create a binding to a collection resource. A collection BIND can create a binding to a collection resource. A collection
accessed through such a binding behaves exactly as would a collection accessed through such a binding behaves exactly as would a collection
accessed through any other binding. Bindings to collections can result accessed through any other binding.
in loops, which servers MUST detect when processing "Depth: infinity"
requests. When a loop is detected, the server MUST respond with a 506 Bindings to collections can result in loops, which servers MUST detect
(Loop Detected) status code (defined in Section 13.1). when processing "Depth: infinity" requests. It is sometimes possible to
complete an operation in spite of the presence of a loop. However, the
506 (Loop Detected) status code is defined in Section 13.1 for use in
contexts where an operation is terminated because a loop was
encountered. Some servers may wish to prevent loops from being created
at all. These servers MAY fail BIND requests with the 507 (Loop
Forbidden) status code defined in Section 13.2.
Creating a new binding to a collection makes each resource associated Creating a new binding to a collection makes each resource associated
with a binding in that collection accessible via a new URI, but does not with a binding in that collection accessible via a new URI, and thus
result in the creation of a new binding for each of these resources. creates new URI mappings to those resources but no new bindings.
For example, suppose a new binding COLLX is created for collection C1 in For example, suppose a new binding COLLX is created for collection C1 in
the figure below. It immediately becomes possible to access resource R1 the figure below. It immediately becomes possible to access resource R1
using the URI /COLLX/x.gif and to access resource R2 using the URI using the URI /COLLX/x.gif and to access resource R2 using the URI
/COLLX/y.jpg, but no new bindings for these child resources were /COLLX/y.jpg, but no new bindings for these child resources were
created. This is because bindings are part of the state of a created. This is because bindings are part of the state of a
collection, and associate a URI that is *relative to that collection* collection, and associate a URI that is relative to that collection with
with its target resource. No change to the bindings in Collection C1 is
its target resource. No change to the bindings in Collection C1 is
needed to make its children accessible using /COLLX/x.gif and needed to make its children accessible using /COLLX/x.gif and
/COLLX/y.jpg. /COLLX/y.jpg.
+-------------------------+ +-------------------------+
| Root Collection | | Root Collection |
| (properties) | | (properties) |
| bindings: | | bindings: |
| coll1 COLLX | | coll1 COLLX |
+-------------------------+ +-------------------------+
| / | /
skipping to change at line 494 skipping to change at line 529
| bindings: | | bindings: |
| x.gif y.jpg | | x.gif y.jpg |
+------------------+ +------------------+
| \ | \
| \ | \
| \ | \
+-------------+ +-------------+ +-------------+ +-------------+
| Resource R1 | | Resource R2 | | Resource R1 | | Resource R2 |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 4 Figure 6
5.3 URI Mappings Created by BIND 5.3 URI Mappings Created by a BIND
The set of URI mappings created by a successful BIND operation MUST be Suppose a BIND request causes a binding from "Binding-Name" to resource
determined as follows: R to be added to a collection, C. Then if C-MAP is the set of URI's
that were mapped to C before the BIND request, then for each URI "C-URI"
in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following
the BIND request.
1. Start with an empty set of URLs, called U. Note that if R is a collection, additional URI mappings are created to
2. Take the Request-URI and remove path segments (and associated "/" the descendents of R. Also note that if a binding is made in collection
characters) from the right until either (a) a non-WebDAV collection is C to C itself (or to a parent of C), an infinite number of mappings is
found, or (b) the root, "/" is reached (i.e., no characters after the introduced.
scheme and authority parts of the URL). This is the base URL B.
3. Add B, and all possible domain name variants of B (i.e., all other
domain names which can be substituted for the domain name in B, and
still retrieve the resource mapped to B), to URL set U.
4. Calculate the next path segment of the Request-URI, going from left
to right, and call it S, which is bound to resource R.
5. For each member of URL set U, called Um, remove Um, then for every
possible binding to R, create a new URL by adding the binding's path
segment to Um, then add this new URL to U.
6. If there is no further path segment, then U has the complete set of
URI mappings. Otherwise, go back to step 4.
5.4 Example: Generating the Set of URI Mappings 5.4 Example: URI Mappings Created by a BIND
Assume a server responds to two domain names, www.fuzz.com, and For example, if a binding from "foo.html" to R is added to the
fuzz.com, and has a top level that is not WebDAV-aware, called A/. collection C, and if the following URI's are mapped to C:
Below A/ is WebDAV-aware collection that is bound to both 1/ and one/.
In collection one/ there is a resource called index.html.
>> Request: http://www.fuzz.com/A/1
http://fuzz.com/A/one
BIND /A/1/info.html HTTP/1.1 then the following new mappings to R are introduced:
Host: www.fuzz.com
Destination: http://www.fuzz.com/A/one/index.html
>> Response: http://www.fuzz.com/A/1/foo.html
http://fuzz.com/A/one/foo.html
HTTP/1.1 201 Created If a binding from "myself" to C is then added to C, the following
The set of all possible URI mappings to the resource identified by infinite number of additional mappings to C are introduced:
http://www.fuzz.com/A/one/index.html is calculated as follows:
1. U is empty. http://www.fuzz.com/A/1/myself
2. The base URL, B, is http://www.fuzz.com/A/, since A/ is not WebDAV- http://www.fuzz.com/A/1/myself/myself
aware. ...
3. Since there are two domain names for this server, the domain name
variations of B are added to U, making U contain: http://www.fuzz.com/A/
and http://fuzz.com/A/.
4. (iteration 1) The next path segment of the Request-URI is 1/, which
is bound to a collection resource, R.
5. (iteration 1) Since the collection resource R is bound to 1/ and
one/, the value of U after the operation is: http://www.fuzz.com/A/1/,
http://www.fuzz.com/A/one/, http://fuzz.com/A/1/, and
http://fuzz.com/A/one/.
6. Go back to step 4, since there is one more path segment in the
Request-URI.
4. (iteration 2) The next path segment of the Request-URI is info.html,
which is bound to an HTML resource, R.
5. (iteration 2) Since the HTML resource is bound to info.html and
index.html, the value of U after the operation is:
http://www.fuzz.com/A/1/index.html, http://www.fuzz.com/A/1/info.html, and the following infinite number of additional mappings to R are
http://www.fuzz.com/A/one/index.html, introduced:
http://www.fuzz.com/A/one/info.html, http://fuzz.com/A/1/index.html,
http://fuzz.com/A/1/info.html, http://fuzz.com/A/one/index.html, http://www.fuzz.com/A/1/myself/foo.html
http://fuzz.com/A/one/info.html. http://www.fuzz.com/A/1/myself/myself/foo.html
6. Since there are no further path segments in the Request-URI, U now ...
has the complete set of URI mappings for the resource identified by the
Destination header.
5.5 BIND Status Codes 5.5 BIND Status Codes
201 (Created): The binding was successfully created. 201 (Created): The binding was successfully created.
400 (Bad Request): The client set an invalid value for the Destination 400 (Bad Request): The client set an invalid value for the Destination
header. header or Request-URI.
409 (Conflict): Several conditions may produce this response. The URI
in the Destination header is not mapped to a resource. The request is
attempting to create a binding in a collection that does not exist. The
request is attempting to re-bind the top-level collection.
412 (Precondition Failed): The Overwrite header is "F", and a binding 412 (Precondition Failed): The Overwrite header is "F", and a binding
already exists for the request-URI. already exists for the Destination header.
507 (Loop Forbidden): The server does not support bindings that create
loops.
508 (Cross-Server Binding Forbidden): The server is unable to create the
requested binding because it would bind a segment in a collection on one
server to a resource on a different server.
5.6 Example: BIND 5.6 Example: BIND
>> Request: >> Request:
BIND /~whitehead/dav/spec08.txt HTTP/1.1 BIND /pub/i-d/draft-webdav-protocol-08.txt HTTP/1.1
Host: www.ics.uci.edu Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/pub/i-d/draft-webdav-protocol-08.txt Destination: http://www.ics.uci.edu/~whitehead/dav/spec08.txt
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
The server created a new binding, associating "spec08.txt" with the The server created a new binding, associating "spec08.txt" with the
resource identified by the URL "http://www.ics.uci.edu/pub/i-d/draft- resource identified by the URL "http://www.ics.uci.edu/pub/i-d/draft-
webdav-protocol-08.txt". Clients can now use the Request-URI, webdav-protocol-08.txt". Clients can now use the URI in the Destination
"http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit requests header, "http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit
to that resource. As part of this operation, the server added the requests to that resource. As part of this operation, the server added
binding "spec08.txt" to collection /~whitehead/dav/. the binding "spec08.txt" to collection /~whitehead/dav/.
5.7 Example: BIND Conflict
>> Request:
BIND /press/prlogo.gif HTTP/1.1
Host: www.softcorp.com
Destination: http://www.softcorp.com/logos/
>> Response:
HTTP/1.1 409 Conflict 6 DELETE and Bindings
The client requested the server to create a binding between "prlogo.gif" The DELETE method was originally defined in [HTTP]. This section
and the resource identified by the URL "http://www.softcorp.com/logos/". redefines the behavior of DELETE in terms of bindings, an abstraction
Since the Destination does end in a slash, while the Request-URI does not available when writing [HTTP]. [HTTP] states that "the DELETE method
not, the server failed the request, returning a 409 (Conflict) status requests that the origin server delete the resource identified by the
code.
6 DELETE and Bindings Request-URI." Because [HTTP] did not distinguish between bindings and
resources, the intent of its definition of DELETE is unclear. The
definition presented here is a clarification of the definition in
[HTTP].
The DELETE method requests that the server remove the binding between The DELETE method requests that the server remove the binding between
the resource identified by the Request-URI and the binding name, the the resource identified by the Request-URI and the binding name, the
last path segment of the Request-URI. The binding MUST be removed from last path segment of the Request-URI. The binding MUST be removed from
its parent collection, identified by the Request-URI minus its trailing its parent collection, identified by the Request-URI minus its trailing
slash (if present) and final segment. The All-Bindings header may be slash (if present) and final segment. The All-Bindings header may be
used with DELETE to request that the server remove all bindings to the used with DELETE to request that the server remove all bindings to the
resource identified by the Request-URI. resource identified by the Request-URI.
Once all bindings to the resource are removed, the server MAY reclaim Once a set of resources are unreachable by any URI mapping, the server
system resources associated with the resource. If DELETE removes a MAY reclaim system resources associated with those resources. If DELETE
binding to a resource, but there remain other bindings to that resource, removes a binding to a resource, but there remain URI mappings to that
the server MUST NOT reclaim system resources associated with the resource, the server MUST NOT reclaim system resources associated with
resource. the resource.
Since DELETE as specified in [WebDAV] is not an atomic operation, it may
happen that parts of the hierarchy under the request-URI cannot be
deleted. In this case, the response is as described in [WebDAV].
[HTTP] states that "the DELETE method requests that the origin server Although [WebDAV] allows a DELETE to be a non-atomic operation, the
delete the resource identified by the Request-URI." Because [HTTP] did DELETE operation defined here is atomic. In particular, a DELETE with
not distinguish between bindings and resources, the intent of its an All-Bindings header MUST fail if any of the bindings to the resource
definition of DELETE is unclear. We consider the definition presented cannot be deleted. In addition, a DELETE on a hierarchy of resources is
here to be a clarification of the definition in [HTTP]. simply the removal of a binding to the collection identified by the
Request-URI, and so is a single (and therefore atomic) operation.
Section 8.6.1 of [WebDAV] states that during DELETE processing, a server Section 8.6.1 of [WebDAV] states that during DELETE processing, a server
"MUST remove any URI for the resource identified by the Request-URI from "MUST remove any URI for the resource identified by the Request-URI from
collections which contain it as a member." Servers that support collections which contain it as a member." Servers that support
bindings SHOULD NOT follow this requirement. bindings SHOULD NOT follow this requirement unless the All-Bindings
header is included in the request.
7 COPY and Bindings 7 COPY and Bindings
As defined in Section 8.8 of [WebDAV], COPY causes the resource As defined in Section 8.8 of [WebDAV], COPY causes the resource
identified by the Request-URI to be duplicated, and makes the new identified by the Request-URI to be duplicated, and makes the new
resource accessible using the URI specified in the Destination header. resource accessible using the URI specified in the Destination header.
Upon successful completion of a COPY, a new binding is created between Upon successful completion of a COPY, a new binding is created between
the last path segment of the Destination header (including trailing "/", the last path segment of the Destination header, and the destination
if present), and the destination resource. The new binding is added to resource. The new binding is added to its parent collection, identified
its parent collection, identified by the Destination header minus its by the Destination header minus its trailing slash (if present) and
trailing slash (if present) and final segment. final segment.
As an example, suppose that a COPY is issued to URI 3 for resource R As an example, suppose that a COPY is issued to URI 3 for resource R
below (which is also mapped to URI 1 and URI 2), with the Destination below (which is also mapped to URI 1 and URI 2), with the Destination
header set to URIX. After successful completion of the COPY operation, header set to URIX. After successful completion of the COPY operation,
resource R is duplicated to create resource R', and a new binding has resource R is duplicated to create resource R', and a new binding has
been created which creates at least the URI mapping between URIX and the been created which creates at least the URI mapping between URIX and the
new resource (although other URI mappings may also have been created). new resource (although other URI mappings may also have been created).
URI 1 URI 2 URI 3 URIX URI 1 URI 2 URI 3 URIX
| | | | | | | |
skipping to change at line 671 skipping to change at line 670
header set to URIX. After successful completion of the COPY operation, header set to URIX. After successful completion of the COPY operation,
resource R is duplicated to create resource R', and a new binding has resource R is duplicated to create resource R', and a new binding has
been created which creates at least the URI mapping between URIX and the been created which creates at least the URI mapping between URIX and the
new resource (although other URI mappings may also have been created). new resource (although other URI mappings may also have been created).
URI 1 URI 2 URI 3 URIX URI 1 URI 2 URI 3 URIX
| | | | | | | |
| | | <---- URI Mappings ----> | | | | <---- URI Mappings ----> |
| | | | | | | |
+---------------------+ +------------------------+ +---------------------+ +------------------------+
| Resource R | | Resource R' | | Resource R | | Resource R' |
+---------------------+ +------------------------+ +---------------------+ +------------------------+
Figure 5 Figure 7
It might be thought that a COPY request with "Depth: 0" on a collection It might be thought that a COPY request with "Depth: 0" on a collection
would duplicate its bindings, since bindings are part of the would duplicate its bindings, since bindings are part of the
collection's state. This is not the case, however. The definition of collection's state. This is not the case, however. The definition of
Depth in [WebDAV] makes it clear that a "Depth: 0" request does not Depth in [WebDAV] makes it clear that a "Depth: 0" request does not
apply to a collection's members. Consequently, a COPY with "Depth: 0" apply to a collection's members. Consequently, a COPY with "Depth: 0"
does not duplicate the bindings contained by the collection. does not duplicate the bindings contained by the collection.
8 MOVE and Bindings 8 MOVE and Bindings
skipping to change at line 721 skipping to change at line 721
>> After Request: >> After Request:
URI 1 URI 2 URIX URI 1 URI 2 URIX
| | | | | |
| | | <---- URI Mappings | | | <---- URI Mappings
| | | | | |
+---------------------+ +---------------------+
| Resource R | | Resource R |
+---------------------+ +---------------------+
Figure 6 Figure 8
Since MOVE as specified in [WebDAV] is not an atomic operation, it may Although [WebDAV] allows a MOVE on a collection to be a non-atomic
happen that parts of the hierarchy under the request-URI cannot be operation, the MOVE operation defined here MUST be atomic. Even when
moved. In this case, the response is as described in [WebDAV]. the Request-URI identifies a collection, the MOVE operation involves
only removing one binding to that collection and adding another. There
are no operations on bindings to any of its children, so the case of
MOVE on a collection is the same as the case of MOVE on a non-collection
resource. Both are atomic.
8.1 Implementation Note 8.1 Implementation Note
In some situations, particularly when the destination is on a different In some situations, particularly when the destination is on a different
server from the original resource, the server may implement MOVE by server from the original resource, the server may implement MOVE by
performing a COPY, performing some consistency maintenance on bindings performing a COPY, performing some consistency maintenance on bindings
and properties, and then performing a DELETE. In the end, all of the and properties, and then performing a DELETE. In the end, all of the
original bindings except the one corresponding to the Request-URI will original bindings except the one corresponding to the Request-URI will
be associated with the new resource. The binding corresponding to the be associated with the new resource. The binding corresponding to the
URI in the Destination header will be associated with the new resource. URI in the Destination header will be associated with the new resource.
And the original resource together with the binding corresponding to the And the original resource together with the binding corresponding to the
Request-URI will have been deleted. This implementation is in accord Request-URI will have been deleted. This implementation is logically
with the definition of MOVE in [WebDAV], and is logically equivalent to equivalent to the definition of MOVE given in Section 8 above.
the definition given above.
The consistency maintenance processing that is required for this The consistency maintenance processing that is required for this
implementation is as follows: implementation is as follows:
The DAV:creationdate property of the new resource SHOULD have the same The DAV:creationdate property of the new resource SHOULD have the same
value as the DAV:creationdate property of the old resource. value as the DAV:creationdate property of the old resource.
The DAV:getlastmodified property of the new resource SHOULD have the The DAV:getlastmodified property of the new resource SHOULD have the
same value as the DAV:getlastmodified property of the old resource. same value as the DAV:getlastmodified property of the old resource.
skipping to change at line 784 skipping to change at line 788
>> After Request: >> After Request:
URI1 URI2 --------------------------------- URIX URI1 URI2 --------------------------------- URIX
| | | | | |
----------------------------------------- | | ----------------------------------------- | |
| | | | | |
+---------------------+ +------------------------+ +---------------------+ +------------------------+
| Resource R | | Resource R' | | Resource R | | Resource R' |
+---------------------+ +------------------------+ +---------------------+ +------------------------+
Figure 7 Figure 9
8.2 MOVE and Locks
The MOVE semantics defined in Section 8 above implies lock behavior that
is different from that specified in Section 7.7 of [WebDAV]. Section
7.7 of [WebDAV] states, "A successful MOVE request on a write locked
resource MUST NOT move the write lock with the resource."
However, the semantics of MOVE defined here say that MOVE does nothing
but remove one binding to a resource and create another binding to the
same resource. The resource itself is not modified. Its state after
the MOVE should be as nearly as possible identical to its state before
the MOVE. Therefore, if it was locked before the MOVE, it MUST be
locked after the MOVE, and with the same lock token. If this
requirement cannot be met, the MOVE MUST fail.
Specifically, the following rules apply to MOVE and locks:
1. If there is a lock on the resource before the MOVE, and that lock is
rooted at the resource (that is, it is not inherited from a parent
collection), the resource MUST still have that same lock after the
MOVE. (This conflicts with [WebDAV].)
2. If there is a lock on the resource at the destination URL before the
MOVE, and that lock is rooted at the destination resource (that is,
it is not inherited from a parent collection), that lock does not
apply to the resource that is moved to that Destination after the
MOVE. (This is consistent with [WebDAV].)
3. If the resource being moved inherits a lock from a parent collection,
and the resource is moved out of the tree affected by that lock, the
lock no longer applies to the resource after the MOVE. (This is
consistent with [WebDAV].)
4. If the resource at the destination URL inherits a lock from a parent
collection before the MOVE, the moved resource inherits that lock
after the MOVE. (This is consistent with [WebDAV].)
5. If there is a lock on the resource before the MOVE, and that lock is
rooted at the resource, and the resource at the destination URL
inherits a lock from a parent collection before the MOVE, the MOVE
MUST fail due to a conflict between rules 1 and 4. (This conflicts
with [WebDAV].)
6. If a collection is MOVEd, and there are some locked resources in that
collection, those resources MUST still have the same locks after the
MOVE. (This conflicts with [WebDAV].)
The results of applying these rules are as follows:
+-------------------------------------------------------------------+
| Before MOVE | After MOVE |
|---------------------------------------------| |
| Source Resource S | Destination Resource D | |
|--------------------------------------------------------------------
| no lock | no lock | no lock |
|-------------------|-------------------------|---------------------|
| no lock | lock rooted at D | no lock |
|-------------------|-------------------------|---------------------|
| no lock | inherited lock | D's inherited lock |
| | | applies |
|-------------------|-------------------------|---------------------|
| lock rooted at S | no lock | S's lock applies |
|-------------------|-------------------------|---------------------|
| lock rooted at S | lock rooted at D | S's lock applies |
|-------------------|-------------------------|---------------------|
| lock rooted at S | inherited lock | MOVE fails |
|-------------------|-------------------------|---------------------|
| inherited lock | no lock | no lock |
|-------------------|-------------------------|---------------------|
| inherited lock | lock rooted at D | no lock |
|-------------------|-------------------------|---------------------|
| inherited lock | inherited lock | D's inherited lock |
| | | applies |
+-------------------------------------------------------------------+
9 LOCK and UNLOCK 9 LOCK and UNLOCK
Bindings do not affect the semantics of locks, as specified in [WebDAV]. Bindings do not change the fundamental requirement on locks, stated in
Specifically, the requirement in section 8.10.3 that "a LOCK request on section 8.10.3 of [WebDAV], that "a LOCK request on a resource MUST NOT
a resource MUST NOT succeed if it can not be honored by all the URIs succeed if it can not be honored by all the URIs through which the
through which the resource is accessible" still holds. The LOCK method resource is accessible". The LOCK method locks the resource, and a lock
locks the resource, and a lock is visible via all URIs mapped to that is visible via all URIs mapped to that resource. Similarly, a successful
resource. Similarly, a successful UNLOCK issued via any URI mapping to a UNLOCK issued via any URI mapping to a resource removes the lock from
resource removes the lock from the resource, and this lock removal is the resource, and this lock removal is visible via all URI mappings.
visible via all URI mappings.
When a resource is locked, the lock owner expects to be able to access When a resource is locked, the lock owner expects to be able to access
the resource -- using the same Request-URI that he used to lock the the resource -- using the same Request-URI that he used to lock the
resource -- for as long as he holds the lock. This would not be resource -- for as long as he holds the lock. This would not be
possible if another user could move or delete any of the collections possible if another user could move or delete any of the collections
corresponding to segments of the request-URI. corresponding to segments of the request-URI.
Consequently, for the duration of a lock, it MUST NOT be possible for a Consequently, for the duration of a lock, it MUST NOT be possible for a
principal other than the lock owner to make a locked resource principal other than the lock owner to make a locked resource
inaccessible via the URI mapping used to lock the resource. Only the inaccessible via the URI mapping used to lock the resource. Only the
skipping to change at line 817 skipping to change at line 891
segments of the Request-URI. This restriction does not prevent others segments of the Request-URI. This restriction does not prevent others
from modifying those collections, by adding members to them, removing from modifying those collections, by adding members to them, removing
members from them, or changing their property values. members from them, or changing their property values.
For example, if a user locks /plants/herbs/rosemary.html, it is not For example, if a user locks /plants/herbs/rosemary.html, it is not
possible for another user to move /plants/herbs/ to possible for another user to move /plants/herbs/ to
/plants/flowering/herbs/, or to completely delete /plants/herbs/, though /plants/flowering/herbs/, or to completely delete /plants/herbs/, though
it is possible this delete operation may succeed in deleting everything it is possible this delete operation may succeed in deleting everything
except for /plants/herbs/rosemary.html and /plants/herbs/. except for /plants/herbs/rosemary.html and /plants/herbs/.
Note that this requirement is weaker than the one implied by [WebDAV].
Sections 8.9.6 and 8.9.2 of [WebDAV] together imply that all URI
mappings to a locked resource must be protected. They forbid moving or
deleting any collection that has a locked resource as a descendent. It
is likely that in an environment where multiple URI mappings to a single
resource are common, it will be prohibitively expensive to enforce this
stronger constraint.
10 Bindings and Other Methods 10 Bindings and Other Methods
This section describes the interaction of bindings with those HTTP This section describes the interaction of bindings with those HTTP
methods not yet explicitly discussed. The semantics of the methods GET, methods not yet explicitly discussed. The semantics of the methods GET,
HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of
PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV].
For most of these methods, no new complexities are introduced by For these methods, no new complexities are introduced by allowing
allowing explicit creation of multiple bindings to the same resource. explicit creation of multiple bindings to the same resource. When
For the access operations (GET, HEAD, OPTIONS, and PROPFIND), it is applied to static resources (that is, resources that are not CGI
simply the case that no matter which URI mapping to a given resource is scripts, Active Server Pages, etc.), they obey the following rule:
used as the Request-URI, the response is mediated by that same resource.
The responses may, however, vary depending upon which Request-URI was
used. For example, the response to a GET request may contain the
Request-URI in its entity. o The method submitted through one URI mapping MUST produce the same
results as the same method, with the same headers and entity body,
submitted through any other URI mapping to the same resource.
The same is true for POST. No matter which URI mapping to a given When applied to dynamic resources, it is not possible to state any such
resource is used as the Request-URI, the response is mediated by that rule. For any method, a dynamic resource may be sensitive to the URI
same resource. The changes made on the server and the responses may, mapping used to access it. The resource may produce different results
however, vary depending upon which Request-URI was used. depending upon which URI mapping was used to submit the request.
If the Request-URI of a PUT identifies an existing resource, then a PUT Nevertheless, servers MAY allow new bindings to dynamic resources to be
via one URI mapping to this resource MUST produce the same result as a created using BIND.
PUT with the same headers and request entity body via any other URI
mapping to the same resource. The change made by a PUT via one URI
mapping MUST affect the resource that generates the GET response for all
URI mappings to the same resource.
A PROPPATCH through one URI mapping to a resource MUST produce the same 11 Determining Whether Two Bindings Are to the Same Resource
changes to its properties as the same PROPPATCH request through a
different URI mapping to the same resource.
As specified in [WebDAV], MKCOL cannot overwrite an existing resource. It is useful to have some way of determining whether two bindings are to
MKCOL through any URI mapping to an existing resource must fail. the same resource. Two different resources might have identical
contents and identical values for the properties defined in [WebDAV].
Although the DAV:bindings property defined in Section 15.1 provides this
information, it is an optional property.
The semantics of MKREF are specified in Section nn of [RR]. A MKREF The REQUIRED DAV:guid property defined in Section 15.2 is a resource
through one URI mapping to a resource MUST produce the same result as a identifier, which MUST be unique across all resources for all time. If
MKREF with the same headers through any other URI mapping to the same the values of DAV:guid returned by PROPFIND requests through two
resource. By default, it overwrites the resource with a new redirect bindings are identical, the client can be assured that the two bindings
reference. are to the same resource.
The semantics of ORDERPATCH are specified in Section nn of [OC]. An The DAV:guid property is created, and its value assigned, when the
ORDERPATCH through one URI mapping to a collection MUST produce the same resource is created. The value of DAV:guid MUST NOT be changed. Even
changes to its ordering as the same ORDERPATCH request through any other after the resource is no longer accessible through any URI, that value
URI mapping to the same collection. MUST NOT be reassigned to another resource's DAV:guid property.
11 Discovering the Bindings to a Resource 11.1 davresourceid URI Scheme
The value of DAV:guid is a URI and may use any URI scheme that
guarantees the uniqueness of the value across all resources for all
time. The davresourceid URI scheme defined here is an example of an
acceptable URI scheme.
The davresourceid URI scheme requires the use of the Universal Unique
Identifier (UUID) mechanism, as described in [ISO-11578]. Davresourceid
generators may choose between two methods of creating the identifiers.
They can either generate a new UUID for every davresourceid they create
or they can create a single UUID and then add extension characters. If
the second method is selected, then the program generating the
extensions MUST guarantee that the same extension will never be used
twice with the associated UUID.
DAVResourceID-URI = "davresourceid:" UUID [Extension] ; The UUID
production is the string representation of a UUID, as defined in [ISO-
11578]. Note that white space (LWS) is not allowed between elements of
this production.
Extension = path ; path is defined in Section 3.3 of [URI].
12 Discovering the Bindings to a Resource
An OPTIONAL DAV:bindings property on a resource provides a list of the An OPTIONAL DAV:bindings property on a resource provides a list of the
bindings that associate URI segments with that resource. By retrieving bindings that associate URI segments with that resource. If the
this property, a client can discover the bindings that point to the DAV:bindings property exists on a given resource, it MUST provide a
resource and the collections that contain bindings to the resource. As complete list of all bindings to that resource. By retrieving this
for all DAV: properties, this specification is silent as to how the property, a client can discover the bindings that point to the resource
DAV:bindings property is implemented on the server. and the collections that contain bindings to the resource. As for all
DAV: properties, this specification is silent as to how the DAV:bindings
property is implemented on the server.
Rationale: A number of scenarios require clients to navigate from a Rationale: A number of scenarios require clients to navigate from a
resource to the bindings that point to it, and to the collections that resource to the bindings that point to it, and to the collections that
contain those bindings. This capability is particularly important for contain those bindings. This capability is particularly important for
Document Management Systems. Their clients may need to determine, for Document Management Systems. Their clients may need to determine, for
any object in the DMS, what collections contain bindings to that object. any object in the DMS, what collections contain bindings to that object.
This information can be used for upward navigation through a hierarchy This information can be used for upward navigation through a hierarchy
or to discover related documents in other collections. or to discover related documents in other collections.
Risks: When deciding whether to support the DAV:bindings property, Risks: When deciding whether to support the DAV:bindings property,
server implementers / administrators should balance the benefits it server implementers / administrators should balance the benefits it
provides against the cost of maintaining the property and the security provides against the cost of maintaining the property and the security
risks enumerated in Sections 17.4 and 17.5. risks enumerated in Sections 18.4 and 18.5.
12 Headers 13 Status Codes
12.1 All-Bindings Request Header 13.1 506 Loop Detected
The 506 (Loop Detected) status code indicates that the server terminated
an operation because it encountered an infinite loop while processing a
request with "Depth: infinity".
When this status code is the top-level status code for the operation, it
indicates that the entire operation failed. In this case, the Loop
header can be used in the response to identify the URI that caused the
failure.
When this status code occurs inside a multistatus response, it indicates
only that a loop is being terminated, but does not indicate failure of
the operation as a whole.
For example, consider a PROPFIND request on the following collection:
Coll-1 (bound to collection C)
Foo (bound to resource R)
Bar (bound to collection C)
>> Request:
PROPFIND /Coll-1/ HTTP/1.1
Host: www.somehost.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 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.somehost.com/Coll-1/</D:href>
<D:propstat>
<D:prop>
<D:displayname>Loop Demo</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.somehost.com/Coll-1/Foo</D:href>
<D:propstat>
<D:prop>
<D:displayname>Bird Inventory</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://www.somehost.com/Coll-1/Bar</D:href>
<D:propstat>
<D:prop>
<D:displayname/>
</D:prop>
<D:status>HTTP/1.1 506 Loop Detected</D:status>
</D:propstat>
</D:response>
</D:multistatus>
13.2 507 Loop Forbidden
The server does not allow creation of bindings that create loops.
13.3 508 Cross-Server Binding Forbidden
The server is unable to create the requested binding because it would
bind a segment in a collection on one server to a resource on a
different server.
14 Headers
14.1 All-Bindings Request Header
All-Bindings = "All-Bindings" ":" All-Bindings = "All-Bindings" ":"
The All-Bindings request header may be used with DELETE requests to The All-Bindings request header may be used with DELETE requests to
instruct the server to remove all bindings to the resource identified by instruct the server to remove all bindings to the resource identified by
the Request-URI. the Request-URI.
13 Status Codes 14.2 Loop Header
13.1 506 Loop Detected Loop = "Loop" ":" Coded-URL
The 506 (Loop Detected) status code indicates that the server detected The Loop header is used in 506 (Loop Detected) responses to identify the
an infinite loop while processing a request with "Depth: infinity". URI that caused the operation to fail. Note that the Coded-URL
production is defined in Section 9.4 of [WebDAV].
14 Properties 15 Properties
14.1 bindings Property 15.1 bindings Property
Name: bindings Name: bindings
Namespace: DAV: Namespace: DAV:
Purpose: Enables clients to discover, for any resource, what bindings Purpose: Enables clients to discover, for any resource, what bindings
point to it and what collections contain those bindings. point to it and what collections contain those bindings.
This is an optional property. If present, it is a read-only This is an optional property. If present on a given
property, maintained by the server. resource, it is a read-only property, maintained by the
server, and contains a complete list of all bindings to that
resource.
Value: List of href / segment pairs for all of the bindings that Value: List of href / segment pairs for all of the bindings that
associate URI segments with the resource. The href is an associate URI segments with the resource. The href is an
absolute URI for one URI mapping of the collection absolute URI for one URI mapping of the collection
containing the binding. Since there may be multiple URI containing the binding. Since there may be multiple URI
mappings for this collection, it is necessary to select one mappings for this collection, it is necessary to select one
(preferably the URI mapping contained in the Request-URI of (preferably the URI mapping contained in the Request-URI of
the BIND request) for use in the DAV:bindings property. The the BIND request) for use in the DAV:bindings property. The
segment is the URI segment that identifies the binding segment is the URI segment that identifies the binding
within that collection. within that collection.
<!ELEMENT bindings ((href, segment)*)> <!ELEMENT bindings ((href, segment)*)>
15 XML Elements 15.2 guid Property
15.1 segment XML Element Name: guid
Namespace: DAV:
Purpose: Enables clients to determine whether two bindings are for
the same resource.
Value: URI that is guaranteed unique across all resources for all
time. It may be of the davresourceid URI scheme defined in
Section 12.1 or any other URI scheme that guarantees this
uniqueness.
<!ELEMENT guid (href)>
16 XML Elements
16.1 segment XML Element
Name: segment Name: segment
Namespace: DAV: Namespace: DAV:
Purpose: The segment that names a binding, used in the DAV:bindings Purpose: The segment that names a binding, used in the DAV:bindings
property. property.
Value: segment ; as defined in section 3.3 of [URI]. Value: segment ; as defined in section 3.3 of [URI].
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
16 Capability Discovery 17 Capability Discovery
Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes
with the DAV header in responses to OPTIONS, to indicate which parts of with the DAV header in responses to OPTIONS, to indicate which parts of
the Web Distributed Authoring protocols the resource supports. This the Web Distributed Authoring protocols the resource supports. This
specification defines an OPTIONAL extension to [WebDAV]. It defines a specification defines an OPTIONAL extension to [WebDAV]. It defines a
new compliance class, called bindings, for use with the DAV header in new compliance class, called bindings, for use with the DAV header in
responses to OPTIONS requests. If a resource does support bindings, its responses to OPTIONS requests. If a resource does support bindings, its
response to an OPTIONS request MUST indicate that it does, by listing response to an OPTIONS request MUST indicate that it does, by listing
the new BIND method as one it supports, and by listing the new bindings the new BIND method as one it supports, and by listing the new bindings
compliance class in the DAV header. compliance class in the DAV header.
When responding to an OPTIONS request, any type of resource can include When responding to an OPTIONS request, any type of resource can include
bindings in the value of the DAV header. Doing so indicates that the bindings in the value of the DAV header. Doing so indicates that the
server permits a binding at the request URI. server permits a binding at the request URI.
skipping to change at line 954 skipping to change at line 1159
new compliance class, called bindings, for use with the DAV header in new compliance class, called bindings, for use with the DAV header in
responses to OPTIONS requests. If a resource does support bindings, its responses to OPTIONS requests. If a resource does support bindings, its
response to an OPTIONS request MUST indicate that it does, by listing response to an OPTIONS request MUST indicate that it does, by listing
the new BIND method as one it supports, and by listing the new bindings the new BIND method as one it supports, and by listing the new bindings
compliance class in the DAV header. compliance class in the DAV header.
When responding to an OPTIONS request, any type of resource can include When responding to an OPTIONS request, any type of resource can include
bindings in the value of the DAV header. Doing so indicates that the bindings in the value of the DAV header. Doing so indicates that the
server permits a binding at the request URI. server permits a binding at the request URI.
16.1 Example: Discovery of Support for Bindings 17.1 Example: Discovery of Support for Bindings
>> Request: >> Request:
OPTIONS /somecollection/someresource HTTP/1.1 OPTIONS /somecollection/someresource HTTP/1.1
HOST: somehost.org HOST: somehost.org
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT Date: Tue, 20 Jan 1998 20:52:29 GMT
skipping to change at line 980 skipping to change at line 1186
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, 2, bindings DAV: 1, 2, bindings
The DAV header in the response indicates that the resource The DAV header in the response indicates that the resource
/somecollection/someresource is level 1 and level 2 compliant, as /somecollection/someresource is level 1 and level 2 compliant, as
defined in [WebDAV]. In addition, /somecollection/someresource supports defined in [WebDAV]. In addition, /somecollection/someresource supports
bindings. The Allow header indicates that BIND requests can be bindings. The Allow header indicates that BIND requests can be
submitted to /somecollection/someresource. The Public header shows that submitted to /somecollection/someresource. The Public header shows that
other Request-URIs on the server support additional methods. other Request-URIs on the server support additional methods.
17 Security Considerations 18 Security Considerations
This section is provided to make WebDAV applications aware of the This section is provided to make WebDAV applications 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 protocol Distributed Authoring Protocol specification also apply to this protocol
specification. In addition, bindings introduce several new security specification. In addition, bindings introduce several new security
concerns and increase the risk of some existing threats. These issues concerns and increase the risk of some existing threats. These issues
are detailed below. are detailed below.
17.1 Privacy Concerns 18.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 to 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 different induce users to send private information to a target on a different
server. server.
17.2 Redirect Loops 18.2 Redirect Loops
Although redirect loops were already possible in HTTP 1.1, the Although redirect 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 target create loops accidentally or maliciously. If the binding and its target
are on the same server, the server may be able to detect BIND requests are on the same server, the server may be able to detect BIND requests
that would create loops. Servers are required to detect loops that are that would create loops. Servers are required to detect loops that are
caused by bindings to collections during the processing of any requests caused by bindings to collections during the processing of any requests
with "Depth: infinity". with "Depth: infinity".
17.3 Bindings, and Denial of Service 18.3 Bindings, and Denial of Service
Denial of service attacks were already possible by posting URLs that Denial of service attacks were already possible by posting URLs 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 service introduction of BIND creates a new avenue for similar denial of service
attacks. If cross-server bindings are supported, clients can now create attacks. If cross-server bindings are supported, clients can now create
bindings at heavily used sites to target locations that were not bindings at heavily used sites to target locations that were not
designed for heavy usage. designed for heavy usage.
17.4 Private Locations May Be Revealed 18.4 Private Locations May Be Revealed
If the DAV:bindings property is maintained on a resource, the owners of If the DAV:bindings property is maintained on a resource, the owners of
the bindings risk revealing private locations. The directory structures the bindings risk revealing private locations. The directory structures
where bindings are located are available to anyone who has access to the where bindings are located are available to anyone who has access to the
DAV:bindings property on the resource. Moving a binding may reveal its DAV:bindings property on the resource. Moving a binding may reveal its
new location to anyone with access to DAV:bindings on its resource. new location to anyone with access to DAV:bindings on its resource.
17.5 DAV:bindings and Denial of Service 18.5 DAV:bindings and Denial of Service
If the server maintains the DAV:bindings property in response to If the server maintains the DAV:bindings 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 the hostile attempts to make it devote resources to adding bindings to the
list. list.
18 Internationalization Considerations 19 Internationalization Considerations
This specification follows the practices of [WebDAV] in encoding all This specification follows the practices of [WebDAV] in encoding all
human-readable content using XML [XML] and in the treatment of names. human-readable content using XML [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set Consequently, this specification complies with the IETF Character Set
Policy [Alvestrand]. Policy [Alvestrand].
WebDAV applications MUST support the character set tagging, character WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML set encoding, and the language tagging functionality of the XML
specification. This constraint ensures that the human-readable content specification. This constraint ensures that the human-readable content
of this specification complies with [Alvestrand]. of this specification complies with [Alvestrand].
skipping to change at line 1053 skipping to change at line 1260
As in [WebDAV}, names in this specification fall into three categories: As in [WebDAV}, names in this specification fall into three categories:
names of protocol elements such as methods and headers, names of XML names of protocol elements such as methods and headers, names of XML
elements, and names of properties. Naming of protocol elements follows elements, and names of properties. Naming of protocol elements follows
the precedent of HTTP, using English names encoded in USASCII for the precedent of HTTP, using English names encoded in USASCII for
methods and headers. The names of XML elements used in this methods and headers. The names of XML elements used in this
specification are English names encoded in UTF-8. specification are English names encoded in UTF-8.
For error reporting, [WebDAV] follows the convention of HTTP/1.1 status For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
codes, including with each status code a short, English description of codes, including with each status code a short, English description of
the code (e.g., 423 Locked). Internationalized applications will ignore the code (e.g., 423 Locked). Internationalized applications will ignore
this message, and display an appropriate message in the user's language this message, and display an appropriate message in the user's language
and character set. and character set.
For rationales for these decisions and advice for application For rationales for these decisions and advice for application
implementors, see [WebDAV]. implementors, see [WebDAV].
19 IANA Considerations 20 IANA Considerations
This document uses the namespaces defined by [WebDAV] for properties and This document uses the namespaces defined by [WebDAV] for properties and
XML elements. All other IANA considerations mentioned in [WebDAV] also XML elements. All other IANA considerations mentioned in [WebDAV] also
apply to this document. apply to this document.
20 Copyright In addition, this document defines new HTTP/1.1 status codes 506, 507,
and 508 in Section 13.
21 Copyright
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
21 Intellectual Property 22 Intellectual Property
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
22 Acknowledgements 23 Acknowledgements
This draft has benefited from thoughtful discussion by Jim Amsden, Steve This draft has benefited from thoughtful discussion by Jim Amsden, Steve
Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer
Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron
Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj
Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry
Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby,
Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner,
Kevin Wiggen, and others. Kevin Wiggen, and others.
23 References 24 References
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,
Xerox. August, 1998. Xerox. August, 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, BCP 14. Harvard University. March, 1997. Levels." RFC 2119, BCP 14. Harvard University. March, 1997.
[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)." World Wide Web Consortium Recommendation REC-xml- Language (XML)." World Wide Web Consortium Recommendation REC-xml-
19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC
2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999.
[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D.
Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518.
Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. Microsoft, U.C. Irvine, Netscape, Novell. February, 1999.
[ISO-11578] ISO (International Organization for Standardization),
ISO/IEC 11578:1996. "Information technology - Open Systems
Interconnection - Remote Procedure Call (RPC)."
[OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. [OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work
in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine, in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine,
CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
[RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. [RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work
in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC
Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
24 Authors' Addresses 25 Authors' Addresses
J. Slein J. Slein
Xerox Corporation Xerox Corporation
800 Phillips Road, 105-50C 800 Phillips Road, 105-50C
Webster, NY 14580 Webster, NY 14580
Email: jslein@crt.xerox.com Email: jslein@crt.xerox.com
E. J. Whitehead, Jr. E. J. Whitehead, Jr.
Dept. of Information and Computer Science Dept. of Information and Computer Science
University of California, Irvine University of California, Irvine
skipping to change at line 1160 skipping to change at line 1372
J. Crawford J. Crawford
IBM IBM
Email: ccjason@us.ibm.com Email: ccjason@us.ibm.com
T. Chihaya T. Chihaya
DataChannel, Inc. DataChannel, Inc.
155 108th Ave. N.E., Suite 400 155 108th Ave. N.E., Suite 400
Bellevue, WA 98004 Bellevue, WA 98004
Email: Tyson@DataChannel.com Email: Tyson@DataChannel.com
25 Appendices 26 Appendices
25.1 Appendix 1: Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 9 ================--> 26.1 Appendix 1: Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 16 ================-->
<!ELEMENT segment (#PCDATA)> <!ELEMENT segment (#PCDATA)>
<!--============= Property Elements from Section 7 ==================--> <!--============= Property Elements from Section 13 ==================--
>
<!ELEMENT bindings ((href, segment)*)> <!ELEMENT bindings ((href, segment)*)>
<!ELEMENT guid (href)>
Expires February 20, 2000 Expires April 15, 2000
 End of changes. 

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