As per Relevance of the word appropriate, we have this rfc below:
Network Working Group J.
Request for Comments: 860 J.
Obsoletes: NIC 16238 May 1983
TELNET TIMING MARK
This RFC specifies a standard for the ARPA community. Hosts on the
Internet are expected to adopt and implement this standard
1. Command Name and
TIMING-MARK 6
2. Command
IAC DO TIMING-
The sender of this command REQUESTS that the receiver of
command return a WILL TIMING-MARK in the data stream at
"appropriate place" as defined in section 4 below
IAC WILL TIMING-
The sender of this command ASSURES the receiver of this
that it is inserted in the data stream at the "appropriate place
to insure synchronization with a DO TIMING-MARK transmitted by
receiver of this command
IAC WON'T TIMING-
The sender of this command REFUSES to insure that this command
inserted in the data stream at the "appropriate place" to
synchronization
IAC DON'T TIMING-
The sender of this command notifies the receiver of this
that a WILL TIMING-MARK (previously transmitted by the receiver
this command) has been IGNORED
3.
WON'T TIMING-MARK, DON'T TIMING-
i.e., No explicit attempt is made to synchronize the activities
the two ends of the TELNET connection
4. Motivation for the
Postel & Reynolds [Page 1]
RFC 860 May 1983
It is sometimes useful for a user or process at one end of a
connection to be sure that previously transmitted data has
completely processed, printed, discarded, or otherwise disposed of
This option provides a mechanism for doing this. In addition,
if the option request (DO TIMING-MARK) is refused (by WON'
TIMING-MARK) the requester is at least assured that the refuser
received (if not processed) all previous data
As an example of a particular application, imagine a
connection between a physically full duplex terminal and a "
duplex" server system which permits the user to "type ahead"
the server is processing previous user input. Suppose that
sides have agreed to Suppress Go Ahead and that the server has
to provide echoes. The server now discovers a command which
cannot parse, perhaps because of a user typing error. It would
to throw away all of the user's "type-ahead" (since failure of
parsing of one command is likely to lead to incorrect results
subsequent commands are executed), send the user an error message
and resume interpretation of commands which the user typed
seeing the error message. If the user were local, the system
be able to discard the buffered input; but input may be buffered
the user's host or elsewhere. Therefore, the server might send a
TIMING-MARK and hope to receive a WILL TIMING-MARK from the user
the "appropriate place" in the data stream
The "appropriate place", therefore (in absence of other information
is clearly just before the first character which the user typed
seeing the error message. That is, it should appear that the
mark was "printed" on the user's terminal and that, in response,
user typed an answering timing mark
Next, suppose that the user in the example above realized that he
misspelled a command, realized that the server would send a
TIMING-MARK, and wanted to start "typing ahead" again without
for this to occur. He might then instruct his own system to send
WILL TIMING-MARK to the server and then begin "typing ahead" again
(Implementers should remember that the user's own system
remember that it sent the WILL TIMING-MARK so as to discard
DO/DON'T TIMING-MARK when it eventually arrives.) Thus, in this
the "appropriate place" for the insertion of the WILL TIMING-MARK
the place defined by the user
It should be noted, in both of the examples above, that it is
responsibility of the system which transmits the DO TIMING-MARK
discard any unwanted characters; the WILL TIMING-MARK only
help in deciding which characters are "unwanted".
5. Description of the
Postel & Reynolds [Page 2]
RFC 860 May 1983
Suppose that Process A of Figure 1 wishes to synchronize with B.
DO TIMING-MARK is sent from A to B. B can refuse by replying WON'
TIMING-MARK, or agree by permitting the timing mark to flow
his "outgoing" buffer, BUF2. Then, instead of delivering it to
terminal, B will enter the mark into his "incoming" buffer BUF1,
flow through toward A. When the mark has propagated through B'
incoming buffer, B returns the WILL TIMING-MARK over the
connection to A
PROCESS A TELNETconnection PROCESS B
+-----------+ +---------------+ Timing+-------+
| |WILL TIMING MARK| BUF 1 | Mark | |
| |<---------------|--|-|-|-|-|-|--|<------| |
| | | |-|-|-|-|-| | ^ | |
| | | BUF 2 | ^ | |
| |--------------->|--|-|-|-|-|-|--|------>| |
| | DO TIMING MARK | |-|-|-|-|-| | | |
+-----------+ +---------------+ +-------+
(NVT process).ME
Figure 1
When A receives the WILL TIMING-MARK, he knows that all
information he sent to B before sending the timing mark
delivered, and all the information sent from B to A before
of the timing mark has been delivered
Three typical applications are
A. Measure round-trip delay between a process and a terminal
another process
B. Resynchronizing an interaction as described in section 4 above
A is a process interpreting commands forwarded from a
by B. When A sees an illegal command it
i. Sends , , <question mark>.
ii. Sends DO TIMING-MARK
iii. Sends an error message
iv. Starts reading input and throwing it away until
receives a WILL TIMING-MARK
v. Resumes interpretation of input
Postel & Reynolds [Page 3]
RFC 860 May 1983
This achieves the effect of flushing all "type ahead" after
erroneous command, up to the point when the user actually
the question mark
C. The dual of B above. The terminal user wants to throw
unwanted output from A
i. B sends DO TIMING-MARK, followed by some new command
ii. B starts reading output from A and throwing it away
it receives WILL TIMING-MARK
iii. B resumes forwarding A's output to the terminal
This achieves the effect of flushing all output from A, up
the point where A saw the timing mark, but not output
in response to the following command
Postel & Reynolds [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
