[rfc-i] Re: Normative information in RFC imagery

Carsten Bormann <cabo@tzi.org> Wed, 14 May 2025 00:11 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-interest@mail2.ietf.org
Delivered-To: rfc-interest@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 99B7C2846B0B for <rfc-interest@mail2.ietf.org>; Tue, 13 May 2025 17:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnrI27lla01l for <rfc-interest@mail2.ietf.org>; Tue, 13 May 2025 17:11:23 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8B7212846B06 for <rfc-interest@rfc-editor.org>; Tue, 13 May 2025 17:11:23 -0700 (PDT)
Received: from smtpclient.apple (p5dc5d5ed.dip0.t-ipconnect.de [93.197.213.237]) (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 4Zxtzt0hPJzDCbX; Wed, 14 May 2025 02:11:22 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <ed683cdd-3b40-4594-9b8d-426df7adb647@gmail.com>
Date: Wed, 14 May 2025 02:11:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F56CE49-DB9F-4E93-BCD5-FD207CB3FB5D@tzi.org>
References: <CALLfFGPtFPZh2onghyiiurH0QBOUmde7Xck66+0tv7-OF07QgA@mail.gmail.com> <69e8dbcf-d026-4558-b28d-fb24964a171a@petit-huguenin.org> <ed683cdd-3b40-4594-9b8d-426df7adb647@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3826.600.51.1.1)
Message-ID-Hash: 6ZJSL5VFTVJUEMINYDGY5QLEBV4BW7SL
X-Message-ID-Hash: 6ZJSL5VFTVJUEMINYDGY5QLEBV4BW7SL
X-MailFrom: cabo@tzi.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rfc-interest.rfc-editor.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Alexis Rossi <alexisrossirsce@gmail.com>, rfc-interest@rfc-editor.org, Marc Petit-Huguenin <marc@petit-huguenin.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [rfc-i] Re: Normative information in RFC imagery
List-Id: "A general discussion list about the RFC Series and its operational processes." <rfc-interest.rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/6hMRK3UQiMkFcskuCmfjQ8sXiSM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Owner: <mailto:rfc-interest-owner@rfc-editor.org>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Subscribe: <mailto:rfc-interest-join@rfc-editor.org>
List-Unsubscribe: <mailto:rfc-interest-leave@rfc-editor.org>

On 14. May 2025, at 01:24, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Just to take a recent example, anyone consulting RFC 9686 using a screen
> reader will not obtain an overview of the address registration mechanism
> (only described by Fig. 1) and will have to guess the length of the
> option-code and option-len fields (only defined by Fig. 2).

Figure 1 should be shipped with the mscgen or UML source.

Figure 2 can be fully understood by Quentin’s parser; we could define a language (like the one called “protocol” that kramdown-rfc can use to generate such figures) that can be read linearly and ship that with our box notation designs.

In both cases, the answer is probably not adding more walls of text, but (1) agreeing on description techniques that are more accessible and (2) providing a way to include those with the RFC.
(English just is one of the worst of those description techniques, so I don’t agree with Marc here — but that is a completely different discussion from the one Alexis started.)

Grüße, Carsten