[Tools-discuss] Re: [art] Re: Exploring ABNF extracts from RFCs

[Carsten Bormann <[e-mail]>]

Hi Paul,

> There are interesting open issues around abnf dependencies:

Let me talk about the directions draft-ietf-cbor-cddl-modules <https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-modules-02.html> [1] has taken on these.
Most of these decisions should transfer to ABNF right away.

[1]: https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-modules-02.html

> * If I want to use a rule defined in another document, do I add to my abnf *all* of the foreign abnf that contains the rule definitions I need? Or do I only import the specific rules I need and any other rules those depend on?

Just the needed rules and dependencies.
(We do have an “import *”.)

> * What to do if the imported abnf has rule names that duplicate ones I have defined in my own abnf? Should the abnf of each document live in a distinct namespace, linked only for the cross referencing rule names? Or should the writer of abnf with dependencies be responsible for avoiding naming conflicts?

Namespacing can help. 
https://www.ietf.org/archive/id/draft-ietf-cbor-cddl-modules-02.html#name-namespacing

> * How to deal with the different ways abnf is used in documents. E.g.,
> 
> - the simple case: the document contains a single block of abnf defining the syntax for the protocol that is the subject of the document.

Easy.

> - the doc has several blocks of abnf, each defining a separate syntax. Rule names may be reused, with different syntax, in each.

The sourcecode block should have a name= attribute to help with this.
(Eventually, this should be checked by tools/the RFC editor.)

> - the doc contains (possibly incomplete) fragments of abnf scattered through the doc text, plus a complete consolidated abnf syntax that likely duplicates some or all of the fragments.

Again, a name= help; the consolidated grammar will be what you want to reference.

> - the doc contains a complete abnf syntax that is broken into fragments interspersed with text descriptions.

No problem, if the name= is equal for all the snippets, kramdown-rfc-extract-sourcecode assembles the fragments for you (in document order, but that doesn’t make a difference for ABNF).

> My interest in this came from working on sip for many years. It has a root document RFC3261, and many extension & revision documents. There are extensive dependencies among these documents. The manner of expressing dependencies evolved over time. E.g.,
> 
> - Simple text in the doc prior to the abnf. E.g.,: "The rules foo, bar, and baz are defined in RFCnnn".
> 
> - Saying (or simply assuming) that all the Core Rules from RFC5234 are available.
> 
> - Stating the dependency in comment in the abnf
> 
> - Stating the dependency in an abnf prose-val. E.g.,
>    foo = <foo as defined in RFCnnn>
> 
> The latter is now my recommended best practice. It results in an abnf that can be fully syntax checked. Ideally we would formalize the syntax within the prose-val so it can be mechanically processed. Or define a new syntax for import, and possibly for namespaces.

draft-ietf-cbor-cddl-modules [1] uses explicit import statements so the import relationships aren’t scattered over the rules.
(ABNF proseval syntax is an unmined asset that we do not have in CDDL.)

Grüße, Carsten