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

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