RE: Collected ABNF for HTTPbis

Julian Reschke wrote:
> Working around the two latter issues, we can generate
> <http://greenbytes.de/tech/webdav/httpbis.abnf> which I'll keep
> up-to-date from now, for those who want to play around with it
> (feedback appreciated).

The collected ABNF is something that is best published separately, probably
by somebody other than the IETF. Generating the collected ABNF is useful for
its diagnostic checks, as you noted. But, it shouldn't be published as part
of the specification.

Many other IETF specifications do not publish a collected ABNF. In fact,
very few seem to do so. SMTP and IMAP are two examples of specifications
analogous to HTTP that don't provide the collected ABNF.

As Julian said before, the collected ABNF exists in order to desugar the
"#X" ABNF extension into true ABNF syntax. AFAICT, that isn't necessary
since ABNF processing tools seem to handle the extension anyway. But, also,
the "#X" extension is really a huge readability advantage. Every usage of
"#X" is easily replaced with X (COMMA-ows X)* where COMMA-ows is just "OWS
COMMA OWS". That doesn't justify the extra complication. Just desugar all
the inline productions, remove the #X extension, remove the collected ABNF.

Obviously, the collected ABNF is redundant with the rest of the
specification. When there is such redundancy, it is important to make it
clear how to resolve differences that arise from the redundancy. My recent
suggestions for cutting text out of the spec. have all been aimed at solving
this problem by removing redundancy. If the inline grammar is normative and
the collected ABNF is normative, then readers are forced to either trust
that they are in sync and/or double-check that they are in sync. If for some
reason the collected ABNF doesn't match the inline grammar then there will
be much confusion about which one to use. It is much easier on the reader to
explicitly say the collected ABNF is non-normative to avoid the issue. The
issue can be avoided altogether by removing the collected ABNF from the
specification.

It doesn't make sense to create a collected ABNF and then split it into
multiple parts like it is in the current drafts. Yet, collecting it in that
goes against the reasons for splitting the specification into multiple parts
in the first place. Not only that, but it would be a lot more useful to
implementers if it included the grammar productions from other
specifications that are currently included by reference (from RFC3986,
RFC1864, RFC4647, RFC5322). At the same time, the HTTP specification should
not duplicate those other specifications' extensive grammar productions. 

The final issue is the one I mentioned before: The collected ABNF would be
much easier to use directly if it was published without the IETF
boilerplate. I checked into this and it seems like there's no accepted
process for including such plain-text attachments in the official version of
IETF specifications.

Anybody can already use the same tool the editors are using to generate the
collected ABNF from the inline grammar. AFAICT, anybody can then publish
this "true" collected ABNF as a plain-text file. And, they can publish the
grammar in whatever format is most usable for then: ABNF syntax, Flex/Bison
syntax, etc.

Regards,
Brian

Received on Sunday, 17 May 2009 23:41:17 UTC