Environment Option
Steve Alexander <stevea@lachman.com> Tue, 20 July 1993 01:13 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05065; 19 Jul 93 21:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05061; 19 Jul 93 21:13 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa23089; 19 Jul 93 21:13 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19) id AA21641; Mon, 19 Jul 93 20:14:12 CDT
Received: by hemlock.cray.com id AA04380; 4.1/CRI-5.6; Mon, 19 Jul 93 20:14:06 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA04373; 4.1/CRI-5.6; Mon, 19 Jul 93 20:14:02 CDT
Received: from laidbak.i88.isc.com by cray.com (4.1/CRI-MX 2.19) id AA21608; Mon, 19 Jul 93 20:13:38 CDT
Received: from ra.i88.isc.com by laidbak.i88.isc.com with SMTP (5.65/isc-mail-gw/2/23/93) id AA21457; Mon, 19 Jul 93 19:36:47 -0500
Received: from ra.i88.isc.com by ra.i88.isc.com (4.1/SMI-4.1) id AA07152; Mon, 19 Jul 93 19:37:10 CDT
Message-Id: <9307200037.AA07152@ra.i88.isc.com>
To: telnet-ietf@cray.com
Subject: Environment Option
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Jul 1993 19:37:10 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Alexander <stevea@lachman.com>
Hello -- At the request of the IESG the working group discussed the environment option some more in Amsterdam. Although we had originally intended to revise RFC 1408 to match the BSD code, we now have two new proposals: 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 2. Leave RFC 1408 alone and fix the BSD-based implementations. Vendors could implement the heuristics if they wanted to follow the robustness principle. I would like to see some discussion of this on the mailing list to get a sense for what people who did not attend the meeting think about these proposals. If anyone in the meeting feels that I have mis-represented the options or would like to offer additional clarification, please feel free to comment. Thanks, -- Steve
- 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