[rfc-i] Pagination and some other stuff
Iljitsch van Beijnum
iljitsch at muada.com
Wed Mar 28 05:44:22 PDT 2012
The pagination question is very important. Even more so than creating the required line length, coming up with the pagination in drafts is problematic. Tools commonly used today simply don't output in this format, and it's hard to create it manually, too.
Now that would be one thing if it's useful for people who want to read drafts and RFCs, but I'm afraid that's rarely the case. 55-line pages don't fit well on screens (large and small alike, although more of an issue on small ones) or on European paper sizes.
However, if we want to get rid of pagination we need to be able to live without page number references. Are we prepared for that? Obviously a ToC can be generated for the PDF versions (yes, multiple: one for each common paper size), but otherwise they can't be used anymore. Someone mentioned paragraph numbers for referencing stuff, but I'm not sure that would work well. In practice today we use a section number or quote the offending text, which seems to work well enough. But I could be mistaken.
After thinking a bit more about the various issues, it occurs to me that pretty much all complaints about how RFCs look can be addressed by people getting the appropriate alternative format, and thus don't seem sufficient to change the main format.
I'll be very happy to see an ePub version along with text/HTML/PDF, and we may want to come up with a canonical HTML version, as well as make the alternative versions more prominent on the IETF and RFC Editor websites.
The RFC format has been tightened a lot in recent years and we have more tools, so we can derive alternative formats pretty reliably from recent RFCs these days, and any change isn't going to address the old ones anyway. And although not as easy to work with as it once was, the RFC format is still very accessible and there are no signs of this changing anytime soon. So no reason to make changes for archival purposes, either.
So then there are difficulties in writing drafts, non-Latin characters, images and equations. Equations can also be represented in text so I'm not even sure if there's a real problem, or otherwise as images so they reduce to the image problem. Non-authoritative images are already possible, and making images authoritative seems problematic. This option isn't used a lot, and a large part of ASCII art is header diagrams which aren't too hard to draw and could be prettyfied into image form algorithmically. So not sure we have a problem here, either.
We need to be really careful with non-Latin characters as they are not universally understood by the community. (My first name is from Russian and my last name is Dutch. So my name should really be written as Ильи́ч van Beĳnum (note the ĳ). Can you type that?) But we can either make non-authoritative versions that have them or allow limited amounts of UTF-8 in RFCs without breaking much, if anything.
So apart from the minor issue of whether to allow UTF-8, it seems to me that it all boils down to the question of whether _writing_ RFCs is so difficult that we need to improve the input format, and/or whether the conversions between the different formats are problematic enough that we need to streamline this process by requiring better meta data in the authoritative format.
More information about the rfc-interest