On 5/13/25 5:11 PM, Carsten Bormann wrote: > 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.)
I spent the last 10 years trying to convince people at the IETF to use formal methods to reduce errata and updates (with little success). I also recently proposed a modification to RFCXML to be able to reflow between different rendering formats (also with little success. see [1] for the motivation for that proposal). That to say that I am all for having more diverse ways of explaining how things works in an RFC (and stay tuned for more on that subject). But all that need to stay informative, and clearly labelled as such. The reason for having the normative part as English text is that it is the least common denominator. Yes, it is ambiguous if not written carefully, but it has the advantage that it is accessible to anybody with a reasonable ability to focus. As suggested by Pamela Zave[2], that English text could simply be paraphrasing what is described by the formal methods. [1] https://datatracker.ietf.org/doc/draft-petithuguenin-ufmrg-formal-sexpr/ [2] Zave, Pamela. "Experiences with protocol description." In Workshop on Rigorous Protocol Engineering (W-RiPE’11). 2011. -- Marc Petit-Huguenin Email: [email protected] Blog: https://medium.com/@petithug Profile: https://www.linkedin.com/in/petithug
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
