On 17 Jul 97 at 16:52, David Goldsmith wrote:
> >Be aware, that UTF-8-Mail cannot be transported by any IBM mainframe
> >running EBCDIC, since EBCDIC makes use of 64 control characters. And there
> >are still many of such beasts left in the email network, many of them
> >running listserv and distributing high duty mailing lists.
> >
> >UTF-7,5 may pass through, but I won't bet on anything but pure ASCII. And
> >even this is sometimes mangled (specially the circumflex).
>
> This is why I mentioned BITNET. It may be 8-bit clean in one sense, but
> it will gleefully mangle stuff nonetheless (read the original documents
> on Base64 encoding for the gory details). This is why UTF-7 has a
> "conservative" form which only uses the subset of ASCII which BITNET will
> leave alone.
Come on folks - let's stop blaming Bitnet for these problems. Let me
say again clearly, there is no byte value or sequence of byte values
that Bitnet-like systems (i.e. RSCS based file transport) cannot
transmit without alteration. This includes NULL, CR, LF, NL, FF and
so on - all of which can exist in the middle of a line without
causing trouble, which is more than can be said of most of the mail
transfer world. Bitnet does not mangle anything.
Where there may be a problem is in the translation between ASCII and
EBCDIC. But if appropriate roundtrip tables are used there should be
no problem whatever. The only sense in which EBCDIC restricts the
use of those low order control characters is when the data stream is
sent to a 3270-series display device. There is no reason a mail user
agent should be sending UTF-8 to such a terminal that I can think
of, anymore than it should be sent to one of those VT320s we hear
about. The terminal driver must surely be responsible for getting
the right sort of data stream to the device.
I would hate to see stuff like UTF-7 persist merely because some
translation tables are set up badly, or worse - because of
misunderstanding of the issues.
Tony Harminc
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:36 EDT