[rfc-i] Comment on: draft-crocker-rfc-media-00.txt
dhc2 at dcrocker.net
Fri Sep 26 12:06:45 PDT 2008
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