[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"

RJ Atkinson 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
with me.

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 
file extension.



More information about the rfc-interest mailing list