[rfc-i] Media Format Choices for RFCs
dhc at dcrocker.net
Sat Mar 24 23:53:30 PDT 2012
Since there is some recycling of proposals going on, I thought it worth citing
the one I produced several years ago, when all this was last visited:
> Documents in the RFC series normally use only plain-text ASCII characters and
> a fixed-width font. However, there is sometimes a need to supplement the
> ASCII text with graphics or picture images. The historic solution to this
> requirement, allowing secondary PDF and Postscript files, is seldom used
> because it is awkward for authors and publisher. This memo suggests a more
> convenient scheme for attaching authoritative diagrams, illustrations, or
> other graphics to RFCs. It further proposes conventions for additional input
> and display formats, to improve readability. This proposal is based on
> draft-rfc-image-files-00, by Braden and Klensin, and revises it as little as
> possible, while expanding the goals of the effort.
To permit an audit of the differences from the braden/klensin proposal, I save a
In the discussion, I tried to highlight significant differences from the
> fc-i] Comment on: draft-crocker-rfc-media-00.txt
> Dave CROCKER dhc2 at dcrocker.net
> Fri Sep 26 12:06:45 PDT 2008
> Previous message: [rfc-i] Comment on: draft-crocker-rfc-media-00.txt
> Next message: [rfc-i] Comment on: draft-crocker-rfc-media-00.txt
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Bob Braden wrote:
>> At 07:22 PM 9/24/2008, Dave CROCKER wrote:
>> Your most significant change seems to be to allow multiple image files per
>> RFC. We thought about this, and rejected it as too complicated, and too
>> confusing, for the possible gain. Can you cite a case where you think it
>> would be important?
> Let's start a real-world example of its already being done. Please ake a look at
> the recent html version of my email-arch draft that is under development:
> I added true graphics to the existing ascii-art. And the handling of figures
> uses off-the-shelf xml2rfc.
> So let me stress:
> My proposal derives from existing practice with xml2rfc. I only offer some
> conventions for naming the files that hold external figures, in order to have
> the related files easily associated with the master file.
> (I should comment that xml2rfc produces html with the spiffy characteristic of
> reverting to the provided ascii art, if the external file is not found.)
> Further, the convention of having one figure per file, rather than multiple per
> file, shows up regularly, such as the output of html by MS Office and (if I'm
> interpreting the file properly, OpenOffice) as well as being what html does.
> Hence, what your proposal does is to seek to invent yet-another multiplexing
> technique. In this case, it is one which forces figures to be separate from the
> text that refers to them, rather than permitting in-line mixing.
> In summary, the enhancements that my draft proposes to yours are:
> 1. Adding the option of having the master file be in xml2rfc which then
> automatically produces alternative formats, such as txt, html and pdf.
> 2. Specifying external figures, etc., as one-per-file
> 3. Enhancing your naming convention to a) support these multiple files in
> a coherent fashion, and b) make the names of the files related to the name of
> the master file.
> To the extent that there is a desire to aggregate multiple figures into a single
> unit, there are established techniques for this, such as putting them into a
> sub-file or using zip.
> While I understand Paul's suggestion to be to permit arbitrary URLs inside
> classic, ascii master files, my proposal is based on the view that jumping into
> multi-media forms warrants a) jumping more extensively, b) using existing
> practices and even existing tools, but c) constraining naming to facilitate
> aggregating related files. So I'd class the figure-handling mechanism as
> sharing the spirit of his, but with meaningful differences.
More information about the rfc-interest