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

Lisa, you say the same thing every time, and we give the same
response every time (:-).  Locking behavior for RFC2518 features
(multiple URLs mapped to the same resource) needs to be defined by the
locking specification, not by the BIND specification.  Otherwise,
there will be mass confusion when the locking specification says
one thing and the BIND specification says something else.
The question of whether or you can apply UNLOCK to a locked resource
using a URL other than the one the LOCK was applied to is an open
question for the locking specification, and the BIND protocol
is not the place to resolve that open locking question (the same question
applies to depth locks, which have nothing remotely to do with the
BIND protocol).

OK, Joe, here's our first test of the "rough consensus" mechanism (:-).

Cheers,
Geoff


Lisa wrote on 01/13/2005 07:01:41 PM:

> 
> I keep re-opening this issue because the spec still doesn't say what 
> the server MUST do or what the client must be prepared to handle.  I 
> don't care how you answer it on the list or in bugzilla; I am not even 
> arguing for any specific answer.  I am arguing for some *specification* 
> here.
> 
> These answers may follow from RFC2518 in your interpretation, but there 
> have been and will be other interpretations.  Without clear guidance, 
> some clients will assume that the URL that they query (the target of 
> PROPFIND) is the one that MUST appear in the lockdiscovery property for 
> that URL, and that if another URL appears the server must be broken. 
> Some clients will associate only one URL with each locktoken and be 
> confused if the same locktoken appears on some other URL.   Some 
> clients will assume that if a URL that they query is locked (and they 
> have the lock token, etc) they can UNLOCK the same URL.   If server 
> implementors aren't forced to make compatible choices, then we will 
> have interoperability problems surrounding bindings.  We have 
> specifications not just so we can explain the model, but also to make 
> requirements of implementors.
> 
> Lisa
> 
> On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote:
> 
> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
> >
> >
> >
> >
> >
> > ------- Additional Comments From julian.reschke@greenbytes.de 
> > 2005-01-13 15:44 -------
> > I'm not sure why you keep re-opening this issue. Your particular 
> > questions
> > answered in 
> > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>, and
> > these answers follow from what RFC2518 already says.
> >
> >
> >
> > ------- You are receiving this mail because: -------
> > You reported the bug, or are watching the reporter.
> 
>