W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2004

locking clarifications/extensions vs BIND draft vs RFC2518bis

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 14 Jan 2004 15:03:33 +0100
Message-ID: <40054C35.1080902@gmx.de>
To: w3c-dist-auth@w3.org

Hi,

I've been thinking about the best way to get the BIND spec out without 
neglecting the fact that the interaction between locks and multiple 
bindings could use a clarification :-)

Several approaches come to mind...:

1) Add a section to the BIND spec. From a procedural point of view that 
would be easiest, but it would IMHO be short-sighted. The aforementioned 
clarification should be independant of the BIND spec, and in particular 
needs to be compatible to whatever RFC2518bis will say when it's finished.

2) Come up with a separate spec that updates RFC2518 and just summarizes 
all that we changed or intend to change regarding locking (like 
deprecation of lock-null resources, fixes to LOCK and lock refresh, If 
header syntax, and lockdiscovery extensions). That would still be a 
"draft standard" as RFC2518, but it would make things easier for 
RFC2518bis as well, because all these changes would be written down in a 
spec that came out prior to the revision, so wouldn't be "new" anymore. 
It would also encourage implementors to actually *implement* these 
changes and extensions *before* RFC2518bis comes out.

3) A drastic approach would be to de-couple locking entirely from 
RFC2518 ("updating" RFC2518 again). That would look similar to how 
RFC3253 is organized (locking would become an optional module, and 
everything that needs to be said about locking would reside in that 
separate document). Of course that approach would have a significant 
impact on RFC2518bis, because optimally, it wouldn't say anything about 
locking anymore either.

 From a purely technical point of view, choice 3) has a lot of appeal. 
Separating the specs should make both more accessible, the base spec 
would be MUCH simpler, and both specs would be easier to update. Also, 
getting people to implement basic WebDAV minus locking may be a lot 
easier if it's decoupled. Of course, that's also the option that would 
cause the biggest amount of editorial work...

On the other hand, I'd understand if people think that we shouldn't mess 
around too much with both RFC2518 and RFC2518bis. In that case, I see 
option 2) as a workable alternative. Of course, that approach only makes 
sense if we can make that activity an official WebDAV working group work 
item.

Feedback appreciated,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 14 January 2004 09:05:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC