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

I agree with Dave and Julian.  The fix for this errata should be a statement about which rules are imported, and a statement that CHAR is NOT imported, to be absolutely specific.  Changing the ABNF itself is neither needed nor desirable, IMO.

— 
Joe Hildebrand

> On Sep 20, 2023, at 10:26 AM, Dave Crocker <dcrocker@gmail.com> wrote:
> 
> 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
> dcrocker@gmail.com
> mast:@dcrocker@mastodon.social
> 408.329.0791
> 
> Volunteer, Silicon Valley Chapter
> Information & Planning Coordinator
> American Red Cross
> dave.crocker2@redcross.org
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json