Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.mail
Subject: Re: colons, atsigns, & domains in uucp path keys
Message-ID: <2038@cbosgd.UUCP>
Date: Mon, 21-Apr-86 23:58:14 EST
Article-I.D.: cbosgd.2038
Posted: Mon Apr 21 23:58:14 1986
Date-Received: Wed, 23-Apr-86 21:19:37 EST
References: <404@geowhiz.UUCP>
Organization: AT&T Bell Laboratories, Columbus
Lines: 71

In article <404@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes:
>Colons:  Is there some reason why these sites can't accept the normal 
>	uucp sequence?  If they are unix sites, there is no excuse, I
>	have a stub which will solve the problem in about 20 lines of
>	code.  I'd be happy to pass it on.

Colons generally are there because of Berknets or ACSnet, although I
think Australia doesn't publish the ACSnet data on the UUCP map.  Since
Berknet went out when 4.2BSD came out, most sites running a Berknet are
probably doing so for historical reasons (they don't have the resources
to convert, as they are busy doing something else) and even a 20 line fix
would be too much effort.  Some of the publications may occur because the
author doesn't understand the intent of the UUCP map - chances are that
most posted Berknet sites really shouldn't be on the map at all.

>Atsigns: Why don't these sites register as normal uucp sites? I see lots 
>	of junk like ....!bigname_here!%s@little_name.  Come on, what's
>	the problem?

Of course, this is dangerous, and RFC976 specifies the safe way to use
atsign semantics in bangs: ...!bitname_here!little_name.!%s
Chances are most such places will convert once smail is posted.
However, again, local names like little_name probably don't belong
on the UUCP map.

>Domains: This is just obnoxious.  There exist routers which will forward
>	stuff from one domain to the next, lets not clutter up the uucp
>	maps with this garbage.  Berkeley is by far the worst offender
>	with 272 out of 389 such names and they are just aliases for
>	the uucp names.  Can't this stuff go someplace else?

It's important to have domains in the map, but the intent is to decrease
the size of the map by having only a single entry for each organization
(or each major gateway into the organization.)  Thus, Berkeley really
only needs an entry for ucbvax, and maybe ucbopt.  I agree that the
huge entries like ucbvax has are not needed, and just contribute to
the overall size of the map.

>Summary: The uucp maps are for UUCP PATHS!  Don't fill them with domain 
>	aliases.  Fill out the stupid maps & send them in.

I think what you mean is that we only need info for ucbvax, but we need
both ucbvax for UUCP, and Berkeley.EDU for domains.  The simple entry
	ucbvax="Berkeley.EDU"
	ucbvax	ihnp4(DAILY), seismo(DAILY), ...
is enough, this tells us that to get to brahms.Berkeley.EDU one need
only send to ucbvax!brahms.Berkeley.EDU!%s, without even storing an
entry for brahms in the database.  This is the whole point of domains,
a small database is all you need.  Anything ending in Berkeley.EDU can
be sent to ucbvax for further forwarding.

It's a bit unfair to pick on Berkeley here, since Erik Fair is aware of
the problem and working on it.  But others are beginning to pick up on
this example, and it's bloating the map and causing more name collisions.

So please, some guidelines:

(a) Don't publish local nets.  Put them in your path.local file for your
    local use, but don't put them in the published entry for the world.
(b) As soon as you have an RFC976 compliant system in place, only publish
    one entry for your organization (two or three if you have that many
    gateways.)  Arrange for that machine to forward all your mail to
    the proper place internally.
(c) If you have small internal machines, please try to hide them.
    Ideally, your mail and news should appear to come from your gateway.
(d) The UUCP map is for UUCP data.  We aren't interested in BITNET, ARPANET,
    CSNET, etc.  Just places that can be reached via the ! notation.
    If this includes other transports, fine.  We put out one file
    (path.top) which lists the top level domains and how to get there.

	Mark Horton