RE: WebDAV Bindings - Issue Yaron.BindSyntax

There was a lot of discussion among the authors about the meanings of the
request-URI and the Destination header in the BIND request.
 
It was actually initially written so that it asked for the creation of a
binding at the Request-URI to the resource identified by the Destination
header.  The rationale for this was that it seemed more intuitive to have
the syntax of the request reflect the natural-language request: Create a
binding from this segment to this resource.  (Anyhow, that's how the spec
always expresses the request in English.)  And it seems as if the
Request-URI should identify the resource for which authorization would be
required to fulfill the request.  It's the collection where the binding
lives that gets modified, and so update permission would be needed on that
collection, and so that collection should be identified by the Request-URI.
 
We changed this to be consistent with the usage in COPY and MOVE, thinking
that it would be too confusing otherwise.  And servers would have to
interpret the Overwrite header differently for BIND than for COPY / MOVE if
we used the Request-URI and the Destination header differently than COPY /
MOVE.
 
We did not consider the implications of adding weak bindings.
 
But I would personally rather go back to the original syntax than introduce
a new header (or even suggest that such a header be introduced in the
future) that would flip the meanings of the Request-URI and Destination
header in a given request.  That is, I would propose that in all BIND
requests, the Request-URI identify the new binding, and the Destination
header identify the existing resource being bound to.
 
If it still seems unacceptable to be in conflict with the syntax of MOVE /
COPY, I would rather just go ahead and define a new header now that would
always be used in BIND requests to identify the resource being bound to.
That is, we would not use the Destination header at all.
 

- -Judy

 -----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:47 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.BindSyntax



The BIND spec defines that a binding is created by sending a message to the
source and instructing it to create a binding at the destination. This is
completely consistent with how WebDAV normally operates in methods such as
COPY/MOVE where the source is instructed to make changes at the destination.
Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings. The problem is that the
current bind syntax requires the active participation of the source to
create a bind at the destination. In the case of a weak binding it is
expected that the source may not even be aware of the binding. This is one
of the main benefits of introducing weak bindings, it allows for bind like
behavior without requiring the participation of the source. This enables
many resources to have weak bindings against a resource without overloading
the resource.

An example may help here. Imagine a user wants to create a weak binding to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar> . Currently, to
create this weak binding, the user would have to issue the bind method to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar>  and ask the
Yahoo server to somehow communicate with the destination server and create a
weak binding. This is like telling people that before they can add a
hyperlink to their HTML document they have to first get the resource pointed
to by the hyperlink to somehow participate in the process. The ability to
link to resources without the knowledge of the source (as the term is used
in the BIND method) has been one of the key aspects of the scalability of
the Web.

In my mind the proper solution is to introduce a source header that, when
used on a BIND method, would mean that the request-URI specifies the
destination rather than the source.

That having been said I really have no desire to prolong the agony of the
BIND authors by asking them to add a new header and deal with all the
complexities it would introduce. As such I am happy to settle for the
following paragraph being added to section 5.1: "The BIND method MUST fail
if it does not include a destination header. Note, however, that future
specifications MAY introduce additional headers that resources could honor
in the place of the destination header and so allow the BIND method to
succeed in the absence of a destination header."

This would allow us, in the future, to introduce a weak binding spec that
could still use the BIND method without forcing us to use MAN or introduce a
new method.

Received on Tuesday, 18 January 2000 11:42:11 UTC