Today, when ASCII messages cross a border into an EBCDIC world, they
are converted to EBCDIC. Assuming that such a gateway is fully
upgraded to conform to the new RFC-XXXX, what should be done about the
content type header? Should it be changed to the following?
With the understanding that Erik asked this question very carefully and
did not refer to the BITNET-instance of this problem, but the more
general "EBCDIC world" case...
I have just put on my "member of the committee that gives technical
advice to the CREN Board" hat, and....
Once RFC-XXXX and the 8bit transport issues settle in a bit, and a few
of us are able to come up for air, a BITNET document will get written
that attempts to offer guidance for the handling of these mail
extensions things at the gateways. Since, in practice, two MHS systems
account for in excess of 95% of the gateways, the authors of one are
watching for that document and one of the authors of the other one is
clearly one of the perpetrators, I'd expect rather speedy agreement and
Now, part of that is intended to say, in a backwards way, what I've
been saying in a forward way for some time: other than making sure that
there is enough information present at the gateway for it to make decent
decisions, what happens on the other side of the boundary is not an
internet issue and I'd like to take this discussion off-list in a hurry.
While I can't predict what will come out of the BITNET-side drafting
process, I would assume (as likely co-author) that at least the first
draft will specify:
o Some trace ("Received") field action that specifies *exactly* what
has been done and by whom.
o Transformation of the header field to reflect the actual character
set in the message as it is to be delivered, e.g., yes, "something like
I would suspect that, when we ask Ed Hart's group about this, they
will tell us to specify a code page number, rather than "us-ebcdic", so
you would be more likely to see something like "text/ebcdic-nnn", but
that is still clearly in the "something like that" domain.