John writes:
the other is to assume a something-centric
(ASCII-centric, 8859-1-centric, IA5-centric, SMTP-centric,
X.400-centric,...) world and try to make everyone else adapt to it.
How about an ASCII-and-US-EBCDIC-centric world? I.e. an ASCII composer
*must* *not* put "us-ascii" in the headers, and an EBCDIC composer
*must* *not* put "us-ebcdic" (or whatever) in the headers. This way,
English messages (the bulk of the messages flying across the Internet
proper (as opposed to local enclaves)) can be transmitted correctly
(without confusion), even in the presence of "old" gateways.
Of course, there are several versions of EBCDIC. Someone even said
that there are several versions of US-EBCDIC. I don't care. Just
choose one. The most common one, if possible.
Anything else (i.e. not ASCII and not US-EBCDIC) *must* be identified
(to conform with RFC-XXXX). This way, an RFC-XXXX conformant EBCDIC
receiver can "guess" the correct way to interpret a message identified
as e.g. ISO 2022, even if the intervening gateway was RFC-XXXX-stupid
and simply converted the octets, one by one, to EBCDIC.
If the 2022 composer is old (and doesn't add the identifying header),
the EBCDIC receiver will not be able to do anything intelligent with
the message. This is no different from today's situation.
If the EBCDIC gateway is intelligent, it might encapsulate the
message, or do something to transmit it safely to the eventual
destination.
If the EBCDIC receiver is stupid, the message cannot be interpreted
correctly. This is no different from today's situation.
I'm not sure if this is (close to) the right solution, but it sure as
hell does provide an extremely clear migration path.
Regards,
EvdP