From: Neil(_dot_)Katin(_at_)eng(_dot_)sun(_dot_)com (Neil Katin)
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...).
First of all, it depends on what you mean by gateway. A gateway for RFC XXXX
to
X.400 certainly needs to look at the content-type field, so it can recognize
things that X.400 supports in its own fashion (like fax) and generate the
appropriate X.400 body parts.
On the other hand, even an 8-to-7 gateway should probably try to
distinguish between body parts that are human-readable
(content-types text and perhaps text-plus) encoding these
as quoted-printable, and encoding other 8-bit parts as base64.
Having a small set of top-level types is also useful for the recipient's UA.
Even if it doesn't support text/mnemonic, it can still look at the top-level
type of "text" and let her read it in encoded form. Similarly for the
top-level type of "message".
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.
Agreed, as long as (a) we don't have too many top-level types, and (b) we
don't end up standardizing lots of different ways to represent the same kind of
data. Better to encourage a particular representation on-the-wire.
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...
Well, the gateways will have a default behavior for each top-level type,
(which in some cases would do no more than "preserve the bits" in case the
message gets forwarded back into the Internet environment), and specific
translations for the specific types that they understand.
Keith