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

Hi Neal,

It's great to have someone other than usual culprits (:-) contribute
to the discussion!

Although the 2518 does not provide a standard method for mapping a
resource to more than one URL, it does explicitly state that in the
WebDAV model, multiple URLs may identify the same resource.
In particular, section 5.1 of RFC2518 states:

"Although implicit in [RFC2068] and [RFC2396], any resource, including
 collection resources, MAY be identified by more than one URI. For 
example,
 a resource could be identified by multiple HTTP URLs."

So since having multiple URLs identify the same resource is part of
the 2518 model, how locks behave when multiple URLs identify the same
resource must be defined by the locking model for 2518.

On the other hand, the BIND specification must specify the locking 
semantics of anything new that it introduces, which is the BIND, REBIND,
and UNBIND methods.  And the locking behavior of those methods is
defined in the BIND specification.

Cheers,
Geoff



Neal wrote on 01/13/2005 09:35:33 PM:

> 
> 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.
> >  > 
> >  > 
> >
>