Quoteing ned+ietf-822(_at_)mrochek(_dot_)com, on Sat, Apr 06, 2002 at
10:50:33AM -0800:
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.
Really? There seems to be much more complex parts of MIME. Oh well.
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.
Fair enough.
Quoteing mutz(_at_)kde(_dot_)org, on Sat, Apr 06, 2002 at 08:54:11PM +0200:
On Friday 05 April 2002 19:03, Charles Lindsey wrote:
<snip>
Or maybe you could define a compression=gzip parameter that could be used
with any CTE. That would seem to be more flexible.
<snip>
More flexible, yes.
But it would also change the syntax of the header, as CTE (the header)
currently doesn't allow parameters.
What about a list of cte's (then better dubbed
"content-transfer-transformations") to be applied in the format
innermostCTE+...+outermostCTE
(or vice versa), so you could say
C.-T.-E: gzip+base64
meaning "first remove base64 encoding, then gunzip". The + here is chosen for
being not tspecial (the cte identifier is a "token") and suggestive of "and"
and of the "+xml" convention (rfc3023).
A legacy agent would parse the cte name to be the full "gzip+base64" and get
an unknown cte, much like when plain "gzip" would be used.
Right, so most agents in existence would just choke, since they "know"
all the possible CTEs. So, this is syntactically backwards compatible,
but won't degrade gracefully.
Not that I think this will go anywhere, but what about adding a parameter
to Content-Type. It accepts parameters already, and I hope that most
implementations would just ignore any parameters it didn't support.
Doing:
content-type: application/tar; compression=gzip
would be fairly accurate, but if a MUA didn't support the compression
parameter it would think that the part was application/tar, but tar
would choke on it.
On the other hand, you could do:
content-type: application/x-gunzip; encapsulates=application/tar
or:
application-type: application/x-zip-compressed; encapsulates=application/pdf
Hopefully, a MUA could handle it as a zip file, and be right, or
it could lookup how to unwrap it in mailcap, then handle it as PDF,
which would be more right.
Sam
--
Sam Roberts <sroberts(_at_)uniserve(_dot_)com> (Vivez sans temps mort!)