RE: WebDAV Bindings - Issue Yaron.BindSyntax

I believe that eventually we will be forced to make it possible to specify a
bind both ways. That is, one can send the request either to the source or
the destination.

The reason has to do with how many tightly bound (and weakly bound) systems
are likely to be implemented.

I will use a real world example to help illustrate.

Imagine I have server S1 and server S2. They both share the same tightly
replicated NTFS volume. Both servers map onto a particular file in the NTFS
volume. Following the specification provided by both the Exchange and NT
WebDAV implementations the WebDAV properties associated with that file are
recorded as an "alternate" stream on that file. Alternate streams are a
feature in Windows 2000 implementation of NTFS that allows one to have
multiple independent named streams off a file. What this means is that
someone can come in through SMB, move a file and all its WebDAV properties
will remain because the file system will move all the streams associated
with the file. (Yes, I recognize the problems this can cause)

Anyway, S1 is just a standard issue W2K WebDAV server and so serves off
files from the NTFS volume. S2, on the other hand, is an enhanced WebDAV
server that has support for BIND. S1 and S2 can both refer to the same file
on the NTFS volume and still meet all the BIND integrity requirements.
However only S2 can explicitly create new bindings since S1 doesn't support
the BIND method.

Therefore if one wants to creating a binding to a file currently pointed to
by S1 then the request must be sent to S2 (S2, btw, can figure out what file
S1 is pointing at by checking the metabase, but that is a whole other
story). However the reverse is also true, if one wants to create a binding
to a file pointed to by S2 then the request MUST also go to S2 because S1
doesn't understand BIND.

Therefore what is needed is the ability to specify a BIND request which can
choose to either have the source or the destination in the request-URI.

I expect that eventually the exact same thing will happen to COPY and MOVE.
The only reason it didn't happen in RFC 2518 is that we all knew that for a
really long time COPY and MOVE would only work within a single server so we
weren't particularly worried about the issue. We probably should have been
but one has to pick one's battles. Don't be too surprised to see the same
source/destination flexibility introduced into the next version of RFC 2518.

Either way, I don't care if we solve this problem in the current BIND spec
so long as we leave the door open to solving the problem later. That is why
I asked for the very limited language. If the authors really want to tackle
the whole problem that is fine with me but I didn't want to force them to do
so.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tue, January 18, 2000 8:42 AM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: 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:56:48 UTC