Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!MOORE.FAC.CS.CMU.EDU!Dale.Moore
From: Dale.Moore@MOORE.FAC.CS.CMU.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Telnet and Timing Mark option
Message-ID: <8812230353.AA16129@ucbvax.Berkeley.EDU>
Date: 21 Dec 88 20:02:01 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

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