On 06-May-25 10:19, Russ Housley wrote:
On May 5, 2025, at 5:23 PM, Brian E Carpenter <brian.e.carpen...@gmail.com>
wrote:
On 05-May-25 20:13, Martin J. Dürst wrote:
Hello Martin, Brian,
On 2025-05-05 09:13, Martin Thomson wrote:
On Mon, May 5, 2025, at 07:10, Brian E Carpenter wrote:
How would we feel about the following statement, in a hypothetical
draft about ASCII art:
"Normative descriptions of protocols, systems, etc. must be fully
represented in the text of the RFC, and must not be contingent on
comprehension of any ASCII art."
My recollection is that this has been the case for as long as I've been
involved in putting RFCs together.
Do we need an exception to the non-normative rule for cases where the
SVG is directly equivalent to ASCII art for a PDU?
I don't think so. There are some cases where RFCs have escaped into
publication without a textual description of the PDU, but I do not consider
that to be acceptable. It's almost trivial to provide words that describe the
PDU layout at the same time as the field semantics are defined. RFC 791 set a
good example there.
I agree. Occasionally, ASCII art may be slightly more accessible than
SVG, but it will still require a lot of effort for some blind person to
understand it. In case we haven't required text equivalents for ASCII
art, that's something that we should fix.
I was a bit surprised by Martin Thomson's reply because I don't think I have
ever seen it written that ASCII art is non-normative. It's not in the style
guide as far as I can see. RFC 2360 describes packet diagrams but doesn't
clarify their status, and does not state that a textual packet description is
*required*:
"Most link, network, and transport layer protocols have packet
descriptions. Packet diagrams included in the standard are very
helpful to the reader."
However, the RFC 2360 checklist implies that packet diagrams are desirable:
"Does it give packet diagrams in recommended form, if applicable?"
I agree that this should be clarified. That's orthogonal to the SVG issue, and
probably fits under accessibility.
Brian:
I bet you recall this...
When you were IETF Chair, I was Security AD and my co-AD was Sam Hartman.
There were several DISCUSS positions that were put on documents that did not
repeat MUST and SHOULD requirements from diagrams in the body. Sam could not
get the information from the diagram (ASCII or otherwise). For a blind man, Sam
had incredible skills, but his text reader could not parse diagrams.
Right. Sam never failed to amaze me. Anyone can check this by running RFC791 through a
screen reader. It gets really boring when it gets to
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. "Plus dash plus
dash plus dash..."
But if we're quibbling, RFC 791 lacks any way to tell a screen reader to skip the diagram, and lacks a
sentence something like "We now describe the components of the header in sequence." After all those
"plus dashes" and associated junk, it just says "Version: 4 bits".
I fear, despite your and Martin Thomson's comments, that we still have a major
accessibility problem for many existing RFCs, and we need stronger guidance for
the future.
Brian
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
