GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc312

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."
                                                              [Page 1]
          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   ]
                                                              [Page 2]
/data/webs/external/dokuwiki/data/pages/rfc/rfc312.txt · Last modified: 1997/03/05 20:01 (external edit)