1. When composing a message, the sender (or his user agent) should choose a
particular c-t-e based on:
a) the liklihood that that particular body part will get damaged in
transit,
b) whether such damage will make the message unreadable, and
c) whether backward compatibility with pre-MIME systems is desired.
It seems to me that you forget the restriction on CTE for message and
multipart types.
Base64 and quoted-printable are carefully defined so that they decode to
the same thing in either ascii or ebcdic. (For example, "A" in
quoted-printable always means 0x41, even if the local charset is ebcdic.)
This allows encoded body parts to pass through a traditional ascii<->ebcdic
mail gateway (which simply translates the entire message) without
losing the ability to recover the canonical form of the contents.
EBCDIC<->ASCII converting gateway is NOT a MIME gateway.
If 'A' is not 0x41, it's not MIME nor RFC 822.
This is NOT true for BINARY.
This is no different for BINARY.
If a message containing a BINARY body part is
gatewayed from an ASCII into an EBCDIC environemnt, it MUST NOT be
translated to EBCDIC. Doing so corrupts the data. A correctly written
user agent will assume that the data in a BINARY body part is the same,
octet for octet, as when it was composed.
What happens when EBCDIC-encoded encapsulation boundary of a multipart
message is included in the binary part?
ASCII<->EBCDIC gateway must also act as a MIME<->non-MIME gateway.
So, the conversion MUST be to Base64, unless what you are sending is
EBCDIC-safe (such as English plain text), which MUST be confirmed
by checking all the bytes in the message.
Also, as others have pointed out, MIME user agents in an EBCDIC world
expect messages as fixed length records.
There is no such thing as "MIME user agents in an EBCDIC world".
Also, variable length records are available even in the EBCDIC world,
3. Back to point #1: Choose the c-t-e based on the likely damage etc.
It is obvious that BINARY is a poor choice for a c-t-e when sending into an
EBCDIC environment,
EBCDIC environment is poor. That's all.
since that environment almost certainly cannot support
it. Furthermore, the corruption of a "plain text" message in a BINARY body
part in such an environment is likely to be far worse than the corruption
of the same contents in a 7bit/8bit/q-p/base64 body part.
I recommend you gain some REAL real-world experience on e-mail, not only
for English plain text with US-ASCII.
I know how badly ISO-2022-JP-encoded plain text messages corrupted
through EBCDIC environment, which drove BITNET users to
TCP/IP in Japan.
Masataka Ohta