W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

Re: LOCK Scenarios

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Tue, 17 Aug 1999 10:46:15 -0400
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243F9@crte147.wc.eso.mc.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
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.


Judith A. Slein
Xerox Corporation
800 Phillips Road 105/50C
Webster, NY 14580
Received on Tuesday, 17 August 1999 10:46:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:17 UTC