RFC 151

COMMENTS ON A PROFERRED OFFICIAL ICP (RFCs 123, 127) 🎀

NWG/RFC # 151 🦋 by A. Shoshani at SDC, NIC #6755, dated May 10, 1971. The header doesn't list a category, and it doesn't say what this RFC obsoletes or updates, so there's nothing else to add there 💅.

The INIT mix-up 🙈

Okay so bestie, Bob Long at SDC noticed something kinda sus 👀. The order that messages actually go out to the network depends on the local NCP. Commands can get priority over data, so in the sequence RFC 123 gives for the server (top of Page 3), the last two INIT commands might go out before data = S on socket = L is sent. (This is literally what happens in SDC's current NCP implementation 💀.)

The implication is that the user's NCP should be prepared to hold onto the INITs it got from the server until the user process gets the data = S and sends two INITs back in response 🫶.

This is being brought up now so people can think about it before the Atlantic City meeting and say whether their NCP can handle it ✨. It may be necessary to make it explicit in the ICP that the two INITs sent by the server should go out only after the data = S is sent, or even after the user process acknowledges its receipt 🌸.

A more general vibe check 💜

I have a bigger remark about the ICP too. This is a third level protocol, so it should not alter or ignore the procedures of the second level protocol (the Host-Host protocol). In particular, three remarks seem appropriate:

RFC 19                                                      October 1969

1. In RFC 123 (bottom of Page 2), it's suggested that the byte size for the connection to the server socket L is 32. But in the modifications to the second level protocol (RDC 107), it's specified that it's up to the sending process to choose the byte size. According to the Host-Host protocol, NCPs should be prepared to accept messages in any byte size (1<= size <=255), so there's no need to impose a size of 32 here 🍓. Also, since the sender gets to choose the byte size, some Hosts may pick one that's simple and convenient for them, and their NCP may not be set up to transmit in an imposed byte size 😭.
2. In RFCs 66 and 80, an ALL is expected on the connection to the server socket before any data can be sent. In RFCs 123 and 127, the ALL requirement just vanished 👻. But the ALL is a Host-Host protocol requirement, and dropping it creates a special case 🙃. A particular NCP implementation may cause the ALL to be sent internally when a connection is created, without the user process having any control over it. Relaxing this requirement would mean a special case for the receiving NCP not to send the ALL, and for the sending NCP to send the data = S without first receiving an ALL.
3. In RFC 127, I disagree with the comment "send 32 bits of data in one message." It's a second level protocol decision that a message can be sent in pieces of any size, and the size is specified through the ALL mechanism. Plus, there may be hosts that aren't ready to accept more than a few bytes at a time (TIPs) 🛑.

In general, we should not make second level decisions in a third level protocol. Let's keep our lanes clean, bestie 💅🌈.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ]