- From: Geoffrey Clemm <geoffrey.clemm@Rational.Com>
- Date: Sun, 28 Nov 1999 13:40:36 -0500
- To: <w3c-dist-auth@w3.org>
I agree with everything Greg says in this message. ----- Original Message ----- From: Greg Stein <gstein@lyra.org> > On Fri, 26 Nov 1999, Jim Davis wrote: > >... > > If I lock a collection with depth infinity lock, then create a new > > interrnal member of that collection (e.g. with PUT) I have to provide the > > lock token to do the PUT, and the new internal member is added to the lock. > > > > We all agree on this, right? > > Yes. > > > Now suppose the lock were depth 0 not depth infinity. > > > > 1) to add a new internal member, I still have to provide the lock > > token, right? > > Right. > > > 2) Previously exising members are not affected. I can PUT or PROPPATCH to > > them at my whim, right? > > Right. > > > 3) However, I can't DELETE them without the lock token, right? > > Right. You must supply the locktoken because you are altering the > collection (on the theory that the set of names of internal members is > part of its state). > > > So where we seem to disagree is: > > > > If I add a new internal member, is it added to the lock, or not? > > It is not. > > > I interpret 7.5 as saying Yes. You seem to think that the answer is, or > > should be, no. > > > > Can you please explain this? I don't see how this depth 0 lock would > > prevent anyone from updating the state of existing members. > > The depth:0 lock does not prevent people from updating existing members. > It prevents you from altering the collections state: the set of names of > internal members. Therefore, you cannot add or remove internal members. > This means you must supply a locktoken with PUT, MKCOL, or a DELETE. Note > that you shouldn't be able to create a locknull resource either(!) without > supplying a locktoken. >
Received on Monday, 29 November 1999 11:10:54 UTC