[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

WEBDAV Working Group                                     J. Slein, Xerox
INTERNET DRAFT                             E.J. Whitehead Jr., UC Irvine
<draft-ietf-webdav-binding-protocol-00.txt>          J. Davis, CourseNet
                                                      G. Clemm, Rational
                                                         C. Fay, FileNet
                                                        J. Crawford, IBM
                                                 T. Chihaya, DataChannel
                                                         August 20, 1999
Expires February 20, 2000

                                  WebDAV Bindings

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Distribution of this document is unlimited. Please send comments to the
Distributed Authoring and Versioning (WebDAV) working group at <w3c-
dist-auth@w3.org>, which may be joined by sending a message with subject
"subscribe" to <w3c-dist-auth-request@w3.org>.

Discussions of the WEBDAV working group are archived at URL:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/>.

Abstract

The WebDAV Distributed Authoring Protocol provides basic support for
collections, offering the ability to create and list unordered
collections.

This specification is one of a group of three specifications that
supplement the WebDAV Distributed Authoring Protocol to increase the
power of WebDAV collections. This specification defines bindings, one
mechanism for allowing a single resource to appear in more than one
collection.  Bindings make this possible by creating mappings of URIs to
resources.  The BIND method defined here gives clients the ability to
create new bindings to existing resources.  [RR] defines redirect
references, another approach to allowing a single resource to be
accessed from multiple collections.  [OC] provides ordered collections.

Table of Contents

1       Notational Conventions.......................................2
2       Introduction.................................................2
3       Terminology..................................................4

Slein et al.                                                    Page 1
Internet-Draft                WebDAV Bindings                August 1999

4       Overview of Bindings.........................................7
5       BIND Method..................................................8
5.1     Overview of BIND.............................................8
5.2     Bindings to Collections......................................9
5.3     URI Mappings Created by BIND.................................9
5.4     Example: Generating the Set of URI Mappings.................10
5.5     BIND Status Codes...........................................11
5.6     Example: BIND...............................................11
5.7     Example: BIND Conflict......................................11
6       DELETE and Bindings.........................................12
7       COPY and Bindings...........................................12
8       MOVE and Bindings...........................................13
8.1     Implementation Note.........................................14
9       LOCK and UNLOCK.............................................15
10      Bindings and Other Methods..................................15
11      Discovering the Bindings to a Resource......................16
12      Headers.....................................................16
12.1    All-Bindings Request Header.................................17
13      Status Codes................................................17
13.1    506 Loop Detected...........................................17
14      Properties..................................................17
14.1    bindings Property...........................................17
15      XML Elements................................................17
15.1    segment XML Element.........................................17
16      Capability Discovery........................................17
16.1    Example: Discovery of Support for Bindings..................18
17      Security Considerations.....................................18
17.1    Privacy Concerns............................................18
17.2    Redirect Loops..............................................19
17.3    Bindings, and Denial of Service.............................19
17.4    Private Locations May Be Revealed...........................19
17.5    DAV:bindings and Denial of Service..........................19
18      Internationalization Considerations.........................19
19      IANA Considerations.........................................20
20      Copyright...................................................20
21      Intellectual Property.......................................20
22      Acknowledgements............................................20
23      References..................................................20
24      Authors' Addresses..........................................21
25      Appendices..................................................21
25.1    Appendix 1: Extensions to the WebDAV Document Type
        Definition..................................................21

1 Notational Conventions

Since this document describes a set of extensions to the HTTP/1.1
protocol, the augmented BNF used here to describe protocol elements is
exactly the same as described in Section 2.1 of [HTTP].  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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

2 Introduction

Slein et al.                                                    Page 2
Internet-Draft                WebDAV Bindings                August 1999


The simple collections that the WebDAV Distributed Authoring Protocol
specification supports are powerful enough to be widely useful.  They
provide for the hierarchical organization of resources, with mechanisms
for creating and deleting collections, copying and moving them, locking
them, adding members to them and removing members from them, and getting
listings of their members.  Delete, copy, move, list, and lock
operations can be applied recursively, so that a client can operate on
whole hierarchies with a single request.

This specification is one of a family of three specifications that build
on the infrastructure defined in [HTTP] and [WebDAV] to extend the
capabilities of collections.  The companion specification [OC] defines
protocol extensions to support ordered collections.  The present
specification and the companion specification [RR] 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
groupings, known as collections, which are more easily browsed and
manipulated than a flat namespace.  However, hierarchies require
categorization decisions that locate resources at a single location in
the hierarchy, a drawback when a resource has multiple valid categories.
For example, in a hierarchy of vehicle descriptions containing
collections for cars and boats, a description of a combination car/boat
vehicle could belong in either collection. Ideally, the description
should be accessible from both.

Hierarchies also make resource sharing more difficult, since resources
that have utility across many collections are still forced into a single
collection. For example, the mathematics department at one university
might create a collection of information on fractals that contains
bindings to some local resources, but also provides access to some
resources at other universities.  For many reasons, it may be
undesirable to make physical copies of the shared resources on the local
server - to conserve disk space, to respect copyright constraints, or to
make any changes in the shared resources visible automatically.

The companion specification [RR] defines redirect references, one
mechanism for providing access to a single resource from multiple
collections.  A redirect reference is a resource in one collection whose
purpose is to forward requests to another resource (its target), usually
in a different collection.  In this way, it provides access to the
target resource from another collection.  It redirects most requests to
the target resource using the HTTP 302 (Moved Temporarily) status code,
thereby providing a form of mediated access to the target resource.

The BIND method defined here provides a different mechanism for allowing
a single resource to appear in multiple collections.  It lets clients
associate a new URI with an existing resource.  This URI can then be
used to submit requests to the resource.  Since URIs in WebDAV are
hierarchical, and correspond to a hierarchy of collections in resource
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
additional collections.

Slein et al.                                                    Page 3
Internet-Draft                WebDAV Bindings                August 1999


These two approaches to allowing clients to add a single resource to
multiple collections have very different characteristics:

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
be stored on the redirect reference resource.  Since redirect references
are implemented using HTTP 302 responses, it generally takes two round
trips to submit a request to the intended resource.  Servers are not
required to enforce the integrity of redirect references.  Redirect
references work equally well for local resources and for resources that
reside on a different server from the reference.

By contrast, a BIND request does not create a new resource, but simply
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
request to a resource.  Only one round trip is needed to submit a
request to the intended target.  Servers are required to enforce the
integrity of the relationships between the new URIs clients create and
the resources associated with them.  Consequently, it is unlikely that
servers will support BIND requests that cross server boundaries.

3 Terminology

The terminology used here follows and extends that in the WebDAV
Distributed Authoring Protocol specification [WebDAV]. Definitions of
the terms resource, Uniform Resource Identifier (URI), and Uniform
Resource Locator (URL) are provided in [URI].

URI Mapping
     A relation between an absolute URI and a resource.  For an
     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
     represent items that are not network retrievable, as well as those
     that are, it is possible for a resource to have zero, one, or many
     URI mappings. Mapping a resource to an "http" scheme URL makes it
     possible to submit HTTP protocol requests to the resource using
     the URL.

Path Segment
     Informally, the characters found between slashes ("/") in a URI.
     Formally, as defined in section 3.3 of [URI].

Binding
     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
     different collections contain a binding between the same path
     segment and the same resource, these are two distinct bindings.
     So for a collection C, a path segment S relative to that
     collection, and a resource R, the binding can be thought of as the
     ordered triple (C,S,R).  Bindings create URI mappings, and hence
     allow requests to be sent to a single resource from multiple
     locations in a URI namespace.

     The following figure can be used to illustrate how bindings create

Slein et al.                                                    Page 4
Internet-Draft                WebDAV Bindings                August 1999

     URI mappings.

                +-----------------------------+
                | root collection             |
                |-----------------------------|
                | bindings:                   |
                |                             |
                | Coll1   Coll2   Coll3       |
                |   |       |       \         |
                +---|-------|--------\--------+
                    |       |         \
                    |       |          \
          +-------------------+   +----------------------+
          | collection C1     |   | collection C2        |
          |-------------------|   |----------------------|
          | bindings:         |   | bindings:            |
          |                   |   |                      |
          | foo   bar         |   | foo                  |
          |  |     \          |   |  /                   |
          +--|------\---------+   +-/--------------------+
             |       \             /
             |        \           /
             |         \         /
             |          \       /
     +--------------+   +---------------+
     | resource R1  |   | resource R2   |
     +--------------+   +---------------+

     Figure 1

     The binding (C1,foo,R1) between foo and resource R1 in collection
     C1 creates the URI mappings /Coll1/foo and /Coll2/foo to resource
     R1.  Each of these URI mappings can be used to submit requests to
     R1.  The binding (C1,bar,R2) between bar and resource R2 in
     collection C1 and the binding (C2,foo,R2) between foo and resource
     R2 in collection C2 create altogether 3 URI mappings to resource
     R2: /Coll1/bar, /Coll2/bar, and /Coll3/foo.  All 3 URI mappings
     can be used to submit requests to resource R2.

Collection
     A resource that contains, as part of its state, a set of bindings
     that identify member resources.

Internal Member URI
     The URI element U of a URI mapping (U,R), created by a binding
     that is contained in a collection. The following figure
     illustrates the relationship between bindings and internal member
     URIs in a collection:

                +-----------------------------+
                | root collection             |
                |-----------------------------|
                | internal member URIs:       |
                |                             |
                | /Coll1/                     |

Slein et al.                                                    Page 5
Internet-Draft                WebDAV Bindings                August 1999

                | /Coll2/                     |
                | /Coll3/                     |
                |-----------------------------|
                | bindings:                   |
                |                             |
                | Coll1   Coll2   Coll3       |
                |   |       |       \         |
                +---|-------|--------\--------+
                    |       |         \
                    |       |          \
          +----------------------+   +----------------------+
          | collection C1        |   | collection C2        |
          |----------------------|   |----------------------|
          | internal member URIs:|   | internal member URIs:|
          |                      |   |                      |
          | /Coll1/foo           |   | /Coll3/foo           |
          | /Coll2/foo           |   |----------------------|
          | /Coll1/bar           |   | bindings:            |
          | /Coll2/bar           |   |                      |
          |----------------------|   | foo                  |
          | bindings:            |   |  /                   |
          |                      |   +-/--------------------+
          | foo   bar            |    /
          |  |     \             |   /
          +--|------\------------+  /
             |       \             /
             |        \           /
             |         \         /
             |          \       /
     +--------------+   +---------------+
     | resource R1  |   | resource R2   |
     +--------------+   +---------------+

     Figure 2

     The URI elements of all URI mappings created by a collection's
     bindings are internal member URIs of the collection.

     However, for a given request, only the URIs from those URI
     mappings that incorporate the Request-URI are treated as internal
     member URIs.  For example, in Figure 2 above, if a PROPFIND
     request with "Depth: infinity" is submitted to collection C1 using
     the Request-URI /Coll1/, only the URI mappings starting with the
     Request-URI would be listed as internal member URIs.  The response
     would include only /Coll1/ itself and the internal member URIs
     /Coll1/foo and /Coll1/bar.

     In [WebDAV], a collection is defined as containing a list of
     internal member URIs, where an internal member URI is the URI of
     the collection, plus a single path segment.  This definition
     combines the two concepts of binding and URI mapping that are
     separated in this specification.  As a result, this specification
     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
     derived from a binding. After this redefinition, an internal

Slein et al.                                                    Page 6
Internet-Draft                WebDAV Bindings                August 1999

     member URI can be used when reading [WebDAV] without loss of
     meaning. For purposes of interpretation, when [WebDAV] discusses a
     collection "containing" an internal member URI, this should be
     read as the collection containing a binding whose mapping to a URI
     creates an internal member URI, in this sense "containing" the
     internal member URI.  The authors of this specification anticipate
     and recommend that future revisions of [WebDAV] perform a full
     reconciliation of terms between these two specifications.

4 Overview of Bindings

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
internal member URIs, as illustrated in Figure 2 above.  The URI segment
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.
The final segment of each internal member URI identifies one of the
bindings that is part of the collection's state, unless the internal
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
method for explicitly creating bindings is introduced here.  Existing
methods that create resources, such as PUT, MOVE, COPY, and MKCOL,
implicitly create bindings.  There is no difference between implicitly
created bindings and bindings created with BIND.

The identity of a binding (C,S,R) is determined by the URI segment (in
its collection) and the resource that the binding associates.  If the
resource goes out of existence (as a result of some out-of-band

Slein et al.                                                    Page 7
Internet-Draft                WebDAV Bindings                August 1999

operation), the binding also goes out of existence.  If the URI segment
comes to be associated with a different resource, the original binding
ceases to exist and another binding is created.

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
destroyed as a side effect of operating on the resource through a
different binding.  It is not acceptable for a MOVE through one binding
to fail to update another binding, turning that binding into a dangling
path segment.  Nor is it acceptable for a server, after performing a
DELETE through one binding, to reclaim the system resources associated
with its resource while other bindings to the resource remain.
Implementations MUST act to 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.1 Overview of BIND

The BIND method creates a new binding from the final segment of the
Request-URI (minus any trailing slash) to the resource identified
by the Destination header.  This binding is added to the collection
identified by the Request-URI minus its trailing slash (if present) and
final segment.  The Destination header is defined in Section 9.3 of
[WebDAV].

If a server cannot guarantee the binding behavior specified for GET
(Section 10), DELETE (Section 6), and MOVE (Section 8), the BIND request
MUST fail with a 501 (Not Implemented) status code.

If the Request-URI ends in a slash ("/") (i.e., the Request-URI
identifies a collection), the resource identified by the Destination
header MUST be a collection resource, or the request fails with a 409
(Conflict) status code. This ensures that URIs ending in a slash are
always bound to collections.  If the Request-URI does not contain a path
segment (i.e., it consists simply of a slash "/"), the BIND operation
MUST fail and report a 409 (Conflict) status code.

After successful processing of a BIND request, it MUST be possible for
clients to use the Request-URI to submit requests to the resource
identified by the Destination header.

By default, if the Request-URI identifies an existing binding, the new

Slein et al.                                                    Page 8
Internet-Draft                WebDAV Bindings                August 1999

binding replaces the existing binding. This default binding replacement
behavior can be overridden using the Overwrite header defined in Section
9.6 of [WebDAV].

5.2 Bindings to Collections

BIND can create a binding to a collection resource.  A collection
accessed through such a binding behaves exactly as would a collection
accessed through any other binding.  Bindings to collections can result
in loops, which servers MUST detect when processing "Depth: infinity"
requests.  When a loop is detected, the server MUST respond with a 506
(Loop Detected) status code (defined in Section 13.1).

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
result in the creation of a new binding for each of these resources.

For example, suppose a new binding COLLX is created for collection C1 in
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
/COLLX/y.jpg, but no new bindings for these child resources were
created.  This is because bindings are part of the state of a
collection, and associate a URI that is *relative to that collection*
with its target resource.  No change to the bindings in Collection C1 is
needed to make its children accessible using /COLLX/x.gif and
/COLLX/y.jpg.

+-------------------------+
| Root Collection         |
| (properties)            |
|  bindings:              |
|  coll1          COLLX   |
+-------------------------+
    |            /
    |           /
    |          /
+------------------+
| Collection C1    |
| (properties)     |
| bindings:        |
| x.gif     y.jpg  |
+------------------+
    |          \
    |           \
    |            \
+-------------+   +-------------+
| Resource R1 |   | Resource R2 |
+-------------+   +-------------+

Figure 4

5.3 URI Mappings Created by BIND

The set of URI mappings created by a successful BIND operation MUST be
determined as follows:

Slein et al.                                                    Page 9
Internet-Draft                WebDAV Bindings                August 1999


1. Start with an empty set of URLs, called U.
2. Take the Request-URI and remove path segments (and associated "/"
characters) from the right until either (a) a non-WebDAV collection is
found, or (b) the root, "/" is reached (i.e., no characters after the
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

Assume a server responds to two domain names, www.fuzz.com, and
fuzz.com, and has a top level that is not WebDAV-aware, called A/.
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:

BIND /A/1/info.html HTTP/1.1
Host: www.fuzz.com
Destination: http://www.fuzz.com/A/one/index.html

>> Response:

HTTP/1.1 201 Created

The set of all possible URI mappings to the resource identified by
http://www.fuzz.com/A/one/index.html is calculated as follows:

1. U is empty.
2. The base URL, B, is http://www.fuzz.com/A/, since A/ is not WebDAV-
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:

Slein et al.                                                    Page 10
Internet-Draft                WebDAV Bindings                August 1999

http://www.fuzz.com/A/1/index.html, http://www.fuzz.com/A/1/info.html,
http://www.fuzz.com/A/one/index.html,
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://fuzz.com/A/one/info.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

201 (Created): The binding was successfully created.

400 (Bad Request): The client set an invalid value for the Destination
header.

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
already exists for the request-URI.

5.6 Example: BIND

>> Request:

BIND /~whitehead/dav/spec08.txt HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/pub/i-d/draft-webdav-protocol-08.txt

>> Response:

HTTP/1.1 201 Created

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-
webdav-protocol-08.txt".  Clients can now use the Request-URI,
"http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit requests
to that resource.  As part of this operation, the server added 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


Slein et al.                                                    Page 11
Internet-Draft                WebDAV Bindings                August 1999

The client requested the server to create a binding between "prlogo.gif"
and the resource identified by the URL "http://www.softcorp.com/logos/".
Since the Destination does end in a slash, while the Request-URI does
not, the server failed the request, returning a 409 (Conflict) status
code.

6 DELETE and Bindings

The DELETE method requests that the server remove the binding between
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
its parent collection, identified by the Request-URI minus its trailing
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
resource identified by the Request-URI.

Once all bindings to the resource are removed, the server MAY reclaim
system resources associated with the resource. If DELETE removes a
binding to a resource, but there remain other bindings to that resource,
the server MUST NOT reclaim system resources associated with 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
delete the resource identified by the Request-URI."  Because [HTTP] did
not distinguish between bindings and resources, the intent of its
definition of DELETE is unclear.  We consider the definition presented
here to be a clarification of the definition in [HTTP].

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
collections which contain it as a member."  Servers that support
bindings SHOULD NOT follow this requirement.

7 COPY and Bindings

As defined in Section 8.8 of [WebDAV], COPY causes the resource
identified by the Request-URI to be duplicated, and makes the new
resource accessible using the URI specified in the Destination header.
Upon successful completion of a COPY, a new binding is created between
the last path segment of the Destination header (including trailing "/",
if present), and the destination resource. The new binding is added to
its parent collection, identified by the Destination header minus its
trailing slash (if present) and final segment.

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
header set to URIX.  After successful completion of the COPY operation,
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
new resource (although other URI mappings may also have been created).


Slein et al.                                                    Page 12
Internet-Draft                WebDAV Bindings                August 1999

 URI 1   URI 2    URI 3                             URIX
   |       |        |                                |
   |       |        |    <---- URI Mappings ---->    |
   |       |        |                                |
+---------------------+                   +------------------------+
|     Resource R      |                   |     Resource R'        |
+---------------------+                   +------------------------+

Figure 5

It might be thought that a COPY request with "Depth: 0" on a collection
would duplicate its bindings, since bindings are part of the
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
apply to a collection's members.  Consequently, a COPY with "Depth: 0"
does not duplicate the bindings contained by the collection.

8 MOVE and Bindings

The MOVE method has the effect of creating a new binding to a resource
(at the Destination), and removing an existing binding (at the Request-
URI). The name of the new binding is the last path segment of the
Destination header, and the new binding is added to its parent
collection, identified by the Destination header minus its trailing
slash (if present) and final segment.

As an example, suppose that a MOVE is issued to URI 3 for resource R
below (which is also mapped to URI 1 and URI 2), with the Destination
header set to URIX.  After successful completion of the MOVE operation,
a new binding has been created which creates at least the URI mapping
between URIX and resource R (although other URI mappings may also have
been created).  The binding corresponding to the final segment of URI 3
has been removed, which also causes the URI mapping between URI 3 and R
to be removed.

>> Before Request:

 URI 1   URI 2    URI 3
   |       |        |
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+
|     Resource R      |
+---------------------+

>> After Request:

 URI 1   URI 2    URIX
   |       |        |
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+
|     Resource R      |
+---------------------+


Slein et al.                                                    Page 13
Internet-Draft                WebDAV Bindings                August 1999

Figure 6

Since MOVE as specified in [WebDAV] is not an atomic operation, it may
happen that parts of the hierarchy under the request-URI cannot be
moved.  In this case, the response is as described in [WebDAV].

8.1 Implementation Note

In some situations, particularly when the destination is on a different
server from the original resource, the server may implement MOVE by
performing a COPY, performing some consistency maintenance on bindings
and properties, and then performing a DELETE. In the end, all of the
original bindings except the one corresponding to the Request-URI will
be associated with the new resource. The binding corresponding to the
URI in the Destination header will be associated with the new resource.
And the original resource together with the binding corresponding to the
Request-URI will have been deleted. This implementation is in accord
with the definition of MOVE in [WebDAV], and is logically equivalent to
the definition given above.

The consistency maintenance processing that is required for this
implementation is as follows:

The DAV:creationdate property of the new resource SHOULD have the same
value as the DAV:creationdate property of the old resource.

The DAV:getlastmodified property of the new resource SHOULD have the
same value as the DAV:getlastmodified property of the old resource.

All URIs that were bound to the original resource except for the
Request-URI MUST be bound instead to the new resource.

Consider again the case where a MOVE is issued to URI 3 for resource R
(which is also mapped to URI 1 and URI 2), with the Destination header
set to URIX.  Unlike the previous example, in this implementation, after
successful completion of the MOVE operation, resource R has been
duplicated as resource R'.  The original bindings corresponding to URI 1
and URI2 are now associated with R'.  The binding corresponding to the
Request-URI (URI 3) has been removed.  And a new binding has been
created which creates at least the URI mapping between URIX and resource
R'. Note that the server may reclaim the storage associated with
resource R once the MOVE operation has finished.

>> Before Request:

 URI 1   URI 2    URI 3
   |       |        |
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+
|     Resource R      |
+---------------------+

>> After Request:


Slein et al.                                                    Page 14
Internet-Draft                WebDAV Bindings                August 1999

URI1     URI2 ---------------------------------    URIX
  |                                            |     |
   -----------------------------------------   |     |
                                            |  |     |
+---------------------+                   +------------------------+
|     Resource R      |                   |     Resource R'        |
+---------------------+                   +------------------------+

Figure 7

9 LOCK and UNLOCK

Bindings do not affect the semantics of locks, as specified in [WebDAV].
Specifically, the requirement in section 8.10.3 that "a LOCK request on
a resource MUST NOT succeed if it can not be honored by all the URIs
through which the resource is accessible" still holds.  The LOCK method
locks the resource, and a lock is visible via all URIs mapped to that
resource. Similarly, a successful UNLOCK issued via any URI mapping to a
resource removes the lock from the resource, and this lock removal is
visible via all URI mappings.

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
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
corresponding to segments of the request-URI.

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
inaccessible via the URI mapping used to lock the resource.  Only the
lock owner can move or delete any of the collections corresponding to
segments of the Request-URI. This restriction does not prevent others
from modifying those collections, by adding members to them, removing
members from them, or changing their property values.

For example, if a user locks /plants/herbs/rosemary.html, it is not
possible for another user to move /plants/herbs/ to
/plants/flowering/herbs/, or to completely delete /plants/herbs/, though
it is possible this delete operation may succeed in deleting everything
except for /plants/herbs/rosemary.html and /plants/herbs/.

10 Bindings and Other Methods

This section describes the interaction of bindings with those HTTP
methods not yet explicitly discussed.  The semantics of the methods GET,
HEAD, PUT, POST and OPTIONS are specified in [HTTP].  The semantics of
PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV].

For most of these methods, no new complexities are introduced by
allowing explicit creation of multiple bindings to the same resource.
For the access operations (GET, HEAD, OPTIONS, and PROPFIND), it is
simply the case that no matter which URI mapping to a given resource is
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

Slein et al.                                                    Page 15
Internet-Draft                WebDAV Bindings                August 1999

Request-URI in its entity.

The same is true for POST.  No matter which URI mapping to a given
resource is used as the Request-URI, the response is mediated by that
same resource.  The changes made on the server and the responses may,
however, vary depending upon which Request-URI was used.

If the Request-URI of a PUT identifies an existing resource, then a PUT
via one URI mapping to this resource MUST produce the same result as a
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
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.
MKCOL through any URI mapping to an existing resource must fail.

The semantics of MKREF are specified in Section nn of [RR].  A MKREF
through one URI mapping to a resource MUST produce the same result as a
MKREF with the same headers through any other URI mapping to the same
resource.  By default, it overwrites the resource with a new redirect
reference.

The semantics of ORDERPATCH are specified in Section nn of [OC].  An
ORDERPATCH through one URI mapping to a collection MUST produce the same
changes to its ordering as the same ORDERPATCH request through any other
URI mapping to the same collection.

11 Discovering the Bindings to a Resource

An OPTIONAL DAV:bindings property on a resource provides a list of the
bindings that associate URI segments with that resource. By retrieving
this property, a client can discover the bindings that point to the
resource 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
resource to the bindings that point to it, and to the collections that
contain those bindings.  This capability is particularly important for
Document Management Systems.  Their clients may need to determine, for
any object in the DMS, what collections contain bindings to that object.
This information can be used for upward navigation through a hierarchy
or to discover related documents in other collections.

Risks: When deciding whether to support the DAV:bindings property,
server implementers / administrators should balance the benefits it
provides against the cost of maintaining the property and the security
risks enumerated in Sections 17.4 and 17.5.

12 Headers

Slein et al.                                                    Page 16
Internet-Draft                WebDAV Bindings                August 1999


12.1 All-Bindings Request Header

All-Bindings = "All-Bindings" ":"

The All-Bindings request header may be used with DELETE requests to
instruct the server to remove all bindings to the resource identified by
the Request-URI.

13 Status Codes

13.1 506 Loop Detected

The 506 (Loop Detected) status code indicates that the server detected
an infinite loop while processing a request with "Depth: infinity".

14 Properties

14.1 bindings Property

Name:       bindings
Namespace:  DAV:
Purpose:    Enables clients to discover, for any resource, what bindings
            point to it and what collections contain those bindings.
            This is an optional property.  If present, it is a read-only
            property, maintained by the server.
Value:      List of href / segment pairs for all of the bindings that
            associate URI segments with the resource.  The href is an
            absolute URI for one URI mapping of the collection
            containing the binding.  Since there may be multiple URI
            mappings for this collection, it is necessary to select one
            (preferably the URI mapping contained in the Request-URI of
            the BIND request) for use in the DAV:bindings property. The
            segment is the URI segment that identifies the binding
            within that collection.

<!ELEMENT bindings ((href, segment)*)>

15 XML Elements

15.1 segment XML Element

Name:       segment
Namespace:  DAV:
Purpose:    The segment that names a binding, used in the DAV:bindings
            property.
Value:      segment  ; as defined in section 3.3 of [URI].

<!ELEMENT segment (#PCDATA)>

16 Capability Discovery

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
the Web Distributed Authoring protocols the resource supports. This

Slein et al.                                                    Page 17
Internet-Draft                WebDAV Bindings                August 1999

specification defines an OPTIONAL extension to [WebDAV].  It defines a
new compliance class, called bindings, for use with the DAV header in
responses to OPTIONS requests.  If a resource does support bindings, its
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
compliance class in the DAV header.

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
server permits a binding at the request URI.

16.1 Example: Discovery of Support for Bindings

>> Request:

OPTIONS /somecollection/someresource HTTP/1.1
HOST: somehost.org

>> Response:

HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT
Connection: close
Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, 2, bindings

The DAV header in the response indicates that the resource
/somecollection/someresource is level 1 and level 2 compliant, as
defined in [WebDAV].  In addition, /somecollection/someresource supports
bindings.  The Allow header indicates that BIND requests can be
submitted to /somecollection/someresource.  The Public header shows that
other Request-URIs on the server support additional methods.

17 Security Considerations

This section is provided to make WebDAV applications aware of the
security implications of this protocol.

All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this protocol
specification.  In addition, bindings introduce several new security
concerns and increase the risk of some existing threats.  These issues
are detailed below.

17.1 Privacy Concerns

In a context where cross-server bindings are supported, creating
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
server.


Slein et al.                                                    Page 18
Internet-Draft                WebDAV Bindings                August 1999

17.2 Redirect Loops

Although redirect loops were already possible in HTTP 1.1, the
introduction of the BIND method creates a new avenue for clients to
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
that would create loops.  Servers are required to detect loops that are
caused by bindings to collections during the processing of any requests
with "Depth: infinity".

17.3 Bindings, and Denial of Service

Denial of service attacks were already possible by posting URLs that
were intended for limited use at heavily used Web sites.  The
introduction of BIND creates a new avenue for similar denial of service
attacks.  If cross-server bindings are supported, clients can now create
bindings at heavily used sites to target locations that were not
designed for heavy usage.

17.4 Private Locations May Be Revealed

If the DAV:bindings property is maintained on a resource, the owners of
the bindings risk revealing private locations.  The directory structures
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
new location to anyone with access to DAV:bindings on its resource.

17.5 DAV:bindings and Denial of Service

If the server maintains the DAV:bindings property in response to
bindings created in other administrative domains, it is exposed to
hostile attempts to make it devote resources to adding bindings to the
list.

18 Internationalization Considerations

This specification follows the practices of [WebDAV] in encoding all
human-readable content using XML [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set
Policy [Alvestrand].

WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML
specification.  This constraint ensures that the human-readable content
of this specification complies with [Alvestrand].

As in [WebDAV}, names in this specification fall into three categories:
names of protocol elements such as methods and headers, names of XML
elements, and names of properties.  Naming of protocol elements follows
the precedent of HTTP, using English names encoded in USASCII for
methods and headers.  The names of XML elements used in this
specification are English names encoded in UTF-8.

For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
codes, including with each status code a short, English description of

Slein et al.                                                    Page 19
Internet-Draft                WebDAV Bindings                August 1999

the code (e.g., 423 Locked).  Internationalized applications will ignore
this message, and display an appropriate message in the user's language
and character set.

For rationales for these decisions and advice for application
implementors, see [WebDAV].

19 IANA Considerations

This document uses the namespaces defined by [WebDAV] for properties and
XML elements.  All other IANA considerations mentioned in [WebDAV] also
apply to this document.

20 Copyright

To be supplied by the RFC Editor.

21 Intellectual Property

To be supplied by the RFC Editor.

22 Acknowledgements

This draft has benefited from thoughtful discussion by Jim Amsden, Steve
Carter, Ken Coar, Ellis Cohen, Dan Connolly, Bruce Cragun, Spencer
Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy Fielding, Yaron
Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj
Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry
Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby,
Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner,
Kevin Wiggen, and others.

23 References

[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,
Xerox. August, 1998.

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels."  RFC 2119, BCP 14.  Harvard University.  March, 1997.

[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)."  World Wide Web Consortium Recommendation REC-xml-
19980210. http://www.w3.org/TR/1998/REC-xml-19980210.

[HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC
2616.  UC Irvine, Compaq, W3C, Xerox, Microsoft.  June, 1999.

[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D.
Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518.
Microsoft, U.C. Irvine, Netscape, Novell.  February, 1999.

[OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work

Slein et al.                                                    Page 20
Internet-Draft                WebDAV Bindings                August 1999

in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine,
CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.

[RR] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Redirect References." Internet Draft (work
in progress) draft-ietf-webdav-redirectref-protocol-00. Xerox, UC
Irvine, CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.

24 Authors' Addresses

J. Slein
Xerox Corporation
800 Phillips Road, 105-50C
Webster, NY 14580
Email: jslein@crt.xerox.com

E. J. Whitehead, Jr.
Dept. of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
Email: ejw@ics.uci.edu

J. Davis
CourseNet Systems
170 Capp Street
San Francisco, CA 94110
Email: jrd3@alum.mit.edu

G. Clemm
Rational Software Corporation
20 Maguire Road
Lexington, MA 02173-3104
Email: gclemm@rational.com

C. Fay
FileNet Corporation
3565 Harbor Boulevard
Costa Mesa, CA 92626-1420
Email: cfay@filenet.com

J. Crawford
IBM
Email: ccjason@us.ibm.com

T. Chihaya
DataChannel, Inc.
155 108th Ave. N.E., Suite 400
Bellevue, WA 98004
Email: Tyson@DataChannel.com

25 Appendices

25.1 Appendix 1: Extensions to the WebDAV Document Type Definition

<!--============= XML Elements from Section 9 ================-->

Slein et al.                                                    Page 21
Internet-Draft                WebDAV Bindings                August 1999

<!ELEMENT segment (#PCDATA)>
<!--============= Property Elements from Section 7 ==================-->
<!ELEMENT bindings ((href, segment)*)>

Expires February 20, 2000

Slein et al.                                                    Page 22


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/