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

Marc Blanchet marc.blanchet at viagenie.ca
Fri Feb 15 07:36:54 PST 2013

Le 2013-02-15 à 10:00, RJ Atkinson a écrit :

> Heather,
>  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.  

I disagree. I agree that we need a way for many people to refer to the same place in a document. But pagination is not the only way to do that, and introduces more problems. Some other ways are:
a) refer to sections and paragraphs
b) like other SDOs do, add line numbers to each line. 

I'm just fine with a). b) is also useful and interesting.

>  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).
> Yours,
> Ran Atkinson
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list