





Network Working Group                    Internet Engineering Task Force
Internet-Draft                                      Telnet Working Group
                                                       D. Borman, Editor
                                                     Cray Research, Inc.
                                                               July 1990


                       TTeellnneett EEnnvviirroonnmmeenntt OOppttiioonn

Status of this Memo

   This draft document will be submitted to the RFC editor as a protocol
   specification.  Distribution of this memo is unlimited.  Please send
   comments to the telnet-ietf@cray.com mailing list.

1.  Command Names and Codes

      ENVIRON         36
          IS               0
          SEND             1
          INFO             2

          VAR              0
          VALUE            1
          ESC              2

2.  Command Meanings

   IAC WILL ENVIRON

      The sender of this command is willing to send environment vari-
      ables.

   IAC WONT ENVIRON

      The sender of this command refuses to send environment variables.

   IAC DO ENVIRON

      The sender of this command is willing to receive environment vari-
      ables.

   IAC DONT ENVIRON

      The sender of this command refuses to accept environment vari-
      ables.




Telnet Working Group                                            [Page 1]

Internet-Draft         Telnet Environment Option               July 1990


   IAC SB ENVIRON SEND [ VAR ... [ VAR ... [ ... ] ] ] IAC SE

      The sender of this command requests that the remote side send its
      environment variables.  Only the side that is DO ENVIRON may ini-
      tiate a SEND command.  If a list of variables is specified, then
      only those variables should be sent.  If no list is specified, or
      if one of the variables has no name, then the default environment
      should be sent.

   IAC SB ENVIRON IS VAR ... [ VALUE ... ] [ VAR ... [ VALUE ... ] [ ...
   ] ] IAC SE

      The sender of this command is sending environment variables.  This
      command is sent in response to a SEND request.  Only the side that
      is WILL ENVIRON may send an IS command.  The VAR/VALUE pairs must
      be returned in the same order as the SEND request specified them.
      Multiple environment variables may be sent.  The characters fol-
      lowing a VAR up to the next VAR or VALUE specifiy the variable
      name.  The characters following a VALUE up to the next VAR specify
      the value of the variable.  If a VAR is not followed by a VALUE
      (e.g., by another VAR or an IAC) then that variable is undefined.
      If a VALUE is immediatly followed by a VAR or IAC, then the vari-
      able is defined, but has no value.  If an IAC is contained 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 a vari-
      able or a value contains a VALUE, it must be sent as ESC VALUE.
      If a variable or a value contains an ESC, it must be sent as ESC
      ESC.

   IAC SB ENVIRON INFO VAR ... [ VALUE ... ] [ VAR ... [ VALUE ... ] [
   ... ] ] IAC SE

      The sender of this command is sending information about environ-
      ment variables that have changed.  It is identical to the IS com-
      mand, except that the command is INFO instead of IS.  Only the
      side that is WILL ENVIRON may send an INFO command.  The INFO com-
      mand is not to be used to send initial information; the SEND/IS
      sequence is to be used for that.  The INFO command is to be used
      to propogate changes in environment variables, and may be spon-
      taneously generated.


3.  Default Specification

   The default specification for this option is

      WONT ENVIRON
      DONT ENVIRON

   meaning there will not be any exchange of environment information.



Telnet Working Group                                            [Page 2]

Internet-Draft         Telnet Environment Option               July 1990


4.  Motivation

   Many operating systems have startup information and environment vari-
   ables that contain information that should be propagated to remote
   machines when Telnet connections are established.  Rather than create
   a new Telnet option each time someone comes up with some new informa-
   tion that they need propagated through a Telnet session, but that the
   Telnet session itself doesn't really need to know about, this generic
   information option can be used.

5.  Implementation Rules

   WILL and DO are used only at the beginning of the connection to ob-
   tain and grant permission for future negotiations.

   Once the two hosts have exchanged a WILL and a DO, the sender of the
   DO ENVIRON is free to request that environment variables be sent.
   Only the sender of the DO may send requests (IAC SB ENVIRON SEND IAC
   SE) and only the sender of the WILL may transmit actual environment
   information (via the IAC SB ENVIRON IS ... IAC SE command).  Though
   this option may be used at anytime throughout the life of the telnet
   connection, the exchange of environment information will usually hap-
   pen at the startup of the connection.  This is because many operating
   systems only have mechanisms for propagating environment information
   at process creation, so the information is needed before the user
   logs in.

   The receiving host is not required to put all variables that it re-
   ceives into the environment.  For example, if the client should send
   across VAR "TERM" VALUE "xterm" as an environment variable, and the
   TERMINAL-TYPE [1] option has already been used to determine the ter-
   minal type, the server may safely ignore the TERM variable.  Also,
   some startup information may be used in other ways; for example, the
   values for "USER", "ACCT" and "PROJ" values might be used to decide
   which account to log into, and might never be put into the users en-
   vironment.  In general, if the server has already determined the
   value of an environment variable by some more accurate means, or if
   it does not understand a variable name, it may ignore the value sent
   in the ENVIRON option.  The server may also prefer to just put all
   unknown information into the users environment.  This is the suggest-
   ed method of implementation, because it allows the user the most
   flexability.

   The following is an example of use of the option:

       _H_o_s_t_1                            _H_o_s_t_2
       IAC DO ENVIRON
                                        IAC WILL ENVIRON
       [ Host1 is now free to request environment information ]
       IAC SB ENVIRON SEND VAR "USER"



Telnet Working Group                                            [Page 3]

Internet-Draft         Telnet Environment Option               July 1990


       VAR "ACCT" VAR IAC SE
       [ The server has now explicitly asked for the USER and ACCT vari-
         ables, and the default set of environment variables.  Note that
         the client includes the USER information twice; once because it
         was explicitly asked for, and once because it is part of the
         default environment.  ]
                                        IAC SB ENVIRON IS VAR "USER"
                                        VALUE "joe" VAR "ACCT" VALUE
                                        "kernal" VAR "USER" VALUE "joe"
                                        VAR "DISPLAY" VALUE "foo:0.0"
                                        VAR "SHELL" VALUE "/bin/csh" IAC
                                        SE

   It is expected that any implementation that supports the Telnet EN-
   VIRON option will support all of this specification.

6.  Security Concerns

   It is important for an implementor of the ENVIRON option to under-
   stand the interaction of setting options and the login/authentication
   process. Specifically careful analysis should be done to determine
   which variables are "safe" to set prior to having the client login.
   An example of a bad choice would be permitting a variable to be
   changed that allows an intruder to circumvent or compromise the
   login/authentication program itself.
7.  References


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

Author's Address

   David A. Borman, Editor
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

   Phone: (612) 452-6650

   Mailing List: telnet-ietf@CRAY.COM
   EMail: dab@CRAY.COM











Telnet Working Group                                            [Page 4]

