Date: Wed, 28 Aug 1991 07:56:05 -0400 (EDT)
From: John C Klensin <KLENSIN(_at_)infoods(_dot_)mit(_dot_)edu>
Subject: Re: Content types and encodings
Vincent, Bill, and others...
I want to add one comment to the remarks from Ned and Mark, without
agreeing (or disagreeing) with those remarks:
We have a controversial mess in the 8bit transport area. We may -- or
may not -- be on the verge of resolving that mess with an approach that
people can live with. But the proposed agreement there (relative to what
"transport encodings" are permitted and where they are applied) is
critically dependent on an assumption of RFC-XXXX. And that assumption
is that there are a rather small, and very closed, set of types.
...
If the number of types is small and closed, it is possible to conceive
of gateways and converting relays doing their conversions one body part
at a time, understanding (at the "type" level) what they need to do. If
it becomes large and/or open, then one must do one of the following
(there are really no other alternatives)
John, I thought that this was old territory, and that a gateway
didn't (and shouldn't) need to look at the type field to encode a
body part. Instead, there are five possible states for transport
encoding: 8bit (text), 7bit (text), binary, base64, and quoted-printable.
This should provide all the necessary information that a gateway
would need to know about a body part; there is no reason why a
gateway needs to look at the type (except for multipart...).
I feel that we should encourage a large set of descriptive type/subtype
names, that map all the way down describe a body part well enough to
match it to a application that can show the part to the user.
Unless the number of types is extremely static, it will be an operational
nightmare to add new parts if you have to upgrade gateways first...
Neil Katin