[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
- [rfc-i] Re: Normative information in RFC imagery Nico Williams
- [rfc-i] Re: Normative information in RFC imagery Alexis Rossi
- [rfc-i] Re: Normative information in RFC imagery Michael Richardson
- [rfc-i] Re: Normative information in RFC imagery Paul Hoffman
- [rfc-i] Normative information in RFC imagery Alexis Rossi
- [rfc-i] Re: Normative information in RFC imagery Paul Duffy (paduffy)
- [rfc-i] Re: Normative information in RFC imagery Brian E Carpenter
- [rfc-i] Re: Normative information in RFC imagery Marc Petit-Huguenin
- [rfc-i] Re: Normative information in RFC imagery Carsten Bormann
- [rfc-i] Re: Normative information in RFC imagery Michael Richardson
- [rfc-i] Re: Normative information in RFC imagery Eliot Lear
- [rfc-i] Re: Normative information in RFC imagery Marc Petit-Huguenin
- [rfc-i] Re: Normative information in RFC imagery Carsten Bormann
- [rfc-i] Re: Normative information in RFC imagery Michael Richardson
- [rfc-i] Re: Normative information in RFC imagery Agent
- [rfc-i] Re: Normative information in RFC imagery Jean Mahoney
- [rfc-i] Normative ABNF [was Re: Re: Normative inf… Marc Petit-Huguenin
- [rfc-i] Description techniques [was Re: Normative… Marc Petit-Huguenin
- [rfc-i] Re: Normative information in RFC imagery Alexis Rossi
- [rfc-i] RFC 9633 SVG is unreadable (was: Normativ… Martin Thomson
- [rfc-i] Re: RFC 9633 SVG is unreadable (was: Norm… StJohns, Michael
- [rfc-i] Re: RFC 9633 SVG is unreadable (was: Norm… Martin Thomson
- [rfc-i] Re: RFC 9633 SVG is unreadable Brian E Carpenter
- [rfc-i] Re: RFC 9633 SVG is unreadable (was: Norm… Carsten Bormann
- [rfc-i] Re: RFC 9633 SVG is unreadable (was: Norm… Martin Thomson
- [rfc-i] Re: RFC 9633 SVG is unreadable James Cloos
- [rfc-i] Re: Normative information in RFC imagery Michael Richardson
- [rfc-i] Re: RFC 9633 SVG is unreadable Jean Mahoney
- [rfc-i] Re: RFC 9633 SVG is unreadable Jean Mahoney
- [rfc-i] Re: RFC 9633 SVG is unreadable (was: Norm… Nico Williams
- [rfc-i] Re: RFC 9633 SVG is unreadable (was: Norm… Carsten Bormann
- [rfc-i] Re: Normative information in RFC imagery Paul Kyzivat
- [rfc-i] Re: Normative information in RFC imagery Nico Williams
- [rfc-i] Re: Normative information in RFC imagery Nico Williams
- [rfc-i] Re: Normative information in RFC imagery Alexis Rossi
- [rfc-i] Re: RFC 9633 SVG is unreadable Brian E Carpenter
- [rfc-i] Re: Normative information in RFC imagery Paul Duffy (paduffy)
- [rfc-i] Re: Normative information in RFC imagery Martin Thomson
- [rfc-i] Re: Normative information in RFC imagery Nico Williams
- [rfc-i] Re: RFC 9633 SVG is unreadable Robert Sparks
- [rfc-i] Re: RFC 9633 SVG is unreadable Nico Williams
- [rfc-i] Re: RFC 9633 SVG is unreadable Brian E Carpenter
- [rfc-i] Re: RFC 9633 SVG is unreadable Martin Thomson
- [rfc-i] Re: checking SVGs (was Re: Re: RFC 9633 S… Martin Thomson
- [rfc-i] Re: RFC 9633 SVG is unreadable StJohns, Michael
- [rfc-i] Re: RFC 9633 SVG is unreadable Brian E Carpenter
- [rfc-i] Re: RFC 9633 SVG is unreadable Carsten Bormann
- [rfc-i] Re: RFC 9633 SVG is unreadable Brian E Carpenter
- [rfc-i] Re: RFC 9633 SVG is unreadable Martin Thomson
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Specification vs implementation [was … Nico Williams
- [rfc-i] Re: RFC 9633 SVG is unreadable Michael Richardson
- [rfc-i] Re: RFC 9633 SVG is unreadable Carsten Bormann
- [rfc-i] Specification vs implementation [was Re: … Marc Petit-Huguenin
- [rfc-i] Re: RFC 9633 SVG is unreadable Martin Thomson
- [rfc-i] checking SVGs (was Re: Re: RFC 9633 SVG i… Jean Mahoney
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Marc Petit-Huguenin
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Paul Kyzivat
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Eric Rescorla
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Brian E Carpenter
- [rfc-i] Re: Normative information in RFC imagery Nico Williams
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Nico Williams
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Wes Hardaker
- [rfc-i] Re: Description techniques [was Re: Norma… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Marc Petit-Huguenin
- [rfc-i] Re: Description techniques [was Re: Norma… Agent
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Agent
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Eliot Lear
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Agent
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Salz, Rich
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Wes Hardaker
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Eric Rescorla
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Julian Reschke
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Paul Kyzivat
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Brian E Carpenter
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Brian E Carpenter
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Eliot Lear
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Nico Williams
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Paul Kyzivat
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Eric Rescorla
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Paul Kyzivat
- [rfc-i] Re: Normative information in RFC imagery Carsten Bormann
- [rfc-i] Re: Normative information in RFC imagery Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Julian Reschke
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Marc Petit-Huguenin
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Paul Kyzivat
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Paul Kyzivat
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Carsten Bormann
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Marc Petit-Huguenin
- [rfc-i] Re: Normative ABNF [was Re: Re: Normative… Eric Rescorla