Telnet Timing Mark Option (RFC0860)
Original Publication Date: 1983-May-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
J. Postel: AUTHOR [+2]
This RFC specifies a standard for the ARPA community. Hosts on the ARPA Internet are expected to adopt and implement this standard.
Network Working Group J. Postel
Request for Comments: 860 J. Reynolds
Obsoletes: NIC 16238 May 1983
TELNET TIMING MARK OPTION
This RFC specifies a standard for the ARPA community. Hosts on the ARPA
Internet are expected to adopt and implement this standard.
1. Command Name and Code
2. Command Meanings
IAC DO TIMING-MARK
The sender of this command REQUESTS that the receiver of this
command return a WILL TIMING-MARK in the data stream at the
"appropriate place" as defined in section 4 below.
IAC WILL TIMING-MARK
The sender of this command ASSURES the receiver of this command
that it is inserted in the data stream at the "appropriate place"
to insure synchronization with a DO TIMING-MARK transmitted by the
receiver of this command.
IAC WON'T TIMING-MARK
The sender of this command REFUSES to insure that this command is
inserted in the data stream at the "appropriate place" to insure
IAC DON'T TIMING-MARK
The sender of this command notifies the receiver of this command
that a WILL TIMING-MARK (previously transmitted by the receiver of
this command) has been IGNORED.
WON'T TIMING-MARK, DON'T TIMING-MARK
i.e., No explicit attempt is made to synchronize the activities at
the two ends of the TELNET connection.
4. Motivation for the Option
RFC 860 May 1983
It is sometimes useful for a user or process at one end of a TELNET
connection to be sure that previously transmitted data has been
completely processed, printed, discarded, or otherwise disposed of.
This option provides a mechanism for doing this. In addition, even
if the option request (DO TIMING-MARK) is refused (by WON'T
TIMING-MARK) the requester is at least assured that the refuser has
received (if not processed) all previous data.
As an example of a particular application, imagine a TELNET
connection between a physically full duplex terminal and a "full
duplex" server system which permits the user to "type ahead" while
the server is processing previous user input. Suppose that both
sides have agreed to Suppress Go Ahead and that the server has agreed
to provide echoes. The server now discovers a command which it
cannot parse, perhaps because of a user typing error. It would like
to throw away all of the user's "type-ahead" (since failure of the
parsing of one command is likely to lead to incorrect results if
subsequent commands are executed), send the user an error message,
and resume interpretation of commands which the user typed after
seeing the error message. If the user were local, the system would
be able to discard the buffered input; but input may be...