RFC 1572

RFC 1572: Telnet Environment Option 💅

Okay bestie, let's get into RFC 1572 🎀. It's called Telnet Environment Option, and it's a Standards Track doc, so it's a real protocol spec for the Internet community 🌈. It's from the Network Working Group, S. Alexander is the Editor, the people behind it are at Lachman Technology, Inc., and it's dated January 1994 📅. The title block doesn't list anything it obsoletes or updates, but the Abstract says it corrects some errors in [1] 🔥.

---

Status of this Memo ✨

Here's the status tea 💜. This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.

Abstract 🌸

This doc lays out a way to pass environment info between a telnet client and server 🧚. With it, a telnet user can push configuration info to a remote host when connecting. It also corrects some errors in [1] 🫶.

---

1. Command Names and Codes 💅

Here are the codes you need to know. NEW-ENVIRON is option 39, and it has its own little set of numbers 🔢.

      NEW-ENVIRON     39
          IS               0
          SEND             1
          INFO             2

          VAR              0
          VALUE            1
          ESC              2
          USERVAR          3

2. Command Meanings 🔥

Let's go through what each command means, bestie 🎀.

IAC WILL NEW-ENVIRON

The sender of this command is willing to send environment variables 💖.

IAC WONT NEW-ENVIRON

The sender of this command refuses to send environment variables 🙈.

IAC DO NEW-ENVIRON

The sender of this command is willing to receive environment variables ✨.

IAC DONT NEW-ENVIRON

The sender of this command refuses to accept environment variables 💀.

SEND request

IAC SB NEW-ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE

This is the sender asking the remote side to send its environment variables 🦋. The "type" MAY be either VAR or USERVAR, which is how you ask for well known or user variable names. Only the side that is DO NEW-ENVIRON MAY start a SEND. If you list specific variables, then only those SHOULD be sent. If you don't list any, then the default environment, both well known and user defined variables, SHOULD be sent. If one of the variables has no name, then all the variables of that type (well known or user defined) in the default environment SHOULD be sent. Main character energy 👑.

IS (sending variables)

IAC SB NEW-ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ]
[ ... ] ] IAC SE

Now the sender is actually sending its environment variables 🎀. This is sent in response to a SEND request, and only the side that is WILL NEW-ENVIRON MAY send an IS. The "type"/VALUE pairs MUST be returned in the same order the SEND request listed them, and there MUST be a response for each "type ..." that was explicitly asked for. The "type" will be VAR or USERVAR, and multiple variables can be sent in one go 🌈.

Here's how the parsing works. The characters after a "type" (up to the next "type" or VALUE) are the variable name. The characters after a VALUE (up to the next "type") are the value. If a "type" isn't followed by a VALUE (like by another VAR, USERVAR, or IAC SE), that variable is undefined 🙅. If a VALUE is immediately followed by a "type" or IAC, the variable is defined but has no value ✨.

Escaping is a whole thing 😭. If an IAC shows up between the IS and the IAC SE, it MUST be sent as IAC IAC. If a variable or a value contains a VAR, it MUST be sent as ESC VAR. If it contains a USERVAR, it MUST be sent as ESC USERVAR. If it contains a VALUE, it MUST be sent as ESC VALUE. If it contains an ESC, it MUST be sent as ESC ESC. Iconic behavior, honestly 💅.

INFO (changed variables)

IAC SB NEW-ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ...
] [ ... ] ] IAC SE

INFO is basically the same as IS, just with the command name swapped 🦋. The sender is telling the other side about environment variables that have changed. Only the side that is WILL NEW-ENVIRON MAY send an INFO. INFO is NOT for sending initial info, since SEND/IS is the move for that 🙅‍♀️. INFO is for propagating changes to environment variables, and it MAY be spontaneously generated 🔥.

---

3. Default Specification 🌸

The default for this option is:

WONT NEW-ENVIRON
DONT NEW-ENVIRON

Which means there is no exchange of environment info at all 🫶.

4. Motivation 💖

Lots of operating systems have startup info and environment variables that SHOULD be propagated to remote machines when Telnet connections get set up 🧚. Instead of making a brand-new Telnet option every time someone needs some new info passed along in a session (info the Telnet session itself doesn't really need to know about), this generic info option can do the job 🎀.

5. Well Known Variables 🧚

Here are the well known variables, bestie ✨:

• USER: transmits the user or account name the client wants to log into on the remote system. The format of the value is system dependent, as determined by the remote system 💅.
• JOB: transmits the job ID the client wants to use when logging into the remote system. Like USER, the format is system dependent, as determined by the remote system 🦋.
• ACCT: transmits the account ID the client wants to use when logging into the remote system. Format is system dependent, as determined by the remote system 💜.
• PRINTER: identifies the default location for printer output. There's no standard way of naming a printer on a network yet, so the format is currently undefined 🖨️.
• SYSTEMTYPE: transmits the type of operating system on the system sending this variable. Its value is identical to the value of the SYSTEM (SYST) command in FTP [4]. The format SHALL have as its first word one of the system names listed in the current version of the Assigned Numbers document [5] 👑.
• DISPLAY: transmits the X display location of the client 🌈. The format for its value is:

<host>:<dispnum>[.<screennum>]

This is the same info passed using the Telnet X-DISPLAY-LOCATION option [6] 🎀. If both the DISPLAY environment variable and the X-DISPLAY-LOCATION option [6] are received and they conflict, the most recently received information SHOULD be used ⏱️.

Because it is impossible to anticipate every variable users might want to exchange, the USERVAR type exists so users can transmit arbitrary variable/value pairs 🌸. Using a separate type lets implementations tell apart values derived by the remote host software from values supplied by the user 🔍. Paranoid implementations will most likely treat both types with an equal level of distrust 😭. The results of a name-space collision between a well-known and a user variable are implementation specific 🦋.

7. Security Concerns 🔐

okay bestie, this section is SERIOUS 😭 if you're implementing the NEW-ENVIRON option, you NEED to understand how setting options interacts with the login/authentication process 🫶 it's giving "who gets past the bouncer" energy.

Careful analysis should be done to figure out which variables are "safe" to set before the client has logged in 🙈 ngl this is the part where you really have to think. A really bad choice would be letting a variable get changed in a way that lets an intruder circumvent or compromise the login/authentication program itself 💀 absolutely not. 🚫

8. References 📚

[1] Borman, D., Editor, "Telnet Environment Option", RFC 1408, Cray Research, Inc., January 1993.

[2] Borman, D., "Telnet Environment Option Interoperability Issues", RFC 1571, Cray Research, Inc., January 1994.

[3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP Software, Inc., February 1989.

[4] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.

[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.

[6] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie Mellon University, March 1989.

Acknowledgements 🫶

The original version of this document was written by Dave Borman of Cray Research, Inc. In addition, the comments of the Telnet Working Group of the IETF are gratefully acknowledged. so grateful for them 💖

Security Considerations 🛡

Security issues are discussed in Section 7. seriously, go read Section 7 🔥

Editor's Address 📬

Steve Alexander
Lachman Technology, Inc.
1901 North Naper Boulevard
Naperville, IL 60563-8895

Phone: (708) 505-9555 x256
EMail: stevea@lachman.com