RFC 695 UNKNOWN PROTOCOL

Official change in Host-Host Protocol

A protocol correction that assigns separate ERR codes to distinct error cases.

On rfc-editor.org ↗
PUBLISHED
July 1975
AUTHORS
M. Krilanovich
STREAM
Legacy
CODE 5
Request on a non-open socket
CODE 6
Message on an unknown link
CODE 7
Invalid host header
DOI
10.17487/RFC0695

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
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

ISO Plain Language

On this page
PROBLEMHost-Host Protocol error code 5 covered two cases whose ERR data fields had different formats, so a receiver could not reliably tell them apart.
MECHANISMThe correction defines code 5 for a request on a non-open socket, code 6 for a message on an unknown link, and code 7 for an invalid host header.
THE CORRECTIONAn NCP can use the error code to distinguish the three cases and interpret the accompanying data field.

§1Why Error Code 5 Was Ambiguous

The earlier protocol used ERR code 5 for both a control command referring to a socket that was not fully open or closed and a non-control message arriving on a link not used for a connection.

The data field held a command in the first case and a message header in the second. A receiving NCP or a person reading an error log could not reliably distinguish them.

One error number described two different problems. Their data had different formats, but the number alone did not show which problem occurred.

§2The New Error-Code Meanings

The replacement text assigns error code 5 to a request other than STR or RTS on a socket that is not part of a fully established connection. Code 6 means a message arrived over a user link not currently used by a connection.

Code 7 means a message on the control link or a valid user link had an invalid host header. The RFC gives examples such as invalid M1 or M2 fields, invalid byte size, or a declared length greater than the actual length.

Each of the three error codes now identifies one case. The receiver can interpret the accompanying command or message header using the code.

§3Effect of the Change

The memo replaces paragraph f under “ERR - Error detected” in the Host-Host Protocol. The data field for each new code is defined for its corresponding case, including any zero fill described in the replacement text.

This is an official change to be filed with the protocol specification and the Current Network Protocols Notebook.

The memo replaces the ambiguous paragraph in the protocol documentation. It makes the ERR command's data easier to interpret.