RFC 533

RFC 533: MESSAGE-ID NUMBERS 🎀

okay bestie, the title block is giving old-school vibes 🌸

• It's written by David Walden of BBN-NET, for the Network Working Group 💅
• It's RFC # 533 (NIC # 17452), dated July 17, 1973 🦋
• It doesn't list a category, and it doesn't say what it obsoletes or updates 🙈

okay so it's been noticed that the IMP message format (the one specified in BBN Report 1822) keeps network users stuck at low throughputs if you want every message uniquely identified through the link number 😭. We recently shipped a change to the IMP/Host protocol that fixes this 🔥. The link field in the IMP/Host and Host/IMP leaders got extended to the right by four bits (so it now uses bits 17 to 28 of the leader), and it got renamed 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 come back to the Host in RFNMs, INCOMPLETE TRANSMISSIONs, etc. 🫶 And no ordering is implied by the message-id field, so don't go looking for one 💀.

Since the Host/Host protocol still uses the old link field to identify connections, those extra four bits could totally be used to uniquely identify messages on a given connection (i.e., over a given link) 🧚. Hosts aren't obligated to uniquely identify their messages (the IMP subnetwork really doesn't care lol), so this change to the IMP/Host message format is completely backward compatible 💖. Even better, the receiving Host doesn't have to look at those extra four bits on arriving messages, so it stays backward compatible even when senders DO use them 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 ]