rfc1178.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          D. Libes
Request for Comments: 1178                Integrated Systems Group/NIST
FYI: 5                                                      August 1990


                   Choosing a Name for Your Computer

Status of this Memo

   This FYI RFC is a republication of a Communications of the ACM
   article on guidelines on what to do and what not to do when naming
   your computer [1].  This memo provides information for the Internet
   community.  It does not specify any standard.

   Distribution of this memo is unlimited.

Abstract

   In order to easily distinguish between multiple computers, we give
   them names.  Experience has taught us that it is as easy to choose
   bad names as it is to choose good ones.  This essay presents
   guidelines for deciding what makes a name good or bad.

   Keywords: domain name system, naming conventions, computer
   administration, computer network management

Introduction

   As soon as you deal with more than one computer, you need to
   distinguish between them.  For example, to tell your system
   administrator that your computer is busted, you might say, "Hey Ken.
   Goon is down!"

   Computers also have to be able to distinguish between themselves.
   Thus, when sending mail to a colleague at another computer, you might
   use the command "mail libes@goon".

   In both cases, "goon" refers to a particular computer.  How the name
   is actually dereferenced by a human or computer need not concern us
   here.  This essay is only concerned with choosing a "good" name.  (It
   is assumed that the reader has a basic understanding of the domain
   name system as described by [2].)

   By picking a "good" name for your computer, you can avoid a number of
   problems that people stumble over again and again.

   Here are some guidelines on what NOT to do.




Libes                                                           [Page 1]

RFC 1178                   Name Your Computer                August 1990


      Don't overload other terms already in common use.

         Using a word that has strong semantic implications in the
         current context will cause confusion.  This is especially true
         in conversation where punctuation is not obvious and grammar is
         often incorrect.

         For example, a distributed database had been built on top of
         several computers.  Each one had a different name.  One machine
         was named "up", as it was the only one that accepted updates.
         Conversations would sound like this: "Is up down?"  and "Boot
         the machine up." followed by "Which machine?"

         While it didn't take long to catch on and get used to this
         zaniness, it was annoying when occasionally your mind would
         stumble, and you would have to stop and think about each word
         in a sentence.  It is as if, all of a sudden, English has
         become a foreign language.

      Don't choose a name after a project unique to that machine.

         A manufacturing project had named a machine "shop" since it was
         going to be used to control a number of machines on a shop
         floor.  A while later, a new machine was acquired to help with
         some of the processing.  Needless to say, it couldn't be called
         "shop" as well.  Indeed, both machines ended up performing more
         specific tasks, allowing more precision in naming.  A year
         later, five new machines were installed and the original one
         was moved to an unrelated project.  It is simply impossible to
         choose generic names that remain appropriate for very long.

         Of course, they could have called the second one "shop2" and so
         on.  But then one is really only distinguishing machines by
         their number.  You might as well just call them "1", "2", and
         "3".  The only time this kind of naming scheme is appropriate
         is when you have a lot of machines and there are no reasons for
         any human to distinguish between them.  For example, a master
         computer might be controlling an array of one hundred
         computers.  In this case, it makes sense to refer to them with
         the array indices.

         While computers aren't quite analogous to people, their names
         are.  Nobody expects to learn much about a person by their
         name.  Just because a person is named "Don" doesn't mean he is
         the ruler of the world (despite what the "Choosing a Name for
         your Baby" books say).  In reality, names are just arbitrary
         tags.  You cannot tell what a person does for a living, what
         their hobbies are, and so on.



Libes                                                           [Page 2]

RFC 1178                   Name Your Computer                August 1990


      Don't use your own name.

         Even if a computer is sitting on your desktop, it is a mistake
         to name it after yourself.  This is another case of
         overloading, in which statements become ambiguous.  Does "give
         the disk drive to don" refer to a person or computer?

         Even using your initials (or some other moniker) is
         unsatisfactory.  What happens if I get a different machine
         after a year?  Someone else gets stuck with "don" and I end up
         living with "jim".  The machines can be renamed, but that is
         excess work and besides, a program that used a special
         peripheral or database on "don" would start failing when it
         wasn't found on the "new don".

         It is especially tempting to name your first computer after
         yourself, but think about it.  Do you name any of your other
         possessions after yourself?  No.  Your dog has its own name, as
         do your children.  If you are one of those who feel so inclined
         to name your car and other objects, you certainly don't reuse
         your own name.  Otherwise you would have a great deal of
         trouble distinguishing between them in speech.

         For the same reason, it follows that naming your computer the
         same thing as your car or another possession is a mistake.

      Don't use long names.

         This is hard to quantify, but experience has shown that names
         longer than eight characters simply annoy people.

         Most systems will allow prespecified abbreviations, but why not
         choose a name that you don't have to abbreviate to begin with?
         This removes any chance of confusion.

      Avoid alternate spellings.

         Once we called a machine "czek".  In discussion, people
         continually thought we were talking about a machine called
         "check".  Indeed, "czek" isn't even a word (although "Czech"
         is).

         Purposely incorrect (but cute) spellings also tend to annoy a
         large subset of people.  Also, people who have learned English
         as a second language often question their own knowledge upon
         seeing a word that they know but spelled differently.  ("I
         guess I've always been spelling "funxion" incorrectly.  How
         embarrassing!")



Libes                                                           [Page 3]

RFC 1178                   Name Your Computer                August 1990


         By now you may be saying to yourself, "This is all very
         silly...people who have to know how to spell a name will learn
         it and that's that." While it is true that some people will
         learn the spelling, it will eventually cause problems
         somewhere.

         For example, one day a machine named "pythagoris" (sic) went
         awry and began sending a tremendous number of messages to the
         site administrator's computer.  The administrator, who wasn't a
         very good speller to begin with, had never seen this machine
         before (someone else had set it up and named it), but he had to
         deal with it since it was clogging up the network as well as
         bogging down his own machine which was logging all the errors.
         Needless to say, he had to look it up every time he needed to
         spell "pythagoris".  (He suspected there was an abbreviation,
         but he would have had to log into yet another computer (the
         local nameserver) to find out and the network was too jammed to
         waste time doing that.)

      Avoid domain names.

         For technical reasons, domain names should be avoided.  In
         particular, name resolution of non-absolute hostnames is
         problematic.  Resolvers will check names against domains before
         checking them against hostnames.  But we have seen instances of
         mailers that refuse to treat single token names as domains.
         For example, assume that you mail to "libes@rutgers" from
         yale.edu.  Depending upon the implementation, the mail may go
         to rutgers.edu or rutgers.yale.edu (assuming both exist).

      Avoid domain-like names.

         Domain names are either organizational (e.g., cia.gov) or
         geographical (e.g., dallas.tx.us).  Using anything like these
         tends to imply some connection.  For example, the name "tahiti"
         sounds like it means you are located there.  This is confusing
         if it is really somewhere else (e.g., "tahiti.cia.gov is
         located in Langley, Virginia?  I thought it was the CIA's
         Tahiti office!").  If it really is located there, the name
         implies that it is the only computer there.  If this isn't
         wrong now, it inevitably will be.

         There are some organizational and geographical names that work
         fine.  These are exactly the ones that do not function well as
         domain names.  For example, amorphous names such as rivers,
         mythological places and other impossibilities are very
         suitable.  ("earth" is not yet a domain name.)




Libes                                                           [Page 4]