RE: [Moderator Action] Questions on Webdav Servers, MOVE and dest LOCK

I think it was our intention that the advanced collection spec be consistent
with the lock semantics described in rfc 2518.  In fact, we explicitly say
this is the case in 4.2.11 LOCK and UNLOCK.

However, it's also true that we didn't consider interactions with locks when
we were defining MOVE semantics.  If you just read 4.2.10 MOVE and Bindings,
you would probably expect that if a resource was locked before a MOVE, it
would still be locked after the MOVE; and if it was not locked before a
MOVE, it would not be locked after the MOVE.

So I think we say or imply conflicting things in the advanced collections
spec, and we need to figure out what we really want our story to be.  I
agree that we need to address these cases explicitly.

My own feeling is that when you MOVE a resource, the result is the same
resource, with all the same properties, at a different location.  So it
should have the same lock that it had at the source location.  

On the other hand, when we are thinking about simple resources inheriting
locks from their parent collections, and moving a bunch of these resources
around, it is certainly simpler to manage the locks if the simple resources
inherit locks dynamically from their parent collections -- so that when you
unlock a collection, you unlock all the resources that are in it at the time
of the unlock rather than the ones that were in it when the lock was applied
(which may reside anywhere by the time the lock is removed).

The earlier rationale for having MOVE destroy the lock on a resource is at
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html.


> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Monday, July 26, 1999 9:48 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: [Moderator Action] Questions on Webdav Servers, MOVE and
> dest LOCK
> 
> 
> 
> <prev>
> > 3)  MOVE/COPY to a destination that is locked.  8.10.5 states "... a
> > successful DELETE of a resource MUST cause all of its locks to be
> > removed."
> > and 8.8.4 states that overwrite set to T will do a DELETE....
> > Then will the
> > LOCK on the destination be lost??  This seems wrong to me.  If the
> > destination is LOCKED, then after a MOVE/COPY which might delete the
> > resource, I would assume the resource is still locked.
> 
> If the destination of a COPY/MOVE is locked, and you submit 
> the lock token
> of the destination lock in the If header, then the intent of 
> RFC 2518 is
> that the destination resource should be locked.  This is stated in the
> second paragraph of section 7.7.
> </prev>
> 
> Note: Although I don't think we deal directly on the topic of
> locks at the destination in the Adv Coll spec, 7.7 does seem to
> be in disagreement
> with the MOVE semantics of the Adv. Coll. proposal. If anyone
> feels strongly that section 7.7 should remain
> as is, I suggest that they do a read of the Adv Coll
> document and then express their opposition.  I just don't
> want our Adv Coll work in this area to surprise anyone.
> 
> We also should make sure that the Adv Coll document is *clear*
> on what should happen in this situation.  My opinion is that
> the destination lock should go away as should the locks of
> any decendent nodes in the URI tree at the destination.  I
> could be persuaded otherwise for a lock on the destination
> URI/resource specifically though.
> 
> J.
> 
>

Received on Tuesday, 3 August 1999 14:23:47 UTC