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

[Toerless Eckert <[e-mail]>]

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.

Cheers
    toerless