*>
*> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf