- From: Brian Smith <brian@briansmith.org>
- Date: Sun, 17 May 2009 18:40:28 -0500
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
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