As per Relevance of the word environment, we have this rfc below:
Network Working Group S. Alexander,
Request for Comments: 1572 Lachman Technology, Inc
Category: Standards Track January 1994
Telnet Environment
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document specifies a mechanism for passing
information between a telnet client and server. Use of
mechanism enables a telnet user to propagate
information to a remote host when connecting
This document corrects some errors in [1].
1. Command Names and
NEW-ENVIRON 39
IS 0
SEND 1
INFO 2
VAR 0
VALUE 1
ESC 2
USERVAR 3
2. Command
IAC WILL NEW-
The sender of this command is willing to send
variables
IAC WONT NEW-
The sender of this command refuses to send environment variables
Telnet Working Group [Page 1]
RFC 1572 Telnet Environment Option January 1994
IAC DO NEW-
The sender of this command is willing to receive
variables
IAC DONT NEW-
The sender of this command refuses to accept
variables
IAC SB NEW-ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC
The sender of this command requests that the remote side send
environment variables. The "type" may be either VAR or USERVAR
to indicate either well known or user variable names. Only
side that is DO NEW-ENVIRON may initiate a SEND command. If
list of variables is specified, then only those variables
be sent. If no list is specified, then the default environment
of both well known and user defined variables, should be sent.
one of the variables has no name, then all the variables of
type (well known or user defined) in the default
should be sent
IAC SB NEW-ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ]
[ ... ] ] IAC
The sender of this command is sending environment variables.
command is sent in response to a SEND request. Only the side
is WILL NEW-ENVIRON may send an IS command. The "type"/
pairs must be returned in the same order as the SEND
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
following a "type" up to the next "type" or VALUE specify
variable name. The characters following a VALUE up to the
"type" specify the value of the variable. If a "type" is
followed by a VALUE (e.g., by another VAR, USERVAR, or IAC SE
then that variable is undefined. If a VALUE is
followed by a "type" or IAC, then the variable is defined, but
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
VAR, it must be sent as ESC VAR. If a variable or a
contains a USERVAR, it must be sent as ESC USERVAR. If a
or a value contains a VALUE, it must be sent as ESC VALUE. If
variable or a value contains an ESC, it must be sent as ESC ESC
Telnet Working Group [Page 2]
RFC 1572 Telnet Environment Option January 1994
IAC SB NEW-ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ...
] [ ... ] ] IAC
The sender of this command is sending information
environment variables that have changed. It is identical to
IS command, except that the command is INFO instead of IS.
the side that is WILL NEW-ENVIRON may send an INFO command.
INFO command is not to be used to send initial information;
SEND/IS sequence is to be used for that. The INFO command is
be used to propagate changes in environment variables, and may
spontaneously generated
3. Default
The default specification for this option
WONT NEW-
DONT NEW-
meaning there will not be any exchange of environment information
4.
Many operating systems have startup information and
variables that contain information that should be propagated
remote machines when Telnet connections are established. Rather
create a new Telnet option each time someone comes up with some
information that they need propagated through a Telnet session,
that the Telnet session itself doesn't really need to know about
this generic information option can be used
5. Well Known
USER This variable is used to transmit the user or
name that the client wishes to log into on the
system. The format of the value the USER variable
system dependent, as determined by the remote system
JOB This variable is used to transmit the job ID that
client wishes to use when logging into the remote system
The format of the value the JOB variable is
dependent, as determined by the remote system
ACCT This variable is used to transmit the account ID that
client wishes to use when logging into the remote system
The format of the value the ACCT variable is
dependent, as determined by the remote system
Telnet Working Group [Page 3]
RFC 1572 Telnet Environment Option January 1994
PRINTER This variable is used to identify the default
for printer output. Because there does not
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
the system that sends this variable. It value
identical to the value of the SYSTEM (SYST) command
FTP [4]. The format of the value shall have as its
word one of the system names listed in the
version of the Assigned Numbers document [5].
DISPLAY This variable is used to transmit the X display
of the client. The format for the value of the
variable is
:[.]
This information is identical to the information
using the Telnet X-DISPLAY-LOCATION option. If both
DISPLAY environment variable, and the X-DISPLAY-
option [6] are received, and they contain
information, the most recently received
received should be used
Because it is impossible to anticipate all variables that users
wish to exchange, the USERVAR type is provided to allow users
transmit arbitrary variable/value pairs. The use of an
type allows implementations to distinguish between values derived
the remote host software and values supplied by the user.
implementations will most likely treat both types with an equal
of distrust. The results of a name-space collision between a well
known and a user variable are implementation specific
6. Implementation
WILL and DO are used only at the beginning of the connection
obtain and grant permission for future negotiations
Once the two hosts have exchanged a WILL and a DO, the sender of
DO NEW-ENVIRON is free to request that environment variables be sent
Only the sender of the DO may send requests (IAC SB NEW-ENVIRON
IAC SE) and only the sender of the WILL may transmit
environment information (via the IAC SB NEW-ENVIRON IS ... IAC
command). Though this option may be used at any time throughout
life of the telnet connection, the exchange of
information will usually happen at the startup of the connection
This is because many operating systems only have mechanisms
Telnet Working Group [Page 4]
RFC 1572 Telnet Environment Option January 1994
propagating environment information at process creation, so
information is needed before the user logs in
The receiving host is not required to put all variables that
receives into the environment. For example, if the client
send across USERVAR "TERM" VALUE "xterm" as an environment variable
and the TERMINAL-TYPE [3] option has already been used to
the terminal type, the server may safely ignore the TERM variable
Also, some startup information may be used in other ways;
example, the values for "USER", "ACCT" and "PROJ" values might
used to decide which account to log into, and might never be put
the users environment. In general, if the server has
determined the value of an environment variable by some more
means, or if it does not understand a variable name, it may
the value sent in the NEW-ENVIRON option. The server may also
to just put all unknown information into the users environment.
is the suggested method of implementation, because it allows the
the most flexibility
The following is an example of use of the option
Host1 Host
IAC DO NEW-
IAC WILL NEW-
[ Host1 is now free to request environment information ]
IAC SB NEW-ENVIRON SEND
"USER" VAR "ACCT" VAR
IAC
[ The server has now explicitly asked for the USER and
variables, the default set of well known environment variables
and the default set of user defined variables. Note that
client includes the USER information twice; once because it
explicitly asked for, and once because it is part of
default environment. ]
IAC SB NEW-ENVIRON IS VAR "USER
VALUE "joe" VAR "ACCT"
"kernel" VAR "USER" VALUE "joe
VAR "DISPLAY" VALUE "foo:0.0"
USERVAR "SHELL" VALUE "/bin/csh
IAC
It is legal for a client to respond with an empty environment (
data between the IAC SB and IAC SE) when no well-defined or
variables are currently defined. For example
IAC SB NEW-ENVIRON IS IAC
is a valid response to any of the following
Telnet Working Group [Page 5]
RFC 1572 Telnet Environment Option January 1994
IAC SB NEW-ENVIRON SEND IAC
IAC SB NEW-ENVIRON SEND VAR IAC
IAC SB NEW-ENVIRON SEND USERVAR IAC
IAC SB NEW-ENVIRON SEND VAR USERVAR IAC
(The last example is equivalent to the first...)
The earlier version of this specification [1] incorrectly
the values for VAR and VALUE, which put the specification at
with existing implementations. In order to resolve that problem,
well as other minor problems, a new option number has been
to the NEW-ENVIRON option. This allows implementations of this
to interoperate with no ambiguity
For a discussion on how to implement to interoperate with the
implementations that pre-date this memo, see [2].
It is expected that any implementation that supports the Telnet NEW
ENVIRON option will support all of this specification
7. Security
It is important for an implementor of the NEW-ENVIRON option
understand the interaction of setting options and
login/authentication process. Specifically careful analysis should
done to determine which variables are "safe" to set prior to
the client login. An example of a bad choice would be permitting
variable to be changed that allows an intruder to circumvent
compromise the login/authentication program itself
8.
[1] Borman, D., Editor, "Telnet Environment Option", RFC 1408,
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,
Software, Inc., February 1989.
[4] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
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.
Telnet Working Group [Page 6]
RFC 1572 Telnet Environment Option January 1994
[6] Marcy, G., "Telnet X Display Location Option", RFC 1096,
Mellon University, March 1989.
The original version of this document was written by Dave Borman
Cray Research, Inc. In addition, the comments of the Telnet
Group of the IETF are gratefully acknowledged
Security
Security issues are discussed in Section 7.
Editor's
Steve
Lachman Technology, Inc
1901 North Naper
Naperville, IL 60563-8895
Phone: (708) 505-9555 x256
EMail: stevea@lachman.
Telnet Working Group [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
