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

Re: Remaining issues with the bind draft -- process

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 06 Apr 2004 00:13:27 +0200
Message-ID: <4071DA07.1040501@gmx.de>
To: Ted Hardie <hardie@qualcomm.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Lisa Dusseault <lisa@xythos.com>, Patrik Fältström <paf@cisco.com>, Webdav WG <w3c-dist-auth@w3c.org>

Ted Hardie wrote:

> Speaking personally, my concern here would be that if those 
> clarifications were not
> present, BIND behavior became non-deterministic.  If 2518bis was done, and
> BIND pointed to it to solve that hypothetical problem, all might be 
> goodness; if
> it will not be done, on the other hand, getting the job done in the spec 
> which
> will be completed might be the practical way to go.
> 
> Again, my personal two cents,
>             regards,
>                 Ted

If we rephrase that as "There should be a standards-track document 
clarifying WebDAV looking as soon as possible.", I'll absolutely agree. 
However, I think that document shouldn't be BIND, if only for the simple 
reason that it matters to those who don't plan to implement BIND at all 
as well.

If we can't get RFC2518bis finished soon, I think the approaches (2) and 
(3) presented in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html> 
would make more sense:

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

I'm willing to help working on either; we just need working group 
consensus to do this as it would affect the (currently dormant?) 
activities on RFC2518bis.

As an experiment, I've already extracted locking from RFC2518. This 
turned out to be relatively simple *except* for the locking semantics 
built into the "If" header checks (which will require some more 
thinking). BTW: RFC2518 shrinks by about 30% (interested parties just 
email me for a copy).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 5 April 2004 18:14:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT