[rfc-i] Comment on: draft-crocker-rfc-media-00.txt

[Dave CROCKER]

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