Re: [abnf-discuss] Are the Core Rules (Appendix B.1 of RFC 5234) always present in an ABNF spec?

[Dave Crocker <[e-mail]>]

On 9/20/2023 11:25 AM, Paul Kyzivat wrote:
> But because there is a practical need to "import"/"copy" rules from 
> one spec to another and 5234 doesn't provide one, various ad hoc 
> mechanisms for specifying this have evolved across multiple documents. 
> Some are:

the 'how' of specifying importation can vary.  personally, I don't care 
how it's done as long as it is clear and easy for an average reader to 
understand unambiguously.


> 1) verbage in the explanatory text of the document explaining that 
> certain rules are to be taken from another document
>
> 2) an ABNF comment explaining the same thing
>
> 3) use of a prose-val, such as:
>     CHAR = <as defined in RFC5234>
>
> I generally prefer (3) when only a few rules are needed and their 
> definitions don't reference lots of other rules. If the situation is 
> more complex then I generally use (2).

It's also common to have a section early in the document that sets up 
terminology definitions and importations. (This might be your 1) but the 
section I'm referencing is more than explanatory.


> It can be hard to verify the ABNF in a document that extends the ABNF 
> of another document. It is necessary to actually cut and paste to 
> create the composite ABNF grammar and then check it. (Or implement it.)

Point taken.  On the other hand, repeating the details of a rule 
specification from another spec invites divergence, as specifications 
evolve.


>
> I would *like* to see ABNF extended to have a more formal mechanism 
> for importation of ABNF, and for extension of ABNF grammars. This 
> would facilitate automatic verification of ABNF in documents. But I'm 
> dubious whether there is sufficient interest to pursue this. 

Yes it would.  I think that every idea for enhancement I've ever seen 
for ABNF was entirely reasonable and, generally, so were the proposed 
details.

At the purely technical level, my main criticism is a tendency to want 
to put enhancements into the core set of rules.  I like a core to be as 
simple as possible, while covering 'essential' capability, in order to 
reduce effort and problems with common implementation.

Something can be a good idea, and have community support, but not be 
widely needed.  Then it makes sense to standardize it but not as part of 
the core set.

At that highlights the non-technical issue, which I think is why many 
reasonable proposed enhancements have not been adopted:  lack of a 
critical mass of community support.


d/

-- 
Dave Crocker
[e-mail]
mast:@[e-mail]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[e-mail]