Re: Issue 163, was: Meaning of invalid but well-formed dates

Brian Smith wrote:
> Martin J. Dürst wrote:
>> Martin J. Dürst wrote:
>>> That seems to be backward. Wouldn't the comments be helpful in the
>>> collected ABNF, too?
>> The collected ABNF is produced by an ABNF parser (Bill Fenner's), by
>> serializing the rule objects it generates. Thus, it doesn't have the
>> comments anymore.
> 
> If the readability of the collected ABNF were a goal, then the comments
> would be included, and the #rule extensions would be preserved.

If we used the #rule, it wouldn't be an ABNF conforming to RFC5234 anymore.

> Having the collected ABNF split into multiple parts defeats the purpose of
> having a collected ABNF. Given the availability of Bill Fenner's tool, and
> the fact that the appendicies are generated from that tool, I don't see why
> the collected ABNF appendices need to be included anymore. A single,
> plain-text (no IETF boilerplate like headers/footers) file that gathers all
> the productions from all documents (including all parts of HTTPbis, RFC3986,
> etc.) would be a much more useful deliverable.

I have no problem in working on generating and publishing it 
unofficially, but I'm not sure how to make it part of the official spec. 
Any proposal for that?

> In the event that Appendix D differs materially from the grammar in the rest
> of the document, which part of the document takes precedence? Is Appendix D
> non-normative? It looks like all the appendices are non-normative except
> maybe the glossary.

Everything in an RFC is normative unless stated otherwise (as far as I 
can tell).

The ABNF appendix is auto-generated, thus I don't see how it can get out 
of sync with the rest of the spec except by us, the editors, screwing up.

BR, Julian