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

From: Jim Davis <[email-masked]>
Date: Tue, 30 Nov 1999 22:59:16 +0100

At 12:02 AM 11/30/99 -0800, David M. Chandler wrote:

>
>... As far as the
>"bad" behavior which might result when newly-added children inherit depth-0
>locks, I propose the following scenario. 

Your scenario is exactly right, that is, it makes all the right predictions.

So the claim is that it would be confusing if WebDAV acted this way...
you'd have a tree of resources, only some of which were locked, and whose
lockedness depended on the history.

In fact I agree, it seems confusing to me too.  It's a good argument for
changing the spec.

---

From: Jim Davis <[email-masked]>
Date: Tue, 30 Nov 1999 23:33:39 +0100

At 01:26 PM 11/30/99 -0500, Geoffrey Clemm wrote:
>From: Jim Davis <[email-masked]>

>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. 

Thanks for tracking down the quotation (I can't search the email archive
right now)   but that message responds to a strawman.  I never said "a
depth:0 lock applies to all the immediate members of a collection".
(indeed, that's what a depth infinity lock does).   I was asking about a
depth 0 lock being inherited by *newly created* members of the collection.

So let me ask again.

If I lock collection a/ with depth 0, then do a PUT to a/b.html (which did
not prev exist), and a/b.html is added to the lock, what bad thing then
happens, or what good thing is prevented?
Does something bad happen if the PUT is instead a MKCOL, or COPY/MOVE, or a
LOCK?

Note that I have seen David Chandler's reply.  Do you have anything to add
other than his example?

Also, if you have any comments on the very end of my last email (where I
asked whether the problem was the definition of "added to the lock") that
might help.

best wishes

Jim

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 1 Dec 1999 13:48:23 -0800

Jim Davis writes:
> 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.

Sorry I didn't read this thread sooner...

The original intent was to have the inheritance behavior only apply to Depth
infinity locked collections, not to Depth 0 locked collections.  Since
section 7.5 does not explicitly state a "depth infinity locked collection",
but only states a "lcoked collection", the section is ambiguous, and should
be clarified in a future revision of RFC 2518.  I've added this to the
issues list, available at:

http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

- Jim

---

From: Jim Davis <[email-masked]>
Date: Thu, 02 Dec 1999 14:38:31 +0100

>issues list, available at:

Okay, that resolves that.

I've modified tdav.py to reflect the intended behavior, and now I can
confirm that the server at Sharemation is (so far as I can tell) in full
compliance with RFC 2518.