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

Lisa Dusseault wrote:
> 
> Does this mean that we agree that some specification must describe  
> binding/locking interaction?  As long as some document says something  

Yes. I think we only disagree about which spec, and whether the current 
language in RFC2518 is sufficient for now (which I think).

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

But that's what RFC2518 already says 
(<http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>):

"The UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the Request-URI, and all other resources 
included in the lock. If all resources which have been locked under the 
submitted lock token can not be unlocked then the UNLOCK request MUST fail."

Also note that this has an entry on RFC2518's official issue list 
(<http://www.webdav.org/wg/rfcdev/issues.htm, entry 65) which says:

"Resolved that you can specify any URL locked by the lock you want to 
unlock. 
(http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html )"

So it's even on the IETF-registered errata list (as "resolved"). Why 
would a new only indirecty related spec need to duplicate that information?

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

Drawbacks:

- makes the spec more complex
- adds normative language about a feature which is *completely* 
orthogonal to BIND
- risks conflicting specification in RFC2518bis

> 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  

Yes, but again, the language in RFC2518 is absolutely sufficient here. 
We're not talking about an IETF document going to "Full Standard", we're 
talking about "Proposed".

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

In particular, we write the spec in a way that bindings fit well into 
the model established by HTTP and WebDAV, and thus *don't need* to 
specify their particular interaction with some optional (!) WebDAV features.

> 3) RFC2518bis should say it.  Well that's not an RFC yet, so this is  

Speaking of which, what is it's status?

> 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  

It wouldn't be able, but it doesn't, so this isn't an issue.

> Bindings behind a draft to revise WebDAV?  It's not necessary.  Why  
> would you want to create this dependency?

Nobody has suggested that (as far as I can tell).

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

Doesn't seem to be different from 1, except that it's an additional 
document.

BTW: you forgot to mention option #5, which is to split out locking from 
RFC2518bis and try to get that published as "Proposed Standard" ASAP. 
Most of the work has already been done in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>.


Best regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 14 January 2005 17:58:50 UTC