RFC 44

Comments on NWG/RFC 33 and 36 🎀

okay bestie, the paperwork first 📋✨ this is RFC 44, from the Network Working Group, written by A. Shoshani, R. Long, and A. Landsberg at the System Development Corporation, dated 10 April 1970. The original doesn't list a category, status, obsoletes, or updates, so I'm not making any up 🙈 it's a set of comments on RFC 33 and RFC 36.

---

The big picture: the team is mostly happy with the suggestions for the new Host-to-Host protocol 💖 but they think a few refinements would help. Let's get into it 💅

I. Two Kinds of Reconnection 🦋

okay so there are apparently two cases of reconnection:

1. Reconnecting from a socket on a local Host to another socket on the same local Host. RFC #33 called this "switch" 🔄 The local sockets can belong to different processes (like the "Login" process switching a connection over to a process that was just created), or they can belong to the same process (like a process that accepts calls for connections on one socket, then switches to another of its sockets after a connection is set up).
2. Reconnecting from a socket on a local Host to a socket on a foreign Host 🌍

they want to split these up, and here's why 👑

a) Case 1 is necessary and useful, but nobody's sure yet how useful Case 2 is 🤔

b) Case 1 is simple to build (at least in theory), while Case 2 needs a whole complicated set of commands because the network is asynchronous. RFC #36 suggested four out of nine commands just to handle Case 2 💀

so at least in the first version of the Host-to-Host protocol, Case 2 should be left out 🙅‍♀️ instead they need an extra system call (not a command) to handle Case 1, which is SWITCH <socket 1> <socket 2> ✨

II. BLOCK vs. CLOSE 🚫

the CLOSE command from RFC #36 is being used for two jobs: blocking a connection and aborting a connection. that's giving confusion 😭 so they want two separate commands, BLOCK and CLOSE. the response to either one can still be the SUSPEND command, which acknowledges that the BLOCK or CLOSE was received, just like RFC #36 said 💜

III. Goodbye, Foreign Socket Numbers 👋

once a connection is set up, there's no real reason to keep the "foreign socket" in the local connection table 🙈 each foreign Host link number has a one-to-one match with a foreign socket number, so the commands can just use the link number instead. that means every command except RFC can use link numbers, and we can drop a 40-bit foreign socket number from every entry in the connection table. this matters a lot because some Hosts are super tight on space 🥺

they did note one catch: if connections get multiplexed over links (like RFC #38 suggested), then the foreign socket would need to stay in the connection table 🧚

IV. The Word "PORT" 🔌

RFC #33 introduced the term PORT. it's private to every Host, so it's really up to each one, but here's their take 💅 if ports have a one-to-one match with a socket for some user, then ports are totally redundant 💀 however, a Host might want to multiplex ports over connections, and in that case, it would need an extra mechanism ✨

Summary of the Last Four Comments 📝

to wrap up III and IV (and the rest), they suggest that the first version use the following system calls and commands. most of them come from RFC 33 and RFC 36 🍓

System Calls:

1) INITIATE <my socket> <your socket>
2) ACCEPT  <my socket>
3) SWITCH <socket 1> <socket 2>
4) LISTEN <my socket>
5) CLOSE <my socket>
6) TRANSMIT <my socket> <address>

Commands:

Commands 0, 1, 3, 4 as in RFC #36 (pp.5) and in addition:

1) BLOCK: BLK <link>
2) CLOSE: CLS <link>

V. The Open Questions 🌈

okay so on top of all that, there are some issues they need to decide on, one way or the other, together with the first version of the protocol. maybe they should set a date for people to share their preferences and then decide from there 🗓️ all of these came up at the UCLA meeting on March 17, 1970, but got put aside for later 😤

1. "Double padding" 🧱 this is when a message doesn't end on a word boundary. two possible fixes came up:

a) Hosts add their own padding on top of the IMP's padding (double padding).

b) Hosts make sure every message ends on a word boundary by shifting their messages when needed and adjusting the "marking" to match.

2. "Echoing" 🔁 there are three apparent options:

a) Echoing

b) No echoing

c) Optional echoing, where a bit in the "Leader" might be used to mark this option.

3. "Code Conversion" 🔤 originally, BB&N suggested doing the conversion in the IMPs, using ASCII-8 as the common code. that got rejected, mainly because people said ASCII-8 isn't big enough for some uses, like graphics. plus, conversion in the IMPs might slow them down and eat up space that could be used for buffers 😬 the team really wants a common code, even if the IMPs aren't the ones doing the conversion, so that all incoming text messages use the same code and only one conversion table is needed. outgoing text messages should get converted into this common code. obviously, a "no translation" option should still be possible for binary data, or for data that can't be represented in the common code 💾 since every known code is probably too restrictive for some purpose, they suggest adopting a Network Common Code (NCC) that uses all 256 possible characters (for 8-bit code), with the "important" part of the union of all the codes used across the network included 🌐

VI. Their Picks 💖

here's where the team lands on the questions above 🫶

a) "Double padding" 🧁 it turns out it's easier for them to get messages sent on a word boundary by shifting the leader of a message (and adjusting the "marking" to match) instead of shifting the data. so they'll go with option V.1.b) 💅

b) "Echoing" 🙅‍♀️ they prefer no echoing. they think character echoing should be handled locally 🏠

c) "Code Conversion" 🔥 they prefer a Network Common Code. to start, ASCII-8 can be used, and then it can be expanded based on what the network needs ✨

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alison De La Cruz 12/00 ]