RE: are depth 0 locks inherited by newly created children?

How do I unsubscribe?

-----Original Message-----
From: Jim Davis [mailto:jrd3@alum.mit.edu]
Sent: Monday, November 29, 1999 5:10 PM
To: w3c-dist-auth@w3.org
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:
>>...
>> 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.
>
>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.

Received on Tuesday, 30 November 1999 13:00:46 UTC