I'm unclear as to why a checksum is so problematic across ASCII-EBCDIC
gateways. You just have to know that the checksum is to be computed
using ASCII, not EBCDIC, codes. This is what Kermit implementations on
IBM mainframes do all the time. Works fine.
It is important that the ASCII-EBCDIC translate tables be correct.
With something like BASE64, where the character set is restricted to
the invariant subset, it is not a problem. I don't recall offhand if
quoted-printable restricts itself to the invariant subset. If not,
that could be a problem when more than one EBCDIC host is involved. In
such a case a checksum would tell you when something did not translate
properly. This could be important for some kinds of text, such as
source code.
There is no such thing as a 'correct ASCII-EBCDIC table'. Even in Finland
there
are several (atleast four, propably more) different tables in use. Also many
tables are not reversible (ASCII->EBCDIC->ASCII change the text file). The
reason
behind selecting the characters to base64 coding is that it contains the
invarian
subset that is reversible in ASCII<>EBCDIC tables.
Yes, I realize that. However, the ASCII-EBCDIC translation tables need
only to be consistent with each other for the characters being used.
Within a single host it's usually possible to get them to match up.
You do have to have reversible translations in the characters being
used. However, ASCII-EBCDIC-ASCII is usually easier to deal with than
EBCDIC-ASCII-EBCDIC. It's only the former that is needed here.
This problem with converions makes checksumming anything that isn't encoded
not very useable.
Also checksum computed in ASCII isn't very much use if your user-agent
is using EBCDIC (or any other charcater set than ASCII).
I disagree. As I mentioned before, Kermit implementations on IBM
mainframes using EBCDIC compute checksums in ASCII all the time. For
example, under TSO/TCAM an ASCII packet will arrive and be translated
to EBCDIC by TCAM (the TP monitor). Kermit translates the packet back
to ASCII in order to verify the checksum. Obviously, the translate
tables have to match up, but it's all within one host. The situation
is similar if an SMTP server receives a message in ASCII and translates
it to EBCDIC before passing it to the UA. The UA does have to know
what table is being used by the SMTP server to translate ASCII to
EBCDIC so that it can use the reverse table. Making a reverse table is
not difficult, as long as the SMTP uses only a single ASCII-EBCDIC
translation table. A similar process happens for mail messages moving
out from the EBCDIC host.
The place where a greater difficulty arises is when the SMTP server and
UA are on different hosts, as might occur with an Internet-BITNET
gateway and a UA on a different BITNET host. One solution to this
would be to use ASCII for BITNET mail, thus keeping all the
EBCDIC-ASCII translations within a single host.
Roger Fajman Telephone: +1 301 402 1246
National Institutes of Health BITNET: RAF(_at_)NIHCU
Bethesda, Maryland, USA Internet:
RAF(_at_)CU(_dot_)NIH(_dot_)GOV