Re: Should REBIND preserve locks, other live properties

Lisa Dusseault wrote:

> In RFC2518, a MOVE operation is supposed to destroy all locks on the 
> moved resource and any descendants.  This behavior is unlike most 
> filesystems.  Yaron laid out the reasons but they weren't too strong.  
> Basically the reasons why not amounted to the fact that some systems 
> that didn't support bindings couldn't do this easily.
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html
> I'd assumed that a REBIND was different than MOVE, and couldn't be used 
> in as many cases.  If a REBIND is really the same as a MOVE then why are 
> we defining it?  If it's different -- e.g. if , as I had assumed, REBIND 

Because RFC2518 allows servers to implement MOVE as COPY/DELETE, and 
BIND can't override that (when it tried, we got complaints from people 
who rely on MOVE working as it does).

> is "safer" and more high-fidelity than MOVE (but can be used in fewer 
> cases) then we need to understand how it's different.
>
> If REBIND can be different than MOVE, then we can make a number of 
> things work better (more predictable) from a client point of view:
>  - locks aren't destroyed, lock token doesn't change, the lock state 
> appearing on other bindings doesn't change

However, the locking model we all agreed on (remember? -> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>) 
explicitly says...:

- If a request causes a directly locked resource to no longer be
   mapped to the lock-root of that lock, then the request MUST
   fail unless the lock-token for that lock is submitted in the
   request.  If the request succeeds, then that lock MUST have been
   deleted by that request.

So REBIND behaves exactly as the locking model is predicting it: a 
namespace operation causes the locked resource not being mapped anymore 
to the lock root, and thus the lock is removed.

Changing this would mean that the locking model needs to made more 
complicated (again). In this case, we couldn't talk about namespace 
operations in general, but would need to go back to special cases.

Unless there's a clear benefit from that complication, I vote with "no".

>  - getlastmodified date doesn't change unless another resource is 
> overwritten (for that matter, we could specify that REBIND can't 
> overwrite another binding which would make it even simpler), so the 
> getlastmodified date on other bindings doesn't change

Again, this is incompatible with HTTP semantics for the Last-Modified 
header, please see my other mail 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0108.html>).

>  - etag doesn't change...

Same.

>  - live properties have more guarantees in how they are preserved

Live properties aren't affected except for the unfortunate cases where 
they are. Same behaviour as in RFC2518.

>  - ACLs aren't re-inherited?

If you're talking about 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PROPERTY_inherited-acl-set>: 
no, they aren't.

>  - this makes a "rename" operation work exactly as the client expects it 
> would (not the case today with MOVE)
> 
> If a server can't implement REBIND -- well, there's still MOVE.

Lisa, the issue is that namespace operations in HTTP *can* *not* behave 
as in filesystems as far as HTTP headers such as "Last-Modified" or 
"ETag" are concerned -- this is just incompatible with HTTP, so there's 
no way to require it.

We *can* encourage servers to use "robust" ETags (Etags that are unique 
across all resources in the namespace) and thus don't have conflicts 
with ETags that may have been previously used for the same URL. But 
that's a general rule, not particular to BIND whatsoever, so if you 
think it's worth the effort, add it to RFC2518bis.

Regards, Julian


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

Received on Friday, 19 March 2004 04:49:02 UTC