Re: LOCK Scenarios

Two people have now taken a careful look at the lock / MOVE scenarios.

Kevin's intuitions are consistent: It is always the lock at the destination
that survives after a MOVE, whether that lock is inherited from a collection
or is directly on the resource at the destination.

Jim Whitehead confirmed that this was the intended behavior specified in
section 7.7 of rfc 2518.

As Kevin points out, the language in 8.8.4 and 8.10.5 together seems to
contradict this, so the inconsistency in rfc 2518 needs to be straightened
out.  Section 8.10.5 says that if Overwrite is "T", the resource at the
destination will be deleted, and section 8.8.4 says that if a resource is
deleted, all its locks are removed.  So the upshot seems to be that after
the MOVE, any singleton lock at the destination will be gone.

Jim Amsden's intuitions about the scenarios were different: No singleton
lock ever survives a MOVE, but a resource that is moved into a locked
collection does inherit the collection's lock.  So Jim's intuitions agree
with sections 8.8.4 and 8.10.5, and with interpreting section 7.7 to be only
about inheriting collection locks, and not about singleton locks.

-------

Cases 9 and 10 poke at the complexities added by multiple URI mappings to
the same resource.

Kevin's intuitions say that there is really no added difficulty about
resolving these cases.  It's the resource that gets locked, as rfc 2518
says, and it's still true that any lock, inherited or singleton, at the
destination, survives the move.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Tuesday, 17 August 1999 10:46:07 UTC