Subject: Re: LOCK Scenarios

From: "Slein, Judith A" <[email-masked]>
Date: Tue, 17 Aug 1999 10:46:15 -0400

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
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 17 Aug 1999 11:35:18 -0400

It appears to me that Jim Amsden's intuition and the current wording of
the spec is more consistent than the "intended behavior".  In particular,
suppose you had three locks, on:

  /x
  /x/y
  /x/y/z.html

Now suppose you MOVE'd a new collection to /x/y.

I think we all agree that the lock on /x is unaffected.
But what about the locks on /x/y and /x/y/z.html?

It is consistent to say that all locks on deleted resources at
the destination are removed (i.e. consistent with the fact that
deleting a resource deletes its locks).

It is also consistent (although somewhat more complicated) to say
that the "delete" performed as a side effect of a MOVE is a special
kind of delete that does not remove locks.  But then neither the
lock on /x/y *nor* the lock on /x/y/z.html should be affected,
which means that if /x/y/z.html is not mapped to any resource
following the MOVE, then a lock-null resource must auto-magically
be created at /x/y/z.html after the MOVE.

In my opinion, the complexity of special casing delete for MOVE, and
creating these lock-null resources as a side effect of the MOVE,
significantly outweigh any benefits that might be achieved. 

Cheers,
Geoff

   From: "Slein, Judith A" <[email-masked]>
   Date: Tue, 17 Aug 1999 10:46:15 -0400
   Mime-Version: 1.0
   X-Mailer: Internet Mail Service (5.5.2448.0)
	   charset="iso-8859-1"
   Resent-From: [email-masked]
   X-Mailing-List: <[email-masked]> archive/latest/3159
   X-Loop: [email-masked]
   Sender: [email-masked]
   Resent-Sender: [email-masked]
   Precedence: list
   X-Lines: 42
   Content-Type: text/plain; charset="iso-8859-1"
   Content-Length: 1640

   -------

   --Judy