doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

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.)
+
+   <label> ::= <usercode>/<filename>|<device name>
+
+   <devicename> ::= <string>
+
+   <usercode> ::= <string>
+
+   <filename> ::= <string>|<filename>/<string>
+
+   <string> ::= <char>|<char> <string>
+
+   <char> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|0|1|2|
+              3|4|5|6|7|8|9|.|,
+
+   A standard set of <devicenames> should be established to reference
+   line printers, card readers, etc. - those hard peripherals with fixed
+   processing tasks.  A beginning set of <labels> might be:
+
+      LP            line printer
+      CR            card reader
+      CP            card punch
+      PTR           paper tape recorder
+      PTP           paper tape punch
+      MT            magnetic tape
+      DSK           disk
+      TTY           teletype compatible terminal
+
+
+
+Bouknight, et al.                                               [Page 2]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+   The format of <usercode> is that of the responding host for the
+   current discussion.  Future discussions about foreign-user usage of
+   host facilities may result in a standard format for the entire
+   network.
+
+   Most systems can identify files by one <string> plus the <usercode>.
+   Others, such as the Burroughs B6500 use multifile identifiers where
+   many <strings> may be used in the <label>.  The set of <char> is that
+   proposed in RFC 66, i.e., ASCII.
+
+   The proposed extensions involve a "request" for information and
+   several variants of a "response" to the request.
+
+   A. Request for Socket Number for this Label
+
+      <RFSNL> <my socker #> <0> <label>
+
+   The RFSNL is sent on the control link to the destination host
+   requesting the socket number of the attached <label>.
+
+   B. Acknowledgement of Request
+
+   Upon receipt of an <RFSNL>, the destination host returns one of three
+   responses:
+
+      <AORP> <desired socket#> <your socket #>
+
+      <AORN> <desired socket#> <your socket #>
+
+      <AORN> <0> <your socket #>
+
+   The first response returns the requested socket number and signifies
+   that the user, device, or process exists.  The second response
+   returns the requested socket number but signifies that the user,
+   device, or process is not currently available for connection.  The
+   last response signifies that no such user, device, or process exists.
+
+   C. Discussion
+
+   The above extensions to the protocol are intended to enhance user
+   acclimation to network usage.  The element of strangeness is subdued
+   and, in fact, for user of the B6500 erased.  Attached to this RFC is
+   an appendix containing a preliminary description of the user language
+   of the network port facility being brought up at the CAC.  We now
+   present a sample user session on the CAC facility and detail how the
+   protocol is used to establish the proper communication paths.
+
+
+
+
+
+Bouknight, et al.                                               [Page 3]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+III. Example of User Dialogue
+
+   Assume a user residing at CAC, whose site code is URBANA.  His
+   terminal is an alphanumeric CRT terminal and we assume solution of
+   code conversion problems for network communications.
+
+   The sample user session will involve the setting up of two processes
+   at two host sites with control from the third host site.  All
+   operations can be accomplished with the current protocol plus the
+   proposed extensions.
+
+   In addition, we also assume that some form of standard user code is
+   in use for all host sites uniquely identifying every network user
+   when he is present.
+
+   Output keyed by systems will be underlined.  Comments are offset to
+   the right for legibility.  All statements about the UTAH system are
+   purely hypothetical.
+
+    User Dialogue                           Comments
+
+                                 The user moves to the terminal, applies
+                                 power and types:
+
+   HELLO
+                                 The CAC system responds for login
+                                 purposes with:
+
+   USER= GROSSMAN
+   ------
+                                 for the user's code.
+
+
+   1437 TR7/GROSSMAN LOGGED IN
+   ___________________________
+   LINE PRINTER DOWN TILL 1600
+   ___________________________
+                                 This acknowledges proper usercode and
+                                 sends any appropriate notes on system
+                                 status.
+   ! LINK TO ILLIAC
+                                 The exclamation point (!) is the escape
+                                 character which flags direct input to
+                                 the PDP-11 OS:
+
+                                 User requests connection to the ILLIAC
+                                 IV node.  NCP operations establish link
+                                 from user terminal to B6500 MCP.
+
+
+
+Bouknight, et al.                                               [Page 4]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+
+   1437 TR7/GROSSMAN LINKED ILLIAC
+   -------------------------------
+                                 Completes response.
+
+   ? EXECUTE DISK/PRINT; FILE DISK = ALPHA@UTAH REMOTE QUEUE; END
+
+                                 1. DISK/PRINT lists text files from
+                                 disk to B6500 line printer.
+                                 2. REMOTE files on the B6500 will refer
+                                 to files going to/coming from the
+                                 network.
+                                 3. ALPHA@UTAH specifies that a
+                                 connection is to be made via the
+                                 network to a file GROSSMAN/ALPHA from
+                                 the UTAH node.
+                                 4. QUEUE specifies periodic attempt to
+                                 complete the connection.
+
+                                 The B6500 will ask for the socket
+                                 number associated with GROSSMAN/ALPHA
+                                 until an AORP is received.
+
+                                 The language is that of the monitor for
+                                 the B6500
+   ! FLAG ILLIAC =#
+                                 All data received or sent on the link
+                                 to ILLIAC must now be prefaced by the #
+                                 character.
+
+   ! LINK TO UTAH
+
+   1441 TR7/ GROSSMAN LINKED UTAH
+   ------------------------------
+                                 User now links into UTAH PDP-10 system.
+
+   #1410: DISK/PRINT BOJ 1441
+   --------------------------
+                                 System message stating beginning-of-job
+                                 for DISK/PRINT on B6500.
+
+   ^C
+
+    . R PIP
+    -
+                                 User will run PIP on a listing file.
+
+
+
+
+
+Bouknight, et al.                                               [Page 5]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+
+   * NETWKR:ALPHA@ILLIAC <- DSK:FIL.TMP
+   -
+                                 NETWRK is network file type for UTAH
+                                 system.  Mechanism for file control
+                                 basically same as for B6500 system.
+                                 Since PIP will be sending to the
+                                 network, it does not request a socket #
+                                 from the B6500 NCP but instead
+                                 instructs its NCP to acknowledge any
+                                 request for GROSSMAN/ALPHA from ILLIAC
+                                 with the socket number PIP will send
+                                 from.  As soon as the B6500 NCP tries
+                                 again to find GROSSMAN/ALPHA from UTAH,
+                                 success occurs and the socket numbers
+                                 are exchanged with subsequent
+                                 connection establishment.
+
+   *
+   -
+                                 PIP completes the task and terminates
+                                 the connection to the B6500.
+
+   #14: DISK/PRINT EOJ 1448
+                                 B6500 acknowledges completion of task.
+
+   #? TO SPO: SAVE LIST GROSSMANHA FOR MAIL(U OF I/GROSSMAN)
+                                 User sends message to B6500 operator.
+
+                                 User logs out of UTAH.
+   JOB 10, USER GROSSMAN@URBANA TY68 AT 1448 ON 22-NOV-70
+   ------------------------------------------------------
+
+   FILES DELETED: 0, FILES SAVEDL RUNTIME 0 MIN 12 SEC
+   ---------------------------------------------------
+                                 System logout listing.
+
+   ! END UTAH
+
+   1449 TR7/GROSSMAN DELINKED UTAH
+   -------------------------------
+                                 Link to UTAH system now dropped.
+
+   # FROM SPO: LISTING MAILED
+   --------------------------
+                                 B6500 operator response.
+
+
+
+
+
+Bouknight, et al.                                               [Page 6]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+   ! LEAVE
+                                 User desired to log out of CAC system.
+
+   1450 TR7/GROSSMAN DELINKED ILLIAC
+   ---------------------------------
+                                 Link to ILLIAC system new dropped.
+
+   1450 TR7/GROSSMAN LOGGED OUT
+   ----------------------------
+                                 Session over.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bouknight, et al.                                               [Page 7]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+        Syntax and Semantics for the Terminal User Control Language
+           for the Proposed PDP-11 ARPA Network Terminal System
+
+                                    by
+
+                              G. R. Grossman
+
+
+Prefatory Notes
+
+   The following document represents a first attempt at providing a
+   control language for the terminal user of the PDP-11 network terminal
+   system.  This language is deemed sufficiently powerful to provide the
+   user with a minimal facility for attaching to remote host computers
+   over the ARPA network, initiating processes, and routing data flow to
+   local peripheral devices.
+
+   The hardware system as envisioned will comprise a PDP-11/20 with a
+   least 8k of core, a small disk (512 kilobytes of storage), a console
+   teletype, and optional card readers, line printers, DECtapes, User
+   terminals, card punches, storage scopes, etc.
+
+   The executive system will consist of a basic driver system which will
+   control autonomous processes and interrupt-driven device service
+   routines.  The system will keep tables in core and on the small disk
+   for logging peripheral usage, keeping track of connections on the
+   network, queuing up of tasks that cannot be immediately performed,
+   storing attributes of remote hosts, etc.
+
+   Since network hosts handle communications in character-at-a-time or
+   message modes, and may or may not echo characters over the network,
+   the system takes this into account when handling connections to
+   specific hosts.  If the connection is in message mode, minimal line-
+   by-line editing facility (character and line deletion) is provided.
+
+   A means for the user to change flag and message transmit characters
+   is provided to prevent incompatibilities which may arise between the
+   PDP-11 and other hosts.
+
+   This document does not describe control card syntax for card reader
+   usage, nor does it describe the operator's control language.  These
+   will be described in later documents.
+
+Character Set
+
+   <character> ::= <letter> | <digit> | <special> | <space>
+
+   <letter>    ::= A | B | ... | Y | Z
+
+
+
+Bouknight, et al.                                               [Page 8]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+   <digit>     ::= 0 | 1 | ... | 8 | 9
+
+   <special>   ::= ! | " | # | $ | % | & | ' | ( | ) | * | + | , | - |
+                   . | / | : | : | < | = | > | ? | @ | [ |  | ] | ^ |
+                     |` | { | <bar> | }
+
+Identifiers
+
+   <identifiers> ::= <letter> | <identifier> <letter> |
+                     <identifier> <digit>
+
+        Semantics:  Identifiers are used to designate peripheral units,
+        host computers, etc.  No identifier may exceed 8 characters in
+        length.
+
+Numbers
+
+   <integer> ::= <digit> | <integer> <digit>
+
+        Semantics:  <integer> are the only form of number allowed in the
+        control language.  They must not exceed 2^15-1.
+
+Peripheral Designator
+
+   <peripheral designator> ::= <device class> <device number> | OPR
+
+   <device number>         ::= <digit> | <digit> <digit> |
+
+   <device class>          ::= CR | CP | LP | DT | TR | SS
+
+        Semantics:  Peripheral designators name specific peripheral
+        devices.  Device lasses designate classes of peripherals.
+
+        OPR designates the operator's console teletype.  The classes of
+        peripherals corresponding to the device classes are given on the
+        following table:
+
+            <device class>                      type of peripheral
+
+                CR                                  card reader
+                CP                                  card punch
+                LP                                  line printer
+                DT                                  DECtape
+                TR                                  terminal
+                SS                                  storage scope
+
+
+
+
+
+
+Bouknight, et al.                                               [Page 9]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+File Label
+
+   <file label>     ::=  <tape label> |  <tape label> / <tape file name>
+
+   <tape label>     ::=  <identifier>
+
+   <tape file name> ::=  <identifier>
+
+        Semantics: File labels provide the means for designating tape
+        files symbolically.  If the <tape label> form is used, the
+        designated file is assumed to occupy the entire tape.
+
+Flagged Control Statement
+
+   <flagged control statement>  ::= <flag> <control statement>
+
+   <flag>                       ::= <special>
+
+        Semantics: <Flagged control statement>s arc the user's names of
+        communicating with the PDP-11 system.  The <flag> must be the
+        system default flag (!) or a substitute which the user provides
+        by means of the <flag statement>.  Input to the system which
+        does not begin with a <flag> will be passed on to the process to
+        which the user is connected, if any.
+
+Control Statements
+
+   <control statement>  ::= <link statement> |
+
+                            <copy statement> |
+
+                            <end statement> |
+
+                            <user statement> |
+
+                            <status statement> |
+
+                            <out statement> |
+
+                            <to statement> |
+
+                            <escape statement> |
+
+                            <back statement> |
+
+                            <delete statement> |
+
+                            <transmit statement> |
+
+
+
+Bouknight, et al.                                              [Page 10]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+                            <lock statement> |
+
+                            <unlock statement> |
+
+                            <assign statement> |
+
+                            <label statement> |
+
+                            <create statement> |
+
+Link Statement
+
+   <link statement> ::= LINK TO <host> <q>
+
+   <q>              ::= <empty> |
+
+                        QUEUE   |
+
+                        QUEUE    <integer>
+
+        Semantics: The Link statement directs the system to set up a
+        connection between the user's unit and a remote host.  The <q>
+        construct allows the user to specify that, if the connection
+        cannot be set up immediately, the system is to keep trying.  If
+        the QUEUE form is used, the system will keep trying
+        indefinitely.  If the QUEUE integer form is used, the system
+        will try for integer minutes.
+
+Copy Statement
+
+   <copy statement>   ::= COPY <source> TO <dest> <q>
+
+   <source>           ::= NETWORK |
+
+                          <file label> |
+
+                          <source class> |
+
+                          <source device>
+
+   <source class>     ::= CR | TR | SS |
+
+   <source device>    ::= <source class> <device number>
+
+   <dest>             ::= NETWORK
+
+                          <file label> |
+
+
+
+
+Bouknight, et al.                                              [Page 11]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+                          <dest class> |
+
+                          <dest device>
+
+   <dest class>       ::= CP | LP | TR | SS
+
+   <dest device>      ::= <dest class> <device number>
+
+        Semantics: The <copy statement> directs the system to set up a
+        connection between the <source> and <dest> and copy records of
+        information between them.  If the <device class> or <device>
+        form is used for either <source> or <dest>, the copy process
+        cannot begin until a unit is assigned to the user.  If the <file
+        label> form is used, the copy process can likewise not proceed
+        until the system has access to a properly labeled tape. if the
+        NETWORK form is used, a connection to a remote process must be
+        pending.
+
+        The <q> construct has the same meaning as for the <link
+        statement>, with the additional provision that the condition
+        that caused the process to be incomplete may be the lack of a
+        device assignment.
+
+End Statement
+
+   <end statement>   ::= END
+
+        Semantics: The <end statement> causes the current connection to
+        be terminated.
+
+User Statement
+
+   <user statement>  ::= USER = <identifier>
+
+        Semantics: The <user statement> is used during the log in
+        process to allow the user to identify himself.
+
+Status Statement
+
+   <status statement> ::= STATUS <device class> |
+
+                          STATUS <peripheral designator>
+
+        Semantics: The <status statement> allows the user to interrogate
+        the system as to the status of a device or class of devices.
+
+
+
+
+
+
+Bouknight, et al.                                              [Page 12]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+Out Statement
+
+   <out statement> ::= OUT|LEAVE
+
+        Semantics: The <out statement> allows a user to log out of the
+        system.  If the OUT form is used, all queued process initiated
+        by the user are terminated.  The LEAVE from does not terminate
+        such pending queued processes so long as these processes do not
+        directly involve the user's terminal.
+
+To Statement
+
+   <to statement> ::= TO CON :<text> |  TO <user> : <text>
+
+        Semantics: The <to statement> allows the user to send a message
+        to the operator or another logged-in user.
+
+Flag Statement
+
+   <flag statement> ::= FLAG = <special>
+
+        Semantics: The <flag statement> allows the user to define the
+        character which the system recognizes as preceding a control
+        statement as distinguished from a message to a remote process to
+        which he may be attached.  The default flag character is "|".
+
+Back Statement
+
+   <back statement> ::= BACK ? {ascii special or control character}
+
+        Semantics: The <back statement> allows the user to define the
+        character which, in control or message mode, causes the system
+        to "forget" the previous input character.  The default backspace
+        character is RUBOUT (ASCII 1778).
+
+Delete Statement
+
+   <delete statement> ::= DELETE = {ASCII special or control character}
+
+        Semantics: The <delete statement> allows the user to define the
+        character which, in control or message mode, causes the system
+        to "forget" the previous line of input.  The default delete
+        character is ASCII VT (control K).
+
+
+
+
+
+
+
+
+Bouknight, et al.                                              [Page 13]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+Transmit Statement
+
+   <transmit statement> ::= TRANSMIT = {ASCII special or
+                                        control character}
+
+        Semantics: The <transmit statement> allows the user to define
+        the character which, in control or message mode, causes the
+        system to begin interpreting the control statement or to
+        transmit the message.  The default transmit character is
+        carriage return.
+
+Lock Statement
+
+   <lock statement> ::= LOCK
+
+        Semantics: The <lock statement> causes the system to prevent any
+        user or process but the process to which the user is currently
+        attached from sending messages to the user's terminal.
+
+Unlock Statement
+
+   <unlock statement> ::= UNLOCK
+
+        Semantics: The <unlock statement> reverses the action of a
+        previous <lock statement>.
+
+Assign Statement
+
+   <assign statement> ::= ASSIGN <assign device> <q>
+
+   <assign device>    ::= LP | DT | CP
+
+        Semantics: The <assign statement> causes the system to attempt
+        to assign a device not currently in use to the user.  The <q>
+        construct has the same meaning as for the <link statement>.
+
+Label Statement
+
+   <label statement> ::? LABEL DT <device number> <tape label>
+
+        Semantics: The <label statement> causes the system to write a
+        new label on the DEC tape specified.
+
+
+
+
+
+
+
+
+
+Bouknight, et al.                                              [Page 14]
+
+RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970
+
+
+Create Statement
+
+   <create statement> ::= CREATE <tape file name> ON <tape label>
+
+        Semantics: The <create statement> causes the system to create a
+        new file named <tape file name> on the DEC tape labeled <tape
+        label>.
+
+Purge Statement
+
+   <purge statement> ::= PURGE <tape label> |
+
+                         PURGE <tape file name> ON <tape label>
+
+        Semantics: The <purge statement> causes the system to delete all
+        tape directory information on the DEC tape or tape file
+        specified.
+
+
+           [ This RFC was put into machine readable form for entry ]
+            [ into the online RFC archives by Gottfried Janik 2/98 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bouknight, et al.                                              [Page 15]
+