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 
resolved", I was referring to a suggestion that RFC-2518bis change the 
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 
is that RFC-2518bis not make this change, and stay consistent with 
and allow an UNLOCK request to be applied to any resource locked by the 
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 
which illustrates why these issues need to be handled by RFC-2518bis (or 
by a separate specification that is devoted to locking).


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 
> > 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 
> > for any specific answer.  I am arguing for some *specification* here.
> Lisa,
> it would be helpful if you would indeed *read* my replies. See 
> <>..:
> "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 
> > 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 
> > 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 
> <>)
> > Some clients will associate only one URL with each locktoken and be 
> > confused if the same locktoken appears on some other URL.   Some 
> Then they are buggy according to RFC2518 
> (<>). 
> 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 
> They can.
> > aren't forced to make compatible choices, then we will have 
> > interoperability problems surrounding bindings.  We have 
> > 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 
> Best regards, Julian
> -- 
> <green/>bytes GmbH -- -- tel:+492512807760

Received on Friday, 14 January 2005 12:41:10 UTC