[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"
rja.lists at gmail.com
Fri Feb 15 09:02:06 PST 2013
On 15 Feb 2013, at 11:22 , Paul Hoffman wrote:
> You are mixing two things here: line-length and pagination.
They inter-relate. If maximum line-length is variable
depending on which device one views a file upon, but the
lines/page is fixed, the pagination necessarily will vary
as a result.
> Keeping the current 72-character line length restriction
> has a significant impact on the kind of ASCII art
> that can be included.
For ~2 decades, I've been told that those two restrictions
(characters/line & lines/page) were picked carefully to ensure
that a text/plain (.txt) format RFC would print the same on
both A4 and US-Letter paper sizes (which have similar
but different geometries).
That property of having at least one common file format that
prints identically on A4 and US-Letter paper, does not
require specialised tools (e.g. PDF application), and also
includes printed page numbers is very important to some of us.
If the RFC Editor did the analysis and came up with
some different characters/line and some different lines/page
that retained the property of having the same pagination,
printed page numbers, and printed result overall for
both A4 and US-Letter paper, that also would be fine
We already have at least one example (e.g., RFC-1305,
circa pages 19 & 20) where the non-text/plain version
(i.e., the PDF version) is rather more readable than the
text/plain version. So workarounds already exist for the
few cases where ASCII art limitations are problematic.
However, kindly recall that my suggestion did not talk
about what format(s) might be officially "normative",
merely about the importance of having the current
text/plain format live on (possibly as one of several
> It is trivial for the RFC Editor to produce both types
> from the canonical source.
I'll leave the evaluation of "trivial" to the
RFC Editor's best judgement.
I do think it ought to be straight-forward to continue
to produce the existing text/plain (.txt) format --
as one of possibly several future RFC formats -- simply
because that tool chain already exists.
To be crystal clear:
I don't object to the RFC Editor having multiple
text/plain formats, provided one of them continues
to have the current characters/line and lines/page
practices -- and includes page numbers as done at
For consistency with the several thousand existing RFCs,
I'd suggest that the one following current conventions
use the .txt file extension, while any other text/plain
formats that might be created use some different
More information about the rfc-interest