Fwd: [Bug 2] Bindings needs to completely describe how bindings interact with locks.

By the way, I agree with this wording.  I would be even happier if it 
also required the server to allow LOCK on any binding to refresh the 
lock already existing.  Can we add that?

The title of the bug is general ("Bindings needs to completely describe 
how bindings interact with locks.") because when I entered it, I could 
see some undefined interactions and suspected there might be more.  At 
this point, I am not aware of any more undefined interactions, so if we 
satisfy the interaction between LOCK/UNLOCK and multiple bindings, I 
suggest we close the bug.  We can also make the bug title more specific 
so that if somebody comes up with a new undefined interaction between 
locking and bindings we'd encourage them to open a new bug.

Lisa

Begin forwarded message:

> From: bugzilla@soe.ucsc.edu
> Date: January 18, 2005 11:35:08 PM PST
> To: lisa@osafoundation.org
> Subject: [Bug 2] Bindings needs to completely describe how bindings 
> interact with locks.
>
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
>
>
>
>
>
> ------- Additional Comments From julian.reschke@greenbytes.de  
> 2005-01-18 23:35 -------
> Suggested additional text bei Joe Hildebrand, Chuck Fay and Julian 
> Reschke:
>
> 2.x UNLOCK and Bindings
>
> 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 particular binding expressed by the Request-URI, rather than the
> resource identified by that 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.
>
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

Received on Friday, 28 January 2005 00:07:02 UTC