[rfc-i] RFC Format - final requirements and next steps

Iljitsch van Beijnum iljitsch at muada.com
Tue May 15 01:10:47 PDT 2012

On 15 May 2012, at 8:13 , Brian E Carpenter wrote:

>> I read this as the need to make the new format display reasonably well on a variety of screen sizes. On many ebook reading devices and especially cell phones the text has to be rendered excessively small if the line length is 72 characters. Allowing regular text to be rewrapped solves this without any downsides as far as I can tell.

> Wrapping ASCII art and fixed-width tables doesn't work, so this can
> only be met by having at least some residual markup in the format.

What I imagine (which doesn't mean this needs to be the end result, just that there are currently wide spread technologies that support this that we may take advantage of) is an HTML-based format where the most basic version of a a diagram (= the ASCII art one) is included in the file itself, and tagged such that it is displayed with an appropriate font without breaking lines. But depending on the CSS file selected by the user, alternative versions of the diagram, which could be resources not included in the HTML RFC file, are displayed instead.

For tables we could include two versions in the HTML, one formatted as a table that is displayed when the display is wide enough, and one formatted as a list that is displayed when the display is too narrow.

>> Page length is a similar issue but not nearly as problematic, because jumping over some headers/footers is annoying, but doesn't get in the way of readability

> Indeed. And since we allow internal page references, getting rid of
> page numbers is not an option.

I disagree. With a hyperlink-enabled format we can link from the table of contents or references in the text directly to (sub-) sections or anything that has a name, really (diagrams, tables, etc) without the need to have page numbers as a layer of indirection. Only when an RFC is printed or rendered in a format that doesn't support hyperlinks are page numbers necessary.

However, if people really want to keep them, it's easy enough in an HTML or similar format to conditionally display headers and footers, so the people who don't want to see them don't have to.

> It seems to me that due to this and the previous point (rewrapping
> text but not figures and tables), it's inevitable that *in any case*
> there needs to be a specially post-processed version for mobiles.

I would really, really like it if I could load an RFC in RFCng format on any smartphone, ebook reader or computer without any special software installed and it would at least display the text part of an RFC in a way that is easy to read, i.e., with lines that have no more than about 12 words or however many words fit on the display on them.

If in addition to that, special versions exist, that is fine of course, but it won't always be easy to load such versions quickly, so they don't remove the need / strong desire for reading the native RFC format on constrained devices.

> I find pagination useful when I need to study a document in close
> detail, for which purpose a hard copy in "booklet" format is
> generally better than reading it on a screen. In contrast,
> on-screen, pagination is just a nuisance.

It seems that we are in agreement, then. I'm not sure if HTML/CSS can be made to print with the headers and footers we like, but unlike having a separate version formatted for mobile devices I don't think having separate PDF versions for printing would be too big a deal, and one nice thing would be to have a few of them, like one for A4 paper and one for whatever it is that people use where A4 isn't available. Someone might even go crazy and produce a two column version for printing...

More information about the rfc-interest mailing list