In <yly9g38fa1(_dot_)fsf(_at_)windlord(_dot_)stanford(_dot_)edu> Russ
Allbery <rra(_at_)stanford(_dot_)edu> writes:
Dan Kohn <dan(_at_)dankohn(_dot_)com> writes:
It's not really been considered for Usenet because essentially all of the
binaries posted to Usenet are already compressed. (GIFs, JPEGs, MP3s, ZIP
files, compressed movies, etc.) A compressed CTE would be a lot more
useful in mail than on Usenet.
Indeed so.
snip...
But there is another problem with a gzip CTE, which is that you may have
gzip on top of Base64, or gzip on top of yEnc, or qzip on top of whatever
else. Maybe, in an ideal world, one would define an encoding (yEnc say)
and then define a gzip option inside that.
Or maybe you could define a compression=gzip parameter that could be used
with any CTE. That would seem to be more flexible.
Has this been proposed? It seems a parameter to the content-transfer-encoding
would be handy. I'm sure I'm not the only one who has wondered why we
have to call things application/pick-your-compression-format instead
of application/tar, as it should be.
It was proposed over a decade ago. It was rejected then because it was felt
to be too complex.
I disagreed with the decision then and I disagree with it now. However,
the issue is moot, because a major change in the syntax of the CTE parameter
is no longer possible. Think for a moment about the size of the installed
base and it should be obvious why this is so.
Ned