IMP-Host Errors: Proposed Change in IMP-to-Host Protocol
BBN proposes clearer IMP-to-Host error messages so Hosts can pick the right recovery action.
McKenzie, A.M., "Proposed Change in IMP-to-Host Protocol", RFC 312, DOI 10.17487/RFC0312, March 1972, <https://www.rfc-editor.org/info/rfc312>.
@misc{rfc312,
series = {Request for Comments},
number = 312,
howpublished = {RFC 312},
publisher = {RFC Editor},
doi = {10.17487/RFC0312},
url = {https://www.rfc-editor.org/info/rfc312},
author = {A.M. McKenzie},
title = {{Proposed Change in IMP-to-Host Protocol}},
pagetotal = 2,
year = 1972,
month = mar,
} RFC text
Network Working Group A. McKenzie
RFC #312 BBN
NIC 9342 22 March 1972
Categories: B.1
Proposed Change in IMP-to-Host Protocol
We are currently considering a redefinition of the IMP-to-Host
error message types (type 1 and type 8) and the creation of addi-
tional IMP-to-Host error message types. We believe that these
changes will assist the Hosts in determining appropriate recovery
action, without causing any serious reprogramming problems. Our
current plans are to install these changes within a few months;
therefore we should be informed of any strong negative reactions
relatively quickly.
The proposed changes fall into two general classes as de-
scribed below:
A) General Error Message
---------------------
Under certain circumstances, particularly when the Host
has been unresponsive to queued input for a "long time"
the IMP drops its ready line for a short period, causing
the "error flip-flops" to be set (see RFC #270, NIC 7818).
Under these conditions the IMP sends a few NOP's to the
Host and then resumes normal operation. We propose to
send the Host a new message (message type 13) in addition
to the NOPs; this message will tell the Host that the
IMP's Ready Line was dropped, that the IMP's error flop
was set, and that the IMP will respond to the next com-
pletion of a Host-to-IMP message with a type 1 or type 8
message (because of the setting of the IMP's error flop.
B) Error Messages which are Responses to Specific
----------------------------------------------
Host-to-IMP Transmissions:
--------------------------
1) IMP-to-Host message type 1 will be 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 will be 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 will be defined to mean:
"A Host-to-IMP message was too short (and cannot be
identified)."
4) IMP-to-Host message type 11 will be defined 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 will be defined 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 ]
AI ELI5
On this page
§1The Proposed Change
Alex McKenzie of BBN announces that BBN is considering a redefinition of the IMP-to-Host error message types (type 1 and type 8) and the creation of additional error types. The goal is to help Hosts decide on an appropriate recovery action without causing serious reprogramming problems.
BBN plans to install the changes within a few months, so it asks to hear about any strong negative reactions relatively quickly.
The people who run the network boxes say they want to change the error notes. They ask everyone to speak up soon if they dislike the idea.
§2A General Error Message
When a Host has been unresponsive to queued input for a long time, the IMP drops its Ready Line for a short period. That sets the IMP's error flip-flops (see RFC 270). The IMP then sends the Host a few NOPs and resumes normal operation.
BBN proposes to also send a new message, type 13. It tells the Host that the Ready Line was dropped, that the error flop was set, and that the IMP will answer the next completed Host-to-IMP message with a type 1 or type 8 message.
If the computer ignores the box for too long, the box rings a bell. The new note says, 'I rang the bell, so expect an error message next.'
§3Errors for Specific Messages
Five error types answer specific Host-to-IMP transmissions. Where the message can be identified, the error carries its source and link number bits.
- Type 1 is redefined: the error flip-flop was set on a message the IMP cannot identify.
- Type 8 is redefined: the flip-flop was set during receipt of the message identified by the source and link number bits.
- Type 10 is new: a Host-to-IMP message was too short and cannot be identified.
- Type 11 is new: a message was too long; it is identified by source and link number.
- Type 12 is new: a message had an illegal message type code; it is identified by source and link number, but the erroneous type code is not included.
Instead of one vague 'something broke' note, the box would have separate notes for 'too short', 'too long' and 'I do not know that kind of message'.
- 1Error, unidentified message — Error flip-flop set on a message the IMP cannot identify (redefined).
- 8Error, identified message — Error flip-flop set during receipt of the identified message (redefined).
- 10Too short — Host-to-IMP message too short and cannot be identified (new).
- 11Too long — Host-to-IMP message too long; identified by source and link number (new).
- 12Illegal type — Illegal message type code; identified by source and link number (new).
- 13General error — Ready Line was dropped and error flop set (new).