doc: Add RFC documents

1 files changed, 119 insertions, 0 deletions

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]<DCROCKER>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.