[rfc-i] Character sets, was Comments on draft-iab-rfcformat
mrex at sap.com
Fri Dec 21 09:51:25 PST 2012
Ted Lemon wrote:
> If Martin doesn't want to upgrade from his 3270 terminal (a truly
> wonderful and innovative piece of technology in its time, I might add!),
What I'm using is primarily an "xterm" from the X11 software,
preferably in the xterm-r5 variant. Something that appears to
be an enhanced version of "VT100" (whatever that is), i.e. monochrome,
fixed pitch&size font, typically 80 columns wide (but resizeable).
> presumably he can get someone to print out a typeset version of
> the document for him to read on paper.
While I do sometimes print out RFCs, I try to do it only when implementing
a non-trivial spec and lack the necessary screen real estate to put up
all necessery parts of relevant specs at the same time while implementing,
and for annotating or coloring the parts of the spec that I consider
At home, I don't even have a printer anymore (my daughter fried two
printer heads of my ink jet printer).
Lots of folks who use "sophisticated" word processing software, or worse HTML,
demonstrate very little clue about typesetting by their font size&type
choices and colorization of words & pages.
You could look at specifications from ITU-T (e.g. ITU-T Rec. X.509 11/2008)
or NIST (e.g. FIPS 186-3) for examples of a more "feature rich" documents
that doen't go completely overboard. You will probably find very few
non-ascii characters in the two mentioned documents, because it would
only make them harder to comprehend.
(And while I've been looking up stuff in X.509 11/2008 several times,
I just noticed for the first time that it contains a few multi-color
pictures. It also contains a few diagrams, but I actually never
ever looked at any of them -- they're irrelevant. Typically, I look
up the definition in PKIX/rfc5280 first, and then cross-check with
X.509 08/2005 and again with X.509 11/2008 (because of several serious
defects in the 08/2005 version, and when doing that, all the graphics
in X.509 remain irrelevant.
Now the problem with feature-rich document formats is, that it is much
harder to discuss changes on Mailing lists, because copy&paste doesn't
work -- something which works just great for traditional I-Ds and RFCs
-- copying content from I-Ds and RFCs into EMails or into Source code
comments usually does not require _any_ reformatting.
Similar for mailing list discussion about graphics and pictures.
Proposing specific alternative text is easy. Talking about changes
and improvements for graphics or pictures can become pretty awkward.
And trying to pick up an abandoned I-D or rev'ving a published RFC
becomes more difficult, the more feature-ladden the existing document is.
More information about the rfc-interest