RFC 625

On-line hostnames service

πŸ“… published March 1974, from ietf

ON LINE HOSTNAMES SERVICE πŸŽ€

Okay bestie, here's the header tea β˜•. This is RFC 625 (NIC # 22152), from the Network Working Group. The authors are Mike Kudlick (SRI-ARC) and Jake Feinler (SRI-ARC), and it's dated March 7, 1974 πŸ“…. The original header doesn't list a category, and it doesn't obsolete or update anything. Iconic clean slate ✨.


Okay so, NIC totally agrees with [RFC 623] that more than one Host should be keeping a copy of the Hostnames data base 🫢. The NIC is more than happy to keep running the master data base and share it with any secondary Host that volunteers to keep a copy. We'd be so pleased to have UCSB as one of those secondary Hosts 🌸.

BUT, we do NOT agree with RFC 623 about building a server process so user processes can get at the official Hostnames file at the NIC πŸ™ˆ. The file is sequential, and honestly? FTP is totally the right tool for this πŸ’…. Setting up common login parameters across the servers isn't a big deal either. Even with a user/server process you'd still need extra protocol agreements, so deciding on common login parameters for FTP isn't much extra work at all ✨.

We're lowkey puzzled by the vibe against FTP 😭. The whole goal was a network file transfer mechanism that everyone can use for all kinds of stuff without writing new programs. So if FTP is that bad, shouldn't the criticism and the effort go into improving or replacing it, instead of making end runs around it? πŸ€” Yes, FTP is more complex than any single application (this one included) needs, but isn't that just the price of a general-purpose facility? πŸ’œ

Last thing: we'd rather keep the file in ASCII πŸ¦‹. It's easier to check data, and debug data transfer problems, in that form than in binary. Periodt πŸ’–.


[ 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 ]
πŸ“¦ where this page comes from