[rfc-i] Problems and requirements for RFC Format
hallam at gmail.com
Sun Apr 22 11:46:37 PDT 2012
I think there are many reasons that we have to edit using something
close to the final format.
If we edit a document in a crappy format that means
1) The reviews will be substandard. No, I do not do my best work
reading documents that look like nobody cares about my time or effort.
2) The reviews will be of a different document to the one that is
published. Change the format and people are going to see the issues
that were hidden by bad formatting.
3) There will now be two document formats to support.
Typography is an art form that is designed to improve comprehension.
Publishing drafts or any document for review in a sub-standard format
is an insult to the people who are being asked to commit their time to
There is a good reason that the Web beat Gopher, the Web looked good
and was easy to use and Gopher did not.
It might well make sense to have a different style sheet for drafts
and RFCs. Easy enough to do. Print the headers in one colour for draft
and another for RFC. But otherwise they should be as close as
On Sun, Apr 22, 2012 at 2:27 PM, Heather Flanagan (RFC Series Editor)
<rse at rfc-editor.org> wrote:
> On 4/22/12 6:02 AM, Peter Koch wrote:
>> On Tue, Apr 17, 2012 at 03:11:26PM -0700, Tim Bray wrote:
>>> I observe that several of your baskets include
>>> " * Need to be able to include complex graphics/equations"
>>> I think it may not be accurate to conflate these two.
>>> think it is actively beneficial to force authors to describe protocols
>>> in clear English without recourse to pictures.
>> and +1;
>> Also, the lists provided for discussion tend to favor change based on
>> the, naturally biased, discussion on this list. I, for one, am not
>> convinced we need anything but i18n, where the most compelling argument
>> for that IMHO is the already mentioned capability to provide examples
>> for protocols that use non-ASCII characters.
>> I am also further confused why the lists contained items for internet-drafts,
>> since those are solely IETF business.
> Because while the I-D format is definitely an IETF decision, if I choose
> something for the final published RFC that ends up requiring a great
> deal of conversion from the I-D to the published document, the IETF and
> the RFC Editor needs to understand and accept that work.
> Does that help?
> -Heather Flanagan
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest