doc: Add RFC documents

1 files changed, 109 insertions, 0 deletions

diff --git a/doc/rfc/rfc312.txt b/doc/rfc/rfc312.txt
new file mode 100644
index 0000000..91ccfa0
--- /dev/null
+++ b/doc/rfc/rfc312.txt
@@ -0,0 +1,109 @@
+
+
+
+
+
+
+Network Working Group                                 A. McKenzie
+RFC #312                                              BBN
+NIC 9342                                              22 March 1972
+Categories:  B.1
+
+                Proposed Change in IMP-to-Host Protocol
+
+        We are currently considering a redefinition of the IMP-to-Host
+   error message types (type 1 and type 8) and the creation of addi-
+   tional IMP-to-Host error message types.  We believe that these
+   changes will assist the Hosts in determining appropriate recovery
+   action, without causing any serious reprogramming problems.  Our
+   current plans are to install these changes within a few months;
+   therefore we should be informed of any strong negative reactions
+   relatively quickly.
+
+        The proposed changes fall into two general classes as de-
+   scribed below:
+
+        A)  General Error Message
+            ---------------------
+
+            Under certain circumstances, particularly when the Host
+            has been unresponsive to queued input for a "long time"
+            the IMP drops its ready line for a short period, causing
+            the "error flip-flops" to be set (see RFC #270, NIC 7818).
+            Under these conditions the IMP sends a few NOP's to the
+            Host and then resumes normal operation.  We propose to
+            send the Host a new message (message type 13) in addition
+            to the NOPs; this message will tell the Host that the
+            IMP's Ready Line was dropped, that the IMP's error flop
+            was set, and that the IMP will respond to the next com-
+            pletion of a Host-to-IMP message with a type 1 or type 8
+            message (because of the setting of the IMP's error flop.
+
+        B)  Error Messages which are Responses to Specific
+            ----------------------------------------------
+            Host-to-IMP Transmissions:
+            --------------------------
+
+            1)  IMP-to-Host message type 1 will be redefined to mean:
+                "IMP's Error flip-flop was set on a message which
+                the IMP cannot identify."
+
+            2)  IMP-to-Host message type 8 will be redefined to mean:
+                "IMP's Error flip-flop was set during receipt of the
+                message identified by the 'source' and 'link number'
+                bits of this error message."
+
+
+
+                                                                [Page 1]
+
+            3)  IMP-to-Host message type 10 will be defined to mean:
+                "A Host-to-IMP message was too short (and cannot be
+                identified)."
+
+            4)  IMP-to-Host message type 11 will be defined to mean:
+                "A Host-to-IMP message was too long; the message is
+                identified by the 'source' and 'link number' bits
+                of this error message."
+
+            5)  IMP-to-Host message type 12 will be defined to mean:
+                "A Host-to-IMP message with an illegal message type
+                code was received; the message is identified by the
+                'source' and 'link number' bits of this error message.
+                (Note that the erroneous type code is not included in
+                the error message.)"
+
+
+
+
+   AAM/jm
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by BBN Corp. under the   ]
+       [ direction of Alex McKenzie.                   12/96   ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+