doc: Add RFC documents

1 files changed, 112 insertions, 0 deletions

diff --git a/doc/rfc/rfc657.txt b/doc/rfc/rfc657.txt
new file mode 100644
index 0000000..5a1ff0f
--- /dev/null
+++ b/doc/rfc/rfc657.txt
@@ -0,0 +1,112 @@
+D. Crocker (UCLA-NMC)
+RFC 657, NIC 31160 (Oct. 25, 1974)
+Online file: [ISI]<DCROCKER>NAOVTD.TXT
+
+            TELNET OUTPUT VERTICAL TAB DISPOSITION OPTION
+
+1. Command name and code
+   NAOVTD 15
+      (Negotiate About Output Vertcial Tab Disposition)
+
+2. Command meanings
+   In the following, we are discussing a simplex connection, as
+   described in the NAOL and NAOP Telnet Options specifications.
+      IAC DO NAOVTD
+         The data sender requests or agrees to negotiate about output
+         vertical tab character 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 vertical tab character considerations.
+      IAC DON'T NAOVTD
+         The data sender refuses to negotiate about output vertical tab
+         character disposition with the data receiver, or demands a
+         return to the unnegotiated default mode.
+      IAC WILL NAOVTD
+         The data receiver requests or agrees to negotiate about output
+         vertical tab character 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 vertical tab character considerations.
+      IAC WON'T NAOVTD
+         The data receiver refuses to negotiate about output vertical
+         tab character disposition, or demands a return to the unnegotiated
+         default mode.
+      IAC SB NAOVTD DS <8-bit value> IAC SE
+         The data sender specifies, with the 8-bit value, which party
+         should handle output vertical tab characters and what their
+         disposition should be.  The code for DS is 1.
+      IAC SB NAOVTD DR <8-bit value> IAC SE
+         The data receiver specifies, with the 8-bit value, which party
+         should handle output vertical tab characters and what their
+         disposition should be.  The code for DR is 0.
+
+3. Default
+   DON'T NAOVTD/WON'T NAOVTD
+      In the default absence of negotiations concerning which party,
+      data sender or data receiver, is handling output vertical tab character
+      considerations, neither party is required to handle vertical tab
+      characters and neither party is prohibited from handling them; but
+      it is appropriate if at least the data receiver handles vertical tab
+      character considerations, albeit primitively.
+
+4. Motivation for the Option
+   Please refer to section 4 of the NAOL and of the NAOVTD Telnet option
+   descriptions.
+
+5. Description of the Option
+   The data sender and the data receiver use the 8-bit value along with
+   the DS and DR SB commands as follows:
+
+      8 bit value   Meaning
+
+      0             Command sender suggests that he alone will handle
+                    vertical tab characters, for the connection.
+      1 to 250      Command sender suggests that the other party alone
+                    should handle tab characters, 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.
+      251           Command sender suggests that the other party alone
+                    handle vertical tabs, but suggests that each 
+		    occurrence of the character be replaced by 
+		    carriage-return/linefeed.
+      252           Command sender suggests that the other party alone
+                    handle vertical tabs, but suggests that they be discarded.
+      253           Command sender suggests that the other party alone
+                    should handle tab characters, but suggests that 
+		    tabbing be simulated.
+      254           Command sender suggests that the other party alone
+                    should handle the output disposition but suggests 
+		    waiting for a character to be transmitted (on the 
+		    other simplex connection) before sending more data.
+	            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 the output disposition 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 the 
+      output vertical tab characters, the data receiver must do it, and
+      2. if both data receiver and data sender want to handle the output
+      vertical tab characters, the data sender gets to do it.
+
+   The reasoning for the former rule is that if neither want to do it, then
+   the default in the NAOVTD 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 character by
+   enough line-feeds (only) to advance the paper (or line-pointer) to the
+   next vertical tab stop.  
+   Note that delays, controlled by the data sender, must consist of NUL
+   characters, inserted immediately after the line-feed character.  This is
+   necessary due to the assynchrony of network transmissions.  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 NAOVTD or
+   DON'T NAOVTD command.