[rfc-i] Pagination requirements

Iljitsch van Beijnum iljitsch at muada.com
Tue May 15 10:07:14 PDT 2012


On 15 May 2012, at 18:40 , Martin Rex wrote:

> The discussion seems to circle around braindead software on small devices.
> There is no requirement for the software that visualizes RFCs on small
> devices to waste most of their fingernail screen real estate with a
> representation of the pre-pagination page breaks.  It would be trivial
> to not display them at all.

That is true. However, in my opinion it would be better to explicitly make page numbers a local matter.

> Writing the software to render HTML on a device that
> does not have that software is a lifetime project.

Implementing a modern browser, yes. But a simple subset of HTML, certainly not.

>> I would argue that if the desire arises to refer to text that doesn't
>> start very soon after a section header, the author has done a bad job.

> You're calling for a 20-page size limit for specifications.

No, I'm calling for a 0.5-page size average for (sub-) sections.

>> I would also think that referring to text is only necessary when
>> it's too long to quote,

> Nope, I prefer to limit quotes to what I believe matters -- but for
> fairness I would like to include an URL that puts the quoted information
> directly on-screen when clicked and enables others to check the vincinity
> of the quoted text to see whether that quotation is "out of context".

A page number is not really better than a section reference in this regard.

> Being able to convert an RFC into some format that I might personally prefer
> with fairly simple scripts is a temendous advantage

Agree. Wouldn't this be easier without possible page number based references to worry about?

> A complex document format like XML or HTML is a dead end road, to get
> from there to other places, it always requires significant familarity with
> the underlying data format, multi-megabytes software and moderately sized
> software projects rather than an all-nighter with no prior knowledge
> about the document format.

What I would like to see is an HTML-based format where stripping out the HTML tags leaves a usable text document. But once again, some simple HTML parsing is not a big deal, so writing a script to scrape certain information from RFCs shouldn't be harder than today, where this largely needs to happen based on location on the page.

Implementing a program that displays HTML-based RFCs should also be significantly easier than creating a full CSS implementation by mapping the class and id tags directly to some output behavior rather than interpreting the CSS.

> Table of contents are normally part of the document, and they would
> be pretty useless without canonical pre-pagination.

I don't see that. If we both print an RFC, for the purposes of using the table of contents, does it matter to me that on your copy section 6.1.3 starts on page 23 while on my copy it starts on page 26?

> There is no requirement that the software you use for reading RFCs
> visualizes the original pre-pagination, headers&footers.  Maybe you're
> simply using the wrong software?

The current format doesn't allow for easy hiding of the headers, footers and page breaks.


More information about the rfc-interest mailing list