Erik M. van der Poel writes:
For example, in the case of an ASCII-->EBCDIC gateway, a conversion
must be done -- the other side does not know ASCII. Knowing the
character set can only aid in doing the conversion properly (or
possibly knowing that encoding is the best bet).
So let's suppose some piece of software adds the ASCII label to a
message. When it passes through an ASCII->EBCDIC gateway which hasn't
been updated yet, the label will still say ASCII, even though the
message is in EBCDIC.
Congratulations -- you are now face-to-face with the problem I've been
grappling with for some time. This is a MAJOR problem; make no mistake about
it.
However, it has nothing to do with the Content-Charset: header issues. The
problem exists regardless of where you stuff this information. It exists even
if you stuff this information in the data itself -- consider the problem of
translating a text-plus/richtext document to EBCDIC. What on earth does such
a translation mean?
Thus, insofar as the debate over Content-Charset goes, this issue is
orthogonal. It is, nevertheless, a big issue.
Would this confuse users? Would this confuse machines?
You bet it is confusing, to both users and machines.
Has anyone made any MIGRATION PLANS for RFC-XXXX?
Specific plans, no. The start of various migration proposals for BITNET and
other affected networks, yes. There is a possibility that we may be able to get
BITNET gateways aligned with our proposals without a lot of hassle -- I'll let
John speak to this if he so chooses.
John Klensin and I have batted this one around offline a bit, but since it has
no effect on the Internet proper (an EBCDIC gateway is not, properly speaking,
a concern of the Internet) we have not discussed it on the list. I don't
propose we start now -- this list is busy enough, and apart from making sure
that the necessary infrastructure gateways need is present I don't think
this sort of stuff is an appropriate topic for this list.
Ned