[rfc-i] RFC Format - final requirements and next steps
Brian E Carpenter
brian.e.carpenter at gmail.com
Mon May 14 23:13:18 PDT 2012
On 2012-05-14 23:27, Iljitsch van Beijnum wrote:
> 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.
IMHO, the goal of RFCs is effective use by technical specialists,
not looking pretty and modern.
I think the evidence is that only a tiny minority of RFCs are unfit for
purpose due to the lack of generic graphics and/or mixed fonts and character
sets. Otherwise, there would be many cases where the PostScript/PDF exception
had been used, and the IETF would have allowed this for normative
>> 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.
Yes, which is the case for allowing restricted use of Unicode.
>> 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.
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.
> 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.
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.
More information about the rfc-interest