RFC 623

Comments on On-Line Host Name Service 💖

Okay bestie, here's the tea ☕ This doc is from the Network Working Group, written by Mark Krilanovich at UCSB, with NIC # 22004, dated February 22, 1974. It's a comment piece that responds to RFC #606 and RFC #608, and it doesn't list anything it obsoletes or updates.

Okay so Peter Deutsch in RFC #606 pointed out that it would be iconic for one host to keep a database of official host names and host addresses, plus other info of secondary importance 🧚 Mike Kudlick in RFC #608 agreed with the concept and proposed that the NIC would build out Peter's ideas. Mark is adding his voice to the "yes, we need this" squad and sharing a few ideas for tweaking it 🫶

The lowkey problem with having one host hold this database is that anyone who wants a copy might show up and find the serving host isn't available 😭 Yes, each host could save its own copy of the latest data, so there's always at least a pretty recent version around. But ngl that's a lot of bother for everyone, so it's not a very attractive plan 💅 Mark's proposal is that the NIC keeps the master database, and one other host keeps a secondary copy. That copy gets updated to match the NIC's at regular, pretty frequent intervals, like once a day 📅 Now anyone who wants the data can try the NIC first, and if that fails, try the secondary host. This makes it way less likely that the data can't be obtained, and only one extra host has to write additional software 🎀 Mark also volunteers UCSB to be that secondary host, and honestly, it's giving main character energy 👑

Next up: RFC #606 says the database should be formatted in an easily machine-readable form, and Mark is 100% on board 🔥 The proposal so far says the database should be an ASCII file. Mark's idea is to make it retrievable in binary form instead. For example, <host-address> would be a one-byte (eight-bit) binary number. <host-name> would be a one-byte length field followed by that many ASCII characters. The possible <attribute-values> for the STATUS <attribute-name> would be one-byte binary numbers 🤓 Yes, a human wouldn't be able to read it at all, but a program would parse it way more easily. Iykyk 🙈

RFC 608 says the database will be kept as a file and retrieved through FTP. Mark is side-eyeing that, because why would you base something as simple as keeping a host table up to date on something as complex as FTP? 💀 So instead he suggests the database be available through a program running on its own socket, both at the NIC and at the secondary host 🧚‍♀️ This also means the program accessing the data doesn't need to know the login parameters for the guest account on the serving host, which might not even be the same on the two hosts. Again, the whole point is to make life easier for accessing programs 💖

Anyone with thoughts on any of this is encouraged to share them 🦋

[ 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 ]