- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 14 Jan 2004 15:03:33 +0100
- 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