>Fortunately for us, a lot of this work has already been done, APIs
>specified, and so on. We just need to implement and integrate. We also need
>to watch out for situations like this one with TELNET, where we're sending
>unlabelled data (TELNET BINARY MODE) with a *presumption* of how it will be
>interpreted on the other end (ISO-8859-1, I bet).

Actually, Bill's problem is the exact opposite.

We're _expecting_ BINARY, but his client is still sending NVT ASCII
which includes NUL after CR.  In non-binary mode, NUL after CR means
simply "CR", but since BINARY mode means "pass this data unchanged",
the NUL gets delivered to the pty, which causes bad things to happen.

I agree that i8n is important; however, this was simply a problem of
of a subtle change in NetBSD causing telnetd to offer BINARY mode, and
Bill's Mac client not doing BINARY correctly.

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

--Ken