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