More on standard host names
A 1971 proposal from the NIC for formal host names plus optional nicknames, to settle the naming argument.
Watson, R.W., "More on standard host names", RFC 273, DOI 10.17487/RFC0273, October 1971, <https://www.rfc-editor.org/info/rfc273>.
@misc{rfc273,
series = {Request for Comments},
number = 273,
howpublished = {RFC 273},
publisher = {RFC Editor},
doi = {10.17487/RFC0273},
url = {https://www.rfc-editor.org/info/rfc273},
author = {R.W. Watson},
title = {{More on standard host names}},
pagetotal = 3,
year = 1971,
month = oct,
} RFC text
Network Working Group Richard W. Watson
Request for Comments #273 SRI-ARC
NIC 7837 18 October 1971
Categories:
Related: 7625, 7626, 7661, 7688, 7650, 7646
Obsoletes: 7662
MORE ON STANDARD HOST NAMES
The Network Information Center is a logical place to handle this
problem of Standard Host Names and so the ball now rests here.
This is clearly a delicate subject with people having strong
feelings and attachments to names. No past proposal, including
RFC 247, NIC 7668, has yet achieved any acceptance. This
identification seems a natural thing and should be taken into
account in setting up a naming scheme. Therefore, the following
proposal is offered which I hope may be satisfactory to everyone.
Any naming scheme must:
(1) Recognize the expanding character of the Network, with
the potential eventually of several hundred sites.
(2) Recognize the need for abbreviations to simplify typing.
(3) Recognize the use of names on hardcopy and online
documentation
(4) Recognize people's strong identification with historical
names associated with their project.
To meet these needs, we propose adoption of a hybrid scheme
related to those in the other past proposals.
Each host will have a formal name of the form:
<Institution Mnemonic> "-" <Host or NIC Station Mnemonic>
and an optional nickname of the form:
<Nickname>
RWW 20 OCT 71 7837 More on Standard Names
We have heard no arguments to support severe restrictions on name
length and, therefore, human considerations should probably
prevail, but would suggest the following guidelines.
<Institution Mnemonic> will be at most 4 characters, formed as
per RFC 247, NIC (7688,).
Examples of Institutions being: AMES, CASE, BBN, UCLA,
SRI, MIT, HARV, MITR, etc.
We must recognize that in the future there may be multiple
IMPS and TIPS and combinations at a given institution, so
that there is not a one-to-one correspondence between
<Institution Mnemonic> and IMPS or TIPS. Also affiliated
with the Network, there will be groups and individuals
without an IMP or a TIP, or with just a terminal to a TIP,
whose organizations need unique names.
<Host or Nic Station Mnemonic> will not have any restriction
on length, but should if possible be short. In picking <Host
or NIC Station Mnemonic>, an order of priority for choosing
this mnemonic might be
(1) Suborganization within the <Institution Mnemonic>.
(2) Project mnemonic.
(3) Machine designation.
(4) The suggestion in RFC 247, NIC 7688 to include the
designation TIP or TEST should probably be followed as
conveying useful information.
Examples might be:
ARC, NMC, NCCTIP, TENEXA, TENEXB, MULTICS, ILLIAC, SAIL,
DMCG, IMP, TX2, etc.
The <nickname> should be unique within the network community,
short, and preferably should be the same as <Host or NIC
Station Mnemonic> to make life easy for people having to learn
them.
I would strongly recommend that Telnets recognize both the Formal
Name and the Nickname.
RWW 20 OCT 71 7837 More on Standard Names
Now the sticky question: who chooses the names? The only
satisfactory answer is to allow the hosts, through their liaison,
to choose their own names, possibly subject to some discussion if
duplicate or extra long names are picked. Hosts or stations at a
given institution should use the same <Institution Mnemonic>.
Let's settle this issue as soon as possible, say by November 5;
each liaison please send me your names by then.
If there are any implementation hardship cases, other than TIPs,
caused by the above scheme, please let me know as soon as
possible.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
AI ELI5
On this page
§1What Any Scheme Must Do
The author says the NIC is a logical place to handle the problem and that the subject is delicate. Any naming scheme must recognize the expanding network, which might eventually have several hundred sites, the need for abbreviations that are easy to type, the use of names in hardcopy and online documentation, and people's strong identification with historical project names.
A good naming plan has to work when the network gets much bigger, be short to type, and respect the names people already love.
§2Formal Names and Nicknames
Each host has a formal name made of an institution mnemonic, a dash and a host or NIC station mnemonic, and an optional nickname. The institution mnemonic is at most 4 characters, formed as in RFC 247, such as AMES, CASE or UCLA.
The second part has no length limit but should be short. The suggested priority is a suborganization, then a project mnemonic, then a machine designation, and the TIP or TEST designation from RFC 247 should probably be kept. The nickname should be unique across the network and preferably equal to the host mnemonic. The author strongly recommends that Telnets recognize both the formal name and the nickname.
A formal name says where a computer is and which one it is. A nickname is a short pet name that should match.
§3Who Chooses and What Happens Next
The only satisfactory answer to who picks the names is that hosts choose their own through their liaison, possibly after discussion if duplicate or very long names appear. Hosts at one institution should share the same institution mnemonic.
The author hoped to settle the issue by November 5 and asked each liaison to send names by then. Any implementation hardship cases, other than TIPs, should be reported.
Each computer's own helper chooses its name. Everyone at one place uses the same place code, and the answers were due by a set date.