[rfc-i] Big Picture and RFC format
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Thu May 31 09:38:42 PDT 2012
On 5/31/12 9:18 AM, Ole Jacobsen wrote:
> Before we can measure consensus I would like to see a "bigger picture"
> discussion of what it is exactly we are trying to achieve. It has been
> suggested, for example, that "real graphics," (maybe line drawings as
> the ones found in patent applications) are "highly desirable," but I
> have not seen much discussion about this as functional "requirement"
> (and I use that word loosely). Instead, I see a lot of detailed
> technical discussion about HTML, XML and the like, all important
> stuff, but to me these are "engineering details" and not overall
> design and architecture discussions.
I think this is reasonable. I actually started to write down something
along these lines for myself, and I still consider it a work in
progress. I'm still learning new things about how the Series has been
used and could be used.
Here are the notes I have for myself, currently in progress on the RSE
wiki. Is this the kind of information you are looking for?
The RFC Series has been in existence for over 40 years. During much of
that time, the limitations of character set, line and page length, and
graphics restrictions of RFC documents met the most immediate needs of
the majority of authors and readers. As technology changed, new formats
that allowed for a richer set of features when editing, reading,
searching, and displaying documents came in to use and tools were
created to convert the plain ASCII documents in to other desired formats
such as HTML, PDF, and Microsoft Word. While the converted versions of
the RFC are widely available, the canonical display format remains the
plain text, ASCII, line-printer structured one. The canonical source
format is nroff.
Canonical source and display versions of an RFC exists for several reasons:
* to provide verification of the content of a RFC in case
inconsistencies are created when a document is converted to another
format or mirrored to another location
* to verify the final content of a document in cases of legal dispute
* to aid in the conversion of the RFC in to formats requested by the
The very basic format of RFC source and display documents have two
persistent characteristics that are considered by the RFC Series Editor
to be critical to the RFC Series, including:
* persistence (tools to read, edit, and print the documents remain
easily accessible to everyone)
* convertibility (the plain text version is simple to convert to other
That said, the very simple nature of the current display format in
particular introduces a variety of limitations, the list of which has
grown as changes in technology create new expectations:
* ASCII art is considered by some to be a major limitation in
expressing visually-oriented information
* the internationalization of the authorship and the Internet is
introducing characters not possible in plain ASCII
* the more common forms of display (web pages, smaller devices) make
the limitations of page and line length a hindrance to the reading of an RFC
So, the community and the RFC Editor have decided to review the
canonical format of the RFC series and discuss whether it needs to
change to address those limitations and, if change is required, what the
change should look like.
More information about the rfc-interest