To prevent people from reading a lengthy, educational document about outgoing telnet connections, let us jump to the most common problem people report in case that's why you are here: People notice that when they telnet to certain hosts, the output "stair-steps" across the screen and then hangs along the right margin. What's wrong? The answer to this question is "Your telnet client is in binary mode and you are talking to a Unix computer. Put it in ASCII mode and it will work. You can use a separate menu option for invoking telnet in non-binary mode. It's documented in the BBS Networking manual".
Now on to some details about telnetting out of a TSX system. First, you should know that for historical reasons we have not one but two telnet client programs. The first of these is named TELNET.EXP and resides in the SY: directory. This is a port of telnet code which we got from Berkley. It is the oldest client, and served the general OS community well for many years. The second program was written specifically to be a component of TSX-Online. The motivations for writing a new telnet client from scratch probably had to do with cosmetics, we wanted the messages it gave to be a little more friendly and just felt like writing fresh code. This second program, which resides in the BBSBIN: directory, is named TELNTBBS.EXP. The remainder of this discussion is about TELNTBBS.EXP, although some comments apply to both since they are about Telnet in general.
The main bugaboo about Telnetting to remote computers is, as we mentioned above, the issue of binary vs. non-binary Telnet. Here is the technical low-down of what the binary vs. non-binary setting in our telnet client actually does. First, in the processing of characters received by the remote data stream, in the non-binary mode, line feeds which are not preceeded by carriage returns have carriage returns added to them. This translation of line feed by itself to carriage-return line feed is to compensate for the differences between the way different operating systems use the line feed character. Second, in binary mode, a high efficiency write of received data is used to send this data out the time sharing line associated with the person running telnet. This bypasses the windowing code in TSX, so it does not know what's on the screen, and would never be called upon to make any subsequent translations based on the terminal type. There are also some differences in the handling of outgoing characters. For example, in non-binary mode, the rubout character, hex 7F, is translated to a telnet escape sequence meaning rubout. This is not, however, done for binary mode.
If all this is unclear, here is a simplification: binary mode is for file transfers. Non-binary mode is for screen data.
The reason we decided to have the telnet client try to negotiate binary mode after establishing a connection has to do with the fact that this Telnet was written for TSX-Online users. We figured people would dial up a TSX-Online system from home using a communication program that understood how to perform ZMODEM file transfers. Then, the person would telnet through the TSX system to a remote computer. If the telnet is not in binary mode, the file transfers will fail because the telnet program in the middle is mucking around with the file data, trying to treat it as if its purpose was to control the user's screen.
Of course, this can cause problems, as we mentioned in the first paragraph, for people whose purpose is not to transfer data but to see screens on a remote system which uses control codes like line feed differently. You can either make these people happy and anger the file transfer types, or make file transfers work and deal with gripes about the screen. That's just the way it goes.
Behind the lines, telnet servers and telnet clients can exchange various commands to control the connection. One of these commands that the server can use is "send me your next terminal type". Servers use this to toggle a remote telnet "terminal" through various terminal emulations until the server finds one it likes. The rule is, when the same type is listed twice by the client, the end of the list of emulations has been reached. The TSX telnet client normally sends the string "VT100" first. This string was actually found in RFC7000, so we figured it was safe, but later discovered some servers that did not like it. Don't ask me how, but we discovered that these servers DID like the string "DEC-VT100", so we send that next. Then, if it does not like that, we send "UNKNOWN" twice; that's the end of the list.
You may have noticed that we said that the client "normally" sends out this terminal type list. In fact, we check to see if the BBS user's account claims he can handle ANSI. If he has turned ANSI sequences off, then we omit the VT100 words and the only terminal type available to the server is UNKNOWN.
The telnet client program can be invoked from the command line by typing TELNTBBS followed by the name of the host to connect to. When used this way, there are several qualifiers to this command which lived in undocumented obscurity until this article was written. It was only then the author realized and corrected this error of omission.