Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2.fluke 9/24/84; site icarus.fluke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!drutx!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!fluke!joe
From: joe@fluke.UUCP (Joe Kelsey)
Newsgroups: net.mail,net.mail.headers
Subject: Re: RFC920 domains vs. cow patties (flame)
Message-ID: <2323@icarus.fluke.UUCP>
Date: Wed, 12-Jun-85 19:37:27 EDT
Article-I.D.: icarus.2323
Posted: Wed Jun 12 19:37:27 1985
Date-Received: Sat, 15-Jun-85 06:25:00 EDT
References: <918@sdcsvax.UUCP>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 43
Xref: watmath net.mail:892 net.mail.headers:477

Joel -

You missed the most important idea behind the domain naming scheme.
That is, the major purpose of domain names is to (almost) completely
decouple the hostname from the transport mechanism.  The motivation
is mainly for mail, but it also extends to many other facilities when
you are talking about a fully connected Internet.  The current ARPA
Internet consists of the main backbone ARPA/MIL network of IMPs with
many local area networks directly or indirectly connected to ARPA/MIL
hosts.  In this environment, addressing a given host on a given connected
subnetwork either requires HUGE host tables (in order to maintain the flat
name space) or a change in the address/naming scheme.  The actual address
mechanism is sufficiently robust (Class A, B, and C netowrks), so the
naming scheme needs to be changed.  Basically, they are giving up a flat
name space, but maintaining what looks like HUGE local name tables through
(hopefully) user-transparent use of name servers/resolvers.  In order
to really understand the use of name servers/resolvers, I recommend that
you get a copy of RFC 882 and 883 (FTP from SRI-NIC) and study them n
conjunction with RFC920.

The exact same arguments about giving up flat name space to save on
routing table sizes applies almost directly to UUCP connections as they
exist today.  What we propose with whatever domain scheme come out is
to decouple the UUCP address (the current hostname) from the actual
site name.  This may seem like a difficult concept to grasp, but many
hosts already have to deal with having a hostname which is different from
their UUCP address.  After all, the physical address used to route in
UUCP bang paths is restricted to 6 globally unique characters, single
case, although special characters are technically allowed.  This is
almost completely user-unfriendly and non-intuitive when you consider the
number of hosts that are reachable via UUCP today.

I think that is important that anyone who is tempted to jump into the
domain discussion consider that what we really want is a way to name
hosts *independent* of their physical location or physical network
address, since both of these are volitile.  What we need is a user-intuitive
way of finding out host names, then a set up protocols to implement some
sort of limited distributed name server/resolver on the UUCP transport
mechanism.  This is possible, but an important step to take is to disconnect
your idea of hostname from physically restricting ideas, like geographic or
network addresses.

/Joe