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

Carsten Bormann <> Sun, 26 November 2023 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7DA2C14CF1E for <>; Sun, 26 Nov 2023 11:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9976JAeVBagw for <>; Sun, 26 Nov 2023 11:45:57 -0800 (PST)
Received: from ( [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 956EFC14CEE3 for <>; Sun, 26 Nov 2023 11:45:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4SdfN16RNSzDCbr; Sun, 26 Nov 2023 20:45:53 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sun, 26 Nov 2023 20:45:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <310371.1700735021@dyas> <> <> <> <> <> <> <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.3774.
Archived-At: <>
Subject: Re: [rfc-i] getting SVG of RFC diagrams
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Nov 2023 19:46:01 -0000

Hi Paul,

>> I put in a proof of concept at
> This is a great proof of concept. It is very much like I was imagining.

Thank you.

> I'm not sure exactly how you are constructing the names of the parts. But the details of that can be bike shedded as needed.

File names should primarily come from the name= attributes of artwork/sourcecode.
However, few authors fill these in (and some get it wrong, e.g., in RFC 8688).
So, as a fallback, the code uses the slugifiedName= attribute created by the preptool (and, if that hasn’t be performed, it simulates the behavior of the preptool).

Multiple artwork/sourcecode with the same name= are aggregated (concatenated) under that name.
That would be mostly wrong with the guessed filenames from slugifiedName=, so here the extractor appends -b, -c… in case of a collision.
(Note that the slugifiedName= creation appends -2, -3…, so you might find a -2-b or so…)

> Question: are you actually extracting and storing all the pieces as a preprocessing step? Or is this virtual, where the pieces are extracted on demand?

In the PoC, this is done as preprocessing, essentially simply calling (an updated version of) kramdown-rfc-extract-sourcecode.

> If you are using a preprocessing step to extract the pieces, this could be made to work for docs prior to 8650 by using ad hoc techniques to extract the pieces from the .txt file. That could be done gradually on a demand basis. That would however require some sort of review process to ensure that is is done correctly.

I think that would be useful.
I’m not sure about how a review process would work, but people already are using aex and similar tools to extract ABNF, so by focusing on these higher-value targets we could cover 80 % of the needs with 20 % of the work.

(If the review process would be too arduous, we might need to fall back to a community effort.)

Grüße, Carsten