[rfc-i] Media Format Choices for RFCs

[Dave Crocker]

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:

    http://datatracker.ietf.org/doc/draft-crocker-rfc-media/


> Abstract:
> 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 
diff:

    http://bbiw.net/specifications/draft-crocker-rfc-media-sidebyside.html


In the discussion, I tried to highlight significant differences from the 
braden/klensin proposal:

> 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,
>
> 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:
>
>     <http://bbiw.net/specifications/draft-crocker-email-arch-11-24dc.html>
>
> 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.
>
> d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net