RFC 57 (rfc57) - Page 2 of 5

Thoughts and Reflections on NWG/RFC 54

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970


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 RFC)
       2.  ILLEGAL OP CODE
       3.  ILLEGAL LEADER (bad message type, etc.)
       4.  ILLEGAL COMMAND SEQUENCE
       5.  ILLEGAL SOCKET SPECIFICATION - COMMAND
       6.  ILLEGAL COMMAND LENGTH (last command in message was too short)
       7.  CONNECTION NOT OPEN - DATA
       8.  DATA OVERFLOW (message longer than advertised available
           buffer space)
       9.  ILLEGAL SOCKET SPECIFICATION - DATA (socket does not exist)