Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SUMEX-AIM.STANFORD.EDU!mrc From: mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: re: TELNET and 8-bit ascii codes Message-ID: Date: 18 Feb 89 19:23:25 GMT References: <8902161007.AA05006@indigo.stl.stc.co.uk> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 In a word, the answer is yes, if you want to transmit 8-bit ASCII codes then you should use network binary mode. Note that network binary mode also turns off the special handling of CR; the concept of the "Telnet newline" only exists if binary mode is off. Also, remember that binary mode is unidirectional and if you want a bidirectional binary stream (e.g. for using the international character set on a VT220) you must negotiate binary mode in both directions (IAC DO BINARY + IAC WILL BINARY). An example of operating systems which support this are WAITS (the system at SAIL.STANFORD.EDU), ITS, and TOPS-20. The most important use is to support 8-bit keyboard controls (the so-called "EDIT" key) or to turn off local controls for people coming in from a TAC. The PANDA version of TOPS-20 also supports VT220 characters as one of its extensions. Beware!! Many Unix Telnet servers tie network binary mode to the internal Unix concept of "raw" vs. "cooked" terminal modes. Arguably, this is a bug or at least a misfeature, but it's much too late to hope for a fix. At least some Unix Telnet servers will process 8-bit characters even if the stream is not in binary mode. Also, many terminals send parity in the high order bit. For this reason, it is not safe for a Telnet client to enter binary mode on its own without explicit direction from the human user or from the Telnet server, since there is no "right" setting that is guaranteed to work on all systems. -------