Dear Colleagues, Do you know, having to deal with legal matters affecting Children&families, and it's the same shit different day - informative v normative alias legislative v executive alias saxon v norman.
I digress. What about borrowing an idea from Microsoft branded visual basic? Graphical tools to generate textual representation optionally generated by synthetic intelligence and proofread by organics. The imagery becomes the data and the text the design. I did a similar experiment a few years ago with Case SD17C00505 including translation from my native British dialect at England to the language used at France and if memory serves also Russia. It's taken a while but it appears message received and understood. Think this is the list I turned to in 2019 when an ill tempered judge told me to write a complaint but failed to declare to whom. Best psychological support I can find. Phil. United National at&of England... -------- Original Message -------- On 14/05/2025 14:57, Marc Petit-Huguenin <[email protected]> wrote: > 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 > _______________________________________________ > rfc-interest mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
publickey - [email protected] - 0x98990EF9.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
