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/rfc533.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc533.txt')
-rw-r--r-- | doc/rfc/rfc533.txt | 59 |
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] + |