RFC 930

TELNET TERMINAL TYPE OPTION 💖

okay so this is RFC 930 💅 It was written by Marvin Solomon and Edward Wimmers at the University of Wisconsin - Madison, and it's dated January 1985. It's a Network Working Group doc, and it supersedes RFC 884 ✨ Nothing is listed as updated.

Status of This Memo 🎀

This RFC is a standard for the ARPA Internet community 🌈 Hosts on the ARPA Internet that trade terminal type info inside the Telnet protocol are expected to adopt and implement it. Distribution is unlimited 🫶

This standard supersedes RFC 884. The only change is that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation. More on that below 👀

1. Command Name and Code 🦋

TERMINAL-TYPE    24

2. Command Meanings 🌸

• IAC WILL TERMINAL-TYPE: the sender is willing to send terminal type information in a later sub-negotiation 💜
• IAC WON'T TERMINAL-TYPE: the sender refuses to send terminal type information 🙈
• IAC DO TERMINAL-TYPE: the sender is willing to receive terminal type information in a later sub-negotiation ✨
• IAC DON'T TERMINAL-TYPE: the sender refuses to accept terminal type information 💀
• IAC SB TERMINAL-TYPE SEND IAC SE: the sender asks the receiver to transmit the receiver's own terminal type. The code for SEND is 1. (See below 🧚)
• IAC SB TERMINAL-TYPE IS ... IAC SE: the sender is stating the name of their terminal type. The code for IS is 0. (See below 🧚)

3. Default 🍓

• WON'T TERMINAL-TYPE: terminal type information will not be exchanged 😭
• DON'T TERMINAL-TYPE: terminal type information will not be exchanged 😭

4. Motivation for the Option 🔥

This option lets a telnet server figure out what kind of terminal is connected to a user's telnet program. Just sending this info doesn't change any processing right away 🙄 But a process can take the info and tweak the data it sends so it fits that specific terminal. For example, some operating systems have a terminal driver that takes a code saying what kind of terminal it's driving. If you use the TERMINAL TYPE and BINARY options together, a telnet server on a system like that can make terminals behave as if they were directly connected, with stuff like cursor addressing, multiple colors, and other things that aren't in the Network Virtual Terminal spec 🌈 This option fits neatly into the normal TELNET option structure by saving the actual transfer of status info for the SB command 💅

5. Description of the Option 👑

WILL and DO are only used to get and give permission for a future discussion. The real swap of status info happens inside the option subcommands (IAC SB TERMINAL-TYPE...) 🫶

Once the two hosts have traded a WILL and a DO, the sender of the DO TERMINAL-TYPE is free to ask for type info whenever. Only the DO sender can send requests (IAC SB TERMINAL-TYPE SEND IAC SE), and only the WILL sender can send the actual type info (inside an IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type info may not be sent spontaneously. It only goes out in response to a request ✨

The terminal type info is an NVT ASCII string, and upper and lower case count as the same thing inside it 🦋 The full list of valid terminal type names lives in the latest "Assigned Numbers" RFC 📚

Here's an example of the option in action 💖

Host1: IAC DO TERMINAL-TYPE

Host2: IAC WILL TERMINAL-TYPE

   (Host1 is now free to request status information at any time.)

Host1: IAC SB TERMINAL-TYPE SEND IAC SE

Host2: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE

6. Implementation Suggestions 🌸

Okay this section is the juicy part 🧁 The "terminal type" info can be any NVT ASCII string that makes sense to both ends of the negotiation. The list of names in "Assigned Numbers" is there to cut down on confusion from different spellings of the same type. For example, it'd be a mess if one side called a terminal IBM3278-2 and the other called it IBM-3278/2 😵‍💫 There's no negative acknowledgement for a terminal type that doesn't get understood. But certain other options, like switching to BINARY mode, may be refused if no valid terminal type name has been specified 🚫

Sometimes one terminal goes by more than one name, like a specific type and a more generic one. In that case, the sender of the TERMINAL-TYPE IS command should reply to each successive TERMINAL-TYPE SEND command with the different names, going from most specific to least specific. That way a telnet server that doesn't recognize the first answer can keep asking for alternatives 🔍 However, it should stop sending TERMINAL-TYPE SEND commands after getting the same response two times in a row 🛑 Similarly, a sender should show it has sent every available name by repeating the last one it sent 🎯

Also, TERMINAL-TYPE IS must only be sent in response to a request (TERMINAL-TYPE SEND). Why? Because a host that sent TERMINAL-TYPE IS and then got a TERMINAL-TYPE SEND couldn't tell whether the other host was asking for a second option, or whether the TERMINAL-TYPE SEND and the TERMINAL-TYPE IS just crossed in midstream 😭 That's a whole vibe mismatch, bestie 🙃

The type "UNKNOWN" should be used if the terminal's type is unknown or unlikely to be recognized by the other party 🤷‍♀️

The complete and up-to-date list of terminal type names will be kept in the "Assigned Numbers". The maximum length of a terminal type name is 40 characters 🎀 And that's the whole thing, periodt 💅✨