Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!ncsuvx!gatech!ukma!nrl-cmf!ames!pasteur!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Telnet and Timing Mark option
Message-ID: <8812231356.AA09277@gateway.mitre.org>
Date: 23 Dec 88 13:56:27 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32

I think you have created an appearance of inconsistency in the RFCs by
injecting an assumption.  I would resolve this by characterizing the
Timing Mark Option as a 'mode' with predefined infinitesimal duration.
Therefore, a second DO TIMING-MARK is not requesting the receiver to
enter a mode it is already in; it is a request to re-enter a mode
it was in at some past time, but is not in now.  When the receiver of
the DO TIMING-MARK sends a WILL TIMING-MARK, it is confirming that it
will enter and exit the timing mark processing mode "immediately" with
respect to the TELNET protocol stream.  If it actually does what it
promises, then it certainly will not be in the act of processing that
timing mark when another one shows up.

This seems like a good opportunity to mention that TELNET as you see it
now is known to Old-Timers as "New Telnet", which correctly implies
that there was also an "Old Telnet".  The transition began about 15
years ago and was mostly completed about 10 years ago.  As I recall it,
Old Telnet reserved the whole range 200-377 octal for control signaling
and it did not use the WILL/DO philosophy.  Instead there were one byte
codes to direct each state change (start echoing, end echoing, start
binary, ...)  This scheme has advantages and disadvantages which
interested folks can probably figure out readily enough.  Why should
anyone care now?  Well, the desire for convenient dual-protocol support
during the transition tends to explain certain otherwise mysterious
features of New Telnet.  I did not work in protocol specification back
then, but it certainly seems as though each O.T. feature was
"translated" into the simplest and most parallel N.T. representation.
This would have saved a lot of work for implementors, and perhaps more
importantly, it saves memory since one set of action routines could
service both flavors.  That used to be significant in boxes like the
Honeywell TIPs which connected terminals to the ARPANET in those days.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org