[rfc-i] v3imp #5 Tag figs with filenames, Internet message data

Sean Leonard dev+ietf at seantek.com
Fri Jan 23 01:05:16 PST 2015

Improvement Need
#5 Tag figs with filenames, Internet message data

This improvement calls for tagging figs with filenames and Internet 
message data. The term "figs" is meant to include <figure> as well as 
other non-spec-text data, including what is currently encompassed by 

I note that <sourcecode> is a stab in the right direction.

Many standards include figures that are better operated upon as files, 
such as ASN.1 modules or Python source code. A big problem historically 
has been that these data have been split apart by pagination and spacing 
artifacts. When stitching them back together, transformation 
(copy-and-paste type) errors have occurred with bad results.

It makes sense to tag this data with filenames, so that users of the 
standard can extract the file information as-is and operate upon it.

For that matter, I also want to be able to tag a figure or blob of code 
with a media type (*and* parameters--yes, we need parameters). Calling 
something "foo.js" is one thing; labeling it as "application/javascript" 
or "application/json" is more well-defined.

The most comprehensive thing desired is to tag a figure or blob of code 
as an Internet message, with headers and a body. By doing this, it is 
trivial to tack on "Content-Type: application/javascript; 
charset=iso-8859-1" and "Content-Disposition: attachment; 
filename=foo.js" at the top of the figure or blob.

Here are some sketches of ways to do it:
MIME data:
1. <content> or <msg> element = complete MIME content (Internet message 
2. <content> element, with attributes @content-type, 
@content-disposition, etc.; the inner text is the body of the content

3. <file> element, with @name or @filename, and @src. If @name/@filename 
is not present, the filename in @src is used as the filename.

(See the upcoming #6 for byte preservation issues.)


More information about the rfc-interest mailing list