W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

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

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 1 Dec 1999 13:48:23 -0800
To: Jim Davis <jrd3@alum.mit.edu>, w3c-dist-auth@w3.org
Message-ID: <NDBBIKLAGLCOPGKGADOJKELOCJAA.ejw@ics.uci.edu>

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
Received on Wednesday, 1 December 1999 16:50:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:52 GMT