Re: [rfc-i] Report: Accessibility of RFCs

[Paul Kyzivat <[e-mail]>]

On 11/6/23 5:44 PM, Toerless Eckert wrote:
> On Mon, Nov 06, 2023 at 11:08:20PM +0100, Alexis Rossi wrote:
>> Yes, that’s the goal - artwork is not normative. I would still like people with visual impairments to be able to read the entire RFC though if they choose.
> 
> The most easy example to the opposite of course are any tables
> to create IANA registries. Which of course are also the type of
> craphics that i'd expect any screen reader to actually make easily sense of.
> 
> It gets more complicated when you go to the ASCII art with which we specify
> the most important normative aspects of protocols: protocol headers.
> E.g.: start with IP (rfc791) and any on-the-wire protocol header RFC
> from there on.
> 
> There are graphics that describe how architecture elements are related
> to each other. I'd call those normative.
> 
> There are graphics core to understanding protocols, the oldest i remember
> for example is rfc2328 (ospf), which really is very nicely using
> graphics to explain and specify the protocol. Topologies, state-tables,
> You can argue how much normative those are, but remember: normative alone
> does not suffice. You need all the information sufficient to understand how
> to build an interoperable implementation.
> 
> aka: there is a humunguous amount of normative graphics we have and/or
> graphics required to be understood to build interoperable implementations.
> 
> Not all of them actually are "nice" by todays standards, aka: for
> something like our protocol header graphics it would be lovely if
> we had a formal language to specify those protocol headers and then
> the graphics would just be one rendering that we could create. But
> we just never had enough of pain to invest efforts to get that done.
> 
> But in summary: Yes, a lot of graphics in RFCs are normative.

Maybe not normative, but sequence diagrams are very important in 
understanding some protocols. I despair at rendering a complex sequence 
diagram as text.

	Thanks,
	Paul