At 6:50 PM 6/9/93 -0400, Keith Moore wrote:
Even a single keyword is an incompatible change to the MIME grammar. And it
also changes how a compressed body part will be treated on old MIME systems.
'I don't support this encoding' seems like a much better error message than
'illegal message'.
First we couldn't change the MIME-Version header because it wouldn't be
backwards compatible. It wasn't very important, so no big deal.
Now you argue that we can't change the syntax because it wouldn't be
backwards compatible. Instead, we will muddy the waters by lumping more
than one piece of information in a single token. This is a more important
issue; maybe not important enough, but more important.
I guess I think that it's too early to work around weaknesses in the
standard rather than fix them, for sake of backward compatibility.
Besides, it doesn't have to go in the CTE header. I'd rather see it in its
own header than just lumped into the CTE tokens, if I can't have real
syntax in the CTE.
Content-Transfer-Encoding := "BASE64" /
"QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" /
"BASE64-COMPRESSED" /
"BINARY-COMPRESSED" /
x-token
What happens if there is EVER another compression scheme we all want to
use? Or some other type of compound encoding (encryption would have fit,
if there were not a standard for it already; I'll use it as an example)?
Or even top-level encoding?
Content-Transfer-Encoding := "BASE64" /
"QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" /
"BASE64-COMPRESSED" /
"BINARY-COMPRESSED" /
"BASE64-SQUISHED" /
"BINARY-SQUISHED" /
"BASE64-COMPRESSED-ENCRYPTED" /
"BINARY-COMPRESSED-ENCRYPTED" /
"BASE64-SQUISHED-ENCRYPTED" /
"BINARY-SQUISHED-ENCRYPTED" /
"HEXIFY" /
"HEXIFY-COMPRESSED" /
"HEXIFY-SQUISHED" /
"HEXIFY-COMPRESSED-ENCRYPTED" /
"HEXIFY-SQUISHED-ENCRYPTED" /
x-token
Perhaps the feeling is that everything has already been weighed and
discarded, and that we need exactly one compression algorithm and exactly
one compression-type conversion (namely, compression), and no more CTE's,
ever. But I imagine that was felt when compression was left out of the
original spec for encoding, too.
Others wrote:
The sub-types name should be indicative of the specific compression
algorithm. If a second gets standardized, then we should specify
an additional set of subtypes (one each for binary, 8-bit, etc.) with
the name indicating this specific, new algorithm.
This implies
Content-Transfer-Encoding: base64/compressed
rather than
Content-Transfer-Encoding: compressed-base64
which is what I *thought* we were debating.
I think this misunderstanding/miscommunication (which I do not know) points
up the fact that it is very strange to mix these two distinct operations in
a single token.
But if I'm the only one who feels this is an ill-advised way to go, I'll
shut up.
--
Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.