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/rfc175.txt | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 doc/rfc/rfc175.txt

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

diff --git a/doc/rfc/rfc175.txt b/doc/rfc/rfc175.txt
new file mode 100644
index 0000000..7ade158
--- /dev/null
+++ b/doc/rfc/rfc175.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group                        11 June 1971
+Request for Comments: 175                    E. Harslem - Rand
+NIC 7074                                     J. Heafner - Rand
+
+             Comments on "Socket Conventions Reconsidered"
+             ---------------------------------------------
+
+        We agree with the conclusions reached by Abhay, Bob, and Joel in
+   RFC #167, "Socket Conventions Reconsidered," (see RFC #129, scheme #4)
+   -- especially the necessity for a major NCP overhaul.
+
+        Our main departure in thinking from RFC #167 concerns the socket
+   length. (See RFC #164, page 21.)  Since there is an apparently serious
+   TIP storage consideration, Rand- assigned sockets will have the
+   high-order 16 bits zero.
+
+        For the particular programs (current and pending) that Rand must
+   access, repeatability of socket name (RFC #167, page 3) is not
+   necessary for the user process and also not necessary for the server
+   process except for initial contact (ICP) sockets.
+
+   Our current use of socket names is diagrammed below.
+
+    O           15 16             23 24          30 31
+    ---------------------------------------------------
+   |              |                 |              |   |
+    ---------------------------------------------------
+     ^              ^                 ^              ^
+     |_ zero        |                 |              |_ gender
+                    |                 |
+                    |                 |_ zero for initial
+                    |                    contact, otherwise
+                    |                    dynamically assigned
+                    |                    by 3rd level user
+                    |                    program
+                    |_ administratively assigned (fixed
+                       and associated with programs)
+
+   (NOTE: This scheme corresponds exactly with both UCSB and UCLA/CCN
+   conventions).
+
+       [ 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 1]
+
-- 
cgit v1.2.3