RFC 312

Proposed Change in IMP-to-Host Protocol

πŸ“… published March 1972, from ietf

RFC 312: Proposed Change in IMP-to-Host Protocol πŸŽ€

okay bestie, this one's from A. McKenzie at BBN 🧚, filed as NIC 9342 on 22 March 1972, and it's in category B.1. it doesn't say anything about obsoleting or updating other RFCs, so there's nothing to swap out 🫢

the whole point is that BBN was thinking about redefining the IMP-to-Host error message types (type 1 and type 8) and adding new IMP-to-Host error message types πŸ’… the goal is to help Hosts figure out what recovery action to take, and they're claiming it won't cause any serious reprogramming problems πŸ™ˆ they plan to install everything within a few months, so if anyone has strong objections, they need to speak up quickly 😭

the proposed changes come in two classes ✨

A. General Error Message πŸ’–

okay so sometimes the Host ignores queued input for a "long time" πŸ’€ when that happens, the IMP drops its ready line for a little bit. that causes the "error flip-flops" to get set (see RFC #270, NIC 7818). the IMP then sends a few NOP's to the Host and goes back to normal πŸ”₯

BBN wants to add a new message (message type 13) alongside those NOPs. it's going to tell the Host three things: the IMP's Ready Line was dropped, the IMP's error flop was set, and the IMP will reply to the next completion of a Host-to-IMP message with a type 1 or type 8 message, because the error flip-flop is set πŸ¦‹

B. Error Messages which are Responses to Specific Host-to-IMP Transmissions 🌈

this part is literally the main event, so read carefully πŸ‘‘
  1. IMP-to-Host message type 1 gets redefined to mean: "IMP's Error flip-flop was set on a message which the IMP cannot identify." 🌸
  2. IMP-to-Host message type 8 gets redefined to mean: "IMP's Error flip-flop was set during receipt of the message identified by the 'source' and 'link number' bits of this error message." πŸ’œ
  3. IMP-to-Host message type 10 gets defined (new!) to mean: "A Host-to-IMP message was too short (and cannot be identified)." πŸ“
  4. IMP-to-Host message type 11 gets defined (new!) to mean: "A Host-to-IMP message was too long; the message is identified by the 'source' and 'link number' bits of this error message." ✨
  5. IMP-to-Host message type 12 gets defined (new!) to mean: "A Host-to-IMP message with an illegal message type code was received; the message is identified by the 'source' and 'link number' bits of this error message. (Note that the erroneous type code is not included in the error message.)" πŸ™ˆ

AAM/jm πŸ’…

[ 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 ] 🫢
πŸ“¦ where this page comes from