ietf-822
[Top] [All Lists]

Re: Massive Content-Type definition ideas & Gopher

1993-06-09 20:36:52
To:  ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject:  Re: Massive Content-Type definition ideas & Gopher
Date:  Wed, 9 Jun 1993 18:55:43 -0500

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.

What I argue is that we should break existing MIME mail readers without
a good reason.  By this point a "good reason" needs to be something like:
"because there's some new feature we cannot live without, and we can't
add that feature any other way".

I should explain what I mean by "break".  Old MIME readers obviously
will not be able to handle the compressed types.  But they should not
act as if such types aren't compressed (say, treat them as base64),
and they should issue a reasonable error message.  If we violate either
of these rules, we are "breaking" existing MIME software.

Will you accept "not breaking things" as a reasonable goal?


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.

Sorry, that breaks existing MIME readers, that will (in the spirit of RFC
822) ignore headers that they don't understand.  We can't add headers
that incompatibly change how a content is decoded.


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?

If we need one more compression scheme, we will add another two encodings.
We won't do this unless we need that compression scheme really badly.

Encryption is not a good example.  It would never have fit into even a
multi-layer encoding scheme; it needs too many extra parameters.


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.

Both compression and encryption were discussed when defining the MIME model. 
MIME was designed to be two-layer even in light of these considerations.

I don't really have a problem with establishing a naming convention for
compression+encoding, solely for implementation convenience.  But just
because we add compression to MIME, does not mean that we are creating a
registry of names for compression algorithms.  But I don't really think
it buys you much.  It's easier to add two or four more entires to a lookup
table, than to bother with parsing the encoding name.

Someday there may be one or two more content-transfer-encodings for MIME,
besides the ones that currently exist and those defined for compression. 
Perhaps implementors will want to provide a metamail-like mechanism to allow
their MIME readers to call external decoders.  But the number should always
be few enough (intentionally!) that a flat table-lookup will suffice.

Keith