[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"
marc.blanchet at viagenie.ca
Fri Feb 15 07:36:54 PST 2013
Le 2013-02-15 à 10:00, RJ Atkinson a écrit :
> 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).
> Ran Atkinson
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest