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

[Michael Richardson <[e-mail]>]

Nico Williams <[e-mail]> wrote:
    > On Tue, May 13, 2025 at 03:00:45PM -0700, Alexis Rossi wrote:
    >> 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!

    > I find it surprising that there are RFCs with normative information in
    > imagery.  And I do think that's a problem, that we really should not
    > have any RFCs with normative information in imagery.

I'm sure that this is not true.
I'm sure that there are many RFCs where the format of the
packet/header/extension can only be understood by looking at the image.
I certainly have never included the field sizes in descriptive text.

Note that I think this might apply to **tables**, particularly in txt format.

Calling myself out for a few RFCs I helped author:
My RFC9148 has tables that contain BCP14 language.
RFC9032 has figures for packets, text has no sizes.
And the descriptions are *not* in order, but in relevance, I think.
RFC9031 has time sequence diagrams whose ordering is probably not well
described in the text, but the packets are described by CDDL.
RFC9010 packet diagram where text is not in order, and do not show sizes.
RFC9008 has a network diagram (Figure 3), which shows connectivity, and the
next 24 sections critically depend upon understanding the adjacencies.
And each section has a table that must be illegible in txt.


    > Even plantuml sources will be more accessible than imagery.  We should
    > try to be more formal and precise in prose.

I haven't used this one, but it seems similiar to other things.

    > And we should use formal specifications languages more, or design ones
    > for our needs.  But this last idea is not popular at the IETF.  We're
    > not the ITU-T, which charges money for participation and for copies of
    > many of their specs, but which also has very high production values.

kramdown has many ways to "shell out" to get nice swim diagrams, and other
things.  We probably need a few more popular choices (I mean: best practices
that are well documented), and to socialize those choices.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*