Dale.Moore@MOORE.FAC.CS.CMU.EDU (12/22/88)
I have a question about telnet option negotiation and the Telnet Timing Mark Option. On RFC854 page 2 If a party recevies what appears to be a request to enter a mode it is already in, the request should not be acknowledged. This non-response is essential to prevent endless loops in the negotiation. But, RFC860 "Telnet Timing Mark Option" seems to violate this rule. It seems to violate this rule by encouraging the behaviour of having a server repeatedly sending "DO Timing-Mark", even after it has received "WILL Timing-Mark" from a client. I believe I clearly understand the use of the option and the motivation. I do not understand how to do a server implementation that sends DO Timing-Mark, yet follows the rules set down by the Telnet RFC. Perhaps a better specification would have been to have the actual timing mark be a part of a Timing-Mark suboption rather than have it be the "Do Timing Mark" negotiation? Comments? Dale Moore Computer Science Carnegie Mellon University
barns@GATEWAY.MITRE.ORG (Bill Barns) (12/23/88)
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
braden@VENERA.ISI.EDU (12/24/88)
Dale, There IS no Timing Mark mode, so a host can never enter it. So, it always refuses, by sending DONT/WONT Timing Mark, which gives the desired synchronization echo. I always thought that very clever, well, say on the level of a good pun. Bob braden
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (12/25/88)
A host can reply WILL TIMING-MARK, not just WONT -- it's actually supposed to WILL if the timing mark echo is properly synchronized and WONT if it's not, though I'd be surprised if many implementations were that careful. Stuart Levy