RFC 80

RFC 80: PROTOCOLS AND DATA FORMATS 💖

okay bestie, title block first! 🎀 This is RFC 80 from the Network Working Group, filed under NIC 5608. The authors are E. Harslem and J. Heafner, both from RAND, and it's dated 1 December 1970. The header doesn't list a category, and it doesn't say what this document obsoletes or updates, so there's nothing else to track up top ✨

Because people were having lots of chats about protocols and data formats, the authors put out this note to share where they're at and what they've been looking into 🧚 They start with some specific sequences, then give some thoughts on two general implementation approaches that can handle these and other specifics. The big focus is the general solutions, not the specifics 💅

---

INITIAL CONNECTION PROTOCOLS 🦋

okay so the authors have two points about specific Initial Connection Protocols (ICPs) 👀 First, the ICP in NEW/RFC #66, which they look at for its generality and restate. Second, a proposal for a variant ICP that uses basically the same logic as NWG/RFC #66.

I. NWG/RFC #66 🌸

ngl, the only technical error in this ICP is that, as diagrammed, both the Server and User send ALL messages before the connections are established. That's inconsistent with Network Document No. 1 😭 Easy fix though, and it's shown in the restatement below.

For generality: any ICP that gets adopted as a standard should apply to more situations than a process calling a logger. Some network service processes hook directly to a user process, regardless of logger action, and could maybe use a standard ICP too 🧚 So, as shown below, the process name field of the server socket should be a parameter, with a value of zero being a special case for loggers.

Restatement of NWG/RFC #66 (using the same wording where appropriate)

Step 1: To start contact, the using process attaches a receive socket (US) and requests a connection to process SERV socket #1 in the serving HOST. (SERV = 0 for ICP to the logger.) As a result, the using NCP sends:

   1              4                 3          1     1
+-----+---------------------+---------------+-----+-----+
| RTS |          US         |      SERV     |  1  |  P  |
+-----+---------------------+---------------+-----+-----+

over link 1, where P is the receive link.

Step 2: The serving process (SERV) may decide to refuse the call, in which case it closes the connection. If it accepts, the serving process completes the connection (via an INIT system call, hence an STR) 💖

   1           3          1            4
+-----+----------------+-----+--------------------+
| STR |      SERV      |  1  |         US         |
+-----+----------------+-----+--------------------+

Step 3: When the connection is completed, the user process allocates a nominal amount of space to the connection, so the NCP sends:

   1     1            4
+-----+-----+--------------------+
| ALL |  P  |       SPACE        |
+-----+-----+--------------------+

where SPACE is the amount.

Step 4: The serving process then picks the socket pair it wants to assign to this user. It sends exactly an even 32 bit number over the connection. That even 32 bit number (SS) is the receive socket in the serving HOST. This socket and the next higher numbered socket are reserved for the using process 🎀

Step 5: Then it closes the connection. The serving NCP sends (step 4):

           4
+---------------------+
|         SS          |
+---------------------+

on link P, and (step 5):

   1            3         1             4
+-----+----------------+-----+--------------------+
| CLS |       SERV     |  1  |         US         |
+-----+----------------+-----+--------------------+

on the control link (which is echoed by the using NCP) ✨

Step 6: Now that both server and user know the remote socket pair for the duplex connection, <STR, RTS>s can be exchanged 🫶

Sever sends User

   1            4                     4
+-----+--------------------+--------------------+
| STR |      SS + 1        |          US        |
+-----+--------------------+--------------------+---+
| RTS |         SS         |        SS + 1      | Q |
+-----+--------------------+--------------------+---+

where Q is the Server's receive link.

User sends Server

   1             4                    4
+-----+--------------------+--------------------+
| STR |       US + 1       |         SS         |
+-----+--------------------+--------------------+---+
| RTS |          US        |       SS + 1       | R |
+-----+--------------------+--------------------+---+

where R is the User's receive link.

ALLocates may then be sent and transmission begun!! 🌈👑

II. A Variation of NWG/RFC #66 ✨

okay so this variation is giving "less is more" 💅 It cuts down on Network messages and gets rid of duplicated info transfer 🫶

Steps 3 and 4 above are deleted 🗑️ The user process isn't told directly which of the Server's sockets it's gonna get. Instead, it listens on sockets US and US + 1 for calls from SERV after step 5 above 🎧 It can reject any spurious calls 🚫 and when it accepts the calls from SERV, the connection is established ✨

Here's a sample sequence for this ICP (same notation as before, bestie 🦋):

1. User --> Server

         1            4                    3         1     1
      +-----+--------------------+----------------+-----+-----+
      | RTS |         US         |       SERV     |  1  |  P  |
      +-----+--------------------+----------------+-----+-----+

2. Server --> User

If accepted:

         1           3          1             4
      +-----+----------------+-----+---------------------+
      | STR |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+
      | CLS |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+

If rejected:

         1           3          1             4
      +-----+----------------+-----+---------------------+
      | CLS |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+

3. If accepted, user listens on US and US + 1.
4. Server --> User

         1             4                     4
      +-----+--------------------+---------------------+
      | STR |       SS + 1       |          US         |
      +-----+--------------------+---------------------+---+
      | RTS |         SS         |        US + 1       | Q |
      +-----+--------------------+---------------------+---+

5. User accepts the calls, hence:

User --> Sender

         1              4                     4
      +-----+---------------------+--------------------+
      | STR |        US + 1       |        SS + 1      |
      +-----+---------------------+--------------------+---+
      | RTS |        US + 1       |          SS        | R |
      +-----+---------------------+--------------------+---+

and the connection is established. 🎉

This cuts the number of network messages by two, and the info about the Server's sockets only gets passed once, through RTS and STR. Iconic efficiency 👑

---

PRE-SPECIFIED DATA FORMATS 💖

We wanna adopt the data format suggestions in NWG/RFC #42 and #63 🎀 We're fans of using multiple standards, each one for its own kind of problem 🌈

AN ADAPTABLE MECHANISM 🦋

Okay, so picture this. We want to hook up Network use with problem programs that nobody planned for the Network, and that probably won't just fit whatever Network standards exist when they get included 😭 This incompatibility problem is just as basic to the research behind the Network as different Host hardware is. Making every program come with extensive front-ends is not a reasonable goal 🙅‍♀️

We see the Network as a mix of three things: a) Hosts that provide services; b) parasite Hosts that hook terminals up to those services; and c) a whole spectrum of Hosts that are both users and providers of services 🌸 Making every parasite Host handle different protocols and data formats for every service its users need? Also not a reasonable goal 💀 The end result is programs and terminals that want to talk to each other but don't speak the same language 😩

One way to tackle the protocol and data format problems is an adaptable mechanism that programs and terminals can use to reach Network resources easily ✨ ARPA is sponsoring the Adaptive Communicator Project at Rand, a research effort into a teachable front-end process that connects people to programs 🧚 The terminal devices they're exploring include voice, tablets, sophisticated graphics terminals, etc.

The Adaptive Communicator looks super promising, but it won't be ready for a while ⭐ The Network Project at Rand went with the adaptable approach (_not_ adaptive, so no heuristics, no self-learning) 🙈 Our problem is getting Rand researchers onto the Network easily, assuming they've got different simultaneous applications that need different program protocols and data configurations 💜

We'll describe protocols and data formats separately so you can see what we mean by adaptation. Protocols are sequences of "system calls" that correspond to NCP commands, which NCP issues. Data formats are descriptions of regular message contents, and an NCP doesn't care about them 🍓

The Form Machine (adapting to data formats) 🧚

Quick context: the Form Machine is one of the finite state machines that recognize a form of _regular expressions_, which in our case describe data formats. Its notation is aimed at specific descriptions, so it can be more succinct for our purposes than regular expressions are 💅

The Form Machine is an experimental software package that links up a bunch of programs and terminals whose data format requirements are all different 🫶 We picture Form Machines sitting at various service providing Hosts so Network traffic stays low 🚦

To test the Form Machine idea, we're implementing two IBM OS-callable subroutines: a compiler that compiles statements describing data formats, and an executor that runs a compiled form on a data stream 🔥

For the Form Machine test, we need to mention another Rand program, the Network Services Program (NSP) 🌈 It's a multi-access program that connects the Network Control Program to both arbitrary programs and Video Graphics Consoles. (We think of a terminal as just another program with a different interface, like # characters/line, # lines/page, unique hardware features, the application it's used for, etc.) The Form Machine subroutines can be called from NSP, either from consoles or by program direction 💖

Here's how it works: a console user names and specifies the data forms they'll use. The forms get compiled and stored for later ✨ Later on, when the user wants to set up Network connections and send data, they dynamically associate named forms with each side of a port (a symbolically named Network full duplex connection) 🦋 Incoming or outgoing data streams get executed according to the compiled form, and then the transformed stream is passed along to the console/program or to the Network, respectively 💅

The details of the Form Machine notation's syntax don't matter much to the wider Network community 🙈 The features of the notation, though, are super interesting. Eventually it'll cover high performance CRT displays, TTY, and arbitrary file structures. To test whether it's viable, they're implementing a subset of those features right now 🧪

The current version has these features:

1. Character code translation (viz., decimal, octal, hexidecimal, 8 bit ASCII, 7 bit ASCII, EBCDIC, and binary).
2. Multiple break strings (lots of terminals have multiple termination signals).
3. Insertion of literals (mostly used for display information presentation).
4. Skip or delete arbitrary strings (used to remove record sequence numbers, etc., that aren't meant to be displayed).
5. Record sequence number generation.
6. String-length computation and insertion.
7. _Arbitrary_ data string length specifications, e.g., "a hex literal string followed by an _arbitrary_ number of EBCDIC characters, followed by a break string, .....".
8. Concatenation of Network messages, i.e., the execution of compiled forms on incomplete data strings.
9. Data field transposition.
10. Both explicit and indefinite multiplicative factors for both single and multi-line messages.

Features that aren't being implemented yet, but will be added if it works out, include:

1. Graphics oriented descriptions.
2. General number translations.
3. Conditional statements.
4. A pointer capability.

The Protocol Manager (adapting to NCP command sequences) 🎧

NSP lets terminal users and programs work at the NCP protocol level, so think LISTEN, INIT, et al. It also lets them send and reshape information that only means something to themselves. This "hands-on" approach is great from a systems programmer's or exploratory point of view 🤓 But the researcher who keeps using the same remote program over and over shouldn't have to do the tedious "handshaking" every time 😤 So it's better to let them define, store, retrieve, and run "canned" protocol sequences 🍓

We're currently specifying a Protocol Manager as an NSP module that'll support those operations on NCP command sequences ✨ Its features:

1. The sequences can contain "break points" so the console user can dynamically inject whatever info is needed in context 💅
2. A command's parameters can contain tokens whose values come from the remote party during the protocol dialog. For example, in Note #66, the socket number provided by the server is used by the user in later RTS and STR commands 🦋

REQUEST 🫶

We'd love to hear from anyone about the idea of adapting to data formats and protocols 💜 Is this a reasonable approach? What should it cover? 🌸

JFH:EFH:hs

Distribution 📬

Albert Vezza, MIT
Alfred Cocanower, MERIT
Gerry Cole, SDC
Bill English, SRI
Bob Flegel, Utah
James Forgie, LL
Peggy Karp, MITRE
Nico Haberman, Carnegie-Mellon
John Heafner, RAND
Bob Kahn, BB&N
Margie Lannon, Harvard
James Madden, Univ. of Ill.
Thomas O'Sullivan, Raytheon
Larry Roberts, ARPA
Robert Sproull, Stanford
Ron Stoughton, UCSB
Chuck Rose, Case University
Benita Kirstel, UCLA

           [This RFC was put into machine readable form for entry]
            [into the online RFC archives by Lorrie Shiota, 10/01]