Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!linus!security!genrad!mit-eddie!smh
From: smh@mit-eddie.UUCP (Steven M. Haflich)
Newsgroups: net.mail
Subject: Re: *uucp* addresses
Message-ID: <935@mit-eddie.UUCP>
Date: Thu, 17-Nov-83 09:59:26 EST
Article-I.D.: mit-eddi.935
Posted: Thu Nov 17 09:59:26 1983
Date-Received: Fri, 18-Nov-83 02:16:49 EST
References: <188@menlo70.UUCP>, <3753@umcp-cs.UUCP> amd70.4102 <1138@cincy.UUCP>
Organization: MIT, Cambridge, MA
Lines: 22

Indeed, name conflicts have already happened -- sort of.  The machine
from which this reply originates is "mit-eddie" and belongs to a suite
of machines named after characters [sic?] in A Hithchhiker's Guide to
the Galaxy.  A machine at the University of Washington is called
"uw-eddie" and belongs to a suite of machines named after characters in
Leave it to Beaver.  The problem does not occur with uucp, but both
machines are on local networks (Ethernet) and also directly or
indirectly accessable from the Arpanet.  Unlike uucp, these other
networks support host-name aliases, in this case, "eddie".  The net
result is that from different locations in this non-Cartesian universe,
the unqualified name "eddie" can get you to very different places.
Another example:  Independently, in the exact same week, a site at
Berkeley and a site at MIT both decided to name suites of machines
after composers, and both have a "bach": mit-bach and ucbbach.  The
same problem exists for abbreviated names...

The probability of naming conflicts can be reduced if sites would try
to keep their organization name apparent in host names.  Problems will
still occur, however, if local abbreviations can be "seen" from
outside.

Steve Haflich, MIT Experimental Music Studio