[rfc-i] Representation flexibility

Iljitsch van Beijnum iljitsch at muada.com
Sun Jun 17 05:55:04 PDT 2012

There is an important aspect to the choice of format that we haven't discussed explicitly, although it has come up indirectly.

For lack of better terminology (that I'm aware of), I'll call this the representation flexibility. With PDF, there is almost none of this, the format exactly describes what the output must look like. Formatted ASCII used to be similar, but over the years implementations have diverged, with many no longer implementing the form feed character and some having trouble with monospace fonts. HTML has traveled in the opposite direction. It used to be that the same HTML file would be rendered vastly different by different implementations, but with the tightening of the specification, the efforts of designers to impose the look they desire and less popular browsers copying market leaders now it's possible to make the same HTML file look very close on different implementations, although this involves user-hostile actions such as overruling window and font sizes.

Now on the one hand it's good to be inflexible, so that everyone sees the exact same thing when opening an RFC. (Also see the page number discussion.) On the other hand, flexibility is desirable, so the representation of the RFC can match the capabilities of the output device as well as user preferences.

My thinking: we can probably trust implementations to render text appropriately without imposing any limitations. I'm somewhat worried about ASCII art, though. When rendered well with an appropriate font, ASCII art can work reasonably well, but in practice, it doesn't always work out that way. Perhaps it would be best to sidestep the issue and make a pre-rendered bitmap version available.

As for bitmaps, the main issue there is inadvertent scaling. So as long as our images can survive that, we should be in good shape, especially if we constrain the size of bitmaps so they're readable on a display size that we agree is a reasonable minimum.

Vector images: I've seen many issues with these, and a big problem is that the complexity (and thus size and display speed) of the images is unbounded. Solution: require a pre-rendered bitmap. I would also be in favor of making the bitmap version the canonical version.

Considering the above, I think a conservative subset of HTML could meet our needs. I'm not sure about XML and SGML, I'm too unfamiliar with the way those formats are rendered. Unformatted ASCII is out, as it is typically rendered without automatic word wrap. Formatted ASCII can work to some degree (as we all know) but isn't entirely unproblematic and imposes rigidity that prevents it from working well on smaller (but not necessarily excessively small) displays. The same for "regular" PDF. I haven't seen reflowable PDF, unsure if this is widely implemented.

More information about the rfc-interest mailing list