RFC 76

Connection by name: User oriented protocol

πŸ“… published October 1970, from ietf

Connection-By-Name: User-Oriented Protocol πŸ’–

Okay bestie, this is RFC 76 πŸŽ€, and its title is Connection-By-Name: User-Oriented Protocol. It came from the Network Working Group (NIC 5180) and is dated 28 October 1970 πŸ¦‹. The authors are J. Bouknight, J. Madden, and G. Grossman, all from the University of Illinois ✨. The header doesn't list a category or status, and it doesn't say whether this RFC obsoletes or updates anything πŸ™ˆ.


I. Introduction ✨

Okay so, shortly after the first of the year, 1971, the Center for Advanced Computation (CAC) at the University of Illinois is going to start using the ARPA network 🌸. CAC is one of a small class of network nodes whose whole thing is being a port to the network. Like, that's it. All of the computing power for these nodes gets borrowed from other nodes on the network, ILLIAC IV for example πŸ’».

Here's the tea: most of the users at the Center are not very sophisticated about data communication techniques and practices πŸ’…. They'll eventually be the majority of people using the network from every node, but the problem is basically ours from the start 😭.

When we talked to our future users while we were designing the port, the biggest confusion (and honestly, consternation πŸ’€) came from having to deal with network protocol at the "nitty-gritty" level of sockets, links, and so on. Most of them are super used to computer systems at the file and device-by-name level, where the software handles the details. But on the current version of the network, the user handles all the details πŸ™ˆ.

So we had to go looking for a user level interface to network protocol 🧚. In it, all user protocol is handled symbolically, and system procedures do the translating into host-to-host protocol. Iconic, right? πŸ‘‘

Right now, connections get set up by exchanging known socket numbers for the four loose ends of the connection. That means either the user or the process has to always know every socket number they'll use at their own installation or anyone else's, OR their NCP (and/or related software) has to remember them and let them reference them symbolically 🫢.

We're proposing a more general fix for the "telephone book" approach to getting socket numbers for users or processes ✨. Only the host at each site knows its socket number space at any given instant, along with the status of the user or process each socket number is assigned to πŸ”₯. Most permanently assigned devices and/or processes already have standard mnemonic labels, like DSK (disk), LP (line printer), CR (card reader), TECO (PDP-10 text editor), and so on πŸ“. In most systems, all other communication goes through files or pseudo files, which users only know by name and not by their internal mechanism. So basically, most intrasystem communication at the user level is symbolic reference to both devices and processes πŸ¦‹.

We're proposing facilities, added by extending the current protocol, that will let users use the network on a connection-by-name basis, the same way they already do in their host system πŸ’–. For the rest of this paper, we'll present the suggested extensions to the current protocol and show how they work in a dialogue between a user at CAC, who is controlling two processes: one at UTAH, and one at PAOLI (the ILLIAC IV construction site) 🌈.


II. Proposed Extensions to Protocol πŸŽ€

Let's define a class of syntax elements for our proposed extensions to the protocol. (This syntax is written in the metalanguage of the ALGOL-60 report, so it's a little retro, but it's giving classic πŸ•°οΈ.)

<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, and other hard peripherals with fixed processing tasks πŸ–¨οΈ. A starter set of <labels> might look like this:

   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

The format of <usercode> is whatever the responding host uses for the current discussion πŸ’…. Future discussions about foreign-user usage of host facilities might end up with a standard format for the entire network 🌍.

Most systems can identify files with one <string> plus the <usercode> ✨. Others, like the Burroughs B6500, use multifile identifiers, where many <strings> can show up in the <label> πŸ™ˆ. The set of <char> is the one proposed in RFC 66, which is ASCII πŸ’œ.

The proposed extensions involve a "request" for information, plus a few variants of a "response" to that request 🫢.

A. Request for Socket Number for this Label

Here's the request message:

<RFSNL> <my socker #> <0> <label>

The RFSNL is sent on the control link to the destination host, asking for the socket number of the attached <label> πŸ¦‹.

B. Acknowledgement of Request

When an <RFSNL> comes in, the destination host sends back one of three responses πŸ”₯:

<AORP> <desired socket#> <your socket #>

<AORN> <desired socket#> <your socket #>

<AORN> <0> <your socket #>

The first response gives back the requested socket number and means the user, device, or process exists ✨. The second gives back the requested socket number too, but it means the user, device, or process exists and is not currently available for connection 😭. The last one means there is no such user, device, or process at all πŸ’€.

C. Discussion

These extensions to the protocol are meant to help users get used to using the network 🌸. The weirdness gets toned down, and honestly, for users of the B6500 it's erased completely 🧚. There's a preliminary appendix attached to this RFC that describes the user language of the network port facility being brought up at CAC πŸ“–. Next up, we'll walk through a sample user session on the CAC facility and show exactly how the protocol gets used to set up the right communication paths πŸ’–.

III. Example of User Dialogue πŸŽ€

okay so picture this: a user at CAC, site code URBANA 🌸 His terminal is an alphanumeric CRT terminal, and we're assuming the code conversion problems for network communications are already solved πŸ’…

This session is kind of a big deal because two processes get set up at two host sites, and a third host site is in charge of the whole thing πŸ‘‘ Everything here works with the current protocol plus the proposed extensions, so nothing new is needed beyond what we already talked about.

We also assume that some form of standard user code is in use at all host sites, so every network user can be uniquely identified whenever they're present 🫢

Quick reading notes: output from each system is underlined in the original, and comments get pushed to the right so they're easier to read πŸ¦‹ Also, everything about the UTAH system is purely hypothetical, so don't come for me πŸ™ˆ

    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.

   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.

   * 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.

   ! 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.

Syntax and Semantics for the Terminal User Control Language

for the Proposed PDP-11 ARPA Network Terminal System

by G. R. Grossman 🌈

Prefatory Notes ✨

okay so this document is the very first attempt at a control language for terminal users on the PDP-11 network terminal system πŸ’– It's meant to be powerful enough to give the user a minimal way to attach to remote host computers over the ARPA network, start up processes, and send data flowing to local peripheral devices πŸ¦‹

The hardware setup they had in mind is a PDP-11/20 with at least 8k of core, a small disk (512 kilobytes of storage), a console teletype, and optional goodies like card readers, line printers, DECtapes, user terminals, card punches, storage scopes, etc. 🧚

The executive system is a basic driver that controls autonomous processes and interrupt-driven device service routines. It keeps tables in core and on the small disk for logging peripheral usage, tracking connections on the network, queuing up tasks that can't be done right away, storing attributes of remote hosts, etc. πŸ’…

Network hosts handle communication either character-at-a-time or in message mode, and they may or may not echo characters over the network. So the system takes that into account when it connects to specific hosts 🫢 If the connection is in message mode, there's minimal line-by-line editing (character and line deletion) πŸ“

Users can change the flag and message transmit characters too, which helps avoid incompatibilities between the PDP-11 and other hosts πŸ”₯

Last but not least, this document does NOT cover control card syntax for card reader usage, or the operator's control language. Those get their own documents later πŸ™ˆ

Character Set 🌸

   <character> ::= <letter> | <digit> | <special> | <space>

   <letter>    ::= A | B | ... | Y | Z
   <digit>     ::= 0 | 1 | ... | 8 | 9

   <special>   ::= ! | " | # | $ | % | & | ' | ( | ) | * | + | , | - |
                   . | / | : | : | < | = | > | ? | @ | [ |  | ] | ^ |
                     |` | { | <bar> | }

Identifiers πŸ¦‹

   <identifiers> ::= <letter> | <identifier> <letter> |
                     <identifier> <digit>

Semantics, bestie: identifiers are how we name peripheral units, host computers, and friends ✨ No identifier can go over 8 characters in length, so keep it short and sweet πŸ’…

Numbers πŸ”’

   <integer> ::= <digit> | <integer> <digit>

Semantics: integers are the ONLY form of number the control language allows πŸ™Œ They must not exceed 2^15-1, so don't try to go over that, it's giving error πŸ’€

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 classes designate classes of peripherals (the "lasses" in the original is a typo, but we all know what they meant 😭).

OPR designates the operator's console teletype. The classes of peripherals that match up with the device classes are on this table:

    <device class>                      type of peripheral

        CR                                  card reader
        CP                                  card punch
        LP                                  line printer
        DT                                  DECtape
        TR                                  terminal
        SS                                  storage scope

File Label πŸ“‚

   <file label>     ::=  <tape label> |  <tape label> / <tape file name>

   <tape label>     ::=  <identifier>

   <tape file name> ::=  <identifier>

Semantics: file labels are how we designate tape files symbolically 🧚 If the <tape label> form is used, the designated file is assumed to occupy the entire tape, so no need to overthink it 🌈

Flagged Control Statement 🚩

   <flagged control statement>  ::= <flag> <control statement>

   <flag>                       ::= <special>

Semantics: flagged control statements are the user's way of communicating with the PDP-11 system πŸ’œ The <flag> must be the system default flag (!) or a substitute the user provides by means of the <flag statement>. Input to the system that doesn't begin with a <flag> gets passed on to the process the user is connected to, if there is one 🫢

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> |
                            <lock statement> |

                            <unlock statement> |

                            <assign statement> |

                            <label statement> |

                            <create statement> |

Okay so the Link statement is how you tell the system to hook your unit up to a remote host πŸ’–

<link statement> ::= LINK TO <host> <q>

<q>              ::= <empty> |

                     QUEUE   |

                     QUEUE    <integer>

The <q> part is the lowkey clutch bit 🫢 It lets you say "if the connection can't happen right now, keep trying." Plain QUEUE means the system keeps trying indefinitely πŸ”, and QUEUE <integer> means it keeps trying for that many minutes ⏳.


Copy Statement πŸ“‹πŸ©·

This one is giving copy-and-paste between two places πŸ’… The <copy statement> sets up a connection between a <source> and a <dest> and copies records of information across.

<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> |
                       <dest class> |

                       <dest device>

<dest class>       ::= CP | LP | TR | SS

<dest device>      ::= <dest class> <device number>

Now the fine print, bestie 🧐 If the <device class> or <device> form is used for either the <source> or the <dest>, the copy can't start until a unit is assigned to the user πŸ”Œ If the <file label> form is used, the copy also can't go ahead until the system has access to a properly labeled tape πŸ“Ό And if the NETWORK form is used, a connection to a remote process has to be pending 🌐

The <q> part works the same way as it does for the Link statement, with one extra twist ✨ The thing holding the copy up might be that there's no device assignment yet.


End Statement πŸ›‘

Short and iconic πŸ’€ The <end statement> is just:

<end statement>   ::= END

It makes the current connection get terminated. Bye bye πŸ‘‹πŸ¦‹


User Statement πŸͺͺ

The <user statement> is how you introduce yourself during the log in process 🧚 It looks like this:

<user statement>  ::= USER = <identifier>

Status Statement πŸ”

This is your little detective move πŸ•΅οΈβ€β™€οΈ The <status statement> lets you ask the system what's up with a device, or with a whole class of devices:

<status statement> ::= STATUS <device class> |

                       STATUS <peripheral designator>

Out Statement πŸšͺπŸ’œ

The <out statement> is how you log out of the system:

<out statement> ::= OUT|LEAVE

Here's the tea β˜• If you use OUT, every queued process you started gets terminated πŸ’€ If you use LEAVE instead, those pending queued processes stay alive, as long as they don't directly involve your terminal 🌸


To Statement πŸ’Œ

The <to statement> is your messaging moment πŸ’¬ You can send a message to the operator or to another logged-in user:

<to statement> ::= TO CON :<text> |  TO <user> : <text>

Flag Statement 🚩

<flag statement> ::= FLAG = <special>

This one lets you pick the character the system looks for before a control statement πŸͺ„ It's how the system tells "this is a command for me" apart from "this is a message for the remote process you're attached to." The default flag character is "|" πŸŽ€


Back Statement βͺ

<back statement> ::= BACK ? {ascii special or control character}

This lets you choose the character that makes the system "forget" the previous input character πŸ™ˆ In control or message mode, that is. The default backspace character is RUBOUT (ASCII 1778) πŸ“


Delete Statement πŸ—‘οΈ

<delete statement> ::= DELETE = {ASCII special or control character}

Same energy as the Back statement, but bigger πŸ’₯ This character makes the system "forget" the previous line of input, again in control or message mode. The default delete character is ASCII VT (control K) πŸ’œ


Transmit Statement πŸš€

<transmit statement> ::= TRANSMIT = {ASCII special or
                                     control character}

This is the send button πŸ“¨ The character you pick here tells the system to start interpreting the control statement or to transmit the message, in control or message mode. The default transmit character is carriage return ↩️


Lock Statement πŸ”’

<lock statement> ::= LOCK

Okay, this is protective and honestly iconic πŸ›‘οΈ It stops any user or process except the process you're currently attached to from sending messages to your terminal.


Unlock Statement πŸ”“

<unlock statement> ::= UNLOCK

This reverses a previous <lock statement> πŸ¦‹ Your inbox is open again, babe πŸ’…


Assign Statement 🎯

<assign statement> ::= ASSIGN <assign device> <q>

<assign device>    ::= LP | DT | CP

The <assign statement> has the system try to assign a device that isn't in use to you πŸ§ƒ The <q> part means the same thing it does for the Link statement, so keep trying, or keep trying for some number of minutes πŸ”


Label Statement 🏷️

<label statement> ::? LABEL DT <device number> <tape label>

This one writes a brand new label on the DEC tape you specify πŸ“Όβœ¨


Create Statement πŸŽ€

<create statement> ::= CREATE <tape file name> ON <tape label>

Now we're making things 🧁 This creates 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>

Ugh, the cleanup crew 🧹 The Purge statement deletes all tape directory information on the DEC tape or tape file you specify. Be careful, bestie πŸ™ˆβš οΈ


           [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Gottfried Janik 2/98 ]
πŸ“¦ where this page comes from