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

Iljitsch van Beijnum iljitsch at muada.com
Sun May 13 06:15:27 PDT 2012


On 11 May 2012, at 18:50 , Heather Flanagan (RFC Series Editor) wrote:

> Thanks to the feedback from the community, I've modified the 
> requirements for the format of RFCs (which ties in I-D format 
> as well, though any actual change to I-D format is outside my 
> purview).

This is by no means meant to suggest you are doing a bad job, but:

I find it very strange that apparently the RFC Editor has been given authority to unilaterally decide on a new RFC format. Writing RFCs is the core business of the IETF. As such, the way I see it, the format of RFCs must be decided upon through the usual IETF decision making mechanism.

> http://www.rfc-editor.org/rse/wiki/doku.php?id=formatreq
> (point of order - is it better for me to include a link as above, 
> or copy the list in to the email?)

Put it in a message, that way it's in the archives.

As to the contents:

	• Need to be able to include graphics/images

I disagree. No need has been demonstrated and although currently allowed, this isn't done much today. But obviously it is a "want" for many people.

	• Want to be able to include equations

Disagree again. Equations can be expressed in code form. This is much more appropriate as guidance for implementers than traditional mathematical notation, which defies copy/paste.

	• Want a publicly available “official” conversion tool (same source file producing the same output between I-D submission and RFC editing step)

This assumes conversion is necessary. I would hope that is not the case.

	• Need a long-lived file format with an open specification, i.e., such that the community can continue to support it even if commercial support disappears

Yes, but not just open, also so simple that anyone could conceivably write a program to parse or display the file. (E.g., PDF is open but way too complex to work on using home grown tools.)

	• Need to be able to see graphics/images

I don't understand. Not everyone has the capability to see graphics or images at all times. Such a capability shouldn't be required to implement an RFC. (This doesn't mean that graphics can't be part of an RFC or even be an important part, just that information in the graphics is also in the text.)

	• Want to have neat printing (intelligent pagination)

Not sure what this means. In my opinion, RFCs shouldn't have built-in pagination, this should be solely an aspect of the printed form of an RFC. This means references by page number can no longer be supported.

Two other points for end consumption:

- Want that the native format of RFCs be rendered in a usable way on common computing  devices without the need to install additional software.

- Want that the native format of RFCs be rendered in a usable way on e-book reader type of devices.


More information about the rfc-interest mailing list