Chris,
perfectly compatible, but I would not do it like your example:
Content-Type: application/gzip
Content-Uncompressed-Type: application/postscript
but instead like this:
Content-type: application/gzip64 (with headers)
Content-type: application/postscript
Fruit-of-the-day: This belongs to the decoded body part
<tons of random-looking stuff deleted>
Note the position of the blank lines; nothing stops an application
from putting its own data inside the body, instead of cluttering up
the headers of the original message.
(and the content-uncompressed-type would require special handling
in the mime-decoder, while this one can be decoded by a short script
that cat's the headers, pipes the rest through gunzip, and feeds
the resulting gunk straight to a MIME-decoder....actually, I think
one could implement application/gzip64 in about 5 minutes in Metamail...)
The two things are different in style; this is a way to do
compression between "consenting adults", while c-t-e: gzip64 is a way
to state that compression should be supported by "everybody", including
gateways that are able to convert, for instance, MIME PostScript into
X.400 PostScript.
(you know, I changed my opinion of which one I liked better while
rephrasing the above paragraph.....)
Again, we prove that gateways are nasty beasts....
Harald A