Excerpts from mail: 9-Jun-93 Re: Massive Content-Type de.. Keith
Moore(_at_)cs(_dot_)utk(_dot_)edu (3125)
Correct me if I'm wrong, but I don't think metamail supports user-definable
"tables of filters" for content-transfer-encodings. Last time I looked,
they were hard-coded in.
That's right. Metamail reflects my philosophy that there should be lots
of content-types -- i.e. people should be free to send more or less any
kind of data that they want, limited only by formal registration and the
application of "reasonableness" to prevent an UNNECESSARY proliferation
of types -- but as few encodings as possible, to promote
interoperability. In particular, the case I'm most concerned about, in
this regard, is the case where two consenting users are trying to do
things their mail systems don't really understand. If I'm sophisticated
enough to tag up my data as application/smell-o-vision, and you're
sophisticated enough to take a smell-o-vision-format file and figure out
how to actually, er, uh, "play" it, your mail systems shouldn't stand in
the way. A proliferation of encodings could have that effect, which is
why I'm so strongly opposed to anything that smacks of parameterization
of content-transfer-encodings.
I would also point out that many of us are not all that unhappy with the
status quo. If no consensus can be reached, MIME will plod along quite
happily without ANY general compression mechanism. Given that some of
us are happy with that situation and are really opposed to LOTS of
compressions/encoding algorithms, and that some people are apparently
fairly desparate for SOME kind of compression/encoding scheme, the
obvious solution -- at least for the short term -- is one that uses a
single compression algorithm, with only a few new values for
content-transfer-encoding (compress-64, compress-binary, and MAYBE
"compress-8bit" in which newlines can be added & quoted). In other
words, I can support some variant of Greg's proposal, but probably not
anything more open-ended.