environment option draft

Steve Alexander <stevea@lachman.com> Fri, 08 October 1993 18:15 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09034; 8 Oct 93 14:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09020; 8 Oct 93 14:15 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa18482; 8 Oct 93 14:15 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19btd) id AA28038; Fri, 8 Oct 93 13:15:21 CDT
Received: by hemlock.cray.com id AA27863; 4.1/CRI-5.6; Fri, 8 Oct 93 13:15:10 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA27857; 4.1/CRI-5.6; Fri, 8 Oct 93 13:14:55 CDT
Received: from laidbak.i88.isc.com by cray.com (4.1/CRI-MX 2.19btd) id AA27998; Fri, 8 Oct 93 13:14:47 CDT
Received: from ra.i88.isc.com by laidbak.i88.isc.com with SMTP (5.65/isc-mail-gw/2/23/93) id AA19042; Fri, 8 Oct 93 13:14:00 -0500
Received: from ra.i88.isc.com by ra.i88.isc.com (4.1/SMI-4.1) id AA28318; Fri, 8 Oct 93 13:14:15 CDT
Message-Id: <9310081814.AA28318@ra.i88.isc.com>
To: telnet-ietf@cray.com
Subject: environment option draft
Cc: klensin@infoods.unu.edu
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Date: Fri, 08 Oct 1993 13:14:14 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Alexander <stevea@lachman.com>

Here's a new draft with the new option number as we discussed in Amsterdam.
Please review carefully so we won't have to change it anymore.  I have also
sent this to Internet-Drafts and it should be out by early next week at the
latest.

Thanks,
-- Steve
   This document specifies a mechanism for passing environment
   information between a telnet client and server.  Use of this
   mechanism enables a telnet user to propagate configuration
   information to a remote host when connecting.                          

   This document corrects some errors in RFC 1408.  In order to
   ensure future interoperability, a new option number has been
   assigned to the environment option by this document.

   This document is intended to replace RFC 1408 as a Proposed
   Standard.





Network Working Group                               S. Alexander, Editor
Internet-Draft                                  Lachman Technology, Inc.
                                                            October 1993


                       Telnet Environment Option

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

   This memo is found in file "draft-ietf-telnet-envmnt-option-02.txt".

Abstract

   This document specifies a mechanism for passing environment
   information between a telnet client and server.  Use of this
   mechanism enables a telnet user to propagate configuration
   information to a remote host when connecting.

   This document corrects some errors in [1].

1.  Command Names and Codes

      ENVIRON         39
          IS               0
          SEND             1
          INFO             2

          VAR              0
          VALUE            1
          ESC              2
          USERVAR          3



                           Expires April 1994                   [Page 1]

Internet-Draft         Telnet Environment Option            October 1993



2.  Command Meanings

   IAC WILL ENVIRON

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

   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
      variables.

   IAC DONT ENVIRON

      The sender of this command refuses to accept environment
      variables.

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

      The sender of this command requests that the remote side send its
      environment variables.  The "type" may be either VAR or USERVAR,
      to indicate either well known or user variable names.  Only the
      side that is DO ENVIRON may initiate a SEND command.  If a list of
      variables is specified, then only those variables should be sent.
      If no list is specified, then the default environment, of 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.

   IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ 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 "type"/VALUE pairs
      must be returned in the same order as the SEND request specified
      them, and there must be a response for each "type ..." explicitly
      requested.  The "type" will be VAR or USERVAR.  Multiple
      environment variables may be sent.  The characters following a
      "type" up to the next "type" or VALUE specify the variable name.
      The characters following a VALUE up to the next "type" specify the
      value of the variable.  If a "type" is not followed by a VALUE
      (e.g., by another VAR, USERVAR, or IAC SE) then that variable is
      undefined.  If a VALUE is immediately followed by a "type" or IAC,



                           Expires April 1994                   [Page 2]

Internet-Draft         Telnet Environment Option            October 1993


      then the variable 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 variable or a value contains a USERVAR, it must be
      sent as ESC USERVAR.  If a variable 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 type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
   ... ] ] IAC SE

      The sender of this command is sending information about
      environment variables that have changed.  It is identical to the
      IS command, except that the command is INFO instead of IS.  Only
      the side that is WILL ENVIRON may send an INFO command.  The INFO
      command 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 propagate changes in environment variables, and may be
      spontaneously 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.

4.  Motivation

   Many operating systems have startup information and environment
   variables 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
   information 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.  Well Known Variables

   USER        This variable is used to transmit the user or account
               name that the client wishes to log into on the remote
               system.  The format of the value the USER variable is
               system dependent, as determined by the remote system.

   JOB         This variable is used to transmit the job ID that the
               client wishes to use when logging into the remote system.
               The format of the value the JOB variable is system



                           Expires April 1994                   [Page 3]

Internet-Draft         Telnet Environment Option            October 1993


               dependent, as determined by the remote system.

   ACCT        This variable is used to transmit the account ID that the
               client wishes to use when logging into the remote system.
               The format of the value the ACCT variable is system
               dependent, as determined by the remote system.

   PRINTER     This variable is used to identify the default location
               for printer output.  Because there does not currently
               exist a standard way of naming a printer on a network,
               the format of this variable is currently undefined.

   SYSTEMTYPE  This is used to transmit the type of operating system on
               the system that sends this variable.  It value is
               identical to the value of the SYSTEM (SYST) command in
               FTP [4].  The format of the value shall have as its first
               word one of the system names listed in the current
               version of the Assigned Numbers document [5].

   DISPLAY     This variable is used to transmit the X display location
               of the client.  The format for the value of the DISPLAY
               variable is:
                  <host>:<dispnum>[.<screennum>]
               This information is identical to the information passed
               using the Telnet X-DISPLAY-LOCATION option.  If both the
               DISPLAY environment variable, and the X-DISPLAY-LOCATION
               option [6] are received, and they contain conflicting
               information, the most recently received information
               received should be used.


   Because it is impossible to anticipate all variables that users may
   wish to exchange, the USERVAR type is provided to allow users to
   transmit arbitrary variable/value pairs.  The use of an additional
   type allows implementations to distinguish between values derived by
   the remote host software and 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.

6.  Implementation Rules

   WILL and DO are used only at the beginning of the connection to
   obtain 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



                           Expires April 1994                   [Page 4]

Internet-Draft         Telnet Environment Option            October 1993


   this option may be used at any time throughout the life of the telnet
   connection, the exchange of environment information will usually
   happen 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
   receives into the environment.  For example, if the client should
   send across USERVAR "TERM" VALUE "xterm" as an environment variable,
   and the TERMINAL-TYPE [3] option has already been used to determine
   the terminal 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 environment.  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 suggested method of implementation, because it allows the user
   the most flexibility.

   The following is an example of use of the option:

       Host1                            Host2
       IAC DO ENVIRON
                                        IAC WILL ENVIRON
       [ Host1 is now free to request environment information ]
       IAC SB ENVIRON SEND VAR "USER"
       VAR "ACCT" VAR USERVAR IAC SE
       [ The server has now explicitly asked for the USER and ACCT
         variables, the default set of well known environment variables,
         and the default set of user defined 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
                                        "kernel" VAR "USER" VALUE "joe"
                                        VAR "DISPLAY" VALUE "foo:0.0"
                                        USERVAR "SHELL" VALUE "/bin/csh"
                                        IAC SE

   It is legal for a client to respond with an empty environment (no
   data between the IAC SB and IAC SE) when no well-defined or user
   variables are currently defined.  For example:

      IAC SB ENVIRON IS IAC SE




                           Expires April 1994                   [Page 5]

Internet-Draft         Telnet Environment Option            October 1993


   is a valid response to any of the following:

      IAC SB ENVIRON SEND IAC SE
      IAC SB ENVIRON SEND VAR IAC SE
      IAC SB ENVIRON SEND USERVAR IAC SE
      IAC SB ENVIRON SEND VAR USERVAR IAC SE

   (The last example is equivalent to the first...)

   The earlier version of this specification [1] incorrectly reversed
   the values for VAR and VALUE,  which this put the specification at
   odds with existing implementations.  In order to resolve that
   problem, as well as other minor problems, a new option number has
   been assigned to the ENVIRON option.  This allows implementations of
   this memo to interoperate with no ambiguity.

   For a discussion on how to implement to interoperate with the various
   implementations that pre-date this memo, see [2].

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

7.  Security Concerns

   It is important for an implementor of the ENVIRON option to
   understand 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.

8.  References

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

   [2] Borman, D., "Telnet Environment Option Interoperability Issues",
       Internet Draft, Cray Research, Inc., April 1993.

   [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



                           Expires April 1994                   [Page 6]

Internet-Draft         Telnet Environment Option            October 1993


       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 are gratefully acknowledged.

Security Considerations

   Security issues are discussed in 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
































                           Expires April 1994                   [Page 7]