home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- 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>
-
-
-
-
-
-
-
-
-
-
- [Page 1]
-
- 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.
-
-
-
-
-
-
- [Page 2]
-
- 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 ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 3]
-
-