In other words, by "flat specification" you mean that in addition to the
current Content-Transfer-Encoding: values of
7bit
quoted-printable
base64
8bit
binary
x-foo
x-bar
there would be added, for each sanctioned compression algorithm, another set
of values, such as
CompressionAlgorithm1-7bit
CompressionAlgorithm1-quoted-printable
CompressionAlgorithm1-base64
CompressionAlgorithm1-8bit
CompressionAlgorithm1-binary
CompressionAlgorithm1-x-foo
CompressionAlgorithm1-x-bar
and
CompressionAlgorithm2-7bit
CompressionAlgorithm2-quoted-printable
CompressionAlgorithm2-base64
CompressionAlgorithm2-8bit
CompressionAlgorithm2-binary
CompressionAlgorithm2-x-foo
CompressionAlgorithm2-x-bar
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.
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.
Is this truly the way that other people are feeling?
I personally find even doubling the number of encodings to be rather
onerous. Wouldn't it be much cleaner to specify the compression algorithm
separately?
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.
The decompression truly is an orthogonal component of the encoding. Some may
consider it a 3rd axis, but Dave is correct that both are part of the
details about how the data is to be handled. However, the two are NOT close
enough in concept that they should be combined into a flat namespace.
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.
Keith