I like your solution - it specifies a nice, clean algorithm to implement in
gateways, and leaves the burden of possibly recursively encoded message/foo
types where it belongs - in UAs that want to deal with newly defined types.
I'd be interested in a little more talk about this "burden" since I'm not
familiar with the "nested encoding rule" Ned referenced - if it applies at
all to message/rfc822.
The nested encoding rule is part of the core MIME specification. Simply put,
composite objects that MIME parsers are required to handle recursively and
hence can contain objects that are encoded with base64 or quoted-printable
cannot themselves be encoded using either base64 or quoted-printable.
How can a gateway (e.g. to a LAN mail system) which doesn't have a "user" to
provide advise, systematically deal with nested encodings?
There is no problem dealing with them systematically, but that's not the point.
The point is complexity. If nested encodings are allowed it is possible for a
part to encoded using quoted-printable or base64 multiple times. Not only is
this wasteful, it either complicates implementations considerably or else calls
for a relatively inefficient multi-pass decoding strategy.
For example, we currently attempt to parse nested message/rfc822 so that we
can give the cc:Mail user back his/her original attachments when a message
bounces (obviously parsing error reports is risky business, so we have a
fallback).
If we send out a message with 8bit or binary C-T-E body parts (I use the term
with great trepidation ;-) which at some later point traverses a 8-to-7 bit
gateway, and at a later point bounces back to the sending system, is it
possible/likely that we would be faced with the need to do an outer level
decode of the body of the error report before we could even see the
message/rfc822?
No. This is precisely what the nested encoding rule prohibits.
Also, in Ned's earlier two-step proposal:
(1) Is it message/rfc822? If it is, check to see if its encoded
using quoted-printable or base64 and if so, flag it as an error.
Otherwise handle message/rfc822 recursively.
(2) Is it encoded as 7bit, quoted-printable, or base64? Stop if it
is, and if it isn't flag it as an error.
rule #2 doesn't make sense to me. Apparently it applies to all *other*
type/subtypes?
It only applies if rule #1 doesn't. But that's doesn't make it apply to
all other type/subtypes. This discussion is about the message type only. It
doesn't generalize.
The underlying issue here is what subtypes of message are actually used for. If
they are used to define new objects that MIME parsers must handle directly and
recursively, you have to teach parsers (including those in 8-to-7 gateways)
about them. There is no way to avoid doing so. But only the rfc822 subtype of
message is directly recursive -- the partial and external-body subtypes both
involve indirect recursion. They cannot be downgraded by an 8-to-7 gateway even
if you wanted to, so the definitions themselves restrict the set of permissible
encodings to make it unnecessary for 8-to-7 gateways to do anything at all.
My proposal is simply to restrict the encodings you can have on new subtypes of
message to the largest set that will not cause any problems with 8-to-7. The
previous MIME document restricted things in a way that was neither
necessary nor sufficient to obtain this effect.
Ned