Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site down.FUN
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!bellcore!allegra!princeton!down!honey
From: honey@down.FUN (code 101)
Newsgroups: net.mail
Subject: Re: name change
Message-ID: <452@down.FUN>
Date: Fri, 22-Feb-85 00:20:44 EST
Article-I.D.: down.452
Posted: Fri Feb 22 00:20:44 1985
Date-Received: Sun, 24-Feb-85 02:25:51 EST
References: <484@digi-g.UUCP> <405@lsuc.UUCP> <597@plus5.UUCP> <603@plus5.UUCP> <604@plus5.UUCP> <890@cbosgd.UUCP>
Organization: Princeton University, EECS
Lines: 71

what i want is a simple way to tell people my mail address.  to me this
means always giving my user name, frequently giving my host name, and
sometimes naming my network, but no more than that.  to achieve this, i
pick a host that has high visibility.  in my case, this happens not to
be the machine on which i work.  this is common, e.g., cbosgd!mark ->
cbpavo!mark, allegra!jpl -> presto!jpl, bellcore!everybody -> god knows
where.

what does it take to make this simple idea work well?

first, we must have a means to make a host name well-known.  i believe
that the efforts of karen (map management) and lauren (name registry)
are making this a reality.

next, we need a way to hide the names of "minor" hosts.  this is partly
for convenience, so that people can use familiar gateways, partly to
minimize data rot, and partly to avoid host name conflicts.  it appears
people have sendmail tricks for hiding host names; i have also seen a
one line sed script that does the job.

this seems a good moment to mention an undocumented capability of the
latest pathalias.  a line of the form

private {host, ...}

declares the list of host names that follows as private, or local, for
the remander of the current input file.  connection data for a private
host is associated with a host guaranteed to be distinct from all others.

for example, eecs at princeton has a machine called iris, but there is
at least one other iris on the network, at brown.  so i declare iris
private in the eecs connection data file.  pathalias then distinguishes
princeton's iris connection info from brunix's, so that i don't end up
routing to princeton!iris!brunix!...

there are two reasons why this is not documented anywhere ('til now,
such as it is).  first, i'm not happy with my yacc description, which
requires that private and { appear on the same line.  (this is to avoid
making private a keyword.  i invite the interested to clean this up.)

second, what do you do with it once you've got it?  should i produce
output for both irises?  how do i build a dbm file on that?

at the moment, i don't produce output for private hosts at all, nor for
any host that clashes with a private host.  this means that i can
specify princeton!iris!user or brunix!iris!user, but not iris!user.

of course, i cheat by adding the local iris to my route tables.  also,
i accommodate other people's broken software:  we changed iris' name to
ivy this week.

finally, my hacked up delivermail consults an edge database built from
karen's data to help optimize the route.  this enables me to re-route a
long path ending in ...!brunix!iris!.. to brown, or even to hosts to
the right of iris on the specified address.

i maintain that these techniques have the same effect as domaining:  by
adding more information to the address specification, ambiguous routes
and host names can be accommodated, and route optimization can take
place.  i also maintain that this is more powerful than domaining,
since it achieves the economy of host!user (or user@host, if you must)
wherever possible, is compatible with existing practices, and works
even when !'s and @'s are mixed.

	peter

ps:  if you care to write a followup to this note, please do not
include huge chunks of it, or even small pieces.  i know the temptation
to make a point-by-point reply is irresistible, but i suggest you
simply state your ideas and let the news reading software provide the
right level of context.