To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> (Non Receipt
Notification Requested)
(IPM Return Requested)
(Arrgh! what's this header trash?!?)
It's not anywhere nearly that bad. First of all, we don't need multiple
compression algorithms -- we need one that everyone can use freely.
How is it you figure that?
Different compression algorithms make sense for different data files.
There are generic algorithms as used in compress or gzip. If you try those
on audio or image files they don't work too well. But using an algorithm
tuned to audio or images works fantastically (*sometimes* by losing
information, unfortunately).
This implies, to me, a need for lots of (well, a few anyway) compression
algorithms. Well, maybe only three. Four? (1: generic algorithm for
`everything', 2: audio-specific, 3: image-specific, 4: video-specific).
At least these anyway.
Seems like all of the existing the audio/image/video content-types already
have compression built-in. So I'm only talking about "generic" compression,
and probably only on top of text/* or application/* types.
Note that I said `a need for', I am trying to view this from an end-users
viewpoint. S/he will eventually want to ship these various kinds of things
around. Their network managers will appreciate it highly if it is
compressed before shipping. Or maybe their MTAs could have a hook to
compress things that aren't already compressed -- in messages which are to
be sent to a distant place.
I'm very concerned that we don't create unnecessary interoperability
barriers. Existing MIME UAs do not support compression. It therefore
needs to be a user-defined option.
Since Keith is, in my opinion, wrong in this assertion his assertion that
"Compressed-BASE64" & etc will not work. This is because what I've argued
above strongly requires the "Compress-alg-{n}-BASE64" style of approach.
If we did have multiple compression algorithms, we would of course have to
have different names for the content-transfer-encodings. However, I object
to imposing any structure to the name of a content-transfer-encoding.
What does it hurt to put compression algorithm choice in as an option/value
pair instead of as a modifier to the encoding name?
It is a major, incompatible change to the MIME framework. We are better
off not breaking MIME if we can help it.
Keith