summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc209.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc209.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc209.txt')
-rw-r--r--doc/rfc/rfc209.txt59
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]
+