Proposal on MOVE and locks

As a result of the discussions on the mailing list over the past week, the
design team would like to make some changes in its proposal about MOVE and
locks.

We agree that we should not be specifying any different behavior for
cross-server MOVEs than for MOVEs on the same server.  So we plan to take
out all normative language related to cross-server MOVEs.

We do want to stand by our basic position that locks MOVE with a resource,
since that is consistent with the underlying semantic model of bindings.  A
MOVE has no effect on the resource, but only involves creating a new binding
between the final segment of the Destination URI in its collection and the
resource, and removing the binding between the final segment of the
Request-URI in its collection and the resource.  The state of the resource
itself -- including its lock state -- is unchanged.

That leaves us with the following:

For MOVE (assuming that the principal performing the MOVE owns all locks
involved):

1. If there is a lock on the source resource that is rooted at the source
resource (that is, the lock is not inherited from a parent collection), the
lock moves with the resource to the destination.  

2. If there is a lock on the destination resource that is rooted at the
destination resource (that is, the lock is not inherited from a parent
collection), its lock is gone after the MOVE.

3. If the source resource inherits a lock from a parent collection, and the
resource is moved out of the tree affected by that lock, the lock no longer
applies to the resource after the MOVE.

4. If the destination resource inherits a lock from a parent collection, the
MOVEd resource inherits that lock after the MOVE.

5. If there is a lock on the source resource that is rooted at the source
resource, and the destination resource inherits a lock from a parent
collection, the MOVE fails due to a conflict between rules 1 and 4.

6. If a collection is MOVEd, and there are some locked resources in that
collection, the locks on those resources move with the resources.

For COPY: 

After the COPY, there will be no locks at the destination except what is
inherited from above.

Judith A. Slein
XR&T/Xerox Architecture Center
jslein@crt.xerox.com
8*222-5169

Received on Wednesday, 15 September 1999 16:02:25 UTC