IMP-Host Errors: Proposed Change in IMP-to-Host Protocol
A proposal for clearer IMP-to-Host error messages and a Ready Line notice.
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 ]
ISO Plain Language
On this page
§1The Proposed Error Changes
BBN is considering redefining IMP-to-Host error message types 1 and 8 and creating additional types. The stated goal is to help Hosts choose recovery actions without causing serious reprogramming problems.
BBN planned installation within a few months and asked to hear strong negative reactions relatively quickly.
The proposal changes how an IMP reports transmission problems to a Host. BBN asks implementers to raise serious objections soon.
§2A Ready Line Notification
When a Host has not accepted queued input for a long time, an IMP may drop its Ready Line briefly, setting an error flip-flop, then send NOPs and resume normal operation. The proposal adds message type 13 to report that the Ready Line was dropped and the error flip-flop was set.
Type 13 also tells the Host that the IMP will respond to the next completed Host-to-IMP message with type 1 or type 8.
A new message would tell a Host that the IMP briefly dropped its Ready Line. It would also warn that an error response will follow the Host's next completed message.
§3Specific Error Types
Type 1 would mean the error flip-flop was set on a message the IMP cannot identify. Type 8 would mean it was set while receiving a message identified by the source and link number bits.
New type 10 reports a message too short to identify. Type 11 reports a message too long and includes source and link number. Type 12 reports an illegal message type code, identifies the message with source and link number, and does not include the erroneous type code itself.
The proposal separates unidentified, too-short, too-long and illegal-type errors. Where possible, the error message identifies the source and link number of the original message.
- 1Unidentified message error — Error flip-flop set on a message the IMP cannot identify (redefined).
- 8Identified message error — Error flip-flop set while receiving an identified message (redefined).
- 10Too short — Host-to-IMP message too short to identify (new).
- 11Too long — Host-to-IMP message too long (new).
- 12Illegal type — Illegal message type code received (new).
- 13Ready Line dropped — Reports that the Ready Line was dropped and the error flip-flop set (new).