Erik,

Telnet is a venerable protocol which encapsulates two conceptually
separate protocols: a remote-login protocol, and a "presentation
layer" network virtual terminal (NVT).
derivative of ASCII.

Telnet's BINARY mode simply turns off the NVT part of the Telnet
protocol and leaves you with just the remote-login part.  Binary lets
two consenting peers exchange raw bytes.  it's up to the consenting
peers (read: the user who asked for it) to interpret the raw 8-bit
bytes. IIANM, tn3270 uses BINARY too, for example.

If you want to invent a mechanism to negotiate character sets as an
extension to telnet, then by all means go ahead.  Get behind rfc2066,
implement it, push it for standards-track, etc., etc.  But please
don't confuse this with telnet BINARY mode. They're not the same at all.

[Ken is probably going to say the above, too, but it's worth repeating].


And FWIW, given the semantics of "BINARY", I think having our
server-side telnet initiate BINARY negotiation is a Really Dumb Idea.
In the absence of sane charset-negotiation, BINARY should only be used
when a human user, or a screen-aware app prepared to take on screen
management (via termcap/terminfo), decides it's OK to do so.