[can.general] Addressing with domains

mouse@mcgill-vision.UUCP (09/05/87)

In article <917@looking.UUCP>, brad@looking.UUCP writes:
> [re domaining schemes]
> There is nothing wrong with having multiple logical addressing
> schemes.  There should be such.

> But one consistent scheme must always be present.  That's the scheme
> you use when you try and "figure out" how to mail somebody.

> If you wanted to get mail to somebody, what would be easiest to work
> out?  I maintain that this is the geographical scheme.  Usually if
> you know one thing about somebody, it's the town they live in.

Not true anymore and less true in the future.  There are already a
handful of people I know for whom I have no idea what city/town they
live, work, or do anything else in.  These are people I reach
electronically.  With greater electronic connectivity, I expect this
phenomenon to make itself felt more and more.  You, for example, I
think of as brad@looking.uucp, and I have to think, or ask for the map
entry for looking, to find out you are in Waterloo.  Nor do I care
particularly where you are geographically, unless and until I have to
do something (like sending paper mail) which requires such information.

> You need this if you want to mail a postal letter,

Necessarily.  We need some way of providing a globally unique address
for each potential recipient.  For paper mail, the means that has been
chosen is a normal name plus a street address (when this system was
developed, not much else was workable, though now we could use
computers to set up a registry allowing other schemes).  For electronic
mail, a scheme involving hierarchical things called "domains" has been
chosen.  (A precursor, still hanging around, involved specifying a
path, as if I had to address a paper letter to you with
	Brad Templeton
	1234 Somewhere Street
	via Crossing Avenue in Waterloo
	via Main Artery in Waterloo
	via Waterloo Main Post Office
	via ....
	via Montreal Main Post Office
	via Main Artery in Montreal
	via Crossing Street in Montreal
this letter being sent from 4321 rue Qpt).

> or find their phone number.

Again, only because that's the only way it has been set up.  It could
be set up differently with the technology we now have, but there's been
no sufficiently compelling reason to tear down what we have.

> Even if you already know the number, the town is coded within it.

From that point of view, once you have a domain address the town is
coded within it as well, since it necessarily refers to some machine,
which necessarily is in some location.

This will break down when we get multiprocessor machines with the
processors in widely different places, but let's not worry about that
just yet.  I forsee a day when there is one world-wide computer, a
colossal distributed machine, but that is some time off.

> This has nothing to do with the routing underneath.  This is just how
> I think we usually associate people.

Only because that's how we are used to doing it.  It does not have to
be this way, and I think that we should try some other way, if only
because progress is made only when we try new things.

> The one, consistent scheme that everybody understands is geography.

Again, only because that's the only one our society uses universally,
because until very recently it was the only one we had the technology
to support.

> Organizational and company related schemes are haphazard and
> difficult to follow.

I suspect this is because they have, so far, been constructed very
ad-hocly(!).

> For far down the line, a geographical domain structure is the only
> way to go.  Now, while the number of email users is small, we can use
> other schemes as we like, but they will damn us later.

I fail to see why the user-visible address should have anything to do
with physical location.  The numeric address (for Internet mail) or
routing path (for UUCP mail) necessarily is physical-location-based
because communication channels tend to tie physically close machines
together.  (This is beginning to break down, witness uunet's
connectivity.)  However, this is what nameservers (for Internet mail)
or UUCP maps (for UUCP mail) are for: to map the user-visible addresses
into the means to reach that address.

> Think about it:  If you could redisign[sic] the Canada Post
> addressing scheme right now (ignoring Postal Codes),

Zip codes (I refuse to stumble over "Postal" codes, just as I always
call all small Band-Aid-style bandages "Band-Aid"s even though they
strictly aren't) are slightly disguised domain addressing, with
geographical domains (natural enough, when geographical locations are
being addressed).

> and things like routing and post offices were not a problem, how
> would you do it?  This is how email should be addressed, too.

I fail to see why.

As you say, there is no problem until the number of email users gets to
the same order of magnitude as the number of postal addresses.  So let
us postulate a world in which every home has a computer; let us suppose
these are networked in some way.

Now let us suppose you have a flame/compliment/question (or some other
sort of message) about something.  Let us suppose it is the rear-view
mirror on your new car.  Why should you have to ask where the head
office of the car maker is and send your letter there?  Let the
computer do the grunge work: address your letter to the car maker and
let the computer look up the physical, numerical, whatever address.
*This* is how *all* mail should be addressed.  However, we do not have
the technology (OCRs &c) to do it reliably for paper mail, and it would
be a humungous conversion effort even if we did.  But with email we
have no conversion effort, or rather the conversion effort is no worse
one way than another, and we *do* have the technology (MX records and
UUCP maps).

					der Mouse

				(mouse@mcgill-vision.uucp)