As per Relevance of the word environment, we have this rfc below:
Network Working Group D.
Request for Comments: 1571 Cray Research, Inc
Updates: 1408 January 1994
Category:
Telnet Environment Option Interoperability
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
RFC 1408 [1], the specification for the Telnet Environment Option
specifies definitions for VAR and VALUE that are reversed from
BSD implementation of the Telnet Environment option. Since the
implementation was the reference implementation that the RFC
supposed to document, and is the base for many
implementations, there exists an interoperability problem
implementations with conflicting definitions for VAR and VALUE
This document describes a method for allowing implementors to
that their implementation of the Environment option will
interoperable with as many other implementations as possible,
providing a set of heuristics that can be used to help identify
definitions for VAR and VALUE are being used by the other side of
connection
2. Client Telnet: Parsing a
The SEND suboption should only contain VAR and USERVAR commands.
should never contain a VALUE. If while parsing a SEND suboption,
VALUE is encountered, the client should assume that the server
reversed values for VAR and VALUE, and from that point on the
should reverse those values, both in parsing the rest of the
suboption, and when generating an IS or INFO suboption. If
VALUE and VAR commands are encountered, the SEND command is not
formed, and it is implementation dependent as to what will happen
If there are not VAR or VALUE commands in the SEND suboption,
the client cannot know what values the server is expecting for
and VALUE. In this case, it should just assume that the server
the correct definitions, and use the correct values for VAR
VALUE
Telnet Working Group [Page 1]
RFC 1571 Environment Option Interoperability January 1994
3. Server Telnet: Parsing an IS or
The IS or INFO in a suboption can only be legally followed by
a VAR or a USERVAR. If an IS or INFO is immediately followed by
VAR, then it can be assumed that the client has the
definitions for VAR and VALUE. If the IS or INFO is
followed by a VALUE, then it can be assumed that the client
reversed definitions for VAR and VALUE, and from that point on
server should assume that the VALUE and VAR definitions are reversed
If the IS or INFO is immediately followed by a USERVAR,
hueristics must be applied to determine what are the
definitions for VAR and VALUE. This is because it is legal for
USERVAR to be followed by either a VAR or a VALUE. A VALUE after
USERVAR gives the value for the USERVER. A VAR after a
implies that the USERVAR is undefined
The next thing to do is to scan the entire suboption, looking for
consecutive instances of VAR or VALUE, or for a VAR or VALUE that
empty. It is not legal for a suboption to contain two VALUEs
an intervening VAR or USERVAR, and it is also not legal for
suboption to contain an empty VAR. Thus, if two consecutive VARs
an empty VALUE can be found, it can be assumed that the client
generated the suboption uses the correct definitions for VAR
VALUE. If two consecutive VALUEs or an empty VAR can be found,
it can be assumed that the client that generated the suboption
reversed definitions for VAR and VALUE, and from that point on
server should assume that the VAR and VALUE definitions are reversed
If things are still in doubt, the next test that can be applied is
count up how many VARs, USERVARs and VALUEs were received
(Consecutive USERVARs without an intervening VALUE or VAR should
be counted as one.) Because a VALUE can only follow a VAR or
USERVAR, there can never be more VALUEs than the sum of VARs
USERVARs, and if all VARs and USERVARs have values, then there
be exactly as many VALUEs as there are VARs and USERVARs. If
number of VARs and USERVARs is the same as the total number
VALUEs, then the client has correct definitions for VAR and VALUE
If the number of VALUEs and USERVARs is the same as the total
of VARs, then the client has reversed definitions for VAR and VALUE
If the number of VALUEs is more than the sum of VARs and USERVARs,
can be assumed that the client has reversed definitions of VAR
VALUE, and if there are more VARs than USERVARs and VALUEs, then
can be assumed that the client has the correct definitions for
and VALUE. However, in order to get to this step, it has
been determined that there are no consecutive VARs and VALUEs.
little math will show that this means that the number of VALUEs
Telnet Working Group [Page 2]
RFC 1571 Environment Option Interoperability January 1994
never exceed the sum of VARs and USERVARs, and the number of
will never exceed the sum of VALUEs and USERVARs. Hence, this
is redundant and can be skipped
If things are still in doubt, the values of the VAR commands can
checked to see if they do indeed specify well known variables.
any of them do, then the client is probably using the
definitions for VAR and VALUE. Otherwise, if any of the
contain well know variable names, then the client probably
reversed definitions for VAR and VALUE
If all the above heuristics fail, then the server has done all it
to determine what type of client it is, and it should just be
that the client is using the correct definitions for VAR and VALUe
4. Client
The SEND suboption contains only VAR and USERVAR commands
The server is ok
The SEND suboption contains VALUE commands
The server is reversed
No VAR or VALUE commands are found
Assume the server is ok
5. Server
IS/INFO is followed by VAR
The client is ok
IS/INFO is followed by VALUE
The client is reversed
There are two consecutive VARs
The client is ok
There are consecutive VALUEs
The client is reversed
There is an empty VALUE
The client is ok
There is an empty VAR
The client is reversed
The number of USERVARs and VARs is equal to the number of VALUEs
Assume the client is ok
The number of USERVARs and VALUEs is equal to the number of VARs
Assume the client is reversed
There are VARs with names that are well known
Assume the client is ok
There are VALUEs with names that are well known
Assume the client is reversed
Anything else
Assume the client is ok
Telnet Working Group [Page 3]
RFC 1571 Environment Option Interoperability January 1994
[1] Borman, D., Editor, "Telnet Environment Option", RFC 1408,
Research, Inc., January 1993.
Security
Security issues are not discussed in this memeo
Author's
David A.
Cray Research, Inc
655F Lone Oak
Eagan, MN 55123
Phone: (612) 452-6650
EMail: dab@CRAY.
Telnet Working Group Mailing List: telnet-ietf@CRAY.
Telnet Working Group [Page 4]
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
