RFC 1091

Telnet Terminal-Type Option 🎀

okay bestie, this is RFC 1091 🧚 (Request for Comments: 1091). It's titled "Telnet Terminal-Type Option," it's from the Network Working Group, and J. VanBokkelen at FTP Software, Inc. wrote it 💖. It's a standard for the Internet community 👑 and it's dated February 1989 📅. It also obsoletes RFC 930 💅, so 930 is officially retired and this one is the new hotness ✨.

Status of This Memo ✨

This RFC specifies a standard for the Internet community 👑. Hosts on the Internet that swap terminal type info within the Telnet protocol are expected to adopt and implement this standard 🫶.

This standard supersedes RFC 930 🙌. A change is made so you can cycle through a list of possible terminal types and pick the most appropriate one 🔄.

Distribution of this memo is unlimited 🌈.

1. Command Name and Code 🎀

      TERMINAL-TYPE   24

2. Command Meanings 💖

• IAC WILL TERMINAL-TYPE: the sender is willing to send terminal type info in a subsequent sub-negotiation 🦋.
• IAC WON'T TERMINAL-TYPE: the sender refuses to send terminal type info 🙅‍♀️.
• IAC DO TERMINAL-TYPE: the sender is willing to receive terminal type info in a subsequent sub-negotiation 🫶.
• IAC DON'T TERMINAL-TYPE: the sender refuses to accept terminal type info 💀.
• IAC SB TERMINAL-TYPE SEND IAC SE: the server asks the client to send his (the client's) next terminal type, and to switch emulation modes if more than one terminal type is supported 🔥. The code for SEND is 1. (See below.)
• IAC SB TERMINAL-TYPE IS ... IAC SE: the client is stating the name of his current (or only) terminal type 🍓. The code for IS is 0. (See below.)

3. Default 🍓

• WON'T TERMINAL-TYPE: terminal type info will not be exchanged 🙈.
• DON'T TERMINAL-TYPE: terminal type info will not be exchanged 🙈.

4. Motivation for the Option 🌸

okay so on most machines with bit-mapped displays (think PCs and graphics workstations 💻), a client terminal emulation program is used to pretend to be a conventional ASCII terminal 🖥️. Most of these programs have multiple emulation modes, and they often have wildly different characteristics 🌈. Meanwhile, modern host system software and applications can handle a whole variety of terminal types too 🤹. So what's needed is a way for the client to show the server a list of available terminal emulation modes 📋, so the server can pick the one it prefers (for arbitrary reasons 🤷‍♀️). There's also a need for a mechanism to change emulation modes during a session, maybe based on what the applications programs need ✨.

Existing terminal-type passing mechanisms within Telnet were not designed with multiple emulation modes in mind 🙈. Multiple names are allowed, sure, but they're assumed to be synonyms 👯. Emulation mode changes are not defined at all, and the list of modes can only be scanned once 😤.

This document defines a simple extension to the existing mechanisms, and it meets both of the criteria above 🦋. It makes one assumption about the behaviour of implementations coded to the previous standard, so that you get full backwards-compatibility 🫶.

5. Description of the Option 🦋

Willingness to exchange terminal-type info gets agreed on through regular Telnet option negotiation 🤝. WILL and DO are only used to get and grant permission for future discussion 🙋. The actual exchange of status info happens inside option subcommands, like IAC SB TERMINAL-TYPE... 💬.

Once the two hosts have exchanged a WILL and a DO, the sender of the DO TERMINAL-TYPE (the server) is free to request type info 🙌. Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE), and only the client may transmit actual type info (within an IAC SB TERMINAL-TYPE IS ... IAC SE command) 🎀. Terminal type info may not be sent spontaneously, only in response to a request 🙅‍♀️.

The terminal type info is an NVT ASCII string 🔤. Within this string, upper and lower case are considered equivalent 🔠. The complete list of valid terminal type names can be found in the latest "Assigned Numbers" RFC [4] 📚.

The transmission of terminal type info by the Telnet client in response to a query from the Telnet server implies that the client must simultaneously change emulation mode 🔁, unless the terminal type sent is a synonym of the preceding terminal type, or there are other prerequisites for entering the new regime (e.g., having agreed upon the Telnet binary option). The receipt of such info by the Telnet server does not imply any immediate change of processing 🐢. However, the info may be passed to a process, which may alter the data it sends to suit the particular characteristics of the terminal 🧠. For example, some operating systems have a terminal driver that accepts a code indicating the type of terminal being driven 💻. Using the TERMINAL TYPE and BINARY options, a telnet server program on such a system could arrange to have terminals driven as if they were directly connected, including special functions not available to a standard Network Virtual Terminal ⭐.

Note that this specification is deliberately asymmetric 🙃. It is assumed that server operating systems and applications in general cannot change terminal types at arbitrary points in a session. Thus, the client may only send a new type (and potentially change emulation modes) when the server requests that it do so 💖.

Author's Address 🎀

okay so this is where we find out who wrote the whole thing! 💖 James VanBokkelen from FTP Software, Inc. is the author, and his contact info is right here 🦋

James VanBokkelen
FTP Software, Inc.
26 Princess Street
Wakefield, MA 01880-3004

Phone: (617) 246-0900

Email: jbvb@ftp.com

and that's the whole RFC, bestie 💅✨