Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site adobe.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!Glacier!adobe!greid
From: greid@adobe.UUCP (Glenn Reid)
Newsgroups: net.mail
Subject: Mail addressing and routing
Message-ID: <644@adobe.UUCP>
Date: Sun, 4-Aug-85 21:12:39 EDT
Article-I.D.: adobe.644
Posted: Sun Aug  4 21:12:39 1985
Date-Received: Tue, 6-Aug-85 05:45:00 EDT
Reply-To: greid@adobe.UUCP (Glenn Reid)
Distribution: net
Organization: Adobe Systems, Palo Alto
Lines: 67

There are lots of problems with the current mail system, as I don't
have to point out to anybody.  I think that many things can be learned
simply by looking at the U.S. Postal Service, like it or not, which works.

For example:  on USENET, people are basically at liberty to decide what
their site will be called, and what usernames are valid at that site,
which starts all these so-called name collisions with mailers.  I point
out to you that there is far more likelihood for name collisions in
street naming (done locally), people naming (done locally), and town
naming (also done locally).  The Post Office is perfectly happy to let
you decide what to call yourself, and where you live.  So should USENET
be.  What they do, however, is to decree that State names need to be
uniform, and ZIP codes, even more so.  They basically will not deliver
a letter without a ZIP code on it, as well they shouldn't.  (Debatable).

It makes sense for electronic mail to follow some similar convention,
which should allocate geographic (probably) zones in which the mail
addresses are to be evaluated, and have several levels of delivery.

To draw another analogy, consider the various lines on a USmail address.
The Post Office starts reading AT THE BOTTOM, not at the top.  Why not
have more than one line for electronic mail messages, like so:

Address:	adobe!greid
Area:		SILICON.VALLEY
State:		CA
ZAPcode:	94303-852-0271		(arbitrary)

The problem at the moment is that net addresses are dependent upon
machine names, which is never going to be constant for long.  There need
to be basic geographic or policital address conventions, with a mechanism
for deciding what computer is actually going to deliver the mail.  Then
any given mailer only has the responsibility of getting the message first
to the proper geographic area, then some computer who claims to represent
that area (or zip-code, if you will), can forward it from there.

"THAT IS A DOMAIN," I can hear people shouting.  Perhaps, but domains at
present are set up at random and without any particular heirarchical or
geographic method.  There is no standard.  And the domain names are 
completely arbitrary.  If they were broken down, say, by STATE NAME, then
it would be reasonable for each computer to maintain a table of all 50
states and where to deliver mail that it receives with that State name
in it.  An 'aliasing' system, which doesn't really require that my computer
know anything about the real route.  For instance, if I send mail bound for
Massachusetts from my computer, (we have no direct links to MA), our mailer
looks in its table under MA and finds: decwrl.  Aha.  decwrl is in California,
everybody knows that.  But my mailer sends it to decwrl anyhow.  Decwrl then
looks at the message and says, "Aha.  Massachusetts."   In decwrl's table
under MA might be MIT-something, so it sends it there.  And so on.

This means that the return route MIGHT NOT BE THE SAME as the sending
route, but who cares?  It allows for path optimization, changing routes
very simply, and for more sensible routing in general.

The next problem arises once the mail gets into the proper state, but 
that is where the ZAP code comes in (or whatever).  First, decwrl (or
whoever) will look at the first line of the address.  If it doesn't know
the address, it will look at the ZAP code, to determine where next to send
it.  Again, this code will evaluate to another computer name, but it can
be changed ON THAT MACHINE without ever changing the net address that the
original sender types in at his end.  And computers in California would
only need to maintain tables for areas in california, and so on.

This would work.  Why don't we do it?

Glenn Reid
..decwrl!adobe!greid