*> *> Note 2: Unlike some others on the IETF list, I recognize the *> importance of having illustrations in better-than-ASCII forms. *> We may disagree on how often it is important, or even on whether *> "important" should be a criterion or the criterion should be *> closer to "convenience". I am nonetheless very sympathetic to *> the arguments that fancy illustrations often hide fuzzy thinking *> while the discipline of producing ASCII line art tends to *> clarify thinking and encourage simplicity in design. Perhaps as *> a result of those possible disagreement, we might disagree on *> the relevance of ASCII versions of text and ASCII approximations *> to the more advanced, image-type, illustrations. But we at *> least share the belief that there is a problem in this area that *> should be solved. I am not positive that even that position has *> IETF community consensus. *> *> regards, *> john
John, This discussion has seemed to overlook that fact that for the past 20 years or so the RFC Editor HAS offered a .ps/.pdf alternative output format; it just can't be normative. With very few exceptions, a protocol specifications (that's what we are supposed to be documenting here, the last time I checked) can be defined normatively quite satisfactorily using ASCII. But, sometimes it is helpful to add additional explanatory (non-normative) diagrams, equations, etc., which can be in an auxiliary .ps/.pdf version. I believe there are roughly 50 worked examples of this approach among the 4000+ RFCs in the archive. The one caveat is that processing RFCs with a .ps/.pdf version does take more time and effort, so we hope it does not happen very often. Bob Braden _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
