Re: Remaining issues with the bind draft -- process

I strongly support choice #3 (issuing a locking draft).

If we are considering defining locking behavior in a 
separate draft that isn't about locking (i.e. the bind draft),
then I think doing so in a separate draft makes the most sense.

Especially if Julian has done most of the editorial work
(thanks, Julian!), we should be able to focus on it after
the binding draft is finalized, and get it out soon afterwards
(once it is decoupled from the many unresolved issues in
the rest of 2518bis).

Cheers,
Geoff

Julian wrote on 04/05/2004 06:13:27 PM:

> 
> 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 22:58:50 UTC