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

Carsten Bormann <> Mon, 27 November 2023 06:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76803C14CF1D for <>; Sun, 26 Nov 2023 22:48:15 -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 K052w9anaUlh for <>; Sun, 26 Nov 2023 22:48:11 -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 EFB45C14CF1C for <>; Sun, 26 Nov 2023 22:48:09 -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 4Sdx4714QLzDCbr; Mon, 27 Nov 2023 07:48:07 +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: Mon, 27 Nov 2023 07:47:56 +0100
Cc: Paul Kyzivat <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <310371.1700735021@dyas> <> <> <> <> <> <> <> <> <> <> <>
To: Paul Hoffman <>
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: Mon, 27 Nov 2023 06:48:15 -0000

On Nov 27, 2023, at 00:07, Paul Hoffman <> wrote:
> On 26 Nov 2023, at 14:53, Paul Kyzivat wrote:
>> OK, it seems Carsten and I are in violent agreement.
>> Can we hear from some others here on rfc-interest on whether this is popular enough to pursue further? At some point it probably needs to be discussed on the tools list.
> This discussion started with "I want to be able to extract $x" and veered into "the RPC should be making $x available to everyone for every RFC”.

Not sure that the RPC needs to do this.
The PoC shows that this can be a simple community-driven effort.
Also, if we want to give this a little more status, such a tool would fit into author tools or possibly in datatracker.

> A different path would be "it would be nice if I could extract $x from one or more RFCs locally".

Done: kramdown-rfc-extract-sourcecode.

> Given that no one has asked the original question before now, it seems likely to only be needed by a small number (maybe less than a few dozen) people.

As I said, people are using their homegrown tools, existing (but single-purpose) tools like aex, or even the extracted files published by IANA (YANG).  So the functionality is needed by quite a few people, but many people think this needs a lot of fudging as they don’t know that this extraction has become mostly straightforward since we keep the XML files around (and then a little more complex again with RFC 8792).

> Thus, a discoverable tool that does it might be better than making the RPC add the tool and the process for everyone.

Which points to author tools/datatracker, or, if the tools team doesn’t want to pick this one up, to a community effort.

Grüße, Carsten