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.

I'd like to point out that there are a bunch of issues with the current lock
design of rfc2518.  JimW says that he's put them on the issues list.  I don't
think we can lean on the rfc2518 lock design until those issues get worked out.


>>
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.
>>
I'm with you, but I want to hold off on commenting further until we've
collected all the LOCK issues in one place.  JimW seems to be collecting
them.  (Thank you Jim.)

>>
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).
>>
Yes, good observations.  This should be added to the issues list to make
sure it isn't overlooked when we discuss locking.  The issue of depth locking
needs to be clarified.

>>
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.
>>
This link should be added to the issues list.    Jim....?  :-)

J.

Received on Tuesday, 3 August 1999 15:18:42 UTC