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

Paul Hoffman <phoffman@proper.com> Tue, 13 May 2025 22:40 UTC

Return-Path: <phoffman@proper.com>
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 B1D1A2841BD3 for <rfc-interest@mail2.ietf.org>; Tue, 13 May 2025 15:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rgVfrFkNZAvs for <rfc-interest@mail2.ietf.org>; Tue, 13 May 2025 15:40:05 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9B3FA2841BC6 for <rfc-interest@rfc-editor.org>; Tue, 13 May 2025 15:40:05 -0700 (PDT)
Received: from [10.32.60.78] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 54DMe3Aq004819 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <rfc-interest@rfc-editor.org>; Tue, 13 May 2025 15:40:04 -0700 (MST) (envelope-from phoffman@proper.com)
X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.60.78]
From: Paul Hoffman <phoffman@proper.com>
To: rfc-interest@rfc-editor.org
Date: Tue, 13 May 2025 15:40:03 -0700
X-Mailer: MailMate (2.0r6255)
Message-ID: <8B304289-B709-43F8-AB34-38CF2B5811EF@proper.com>
In-Reply-To: <CALLfFGPtFPZh2onghyiiurH0QBOUmde7Xck66+0tv7-OF07QgA@mail.gmail.com>
References: <CALLfFGPtFPZh2onghyiiurH0QBOUmde7Xck66+0tv7-OF07QgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_1611933A-2AD0-4558-9785-30C47DB3E3C0_="
Embedded-HTML: [{"plain":[373,3916],"uuid":"D66F2D0F-6F63-4E69-A199-29B17387A994"}]
Message-ID-Hash: GCXNC66RYJHIQZP6KV3AQIABUFJT54FQ
X-Message-ID-Hash: GCXNC66RYJHIQZP6KV3AQIABUFJT54FQ
X-MailFrom: phoffman@proper.com
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
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/oPkV-UiI9B4MJZeZPuv0NZLMd-o>
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>

This is a great summary of a thread that should have moved to this list 
long ago; it does not belong in the RSWG.

It would help the entire IETF community if there was a definitive RFC 
covering this topic. Each RFC stream could decide if they agree with the 
contents of the eventual RFC for their own stream.

--Paul Hoffman

On 13 May 2025, at 15:00, Alexis Rossi wrote:

> Hello,
>
> This is a long one, so let me state my goal up front. I am trying to
> ascertain whether there is community interest in trying to make sure 
> future
> RFCs can be fully read and understood without relying on information 
> in
> imagery (SVG or ASCII). This is an accessibility issue, but I think it 
> also
> may be helpful for people who learn in different ways. We are not 
> talking
> about trying to address this in older RFCs, just new ones.
>
> If there is interest in this, I think the path we would take would be 
> to
> have an IETF working group attempt to address the issue.
>
> * Background
>
> The RSWG is currently working on replacing RFC 7996, which allowed the 
> use
> of SVGs in RFCs. (We would like to make creating SVGs easier for the
> community.)
>
> RFC 7996 contains the following language in the introduction:
>
> "Note that in RFCs, the text provides normative descriptions of 
> protocols,
> systems, etc. Diagrams may be used to help explain concepts more 
> clearly,
> but they provide supporting details and should not be considered to be
> complete specifications in themselves."
>
> The RSWG draft [1] that has been adopted for the replacement of 7996
> currently has similar but stronger language (though softer language 
> has
> been suggested in thread), and this has lead to a discussion about
> normative info in imagery:
> https://mailarchive.ietf.org/arch/msg/rswg/E4eBJEmlTo5nX7ITYFvIvjKa2ec/
>
> * Thread Discussion Summary
>
> Some people think that we already have the general idea in the 
> community
> that the text should be normative, and that imagery should be a 
> helpful
> illustration of the text. (So you could have normative info in an 
> image,
> but that shouldn't be the ONLY place where it exists.) Other than the 
> above
> text in RFC7996, this seems to be "folklore" or a generally accepted 
> but
> not documented norm. Additionally, the point has been made that 7996 
> is an
> Informational IAB document (so does not have IETF consensus), and 
> shouldn't
> govern how the IETF uses imagery.
>
> Others have made the point that this has never been an accepted norm 
> for
> ASCII art. We haven't found a citation that says otherwise (other than
> 7996). And it seems that in regards to packet diagrams specifically, 
> BCP
> 22/RFC2360 Section 3.1 [2] actually tells us to put normative info 
> into
> ASCII art.
>
> Additionally, in discussing whether it is even possible to have all
> normative information in the text, some have asserted (and others have
> refuted) that some types of information may be too difficult/onerous 
> to
> represent fully in text, thus making a diagram/image the most 
> reasonable
> place for the information.
>
> * Accessibility
>
> ASCII art is not accessible to people using screen readers. It is read 
> as
> gobbledygook, essentially. ZSo generally there are three ways to make
> imagery accessible:
>
> 1) provide adequate alt/desc text within the code to fully describe 
> the
> content of a diagram/image to someone using a screen reader (SVG only)
> 2) use aria labels appropriately to allow a screenreader user to 
> navigate
> the diagram (SVG only)
> 3) fully describe the normative information in the text (TXT has all 
> the
> info needed outside of the ASCII art, and SVG points people to the 
> text)
>
> A fourth path has been suggested: using a formal language to describe
> diagrams. UML was suggested as a possibility. I have not yet found
> convincing evidence that UML alone is sufficiently accessible to 
> people
> with visual disabilities.
>
> So I think this leads me back to my goal for posting here. Is the 
> community
> interested in supporting accessibility by trying to make sure future 
> RFCs
> can be fully read and understood without relying on information in 
> imagery?
> And thank you for reading this far!
>
> Alexis
>
>
> [1] https://datatracker.ietf.org/doc/draft-editorial-rswg-svgsinrfcs/
> [2] https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1