RE: Proposal on MOVE and locks

This exact same question, regarding moves and locks, came up in the past and
the group consensus was that we should not allow locks to MOVE with
resources. To revoke this decision is to pull the rug out of implementers
who took WebDAV in good faith. This is exactly the sort of behavior which
makes some many companies wary of dealing with the IETF. The rules change
too often.

There is an alternative route which I believe meets everyone's needs. We
define a new header, which can optionally be used with mandatory, that
specifies that the move is only to succeed if the lock (if any) is moved
with it. If the header is absent the server MUST NOT move the lock. The
benefit of this system is that existing clients will continue to properly
interoperate with both existing WebDAV servers and future WebDAV servers. In
addition existing WebDAV servers will be able to properly interoperate with
both existing WebDAV clients and future WebDAV clients.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wed, September 15, 1999 1:02 PM
> To: 'WebDAV'
> Subject: 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 19:34:18 UTC