Re: Source Format of RFCs

[Keith Moore <moore at cs.utk.edu>]

> A number of RFC's and drafts, such the ones regarding BGP, suffer negatively 
> from the text-only format. It would be nicer to have a richer format, 
> especially since such documents rarely originate in the text-only format, 
> but are rendered into that format by MS-Word, nroff, LaTeX or whatever.
> 
> Would it be asking too much for all RFC's too made available in some sort 
> of rich format, and in particular their source format since that doesn't 
> require additional work?

You may be asking for far more than you realize.

I agree with you that the ASCII-only RFC format is a bit restrictive.
However, ASCII is amazingly flexible.  It is one of the few formats 
that can be reasonably viewed (or searched) on any computer, and
printed on any printer.  Neither of these is true of the document 
formats associated with common word processors.  Also, since it is 
so simple, ASCII is a good choice for formatting documents that may 
need to be readable for many decades.  For comparison, word processor 
documents from the early 1980s are difficult to read today, and
it's not difficult to imagine that today's word processor documents
will be difficult to read ten or twenty years from now.

(The more complex the document format, the less interoperable it is.
There have been problems with PostScript RFCs because some tools
produce PostScript that cannot be printed on some printers.
Similarly, version X of FooWord may produce documents that cannot
be read by version Y of FooWord.)

There are also problems with making RFCs available in multiple formats.
One is that the RFC Editor and Internet-Drafts folks would then need
to deal with a wider variety of tools.  Another is that multiple formats
can make it more difficult to keep the various formats in sync.
For instance the RFC Editor generally needs to be able to make minor 
changes to a document before publication, yet may not have the 
tools neded to modify the "source" document.  If the author is asked
to make the changes, there is then a need to make sure that the
author does not make other modifications to the work after it has 
been reviewed and approved by a working group and IESG.  Again, 
this generally requires special tools.

Until a new format can supplant ascii text for all intents and purposes,
there will continue to be a need to produce ascii text versions of RFCs.
Many word processors do a very poor job of producing "RFC ASCII"
(with margins that allow printing on both A4 and US-Letter paper, 
no overprinting, and so forth)  Documents written for a wysiwyg 
word processor are often difficult to read as ASCII, e.g. because 
the word processor will try to put too many words on a line, or too
many characters in a column of a table. (I've seen various versions 
of this while reviewing RFCs for IESG.)

Then there is a need to make sure that new RFC formats are adequately
supported by all of the RFC and internet-drafts mirrors.

For some time I have been interested in exploring the use of HTML
for RFCs and Internet-Drafts.  This would provide several advantages,
including multifont and multi-faced text in a variety of sizes,
hyperlinks, images, and ease of generation with many word processors.
HTML is openly published and widely-used, and (provided a few restrictions
are observed) one of the few formats which can be read on every platform 
(and is easily converted to plain text).

However, as far as I can tell, there are several barriers to adoption 
of HTML as an RFC format:

0. Given that not all features of HTML are available on all HTML viewers,
   We need some (perhaps loose) standards for which features can be
   used, and which ones should be avoided.    (For example, the use of
   tables for formatting, or embedded images for bullets, should perhaps 
   not be allowed.  Even the use of CSS might be questionable since
   many viewers do not support it.) The standard would need to specify 
   things like which HTML tags could be used, the naming convention to
   be used for files, the format of links to other RFCs and to embedded 
   images (presumably relative rather than absolute), and "style" - 
   how a document should be formatted if it wants to look like an RFC
   (e.g. which tag should you use for a section header?).

1. Once an "RFCs in HTML" standard were adopted, common word processors 
   might be unable to produce HTML which conformed to the standard.
   It might turn out to be even more difficult to produce reasonable 
   HTML than it currently is to produce reasonable plain text.

2. The Internet-drafts and RFC Editor people would need tools to let
   them edit HTML, remove or alter tags that did not conform to the
   standard, and perhaps to convert HTML to "RFC format" ASCII text.
   (again, such tools would need to work with the garbage HTML that
   is generated by some word processors)

3. The mirror sites would have to adapt to accomodate HTML RFCs, 
   including any embedded images referenced by those RFCs.

...and there are probably a few more.  None of these is insurmountable,
but so far there has been a lack of critical mass behind the effort.

A year or two ago I set up a discussion list for rfcs-in-html.
To subscribe, send mail to rfcs-in-html-REQUEST at cs.utk.edu.

Keith