ned+ietf-822(_at_)mrochek(_dot_)com
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.
TLS does compression, so RFC2595 would have the side effect of providing
compressed SMTP, provided implementations negotiate something better than
CompressionMethod.null.
Good point, although I've heard that there's a patent covering the combining
of compression and encryption. What's the story?
Ned