RE: Bindings, Locks, and MOVE

Wait, I think we need to go back to the original proposals from the design
team.  There are a lot of separate points there, and SHOULD only applied to
one of them (not the one about whether locks survive a MOVE).

Here they are again, just for reference:

AGREED: 
For MOVE, if the source resource is locked (the lock is not inherited from
a parent collection), the lock moves with it to the destination. (This is a
reversal of the position taken in RFC 2518.)  If the  destination resource
is locked (the lock is not inherited from a parent collection), its lock is
lost.  
For MOVE, if it's the parent collections that are locked, the resource
being moved inherits the lock of the destination collection.
If a collection is MOVEd, and there are some locked resources in that
collection, the locks on those resources get moved.
We don't require support for cross-server MOVEs where the source resource
is locked, but we will define an optional lock header for use in
responses, so that the destination server can change the lock token and
return the new token with its response.  If the server allows a cross-
server MOVE but elects not to return a lock token value, the client
can do lock discovery to find it out. 
If a cross-server MOVE is allowed in a case where there are multiple
bindings to the source resource, and the source resource is locked, the
result will be that the resource is locked on both servers with the same
lock token in both places.  (If the same lock token cannot be used, the
MOVE must fail.)
For COPY, any locks at the destination are deleted, and no new locks are
created at the destination.  After the COPY, there will be no locks at
the destination except what is inherited from above.

AGREED: We'll change the language related to protecting the
Request-URI to SHOULD.  We intend this to protect the entire path,
including the final segment.  This does impact the definition of write
locks in RFC 2518, which will have to change.  It's no longer that a
write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent
them.

I agree with Yaron's rant about SHOULD.  I think that changing the language
to SHOULD on this last point is a bad thing.

Back to the issue of having locks move when a resource is MOVEd:  The one
case that has been cited of a system that cannot move locks with a resource
is Windows 95.  I assume that it's really all the Microsoft file systems,
including future plans, that won't be able to comply if we say that locks
MUST move with their resources.  So that's a pretty serious pragmatic
consideration.

It still would be interesting to hear about other systems that do locking,
and whether they would be able to comply with the position stated above.

Setting aside for a minute the pragmatic considerations and looking for
technical ones: The only technical reason we have heard for not having locks
move with the resource is the case of cross-server moves.  Since we didn't
standardize an algorithm for constructing lock tokens, it might not be
possible for the destination server to preserve the lock token created by
the source server in a cross-server move.  We think we can solve this
problem by letting the destination server replace the lock token with one of
its own, and inform the client of the new lock token.

--Judy

> -----Original Message-----
> From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com]
> Sent: Wednesday, September 08, 1999 4:05 PM
> To: 'Slein, Judith A'; 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org
> Subject: RE: Bindings, Locks, and MOVE
> 
> 
> The reason that locks are lost on MOVEs is that the 
> overwhelming majority of
> existing systems can not handle moving locks on MOVEs. We 
> could, of course,
> have said locks SHOULD NOT be lost on moves. But this sort of 
> language is
> exactly the type of language the destroys interoperability. 
> When I write a
> client I am going to write it to either demand that locks 
> move properly on
> moves in the average case (with exceptions handled as force 
> 10 failures) or
> I'm going to write it to assume that locks never work on MOVE 
> and set up my
> UI and APIs appropriately.
>  their UI and internal code in order to compensate. 
> 
> We will be consistent.
> 
> We will be uniform.
> 
> We will use "MUST."
> 
> If you want to change the language to say that locks MUST 
> move then we can
> discuss this, although I think preventing the majority of 
> existing systems
> in the world from supporting WebDAV is probably a bad idea. 
> If you want to
> use the Mandatory mechanism, I think that would be a great 
> idea. But the
> requirement absolutely will not be a SHOULD.
> 
> 		Yaron
> 
> P.S. Phew... I haven't had a good rant in a while. Feels good. =)
>

Received on Thursday, 9 September 1999 11:11:54 UTC