RE: Bindings, Locks, and MOVE

Lock tokens are universally unique therefore unless a server has made the
really silly mistake of encoding useful information in the lock token it
should be able to use the existing token.

In general, any time you feel the need to specify cross-server behavior you
can be absolutely sure that the base standard has a design mistake.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Thursday, September 09, 1999 8:11 AM
> To: Yaron Goland (Exchange); Slein, Judith A; 'jamsden@us.ibm.com';
> w3c-dist-auth@w3.org
> Subject: 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 Friday, 10 September 1999 13:55:51 UTC