summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc533.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/rfc533.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc533.txt')
-rw-r--r--doc/rfc/rfc533.txt59
1 files changed, 59 insertions, 0 deletions
diff --git a/doc/rfc/rfc533.txt b/doc/rfc/rfc533.txt
new file mode 100644
index 0000000..026c721
--- /dev/null
+++ b/doc/rfc/rfc533.txt
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+Network Working Group David Walden
+RFC # 533 BBN-NET
+NIC # 17452 July 17, 1973
+
+
+ MESSAGE-ID NUMBERS
+
+
+ It has been noted that the IMP message format (specified in BBN
+Report 1822) constrains network users to low throughputs if messages are
+to be uniquely identified via the link number. We have recently
+implemented a change in the IMP/Host protocol which alleviates this
+difficulty. The link field in the IMP/Host and Host/IMP leaders has
+been extended to the right by four bits (in other words, it now uses
+bits 17 to 28 of the leader), and the name of the link field has been
+changed to the _message-id field_. We expect this field to be used to
+uniquely identify messages between the IMPs and the Hosts. All 12 bits
+in the message-id will be returned to the Host in RFNMs, INCOMPLETE
+TRANSMISSIONs, etc. Note that no ordering is implied by the use of the
+message-id field.
+
+ Given that the Host/Host protocol uses the old link field to
+identify connections, the additional four bits in the new message-id
+field might well be used to uniquely identify messages on a given
+connection (i.e., over a given link). Of course, there is no obligation
+for Hosts to uniquely identify their messages (the IMP subnetwork
+certainly doesn't care), so this change in the IMP/Host message format
+is completely backward compatible. In fact, since the receiving Host
+does not have to look at these extra four bits on arriving messages, the
+change is completely backward compatible even when senders of messages
+do use the extra four bits to uniquely identify messages.
+
+ Please store this RFC with your copy of BBN Report 1822 until 1822
+is updated.
+
+
+
+
+
+
+
+
+
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Alex McKenzie with ]
+ [ support from GTE, formerly BBN Corp. 10/99 ]
+
+
+
+
+Walden [Page 1]
+