6) Message/Partial send over an 8 bit or binary path cannot be
converted in a MIME aware gateway from 8 bits to 7 bits due to the
prohibition on encoding of the message content type and the unknown
nature of the content
Alternate Solution2: Make an exception to the nested encoding rules for
Similar to alternate solution 2:
I'd prefer that the "no nested encoding" rule apply only to multipart/* and
message/rfc822. It's not clear that it makes sense to place constraints on
the encoding of other message/* types. For example, were a message/x400
content-type defined, it probably needs to be encoded in base64.
I agree that the no nested encoding rule needs to be lifted on as-yet-undefined
types under message/. As you say, an X.400 message is going to require
At any rate, I don't think the "no encoding" rule should apply to
This has an immediate and powerful side effect -- it forces anyone who wants to
support message/partial defragmentation into having to support full binary
MIME. Consider the following: I have a big multipart MIME message containing
binary parts, text parts, etc. I want to fragment it. If the rule on encoding
of message/partial is lifted one way I can do this is to convert the sucker
into all-binary canonical form. Then I encode the entire thing in base64, break
it up into pieces and ship them all out as message/partial critters. Now, when
someone decodes this thing they're presented with a complex mixed binary/text
object. Very nasty if you don't have the software on hand to deal with it.
If, on the other hand, we enforce the ban and add the rule that message/partial
parts must be 7bit, the only feasible way to fragment such a message is to
encode all the parts individually and then break it all up into separate
message/partial pieces in strict 7bit. This minimizes the burden placed on the
defragmentation software. I think making life easier for readers is a good
thing and therefore I do not support lifting the no encoding rule on
If we do decide to lift the ban we must be very very careful to spell
out the requirement that the encoding be removed right after reassembly.
Otherwise we run the risk of letting nested encodings loose; a Bad Thing.
(We also have to spell out whether the object is fragmented and encoded versus
encoded and fragmented. These can produce very different results.)