From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc76.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc76.txt (limited to 'doc/rfc/rfc76.txt') diff --git a/doc/rfc/rfc76.txt b/doc/rfc/rfc76.txt new file mode 100644 index 0000000..97aa28c --- /dev/null +++ b/doc/rfc/rfc76.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group J. Bouknight +Request for Comments: 76 J. Madden +NIC 5180 G. Grossman + University of Illinois + 28 October 1970 + + + Connection-By-Name: User-Oriented Protocol + + +I. Introduction + + Shortly after the first of the year, 1971, the Center for Advanced + Computation (CAC) at the University of Illinois will begin to use the + facilities of the ARPA network. We are the first of a small class of + network nodes whose chief characteristic is that the node is a port + to the network only. All computational power for these nodes will be + taken from other nodes on the network, ILLIAC IV for example. + + An important characteristic of most of the users at our Center is a + lack of sophistication about data communication techniques and + practices. The user will eventually be in the majority of those + using the network from all nodes but the problem is ours, almost from + the start. + + In our discussions with our prospective users of the network as we + designed our port facility, we found that the greatest confusion and + consternation arose over having to deal with network protocol at the + "nitty-gritty" level of sockets, links, etc. While most of them have + been acclimated to computer systems at the file and device-by-name + level where the software system handles details, here on the current + version of the network, the user handles all details. + + Thus, we were compelled to seek a user level interface to network + protocol where all user protocol is handled symbolically with system + procedures making the translation into host-to-host protocol. + + Currently, connections are established by exchange of known socket + numbers for the four loose ends of the connection. This requires + either that the user or process always know all socket numbers he + will use at his or other installations OR that his NCP (and/or + related software) remember them for him, allowing him to reference + them symbolically. + + We propose a more general solution to the "telephone book" approach + of obtaining socket numbers for user or processes. Only the host, at + each site, knows its socket number space at any given instant in time + as well as the status of the user or process to which a socket number + + + +Bouknight, et al. [Page 1] + +RFC 76 Connection-By-Name: User-Oriented Protocol October 1970 + + + assigned. Additionally, most permanently assigned devices and/or + processes are known by standard mnemonic labels such as DSK (disk), + LP (line printer), CR (card reader), TECO (PDP-10 text editor), etc. + In most systems, all other communications are done through files or + pseudo files, known only to the user by their names and not by their + internal mechanism. In other words, most intrasystem communication + at the user level is by symbolic reference to both devices and + process. + + We propose facilities, by extension of the current protocol, that + will allow users to use the network on a connection-by-name basis as + they already do in their host system. In the remainder of this paper + we will present the suggested extensions to the current protocol and + give an example of its usage in a dialogue between a user at CAC, + controlling two processes; one at UTAH, and one at PAOLI (ILLIAC IV + construction site). + +II. Proposed Extensions to Protocol + + Let us define a class of syntax elements for use in our proposed + extensions to the protocol. (This syntax is expressed in the + metalanguage of the ALGOL-60 report.) + +