Subject: Should REBIND preserve locks, other live properties

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 Mar 2004 16:05:14 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Mar 2004 10:48:07 +0100

Lisa Dusseault wrote:

> 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.
>

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 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)
> 

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Mar 2004 08:33:53 -0500

I agree with Julian's responses.

In addition, a client-side motivation for the "delete on MOVE" behavior of
locks is that it simplifies client-side lock management.  When the
client locks a resource, it just adds the request-URL of the lock
and the returned lock token to its list of URL/lock-token pairs.
It knows that that lock-token will be at that URL for the lifetime of
that lock-token.  If locks were not deleted when the protected URL
was unmapped, it is harder for a client to keep track of its locks.

Cheers,
Geoff 

> > in as many cases.  If a REBIND is really the same as a MOVE then why 
are 
> >  - this makes a "rename" operation work exactly as the client expects 
it

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 22 Mar 2004 12:14:46 -0800

So if REBIND is the same as MOVE in all cases, why are we defining it?

I reject the argument that this behavior is needed for REBIND as well  
as MOVE for client convenience.  MOVE would remain as defined for  
clients that want the convenience of keeping URL/Lock-token pairs  
unchanged.  A new method, like RENAME, could provide clients a  
completely optional method with different convenience tradeoffs: the  
convenience of not having to issue a new LOCK request if further  
resource changes are required, etc.  That's what I thought the original  
intent of REBIND was.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Mar 2004 21:31:13 +0100

> So if REBIND is the same as MOVE in all cases, why are we defining it?

It isn't 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html#METHOD_REBIND>):

"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."

> resource changes are required, etc.  That's what I thought the original  

Well, it isn't. If you feel that there should be a method allowing 
namespace manipulation while maintaining locks, you're free to work on 
it (I may even be interested on supporting it, once it's defined).

But this wasn't on the requirements list for BIND, and IMHO nobody has 
asked for it recently, so it doesn't belong into BIND. It's a completely 
separate issue.

Regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 23 Mar 2004 11:12:16 -0500

I agree with Julian that point of REBIND/UNBIND is (and has always been)
to define an atomic form of MOVE/DELETE.

The only point at which we differ is that he might be interested in
supporting a lock-preserving RENAME method, while I am not (:-).

Cheers,
Geoff