Subject: draft-ietf-webdav-binding-protocol-02

From: [email-masked]
Date: Thu, 20 Jan 2000 22:09:08 -0800

Here are my detailed comments on the binding protocol specification.
Some of these have already been mentioned by Yaron, but I don't have
time to separate them into separate messages.  Sorry.

General
=======

I am a bit surprised by the size of the specification. After all, the
manpage for the Unix ln command is only 4 pages.  I think that this shows
there were far too many extremely intelligent people working on the spec.

I am going to highlight portions of the spec which are not relevant to
the Web interface, and thus shouldn't be part of the protocol. In doing
so, I am not trying to slam the authors or even the fact that many of
these reflect important implementation issues -- they simply aren't
relevant to the Web, for reasons that I will attempt to explain.

Formatting
==========

I know that the draft guidelines say that the author should paginate
the document.  The guidelines are wrong.  Pagination is only applicable
to final RFCs, and only get in the way of draft reviews. In particular,
the RFC editor will properly paginate the document according to the rules
of nroff processing macros, so completely messing up all the figures
and examples by automated addition of header/footers in the *wrong*
places is just annoying.

Details
=======

> Abstract

The first and third paragraphs of the Abstract are irrelevant to this
memo -- such things belong in the introduction (if at all).  A simple
rewrite is:

 This specification extends the Hypertext Transfer Protocol (HTTP/1.1),
 as previously extended by the WebDAV Distributed Authoring Protocol,
 to enable clients to create new identifiers for existing resources.
 It defines the semantics for a new request method, BIND, that creates
 a new name binding within the namespace of a target DAV collection.

> Servers are required to insure the integrity of any bindings 
> that they allow to be created.

This is an implementation concern that has no relevance to the client.
Resources disappear for many reasons, and it isn't possible for a
binding to be more persistent than a resource.

> 1 Notational Conventions

This section should follow the Introduction, not precede it.

> 2 Introduction
> 
> This is one of a pair of specifications that extend the WebDAV 
> Distributed Authoring Protocol to enable clients to create new access 
> paths to existing resources.  This capability is useful for several 
> reasons:

The above paragraph can be deleted without losing any useful info.

> URIs of WebDAV-compliant resources are hierarchical and correspond to a 
> hierarchy of collections in resource space.  The WebDAV Distributed 
> Authoring Protocol makes it possible to organize these resources into 
> hierarchies, placing them into groupings, known as collections, which 
> are more easily browsed and manipulated than a single flat collection. 
> 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. 
> Allowing clients to create new URIs that access the existing resource 
> lets them put that resource into multiple collections.
> 
> 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. Being 
> able to create new access paths to existing resources in other 
> collections or even on other servers is useful for this sort of case.

resources != storage objects.  What is the motivation for creating aliases
within one namespace to identifiers in some other namespace?  That is what
needs to be described in the above paragraph -- storage is irrelevant.

> The BIND method defined here provides a mechanism for allowing clients 
> to create alternative access paths to existing WebDAV resources. HTTP 
> and WebDAV methods are able to work because there are mappings between 
> URIs and resources.  A method is addressed to a URI, and the server 
> follows the mapping from that URI to a resource, applying the method to 
> that resource.  Multiple URIs may be mapped to the same resource, but 
> until now there has been no way for clients to create additional URIs 
> mapped to existing resources. 
> 
> BIND lets clients associate a new URI with an existing WebDAV resource, 
> and this URI can then be used to submit requests to the resource.  Since 

> URIs of WebDAV resources 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.

These are not WebDAV resources -- they are Web resources.  The aliased
resource doesn't even need to be in the http namespace.

> The companion specification, RFC xxxx, defines redirect reference 
> resources, a different mechanism for creating alternative access paths 
> to existing resources.  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.

Forwarding requests is what proxies do.  This paragraph should simply say

  Another mechanism for creating alternative access paths to existing
  resources, using redirect references, will be defined in a separate
  specification.

and the three comparison paragraphs deleted.  Cross-specifying protocols
is evil.

> 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 (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.

Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the
current time, R is the resource, -R-> is a mapping function that has
been implemented according to the semantics of resource R), and the range
is a set of values representing that resource at time t.

I covered some of the problems with the way the binding spec tries to
redefine resources in other e-mail.  However, the real deciding issue
in my mind is that none of this is useful to the client in defining
the protocol.  It would be better to simply say:

   For the purpose of this protocol, each unique URI is considered to
   be identifying a unique resource, even when the URI corresponds to
   a binding created by BIND.  The only distinguishing characteristics
   between the two that may be discovered by the client are ...

> Path Segment
>      Informally, the characters found between slashes ("/") in a URI.
                                                              xxxxxxxxx
in the path component of a hierarchical URI.

>      Formally, as defined in section 3.3 of [URI].

> Binding

Ugh.  Sorry, but all this does is define a bunch of things which are of
no concern to the client.  The abstraction is broken.

A binding is a name within a collection namespace.  This includes "normal"
resources, redirect references, immediately subsidiary collection names,
etc.  We know this because we want a DELETE on a binding to have the 
effect
of deleting any of these names -- even if the server is required to 
respond
with an error under some conditions, since the semantics remain the same.
The only thing BIND does is define a new way to create a binding,
similar to PUT and POST.  Once the binding is created, there is no way
for the client to differentiate it from the original PUT resource.  Thus,
the protocol doesn't care either.

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

Hey, that's what I just wrote -- I should have used a larger read-ahead.
So, if a collection is a set of bindings, why is it so hard to define
bindings?  They are just names.

>      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 

sucks.  [Well, it would make for a shorter spec, but okay I guess you
can't just replace it like that.  Yaron's suggestion to move this
stuff to an appendix is a good one.]

> 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.

Egads.  Bindings are the names within a collection.

> 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.

Yes!
 
> 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 
> 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.

No!  It is fundamentally impossible to implement the above.  In order
to be a protocol requirement, we must specify it in terms of the 
interface.
In other words, what must be done on a PUT/POST/DELETE upon a binding,
where "binding" includes any resource in the namespace.  Once you do
that, you will discover that no one will want to implement this.

> 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 moving a resource through one binding to disrupt 
> another binding, turning that binding into a dangling path segment.  Nor 

> is it acceptable for a server, after removing one binding, to reclaim 
> the system resources associated with its resource while other bindings 
> to the resource remain.  Implementations MUST ensure the integrity of 
> bindings.

I don't need any of these requirements.  If I don't need them, then they
must be specifying something more than a binding, because I've already
implemented every semantic in this spec aside from the BIND method itself.
I am damn sure that I am not going to post-hoc implement alias integrity
within Apache just because this protocol says that a DELETE must result
in removal of all bindings to the binding being deleted.  Late binding,
where the existence or nonexistence of a resource is determined at the
time requested, is far easier to implement and corresponds to what
a user expects to happen -- no magic.

I'm just going to skip the rest of the spec that mentions integrity.

> 5 BIND Method
> 
> 5.1 Overview of BIND
> 
> The BIND method creates a new binding between the resource identified by 

> the Request-URI and the final segment of the Destination header (minus 
> any trailing slash).  This binding is added to the collection identified 

> by the Destination header minus its trailing slash (if present) and 
> final segment.  The Destination header is defined in Section 9.3 of 
> [WebDAV].

As discussed in other mail, this is backwards because the Request-URI
needs to identify the collection that will be changed so that the right
authentication is picked up prior to other processing.  It can be
implemented in the reverse, but doing so is much less efficient for
a general-purpose HTTP server.

>...
> 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.

That says nothing.  Not even what was intended.  A client can submit
anything it wants at any time.

> By default, if the Destination header identifies an existing binding, 
> the new binding replaces the existing binding. This default binding 
> replacement behavior can be overridden using the Overwrite header 
> defined in Section 9.6 of [WebDAV]. 

Yuck.  I don't like this either -- force the client to do a DELETE.

> 5.2 Bindings to Collections
> 
> Bindings to collections can result in loops.  If a server wants to 
> prevent a loop from being created, it MAY fail the BIND request with a 
> 403 (Forbidden) status code.  If a server allows a loop to be created, 
> it MUST detect the loop when processing "Depth: infinity" requests that 
> encounter the loop.  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 12.1 for use in contexts where an 
> operation is terminated because a loop was encountered. 

I'd prefer a new 4xx code instead of 403.  If we are going to all the
trouble of officially extending HTTP, we might as well take advantage
of the benefits.

> Creating a new binding to a collection makes each resource associated 
> with a binding in that collection accessible via a new URI, and thus 
> creates new URI mappings to those resources but no new bindings.

except for the binding created.  I think we'd all live longer if this
and the following paragraphs trying to explain it were just left to the
reader to figure out for themselves -- the description is far more
difficult to understand than just saying "you can create multiple
bindings to a collection resource".  Besides, the Note below does a
far more effective job of saying the same thing.

> 5.3 URI Mappings Created by a BIND
> 
> Suppose a BIND request causes a binding from "Binding-Name" to resource 
> 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.

Wow, that's an even more obscure way of saying that a BIND adds a name
to a collection such that the new name indirectly identifies R.

> Note that if R is a collection, additional URI mappings are created to 
> the descendents of R.  Also note that if a binding is made in collection 

> C to C itself (or to a parent of C), an infinite number of mappings is 
> introduced.

>...

> 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 or Request-URI.
> 
> 403 (Forbidden): This server has a policy that forbids creation of 
> bindings that would result in loops.

403 means that the request is forbidden for reasons that the server
does not want to explain to the client.  You can't redefine 403 to be
this specific because its purpose is not to be specific.

> 412 (Precondition Failed): The Overwrite header is "F", and a binding 
> already exists for the Destination header.
> 
> 507 (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.

I don't see why that is any different than the code formerly known as 403.

> 6 DELETE and Bindings
> 
> The DELETE method was originally defined in [HTTP]. This section 
> redefines the behavior of DELETE in terms of bindings, an abstraction 
> not available when writing [HTTP]. [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.  The 
> definition presented here is a clarification of the definition in 
> [HTTP].

Much easier to just say that DELETE in HTTP/1.1 now refers to deletion
of any binding, including those created by bind, and then add
 
> 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. 
> 
> Once a resource is unreachable by any URI mapping, the server MAY 
> reclaim system resources associated with that resource. If DELETE 
> removes a binding to a resource, but there remain URI mappings to that 
> resource, the server MUST NOT reclaim system resources associated with 
> the resource.

> Although [WebDAV] allows a DELETE to be a non-atomic operation, the 
> DELETE operation defined here 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, and so is a single (and 
> therefore atomic) operation. 

Single operations do not imply atomicity.  Atomic implies that nothing
else can happen during the processing of the request, which is false
for any but the most trivial operations.  DELETE is never trivial.

> 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 MUST NOT follow this requirement.

Huh?  For the sake of this discussion, just ignore WebDAV.  Define what
the new requirement is and note in the appendix how (and why) it differs
from RFC 2518.  On other words, the above requirement creates an infinite
loop binding between two protocol specs, rather than updating one.

> 9 Bindings and Other Methods

I agree with Yaron that static versus dynamic in this section is 
irrelevant.

> 10 Determining Whether Two Bindings Are to the Same Resource
> 
> It is useful to have some way of determining whether two bindings are to 

> 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 13.1 provides this 

> information, it is an optional property.
> 
> The REQUIRED DAV:resourceid property defined in Section 13.2 is a 
> resource identifier, which MUST be unique across all resources for all 
> time.  If the values of DAV:resourceid returned by PROPFIND requests 
> through two bindings are identical, the client can be assured that the 
> two bindings are to the same resource.

Whoa, where did this requirement come from?  The URI is a resource ID.
If somebody wants to create a general metadata field for some sort of
sacred-name, then go wild, but this is not needed for bindings.

A question like this should be answered by a method applied to the
collection, not to the individual bindings.

> 10.1 resourceid URI Scheme
> 
> The value of DAV:resourceid is a URI and may use any URI scheme that 
> guarantees the uniqueness of the value across all resources for all 
> time.  The resourceid URI scheme defined here is an example of an 
> acceptable URI scheme.
> 
> The resourceid URI scheme requires the use of the Universal Unique 
> Identifier (UUID) mechanism, as described in [ISO-11578].  UUID 
> generators may choose between two methods of creating the identifiers. 
> They can either generate a new UUID for every identifier 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.
> 
> resourceid-URI = "resourceid:" 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].

No.  No.  No.

There shall be no repeat of the stupid "opaquelocktoken" URI scheme
just because this is another DAV-related spec.  A URI scheme defines
a namespace, not a purpose for a namespace.  If you want to use UUIDs,
the implementer can CHOOSE to use the "uuid" scheme.  Or they can
choose to use the "mid" scheme, the "urn" scheme, or any other scheme
that fits the need at hand.  Defining a new URI scheme for each new way
that a URI can be used is CONTRARY TO THE DESIGN GOALS OF URI.

>...

> 16.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.

That isn't denial of service.  There is no need for this subsection.
 
I think that's it.  I'm sorry that I didn't get a chance to review
this earlier, but I've been pretty busy the past two years.

...........................................................
Roy T. Fielding                         [email-masked]
eBuilt, Inc.                            tel:+1.949.609.0000
2652 McGaw Ave.                         fax:+1.949.609.0001
Irvine, CA 92614-5840   USA           http://www.eBuilt.com
...........................................................

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 21 Jan 2000 11:56:36 -0500

First, many thanks to Roy for taking time to review the spec.  I
agreed with many/most of his comments, so to keep this response short,
I'll delete the parts of Roy's review that I agree with or have no
comment on.  The result is that it will appear that I disagree with
everything Roy says, but that emphatically is not the case!

   From: [email-masked]

   I am a bit surprised by the size of the specification. After all, the
   manpage for the Unix ln command is only 4 pages.

There was a wide range in views on "how much to say" among the authors.
At the end, we decided to err on the side of too much, and ask the working
group to let us know what could be cut.  You can assume that any comment
of the form "get rid of this" echoes the sentiments of at least one of
the authors.  So to all reviewers, please take Roy's lead and let us know
what to cut!

True, but this statement is intended to constrain a server implementation
to retain a resource while there is a binding to it.  In other words,
an implementation is faulty if it allows a method to have a resource
disappear while there is still a binding to it.  This is in contrast
to references (e.g. redirect references) that have no such guarantee.

Although I agree that storage is not the primary value to a client of
creating multiple bindings, it is one of the reasons why a BIND can be
more desireable to a client than a COPY; namely, because they are
aware that a BIND allows for certain storage optimizations that would
not be feasible for a COPY.

   However, the real deciding issue
   in my mind is that none of this is useful to the client in defining
   the protocol.  It would be better to simply say:

This is a model we considered (and JimW even did some impressive ASCII
art to illustrate it), but we found that saying that "every URI
identifies a unique resource" makes the term "resource" irrelevant.
The point of the binding spec was to allow two different URI's to
identify the same "something".  If we say that every URI identifies a
unique resource, then we need another term, say "object", and now all
of our semantics are in terms of URI's and objects, i.e. "A bind
causes two URI's to be mapped to the same object".  So instead, we
took the approach of Yaron's WebDAV model, and say that there are two
spaces, URI-space and resource-space.  URI's are strings whose syntax
is well-defined.  A resource can respond to an HTTP method, and can
be identified by a URI.  Without the binding protocol, there is no way
for a client to cause two URI's to identify the same resource, so for
all practical purposes, each URI identified a unique resource.  With
the binding protocol, a client now has a way to cause two different
URI's to identify the same resource.  In addition, there is a defined
property, DAV:resourceid, that allows a client to determine whether or
not two URI's are bound to the same resource.

We found that this was much more comprehensible to readers, than to
maintain that every URI identified a unique resource, but that a URI/resource
can be "mapped" to an "object", and two URI/resources can be mapped to the
same object.

On the other hand, perhaps we missed something valuable that was gained
by saying "every URI identifies a unique resource".  Could you explain
what this is?

								 xxxxxxxxx

A client uses collections and bindings to define and control the
mapping of URI's to resources.  In particular, it can only do so (by
the binding protocol) at the "segment" granularity, i.e. when you bind
the resource R1 into collection C1 with the name "x", and the URL
/stuff/coll identifies C1, then you have made /stuff/coll/x identify
R1.  In particular, the discussions of segments and URL syntax is
important to prevent the incorrect conclusion in this example you have caused
/suff/collx to identify R1.

   A binding is a name within a collection namespace.

It is important for a binding to be a name with legal segment syntax,
so that it produces a legal URL when it is concatenated to the URL
that identifies the collection (separated by a "/").

It is also important that a binding be both a name and the resource
that the name identifies, so that when a method replaces a binding
with another binding that has the same name but identifies a different
resource, this is considered a change to the state of the
collection (as reflected in a different entity tag, lock checking,
etc.)

   The only thing BIND does is
   define a new way to create a binding, similar to PUT and POST.  Once
   the binding is created, there is no way for the client to
   differentiate it from the original PUT resource.  Thus, the protocol
   doesn't care either.

There is an important difference in that a BIND creates another name
for a resource, meaning that changes to the state of the resource through
the first name will be visible at the new name.  Unless you know the
resource type of a resource, that doesn't mean much, but when you do
know the resource type (e.g. that it is a collection resource), then
saying changes through one URL are visible at another URL are of great
significance to a client.

For example, if you have two URL's that identify the same collection, and you
add or delete a binding to that collection from one URL, you will see
that addition or deletion at the other URL.

   > ceases to exist and another binding is created.

   No!  It is fundamentally impossible to implement the above.

I don't understand in what sense it is fundamentally impossible to
implement the above.  What part of this appears problematic?

   In order

Perhaps something like: A binding cannot return a 404" and
"any out of band operation that changes the resource associated
with a binding in a collection results in a state change of the
collection (as reflected in an entity tag)" ?

It sounds like you read this as meaning something very different than
was intended.  Could you describe a bit what you thought this was saying,
so we can make sure that we fix it?

This is the strong integrity requirement.  If you don't need these
requirements, then you don't need bindings (you probably want "references").

   I am damn sure that I am not going to post-hoc implement alias integrity
   within Apache just because this protocol says that a DELETE must result
   in removal of all bindings to the binding being deleted.

Actually, we specifically contradict 2518, and say that a DELETE must
not result in the removal of all bindings to the resource being
deleted (note that we have bindings to resources, not bindings to
bindings).  Some servers will chose not to implement bindings, but
there is (we believe) a large community of clients and servers that
want/need the integrity constraints provided by the binding protocol.
For servers that chose not to implement BIND, then there is no
problem because there will not be multiple bindings to the same
resource (as defined in this protocol).

   Late binding,

Yes, and a simple limited form of that is provided by the redirect
reference protocol.  A more extensive form of that would be provided
by a "direct referenece" (i.e. a reference followed by the server),
but that is not what the BIND protocol is about.  Yaron and others have
indicated interest in developing a direct reference protocol, but that
is very different from a binding (i.e. integrity preserving) protocol.

There is a terminology question, i.e. should these non-integrity-preserving
things be called "weak bindings" or "direct references" (I'm a staunch
advocate of the latter), but this protocol is definitely not about
them, whatever we end up calling them.

A BIND request affects two resources: the source resource (it gets a
new binding to it) and the target collection (it gets a new binding in
it).  Whether this is implemented as an operation on the source
resource, the target collection, or both, is completely up to the
implementation.  You may need authentication on either or both
resources, and whether it is more efficient depends on the
implementation, so I believe that consistency with similar protocol
methods (COPY, MOVE) should take precedence over optimizing towards a
particular implementation.

If this really is an efficiency killer for an implementation, then I'm
certainly open to change, but I'd like to see that argument in more
detail.  This topic is much less important to me than the underlying
semantics, but seeing how many people get confused over the direction
of "ln" over the years (i.e. using it like "cp"), I'd hate to submit
WebDAV clients to the same confusion without good reason.

In particular, I'd like to see why any such argument doesn't apply
equally well to MOVE, which in practice does not seem to suffer from
having the target in the Destination header.

The key here is "to the resource identified by the Request-URI".  A client
can submit anything it wants the Destination URI, but if it's a COPY,
it won't go to the resource identified by the Request-URI, but rather
to some new resource.

If a client didn't want the old binding to be deleted unless the new
binding could be created, it's convenient to be able to specify both
operations in a single request.

I'm happy to improve the wording, but this distinction was the key
one that distinguished this approach from another that Yaron proposed
(i.e. the forest of mappings approach).  In this approach, when you
add a new binding, you can cause more than one (in fact, with cyclic
bindings, an infinite number) of new URL-resource mappings to be
created.  Knowing exactly what URL mappings will be introduced by a
BIND request is essential for a client to understand how to use multiple
bindings to collections.

This is emphasizing the above point, namely that adding a binding to a
collection creates a set of mappings, one for each URI mapping to that
collection.  We have found that most readers did not infer that from
statements like "a BIND adds a name to a collection".  So we need better
wording (if both Roy and Yaron find it confusing, I think we can safely
predict that others will as well :-).

The DAV:resourceid property is the only property that a client can
use in general to determine of two different URL's identify the same
resource.

Could you explain this?

I hear you on that "busy" thing (:-).  If you have time for a
couple more iterations, that would be great!

Cheers,
Geoff