RFC 606

Host Names On-line ✨

Title block 🎀: This is RFC 606, from the Network Working Group, written by L. Peter Deutsch at PARC-MAXC, dated December 1973. The doc doesn't say what category or status it has, and it doesn't obsolete or update anything. 💅

Okay bestie, so we finally have an official list of host names 🎉 That means it's time to stop the chaos where every site keeps its own host list for its OS and user programs, and every single one is kinda outdated 😩

Take the TENEX sites I use: SRI-ARC, BBN-TENEX, USC-ISI, and PARC-MAXC. Each has a slightly different mapping between host names and host addresses. None of them is complete, and I'm pretty sure each one is off from the official List in some way 💀

The Plan 🦋

The NIC is already in charge of the official list, so it makes total sense for them to keep an on-line file that anyone can access. It would list names and host addresses, plus some other info I'm about to suggest, in a format machines can easily read 🤖

I don't think an NLS structured file works here. You can't reach those files over the network, and lots of sites wouldn't want to bend to that structure even if they could. Not it 🙅‍♀️

This file is mainly for programs, not people. Programs want compact, easy-to-parse info, while people like wordy explanations and fancy browsing or querying tools. So here's what I'd put in the file:

• The official name and host address for each host. This is the main content of each entry. 🌸
• Info about the protocol options each host supports. For FTP that's the preferred byte size, and for TELNET it's the preferred duplex mode. The byte size can seriously change how fast file transfers go 🔥 Since the new TELNET lets hosts negotiate options, this list doesn't have to be complete or accurate.
• What the host does on the network (user, server, TIP, etc.). This helps NCPs decide whether to poll the host, and it's useful for stats. For example, I'd love for my NCP to track traffic with TIPs vs. other hosts 📊

The file gets generated in one central spot but gets used by tons of different programs. So it should be built for easy lookups, even if that makes it harder to create. I think the way to do that is an ASCII text file with the structure of a "property list" 🧚

In other words, apart from the two basic facts in each entry (name and address), everything else is written as <attribute, value> pairs. The attribute isn't identified by its format or position 💖

The Proposed Syntax 💅

I don't think the exact format of this file matters that much. I'm making a suggestion and hoping nobody cares enough to fight it 🙈 (Yes, I know this has never worked in the history of the network, but it's still worth a shot 😭) Here's the proposed syntax:

<host-name-file> ::= <entry> | <host-name-file> <entry>

<entry> ::= <data-part> <end-of-line>

Note that this produces a blank line after the <data-part>.
<data-part> ::= <basic-part> | <data-part> <attribute-item>
<basic-part> ::= <host-name> , <host-address> <end-of-line>
<attribute-item> ::= <attribute-name> = <attribute-value>
<end-of-line>

Some terms are still undefined, so let's fill those in 🧩

<end-of-line>: I'm not sure which end-of-line indicator people are into these days. Personally I like carriage-return followed by line-feed 🍓 TENEX usually uses the single character octal 37, which is totally non-standard and not right for this 🙅‍♀️

<host-name>: This is an official host name, as defined in the recent RFC 597 (NIC 20826) by NJN and JAKE. As I understand it, these names can only have letters, digits, hyphens, and parentheses (including the network name) ✨

<host-address>: This is a decimal host address relative to its own network, which is what I'd assume. Nobody has really talked about multi-network addressing yet. There's apparently an unpublicized Internetworking Protocol experiment going on, though, so another convention might be better 👀

<attribute-name>: This is an arbitrary name made of only letters, digits, and hyphens. We'll have to agree on some names like BEST-FTP-BYTE-SIZE (?), but I'm happy to let the NIC pick them 🎀

<attribute-value>: This is an arbitrary string that doesn't contain <end-of-line>. How it's interpreted depends on the attribute. For example, there could be a SERVERS attribute whose value is a list of the servers a site usually runs 🖥️

Some Attributes I Love 🌈

These are the specific attributes I think would be worth it:

• NICKNAMES: The value is a list of acceptable nicknames for the host. Any system that does name-to-address translation is encouraged (though of course not required) to accept these as alternatives to the official host name 💜
• FTP-BYTE-SIZES: The value is a list of the byte sizes the FTP server supports. The first byte size is the one with the least computational overhead (e.g. 36 for PDP-1O's, 32 for 36O's) 🔥
• ECHOING: The value is L or R, depending on whether the host expects the terminal to echo (Remote) or expects to do its own echoing (Local) 🦋

Also, no attribute is actually required, and the values under a given attribute don't need to be complete. This list isn't meant to replace option negotiation, word-of-mouth, or any other way one host finds out about another host's properties. It's just an extra source of info that programs can access in a simple, uniform way 🫶

⚠️ Heads up: there's a famous trap with suggestions like this one. It's a specific solution to a specific problem, so it might not fit with or be a good base for more general solutions to bigger problems. But (1) this particular problem has been bugging me and everyone I've talked to for over a year, and it's honestly absurd that it's gone unsolved this long; and (2) nobody seems interested in solving any bigger problem right now 😤

The Datacomputer Ask 💀

Except for the Datacomputer: PLEASE, if there's an easy way to do the same thing through the Datacomputer, somebody write an RFC about it 🙏✨