It was an explicit design decision to NOT allow multiple layers
of encoding in MIME, in the name of simplicity. (It was also
an explicit decision to require standardization of new c-t-e's,
because the definition of new c-t-e's will decrease interoperability.)
This is the best decision made when makeing MIME, IMHO. For
complete interoperability, you can't assume that every system can
do a pipe to a process. Plus, if you allowed a chain of encodings,
compressions, encryptions, colorizings, etc you'd have to deal
with a way to specify the order that things get encrypted,
compressed, encoded, colorized, etc.
Even though "gzip64" seems inelegant, it is a better "fit" into
MIME than trying to define a new mechanism which separates encoding
from compression.
I don't think gzip64 is inelegant. Once there is a libgzip.a porting
this kind of thing will be a breeze.
There are very few MIME composers that do an intelligent job
of deciding which of the available options to use. Why add new ways
to confuse the implementers? :-)
--tal
P.S. Is there a mailer that tries to base64, quoted-printable, etc. etc.
looking for the best way to send something or do they still all require
the user to select the encoding?