Re: [Json] [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 8:20 AM, Carsten Bormann wrote:
> The problem here is that RFC 8259 seems to (implicitly) import “DIGIT" and “HEXDIG" from RFC 5234 Appendix B.1, but also defines a rule “char”, which conflicts with “CHAR” in Appendix B.1 (rule names are case-insensitive per Section 2.1 of RFC 5234).
>
> Is this a bug in 8259?

Probably.  To use a rule that is not defined within the document using 
it has to mean that it comes from somewhere else.  (This is a tautology, 
but seems to be needed as a foundation for the concern here.)

If it comes from somewhere else, how is that importation specified?

If it is implied, how is a reader to reliably and accurately know what 
is imported and where it comes from?  Readers vary widely in subject 
matter knowledge and a specification needs to work for all readers.

In other words, it must not be 'implied'.  It has to be specified 
explicitly.

> And, if yes, is that bug that “char” and “CHAR” conflict (i.e., because B.1 is always implicitly imported), or that 8259 forgets to import DIGIT and HEXDIG (i.e., because B.1 is not implicitly imported)?

This hits some different issues, IMO.

One is formal specification requirements.  To that, anything clearly and 
precisely defined in fine.  So if a rulename is common elsewhere, there 
is nothing wrong with defining it differently, within the 4 walls of a 
given specification.

The other is a human factors concern.  If readers are generally already 
used to using the rulename and that rulename has a particular semantic, 
defining it differently within a spec creates a cognitive conflict, 
called proactive inhibition.  That invites error.

However sometimes it can be useful to note the history of the name and 
explicitly redefine it.  As long as the rationale for doing this is 
clear and documented, it might make sense to do. This would be an 
explicitly 'derivative' specification of the rulename, rather than 
purely replacement.

Lastly, while it might make sense to say that a spec citing the ABNF 
spec can be assumed to be importing rules from it, that seems to me a 
pretty risky approach to spec writing.  For example:

  * there is nothing in the ABNF spec that declares these rules to be
    automatically imported by users of ABNF
  * having something in an Appendix means it is extra, and therefore not
    'inherent'
  * the language at the start of the Appendix is "This appendix contains
    some basic rules that are in common use." which is casts this as
    informative rather than normative.


d/

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

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