RFC 40

Network Working Group, Request for Comments 40 🎀

More Comments on the Forthcoming Protocol ✨

Written by E. Harslem and J. Heafner of RAND, March 1970 📅. The header doesn't list a category, and it doesn't say what this RFC obsoletes or updates, so there's nothing more to add there 🫶.

Okay bestie, so we recently talked about NWG/RFC Nos. 36 and 39 with Steve Crocker at UCLA 💅. Steve asked us to spell out the errors, queries, and HOST status stuff from NWG/RFC #39 🔥.

Pls drop your takes soon so they can actually shape the upcoming protocol specs 🦋

ERROR MESSAGES 💖

Every error message looks like this 👇

<ERR> <Code> <Command length> <Command in error>

The <Code> is an eight-bit field that tells you the error type. The assigned codes are listed below. <Command length> is a 16-bit integer that tells you how long the <Command in error> is, in bits. The <Command in error> is the spurious command 😭.

The ranges of <Code> are in hexadecimal, and they look like this:

00     Unspecified error types
10-0F  Resource errors
10-1F  Status errors
20-2F  Content errors
30-3F  Unused

Here are the specific <Code> values and what they mean 🧚

<Code> value   Semantics

    00         Unspecified errors.
    01         Request for an invalid resource.
    02         Request for an exhausted resource, try later.
   03-0F       Unused.
    10         Invalid <RSM>, i.e., link connected but unblocked.
    11         Invalid <SPD>.
    12         Invalid <ASG>, i.e., connected but no <RDY>
                 received.

<Code> value   Semantics

    13         Message received on blocked link.
   14-1F       Unused.
    20         Unknown command code.
    21         Message received on unconnected link.
    22         Invalid <RFC>.
    23         Invalid <CLS>.
    24         Invalid <RSM>, i.e., link not connected.
    25         Invalid <FND>.
    26         Invalid <END>.
    27         Invalid <RDY>.
    28         Invalid <ASG>, i.e., not connected.
   29-2F       Unused.
   30-FF       Unused.

QUERIES 🌸

These are the two forms you'll see 🦋

<QRY> <My Socket>
or   <RPY> <Your Socket> <Text>

The <QRY> is the query from NWG/RFC #39, and <RPY> is the reply. The format of <Text> is below, but also peek at NWG/RFC #36, p. 3 🙈

<Text>::= <16 bit count of relevant connection table entries>
          <relevant connection table entries>

<relevant connection table entries>::=
                                     <relevant connection table entries>
                                     <a relevant connection table entry>
                                     <a relevant connection table entry>

<a relevant connection table entry>::= <local socket> <foreign socket>
                                       <link> <connection state>
                                       <flow state and buffer control>
                                       <reconnection control state>

HOST STATUS 🍓

Here's the message 👇

<NOP>

An NCP can be up, down, pending, etc. (the states are giving main character energy 💀). When an NCP switches its state to UP, it should send a <NOP> to each remote NCP, and that tells them the NCP is available ✨. The sending NCP can then build a vector of HOST status from the RFNMs it gets back. An NCP that receives a <NOP> can update the availability of the sending NCP in its HOST status vector 🫶.

[ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Richard Ames 6/97 ]