On 14. May 2025, at 01:24, Brian E Carpenter <[email protected]> wrote: > > Just to take a recent example, anyone consulting RFC 9686 using a screen > reader will not obtain an overview of the address registration mechanism > (only described by Fig. 1) and will have to guess the length of the > option-code and option-len fields (only defined by Fig. 2).
Figure 1 should be shipped with the mscgen or UML source. Figure 2 can be fully understood by Quentin’s parser; we could define a language (like the one called “protocol” that kramdown-rfc can use to generate such figures) that can be read linearly and ship that with our box notation designs. In both cases, the answer is probably not adding more walls of text, but (1) agreeing on description techniques that are more accessible and (2) providing a way to include those with the RFC. (English just is one of the worst of those description techniques, so I don’t agree with Marc here — but that is a completely different discussion from the one Alexis started.) Grüße, Carsten _______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
