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

From: [email-masked]
Date: Fri, 26 Nov 1999 15:06:02 -0500

Just noticed this note from you.  You pointed out that you are talking
about the pre-AdvColl behavior  In light of this, please add the following
to my previous note...

Although this note uses the term "binding", what I'm saying is not
contingent on the Adv.Coll. spec.  BINDING is just an unambiguous term that
I am using to distinguish the child resource from the parent's connection
to it.

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

---

From: [email-masked]
Date: Mon, 29 Nov 1999 09:47:44 -0500

<jim davis>
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.
</jim davis>
<jra>
I think this is assuming too much from missing information. I do not draw
this conclusion given the inheritance of depth locks on existing resources.
Locking a collection with depth:0 does not lock any of the members of the
collection. So why would adding a new member inherit the lock?
</jra>

---

From: Michael Hamilton <[email-masked]>
Date: Tue, 30 Nov 1999 09:57:41 -0800

How do I unsubscribe?

-----Original Message-----
From: Jim Davis [mailto:[email-masked]]
Sent: Monday, November 29, 1999 5:10 PM
To: [email-masked]
Subject: Re: are depth 0 locks inherited by newly created children?

At 11:12 AM 11/26/99 -0800, Greg Stein wrote:
>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.

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: [email-masked]
Date: Tue, 30 Nov 1999 17:44:04 EST

Yes, I've been following this analysis too, and I concur that depth 0 locks
stay on the resource, period.  There should be no weird crossovers from
depth:0 to depth:1 just because the resource is a collection.

[I am afraid to ask what the implications are for creating a locked-null
resource as an immediate child, but if it is a problem, I think the defect
is in lock-null.]

-- Dennis

------------------
Dennis E. Hamilton
InfoNuovo
mailto:[email-masked]
tel. +1-206-779-9430 (gsm)
fax. +1-425-793-0283
http://www.infonuovo.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Geoffrey Clemm
Sent: Tuesday, November 30, 1999 10:27
To: [email-masked]
Subject: Re: are depth 0 locks inherited by newly created children?

[ ... ]

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