I'm impressed that my message will get to you, and you'll be able to read
it, despite the fact that my default encoding is ASCII and yours is
Whoops! I forgot to mention that only out-going messages are converted
from Shift-JIS to ISO 2022. So I'm reading your message in ASCII.
(Actually, even if our gateway converted in-coming messages from 2022
to Shift-JIS, I would still receive your message in ASCII, because (a)
your message does not contain any 2022 escape sequences, and (b)
Shift-JIS is a strict superset of ASCII.)
But there's a fundamental problem in this approach. We want to
define a scheme which enables us to exchange TeX dvi files (for example).
I'm afraid you have missed the point entirely. If we want to exchange
dvi files, we will need some sort of Content-Encoding, like uuencode
or base64. One of the main advantages of base64 is that it will not be
mangled by ASCII<->EBCDIC gateways, right?
(But is this realistic knowing intermediate transformations already exist?)
I contend that it is unrealistic to assume that EBCDIC and its
associated gateways will disappear soon. They may not disappear at
all. But they may become more intelligent.
One of the points I'm trying to make is that we will not be able to
upgrade ALL of the world's UAs and gateways at the same time, so if we
tried to add character set headers, there would be a transition period
in which all sorts of errors would occur, and I don't think the users
would forgive us.
So let's concentrate on the Quoted-Readable encoding, and
let's make it EBCDIC-safe i.e. unaffected by ASCII<->EBCDIC
Unfortunately, this would require a transformation which is neither ASCII
nor EBCDIC, and liable to satisfy no one.
No, this would require the use of a set of characters that is common
to both ASCII and EBCDIC (actually, all versions of EBCDIC). This is
what BASE64 is all about, right? Actually, I hope we can find a larger
set of common characters. The BASE64 set would be rather limited for a
Quoted-Readable encoding. Any EBCDIC experts out there? How about