1 INTRODUCTION............................................3
1.2 Rationale for Distinguishing Bindings from URI
Mappings..............................................6
1.3 Method Preconditions and Postconditions...............6
2 OVERVIEW OF BINDINGS....................................7
2.4 DELETE and Bindings..................................10
2.6 Determining Whether Two Bindings Are to the Same
Resource.............................................11
3 PROPERTIES.............................................12
4 BIND METHOD............................................13
5 UNBIND METHOD..........................................15
5.1 Example: UNBIND......................................16
6 REBIND METHOD..........................................17
6.1 Example: REBIND......................................18
7 ADDITIONAL STATUS CODES................................19
8 SECURITY CONSIDERATIONS................................20
9 INTERNATIONALIZATION CONSIDERATIONS....................21
10  IANA CONSIDERATIONS..................................21
11  INTELLECTUAL PROPERTY................................22
terminology used in the rest of the specification, while Section
1.3 overviews bindings.  Section 3 defines the new properties
needed to support multiple bindings to the same resource.  Section
4 specifies the BIND method, used to create multiple bindings to
the same resource.  Section 5 specifies the UNBIND method, used to
remove a binding to a resource.  Section 6 specifies the REBIND
method, used to move a binding to another collection.
- Element names use the "DAV:" namespace.
- Element ordering is irrelevant.
- Extension elements/attributes (elements/attributes not already
defined as valid child elements) may be added anywhere, except when
explicitly stated otherwise.
submit HTTP protocol requests to the resource using the URI.
(accessible through the URI ), a path
/foo.html to access R.
must be true for that method to be performed.  A "postcondition" of
a method describes the state on the server that must be true after
that method has completed.  If a method precondition or
postcondition for a request is not satisfied, the response status
of the request MUST be either 403 (Forbidden) if the request should
not be repeated because it will always fail, or 409 (Conflict) if
it is expected that the user might be able to resolve the conflict
and resubmit the request.
In order to allow better client handling of 403 and 409 responses,
a distinct XML element type is associated with each method
precondition and postcondition of a request.  When a particular
precondition is not satisfied or a particular postcondition cannot
be achieved, the appropriate XML element MUST be returned as the
child of a top-level DAV:error element in the response body, unless
otherwise negotiated by the request.  In a 207 Multi-Status
response, the DAV:error element would appear in the appropriate
DAV:responsedescription element.
because a loop was encountered.
a collection, C.  Then if C-MAP is the set of URIs 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.
final segment.
URI-2), with the Destination header set to URI-X.  After successful
creates at least the URI mapping between URI-X and the new resource
If a COPY causes one or more existing resources to be updated, the
bindings to those resources MUST be unaffected by the COPY.  Using
the preceding example, suppose that a COPY is issued to URI-X for
resource R', with the Destination header set to URI-2.  The content
and dead properties of resource R would be updated to be a copy of
those of resource R', but the mappings from URI-1, URI-2, and URI-3
to resource R remain unaffected.
than the one identified by the request URI.  For example, suppose
the collection identified by the URI "/a" has a binding named "x"
to a resource R, and another collection identified by "/b" has a
binding named "y" to the same resource R.  Then a DELETE applied to
"/a/x" removes the binding named "x" from "/a" but MUST NOT remove
the binding named "y" from "/b" (i.e. after the DELETE, "/y/b"
continues to identify the resource R).  In particular, although
Request-URI from collections which contain it as a member", a
server that supports the binding protocol MUST NOT follow this
membership of any other collection that is not itself a member of
the collection being deleted.  For example, if both "/a/.../x" and
"/b/.../y" identify the same collection, C, then applying DELETE to
"/a" MUST NOT delete an internal member from C or from any other
If a collection supports the UNBIND method (see Section 5), a
DELETE of an internal member of a collection MAY be implemented as
an UNBIND request.  In this case, applying DELETE to a Request-URI
has the effect of removing the binding identified by the final
segment of the Request-URI from the collection identified by the
Request-URI minus its final segment. Although [RFC2518] allows a
DELETE to be a non-atomic operation, when the DELETE operation is
implemented as an UNBIND, the operation is atomic.  In particular,
a DELETE on a hierarchy of resources is simply the removal of a
binding to the collection identified by the Request-URI.
method (see Section 6), a MOVE of a resource into that collection
MAY be implemented as a REBIND request.  Although [RFC2518] allows
a MOVE to be a non-atomic operation, when the MOVE operation is
implemented as a REBIND, the operation is atomic.  In particular,
applying a MOVE to a Request-URI and a Destination URI has the
effect of removing a binding to a resource (at the Request-URI),
and creating a new binding to that resource (at the Destination
URI).
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 URI-X.  After successful completion of
the MOVE operation, a new binding has been created which creates
the URI mapping between URI-X and resource R.  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.  If
resource R were a collection, old URI-3 based mappings to members
of R would have been removed, and new URI-X based mappings to
members of R would have been created.
operation, a MOVE implemented as a REBIND MUST be atomic.  Even
value to its DAV:resource-id property.  For example, a PUT or a
COPY that creates a new resource must assign a new, unique value to
the DAV:resource-id property of that new resource.
example, a PUT or a COPY that updates an existing resource must not
change the value of its DAV:resource-id property.  A MOVE, since it
does not create a new resource, but only changes the location of an
existing resource, must not change the value of the DAV:resource-id
properties defined by this document.  This allows a binding server
to perform efficiently when a naive client, which does not
understand the cost of asking a server to compute all possible live
properties, issues a DAV:allprop PROPFIND request.
(DAV:protected-source-url-deletion-allowed): If the DAV:href URI is
protected by a write lock, then the appropriate token MUST be
to the resource that was identified by the DAV:href element in the
(DAV:binding-deleted): The URL specified in the DAV:href element in
the request body MUST NOT be mapped to a resource.
"", associating "foo.html" with the
"/bar.html", and removes the binding
named "bar.html" from the collection identified by the URI
"".  Clients can now use the URI
"/foo.html" to submit requests to that
resource, and requests on the URI
"/bar.html" will fail with a 404 (Not
Found) response.