Re: Should REBIND preserve locks, other live properties

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

On Mar 19, 2004, at 5:33 AM, Geoffrey M Clemm wrote:

>
> 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
>
>
> Julian wrote on 03/19/2004 04:48:07 AM:
>
>> 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 Monday, 22 March 2004 15:15:28 UTC