[rfc-i] Normative ABNF [was Re: Re: Normative information in RFC imagery]

[Marc Petit-Huguenin <[e-mail]>]

On 5/13/25 4:57 PM, Martin Thomson wrote:
> On Wed, May 14, 2025, at 09:43, Marc Petit-Huguenin wrote:
>> No to making anything but English sentences normative.  People can add 
>> all the examples, diagram, images, and alt tags they want in an RFC, I 
>> am going to ignore all of them and complain loudly that the protocol 
>> cannot be implemented.
> 
> Ah, that's roughly the same as Brian's "yes", then.  This language we write in is amazing.  I also agree, in principle.
> 
> There is a place for formal definition in languages other than English.  Things like formal schema definitions might appear in "figures", which is unclear to a reader, even if we have that distinction in source with <artwork> vs. <sourcecode>.  This guidance needs to be limited to <artwork> and non-essential <sourcecode>: imagery, examples, and "supporting" material.  The stuff that might help comprehension, but might not need to be formally understood to implement.  
> 
> Normative ABNF (whoa, there's open debate about that as a good idea too, not going to take an absolutist position on that) might need to be normative.  But ABNF isn't pictures, so maybe we avoid that problem.
> 

https://datatracker.ietf.org/doc/draft-rivest-sexp/ is a good example of a language whose ABNF cannot be normative (that's because the s-exp variant described in it is non-context free).  Even without that, a normative ABNF would be too complex (if you look closely at my formalization of that spec, you can understand why).  So that's really an example of the English text be good enough to describe it clearly, but the formalization too complex for anyone but the purist.  That's why I think that formalizations are best as tools used to generate an RFC, but are not as useful inside the RFC itself.