[rfc-i] RFC Format - final requirements and next steps

Tim Bray tbray at textuality.com
Mon May 14 12:50:25 PDT 2012


There are a few items in this list that I do *not* support.  Possibly
I’m an outlier, in which case feel free to ignore.  For simplicity,
I’m reproducing the relevant bits of the list.

Draft-Edit, Review (what authors, ADs, and other interested parties
worry about when writing and reviewing an I-D)

    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 (and these are the things that matter, in
the final analysis) have been seriously damaged.  Plus, getting
agreement on technologies and editorial issues around graphics is
hard.

    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.

    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?

End consumption (what consumers of RFC worry about)

    Need to be able to see graphics/images

Nope; see above.

    Want a more flexible line length

Nope; see above.


More information about the rfc-interest mailing list