From: utzoo!decvax!harpo!npoiv!npois!cbosgd!mark
Newsgroups: net.followup
Title: Re: UUCP Internet Addresses
Article-I.D.: cbosgd.2639
Posted: Mon Sep 20 11:24:45 1982
Received: Tue Sep 21 07:30:40 1982
References: populi.342

Bill Wells makes an interesting proposal.  I'm glad to see people
are addressing the issues of heirarchies for UUCP.

I'm beginning to wonder if we need a newsgroup to talk about mail
issues?  There are two ARPANET mailing lists (header-people and
msggroup, and I still don't understand the difference) for this
but only two USENET people are involved in these discussions,
and they are ARPANET oriented.  Anyone interested in net.mail?

The idea of making UUCP into a heirarchy is appealing.  But there
are some enormous technical problems to be worked out.

Note also that Steve Belovin (unc!smb) is keeping a quasi-official
UUCP map, and while it will probably never be 100% correct (due to
lack of any control of UUCP net, lack of a broadcast mechanism, and
lack of a central registry) desire to receive mail should provide
some incentive.  Rick Adams effort will also no doubt be extremely
helpful, although cooperation between the people involved will make
for one superior map.

The decision to go initially with the user@host.uucp syntax was made
for simplicity.  Most uucp sites that deal with other sites currentl
think of sites, not heirarchies.  Many don't even believe in network
boundaries: MMDF wants all mail to go to user@host where host is not
subdivided - a table lookup is done (either locally or by a forwarder)
to decide what host and what network to send to.  This simplicity goal
is probably good to make conversion easier, but there are certainly
long term problems.  (Netnews assumes host names are unique - if Bill
has seen duplicate UUCP host names I'd be interested to hear about
them, since I've never seen a duplicate and many programs assume there
are no duplicates.)

First note that the problem of keeping a large database on a micro
does not wash.  A tiny micro can punt the issue entirely by sending
all non-local outgoing mail to one particular site (which it probably
does anyway) and letting that site worry about how to route it.

Second, note that there is no requirement or advantage to forcing fixed
length abbreviations.  Countries can be USA, Canada, and Mexico,
time zones can be PST, EST, etc (although I am opposed to using time
zones as part of the heirarchy).  Since we already have official two
letter state/province abbreviations which most people know, it is fair
to use them.  (We should, however, probably avoid names like
Czechoslovokia, instead adopting an official abbreviation like Czech,
and hopefully allowing nicknames.)

Now for the technical problems.  First off, we need software to support
it.  I urge Bill Wells to talk to Eric Allman (arpavax:eric) to see
if sendmail can do this.  (It probably can, but it's not obvious to me
how.)  If not, perhaps sendmail can be augmented.  We also need a trivial
program (such as that by ucf-cs!tim) that can be dropped into any
existing mail system, so that people won't be out in the cold if they
have their own homegrown mail system, or if they have some official
requirements like "we run UNIX as it comes from group xyz with no mods"
it will be possible to argue that the changes are trivial and therefore safe.

Second, if USENET has shown anything, it has shown that there are all
kinds of anomalies about where cross country links go.  While it's
appealing to have a geographic heirarchy, In reality what happens is
that some sites are only on UUCP by the grace of a friend of theirs
across the country who is willing to pay the phone bills.  One look
at the geographic USENET map from my talk last January shows what appears
to be a big mess.  (Examples: utah-cs started out talking to harpo,
uwvax in Wisconsin started out talking only to ucbvax, philabs in NY
state talking to sdcsvax in San Diego, etc.  Most of these sites are
better connected now, but there are always new sites - currently there
is kentvax in Kent State, Ohio, whose only connection is to ucbvax.)
Sometimes there is a leased line (e.g. ima, in Mass, to ico, in Colo.);
sometimes there is a special link, like the ARPANET link between cca
in Boston to sri-unix in San Francisco.; sometimes a site just happens
to have a high phone budget (e.g. decvax, which is the main link for
pur-ee in Indiana and microsoft in Seattle) or a WATS line.  Security
is an issue too - there are three groups of USENET sites near Denver:
Bell Labs has Denver sites that aren't even allowed to talk to other
Bell Labs sites, much less outside sites; Interactive's ico site is
there, and hao is also there.  These sites don't talk for security
reasons, as I understand it.

The following technical problem can arise.  Suppose mail distribution
is heirarchical by, say, state (which would be my preference).  I
send mail to daveb@ico.co.usa.uucp.  It gets sent to colorado, say hao,
which then figures out a route to get it to ico:
menlo70!ucbvax!decvax!cca!ima!ico!daveb is the shortest path!  So hao
sends it to menlo70, which says "this should go to Colorado, so I'll
send it to the Colorado distribution center, which is hao".  (For those
of you familiar with packet switched networks, this problem will remind
you of the situation where a link goes down and tables aren't up to date,
resulting in a loop.)

Also, if we're going to get this fancy, we should consider what to do
about a down host.  If I'm in Canada, chances are all my mail goes
through decvax.  If decvax goes down for 2 weeks, I'm isolated.  It
would be nice to have mail try to send through site x, and if that
fails, try an alternative site.  (Given the implementation of uucp,
this is a very difficult problem.)

I believe these problems can be solved.  A site can invoke arbitrarily
hairy decisions about how to route a message (the address heirarchy is
only a precise specification of a location, not a route) if they are
allowed (forced?) to write code.  I don't know if these decisions can
be implemented in a sendmail configuration file; I hope so.

We can start by specifying a precise routing algorithm that all sites
can implement.  If an algorithm exists, it may make sense to adopt
a hierarchical standard.  Bill - care to make an initial stab at it?

	Mark Horton