Re: Environment Option

["David A. Borman" <[e-mail]>]

This message is in two parts.  The first part is a report in much
more detail of what happened at the Telnet WG meeting in Amsterdam,
with regards to the Environment option.  It also spells out clearly
what decisions were made at that meeting, and what future actions
were agreed on.  The last part contains my own comments.

In short:
	In Amsterdam, the Telnet WG voted 7 to 3 to reissue
	the Environment option with a new option number.  These
	results are to be posted to the mailing list, and if
	there are no serious new objections to that decision,
	that will be the decision of the WG

And now for the details...

Background
----------
The issue at hand is that the BSD based implementation of the
Environment option has the value for VAR and VALUE swapped from
what RFC-1408 says.  We all know this.  When this was discovered,
it was proposed that RFC-1408 be re-issued with definitions for
VAR and VALUE that match the BSD implementation.  HP objected to
making the change, since they are already shipping products based
on the RFC-1408 definitions.  The WG decided to re-issue the
RFC, changing VAR and VALUE to match the BSD implementation.

At the same time, I wrote up some heuristics that can be used
to detect whether or not the other side of a telnet connection
has the same or reversed definitions for VAR and VALUE.  It was
proposed that implementations use these to aid in interoperability.

HP continued to object, and raised the issue with the IESG. The
upshot of the IESG response was that they refused to either uphold
or overturn the WG decision to reissue RFC-1408.  Instead, they
said that the WG would have to revisit the decision to reissue
RFC-1408 and decide whether or not the heuristics were a good long
term solution, and then whatever the WG decided, the IESG would
back the Working Group decision.

The IESG did iterate that the Environment option is just at the
Proposed level, and when vendors implement Proposed specifications
into products, they are assuming the risk that they may very well
have to change their implementation, since Proposed standards can
change.  Installed base may be a good argument for not changing a
Draft or full Standard, but it is not a good argument for not
changing a Proposed Standard.  In part this is why the IESG pushed
the decision back to the WG.

So, in Amsterdam those in attendance at the Telnet WG meeting
went over the whole issue again.

The Discussion as Amsterdam
---------------------------
It was agreed that there is no technical reason for picking one
definition over the other, both will work just fine.  If there was
a technical reason, the answer would be easy.  Everyone agreed that
the only reason for considering changing the definitions and doing
the heuristics was to allow new implementations to be interoperable
with existing implementations, and all the future discussion was
held with this in mind.

The working group thus had two issues to discuss.  First, should the
values for VAR and VALUE be changed, and second, should the heuristics
be published as an interoperability solution, which would be in use
forever.  The group decided to attack the second question first,
hoping that it would lead to the answer to the first question.

Problems with the Heuristics
----------------------------
The problem with the heuristics is that there are situations
where they are not deterministic, and you cannot guarantee that
you know what definitions are in use on the other side.  Most
of the group agreed that it would be good to be able to get to
a point in the future when using the Environment option could be
done in a deterministic manner.

Leaving the definitions for VAR/VALUE alone, or reversing them
would not achieve this.  The only way to do this is to get new
definitions that are not ambiguous.

Proposal for new VAR/VALUE definitions
--------------------------------------
The first proposed solution was to define entirely new values
for VAR and VALUE.  If you got either 0/1 or 1/0, it would mean
that you had an old host, and you would do the best you could
using the heuristics.  If you got the new VAR/VALUE values,
then you would know exactly what to do.

The problem with this is trying to decide whether or not to
send the new VAR/VALUE values, since old hosts would really
be confused if they got these new values, even more than if
they had just gotten reversed definitions for VAR and VALUE.
(There is more detail that was discussed, and I'll type it
 up if there is a request for it...)

Counter proposal to have a new Telnet Option Number
---------------------------------------------------
A counter proposal was that rather than define new values for
VAR and VALUE within the existing Environment option, that instead
a new Telnet Option number would be assigned to the Environment
option, and the old option number would be deprecated.

The advantage of this is that for the cost of sending both "IAC DO
NEW-ENVIRON" and "IAC DO OLD-ENVIRON" at connection establishment,
implementations that implement the new option number would be positively
identified, and no heuristics would be needed when talking to those
implementations.

If the NEW-ENVIRON was not recognized, but OLD-ENVIRON was, then
things would be exactly as they are today.  Either you just use
what ever definitions you have used in the past for VAR and VALUE,
or you use the heuristics to try and interoperate with a reversed
implementation.

In the long run, we get a deterministic solution, and the need
for the heuristics slowly dies out.

Leave things as they are
------------------------
The HP representatives re-iterated their proposal to just leave
things as they were.  Marjo has sent a message to the mailing list
with HPs wording of why they want things left as they are.

A Vote was taken
----------------
A vote was taken among those present.  The choices were
the two proposals:
	1) Assign a new option number
	2) Leave things as they are

The vote was 7 for changing the option number, and 3 for leaving
things as they were.  Since those in attendance did not represent
the entire WG, it was decided that a final decision could not be
made at the WG meeting.  Instead, these results would be posted
to the mailing list, and unless there was serious objection on the
mailing list to going with the proposal to assign a new option number
to the Environment option, that would be the final outcome.


##############################################
## Here ends my summary of what happened at ##
## the WG meeting. The rest of this message ##
## is my personal views on a few points.    ##
##############################################


o The new RFC should have the same definitions for VAR and
  VALUE as RFC-1408.  This will place more of the burden of
  change on implementations that don't match RFC-1408.

o To update an RFC-1408 implementation will require:

	1) Send IAC DO/WILL NEW-ENVIRON in addition
	   to the existing IAC DO/WILL OLD-ENVIRON.
	2) Have a global variable, say "env_opt",
	   initialized to OLD-ENVIRON.
	3) If a DO/WILL NEW-ENVIRON is received,
	   set "env_opt" to NEW-ENVIRON.
	4) Add a case statement for NEW-ENVIRON next
	   to OLD-ENVIRON when parsing suboptions.
	5) Use the global variable "env_opt" for the option
	   number when generating a Environ suboption, rather
	   than using a static definition.

o Implementations with reversed VAR/VALUE definitions will need
  a little bit more code.

o Heuristic checking need only be done if only the OLD-ENVIRON
  is recognized, and if the implementor wants to interoperate
  with implementations that have reversed VAR/VALUE definitions.

o Marjo's list of Cons for leaving RFC1408 alone is not complete.
  It misses one of the main disadvantages of just leaving things
  as they are: Interoperability both now and in the future with
  both existing and new implementations.

  He ignores the fact the the existing, uninteroperable implementations
  will be around for a long time, and that by doing nothing
  means that this interoperability issue will be around as a
  support issue for vendors for a very long time, with no hope
  of ever getting out from underneath of it.

  As a telnet implementor, my goals for interoperability are,
  in decreasing importance:
	1) New implementations
	2) Old implementations with the same VAR/VALUE definitions
	3) Old implementations with reversed VAR/VALUE definitions

  This means that if things are left as they are, implementations
  that have had reversed definitions from RFC-1408 will continue
  to use those definitions as their default values, for the cases
  when the heuristics fail to determine what type of implementation
  is on the other side.  There will be no obvious convergence in
  implementations for the default definitions of VAR and VALUE, and
  there will be this gray area of interoperability forever.

  This means that leaving things as is is not a technically clean
  solution except for those who wish to have implementations that
  only interoperate with implementations that have RFC-1408
  implementations.  And even then those implementations will have
  trouble if an implementation with reversed definitions talks
  to them...

o The argument that voting to leave RFC-1408 alone is an endorsement
  for the IETF process completely ignores that fact that the whole
  point of the standards process is to allow people to have interoperable
  implementations of a common protocol.  The only reason we are even
  having this discussion is to 1) allow future implementation to have
  as widespread interoperability with existing implementations as possible,
  and 2) the desire that in the long run implementations should be
  able to have deterministic and reliable behavior.

o Bottom line, in my mind:

  Assigning a new Environment option number means recognizing that
  we are in an very messy situation with regards the interoperability
  of the Environment option.  It also means that future implementations
  need not be forever tainted due to problems with existing implementations.
  
			-David Borman, [e-mail]