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

[Nico Williams <[e-mail]>]

On Wed, Sep 20, 2023 at 05:20:42PM +0200, 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).

It's unclear if the core rules are always in scope or if one has to
import them somehow.  But clearly RFC 8259 wants some of the core rules.

It's also unclear if rule conflicts are errors or if the latest
overrides the preceding.

> Is this a bug in 8259?

I'm inclined to think so.  But perhaps it's only or also a bug in RFC
5234 (and possibly in other RFCs that use ABNF).

> 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)?

That depends on whether one reads RFC 5234 as having the core rules
always in effect (like you, I don't), and whether conflicts are errors
or overrides (there's no mention of this in RFC 5234).  ABNF lacks
import/export syntax (and therefore also rule name namespacing), so
conflicts must be very likely.

Perhaps the best thing to do is to resolve all of this in an update to
ABNF.  The easiest thing to do though is to accept this erratum.  Both
can also be done.

> I know there are tons of ABNF out there that doesn’t get this right,
> so I’m also interested in a way forward that allows us to de-soupify
> ABNF (RFC 9431), while also offering a clear interpretation of what is
> already there.

RFC 9431?  "Message Queuing Telemetry Transport (MQTT) and Transport
Layer Security (TLS) Profile of Authentication and Authorization for
Constrained Environments (ACE) Framework"?

Nico
--