As per Relevance of the word position, we have this rfc below:
D. Crocker (UCLA-NMC
RFC 658, NIC 31161 (Oct. 25, 1974)
Online file: [ISI]NAOLFD.
TELNET OUTPUT LINEFEED
1. Command name and
NAOLFD 16
(Negotiate About Output Linefeed Disposition
2. Command
In the following, we are discussing a simplex connection, as described in
the NAOL and NAOP Telnet Options
IAC DO NAOLFD
The data sender requests or agrees to negotiate about
linefeed disposition with the data receiver. In the case
agreement has been reached and in the absence of
subnegotiations, the data receiver is assumed to be handling
linefeed considerations
IAC DON'T NAOLFD
The data sender refuses to negotiate about output
disposition with the data receiver, or demands a return to
unnegotiated default mode
IAC WILL NAOLFD
The data receiver requests or agrees to negotiate about
linefeed disposition with the sender. In the case where
has been reached and in the absence of further subnegotiations,
data receiver alone is assumed to be handling output
considerations
IAC WON'T NAOLFD
The data receiver refuses to negotiate about output linefeed
disposition, or demands a return to the unnegotiated default mode.
IAC SB NAOLFD DS <8-bit value> IAC
The data sender specifies, with the 8-bit value, which party should
handle output linefeeds and what their disposition should be. The
code for DS is 1.
IAC SB NAOLFD DR <8-bit value> IAC
The data receiver specifies, with the 8-bit value, which
should handle output linefeeds and what their disposition
be. The code for DR is 0.
3.
DON'T NAOLFD/WON'T NAOLFD
In the default absence of negotiations concerning which party,
under or data receiver, is handling output linefeed considerations
neither party is required nor prohibited from handling linefeeds;
it is appropriate if at least the data receiver handles them,
primitively
4. Motivation for the
Please refer to section 4 of the NAOL and of the NAOLFD Telnet option
descriptions
5. Description of the
The data sender and the data receiver use the 8-bit value along with
and DR SB commands as follows
8-bit value
0 Command sender suggests that he alone will handle
linefeeds, for the connection.
1 to 250 Command sender suggests that the other party alone
should handle linefeeds, but suggests that a delay
of the indicated value be used. The value is the
number of character-times to wait or number of
NULs to insert in the data stream before sending
the next data character. (See qualifications, below.)
251 Not allowed, in order to be compatible with
related Telnet options.
252 Command sender suggests that the other party alone
handle linefeeds, but suggests that they be discarded
253 Command sender suggests that the other party alone
should handle linefeeds, but suggests
linefeeds be simulated.
254 Command sender suggests that the other party alone
should handle output linefeeds but suggests
waiting for a character to be transmitted (on the
other simplex connection) before sending more
data. (See qualifications, below.) Note that, due
to the assynchrony of the two simplex connections,
phase problems can occur with this option.
255 Command sender suggests that the other party alone
should handle output linefeeds and suggests
nothing about how it should be done.
The guiding rules are that:
1) if neither data receiver nor data sender wants to handle output
linefeeds, the data receiver must do it,
2) if both data receiver and data sender want to handle output linefeed
disposition, the data sender gets to do it.
The reasoning for the former rule is that if neither wants to do it,
the default in the NAOLFD option dominates. If both want to do it,
sender, who is presumed to have special knowledge about the data,
be allowed to do it, taking into account any suggestions the receiver
make. Simulation is defined as the replacement of the linefeed
by new-line (see following) and enough blanks to move the print head (
line pointer) to the same lateral position it occupied just prior
receiving the linefeed. To avoid infinite recursion, such simulation
allowed only for linefeed characters that are not immediately preceded
carriage-returns (that is, part of a Telnet new-line combination). It
assumed that linefeed simulation will be necessary for printers that
not have a separate linefeed (like the IBM 2741); in this case
end-of-line character padding can be specified through NAOCRD.
padding (0 < <8-bit-value> < 251) of linefeed characters is to be
for ALL linefeed characters
NOTE: Delays, controlled by the data sender, must consist of
characters inserted immediately after the character. This is
due to the assynchrony of network transmissions. Additionally, due
the presence of the Telnet end-of-line convention, it may be necessary
add carriage-return padding or delay after the associated linefeed (
NAOCRD Telnet option). As with all option negotiations, neither
should suggest a state already in effect except to refuse to negotiate
changes should be acknowledged; and once refused, an option should not
resuggested until "something changes" (e.g., another process starts).
any time, either party can disable further negotiation by giving
appropriate WON'T NAOLFD or DON'T NAOLFD 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
