Even though application/zip is lame, other mechanisms might be
worse. Maybe we should look harder at providing what would be
necessary to make 'application/zip' actually work, e.g., some
top-level indication of what's actually in the package?
this has the same deployment barrier as adding a new
content-transfer-encoding - in either case the mime mail
reader needs to know what to do with the extra parameter
or the new c-t-e.
I'm not sure this is true. Unaware MIME mailers will just
see they have application/zip, that they either recognize
or not, and users of existing MIME mail programs have simple
way of configuring their mail reader to at do something
sensible with it.
Adding a new content-transfer-encoding has a more serious
deployment problem, because most deployed systems don't have
any kind of extensibility built in for CTE.
Mailing around zip files is common practice. Many people are
used to dealing with getting a zip file. Leveraging this
just means making the common practice easier to accomplish
for senders, and less awkward for receivers; it's a product
enhancement that mail client vendors could add today.
In the menu for 'attach file', it could just have a check
box for 'send zipped', for example, and a setting for making
'send zipped' the default for attachments, or for attachments
that aren't known to already have better media-specific
compression.