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

At 09:31 AM 11/24/99 -0500, 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 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


Received on Thursday, 25 November 1999 19:05:08 UTC