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

[Agent <[e-mail]>]

I'm thinking about this one. My initial thoughts are that we should use an alternatives mechanism so that ASCII art is always there but SVG overlay exists - or maybe work on an ASCII/SVG gateway is called for. Not sure how the current generation of braille readers are impacted by SVG and it is important not to risk trojans in the vectors. Probably offended someone with that but I hope you know what I mean.

If you have received this message by common mistake, please contact the sender as soon as possible - you may be committing an offence if you copy it, or make use of any information contained in it for any purpose, or disclose its contents to any other person. Messages sent and received may not be private and may be the subject of monitoring.

Sent from Proton Mail Android

-------- Original Message --------
On 13/05/2025 23:18, Paul Duffy \(paduffy\) wrote:

"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.)”

 

Long, long overdue good news.  IMO SVG must be treated as a first-class feature for RFC production and related IETF tooling.  Meaning IETF needs to adhere to the SVG format/tooling used by the rest of the world.

 

 

From: Alexis Rossi <[e-mail]>
Sent: Tuesday, May 13, 2025 6:01 PM
To: [e-mail]
Subject: [rfc-i] Normative information in RFC imagery

 

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/" rel="nofollow"> 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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-editorial-rswg-svgsinrfcs/
[2] https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1" rel="nofollow">https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1