Re: IETF review of AS1

["Carl Hage" <carl@xxxxxxxxx>]

From:           	Terry Harding <tharding@xxxxxxxxxxxxxxxxxxx>
Date sent:      	Fri, 3 Nov 2000 13:46:22 -0700

> 5.4.1, last paragraph. This is the biggie. Saying it is OK to use
> content-encoding in email even as an option just isn't acceptable.

Seems like "Content-Encoding" is a resonable extension, but...

> 4 - add a name value pair to the content-type line
> ex: Content-Type: application/xml; encoding=gzip
> or  Content-Type: applicatoin/xml; conversion= gzip.

This wouldn't be backwards-compatible (has the same problem). 
However, it seems like the other way around, as you mention, makes 
sense as it can work with existing MIME software.

I believe, the best backwards-compatible solution would be to define a 
new (standards track) discrete-type extension-token, "encoded",
with subtypes registered for the different encodings, e.g. "gzip". A
required parameter for encoded/gzip would be "encoded-type",
which is the replacement "type/subtype" for the Content-Type before 
encoding.

     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token

[Note the word "Encoded" is more general than "Compress", and 
matches the nomenclature of "Content-Encoding".]

Since it's impractical to include parameters within the
Encoded-Type="string", the semantics is that an application 
processing "encoded/gzip" will strip off a "encoded-type" parameter,
then decode the binary data and pass it to a MIME application with 
encoded-type used for Content-Type and the remaining parameters
appended.

Example:

Content-Type: encoded/gzip; encoded-type=text/xml;
         schema="http://www.w3.org/xml/schema/EDI-HL7";

(Test software can use:
Content-Type: x-encoded/gzip; encoded-type=text/xml;
         schema="http://www.w3.org/xml/schema/EDI-HL7";)

An old MIME program would handle "encoded/gzip" like 
application/octet-stream, and typically would allow definition of
a processing application for "encoding/gzip" to be some GUI
that can uncompress and save the data. It makes more sense than
"application/gzip".

A new MIME processor would know that "encoded/XXXX" can be used
as a piped filter, automatically post-processing the output of the XXXX 
filter and passed to the MIME handler for "encoding-type".

In the above example, the "schema" is a hypothetical parameter 
passed to the xml MIME processor. Of course, it might make more 
sense to use "xml/edi-hl7" instead. (Or whatever content-type is used-- 
not the issue here.)

Does this make sense to y'all?


--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086