[rfc-i] Thinking about HTML, was: Re: graphics support

Iljitsch van Beijnum iljitsch at muada.com
Sat Apr 21 03:27:20 PDT 2012

On 21 Apr 2012, at 4:01 , Paul E. Jones wrote:

> Still, I had fairly good success with even that proprietary format.  Use an
> open format and keep texts in a current open format and you should be fine.

Yes, these things are doable. Still, with many thousands of documents to convert even minor issues get amplified, and something that is easy for a few dozen of your own documents can be much harder for thousands of RFCs where the placement of every + in ASCII art counts.

> In any case, where does all of this stand?  I saw the requirements list.  I
> think HTML came close to meeting almost everything, if not everything.  HTML
> is pretty much the only way I read RFCs or I-Ds today, anyway.  I'd say we
> go in that direction.  We would not have to support images and equations on
> day 1; we always have the old ASCII approach, even with HTML.

Right. I'm with you that HTML is probably the best way forward. Because it's so versatile it will let us mark up metadata just like the XML2RFC format, but it will also natively display on pretty much anything and if we carefully limit ourselves to a subset of the features it's only slightly harder to process using homegrown tools and even existing text based tools can be made to work for the most part.

What I'm imagining is that an RFCng would have three stages, like a rocket. The first stage is the text stage, which would be pretty much what we have now with UTF-8 to allow for "real" names in addition to ASCII-only ones (not a replacement for those) and for examples and specifications where non-ASCII characters are relevant. ASCII art is still welcome here, probably marked as such so it can be displayed using an appropriate font (maybe even commission one?) with tight spacing so it looks much better than today. There would be a standard (included) stylesheet that displays most RFCs reasonably well on most systems, with the ability to load user selected stylesheets easily to adjust things like text size, line width and colors to the user's preference.

The second stage adds bitmaps in a simple and open format like PNG. Here we lose the ability to scrape text, but bitmaps are easy and unambiguous to display and edit and as such we can assume the ability to round trip from published RFC back to a wg for editing and then be part of a new RFC. We'd have to see if it makes sense to make the bitmaps part of the normative text, or require that the stage 1 text can stand on its own and the bitmaps are only a non-normative addition. Much better looking bitmap versions can be made for ASCII drawings and presumably the wg and/or RFC editor can check whether the two are semantically identical.

The third stage adds vector graphics. These can't be assumed to be round-tripable and in theory (in practice it won't be so bad) displaying them at different sizes can lead to different results so these are certainly non-normative but will look good if the authors are capable in this area. Also, depending on the format, some text scraping ability may exist. Apparently SVG is popular for vector images, but EPS and/or PDF may also be good choices.

Then, if a system needs to display an RFC, for every image or drawing, it selects the best version or the best normative version (whichever the user prefers) that is available for any image or drawing, and displays that version inline with the text at the right place. This can probably be done with CSS, but if not, with a small amount of javascript. Although I don't like the idea of javascript or other executable code in RFCs, if this is some standard boilerplate code that is the same in all RFCs and you still get good output without javascript support, I can live with it.

As far as I'm concerned equations are images in this system, although stage three may support a couple of formats specifically for displaying equations in all their glory.

More information about the rfc-interest mailing list