[rfc-i] ABNF (RFC2234)

[Bruce Lilly]

>  From: Dave Crocker <dhc2 at dcrocker.net>

> > >  The question is whether there is strong pressure from the community to
> > >  re-cycle ABNF at Proposed, in order to include these enhancements. Â Or
> > >  would the community prefer to have ABNF advance to Draft, so that it
> > >  can be cited by various other specifications that are advancing to
> > >  Draft.
> > >
> > >  I've been seeing overwhelming desire for the latter, rather than the
> > >  former.
> > >
> >  It's often a difficult call.  
> 
> So far, no it's not.  That's why I said "overwhelming".

You may have missed two crucial points:
1. incorporating "reasonable" "enhancements" at a later date results
   in a longer overall process (2 cycles between Proposed and Draft)
   than resolving those issues while still at Proposed.
2. the premise regarding citation is not valid (see RFC 3967 section
   3).

> One of the biggest dangers to any standards effort (or any development project) is the legitimate desire to make it better.  Delay kills real-world utility.

It is important to distinguish several categories that can "make it better":
1. functional changes resulting from substantive additions ("feature bloat")
2. functional change due to featurecide
3. editorial changes to improve clarity / reduce ambiguity
4. technical changes to correct errors.

Feature bloat is a potential problem.  The others noted above make the
specification more useful without adding bloat.
 
> >  On another note, some of the ABNF provisions make little sense:
> 
> Given the long history of using abnf, and the lengthy discussions that produced the current rfc, 'make little sense' is not likely to be a general-purpose assessment.

Substitute "are harmful" for "make little sense"; the specific issue
results in confusing specifications, which in turn may lead to
interoperability problems.  The specific suggested change would be
a case of featurecide for a confusing feature which (as far as I
know) has not been used.

Category 3 is another matter, it will have to wait for a future
message.

We've already discussed some issues in category 4 (e.g. CRLF).