Re: Remaining issues with the bind draft -- process

Antony Blakey wrote:

> ...
> To be honest, my comments were motivated by watching the discussion 
> between (principally) Lisa and Julian, rather than reading the most 
> recent BIND spec, although now I'm motivated to do that!

That whould be great...

> I know there have been arguments about DELETE not being equivalent to 
> UNBIND, and MOVE not being BIND+UNBIND. However, our implementation is 

Well, REBIND isn't MOVE as the working group couldn't change the 
semantics for MOVE (that would have breaked existing code). Thus REBIND 
is introduced as atomic version of MOVE:

"The REBIND method removes a binding to a resource from one collection, 
and adds a binding to that resource into another collection. It is 
effectively an atomic form of a MOVE request."

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_REBIND>

Clients can now select a best-effort move (MOVE) or a transactional one 
(REBIND), when supported by the server.

The situation for DELETE vs UNBIND is a bit more complicated. Do you 
think the rational should be explained here?

> transactional and non-transactional semantics seem broken to us - that's 
> one place where some non-normative content motivating these distinctions 
> would help. As another (tangential) example, having a lock create a new 

Well, that's an issue with RFC2518, right? MOVE and DELETE aren't atomic 
for the simple reason that there are servers that can't or don't want to 
implement in atomically.

> resource seems, on the surface, broken to us, because effects caused by 
> a failed lock creator should be rolled back at the server. IMO any spec 
> specifying that behaviour should say why that's required. I'm sure there 
> must be some reason for this that non-transactional environments 
> require, which is outside our headspace.

I'm not sure what you're talking about here. LOCK is a bit special in 
that it creates an empty resource when the URL wasn't mapped before, but 
that is needed to implement a safe way to do a safe "save as" operation. 
The LOCK operation itself is transactional. Either it succeeds (and 
creates a locked resource), or it fails (in which case nothing should be 
left). BTW, this is standard RFC2518 and has nothing to do with BIND.

> As a matter of completeness: it has always seemed to me that binding is 
> more fundamental than locking, and that it would be better to have the 
> WebDAV spec recast in terms of bindings, with support for more than one 
> binding to a resource as an implementation option. Locking would then be

I agree with the fact that bindings are more fundamental, as they affect 
the understanding of the relation of URLs, collection membership and 
resources. That being said, RFC2518 already does that in a minimal way; 
it just calls bindings "internal member URIs" and doesn't provide

- "same resource" discovery
- explicitly creating new bindings

But the concept per se is there.

> on top of that, explaining how core semantics are modified in the 
> presence of locks. I know this isn't going to happen.

Well, we've been discussing separating locking from the rest for some 
time now (see the mail thread that started in January: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/thread.html#30>). 
However, this proposal affects an official working group item 
(RFC2518bis), so we didn't make any progress here yet, missing support 
from the RFC2518bis authors.


Regards, Julian
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 6 April 2004 03:31:00 UTC