From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc209.txt | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 doc/rfc/rfc209.txt (limited to 'doc/rfc/rfc209.txt') 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] + -- cgit v1.2.3