Compression is fundamentally a transport issue, not an application issue,
and as such should be added or removed as part of the transport layer, not
as part of the application dispatch layer. The Content-Transfer-Encoding
vs. Content-Type distinction already encapsulates that, and shouldn't be
abandoned.
Indeed, one can argue that compression should be negotiated as an SMTP
(or whatever protocol) extension, and should not enter in to the message body
format at all. The argument against that is encrypted messages, where the
compression has to be done as part of the encryption operation to be
effective. However, now that S/MIME has (or is getting) a compression
layer added, maybe this solves the compression of encrypted content
problem and leaves us free to address the compression of unencrypted
content at the protocol level.
Ned