Thoughts and Reflections on NWG/RFC 54 (RFC0057)
Original Publication Date: 1970-Jun-19
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
M. Kraley: AUTHOR [+1]
In the course of writing NWG/RFC #54 several new ideas became apparent. Since these ideas had not previously been discussed by the NWG, or were sufficiently imprecise, it was decided not to include them in the official protocol proffering. We thought, however, that they might be proper subjects for discussion and later inclusion in the second level protocol.
Network Working Group Mike Kraley (Harvard)
Request for Comments #57 John Newkirk (Harvard)
June 19, 1970
Thoughts and Reflections on NWG/RFC #54
In the course of writing NWG/RFC #54 several new ideas became
apparent. Since these ideas had not previously been discussed by the
NWG, or were sufficiently imprecise, it was decided not to include them
in the official protocol proffering. We thought, however, that they
might be proper subjects for discussion and later inclusion in the
second level protocol.
I. Errors and Overflow
In line with the discussion in NWG/RFC #48, we felt that two
types of errors should be distinguished. One is a real error, such as
an RFC composed of two send sockets. This type of error can only be
generated by a broken NCP. In the absence of hardware and software
bugs, these events should never occur; the correct response upon
detection of such an event was outlined in the description of the ERR
command in NWG/RFC #54.
The other "error" is an overflow condition arising because
finite system resources are exhausted. An overflow condition could
occur if an RFC was received, but there was no room to create the
requisite tables and queues. This is not a real error, in the sense
that no one has done anything incorrect (expect perhaps the system
planners in not providing sufficient table space, etc.) Further, a
recovery procedure can be well defined, and simply entails repeating the
request at a future time. Thus, we believe an overflow condition should
be distinguished from a real error.
In NWG/RFC #54 an overflow condition was reported by returning
a CLS, as if the connection had been refused. This sequence performs
the necessary functions, and leaves the connection in the correct state,
but the initiating user is misinformed. He is deluded into thinking
that he was refused by the foreign process, when, in fact, this was not
the case. In certain algorithms this difference is crucial.
In further defining error conditions, we felt that it would
be helpful to specify why the error was detected, in addition to
specifying what caused the error. While writing the pseudo-Algol
program mentioned in NWG/RFC #55 we differentiated 9 types of errors
(listed below). We would, therefore, like to propose the extension of
the ERR message to include an 8-bit field following the op code to
designate the type of error. This would be followed by the length and
text fields, as before. We propose these error types;
0. UNSPECIFIED ERROR
1. HOMOSEX (invalid send/rcv pair in an RF...