Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2.fluke 9/24/84; site fluke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!vax135!cornell!uw-beaver!fluke!joe
From: joe@fluke.UUCP (Joe Kelsey)
Newsgroups: net.mail
Subject: Re: name change
Message-ID: <2180@vax4.fluke.UUCP>
Date: Thu, 28-Feb-85 12:27:13 EST
Article-I.D.: vax4.2180
Posted: Thu Feb 28 12:27:13 1985
Date-Received: Fri, 1-Mar-85 09:42:02 EST
References: <484@digi-g.UUCP> <405@lsuc.UUCP> <597@plus5.UUCP> <603@plus5.UUCP> <604@plus5.UUCP> <890@cbosgd.UUCP>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 94

Well, since my name was mentioned, I guess I should speak up.

There was a discussion on header-people (I think) about a month ago
which was started when Mark posted a note asking everyone if they
thought dahses (-) were ok to use in domain names.  He outlined the
current UUCP Domain proposal along the way.  What ensued was a variety
of messages, mostly about whether or not it was appropriate to name a
domain after the transport mechanism.  I thought about this for a
while, especially after a particluarly enlightening message from Jon
Postel about the real meaning of Domains.

What struck me most was that the UUCP domain was in some respects
re-inventing the wheel.  Way back when the ARPAnet started, they had a
flat name space.  After a while, they decided this wasn't good enough,
so someone came up with Domains.  It started to catch on when DoD
forced a change to TCP/IP, and everyone started tacking .ARPA onto
their hostname.  This works fine until you try to start adding "real"
domains, like .COM, .EDU, etc.  Suddenly, your hostname no longer has
anything to do with the network you are attached to, it simply
describes you!  Then along comes the UUCP Domain Spec, and suddenly we
are transported back in time 5 years!  Our hostname no longer simply
describes us, but rather ties us down to a particluar transport
mechanism.

Now I ask you, how are you going to deliver a message to ISIF.USC.EDU?
That IS going to be the name of one of the ISI machines at USC.  I know
that they are connected to ARPAnet now, but you can't tell that from
the name, can you?  How about BEAVER.UWASH.EDU?  A possible name for
uw-beaver, but they are on ARPAnet AND UUCP!  In fact, they are a
backbone site for USENET.  Are you going to special case all of the
non-UUCP domain names as ASSUME they are ARPA-based?

Don't get me wrong - I think the UUCP Doamin Spec is a GREAT first
draft.  However, there are some issues that need to be clarified, and I
think that the issue of names is the primary one.  If you read the
Domain Spec RFC you will notice that a host may have ONE AND ONLY ONE
name. (well, LOCAL nicknames are OK as long as they don't filter out to
the resto of the world)  This means that hosts like uw-beaver will have
to choose a name to be known as in Internet-land.  They can still keep
uw-beaver as a uucp transport name, but they can't use
UW-BEAVER.WA.UUCP and BEAVER.UWASH.EDU.  I suspect that they will
choose a name in the .EDU domain over a name in the .UUCP domain.  That
means that people who send messages to the Beav' can either send to
user@BEAVER.UWASH.EDU or to host!host!host!uw-beaver!user.  So, having
a .UUCP domain does nothing for us.

What I propose is a distributed routing algorithm, loosely based on the
current UUCP Domain Spec. and the UUCP Mail Transmission Format Std.
and including a concept of a distributed name server.  Bascially, you
start with a mapping from domain style names to transport names,
similar to the way you currently map hostnames to Internet addresses.
In the strictly UUCP case, your table would contain the mapping from
domain name to uucp name, with a possible step to further specify the
uucp name using some sort of path finder (or you could store the actual
path in the database).  This is not much more complicated than the
current setup, and we will still allow directly routed paths in the
traditional uucp bang format.

Now, what happens when we come across a host that we have no data on?
Well, let's peruse RFC882 (Domain Names - Concepts and Facilities) for
some help.  Instead of having direct access to a name server, we must
rely on relatively static databases, but we can use the same concepts.
We can establish regional or corporate (for ATT, HP) centers which
would be responsible for keeping fairly accurate routing information,
and then specify MF (mail forwarders) or MD (mail destination) records
for at least the major top-level domains.  Then, if we have mail for
some unknown place, we should at least have a MF record in our database
and we can send the message to them for further processing.  They in
turn will guarantee us that they can either directly send the mail or
they will return it to us with an error.  In the case of Class 1 uucp
hosts, they may be two or more hops away from and authority, and so
won't get that kind of service.  Class 2 uucp hosts should be only one
hop away from an authority.  After sending the message, the authority
COULD send us a database update for the domain, if we requested it, so
that we could update our database.

I guess that what it boils down to is that the UUCP Doamin Spec is a
great Administrative concept, but it is not backed by enough
understanding of the Domain system, including the concepts in RFC 882
and 883.  If we don't do something to address the issue of name servers
and non-.UUCP domains, we will end up being even more cut off from the
Internet world than we are now.   I basically see the establishment of
a .UUCP domain as the beginning of true isolation from other networks
unless we really face up to the issue of a REAL domain implementation.
I would not be opposed to the use of .UUCP as a domain as long as I can
choose to be in the .COM domain if I decide that I prefer that one.
(I'm not saying that Fluke will actually choose that - we are nowhere
near that kind of decision yet).

I will post RFC882 and RFC883 to mod.sources so that we can discuss
issues in those documents.

/Joe Kelsey			John Fluke Mfg. Co., Inc.
				(206)356 5933