home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0040.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  3.7 KB  |  166 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         E. Harslem
  8. Request for Comments: 40                                      J. Heafner
  9.                                                                     RAND
  10.                                                               March 1970
  11.  
  12.                More Comments on the Forthcoming Protocol
  13.  
  14. We have recently discussed NWG/RFC Nos. 36 and 39 with Steve Crocker,
  15. UCLA.  Steve has asked that we elaborate on the errors, queries, and
  16. HOST status that were mentioned in NWG/RFC #39.
  17.  
  18. Please voice your opinions soon in order to affect the forthcoming
  19. protocol specifications.
  20.  
  21. ERROR MESSAGES
  22.  
  23.      <ERR> <Code> <Command length> <Command in error>
  24.  
  25. <Code> is an eight-bit field that specifies the error type.  The
  26. assigned codes are shown below.  <Command length> is a 16-bit integer
  27. that indicates the length of the <Command in error> in bits.  The
  28. <Command in error> is the spurious command.
  29.  
  30. The ranges of <Code> are shown below in hexidecimal.
  31.  
  32.      00     Unspecified error types
  33.      10-0F  Resource errors
  34.      10-1F  Status errors
  35.      20-2F  Content errors
  36.      30-3F  Unused
  37.  
  38. Specific values of <Code> are shown below with their meaning.
  39.  
  40.      <Code> value   Semantics
  41.  
  42.          00         Unspecified errors.
  43.          01         Request for an invalid resource.
  44.          02         Request for an exhausted resource, try later.
  45.         03-0F       Unused.
  46.          10         Invalid <RSM>, i.e., link connected but unblocked.
  47.          11         Invalid <SPD>.
  48.          12         Invalid <ASG>, i.e., connected but no <RDY>
  49.                       received.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.      <Code> value   Semantics
  61.  
  62.          13         Message received on blocked link.
  63.         14-1F       Unused.
  64.          20         Unknown command code.
  65.          21         Message received on unconnected link.
  66.          22         Invalid <RFC>.
  67.          23         Invalid <CLS>.
  68.          24         Invalid <RSM>, i.e., link not connected.
  69.          25         Invalid <FND>.
  70.          26         Invalid <END>.
  71.          27         Invalid <RDY>.
  72.          28         Invalid <ASG>, i.e., not connected.
  73.         29-2F       Unused.
  74.         30-FF       Unused.
  75.  
  76. QUERIES
  77.  
  78.      <QRY> <My Socket>
  79. or   <RPY> <Your Socket> <Text>
  80.  
  81. The <QRY> is the query indicated in NWG/RFC #39 and <RPY> is the reply.
  82. The format of <Text> is shown below; also refer to NWG/RFC #36, p. 3.
  83.  
  84. <Text>::= <16 bit count of relevant connection table entries>
  85.           <relevant connection table entries>
  86.  
  87. <relevant connection table entries>::=
  88.                                      <relevant connection table entries>
  89.                                      <a relevant connection table entry>
  90.                                      <a relevant connection table entry>
  91.  
  92. <a relevant connection table entry>::= <local socket> <foreign socket>
  93.                                        <link> <connection state>
  94.                                        <flow state and buffer control>
  95.                                        <reconnection control state>
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. HOST STATUS
  114.  
  115.      <NOP>
  116.  
  117. An NCP may be up, down, pending, etc.  When an NCP changes its
  118. state to UP it should send a <NOP> to each remote NCP which
  119. indicates the NCP is available.  The sending NCP can then
  120. construct a vector of HOST status from the RFNMs it receives.  An
  121. NCP receiving a <NOP> can update the availability of the sending
  122. NCP in its HOST status vector.
  123.  
  124.  
  125.  
  126.        [ This RFC was put into machine readable form for entry ]
  127.          [ into the online RFC archives by Richard Ames 6/97 ]
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166.