Subject: Re: LOCK Scenarios

From: [email-masked]
Date: Fri, 6 Aug 1999 16:30:27 -0400

Judy, I've collected your scenarios and inserted them into a draft doc.   I'll
read through them more carefully later.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Fri, 13 Aug 1999 22:16:42 -0400

<KW> In case 9 and 10 I had arguments that the resource R, and not the
namespace should be locked.  This contradicts infinity locks a little, as
they lose and gain members on movement in the namespace.  So I guess I am
saying locks should LOCK the resource, but should be namespace aware :)
</KW>
It took a while to read it all, but I think I agree with everything you
said for scenarios 1 - 8.  It's difficult to express succinctly.  I
think it is after we get some vocabulary.

Lets call the URI at which the LOCK was placed the "lock URI".

The LOCK URI has special properties.  First of all, it is "protected".  These
scenarios don't cover that prroperty, but the Adv. Collection spec does.  It
means that among other things, that it's parent nodes (Is that what we call
them?) can not go through name space manipulations that would cause the locked
URI to disappear.  That is...

   if /a/b/c is locked, then /a/'s 'b' binding is not allowed to change and to
therefore take the URI "/a/b/c" out  of existance.  I'll leave that fuzzy for
now.  If we dig further, I'm sure we can find some complications in there.  The
idea behind protection is that we protect the URI so that someone that doesn't
have a lock can't make the LOCK URI mapping go away.  The thinking is that we
are locking that URI because we're going to be using that URI to perform some
operation on the resource.  If some other principal can make that URI go away or
map to something else, then we aren't happy.  (A URI is our only way of address
resources right now.)

In addition, the lock binds most tightly to the LOCK URI.  Then secondarily to
the resource at the LOCK URI.  That means if you change the resource at that
URI, the new resource gets the lock that was set to the LOCK URI.  (This what
your scenarios seem to suggest and it sounds like it might be what users want.)

Next... if the lock has depth... various descendent (vocab?) URI's are locked.
(We need vocabulary to distinguish this "locked" from what we are talking about
at the LOCK URI.)   And the resources at those URI's are locked.

The fact that these resources are locked also means that they are locked if
accessed through other URI's too... but that those URI's aren't necessarily
"protected".

Yes, this is a totally fuzzy definition.  I'll come up with a detailed boring
one later if this one shows promise.  Anyway, I think this is the definition
that you used for scenarios 1-8.   Now let me move on to 9 and 10....

Firstly, unless I misunderstand you, I think I disagree with what you've said
above about 9 and 10.  This seems to be in disagreement with 1-8.  I believe
that in the first scenarios, the LOCK URI is the primary location of the lock...
not necessarily the resource at that URI.  (Yes, this is in conflict with what
we've been thinking with AdvCollections, but I want to run with your proposal
which you demonstrated with scenarios 1 - 8...)  The resource IS locked, but
only by virtue of it's current relationship to the LOCK URI.  The fact that the
resource is locked does mean it (the resource itself) is locked at other
mappings too.

<JS>
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.
</JS>
<KW> Since the resource R is locked, if the correct lock token for /c/d is
given (the lock token for the lock holding R), then the move occurs.  Since
/a/b still points to R, /x/y is still locked via /a's lock. </KW>

I agree.

<JS>
9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to
/x/y.
</JS>
<KW> Again the MOVE succeeds if the token for R is given, the resource is
still locked by /a/b </KW>

I don't see why a token is necessary.. Yes R is locked, but the move is an
operation on the state of it's parent, not it.  (I assume that /a/ and /c/
aren't the same resource.)  That means the /c/d URI is not protected.  The /a/b
URI is, but the MOVE isn't threatening that mapping.  -- Besides the token
issue, I agree.

<JS>
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.
</JS>
<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 </KW>

I disagree about the lock token for the same reason as above... unless we're
possibly talking about a depth lock token.  Let's first assume we're not.
Moving /a/b to /y/z is changing the state of the collections /a/ and /y/.  (At
least that's how we have been thinking about it in the AdvColl discussions.)
Since neither of them is locked, the lock is irrelevant in the example.    (BTW,
I assume /w/ and /y/ are not two mappings for the same collection.)

Now if it's a depth lock.... which I think you assumed... In that case, R is
locked by virtue of being accessable via /w/x.  But I assert that that lock
remains irrelevant.  When all the operations are through, resource R remains
accessible via /w/x  and R remains locked.  Nothing attempted threatens to break
the lock.  It just becomes accessible through different mappings, but the
mappings that were lost were not PROTECTED by that particular lock since the
LOCK URI was not involved.

I agree about everything else besides the token.

<JS>
10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to
/y/z.
</JS>
<KW> Given the correct lock tokens (See above), the move succeeds.  The lock
is then lost according to number 2 above.  Again I would argue that the lock
on /w/x would still be there with the same logic as in number 2 above </KW>

Once again, I say the lock tokens aren't relevant here.  Nor is the lock.  R
continues to exist.  It's state hasn't changed.  And the LOCK URI wasn't
threatend by the move.

11) - One thing I want to point out is a combination of 9 and 10.  Both the
source and the destination are locked.  By different locks.  Exclusive locks.
 /a/b and /c/d map to R.   /a/ is depth locked.
/x/ is depth locked.
move /c/d to /x/y

In all the similar cases above, I believe we said it succeeded.   But in this
combination, I believe it fails.  Why?  Because if it succeeded, R would be
accessable via /a/b  and /x/y.  but both /a/ and /x/ are depth locked.
Exclusively.  That means R somehow would have inherited two exclusive
locks..  That sounds like something we have to disallow.  :-)   (Well, maybe.
I'll make another post on a twist on this in a sec.)

Anyway, Kevin, I think you have a viable proposal.  I think most of us were
expecting a resource to be the primary holder of a lock.  That seems like
something that would be easy to understand and would seem like what one would
want on first blush.   But I think you've suggested is that what clients might
prefer is that the LOCK-URI own the lock... and whether a resource is locked is
determined if the resource that has a mapping the is or descends from that URI.
As resources are moved around they might be added or removed from the lock as
their mappings change.  And even the resource mapped to the LOCK-URI itself can
change... and thus be added or removed from the lock.

I think we should keep your proposal on the table.  And probably define it more
rigorously.

J.

---

From: [email-masked]
Date: Mon, 16 Aug 1999 16:51:07 -0400

I agree with all of Kevin's observations below. In particular, if you MOVE a
resource to a destination where the (new) parent collection is locked, you need
the lock token for that parent collection in order to add the new member. Sorry,
I wasn't careful enough in my response. It's easy to get all these rules mixed
up or forget one - ample justification for keeping things simple and regular.

"Kevin Wiggen" <[email-masked]> on 08/16/99 03:46:42 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS, [email-masked]
cc:

Subject:  RE: LOCK Scenarios

<KW> tags.... Thanks for bringing up COPY, we should be making it a priority
as well in all of this..

I am OK with 1-3.  I might argue that locks on the destination should
remain, but I could be convinced otherwise.

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><KW> agree</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.
<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>
<KW> Disagree with the part about No lock token required.  Since you are
changing /x's contents, you need /x's LOCK.  /a/b is moved to /x and added
to its LOCK </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.
<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><KW> Same arguement as above.  2 Lock token's required, /a loses /a/b
as a resource and loses it from its lock.  /x/y now exists as a new resource
(/a/b) but is still locked by L2.</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.
<jra>
L1 is required in the If header. /x/y will be locked with lock L2 if it is a
depth infinity lock.
</jra><KW> Both locks are required in IF header for reasons above.  L1 is
removed from system (nothing left to lock?) while new /x/y is in L2 due to
infinity lock</KW>

I agree that some mention must be made of the Depth header on the collection
locks.  We need to add it and COPY to the use cases that are being argued..

Kevin

---

From: [email-masked]
Date: Tue, 17 Aug 1999 11:39:50 -0400

Judith,

> Two people have now taken a careful look at the lock / MOVE scenarios.
At least three people.  You overlooked my note.

<JS>
Kevin's intuitions are consistent: It is always the lock at the destination
that survives after a MOVE, whether that lock is inherited from a collection
or is directly on the resource at the destination.
<JS>
Agreed.  They seem consistant and your interpretation of what he's said sounds
right.  As my note pointed out, I think he had some trouble on whether lock
tokens are required though in scenarios 9/10.  It seemed to be based on his
assumption that changing the membership of a collection isn't an operation on
the collection.  Just on the resource already at the URI.  In subsequent notes
in response to Jim, Kevin seemed to recognize the role of the parent though.

<JS>
Jim Amsden's intuitions about the scenarios were different: No singleton
lock ever survives a MOVE, but a resource that is moved into a locked
collection does inherit the collection's lock.
</JS>
Just for the sake of consistancy,  I prefer the singleton and depth locks
to be treated the same.  Just as Kevin apparently does.

<JS>
Cases 9 and 10 poke at the complexities added by multiple URI mappings to
the same resource.

Kevin's intuitions say that there is really no added difficulty about
resolving these cases.  It's the resource that gets locked, as rfc 2518
says, and it's still true that any lock, inherited or singleton, at the
destination, survives the move.
</JS>
I disagree somewhat with "it's the resource that gets locked" as sumarizing
Kevin's interpretation.  If the resouce moves and doesn't carry the lock with it
at times, then I don't think it's correct to say it's the resource that
is locked.  At least not without further explanation.  That's what my
note pointed out.  But yes, if a resource is locked at one mapping, it is
locked at all.  But only the original URI mapping is "protected"... using
the AdvColl definition of "protected".  At least that was my proposal... based
on AdvColl discussions.

J.

---

From: [email-masked]
Date: Tue, 17 Aug 1999 13:13:15 -0400

Section 7.7 makes no mention of locks on the destination, only depth infinity
locks inherited from new parent collections. If the destination resource falls
within the scope of a depth infinity lock, then it inherits the lock, just like
PUT or MKCOL. I don't think the spec is inconsistent with regard to locks and
MOVE and COPY. It may not be the semantics everyone would want, but it is not
inconsistent. I'm not convinced that destination locks should be retained after
MOVE and COPY anyway as the destination is a new resource with new properties.
The lock was on the old resource which was deleted. However, I don't feel
strongly about these semantics as long as whatever we come up with is simple,
consistent, and predictable.

"Slein, Judith A" <[email-masked]> on 08/17/99 10:46:15 AM

To:   "'WebDAV'" <[email-masked]>
cc:

Subject:  Re: LOCK Scenarios

Jim Whitehead confirmed that this was the intended behavior specified in
section 7.7 of rfc 2518.

As Kevin points out, the language in 8.8.4 and 8.10.5 together seems to
contradict this, so the inconsistency in rfc 2518 needs to be straightened
out.  Section 8.10.5 says that if Overwrite is "T", the resource at the
destination will be deleted, and section 8.8.4 says that if a resource is
deleted, all its locks are removed.  So the upshot seems to be that after
the MOVE, any singleton lock at the destination will be gone.

Jim Amsden's intuitions about the scenarios were different: No singleton
lock ever survives a MOVE, but a resource that is moved into a locked
collection does inherit the collection's lock.  So Jim's intuitions agree
with sections 8.8.4 and 8.10.5, and with interpreting section 7.7 to be only
about inheriting collection locks, and not about singleton locks.

-------

--Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580