Subject: Re: are depth 0 locks inherited by newly created children?

From: Jim Davis <[email-masked]>
Date: Fri, 26 Nov 1999 00:22:33 +0100

At 09:31 AM 11/24/99 -0500, [email-masked] wrote:
> Jim Davis wrote:
>> ... please provide a sequence of operations that would be impossible
>> [if a depth 0 lock on a colllection is  inherited by newly created
internal members of that collection, as in 7.5]...
>
>LOCK /a/ is invoked, depth:0
>
>...Now the owner does a BIND to /a/c/ and adds a whole new
>tree below /a/.  

Oh now I get it.  You are thinking about the consequences for BIND.

But BIND is not  part of RFC 2518.  But my question was about the behavior
of plain old RFC 2518.  My intention is to try to finish a WebDAV testing
tool tdav.py that tests compliance and interoperability of WebDAV servers
according to RFC 2518, not according to the work of the advanced
collections group.  RFC 2518 is on its way to a Standard, but the advanced
collection work is not yet there.  it may be part of WebDAV someday, but it
is not, yet.

I have not proposed or argued against anything.  I am just trying to get a
clear  understanding  of  RFC 2518.

We all agree that a depth infinity lock on a collection is inherited by
newly created internal members.  The only point of disagreement is about a
depth zero lock.

I read 7.5 as saying that even a depth zero lock is inherited, because it
does not say "only depth infinity". You and others have asserted that this
is bad.  When I asked why, you said it causes problems for BIND.

But BIND is not in RFC 2518, so let me ask, just for clarity's sake, does
it cause problems for a server compliant with RFC 2518, but ignorant of BIND?

If so, what is it?

If not, then we can take up the problem with BIND, and see whether it
really is a problem, and if so, what to do about it.  it's perfectly fine
with me to rule out certain behaviors that might be lawful under plain old
RFC 2518  in order to leave room for future expansion.  But if that's the
reason, we should say so.

So can we clear up this question first, and then take on the question of
whether there's a problem for BIND?

With all best wishes

Jim

---

From: Greg Stein <[email-masked]>
Date: Fri, 26 Nov 1999 11:12:38 -0800 (PST)

On Fri, 26 Nov 1999, Jim Davis wrote:
>...

That's being a bit pedantic, don't you think? All right, so the RFC is
missing three words. Put them in and interpret it that way.

We know what the state of a Depth:0 lock on a collection is after one has
been applied (just the collection is locked), and we know the state after
a Depth:infinity has been applied (a bunch of stuff is locked). Your
"interpretation" would create situations that just don't match normal
behavior. With the simple insertion of three words, you get behavior that
matches for the PUT/MKCOL case and the LOCK case.

What I don't understand is how you could arrive at a reasonable
interpretation that the lock *should* be inherited. Could you explain?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Jim Davis <[email-masked]>
Date: Tue, 30 Nov 1999 02:10:26 +0100

>missing three words. Put them in and interpret it that way.

Uh, actually no I don't think it's being pedantic.  Could we please keep
the discussion to logic and pragmatics?  

I don't object off hand to making a change (in the next draft) but I would
like it to be noted as a *change* or at least a clarification in the
meaning.  It's possible that the authors actually had in mind that only
depth infinity locks would be inherited, but that is not what the spec
actually says.  maybe it's a typo, or maybe it's a bad design decision, but
neither you nor I are free to simply insert words that change the meaning
just because we don't like the behavior as specified.  The point of this
conversation, and the testing experience with WebDAV is to find places
where the spec is either a bad idea and should be changed, or is unclear.

Just to remind you, at the start of this thread someone (G Slein, J Amsden,
CC Jason or G Clemm,  sorry I am not sure who though)  asserted that if a
depth 0 lock was inherited, something bad would happen.  but  upon
challenge, no one has been able to say what that bad thing is.  All you
have said is that it's pedantic to interpret it that way.

Look, I quote 7.5

   If a lock owner causes the URI of a resource to be added as an
   internal member URI of a locked collection then the new resource MUST
   be automatically added to the lock.  This is the only mechanism that
   allows a resource to be added to a write lock.  Thus, for example, if
   the collection /a/b/ is write locked and the resource /c is moved to
   /a/b/c then resource /a/b/c will be added to the write lock.

It does not say "locked depth infinity" it just says "locked".

If the authors had meant to restrict this to apply only to infinite-depth
locked collection, they would have said so, no?

Or perhaps the difficulty lies in the term "added to the lock"?  I think
this may be the source of the confusion.  

This really isn't pedantry, honest.  I am not doing this just for the
pleasure of arguing.  I am doing this because i want a spec that's clear,
so that any implementor can read it and know what to expect. 

I suspect that you guys interpret "added to the lock" as meaning something
like "falling under the same protection as the other resources previously
protected by it", which is to say protected from DELETE (because that
changes the membership-state  of the parent collection) but not from a
(second) PUT.  I interpret it as meaning "locked in the same manner as the
original resource".  Thus when patent collection P is exclusive write
locked (at depth 0) with lock L and new resource R is added to that lock,
then there are now two resources that lock L applies to, P and R.  And just
as one can not change P's state without passing L's token, neither can one
change R.

If this is not the correct interpretation, then we should add language to
the spec to make this explicit.

Is any one else on this list paying any attention to this?  Or is it just
the five of us?

Hopefully we will soon straighten this out.

---

From: "David M. Chandler" <[email-masked]>
Date: Tue, 30 Nov 1999 00:02:42 -0800

> Is any one else on this list paying any attention to this?

Well, since you asked, yes, someone else is paying attention. For clarity, I
think 7.5 should specify a depth infinity lock if that is in fact what the
authors intended (I don't know whether that might be true). As far as the
"bad" behavior which might result when newly-added children inherit depth-0
locks, I propose the following scenario. Please forgive me if this is
obviously wrong. Suppose the following hierarchies of resources:

a/
a/b
a/b/d/
a/b/d/q
a/b/d/r

c/
c/j
c/k

Suppose a/b/ is write-locked depth 0. My understanding is that a/b/d and its
members are not locked at this point.

Now suppose we move collection /c with its members under /a/b, as in the
example of 7.5. Now we have

a/
a/b
a/b/c/
a/b/c/j
a/b/c/k
a/b/d/
a/b/d/q
a/b/d/r

If we interpret 7.5 to mean that the write-locks are inherited even for
depth 0, then /a/b/c becomes locked, but /a/b/d is not locked, which seems
inconsistent to me because the lock has developed memory--pre-existing
internal members are not locked, but newly-added ones are.

Furthermore, what about new members of /a/b/c? Wouldn't /a/b/c/x and
/a/b/c/y inherit the depth-0 write-lock from /a/b/c while /a/b/c/j and
/a/b/c/k remain unlocked? It's the same case, just another level down. I
think you could end up with a depth-0 lock locking some resources down to
depth infinity by virtue of the fact they were added after /a/b/ was locked.

Or I'm just completely lost, which is a real possibility.

>    be automatically added to the lock.  This is the only
>    mechanism that allows a resource to be added to a write lock.  Thus,
for
>    example, if the collection /a/b/ is write locked and the resource /c
>    is moved to /a/b/c then resource /a/b/c will be added to the write
lock.
> It does not say "locked depth infinity" it just says "locked".

David Chandler

---

From: "Geoffrey Clemm" <[email-masked]>
Date: Tue, 30 Nov 1999 13:26:50 -0500

From: Jim Davis <[email-masked]>
> challenge, no one has been able to say what that bad thing is.

See <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0245.html>
In particular, this message says:

I lock a collection, because I'm going to be adding members
to that collection.  If a depth:0 lock applies to all the
immediate members of a collection as well, then I have prevented
anyone from updating the state of one of the existing internal members of
that collection.  If I'd wanted that behavior, I would have issued a
depth:1 lock.  And quoting from the definition of what depth means:

   The Depth header is used with methods executed on resources which
   could potentially have internal members to indicate whether the
   method is to be applied only to the resource ("Depth: 0"), to the
   resource and its immediate children, ("Depth: 1"), or the resource
   and all its progeny ("Depth: infinity").

Cheers,
Geoff