Subject: RE: Bindings, Locks, and MOVE

From: "Slein, Judith A" <[email-masked]>
Date: Thu, 9 Sep 1999 11:11:26 -0400

Wait, I think we need to go back to the original proposals from the design
team.  There are a lot of separate points there, and SHOULD only applied to
one of them (not the one about whether locks survive a MOVE).

Here they are again, just for reference:

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. (This is a
reversal of the position taken in RFC 2518.)  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.

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.

I agree with Yaron's rant about SHOULD.  I think that changing the language
to SHOULD on this last point is a bad thing.

Back to the issue of having locks move when a resource is MOVEd:  The one
case that has been cited of a system that cannot move locks with a resource
is Windows 95.  I assume that it's really all the Microsoft file systems,
including future plans, that won't be able to comply if we say that locks
MUST move with their resources.  So that's a pretty serious pragmatic
consideration.

It still would be interesting to hear about other systems that do locking,
and whether they would be able to comply with the position stated above.

Setting aside for a minute the pragmatic considerations and looking for
technical ones: The only technical reason we have heard for not having locks
move with the resource is the case of cross-server moves.  Since we didn't
standardize an algorithm for constructing lock tokens, it might not be
possible for the destination server to preserve the lock token created by
the source server in a cross-server move.  We think we can solve this
problem by letting the destination server replace the lock token with one of
its own, and inform the client of the new lock token.

--Judy

> -----Original Message-----
> From: Yaron Goland (Exchange) [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 4:05 PM
> To: 'Slein, Judith A'; [email-masked]'; [email-masked]
> Subject: RE: Bindings, Locks, and MOVE
> 
> 
> The reason that locks are lost on MOVEs is that the 
> overwhelming majority of
> existing systems can not handle moving locks on MOVEs. We 
> could, of course,
> have said locks SHOULD NOT be lost on moves. But this sort of 
> language is
> exactly the type of language the destroys interoperability. 
> When I write a
> client I am going to write it to either demand that locks 
> move properly on
> moves in the average case (with exceptions handled as force 
> 10 failures) or
> I'm going to write it to assume that locks never work on MOVE 
> and set up my
> UI and APIs appropriately.
>  their UI and internal code in order to compensate. 
> 
> We will be consistent.
> 
> We will be uniform.
> 
> We will use "MUST."
> 
> If you want to change the language to say that locks MUST 
> move then we can
> discuss this, although I think preventing the majority of 
> existing systems
> in the world from supporting WebDAV is probably a bad idea. 
> If you want to
> use the Mandatory mechanism, I think that would be a great 
> idea. But the
> requirement absolutely will not be a SHOULD.
> 
> 		Yaron
> 
> P.S. Phew... I haven't had a good rant in a while. Feels good. =)
>

---

From: "Kevin Wiggen" <[email-masked]>
Date: Tue, 14 Sep 1999 11:11:48 -0700

My thoughts on the following subject, and some random thoughts...

1)  Xythos does have cross-server communication planned.  We have a hook for
it, some code written, but need to build a version that works with
proxy-servers etc.  This being said, I agree that cross-server MOVE is hard.
For all the reasons stated earlier plus other things such as keeping
permissions on a file constant across servers (especially if they are across
corporate barriers and users/groups do not exist on both servers.  I will
agree with the statements that cross-server MOVE should be out-of-scope for
Webdav, and should just return an error.  Clients can still issue a COPY,
then DELETE if they want.

Xythos will implement cross-server COPY.

2)  I am fine with the lock-token being MOVED with a resource.  If we can
get away with saying cross-server MOVE is not supported, then the individual
servers simply need to make a way of keeping locks on their own server.  I
believe this is how we should proceed.  It sounds like we are cutting out a
bunch of functionality, but I think it will take a whole set of working
groups to get cross-server MOVE to work correctly in all cases anyway, so we
might as well punt now.

3)  I believe (with I think most other people), that the language
surrounding the use of write-lock, should remain a MUST.

4)  I would then like to take Judith's original note on locks and work
though the scenarios to make sure we are all not missing anything...

I now assume that locks are locking the resource not the URI.

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.

<KW> /a/b moves to /x/y and remains locked with the same lock-token it had
before.  The only Lock Token mentioned still exists and remains on the
resource it was locking.</KW>

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

<KW> This one gets a little weird.  I assume that we can delete /x/y since
we have the lock on it.  This delete removes the lock from the system.  When
/a/b is moved to /x/y, it still is not locked.

As a user, I might expect that /a/b (which is now /x/y) has the /x/y lock,
but I have always thought (from a user's perspective) that a merge would
happen and not a delete followed by a write.  But the fact that the lock is
removed from the system, does make the rest of the scenarios work
nicely</KW>

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.

<KW> This will remove L2 from the system, and the new /x/y is still locked
by L1.</KW>

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.

<KW> Since the lock on /a/b comes from /a, the lock is not kept on its move.
/a remains locked, but the new resource /x/y loses the lock it had on it.
</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.

<KW> The original /x/y is removed, and the lock on that resource is removed.
/a/b is then moved there, and picks up the lock from its new parent /x/</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.

<KW> /x/y is removed and its resource is no longer locked by L2.  /a/b is
removed from /a's lock, and the resource is added to the L2 lock space.</KW>

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.

<KW> I believe this must FAIL.  A user cannot have 2 locks on the same
resource, and therefore needs to remove one of them before the MOVE can
happen.</KW>

8. The source collection is locked, the destination resource (not its
collection) is locked with a different token
MOVE /a/b to /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has
lock L2.

<KW> Strangely enough (to the user), this succeeds.  The lock L2 is removed
from the system during the DELETE phase of the move, /a/b is then moved.  It
is removed from /a's L1 and no lock now exists on the new /x/y </KW>

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.

<KW> Since locks are on resources, if the correct lock-token is passed, I
say this succeeds.  The new /x/y is still locked via /a's lock because the
binding for /a/b still exists.  In order to do something to the new /x/y you
need to pass the correct lock-token.</KW>

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

<KW> Again the MOVE succeeds if the token for R is given, the resource is
still locked and bound to /a/b and the new /x/y </KW>

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.

<KW> If correct lock token for R is given (If header with a tagged list of
/y/z and the correct token) the move completes.  Since /w is locking the
resource R, it continues to do so, but /y/z no longer maps to R so it is not
locked anymore </KW>

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

<KW> If the correct lock-token for R is passed (through the correct IF
header and tagged list), the MOVE succeeds.  When it is done, /w/x is still
locking R, and the new /y/z is no longer locked as it now points to a new
resource R2. </KW>

Kevin