Re: Remaining issues with the bind draft -- process

Hi Antony,

Thanks for speaking up!  It's folks that aren't part of the
design team whose feedback on this point is most valuable.

I agree that comprehensibility is more important than
axiomatic minimality, but we do try to avoid duplicating
normative information from other specs, to avoid confusion
when those other specs are revised.

Were there specific parts about the BIND spec that you felt
merited/required additional explanation?

Thanks,
Geoff


Antony wrote on 04/05/2004 10:03:33 PM:

> 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 23:23:22 UTC