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.
Believe me, from a tech support perspective the problems here are far worse
than those associated with a CTE. Think about the implications in the context
of IMAP, for example, where separate fetch of body parts is an important
feature.
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.
Summary and unconditional rejection of ZIPs is also common because of the
inability in some environments to check the content for viruses.
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.
In case it isn't clear, I am absolutely opposed to increased use of
application/zip within MIME. We need to solve the real problem here, which is
to allow end-to-end knowledge of what C-Ts and CTEs are supported. Once this is
done we can deploy new CTEs or whatever else we chose willy-nilly. And until it
is done none of this stuff, with the exception of TLS-based compression, stands
a snowball's chance in hell of being widely deployed.
Ned