To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Subject: Re: Massive Content-Type definition ideas & Gopher
Date: Wed, 9 Jun 1993 16:26:08 -0500
At 5:05 PM 6/9/93 -0400, Keith Moore wrote:
1. It reduces the number of names that need to be registered and handled
.
And increases the number of lists that need to be registered and handled.
No, it adds a single keyword. It could even be an on/off content-type
parameter.
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'.
And there's no point to changing the current MIME syntax just to add one
or two compression algorithms. It's not necessary, and not worth the
effort.
You haven't changed the syntax for metamail-like systems that use tables of
filters. But you HAVE changed the syntax for systems that don't have
pipes.
I'll be more specific. I'm talking about changing the grammar from:
Content-Transfer-Encoding := "BASE64" /
"QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
to
Content-Transfer-Encoding := "BASE64" /
"QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" /
"BASE64-COMPRESSED" /
"BINARY-COMPRESSED" /
x-token
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.
I *will* have to deal specially with each and every one of your new
encodings, in code.
And so will everyone else that wants to support compression.
Except that I have no tools to parse this information,
since you're hiding two pieces of info in one, and not providing any
special characters to delimit them.
That's entirely by design. I want to change the MIME syntax as little as
possible. The content-transfer-encodings don't need to be subdivided because
we don't need lots of compression algorithms.
Promise me that ALL encodings with the compression scheme WILL begin with
"compressed-" and be followed by some other encoding type, and that NO
encoding types will be registered with an initial "compressed-" prefix
unless they follow this rule, and I will consider that you have made a
decision I dislike but can live with. It's a mongrel name-space, but at
least it is parseable.
Without such language, there is no reason someone could not register an
encoding of "compressed-fubar" that did NOT use the standard compression
scheme. Nor any reason someone could not register an encoding of
"squeezed-foobar" that DID use the compression scheme.
Content-transfer-encodings are part of the MIME grammar, so you can't
simply register them. To define new encodings requires an RFC.
Keith