- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Tue, 20 Dec 2005 10:12:18 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>, Cullen Jennings <fluffy@cisco.com>
On Dec 20, 2005, at 1:06 AM, Julian Reschke wrote: > Cullen Jennings wrote: > >> Now Lisa proposed a model for locking slightly different than GULP >> which >> would, by my understanding, would allow an implementation like GULP >> but >> would also allow implementation like the one I just described to also >> be >> compliant. For a server that supported BIND, it would probably have >> to be a >> GULP like implementation. > > I'll assume you're referring to > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/ > 1282.html>? > > Which reads: > > LD> One could imagine the lock applying to the resource and to all its > LD> bindings, considering the bindings to be part of the state of the > LD> resource. If I recall, I think this is the model I'd always > assumed > LD> until GULP. With this model, if A and B are bindings to a > resource, > LD> and a LOCK token to A is successful, then for the duration of the > lock > LD> the token is required to change either A or B. > > This implies that a binding is part of the state of the resource, and > I think both RFC2518 and RFC3744 are very clear that it's not. Namely, > in <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>: No, that's not a correct conclusion. This model only implies that all bindings are covered by the LOCK as well as the resource itself. The resource state is still the resource state and that doesn't include *any* bindings. It's actually very similar to the model proposed in GULP. In that model, the LOCK covers one binding as well as the resource. The GULP model does not imply that the locked binding is part of the state of the resource either. What a lock covers is a separate concept from what a resource state includes. Lisa
Received on Tuesday, 20 December 2005 18:12:38 UTC