Opened 9 years ago

Closed 9 years ago

#266 closed defect (fixed)

Requirement for "Clear Printing"

Reported by: bernard_aboba@… Owned by: draft-iab-rfcformatreq@…
Priority: major Milestone: milestone1
Component: draft-iab-rfcformatreq Version: 1.0
Severity: In WG Last Call Keywords:
Cc: rfc-interest@…


3.3. Requirements to be retired

Some of the original requirements are removed from consideration:

  • Pagination ("Each page must be limited to 58 lines followed by

a form feed on a line by itself.")

  • Maximum line length ("Each line must be limited to 72

characters followed by carriage return and line feed.")

[BA] The document doesn't say whether "clear printing" of at least one format is a requirement or not, although Section 1.1 does refer to printing:

Publication format = display and distribution format as it may be
read or printed after the publication process has completed

Is the intent to just remove the above requirements, but still retain support for "clear printing" in at least one format, or is the requirement for printing also being removed?

Change History (8)

comment:1 Changed 9 years ago by hlflanagan@…

I am not certain exactly what you mean by "clear printing". The old requirements being retired were created with the expectation for printing to a certain paper size and format. Those requirements today are more commonly handled by tools (e.g. browsers, e-readers, print drivers) on the user side of things and I think that is acceptable. Where printing is preferred, the tools available to the users can control the printing to meet their particular circumstances more adeptly than requiring strict line length and pagination which would in turn impact other forms of display. I don't think specifically requiring "clear printing" if it means "make absolutely sure that something prints out to a specific layout" is necessary.

comment:2 Changed 9 years ago by bernard_aboba@…

From Ran Atkinson (see


A key feature of the current RFC publication process is

that a given RFC (or I-D) will have identical pagination
-- regardless of whether it is printed on A4 paper,
printed on US-Letter paper, or even viewed in a web browser
(i.e., browser showing text/plain format, rather than
a browser showing HTML format).

This means that when working with colleagues, one

can talk about some RFC (or I-D) and use the page
number as a reference/anchor point in our discussions.
Today, even folks working from an electronic copy
(if using the text/plain ".txt" format, rather than the
HTML format) also have that pagination visible to them.

It would be a nightmare to have a colleague refer

to (his/her) "page 4" and have that be "page 3" or
"page 5" on my own copy. That would be a huge waste
of a lot of folks' time, and seems easily avoidable.

While I'm sure that individual custom varies, nearly

all of the implementers that I know well normally work
from a printed copy. Similarly, many reviewers of I-Ds
and readers of RFCs find it more effective to work from
a printed copy.

Curiously, in my own (non-scientific) sample of people,

there is no "generational" aspect to this. This practice
of working from print when coding or designing an implementation
seems as common among folks who are 20-something as it is
with folks who are 40-something.

While I have no objection to making RFCs available

in other formats (e.g., HTML without pagination), I would
be greatly obliged if a print-oriented format with existing
fixed/predictable/consistent pagination and fixed/predictable
line-length remained available for those who wish to continue
to work from the decades-long text/plain (".txt") format.

The 2 current text/plain format rules cause printing

to work equally well with A4 and US-Letter paper sizes.
So one can work trans-Atlantic or trans-Pacific and all
be on the same page:

  • 58 lines/page
  • 72 characters (plus CR and LF)/line

So my requested action is that Section 3.3. be revised

to delete the "retirement" of the 58 lines/page and
72 characters (plus CR and LF)/line rules.

I'd be quite happy if these 2 rules were scoped to apply only

to the "text/plain" format of RFCs (and I-Ds), such that those
2 rules did NOT apply if one were generating an HTML format
or some other format. Of course, this implies continuing the
automatic generation of a print-oriented format (i.e., text/plain
with ".txt" filename extension) that DOES comply with those
2 rules.

This change to the RFC Format Requirements draft would retain

the critical uniformity of pagination in the existing widely used
printable format, while allowing flexibility in line-length and
pagination in other formats (e.g, HTML).


Ran Atkinson

comment:3 Changed 9 years ago by bernard_aboba@…

[BA] Note that the term "clear printing" is used in Section 2.1.3:

Arguments for continuing the use of discrete pages within RFCs:

  • Ease of reference and clear printing; referring to section

numbers is too coarse a method.

[BA] My suggestion is that the term "clear" be removed, since the meaning appears to be unclear.

comment:4 Changed 9 years ago by hlflanagan@…

<removed confusing text from original comment>

I agree that the use of the word "clear" is ambiguous, and have removed it from the draft.

Printing is only listed in any kind of requirement here (section 3.2) :

  • Graphics may include ASCII art and a more complex form to be defined, such as SVG line art. Color and grayscale will not be accepted; RFCs must correctly display in monochrome to allow for monochrome displays, black-and-white printing, and support for physical and age-related disabilities.

Clear printing was part of the reference of the overall history of the conversation. It is still unclear, even in that part of the document, and so I have removed it.

It does make sense to have a simple requirement that RFCs must be printable in such a way as to retain their basic structure and readability. I do not believe getting in to detailed requirements on page size is appropriate given that such a level of detail impacts requirements for reflowable text as well as removing the general pagination requirement.

I propose to add the following text to section 3.2:

  • At least one Publication format must support readable print to paper.
Last edited 9 years ago by hlflanagan@… (previous) (diff)

comment:5 follow-up: Changed 9 years ago by julian.reschke@…

I do not recall anything close to a "consensus" in favor of requiring pagination. Maybe this is a typo???

comment:6 in reply to: ↑ 5 Changed 9 years ago by hlflanagan@…

Replying to julian.reschke@…:

I do not recall anything close to a "consensus" in favor of requiring pagination. Maybe this is a typo???

Yes, it is. My apologies! I'm going to remove and retype up that entire response, actually. As I've thought more about it, there's more I want to say here.

comment:7 Changed 9 years ago by hlflanagan@…

Some further concern was expressed regarding including an emphasis on paper sizes (A4 vs US). I do not want to get in to paper sizes here, particularly as pagination is deprecated and we rely more on the tools of the end user to print to whatever paper size is appropriate in their region. I think a reasonable compromise here is:

  • At least one Publication format must support readable print to standard paper sizes.

I have adjusted the draft accordingly.

comment:8 Changed 9 years ago by hlflanagan@…

  • Resolution set to fixed
  • Status changed from new to closed

No further comments received; closing ticket.

Note: See TracTickets for help on using tickets.