As per Relevance of the word handling, we have this rfc below:
Request for Comments: 652 D. Crocker (UCLA-NMC
25 Oct. 74
NIC #31155
Online file: [ISI]NAOCRD.
Telnet Output Carriage-Return Disposition
1. Command name and
NAOCRD 10 (Negotiate About Output Carriage-Return Disposition
2. Command
In the following, we are discussing a simplex connection,
described in the NAOL and NAOP Telnet options
IAC DO NAOCRD The data sender requests or agrees to
about output carriage-return
disposition with the data receiver. In
case where agreement has been reached and
the absence of further subnegotiations,
data receiver is assumed to be handling
carriage-returns
IAC DON'T NAOCRD The data sender refuses to negotiate
output carriage-return disposition with
data receiver, or demands a return to
unnegotiated default mode
IAC WILL NAOCRD The data receiver requests or agrees
negotiate about output carriage-
disposition with the sender. In the case
agreement has been reached and in the
of further subnegotiations, the data
alone is assumed to be handling
carriage-returns
IAC WON'T NAOCRD The data receiver refuses to negotiate
output carriage-return disposition, or
a return to the unnegotiated default mode
IAC SB NAOCRD DS <8-bit value> IAC
The data sender specifies, with the 8-
value, which party should
carriage-returns and what their
should be. The code for DS is 1.
Telnet NAOCRD Option Page 2
IAC SB NAOCRD DR <8-bit value> IAC SE The data
specifies, with the 8-bit value, which
should handle carriage-returns and what
disposition should be. The code for DR is 0.
3.
DON'T NAOCRD/WON'T NAOCRD. In the default absence
negotiations concerning which party, data sender or data receiver
is handling output carriage-returns, neither party is required
handle carriage-returns and neither party is prohibited
handling them; but it is appropriate if at least the data
handles carriage-returns, albeit primitively
4. Motivation for the
Please refer to section 4 of the NAOL and of the NAOP
option descriptions
5. Description of the
The data sender and the data receiver use the 8-bit value
with the NAOCRD SB commands as follows
8-bit value
0 Command sender suggests that he alone
handle carriage-returns, for the connection.
1 to 250 Command sender suggests that the other
alone should handle carriage-returns,
suggests that a delay of the indicated value
used. The value is the number
character-times to wait or number of NULs
insert in the data stream before sending
next data character. (See qualification
below.)
251 Not allowed, in order to be compatible
related Telnet options
252 Command sender suggests that the other
alone handle carriage-returns, but
that they be discarded
253 Not allowed, in order to be compatible
related Telnet options.
Telnet NAOCRD Option Page 3
254 Command sender suggests that the other
alone should handle carriage-returns
suggests waiting for a character to
transmitted (on the other simplex connection
before sending more data. (See qualification
below.) Note that, due to the assynchrony
the two simplex connections, phase problems
occur with this option.
255 Command sender suggests that the other
alone should handle carriage-returns
suggests nothing about how it should be done
The guiding rules are that
(1) if neither data receiver nor data sender wants to
carriage-returns, the data receiver must do it,
(2) if both data receiver and data sender want to
carriage-returns, the data sender gets to do it
The reasoning for the former rule is that if neither wants to
it, then the default in the NAOCRD option dominates. If both
to do it, the sender, who is presumed to have special
about the data, should be allowed to do it, taking into account
suggestions the receiver may make
Note that carriage-return delays, controlled by the data sender
must consist of NUL characters inserted immediately after
character in question. This is necessary due to the assynchrony
network transmissions. Due to the Telnet end-of-line convention
with carriage-returns followed by a linefeed, any NULs that
otherwise be placed after the carriage-return must be placed
the linefeed, regardless of any modifications that may
be made to the line feed (see NAOLFD Telnet option).
As with all option negotiations, neither party should suggest
state already in effect except to refuse to negotiate;
should be acknowledged; and once refused, an option should not
resuggested until "something changes" (e.g., another
starts).
At any time, either party can disable further negotiation
giving the appropriate WON'T NAOCRD or DON'T NAOCRD command
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
