Subject: Re: LOCK Scenarios

From: [email-masked]
Date: Mon, 16 Aug 1999 13:45:56 -0400

See <jra> tags below...

"Slein, Judith A" <[email-masked]> on 08/05/99 04:54:57 PM

To:   "'WebDAV'" <[email-masked]>
cc:

Subject:  LOCK Scenarios

We've been concerned about interactions between MOVE and locks.  Logically
speaking, I think we have to consider the following cases.  (They are not
all equally realistic, but they all are possible.)  The question to answer
about each one is whether it seems right for the resource to be locked after
the MOVE, and if so, which lock should apply to it after the MOVE.

Considering these cases *may* help us decide whether the design principles
applied in RFC 2518 were the right ones.  Speaking for myself, I find that I
don't have clear and consistent reactions to these cases, so I find myself
relying on other considerations like what our underlying models imply, and
implementation considerations.

Anyhow, here are the cases:

In all cases, we assume that the agent requesting the MOVE owns all the
locks in question.

A resource is being MOVEd.  The locks are on that resource and / or its
destination, not the collections that contain them.

1. The source resource is locked, but the destination is not.
MOVE /a/b to /x/y, where /a/b is locked  but /a/ is not and /x/y is not.
<jra>
Lock token is required on source for MOVE, but not COPY. /x/y is not locked
after the MOVE or COPY.
</jra>

2. The source resource is not locked, but the destination is.
MOVE /a/b to /x/y, where /a/b is not locked and /x/ is not locked, but /x/y
is locked
<jra>
The lock token for the destination is required in the If header for both MOVE
and COPY, and overwrite must be "T". The destination is not locked after the
MOVE or COPY.

Although at first, this seems to loose the lock, but the destination is a
different resource, so it's not clear it should be locked after the MOVE or
COPY.
</jra>

3. Both are locked, but with separate locks.
MOVE /a/b to /x/y, where /a/b has lock L1 and /x/y has lock L2, but neither
/a/ nor /x/ is locked.
<jra>
Both lock tokens are required in the If header for MOVE, only the destination
for COPY. The destination is not locked after the MOVE operation.
</jra>

A resource is being MOVEd.  The locks are Depth: infinity locks on the
collections that contain either the source or the destination location.

4. The source collection is locked, but the destination collection is not
MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not.
<jra>
The source lock token is required in the If header. /x/y is not locked after the
MOVE.
</jra>

5. The source collection is not locked, but the destination collection is.
MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/
is locked.
<jra>
No lock token is required. /x/y will be added to /a's write lock if it is a
depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation.
</jra>

6. Both are locked, but with separate locks.
MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2.
<jra>
The source lock token is required in the If header. /x/y will be added to /a's
write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after
the MOVE operation.
</jra>

One lock is at the collection level, the other at the resource level.

7. The source resource is locked, and the destination collection is locked
with a different token
MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has
lock L2.
<jra>
L1 is required in the If header. /x/y will be locked with lock L2 if it is a
depth infinity lock.
</jra>

8. The source collection is locked, the destination resource (not its
collection) is locked with a different token
MOVE /a/b ro /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has
lock L2.
Both lock tokens L1 and L2 are required in the If header, and overwrite must be
"T".
</jra>

For the following cases, should the MOVE succeed or fail? If it succeeds,
what should the lock state be afterwards?

9. The source resource was locked through one mapping, and a MOVE is
attempted through a different mapping.
9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y.
<jra>
The question here is, do we lock URLs or do we lock resources. If we lock
resources, then we don't have enough information. We need to know what /a/ maps
to.
</jra>

9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to
/x/y.

10. The destination resource was locked through one mapping, and a MOVE is
attempted through a different mapping.
10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z.
<jra>
if the locks are on the resources, not the URLs that map to them, then it
wouldn't matter which mapping was used to access the resource.
</jra>

10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to
/y/z.

--Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: "Kevin Wiggen" <[email-masked]>
Date: Mon, 16 Aug 1999 12:46:42 -0700

<KW> tags.... Thanks for bringing up COPY, we should be making it a priority
as well in all of this..

I am OK with 1-3.  I might argue that locks on the destination should
remain, but I could be convinced otherwise.

4. The source collection is locked, but the destination collection is not
MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not.
<jra>
The source lock token is required in the If header. /x/y is not locked after
the
MOVE.
</jra><KW> agree</KW>

5. The source collection is not locked, but the destination collection is.
MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/
is locked.
<jra>
No lock token is required. /x/y will be added to /a's write lock if it is a
depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation.
</jra>
<KW> Disagree with the part about No lock token required.  Since you are
changing /x's contents, you need /x's LOCK.  /a/b is moved to /x and added
to its LOCK </KW>

6. Both are locked, but with separate locks.
MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2.
<jra>
The source lock token is required in the If header. /x/y will be added to
/a's
write lock if it is a depth infinity lock. Otherwise, /x/y is not locked
after
the MOVE operation.
</jra><KW> Same arguement as above.  2 Lock token's required, /a loses /a/b
as a resource and loses it from its lock.  /x/y now exists as a new resource
(/a/b) but is still locked by L2.</KW>

7. The source resource is locked, and the destination collection is locked
with a different token
MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has
lock L2.
<jra>
L1 is required in the If header. /x/y will be locked with lock L2 if it is a
depth infinity lock.
</jra><KW> Both locks are required in IF header for reasons above.  L1 is
removed from system (nothing left to lock?) while new /x/y is in L2 due to
infinity lock</KW>

I agree that some mention must be made of the Depth header on the collection
locks.  We need to add it and COPY to the use cases that are being argued..

Kevin