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

I agree with everything Julian says here, including the fact that RFC-2518
answers both of these questions.  When I said that "there is an issue to 
be
resolved", I was referring to a suggestion that RFC-2518bis change the 
semantics
of RFC-2518 to require that an UNLOCK be applied to the request-URL of the
original LOCK request, but my understanding is that the most recent 
consensus
is that RFC-2518bis not make this change, and stay consistent with 
RFC-2518
and allow an UNLOCK request to be applied to any resource locked by the 
lock.
Thus one of the two questions that Lisa states should be answered by the
BIND spec is an issue being explicitly discussed in the context of 
RFC-2518, 
which illustrates why these issues need to be handled by RFC-2518bis (or 
preferably,
by a separate specification that is devoted to locking).

Cheers,
Geoff

Julian wrote on 01/14/2005 04:15:08 AM:

> 
> Lisa Dusseault wrote:
> > 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.
> 
> Lisa,
> 
> it would be helpful if you would indeed *read* my replies. See 
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>..:
> 
> "General statement: it's not the BIND spec's job to resolve open issues 
> with RFC2518's defintion of locking. RFC2518 explicitly allows multiple 
> URIs to be mapped to the same resource (see for instance section 5.1), 
> thus if there's some doubt about lock semantics, it needs to be 
> clarified in RFC2518bis.
> 
> That being said, both questions can be answered by looking in RFC2518:
> 
> - the value of the DAV:lockdiscovery property will be the same, as both 
> bindings refer to the same resource, and the lock is on the resource 
> (RFC2518, section 13.8)
> 
> - UNLOCK removes the lock identified by the lock token from the resource
> identified by the request-URI (and all other resources included in the 
> lock), so again, it doesn't matter to which binding the UNLOCK is 
> applied (section 8.11)"
> 
> So I *both* answered the actual questions *and* explained how it is 
> indeed specified through RFC2518 and BIND. So in order to have a 
> constructive discussion, you'd need to challenge these statements.
> 
> > 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.
> 
> I don't know what you're talking about. Where is the URI supposed to 
> appear inside the DAV:lockdiscovery element at all? We're talking about 
> RFC2518 + BIND, not RFC2518bis, right? (see 
> <http://greenbytes.de/tech/webdav/rfc2518.html#PROPERTY_lockdiscovery>)
> 
> > Some clients will associate only one URL with each locktoken and be 
> > confused if the same locktoken appears on some other URL.   Some 
clients 
> 
> Then they are buggy according to RFC2518 
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>). 
> Can you name a client that has this problem?
> 
> > 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 
> 
> They can.
> 
> > 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.
> 
> Nobody argues with that. Can we please get back to the question *what* 
> you think is underspecified?
> 
> Finally, a general note on "what to UNLOCK". A properly written client 
> will apply UNLOCK to the URI where it originally applied the LOCK 
> request to. It's supposed to keep this information anyway.
> 
> Questions about what to UNLOCK in case of "lock stealing" (removing a 
> lock created by a different client (instance)) are interesting but 
> really about an edge case that should not occur during normal operation. 

>   It's fine to discuss this in the context of RFC2518bis (DAV:lockroot 
> child element, for instance), but this has nothing to do whatsover with 
> BIND.
> 
> Best regards, Julian
> 
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>