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.
Similar problems apply to gateways, especially into networks who native
character sets are different from that of the Internet.
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)
-- learn to live with "encapsulation" models instead of message
conversion that preserves text as text. These "encapsulation" modes are
worse than what most people have been thinking about when they talk
about nested encoding.
-- include (and require) additional fields or header lines in RFC-XXXX
that provide explicit advice or direction to converters, gateways, etc.
The hypothesis is that this information would either closely resemble
the current primary content-type subfield (including the "small number"
and "closed" parts, or that it would quickly become very complicated.
-- adopt a variant on an X.400-like model in which parts of messages
that were not recognized at any point in the transport process were
simply discarded.
My impression--which could easily be wrong--is that there is general
agreement that each of the above three options is pretty abhorrent.
So, reopening this issue has significant implications all over the email
landscape, not just in how UAs interpret things.
john