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

Does this mean that we agree that some specification must describe  
binding/locking interaction?  As long as some document says something  
like "The server MUST allow UNLOCK to work on any binding to a locked  
resource, given an otherwise well-formed and permissioned request"  
(some standards-track document, not an email list or bug db), the  
requirements for interoperability have minimally been met.

Now let's discuss which specification should say these kinds of things.

1) Bindings spec should say it.  This works great -- it's a small  
clarification to add to a document which already describes bindings,  
and since it depends on RFC2518 it's perfectly easy to add text to  
describe how bindings works with the features described in RFC2518.   
Then Bindings can go to RFC, depending only on other RFCs.  Easy, done.

2)  RFC2518 should say it.  Oops, too late.  As you point out, RFC2518  
didn't fully specify bindings -- it only described that they might  
exist.  As did RFC2616.  This is pretty typical, similar to the way  
variants are described as being possible in RFC2616 but it doesn't  
fully describe how they work (e.g. with PUT).  Without a full  
specification, such a feature (bindings without the Bindings draft, and  
variants today) is not fully interoperable -- bindings and variants may  
exist, but servers may handle them differently, and clients have no  
reliable way of authoring them.  That's why we write a bindings spec,  
to fully specify how bindings work.

3) RFC2518bis should say it.  Well that's not an RFC yet, so this is  
problematic.  How can the Bindings draft go to RFC if it depends on  
something that's still a draft?  And why would you *want* to block  
Bindings behind a draft to revise WebDAV?  It's not necessary.  Why  
would you want to create this dependency?

4) Write some other document on "Interactions between Bindings and  
Locking".  This would be a companion to both the bindings specification  
and the locking specification but separate from both.  If implementors  
remember to consult this, it's a fine place to put information which  
discusses the interaction between two features.   Now Bindings has a  
dependency on another Internet-Draft, but this is a small one and  
should be easy to progress.


On Jan 14, 2005, at 4:40 AM, Geoffrey M Clemm wrote:

> 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
>> <>..:
>> "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
>> < 
>> 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
>> (<>).
>> 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 -- -- tel:+492512807760

Received on Friday, 14 January 2005 17:38:18 UTC