< From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
< ...
< 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.
I think this is a poor assumption. It wasn't that long ago that compress
came out; up until then, Huffman encoding was considered to be "it". Then
along comes LZ, LZW, and all the other variants along those lines, the
latest being the one used by gzip. How much longer until a newer algorithm
comes along that beats the pants off of these algorithms? Once we've chosen
the one<<, we can't later just say "oops, we chose the wrong one". At that
point it would be difficult to switch. Will we always be able to say "this
algorithm is the best for compression"?
What I'm trying to say is that choosing a single algorithm doesn't permit
future growth. It's always better to make an escape hatch available.
< Second, there would only be two new encodings added: one using base64 and
< another using binary. Since compression presumably generates a stream of
< random-looking octets, quoted-printable wouldn't ever be optimal or useful
< for readablity, and compressed-{7,8}bit wouldn't be useful at all.
You may be right here, we may be able to get by with just adding versions of
base64 and binary. But then, we may not. How clear is your crystal ball? :-)
< I'd personally like to avoid making such a drastic change to the MIME
< framework. Also, if memory serves, we have discussed this topic before
< and ruled out multi-layer encodings.
No, I think the topic was postponed for perusal later on after the mime spec
got out the door.
<< For example,
<< Content-Transfer-Encoding: base64; compression="CompressionAlgorithm1"
<< Content-Transfer-Encoding: 8bit; compression="CompressionAlgorithm1"
< This would probably break current MIME readers that would ignore the
< parameter.
Would current MIME readers be able to easily handle ANY method of extending
encoding to handle compression? Adding support for compressed-binary and
compressed-base64 is just as intrusive.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony