RFC 76
Connection by name: User oriented protocol
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> |
Link 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
- ietf: rfc76 1970-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms