Official change in Host-Host Protocol
Clarification of the ERR command error codes.
Krilanovich, M., "Official change in Host-Host Protocol", RFC 695, DOI 10.17487/RFC0695, July 1975, <https://www.rfc-editor.org/info/rfc695>.
@misc{rfc695,
series = {Request for Comments},
number = 695,
howpublished = {RFC 695},
publisher = {RFC Editor},
doi = {10.17487/RFC0695},
url = {https://www.rfc-editor.org/info/rfc695},
author = {M. Krilanovich},
title = {{Official change in Host-Host Protocol}},
pagetotal = 3,
year = 1975,
month = jul,
} RFC text
NWG/RFC# 695 MCK 5-JUL-75 15:38 32908
Official Change in Host-Host Protocol
Mark Krilanovich 1
Official Change in Host-Host Protocol 2
This is an official change to the Host to Host
protocol, this document should be filed with the
protocol specification (nic -- 8246,) in the Current
Network Protocols Notebook (nic -- 7104,). 3
-- Jon Postel 3a
This document corrects an ambiguity in the current
host-host protocol, concerning the ERR command.
Paragraph "f", page 35, of NIC 8246 defines the
meaning of an ERR command with error code of 5 to be
"socket (link) not connected". The error code is
stated to apply to two cases, one in which a control
command other than STR or RTS refers to a socket that
is neither fully open nor fully closed, and the other
in which a (non-control) message arrives over a link
not being used for a connection. 4
The difficulty arises from the fact that the contents
of the "data" field of the ERR command has distinctly
different formats in the two cases. In the first, it
is a host-host command, and in the second it is a
message header. There is no reliable way for the code
in the NCP receiving the ERR command (or a human
reviewing an error log) to distinguish between the two
cases, and therefore fullest use cannot be made of the
ERR command. 5
The two cases are now defined to have different error
codes. In addition, a new error code is defined,
meaning "invalid host leader received". Therefore,
paragraph "f" under "ERR - Error detected" is now
replaced by the following: 6
f. Request on a non-open socket (Error code = 5) 7
NWG/RFC# 695 MCK 5-JUL-75 15:38 32908
Official Change in Host-Host Protocol
A request other than an STR or RTS was made for a
socket (perhaps referenced by link number) that is
not party to an fully established connection. The
socket's inappropriate state could either be that
only one RFC has been sent (not yet open) or that
only one CLS has been sent (not yet closed). The
"data" field contains the command in error; the
value of any fill necessary is zeros. 7a
g. Message on an unknown link (Error code = 6) 8
A message was received over a user link which is
not currently being used for any connection. The
contents of the "data" field are the message header
followed by the first eight bits of text, if any,
or zeros. 8a
h. Invalid host header (Error code = 7) 9
A message was received either over the control link
or a valid user link that had a host header with
invalid format. Examples of when this subtype would
be appropriate are the following: the M1 or M2
fields were non-zero, the byte size was invalid
(not 8 for a control link, zero for any link), or
the declared length (byte size times byte count)
exceeded the actual length. The contents of the
"data" field is the message header padded with
eight bits of zeros. 9a
------- 10
1
AI ELI5
On this page
§1The Ambiguity
The Host-Host Protocol specified an ERR (Error) command with error code 5 to mean "socket (link) not connected". However, this code applied to two distinct error cases: when a control command other than STR or RTS referred to a socket that was neither fully open nor fully closed, and when a non-control message arrived over a link not being used for a connection.
The two cases have fundamentally different data formats. In the first case, the data field contains a host-host command. In the second case, it contains a message header. There was no reliable way for an NCP receiving the ERR command to distinguish between the two cases by examining the data field, and no way for a human reviewing an error log to interpret the error correctly.
One error code meant two different things depending on the context, and there was no way to tell which was which when you saw the error.
§2The Fix
The protocol change assigns separate error codes to each case and adds one more.
Error code 5: Request on a non-open socket. Issued when a request other than STR (Start) or RTS (Restart) is made for a socket that is not party to a fully established connection (perhaps because only one RFC has been sent, not yet opening, or only one CLS has been sent, not yet closing). The data field contains the erroneous command, with zeros as fill.
Error code 6: Message on an unknown link. Issued when a message arrives over a user link that is not currently being used for any connection. The data field contains the message header and the first eight bits of text, if present, or zeros.
Error code 7: Invalid host header. Issued when a message over the control link or a valid user link has a host header with invalid format, such as non-zero M1 or M2 fields, invalid byte size, or declared length exceeding actual length. The data field is the message header padded with eight zero bits.
Now each error code means exactly one thing. You can read the code number and know what went wrong.
§3Improvement
This change makes the protocol unambiguous and allows full use of the ERR command for debugging and troubleshooting. An NCP implementation can now reliably interpret error codes and a network troubleshooter can read error logs with confidence that the data field is in the expected format.
This makes the protocol clearer and easier for programmers to get right, and easier for people to understand when something goes wrong.