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