Re: LOCK Scenarios

Section 7.7 makes no mention of locks on the destination, only depth infinity
locks inherited from new parent collections. If the destination resource falls
within the scope of a depth infinity lock, then it inherits the lock, just like
PUT or MKCOL. I don't think the spec is inconsistent with regard to locks and
MOVE and COPY. It may not be the semantics everyone would want, but it is not
inconsistent. I'm not convinced that destination locks should be retained after
MOVE and COPY anyway as the destination is a new resource with new properties.
The lock was on the old resource which was deleted. However, I don't feel
strongly about these semantics as long as whatever we come up with is simple,
consistent, and predictable.




"Slein, Judith A" <JSlein@crt.xerox.com> on 08/17/99 10:46:15 AM

To:   "'WebDAV'" <w3c-dist-auth@w3.org>
cc:

Subject:  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 13:21:08 UTC