Bindings, Locks, and MOVE

The authoring team for the bindings spec had a discussion of locks and MOVE
in the context of bindings, and wants to test its conclusions with the
mailing list members.  (For a complete record of the discussion, see the
minutes of 8/31/99, accessible from
http://www.ics.uci.edu/pub/ietf/webdav/.)


AGREED: 
For MOVE, if the source resource is locked (the lock is not inherited from
a parent collection), the lock moves with it to the destination.  If the 
destination resource is locked (the lock is not inherited from a parent
collection), its lock is lost.  
For MOVE, if it's the parent collections that are locked, the resource
being moved inherits the lock of the destination collection.
If a collection is MOVEd, and there are some locked resources in that
collection, the locks on those resources get moved.
We don't require support for cross-server MOVEs where the source resource
is locked, but we will define an optional lock header for use in
responses, so that the destination server can change the lock token and
return the new token with its response.  If the server allows a cross-
server MOVE but elects not to return a lock token value, the client
can do lock discovery to find it out. 
If a cross-server MOVE is allowed in a case where there are multiple
bindings to the source resource, and the source resource is locked, the
result will be that the resource is locked on both servers with the same
lock token in both places.  (If the same lock token cannot be used, the
MOVE must fail.)
For COPY, any locks at the destination are deleted, and no new locks are
created at the destination.  After the COPY, there will be no locks at
the destination except what is inherited from above.

This is a reversal of the position taken in RFC 2518.

Most people's intuition is that a MOVEd resource is the same resource, with
the same state (including its lock state).

The only rationale that has been presented for having locks be lost after a
MOVE is the case of cross-server MOVEs.  The source server and destination
server may use different URI schemes for lock tokens, so that the
destination server may be unwilling to keep the same lock token for the
MOVEd resource.

We can make support for cross-server MOVEs of locked resources optional, and
allow the destination server to replace the lock token with a different lock
token.  We'll provide a response header for it to use to report the new lock
token.

AGREED: We'll change the language related to protecting the
Request-URI to SHOULD.  We intend this to protect the entire path,
including the final segment.  This does impact the definition of write
locks in RFC 2518, which will have to change.  It's no longer that a
write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent
them.

This discussion began with Yaron's comment that saying that "it MUST NOT be
possible for a principal other than the lock owner to make a locked resource
inaccessible via the URI mapping used to lock the resource" is too strong.
It may make sense for write locks as defined in RFC 2518, but may not make
sense for other sorts of locks that don't restrict MOVE and DELETE.

The user expectation would be that the Request-URI used to lock the resource
would continue to work for the duration of the lock, so we should go as far
as is practical toward protecting the Request-URI.

Locks can disappear anyhow due to administrator actions, and it is quite
unlikely that anyone will interfere with the Request-URI while a lock is in
force, so it's ok to weaken the normative language from "MUST NOT" to
"SHOULD NOT".

But we want to be consistent for the whole Request-URI.  That would mean
weakening the definition of write lock in RFC 2518, so that a write lock
only SHOULD prevent other principals from MOVE or DELETE on the locked
resource, not MUST.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Thursday, 2 September 1999 10:23:34 UTC