Summary

  • RFC 884, issued in December 1983, gave Telnet option 24 a small job: let a host request the name of the user's terminal. Permission came through DO and WILL; the actual name travelled later in a SEND/IS subnegotiation.
  • The first name could be too specific for the host's vocabulary. RFC 884 let the terminal offer successively more general names and repeat the last one to announce that the list was exhausted. Its 1985 successor, RFC 930, repaired an awkward timing case by requiring each IS to answer a SEND.

Imagine sitting before a glowing screen and logging into a distant machine. Your keyboard works. Characters arrive. Then an application tries to put a menu in the corner and discovers that “corner” has several competing meanings. One terminal wants one escape sequence; another wants a different one; a paper teletype would regard the entire exercise as showing off. The computer can keep printing lines, but a clever interface needs to know what sits on your desk.

Telnet's Network Virtual Terminal solved the first half of that problem by giving both ends a common starting point. Every host could speak to that imaginary device. It was a useful diplomatic fiction: the network did not have to memorize each local terminal's quirks before allowing a conversation. The fiction became cramped when a program wanted cursor addressing or colours. Marvin Solomon and Edward Wimmers supplied a polite introduction in RFC 884: ask the other end what sort of terminal it has.

The introduction had protocol manners. TERMINAL-TYPE received option code 24. The default was silence: DON'T and WON'T meant the name would stay private. A host's DO and the other side's WILL opened the conversation. Those words gave permission; they did not contain the answer. The host could then send IAC SB TERMINAL-TYPE SEND IAC SE, and the other end could reply with IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE. SEND was subcommand 1, IS subcommand 0. In a world fond of massive acronyms, the exchange was almost chatty.

The name itself was an NVT ASCII string, compared without regard to case. RFC 884's suggestions ranged across IBM displays, TOPS20 machines and Unix terminals: DEC-VT100, TELETYPE-33 and a formidable run of other models. The list reveals what a universal network connection encountered at its edges. Those devices could share a Telnet session while disagreeing violently about where a character should land on a screen.

Of course, names are a human invention, and humans enjoy spelling the same thing twice. The authors gave IBM3278-2 and IBM-3278/2 as a recipe for confusion. Telnet supplied no negative acknowledgement for a terminal name the server failed to understand. Instead, a device known by a precise name and a broader one could offer the precise name first, then work down to the generic one as the host asked again. To say “that's all,” it repeated the last name. The host was to stop asking after seeing the same answer twice in a row. The protocol had invented a surprisingly civil way to say, “Any other names you go by?”

Receiving a name could help a local terminal driver choose suitable output. A host with the right support could use cursor addressing and other features beyond the basic virtual terminal, sometimes alongside Telnet's BINARY option. The 1983 specification left that local choice to the receiving process. A mere name was information for a decision; the host still had to understand it and act on it. If it did not understand the name, another option such as BINARY might be declined. UNKNOWN was an honest answer when neither end could expect a recognizable model.

There was one wrinkle in the original conversation. After DO and WILL, RFC 884 allowed the terminal side to volunteer an IS without waiting for SEND. The authors expected that a simultaneous request would, at worst, produce the same information twice. RFC 930 changed precisely that rule in January 1985. If an unsolicited IS and a SEND crossed in flight, the receiving host could mistake the subsequent answer for the next entry in the list. Under the revised rule the terminal spoke only when asked. The terminal still had names; the protocol acquired a turn-taking rule.

Later, RFC 1091 let a client with several emulation modes cycle through them and switch modes in response to server requests. That was a different bargain from the 1983 one, whose successive names could describe the same device at different levels of specificity. The older document captures a smaller, more charming problem: a remote machine wanting to draw on your screen had to learn which screen you owned. It asked, listened, and, when necessary, asked what else the screen called itself.