Telnet Environment Option Interoperability Issues
RFC 1571

Document Type RFC - Informational (January 1994; No errata)
Updates RFC 1408
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 1571 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          D. Borman
Request for Comments: 1571                           Cray Research, Inc.
Updates: 1408                                               January 1994
Category: Informational

           Telnet Environment Option Interoperability Issues

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

1.  Overview

   RFC 1408 [1], the specification for the Telnet Environment Option,
   specifies definitions for VAR and VALUE that are reversed from the
   BSD implementation of the Telnet Environment option.  Since the BSD
   implementation was the reference implementation that the RFC was
   supposed to document, and is the base for many existing
   implementations, there exists an interoperability problem between
   implementations with conflicting definitions for VAR and VALUE.

   This document describes a method for allowing implementors to ensure
   that their implementation of the Environment option will be
   interoperable with as many other implementations as possible, by
   providing a set of heuristics that can be used to help identify which
   definitions for VAR and VALUE are being used by the other side of the
   connection.

2.  Client Telnet: Parsing a SEND

   The SEND suboption should only contain VAR and USERVAR commands.  It
   should never contain a VALUE.  If while parsing a SEND suboption, a
   VALUE is encountered, the client should assume that the server has
   reversed values for VAR and VALUE, and from that point on the client
   should reverse those values, both in parsing the rest of the SEND
   suboption, and when generating an IS or INFO suboption.  If both
   VALUE and VAR commands are encountered, the SEND command is not well
   formed, and it is implementation dependent as to what will happen.

   If there are not VAR or VALUE commands in the SEND suboption, then
   the client cannot know what values the server is expecting for VAR
   and VALUE.  In this case, it should just assume that the server has
   the correct definitions, and use the correct values for VAR and
   VALUE.

Telnet Working Group                                            [Page 1]
RFC 1571          Environment Option Interoperability       January 1994

3.  Server Telnet: Parsing an IS or INFO

   The IS or INFO in a suboption can only be legally followed by either
   a VAR or a USERVAR.  If an IS or INFO is immediately followed by a
   VAR, then it can be assumed that the client has the correct
   definitions for VAR and VALUE.  If the IS or INFO is immediately
   followed by a VALUE, then it can be assumed that the client has
   reversed definitions for VAR and VALUE, and from that point on the
   server should assume that the VALUE and VAR definitions are reversed.

   If the IS or INFO is immediately followed by a USERVAR, further
   hueristics must be applied to determine what are the client
   definitions for VAR and VALUE. This is because it is legal for a
   USERVAR to be followed by either a VAR or a VALUE.  A VALUE after a
   USERVAR gives the value for the USERVER.  A VAR after a USERVAR
   implies that the USERVAR is undefined.

   The next thing to do is to scan the entire suboption, looking for two
   consecutive instances of VAR or VALUE, or for a VAR or VALUE that is
   empty.  It is not legal for a suboption to contain two VALUEs without
   an intervening VAR or USERVAR, and it is also not legal for a
   suboption to contain an empty VAR.  Thus, if two consecutive VARs or
   an empty VALUE can be found, it can be assumed that the client that
   generated the suboption uses the correct definitions for VAR and
   VALUE.  If two consecutive VALUEs or an empty VAR can be found, then
   it can be assumed that the client that generated the suboption has
   reversed definitions for VAR and VALUE, and from that point on the
   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 to
   count up how many VARs, USERVARs and VALUEs were received.
   (Consecutive USERVARs without an intervening VALUE or VAR should only
   be counted as one.) Because a VALUE can only follow a VAR or a
   USERVAR, there can never be more VALUEs than the sum of VARs and
   USERVARs, and if all VARs and USERVARs have values, then there will
   be exactly as many VALUEs as there are VARs and USERVARs.  If the
   number of VARs and USERVARs is the same as the total number of
   VALUEs, then the client has correct definitions for VAR and VALUE.
   If the number of VALUEs and USERVARs is the same as the total number
   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, it
   can be assumed that the client has reversed definitions of VAR and
   VALUE, and if there are more VARs than USERVARs and VALUEs, then it
Show full document text