[rfc-i] [xml2rfc] use of sourcecode type
cabo at tzi.org
Mon Jul 27 08:43:36 PDT 2020
> […] I have never seen abnf in an ietf document that was complete on its own. Every one references rules defined somewhere else - usually in some other ietf document. These references all all informal, either stated in text before or after the abnf, or within the abnf as a comment or as a prose-val (e.g., <foo defined in RFC666>).
Well, I have started to recommend doing complete ABNF instead of ill-defined references. E.g., see it in draft-ietf-core-dev-urn-07.txt:
The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and
ALPHA rules originally defined in [RFC5234], exactly as defined
The general problem of composing a grammar out of parts coming from different places is now being discussed in CBOR (for CDDL), and I would expect the results copy over to ABNF as CDDL is so similar to ABNF.
> But I think *that* is a problem that we shouldn't attempt to solve here. IMO an abnf file that is intended to be syntactically correct and complete other than references to external rules should probably be tagged with type "abnf".
> ABNF is particularly forgiving regarding statement ordering. So it may take further study to decide if/when marking abnf as a fragment makes sense.
If you aren’t supposed to use it on its own.
As with “bad” ABNF (CDDL, …); I would suggest a “;bad” qualifier for these.
More information about the rfc-interest