Adam M. Costello wrote:
And it's a bit gross to have to define N*M transfer
encodings to support N escape mechanisms (quoted-printable, base64,
escaped-8bit) and M compression schemes (gzip, deflate, bzip2, ...).
It's actually worse than that; there are other transformations
unrelated to transport transparency that one might perform on
content. E.g. encryption (more about that below). If all such
transformations *must* be bundled into CTE for the sake of old
clients, the combinatorial explosion will be tremendous. Something
will have to give; either there will be a need for a large number
of CTEs in contradiction to RFC 2045, or the mechanism will have
to be adapted, or the current plethora of ad-hoc approaches will
worsen.
Here's a way to separate the compression from the escaping in a
backward-compatible way. I don't claim that this is the best way, but
it's something to consider.
Content-Type: encoded/gzip
Content-Decoded-Type: application/postscript
Content-Disposition: attachment; filename="foo.ps.gz"
Content-Transfer-Encoding: escaped-8bit
Well, there's already application/vnd.ms-tnef and
application/mac-binhex40; of course that hides the media
type of what has been compressed. An approach along the
lines of RFC 2633 could be used, with suitable definitions
for application/gzip, application/deflate, etc.
Another approach would be to introduce structure into the
transfer-encoding, and recommend that transport agents ignore all but
the last component:
Content-Type: application/postscript
Content-Disposition: attachment; filename="foo.ps"
Content-Transfer-Encoding: gzip|escaped-8bit
List syntax might be a cleaner fit to existing paradigms, and
of course that would in any event be a different type of
Content-Transfer-Encoding field, which in turn would
necessitate a newer MIME-Version.
Yet another approach would be something similar to the way
signing and encrypting transformations are applied per RFC
1847, viz. via a multipart encapsulation. So, following the
RFC 1847 model, with the appropriate media type definitions
one could have:
Content-Type: multipart/compressed ; method=application/gzip ; boundary=foo
Content-Transfer-Encoding: escaped-8bit
--foo
Content-Type: application/gzip
Content-Disposition: attachment ; filename="foo.ps.gz"
Control information for application/gzip
--foo
Content-Type: application/octet-stream
[compressed]Content-Type: application/postscript
Content-Disposition: attachment ; filename="foo.ps"
%!blah[end of compressed data]
--foo--
That would allow the recipient's UA to present a choice of
saving in compressed or uncompressed format (if the
compression method is recognized!). It would also allow
flexibility in composition, e.g.
compress | encrypt | sign
or
encrypt | sign | compress
etc. I'd expect old client software to work pretty much
as it works with RFC 1847 signed/encrypted multiparts, i.e.
since the multipart/compressed isn't recognized, it's treated
as multipart/mixed and the unrecognized application/gzip
would be treated as application/octet-stream. If there
will never be a need for control information for any
compression method, that could be simplified to a 1-part
"multipart" wrapper around the application/compression-method
type.