summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc175.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc175.txt')
-rw-r--r--doc/rfc/rfc175.txt59
1 files changed, 59 insertions, 0 deletions
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]
+