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

I don't see how the locking specification (2518) can possibly say
anything about this, as there is no way without the bind spec of
getting more than one URL to the same resource.

On Thu, 13 Jan 2005 21:16:10 -0500, Geoffrey M Clemm
<geoffrey.clemm@us.ibm.com> wrote:
>  
> 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.
>  > 
>  > 
>

Received on Friday, 14 January 2005 02:36:04 UTC