From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc40.txt | 165 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 doc/rfc/rfc40.txt

(limited to 'doc/rfc/rfc40.txt')

diff --git a/doc/rfc/rfc40.txt b/doc/rfc/rfc40.txt
new file mode 100644
index 0000000..2fd024a
--- /dev/null
+++ b/doc/rfc/rfc40.txt
@@ -0,0 +1,165 @@
+
+
+
+
+
+
+Network Working Group                                         E. Harslem
+Request for Comments: 40                                      J. Heafner
+                                                                    RAND
+                                                              March 1970
+
+               More Comments on the Forthcoming Protocol
+
+We have recently discussed NWG/RFC Nos. 36 and 39 with Steve Crocker,
+UCLA.  Steve has asked that we elaborate on the errors, queries, and
+HOST status that were mentioned in NWG/RFC #39.
+
+Please voice your opinions soon in order to affect the forthcoming
+protocol specifications.
+
+ERROR MESSAGES
+
+     <ERR> <Code> <Command length> <Command in error>
+
+<Code> is an eight-bit field that specifies the error type.  The
+assigned codes are shown below.  <Command length> is a 16-bit integer
+that indicates the length of the <Command in error> in bits.  The
+<Command in error> is the spurious command.
+
+The ranges of <Code> are shown below in hexidecimal.
+
+     00     Unspecified error types
+     10-0F  Resource errors
+     10-1F  Status errors
+     20-2F  Content errors
+     30-3F  Unused
+
+Specific values of <Code> are shown below with their meaning.
+
+     <Code> value   Semantics
+
+         00         Unspecified errors.
+         01         Request for an invalid resource.
+         02         Request for an exhausted resource, try later.
+        03-0F       Unused.
+         10         Invalid <RSM>, i.e., link connected but unblocked.
+         11         Invalid <SPD>.
+         12         Invalid <ASG>, i.e., connected but no <RDY>
+                      received.
+
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+     <Code> value   Semantics
+
+         13         Message received on blocked link.
+        14-1F       Unused.
+         20         Unknown command code.
+         21         Message received on unconnected link.
+         22         Invalid <RFC>.
+         23         Invalid <CLS>.
+         24         Invalid <RSM>, i.e., link not connected.
+         25         Invalid <FND>.
+         26         Invalid <END>.
+         27         Invalid <RDY>.
+         28         Invalid <ASG>, i.e., not connected.
+        29-2F       Unused.
+        30-FF       Unused.
+
+QUERIES
+
+     <QRY> <My Socket>
+or   <RPY> <Your Socket> <Text>
+
+The <QRY> is the query indicated in NWG/RFC #39 and <RPY> is the reply.
+The format of <Text> is shown below; also refer to NWG/RFC #36, p. 3.
+
+<Text>::= <16 bit count of relevant connection table entries>
+          <relevant connection table entries>
+
+<relevant connection table entries>::=
+                                     <relevant connection table entries>
+                                     <a relevant connection table entry>
+                                     <a relevant connection table entry>
+
+<a relevant connection table entry>::= <local socket> <foreign socket>
+                                       <link> <connection state>
+                                       <flow state and buffer control>
+                                       <reconnection control state>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+HOST STATUS
+
+     <NOP>
+
+An NCP may be up, down, pending, etc.  When an NCP changes its
+state to UP it should send a <NOP> to each remote NCP which
+indicates the NCP is available.  The sending NCP can then
+construct a vector of HOST status from the RFNMs it receives.  An
+NCP receiving a <NOP> can update the availability of the sending
+NCP in its HOST status vector.
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+         [ into the online RFC archives by Richard Ames 6/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
-- 
cgit v1.2.3