(Note: Maybe this should be taken off-line, because I doubt the majority
of people on current-users care about this ...)

>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.

I completely understand the need for OS & hardware independence, but
my mind was naturally drawn to the problem of "how do we do this on
NetBSD?".  Assuming that we will simply use the defined protocol
for charset negotiation (RFC 2066), that's the real problem (I
doubt that many telnet clients actually implement this, but that's
another issue :-) ).

>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.

Especially since differrent applications may support different character
sets ...

>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.

Well, we still need to do BINARY negotiation, regardless.  Right now
there are two "network modes" (for lack of a better term) with telnet.
The so-called "Network Virtual Terminal", which is only seven-bit and
has some defined network mangling, and BINARY, which is "pass everything
unmangled".  After you negotiate BINARY, then you could do character
set negotiation.

We _do_ have a number of non-US users.  Perhaps they could speak up and
tell us what they think, because they probably deal with i18n issues
on a daily basis.

--Ken