RFC 39

RFC 39: COMMENTS ON PROTOCOL RE: NWG/RFC #36 🎀

okay bestie, title block first 💅 this one's from the Network Working Group, it's RFC 39, written by E. Harslem and J. Heafner at RAND, dated 25 March 1970 🦋 the original doesn't list a category or status, and it doesn't say what it obsoletes or updates, so I'm not making that up ✨

We're basically giving feedback on NWG/RFC #36 💖 these are suggestions for additions to the April 28th 1970 protocol grammar specifications 🌸

ERROR MESSAGES 🚨

okay so the first thing is an error message format 🫶 it looks like this:

<ERR> <Code> <Command in error>

it's desirable to include debugging aids in the initial protocol for checking out Network Control Programs, etc. 🔍 we need that to actually debug stuff, obviously 😭

there are three classes of errors: content errors, status errors, and resource allocation or exhaustion 🧚 the <Code> specifies the class and the offending member of the class. the command gets returned to the sending NCP for identification and analysis 💜

status errors are things like messages sent over blocked links and attempts to unblock a link that's already unblocked 🙈

content errors are things like an invalid RFC complete, a message sent on a link that isn't connected, closing a link that was never connected, and an attempt to unblock a link that isn't connected 💀

resource errors are things like a request for a non-existent program and connection table overflow, etc. 🍓 resource errors should be followed by a <CLS> in response to the <RFC> ✨

QUERIES 🔮

queries are giving extension to the <ERR> facility plus limited error recovery, which means you don't have to re-initialize an NCP 🙌 very iconic 👑

<QRY> <My   Socket>  < >

or

<QRY> <Your Socket>  <Text>

the first command asks the remote NCP to supply the status of all connections to the user specified by the user number in <My socket> 🦋 the second one is the reply, and <Text> contains the connection status information 💅

if an NCP wants the status of all connections to a remote HOST, the <My Socket> is zero 🌈

PROGRAM TERMINATION NOTIFICATION 🛑

<TER> <My Socket>

this command supplements rather than replaces <CLS>, so it's not taking over for it 🫶 it severs all communication between a program and those programs in a given HOST that it's connected to 💥

this basically does what would otherwise need multiple <CLS> commands, which is so efficient, periodt ✨ the <My Socket> contains the sender's user number 🎀

HOST STATUS 🏠

<HCU>
<HGD>

these messages (HOST coming up and HOST voluntarily going down) are compatible with asynchronous, interrupt-driven programs 🌸 that's different from the more conventional post/poll method, which is lowkey the main character move 👑

TRANSMIT AND BROADCAST 📣

<TRN> <Body>
<BDC> <Body>

unlike the previous commands, these aren't sent over the control link. they go over links assigned to user programs instead 🦋 the prefix of <TRN> or <BDC> tells the receiving NCP what to do with the message body 💜

<TRN> means the message goes to a single process 🧚 <BDC> tells the destination NCP to distribute the message over all receiving connections linked to the sender 📡

when a user makes a system call to an NCP asking for <BDC>, the NCP generates one <BDC> to each HOST the sender is connected to 🫶

RFC AND DYNAMIC RECONNECTION 🌀

ngl this one's the big critique 😭 the protocol is complex, it proliferates control messages, and it causes queues (to become associated with re-entrant procedures) that are artificially imposed via the protocol (remote AEN assignment) 💀 it also discounts the situation where only controlling process "A" knows that slave process "B" should be "rung out" in a dynamic reconnection 🙈

the <ERR>, etc., are suggestions for inclusion as additions in the April 28th protocol specifications 🌸 the criticism above is, of course, not meant to affect modifying the RFC structure by April 28th, and it's not reflecting on the people who planned it 🫶 we haven't studied the problem yet, though 🔍

it's meant to voice concern about complexity and resulting response times ⏱️ this is a difficult problem and deserves more study after we've exercised the current RFC specifications 💅 we hope to offer constructive suggestions about the RFC in the future 🦋✨

---

JFH:hs

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Mario Vitale 08/99 ]