[rfc-i] ABNF (RFC2234)
blilly at erols.com
Mon Feb 21 17:11:55 PST 2005
> Date: 2005-02-18 17:22
> From: Dave Crocker <dhc2 at dcrocker.net>
> On Thu, 17 Feb 2005 17:34:06 -0800, Bill Fenner wrote:
> > > OK -- what's the planned resolution of the multi-line <prose>
> > >
> > > discrepancy?
> > >
> > The plan is that multi-line <prose> will continue to be illegal.
> to underscore Bill's response:
Somebody (one of 2234's authors) should probably instruct the RFC Editor
to elide the "erratum" which purports to change the technical content of
> moving a specification to Draft Standard is supposed to include no significant technical changes. making significant technical changes renders a specification unstable, in the sense that it removes the experience base that is used to justify advancement to Draft.
> there are a substantial number of "enhancements" that different folk would like to make to ABNF. Generally I think they are reasonable ideas.
> 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. If the ideas are indeed reasonable, then
incorporating them at a later date (after advancement to Draft w/o the
changes) will still require resetting to Proposed (as I understand the
rules), resulting in a longer path to full Standard. It might be
worthwhile discussing specific suggested changes. In light of RFC
3967, it could be argued that a delay in advancement to Draft need not
delay use by other documents that are intended to advance to Draft.
On another note, some of the ABNF provisions make little sense:
repetition = [repeat] element
repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
element = rulename / group / option /
char-val / num-val / prose-val
option = "[" *c-wsp alternation *c-wsp "]"
permits constructs such as:
*[foo] ; equivalent to *foo
3*[foo] ; equivalent to *foo
*5[foo] ; equivalent to *5foo
3*5[foo] ; equivalent to *5foo
and of course it is worth remembering that
is equivalent to
as noted in RFC 2234 section 3.8.
That is, the combination of repeat and option is never necessary; any
such combination can always be expressed as repeat w/o option or v/v.
I suspect that many of the above combinations of repeat with option
may be a potent source of confusion (because any DIGITs before the
asterisk are completely meaningless. Such confusion could be avoided
by the following revisions:
repetition = [repeat] element / option
element = rulename / group / char-val /
num-val / prose-val
More information about the rfc-interest