Re: LOCK Scenarios

See <jra> tags below...





"Slein, Judith A" <JSlein@crt.xerox.com> on 08/05/99 04:54:57 PM

To:   "'WebDAV'" <w3c-dist-auth@w3.org>
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
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Monday, 16 August 1999 13:46:10 UTC