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

Carsten Bormann <cabo@tzi.org> Mon, 27 November 2023 18:04 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20E6C17DC14 for <rfc-interest@ietfa.amsl.com>; Mon, 27 Nov 2023 10:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZaZV27Qqg2m for <rfc-interest@ietfa.amsl.com>; Mon, 27 Nov 2023 10:04:49 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [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 ietfa.amsl.com (Postfix) with ESMTPS id C694BC151067 for <rfc-interest@rfc-editor.org>; Mon, 27 Nov 2023 10:04:20 -0800 (PST)
Received: from eduroam-0647.wlan.uni-bremen.de (eduroam-0647.wlan.uni-bremen.de [134.102.18.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4SfD4L0YK8zDCbr; Mon, 27 Nov 2023 19:04:18 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2f28226d-8531-4352-908b-30ca6ac18ab8@alum.mit.edu>
Date: Mon, 27 Nov 2023 19:04:17 +0100
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, rfc-interest@rfc-editor.org
X-Mao-Original-Outgoing-Id: 722801057.395944-a64aedb03cc997c27d6e465c0f872425
Content-Transfer-Encoding: quoted-printable
Message-Id: <33824D55-144E-4ACA-BC9B-CD049CF86719@tzi.org>
References: <310371.1700735021@dyas> <7C81D316-7D04-4941-BEE5-6AE8C96F0DE1@tzi.org> <D1F8F86E-80D7-4FC7-B7B5-32648ACB5D65@tzi.org> <MN2PR11MB3757AF8CCDF388BA5CECFE1AB9B8A@MN2PR11MB3757.namprd11.prod.outlook.com> <153bde12-5773-42ce-bfdf-392e4492c06b@gmx.de> <9D66A3A2-5516-4924-8B1E-420871D862C5@tzi.org> <8373b6b5-4a0a-4abb-8880-d618154b2f81@alum.mit.edu> <1F2DBD33-1553-4BBE-8ADB-115632C8373D@tzi.org> <d9b2052b-8f23-4cbf-99b8-9d2b85892fb4@alum.mit.edu> <75157E6C-99B3-4E17-8FFD-57A1D55E0CD4@tzi.org> <b9ba0201-13c6-420c-804a-180572083f02@alum.mit.edu> <8B573C04-4BDB-47B3-80B9-A2BE87A43AAF@vpnc.org> <2f28226d-8531-4352-908b-30ca6ac18ab8@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/ErqiK__3hCmx1J7fdVhyVVqlnuI>
Subject: Re: [rfc-i] getting SVG of RFC diagrams
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2023 18:04:54 -0000

On 2023-11-27, at 18:21, Paul Kyzivat <pkyzivat@alum.mit.edu> 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.
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.)

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.

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