Re: Environment Option

Theodore Ts'o <tytso@athena.mit.edu> Fri, 30 July 1993 04:32 UTC

Date: Fri, 30 Jul 1993 00:33:02 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso@athena.mit.edu>
Message-Id: <9307300433.AA22127@tsx-11.MIT.EDU>
To: Jordan Brown <jbrown@qdeck.com>
Cc: stevea@lachman.com, telnet-ietf@cray.com
In-Reply-To: Jordan Brown's message of Thu, 22 Jul 1993 16:06:22 -0700 (PDT), <9307221606.aa21460@angel.qdeck.com>
Subject: Re: Environment Option
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091

   From: Jordan Brown <jbrown@qdeck.com>
   X-Mailer: ScoMail 1.0
   Date: Thu, 22 Jul 1993 16:06:22 -0700 (PDT)

   > 1. Assign a new option value to the Environment option.
   > 	-- this would primarily be done for three reasons
   > 	   A.  Enable detection of up-to-date systems so that the heuristics
   > 	       for interoperability could be safely avoided.
   > 	   B.  Ensure that over time the old option will die out and
   > 	       avoid dragging the heuristics along forever.
   > 	   C.  Implementations that pre-date the introduction of USERVAR
   > 	       will be confused if they ever receive a USERVAR, so in
   > 	       some sense there is an additional problem, even if the 
   > 	       heuristics to detect the VAR/VALUE swap are used

   I favor this approach because it will (one would hope) tend to lead to
   a well-defined deterministic protocol, not one based on imperfect
   heuristics.

   In other words, the situation now is a mess and can't really be cleaned up.
   Throw it away (with perhaps a bit of work for backwards compatibility)
   and make the standard clean.

I favor this approach as well, for the same reasons which Jordan has
brought up.  (Although this should not be all that surprising, since I
was the one who suggested it at the meeting.  :-)

As for HP's assertion that we should 'uphold the output of the RFC
review process as more "correct" than reference implementations of the
RFC/Proposed Standard', at the Proposed Standard, I view this being
completely irrelevant.  

The whole point of the IETF is to produce implementations that work.  In
addition, the situation has been complicated by a relatively large
installed base of a "Proposed Standard", which is still subject to
change --- and it appears that at least some of the people who deployed
this large installed base didn't warn their users that they were basing
their implementation of a standard which was still subject to change.
"Mistakes were made", by many sides.

Our best hope to avoid future problems is to choose a new option number,
and to encourage temporary (== 5 years) usage of hueristics in case a
telnet implementation meets up against an older implementation.

						- Ted

Environment Option Steve Alexander
Re: Environment Option Marjo Mercado
Re: Environment Option David A. Borman
Environment Option Jordan Brown
Re: Environment Option Theodore Ts'o