Should REBIND preserve locks, other live properties

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 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
  - 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
  - etag doesn't change...
  - live properties have more guarantees in how they are preserved
  - ACLs aren't re-inherited?
  - 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

Received on Thursday, 18 March 2004 19:05:30 UTC