Re: [Bug 2] Bindings needs to completely describe how bindings in teract with locks.

I agree that it would be desireable to add the statement Joe suggests
to the binding specification, and I like the editorial changes suggested
by Chuck and Julian.

Cheers,
Geoff

Julian wrote on 01/14/2005 03:52:35 PM:

> 
> Fay, Chuck wrote:
> > I like Joe's suggestion, but I would word it differently, because part
> > of 2518's description of UNLOCK is flawed and misleading.  Note that 
it
> > says "The UNLOCK method removes the lock... from the Request-URI", not
> > from the *resource* identified by the Request-URI.  It is clearly 
stated
> > elsewhere in 2518 that "locks apply to resources, not URIs," and the
> > sentence on UNLOCK goes on to talk about "all other resources included
> > in the lock."  So the sentence is internally inconsistent.  If one
> > relied just on this misleading portion of the description of UNLOCK 
from
> > 2518, one could mistakenly conclude that locks are on URIs, not
> > resources, and hence an UNLOCK on a URI other than the one used in the
> > original LOCK operation would fail.  I think this is at the heart of
> > Lisa's concern.
> > 
> > So I would rework Joe's suggestion this way, so that it doesn't rely 
on
> > the flawed definition of UNLOCK:
> > 
> > <blockquote>
> >    It might be thought that an UNLOCK request to a locked resource
> >    would unlock just the binding of the Request-URI.  This is not
> >    the case, however. [RFC2518] clearly states that locks are on
> >    resources, not URIs, so the server MUST allow UNLOCK to be used
> >    to unlock a locked resource through any binding to that resource,
> >    given an otherwise well-formed and permissioned request.  The
> >    authors of this specification anticipate and recommend that future
> >    revisions of [RFC2518] maintain this behavior.
> > </blockquote>
> 
> I like this better, as it actually attempts to give a reason *why* 
> somebody would think that. Thinking of it, the language could be even 
> more precise here. I'd also prefer to lose the part about "given an 
> otherwise well-formed and permissioned request" because that IMHO is 
> just fluff and distracting (of course a LOCK will fail when there's 
> something else wrong with the request or the state of the resource).
> 
> Proposal:
> 
> "Due to the specific language used in section 8.11 of [RFC2518], it 
> might be thought that an UNLOCK request to a locked resource would 
> unlock just the binding of the Request-URI.  This is not the case, 
> however.  Section 6 of [RFC2518] clearly states that locks are on 
> resources, not URIs, so the server MUST allow UNLOCK to be used
> to unlock a locked resource through any binding to that resource.  The
> authors of this specification anticipate and recommend that future
> revisions of [RFC2518] maintain this behavior."
> 
> Best regards, Julian
> 
> PS: great to see you back on the mailing list, Chuck.
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>