ARPAVAX:UNKNOWN:G:wcwells (09/19/82)
Proposal for UUCP Network & Internet Addresses
Summary.
I believe the UUCP network can improve the way it handles mail by
establishing communications regions/areas. Here are my suggestions for
UUCP addresses meeting the ARPA Internet standards.
Discussion.
The proposed adoption of the ARPA Internet formatted addresses by the
UUCP community (cbosgd!mark Fri Aug 20 10:26:18 1982) presents a number
of challenges. The format suggested by Mark Horton "user@host.uucp"
requires the following to be implemented:
1. A central registry of UUCP host names.
2. No duplicate host names
3. Each host must have a complete and
current list of UUCP host names
(and associated relative path
address).
>From what I have read on the USENET over the last several months, there
is no central registry for UUCP host names (through a few brave souls
are trying to compile a master list of UUCP host names). We have
already had one or more sites joining the UUCP network with a duplicate
host name. We do need to establish a central registry (or regional
registries) for UUCP host names if we are going to implement an
Internet type addressing scheme.
Micro computer (ie. floppy disk) hosts on UUCP have storage
restrictions which are not present in ARPA Internet hosts.
Maintaining a file of all host names (and their relative paths) is
fine for large machines (with plenty of disk space) but is not
feasible for small micros (with very limited floppy-disk space).
The way I see it, we have two solutions to help small micros on
the network, (a) establish mail service machines (with complete
host table files) to serve small machines, and/or break the UUCP
network into communication regions/areas so that the local machine
only needs to know about hosts in its local communications area
and how to send to other areas.
Proposal.
My first proposal is that we divide the UUCP community into regions
and areas within regions.
The advantages to dividing UUCP into regions are:
1. We can divide the labour to maintain the host
lists (ie. regional host lists can be managed by
one person, or several - one for each region).
2. Duplicate names are permitted (provided that
they are unique within the local communications area.)
3. The size of host list files need to be maintained
at any one site can be reduced. A host only needs to
know about hosts in its local communications area
and how to send to outside areas.
4. Outgoing and relayed messages can be stored by
the region of destination (a smaller directory to be
searched for mail!).
5. Gateways to and from other networks (eg. ARPANET
could be established in the same region instead of
half-way across the country. (No more need to send
a message across the country to get it next door.)
On the other hand, to establish a regional system, we would
have to define communication regions and areas within regions.
And establish regular routes for transmissions between
regions and/or areas. (To some extent we are already defining
routes between regions.)
Communication Regions
Some possiblities that I have thought of for regions are time zones,
continents, and countries. I prefer times zones since they are directional
in nature (east-west) and can be specified with one letter if we
use military time zone designators. For example,
Region Civilian Zone Number Military Proposed
Name Time Zone (delta GMT) Time Zone Domain Name
GMT 0 Z Z.UUCP
Atlantic AST +4 Q Q.UUCP
Eastern EST +5 R R.UUCP
Central CST +6 S S.UUCP
Mountain MST +7 T T.UUCP
Pacific PST +8 U U.UUCP
Communication Areas:
For communication areas I believe we should use
pre-established divisions such as political divisions, telephone area
codes, or postal codes. My personal preference is to use a combination
code with a two letter country code (standard military) and a two letter
state or province code (standard postal), for example, 'CA.US' for California,
USA, 'BC.CA' for British Columbia, Canada. Another possiblity, would
be to have a combination country and telephone area code. For example,
'US415' for the 415 area code (San Francisco CA), 'CA604' for the
604 area code (British Columbia, Canada). The latter might be a better
choice for UUCP since the UUCP network is primarily a telephone
network. However, the latter would mean a larger look-up table for
area to region expansion and requires the user to specify the telephone
area code for hosts outside his local area. The former requires state
codes be specified for out of state hosts. If you do not have a mail
service program to look-up full host names, then I believe it is
easier to remember the state a host is located in.
Using political divisions I come up with the following communication
areas for the Pacific (U.UUCP) region:
Area UUCP Area UUCP Internet Domain
British Columbia BC.CA BC.CA.U.UUCP
California CA.US CA.US.U.UUCP
NW Mexico NW.MX NW.MX.U.UUCP
Oregon OR.US OR.US.U.UUCP
Washington WA.US WA.US.U.UUCP
Or using telephone area codes:
Area Code UUCP Area UUCP Internet Domain
70 (NW Mexico) MX70 MX70.U.UUCP
206 US206 US206.U.UUCP
209 US209 US209.U.UUCP
213 US213 US213.U.UUCP
408 US408 US408.U.UUCP
415 US415 US415.U.UUCP
503 US503 US503.U.UUCP
509 US509 US509.U.UUCP
604 (BC Canada) CA604 CA604.U.UUCP
702 US702 US702.U.UUCP
707 US707 US707.U.UUCP
714 US714 US714.U.UUCP
805 US805 US805.U.UUCP
916 US916 US916.U.UUCP
Take your chose. (Please send votes to ucbvax!g:wcwells, I will
tally and post results. Send comments and new ideas to net.followup)
Addresses specified by the user:
It should be noted that we can make addressing easier for the user
if we have mail programs that will expand the addresses as
needed so that the user only has to specify a partial domain
address, for example:
g.wcwells@ucbvax (same state & country assumed)
g.wcwells@ucbvax.ca (same country assumed)
and g.wcwells@ucbvax.ca.us (UUCP area specified)
will all expand to the Internet address:
g.wcwells@ucbvax.ca.us.u.uucp
or if we chose to go with area codes:
g.wcwells@ucbvax (same area code assumed)
and g.wcwells@ucbvax.us415 (UUCP area specified)
will all expand to:
g.wcwells@ucbvax.us415.u.uucp
If our mailing programs have a complete list of host names
then we can use the simplest form of the address,
user@host
and let the mail program expand the addresses. Of course, with
duplicate host names you would have to include the area
name to distinguish between hosts:
user@host.area
My second proposal is that we develop mail forwarding programs
in such a way that we can provide mail address expansion services
to micros when their messages pass through our larger minis.
[Since this message is getting to be a long one,
I will let someelse pick-up and run with this idea.]
COMMENTS?
Bill Wells
Computing Services, University of California, Berkeley CA 94720, USA
(415) 642-9801
ARPANET: G.wcwells@BERKELEY
BITNET: WCWELLS at UCBUNIXG
MARS: NNN0LBR NCA
UUCPNET: ucbvax!g:wcwellsmark (09/20/82)
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
CSvax:cak (09/20/82)
While I applaud your efforts to come up with a naming scheme for the
uucp Internet name domain, I think you may be moving in the wrong
direction. The point is that users should not have to know the
subdomain, etc., of a site in order to get mail there; the sitename
should be sufficient. Unfortunately, this means we have to have unique
site names -- I agree that this is a problem. I think, however, that
this can be handled in an ad hoc manner; a new site coming on line just
won't be able to get mail, and will change its name.
That's not the main point though. I think that it is foolish to expect
every site to maintain a complete registry of available uucp site
names; this happens to be necessary for Arpa Internet hosts now, but
soon won't be. The direction the Internet is moving towards is a system
of central nameservers, at least one for each naming domain, that know
either a) how to tell you how to get to a site in that domain, or b)
will forward mail to a site in that domain for you. Internet hosts are
expected to maintain a cache of addresses locally, so as to minimize
traffic to and from the nameserver, but this won't be necessary.
I would suggest that uucp sites should move in the same direction. To
send a letter, you would look in your local cache of names (which might
have only one name in it -- your connection to the outside world) to
see if you know the path to get there. If you don't, you hand off to
your chosen forwarder, who presumably knows how to get everywhere.
Every site applies this algorithm recursively. By maintaining a number
of central sites that really DO know how to get everywhere (the set
{ucbvax,harpo,decvax,pur-ee} is representative of this class of sites)
with fairly up to date routing tables, things should work out pretty
well.
Some mechanism for updating a local cache is desirable; for example, a
site that receives a letter to be forwarded might send a message back
to the originating site indicating where it was forwarded to. Then the
site could compare that forwarding site's name to its local list of
connections, and update routing tables accordingly, thus cutting one
hop off of its path. Very sophisticated distributed routing algorithms
exist; we should make use of one of them.
We really should try to view the uucp net as an Internet-like system,
consisting of a number of subnets connected by gateways that are
'smart'. With some form of routing updates slowly propogating around
the net, I think we can maintain some semblance of current connectivity
information sufficient to implement speedy routing.
I also welcome any and all comments, and will summarize them to the net
(if they don't get posted there).
Cheers,
Chris Kent, Purdue CSkis (09/21/82)
Just a small comment as to the coherent property of the Bell Labs sites. My experiences have shown that the network changes very dynamically, and that the site gurus have been too busy to advise their neighbors of impending changes. The result is that the path that worked yesterday may not work today.