Telnet Environment Option
Extracted elements (18)
A generic environment-passing option was created to avoid defining a new Telnet option each time new configuration information needed to be propagated through a session. The option carries arbitrary name/value pairs that the Telnet session itself does not need to interpret.
A new option code was assigned rather than reusing the RFC 1408 option number specifically to eliminate ambiguity caused by the VAR/VALUE value reversal bug. RFC 1571 documents how to interoperate with pre-existing implementations.
The USERVAR type was added to allow transmission of arbitrary user-supplied variable/value pairs, distinct from implementation-derived well-known variables. This lets implementations apply different trust levels, though paranoid implementations will treat both types with equal distrust. Name-space collisions between well-known and user variables are implementation-specific.
RFC 1408, the earlier version of this specification, incorrectly reversed the values for VAR and VALUE, putting the spec at odds with existing implementations. A new option number (39) was assigned to NEW-ENVIRON to allow unambiguous interoperation between implementations of this memo and those of RFC 1408.
A client may respond to a SEND request with an empty IS response (IAC SB NEW-ENVIRON IS IAC SE) when no well-defined or user variables are currently defined.
IAC WILL NEW-ENVIRON indicates the sender is willing to send environment variables; IAC DO NEW-ENVIRON indicates willingness to receive them. WONT and DONT refuse sending and receiving respectively.
Only the side that has sent DO NEW-ENVIRON may initiate a SEND command requesting environment variables. Only the side that has sent WILL NEW-ENVIRON may transmit actual environment data via IS or INFO commands.
The default state is WONT NEW-ENVIRON / DONT NEW-ENVIRON, meaning no environment information will be exchanged unless explicitly negotiated.
The DISPLAY variable uses the format <host>:<dispnum>[.<screennum>] identical to the X-DISPLAY-LOCATION option. If both are received with conflicting values, the most recently received information should be used.
The receiving host is not required to place all received variables into the environment. If the server has determined a variable's value by more accurate means, or does not understand a variable name, it may ignore the value. The suggested implementation is to put all unknown information into the user's environment for maximum flexibility.
WILL and DO are used only at connection start to grant permission for future negotiations. Environment information exchange typically occurs at connection startup because many OSes only support environment propagation at process creation.
NEW-ENVIRON is assigned option code 39. Sub-command codes are: IS=0, SEND=1, INFO=2, VAR=0, VALUE=1, ESC=2, USERVAR=3.
The INFO sub-command (IAC SB NEW-ENVIRON INFO type...[VALUE...] IAC SE) propagates changes to environment variables and may be generated spontaneously. It is identical to IS except it is not used for initial information exchange; the SEND/IS sequence handles that.
The IS sub-command (IAC SB NEW-ENVIRON IS type...[VALUE...] IAC SE) transmits environment variables in response to SEND. Type/VALUE pairs must be returned in the same order as the SEND request, with a response for each explicitly requested type.
The SEND sub-command (IAC SB NEW-ENVIRON SEND [type...] IAC SE) requests the remote side to send environment variables. Type may be VAR (well-known) or USERVAR (user-defined). If no list is specified, the entire default environment of both types is sent.
Well-known VAR names include: USER (login name), JOB (job ID), ACCT (account ID), PRINTER (default printer location), SYSTEMTYPE (OS type, using FTP SYST naming), and DISPLAY (X display in host:dispnum[.screennum] format).
Implementors must carefully analyze which environment variables are safe to set prior to client login/authentication. Permitting a variable to be changed that allows circumvention or compromise of the login/authentication program is explicitly called out as a dangerous implementation choice.
Within IS and INFO payloads, special bytes must be escaped: IAC must be sent as IAC IAC; VAR as ESC VAR; USERVAR as ESC USERVAR; VALUE as ESC VALUE; ESC as ESC ESC. A variable with no following VALUE is undefined; a VALUE immediately followed by type or IAC is defined but empty.