by Jim E. White, May 11, 1973
NOTE: This was transcribed from a scan at the Computer History Museum by Darius Kazemi (me) on September 18, 2019. The scan should be considered the “real” version of this document, but I decided I wanted a nice text version to refer to online. This is part of my research on early RFC documents and is related to RFC-226. If you like this kind of stuff, consider backing my Patreon!
The following are thoughts on the subject of host designation, prompted by Jean's (16331,1) and Jake's (16300,1).
Numeric Host Designations
A word about the terms 'site' and 'host'. I distinguish sharply between these two terms, and part of the confusion about designating hosts in the Network stems from their misuse.
A host is either a computer attached to an IMP, or the terminal-handling portion of a TIP.
A site, for my money, designates an installation at which an IMP is located.
The crucial point is that hosts bear a many-to-one relation to sites, since up to four host computers can be connected to a single IMP.
I recognize that it's a hopeless task at this point to try to get everyone speaking the same language, but I suggest that maintaining that distinction in your own mind will buy you much in the long run.
The following three numbers used in designating ARPANET hosts appear throughout the literature:
IMP Number. Every IMP (and TIP) has an 'IMP number', assigned by BBN, and used by the IMPs themselves in intercommunication. IMP numbers fall in the range, decimal 0-63, and are unique within the Network.
Host Number. Each host at each IMP has a number by which it's distinguished from the zero to three other hosts attached to the same IMP. Host numbers fall in the range, decimal 0-3, and are unique within the sphere of an IMP.
Host Address or Network Address. IMP number and Host number are combined to form a Host or Network address:
Host address = IMP number + decimal 64 * Host number
That is, a host address can be constructed in an eight-bit field by storing the host number in the left-most two bits, and the INP number in the right-most six bits. Given the Host address, one can readily infer both Host and IMP numbers; and given both Host and IMP numbers, one can readily infer the host address.
Host addresses are what host systems (NCPs) use internally to designate other hosts in the Network, and are what are stored with standard host names and nicknames in the (TENEX) monitor's system tables.
A HOST ADDRESS, EXPRESSED IN DECIMAL, IS WHAT TIPS REQUIRE OF THE USER IN CONNECTING TO ANOTHER HOST.
The very existence of these three types of host designations (which appear primarily In BBN Report # 1822), and the fact that the names of these three designations are often misused, makes life much more complicated than it need be.
I recommend that the ONLY host designations that appear ANYWHERE but in the most esoteric, low-level Network specs (such as 1822) be HOST ADDRESS and STANDARD HOST NAME. This goes then, of course, for the Resource Notebook.
Alphameric [sic] Host Names
Standard host names, as originally defined back in '71 by Dick Watson (see — 7837,1), stand in one-to-one correspondence (forgetting nicknames) with Host addresses.
I believe that hosts DO care what their host names are. In fact, if one peruses the early dialog on this subject, one finds it was an EXTREMELY controversial issue.
I think that host names in general DO follow a fairly coherent scheme. Dick Watson's early spec (see — 7837,1) declared that a standard host name be of the form:
<site> - <host>
Note here that the site-host distinction is crucial.
<Host> was to describe either a suborganization (like 'ARC' in 'SRI-ARC'), or a project, or a machine (like '67' in 'LL-67', or 'TIP' in 'MITRE-TIP').
About the suggestion that host names be:
<site> - ['T / 'U] <host address>
The purpose of host names is specifically NOT to provide a place where 'everything needed to address a site' can be stored. Host names should be a convenient, user-oriented way of distiguishing [sic] host computers. The fact that, at the lowest level, Network software employs numbers to designate hosts, is purely an artifact of the existing implementation of the Network, and is something that the human user should NEVER see or even know about.
It's relatively simple to remember a mnemonic (like #BBN-TENEX), but considerably harder to remember an arbitrary number (decimal 69). If one embeds host addresses within host names, then the user must remember BOTH. That's clearly the wrong way to go.
The fact that the human user in fact DOES, in some circumstances, have to know about host addresses, is largely (if not wholly) because TIP users have to use them (rather than host names) in connecting to other hosts. This is an artifact of the TIP's current core limitations, and should not become the forcing function in ANY discussion of host naming conventions.
My personal opinion about naming conventions is that there should be none (except for some common sense ones like imposing a reasonable upper bound on their length, and restricting them to printable, ASCII characters). It seems to me that it is perfectly appropriate for the NIC to have 'NIC' as it's [sic] official host name, if it so chooses, even though that name provides no information about the host's location or computer type. The Network is a network of resources, and, in general, the user should only have to call to mind the RESOURCE he desires, not its geographical location. I think that geographical location and machine type should more and more be suppressed whenever possible, not emphasized.
About Changing Host Names
It seems to me necessary that a host have the option of changing its host name. If machine names are embedded in host names, then a host MUST have this option if its machine changes. The name 'MITRE-TIP' is ludicrous if MITRE replaces its TIP wth a PDP-11.
I think I understand some of the unpleasant implications of a hostjname [sic] change — like obsoleted group names in Journal files, and a transition period during which many people don't know how to properly address that host — but it seems necessary nonetheless.
The system CAN, I think, help out here some. For example, the Ident system can retain a record of previous names and recognize them when given by the user.
Keeping Track
As I'm sure Jean North can attest, it's an almost impossible job to get hold of an accurate and complete list of host names and addresses. Even if that much WERE possible, 'FNWC', for example, doesn't meaningfully identify that host to the average user (or most anyone else).
There needs to be maintained at the NIC in its Ident file an accurate and complete list of Network hosts, containing for each:
- It's [sic] standard host name
- It's [sic] host address
- A meaningful organization name
- A physical location
- A telephone number
This list should always be exactly that set of hosts which are actually and physically attached to the Network.
This requires cooperation from BBN and/or whoever else sees installations into and out of the Net. It requires that they contact the NIC when the status of the Net changes.
BBN should be requested to use standard host names in Report #1822, rather than the ad hoc and often cryptic character strings they currently employ.
