Content-Type: application/gzip
Content-Uncompressed-Type: application/postscript
Where "Content-Uncompressed-Type" is identical in structure to
Content-Type, except that types "multipart" and "message" are
forbidden.
This is fully compatible, and it shouldn't be too difficult to add
intelligent support (just pass the CUT header to the CT header parser
after a gunzip phase). It also recognizes the fact that a receiver
may wish to remove the base64 encoding without removing the
compression.
Actually, if you want plug-n-play compatibility with metamail,
you want to make the uncompressed type a parameter to the
application/gzip content type. Thus:
Content-Type: application/gzip;
uncompressed-type="text/plain; charset=us-ascii"
Then the display module for application/gzip can pass the uncompressed object
and its real type back to metamail for display. (there is already support in
metamail and similar systems to pass content-type parameters; adding a new
header would require support for a new header which is specific to a
particular content-type).
This scheme does have some drawbacks when compared with a new c-t-e. For
example, it's more difficult to support multipart/alternative properly.
Keith