Host mnemonics proposed in RFC 226 (NIC 7625)
Technical critique of proposed ARPANET host naming scheme
Braden, R.T., "Host mnemonics proposed in RFC 226 (NIC 7625)", RFC 239, DOI 10.17487/RFC0239, September 1971, <https://www.rfc-editor.org/info/rfc239>.
@misc{rfc239,
series = {Request for Comments},
number = 239,
howpublished = {RFC 239},
publisher = {RFC Editor},
doi = {10.17487/RFC0239},
url = {https://www.rfc-editor.org/info/rfc239},
author = {R.T. Braden},
title = {{Host mnemonics proposed in RFC 226 (NIC 7625)}},
pagetotal = 1,
year = 1971,
month = sep,
} RFC text
Network Working Group R. Braden
Request for Comments: #239 UCLA-CCN
NIC 7664 23 September 1971
Categories: D.3
Related: #226, 229, 236
HOST MNEMONICS PROPOSED IN RFC #226
(Note from NIC: These are comments sent by R.Braden to P. Karp in NIC
7626, and are now issued as NIC 7664, RFC 239 to include them in the
dialogue along with RFC 226, 229, 236)
CCN is in full agreement that a standard set of host mnemonics
should be selected. However, your proposed set is not fully
satisfactory.
1. The set you suggest was created, I assume, by the systems
programmer(s) who wrote TELNET in TENEX. It is a set of
historical accidents, and shows it.
2. A better source for standard mnemonics might be the NIC site
codes, since these have been chosen with more care and will
become familiar as we begin to use the NIC on-line. Surely
the NIC is a more reasonable source for a defacto standard
than a particular system programmer.
3. Should mnemonics be limited to 6 characters?
4. The most recent list from BBN (NIC #7181, RFC #208,
August 9, 1971) shows 40 hosts. You show only 20. Your
proposed standard should include known hosts at this time.
5. The mnemonic "UCLA36" seems a particularly bad choice; "UCLA91"
would be much better.
6. Also, we at CCN object to the short form "UCLA" for the NMC
Sigma 7; that also is historical. We propose the following:
host 1: UCLAS7 or UCLANM; host 65: UCLA91.
7. "SRIARC" is a poor choice; everybody calls it the NIC. So we
suggest "SRINIC" for host 2.
Please, let's not perpetrate systems programmers' midnight
decisions on all future Network users! Standards are vital, and
deserve a little care.
[ 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 ]
9
AI ELI5
On this page
§1Critique of RFC 226
UCLA-CCN agrees that standardizing host names is a good idea, but objects to the specific list proposed in RFC 226. The response identifies the list as reflecting historical choices made by TENEX Telnet programmers rather than a principled approach to naming.
The reply says: yes to standard names, but no to this particular list.
§2Better Source for Names
UCLA-CCN proposes using NIC site codes as the foundation for host mnemonics instead. The NIC codes were chosen carefully and would become familiar to users as the Network Information Center grew. This would be more principled than relying on one programmer's choices.
The critique also questions why mnemonics should be limited to six characters, and points out that the RFC 226 list covers only 20 hosts when the most recent ARPANET roster lists 40. Using an incomplete list as a standard is problematic.
The NIC codes are better because they were thought out, people already know them, and they cover all the computers.
§3Specific Disagreements
UCLA-CCN proposes concrete changes: UCLA91 instead of UCLA36 for their Sigma 7, and SRINIC instead of SRIARC for host 2 at Stanford Research Institute (because everyone calls it the NIC, not ARC). The reply emphasizes that standards deserve careful thought rather than perpetuating historical accidents.
For example, people call one computer the NIC, so its short name should reflect that rather than preserving an old choice.