Re: [rfc-i] getting SVG of RFC diagrams

[Paul Kyzivat <[e-mail]>]

Carsten,

On 11/27/23 1:04 PM, Carsten Bormann wrote:
> On 2023-11-27, at 18:21, Paul Kyzivat <[e-mail]> wrote:
>>
>> My interest came from working on a bunch of sip documents that define syntax using ABNF. The core defining document for sip is RFC3261. Its ABNF is large self contained except it uses the ABNF core rules. It references SDP (RFC237) but their syntax is independent. There are quite a lot of follow on documents that extend and revise RFC3261 and/or RFC2327. Many of those contain new ABNF describing their extension as an addition/revision of the ABNF in prior documents.
> 
> I have a slightly different approach here.
> 
> Generally, FDT that we find in older RFCs is not fully usable out of the box.

FDT?

> Some assembly may be required, as you mention.
> There also may be some need for fixing, completing, or bundling.
> (A typical example for the need of intervention is the use of prose <…> in ABNF.)

Yes. Some of the issues wrt ABNF in older RFCs:

- the oldest have no xml at all. The txt was generated using assorted 
tools. So the ABNF needs to be extracted from the txt.

- some were generated from v1 xml, but that doesn't exist for the final 
RFC, so again ABNF must be extracted from the txt version

- the ABNF was often interspersed with free form text commentary. While 
automation can do a "decent" job of extracting abnf it generally 
requires some manual tweaking to get it exactly right.

- there is no formal notation for indicating the dependency on abnf from 
another document. This is typically indicated via verbiage in the doc 
text or in abnf comments. Eventually I took to using a form like:

	token = <defined in RFC3261>

My thinking is that going forward we can provide for automatic 
extraction from newer authoritative xml sources, using a consistent URL 
convention for referencing them. Then for important older documents the 
pieces can be manually extracted, stored by the datatracker, and 
accessed using the same URL conventions.

This doesn't solve the problem of how to formally reference stuff from 
other documents. (Must this be handled separately for each source 
format, or can it be handled consistently as a preprocessor across 
source formats?)

> So, for CDDL, I started writing a draft motivated by my own use, draft-bormann-cbor-rfc-cddl-models.
> This picks up a few pieces of CDDL from RFCs and makes it available in a more palatable form.
> Obviously, this needs more work, but it already helps as it is.

I'm not sure what your goal is here? If I was implementing RFC8366 
should I somehow know that I can get a definition of voucher-artifact 
from draft-bormann-cbor-rfc-cddl-models?

And would a revision of this document be published every time a new RFC 
is published containing CDDL?

This doesn't seem to me to work at scale.

	Thanks,
	Paul

> Clearly a community effort, but one that could be made more useful without a lot of process needed.
> 
> YANG has a much stronger culture of checking the FDT models before publication.  (The recently pointed out XPath problems notwithstanding.)
> 
> BTW, some interesting data:
> 13 post-8650 RFCs have SVG, 108 active I-Ds.
> SVG is clearly on an upwards trend.
> 69 post-8650 RFCs have ABNF, 43 active I-Ds that we have the XML for.
> ABNF appears to be well-established and in active development.
> 29 post-8650 RFCs have CDDL, 55 active I-Ds that we have the XML for.
> CDDL also is seeing an upwards trend.
> 58 post-8650 RFCs have YANG, 37 active I-Ds that we have the XML for.
> YANG also is well-established.
> 
> (Of course, this quick check only was counting properly identified ABNF or CDDL.  The post-8650 RFCs span four years of activity now, the active I-Ds 0.5 years, but of course many of these have earlier revisions and do replace even older drafts.)
> 
> Grüße, Carsten
>