At 7:58 -0700 6/30/98, Ken Hornstein wrote:

>On further thought, though .... I'm not sure what making telnet
>character-set aware would _mean_, in a practical sense.  For example,
>if one side says it wants to do ISO-8859, and the other side says it
>wants to do a Russian or Hebrew character set .... exactly what is
>supposed to happen?  That character set Telnet RFC seems to be designed
>to solve the problem of translating EBCDIC to ASCII.  If you just want
>the other side to know what character set you're using, wouldn't simply
>sending the right environment variable over using the standard telnet
>environment negotiation sequence solve that problem?  It's really the
>applications on the other side of the telnet that need to know what
>character set to use ...

It's both the terminal emulator (or whatever display/keyboard thing you're
using on the TELNET client) and the TELNET server (remote host) that need
to agree, on an ongoing basis. If the server wants to send ISO-8859-1
instead of NETASCII, the client needs to be in a position to refuse if it
cannot display such characters. And vice versa for the reverse case.

Environment variables are a UNIX thing, and are not expected to change
under UNIX after a process is started (indeed, there is no mechanism to
change them external to the process that must be affected by any such
change that might be renegotiated in TELNET). Despite its common use on the
Internet, the Internet is not about UNIX systems, any more than it is about
TOPS-20 systems, VAX/VMS systems, PCs or Macs. This is why you need an OS
and hardware independent mechanism. It's also likely that some OS's will
need to be fixed to properly support character sets other than ASCII or
EBCDIC.

At one level, we need a new termcap entity to indicate the character sets
that a terminal (or emulator) can display. Then you change the TELNET
client to read that as initialization for what it will accept from a remote
host. The host end of this is messy.

There is no excuse for the Macintosh TELNET client that does BINARY mode
wrong; that software needs to be fixed or replaced. Of the TELNET clients
out there for Macintosh, the only one I know that is actually under
development (and therefore there is a likelyhood of bugs being fixed) is
BetterTelnet, a new NCSA Telnet derivative. It can be found at
http://www.cstone.net/~rbraun/mac/telnet/

On another level, though, if we mean that we're moving ISO-8859-1 in
TELNET, we need to *say* that, in a TELNET negotiation. If we're moving
ISO-10646, or whatever, we need to *say* that. Just jumping into binary
mode and hoping the remote will DWIM is guaranteed to lose in a large
enough number of cases that we should not be doing that - It's Not The
Right Thing.

The up side of this is that, given X, xterm, and the right set of fonts,
NetBSD should be able to display anything, or accept anything as input from
a keyboard, which is a strength; This is not a capability that either Apple
or Microsoft have developed. They ship country-specific system versions
which can do the local stuff, plus English, but if you were expecting to
display Korean on a Norwegian system, you're going to be out of luck,
unless you go to extra trouble. We have developers all over the world; I
see no reason we shouldn't support them all in the base release as best we
can.

	Erik <fair@clock.org>