diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc209.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc209.txt')
-rw-r--r-- | doc/rfc/rfc209.txt | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc209.txt b/doc/rfc/rfc209.txt new file mode 100644 index 0000000..cdde253 --- /dev/null +++ b/doc/rfc/rfc209.txt @@ -0,0 +1,59 @@ + + + + + + +Network Working Group B. Cosell +Request for Comments: 209 Bolt Beranek and Newman +NIC: 7187 13 August 1971 + + + HOST/IMP Interface Documentation + + On 25 June 1971 we put a new version of the IMP system, Version 2500, + up in the network. Among other changes, the new system corrected the + problem of Hosts receiving spurious "Destination Dead" [Type 7] + messages. The correction involved making the IMP refuse to accept + any messages from its Host for about 30 seconds after the Host + indicated its intention to come alive. This delay has caused trouble + to a number of NCPs because they had imposed an upper limit on the + time an IMP may take to accept a message, and when that time was + exceeded the IMP was declared inoperative and the NCP shut itself + down, leaving the site personnel annoyed and perplexed. + + We're sorry to have caused so much trouble, but we thought that the + new version modified no advertised property of the system. To + prevent misunderstandings of this type in the future, the IMP/Host + interface should be well documented, well understood and invariant. + The only way to set up and maintain such an interface is to presume + that BBN Report No. 1822 is complete and correct. We understand that + it is neither, but operating on the basis of this assumption is the + best way to force 1822 to improve. In our view, the Hosts should + proceed under the constraint that anything not specifically + guaranteed by 1822 does not exist and should not be used. If there + are problems using this approach, please don't "code around" the + problem or treat your IMP as a "black box" and extrapolate its + characteristics from a series of experiments. Instead, send your + comments and problems to the NCC at BBN, and we will fix the IMP + system, or 1822, whichever is necessary. + + We are, at the moment, working n an update to 1822. It will reflect + the deletion of the "cease" mechanism [as per RFC #107]. + + We are also considering augmenting the IMP/Host protocol with a + mechanism to allow a Host to detect a change in the "version" of the + IMP system, and to provide the Hosts with status information as to + who is alive in the net. + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Ryan Kato 6/01] + + + + + + +Cosell [Page 1] + |