[rfc-i] Pagination requirements

Julian Reschke julian.reschke at gmx.de
Tue May 15 10:00:17 PDT 2012

On 2012-05-15 18:40, Martin Rex wrote:
> Iljitsch van Beijnum wrote:
>> Martin Rex wrote:
>>>> Why are page references so much better than section references
>>>> that we need to have pages in the canonical format?
>>> Because there are numerous sections that span multiple pages, and
>>> it is really helpful when you can specify locations in a specification
>>> with reasonable proximity -- and that page-based location information
>>> remains valid across all display devices.
> page-based location information only makes sense if is pre-paginated
> and canonical.

Yes. That's why I believe we should get rid of it.

>> So what you're saying is that it's a good tradeoff for readers
>> of ALL RFCs on ALL devices where the page length and the display
>> length are not identical to be annoyed dozens of times when reading
>> an RFC because they have to navigate across superfluous page boundaries
>> in order to make it easier to accommodate the very occasional situation
>> where someone wants to refer to the middle of a long section that
>> the author couldn't be bothered to break up in subsections?
> 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.
> Do those fancy devices have a requirement for pocket-book printers, or
> are they capable of driving regular printers with DIN A4 or Letter paper
> size?

I don't think anybody who wants to read RFCs on devices like these would 
consider the ability to print them as a good solution.

> Rendering pre-formatted and pre-paginated ASCII (such as existing RFCs)
> smarter on small devices can probably done by a single person in less
> than a week and is close to a no-brainer (but one that is meeting strong
> resistance).  Writing the software to render HTML on a device that

Go ahead.

> does not have that software is a lifetime project.

Can you identify the device you want to use that doesn't display HTML?

> rfcmarkup, the script that produces the HTML display on
> http://tools.ietf.org/html/rfc5280
> knows quite well where page breaks, header&footers are.

Yes. But it sometimes fails for other things, such as understanding what 
a section reference actually refers to. For these things, it's based on 
heuristics. It's done well, but still sometimes it fails.

> If HTML is as versatile as folks claim it to be, why does it take regular
> long discussions, rather than adding the 10 lines of code to rfcmarkup
> that enable small devices to not display the page breaks for folks that
> dislike them?

The page breaks are just one problem; reflowing paragraphs is the next 
one (the software needs to understand the difference between artwork, 
tables, lists and plain paragraphs, rfcmarkup does not do that).

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


>> 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".

Indeed. That's an argument for a usable anchor points inside the 
document, not necessarily page boundaries. For instance, rfc2629.xslt 
generates an anchor for each paragraph.

> Usually, when implementing an RFC, I do just the same: quote the lines
> relevant to a block of code from the RFC into a comment of the code
> and include an direct URL to that part of the RFC.


> RFCs specify data and functions in abstract fashion, program source code
> specify a particular implementation.  If the RFC can not get along with
> plain ASCII, then it is probably not a technical specification that
> others want to implement, but rather demo/marketing/sales material.

OMG. Did you ignore the whole requirements discussion?

Did you ever have to write/review/implement a document that deals with I18N?

> Do we need a third demo/marketing/sales track for IETF documents?


>> And although deep study or review of an RFC or draft may happen using
>> a hardcopy,
> That is what I usually do when implementing a larger spec for the
> first time.  I print it out, read through the document 2-3 times,
> paging back and forth and marking all parts relevant for the initial
> implementation, and then start implementing and copy&pasting snippets
> of the online RFC into comment lines in front of code blocks or
> functions/modules.
> Doing this for current RFCs is easy and fast.
> Doing the same for ISO-specification (e.g. X.509) is a royal PITA,
> because of the PDF format with 100+ chars line lengths and ripple
> left margin.

Use an editor that can reformat.

> Discussing paragraphs from ISO-specs is also a royal PITA because of
> the difficulty of quoting the stuff in plain text EMail and because
> I can not include functioning URLs that will position mail recipients
> at the exact location of the spec with a single mouse-click.


> PDF is nice for printing and archival, but significantly lacks
> in comparison to the rfcmarkup that is available on tools.ietf.org.

PDF can have the same type of link targets, they are just harder to 
discover. rfc2629toFo.xslt generates them.

> Being able to convert an RFC into some format that I might personally prefer
> with fairly simple scripts is a temendous advantage, as demonstrated by
> the rfcmarkup and 2-column document diff display on tools.ietf.org.

That argues for a format that can be transformed to plain text 
(something I would agree with), but not necessarily for the format 
*being* plain text.

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


You seem to be on a vendetta against XML parsers and browsers. I don't 
think that's helpful.

>> I think most referrals will be followed in electronic form,
>> preferably through a hyperlink. In that case, page numbers aren't the
>> most obvious mechanism.
> Only if the page-numbers are based on canonical pre-pagination.
> Table of contents are normally part of the document, and they would
> be pretty useless without canonical pre-pagination.

They are useful without pagination as well.

>> Perhaps an example of where the omission of page numbers would
>> be problematic would help.
> 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?

If it doesn't, then, for instance, the page numbers in the TOC and the 
index become less useful.

Best regards, Julian

More information about the rfc-interest mailing list