[rfc-i] RFC Format - final requirements and next steps
Iljitsch van Beijnum
iljitsch at muada.com
Mon May 14 15:27:09 PDT 2012
On 14 May 2012, at 21:50 , Tim Bray wrote:
> Need to be able to include graphics/images
> Do not agree. IETF has done without this for a long time and I haven’t
> heard a single convincing narrative about how usability of specs or
> interoperability of results
I agree with this.
However, non-normative images are allowed now, and forbidding them would be an uphill struggle that I'm willing to forego. So as long as we don't end up in a situation where the text says "see image A for the header layout" I can probably live with this.
> Want broader character encoding for body of document
> I don't think you have consensus for this, except for the special case
> of examples which require larger character repertoires than are
> necessary for the explanatory text.
Also largely agree, with the addition of having non-latin script names and maybe addresses in non-latin script in addition to the latin script transcription.
> Want a more flexible line length
> I don't think this is really a requirement. We want the ability to
> print better, and to use mobiles, but line length specifically?
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.
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
More information about the rfc-interest