Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Telnet Timing Mark Option (RFC0860)

IP.com Disclosure Number: IPCOM000003908D
Original Publication Date: 1983-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR [+2]

Abstract

This RFC specifies a standard for the ARPA community. Hosts on the ARPA Internet are expected to adopt and implement this standard.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 36% of the total text.

Network Working Group J. Postel

Request for Comments: 860 J. Reynolds

ISI

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

TIMING-MARK 6

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

synchronization.

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.

3. Default

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 use...