Dave Crocker posted the following to comp.mail.mime:
< From: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
<
< Let me suggest a somewhat different way of stating Keith's view, to which
< I subscribe:
<
< There are different ways to deal with compression, but there is
< considerable benefit in trying to keep the meta-framework simple. The
< philosophy in Mime is to specify a two-axis model. One access specifies
< the syntax and semantics of the data. The other axis specifies any
< necessary details about the handling of the data that pertain to shipping
< it around. Compression clearly and only falls into the latter camp. The
< fact that that compression might be long-lasting (e.g., longer lasting
< that 7-to-8 bit encoding as the individual transport links change) is not
< significant.
<
< So, the feeling is to merge "bit"-ness with compression. While they could
< be represented separately, the feeling is that the combinatorials are
< small enough to warrant a flat specification of bit-encoding and
< compression.
<
< d/
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
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?
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"
By separating the two, the orthogonality of the compression scheme is
spelled out distinctly, it is obvious how to parse the algorithm name, and
the encoding name is not mixed in with the compression scheme name. The
encoding value would cover strictly how the bytes that follow are to be
interpreted, just as it does now.
In the example, the compression algorithm is applied to the results of
reversing the encoding back to 8-bit-clean bits from the encoding value,
here shown as base64 and 8bit. The output of the decompression is then
treated according to the Content-Type: header.
Thoughts?
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony