Re: Remaining issues with the bind draft -- process

I'm a (lurking) WebDAV implementer, and I'm waiting for BIND. I think 
it's bizarre to propose publishing BIND when understanding it depends 
on RFC2518bis, that has an indeterminate publish schedule and may never 
happen. IMO the only thing that makes sense is to publish locking 
separately, and only then publish BIND. I've been hoping this would 
happen ever since I saw GULP, so for what it's worth, I request 
Julian's point 3.

As an aside, I think the BIND spec should err on the side of ease of 
comprehension, rather than being axiomatically minimal. I think the 
process of writing such explanatory content is more likely to bring to 
light misunderstandings that illustrate ambiguity or incomplete 
coverage. Developing such non-normative explanatory content is a 
time-honoured and very effective mechanism to avoid that.

Just my $0.02

On 06/04/2004, at 7:43 AM, Julian Reschke wrote:

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

Antony Blakey
-------------
Some defeats are installments to victory.
   --Jacob Riis

Received on Monday, 5 April 2004 22:08:56 UTC