Apologies, I confused (1) and (2):
1 - The use of a "nested" CTE B64 if all else fails to send
DSNs to an EAI sender with a 7bit bit hop on the route.
2 - The use of UTF-8 in MIME version 1.0 part headers, this
can require to parse the MIME structure of a message to
figure out if it's a message/global or a message/rfc822,
instead of only looking at the message header.
| Oddly you don't have this problem with (2), and I don't have
| it with (1). For both issues I think they could be fixed in
| MIME, and I don't insist on an erratum or 2045bis for (1), or
| on a MIME version 1.1 for (2). And for your issue (= my 1) it
| might be precisely the purpose of an "IETF experiment" to see
| if it works out in practice.
| I could say the same about (2), but I'd hate it if (2) turns
| out to be critical and kills the EAI effort, because (2) is
not really necessary to experiment with "Email Address I18N".
| Arguably (1) is also not really necessary, but Ned told me
that application/message ideas to solve this problem are old
and never made it, and without something in the direction of
| application/message (1) is necessary. Somehow those DSNs to
an EAI sender with 7bit hops on the return path must make it.
IETF mailing list