From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc658.txt | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 doc/rfc/rfc658.txt (limited to 'doc/rfc/rfc658.txt') diff --git a/doc/rfc/rfc658.txt b/doc/rfc/rfc658.txt new file mode 100644 index 0000000..15ea693 --- /dev/null +++ b/doc/rfc/rfc658.txt @@ -0,0 +1,119 @@ +D. Crocker (UCLA-NMC) +RFC 658, NIC 31161 (Oct. 25, 1974) +Online file: [ISI]NAOLFD.TXT + + TELNET OUTPUT LINEFEED DISPOSITION + +1. Command name and code + NAOLFD 16 + (Negotiate About Output Linefeed Disposition) + +2. Command meanings + 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 output + linefeed disposition with the data receiver. In the case where + agreement has been reached and in the absence of further + subnegotiations, the data receiver is assumed to be handling output + linefeed considerations. + IAC DON'T NAOLFD + The data sender refuses to negotiate about output linefeed + disposition with the data receiver, or demands a return to the + unnegotiated default mode. + IAC WILL NAOLFD + The data receiver requests or agrees to negotiate about output + linefeed disposition with the sender. In the case where agreement + has been reached and in the absence of further subnegotiations, the + data receiver alone is assumed to be handling output linefeed + 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 SE + 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 SE + The data receiver specifies, with the 8-bit value, which party + should handle output linefeeds and what their disposition should + be. The code for DR is 0. + +3. Default + DON'T NAOLFD/WON'T NAOLFD. + In the default absence of negotiations concerning which party, data + under or data receiver, is handling output linefeed considerations, + neither party is required nor prohibited from handling linefeeds; but + it is appropriate if at least the data receiver handles them, albeit + primitively. + +4. Motivation for the Option + Please refer to section 4 of the NAOL and of the NAOLFD Telnet option + descriptions. + +5. Description of the Option + The data sender and the data receiver use the 8-bit value along with DS + and DR SB commands as follows: + + 8-bit value Meaning + + 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 that + 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, and + 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, then + the default in the NAOLFD option dominates. If both want to do it, the + sender, who is presumed to have special knowledge about the data, should + be allowed to do it, taking into account any suggestions the receiver may + make. Simulation is defined as the replacement of the linefeed character + by new-line (see following) and enough blanks to move the print head (or + line pointer) to the same lateral position it occupied just prior to + receiving the linefeed. To avoid infinite recursion, such simulation is + allowed only for linefeed characters that are not immediately preceded by + carriage-returns (that is, part of a Telnet new-line combination). It is + assumed that linefeed simulation will be necessary for printers that do + not have a separate linefeed (like the IBM 2741); in this case, + end-of-line character padding can be specified through NAOCRD. Any + padding (0 < <8-bit-value> < 251) of linefeed characters is to be done + for ALL linefeed characters. + + NOTE: Delays, controlled by the data sender, must consist of NUL + characters inserted immediately after the character. This is necessary + due to the assynchrony of network transmissions. Additionally, due to + the presence of the Telnet end-of-line convention, it may be necessary to + add carriage-return padding or delay after the associated linefeed (see + NAOCRD Telnet option). As with all option negotiations, neither party + should suggest a state already in effect except to refuse to negotiate; + changes should be acknowledged; and once refused, an option should not be + resuggested until "something changes" (e.g., another process starts). At + any time, either party can disable further negotiation by giving the + appropriate WON'T NAOLFD or DON'T NAOLFD command. -- cgit v1.2.3