Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!RMXJ%CORNELLA.BITNET@ucb-vax.ARPA
From: RMXJ%CORNELLA.BITNET@ucb-vax.ARPA
Newsgroups: net.mail.headers
Subject: (copy) Re: .EDU problems in Bitnet
Message-ID: <3275@brl-tgr.ARPA>
Date: Fri, 15-Nov-85 14:52:07 EST
Article-I.D.: brl-tgr.3275
Posted: Fri Nov 15 14:52:07 1985
Date-Received: Sun, 17-Nov-85 06:29:21 EST
Sender: news@brl-tgr.ARPA
Lines: 63

Originally sent from: RMXJ@CORNELLA.BITNET
Originally sent to: RMXJ@CORNELLA

This message is from Ken Rossman at Columbia: SY.KEN @ CU20B. BITNET
What some of the folks arguing against our new naming convention fail to
realize is that the domain style name has nothing specifically to do with:

 a) Specific networks.
 b) TCP/IP or ARPAnet.

Specific networks in domain names:

The network name does not necessarily need to be somewhere within the name,
and in most cases, isn't.  Many hosts are also on several networks, for
example (like CU20B or COLUMBIA), so how could it make sense to stick a
network name somewhere in the domain name for the host?  This would have to
mean that such hosts would have to have different names for different
networks, while the domain naming concept was created for exactly the
opposite reason -- so that every host, no matter what network or networks
it was on, could have ONE name which described it (the name should describe
the administrative domain within which it resides, not (necessarily) the
network domain).

Network protocols:

Here again, even though early on, domain names had .ARPA tacked onto them,
they no longer will have them.  The highest level domains are names like
EDU (the research/educational segment of the Internet), MIL (the military
segment), and COM (commercial).  So even though we use domain style names
for both our Internet and non Internet systems, it shouldn't matter, and
the NIC host tables (which are disappearing sometime soon anyway!) don't
need to know about some of these (and shouldn't).

So, once the smoke clears, the name is neither related to the protocol nor
the network, and the answer as to how one picks the return network path
does not lie in parsing the name.  Apparently, until recently, many BITnet
sites would assume that if a domain style name was used, it should go back
through the Wisconsin Internet gateway, and of course, this worked for most
cases up to now.  Since the face of networks and network names is changing
rapidly now (and NOT just here at CU either!), BITnet folks are just going
to have to figure a different way out of the dilemma.  The recoommended way
to do this, of course, is through the use of a name server.  However, since
these don't exist widely yet, the next best thing I can think of is to
stick aliases into your host tables, with the older short-form BITnet host
names as the official names.  These should still work in the reverse
direction, since they are still used as aliases on this side.

As for being reluctant to send mail from here to BITnet with alternate
names in the mail headers, this would mean major hacks to our mail system
software, which naturally I am rather reluctant to do (not even having
enough time to do the other things I should already be doing here).  Also,
folks on BITnet might as well get used to having to deal with the domain
style names, as more and more hosts are using them, and they are becoming
the standard on more than a few networks.  Additionally, it is a bad idea
to change the contents of mail headers or text while in transit through,
say, a DECnet-BITnet gateway.

Remember, we didn't cook up the concept of the domain name -- the folks
writing the RFC's did.  As far as I can tell, we're going by the rules.

Please feel free to redistribute this to other interested parties, and I
welcome further debate on the matter.  /Ken
-------