Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!think!ames!ucbcad!ucbvax!H.CS.CMU.EDU!Rudy.Nedved
From: Rudy.Nedved@H.CS.CMU.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tcp/Ip vs a store & forward network
Message-ID: <1987.4.5.16.13.47.Rudy.Nedved@h.cs.cmu.edu>
Date: Sun, 5-Apr-87 11:21:15 EST
Article-I.D.: h.1987.4.5.16.13.47.Rudy.Nedved
Posted: Sun Apr  5 11:21:15 1987
Date-Received: Sun, 5-Apr-87 23:43:54 EST
References: <8704030246.AA02484@gwen.cs.purdue.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20
Approved: tcp-ip@sri-nic.arpa

The concept of distributing internal configuration information to everyone
in the world is too prone to failures from too much information. Assuming
that people will extensively use the domain system to publish current
routing information for mailboxes and dealing with cacheing and all the
other problems is expecting too much. The idea is a nice one alas a very
flawed one (from too much data).

The trick at this pont is to just get a reasonable mail relaying mechansim up
and to get rid of the host table. The MX records solve in a not so great way
the problem of mail relaying for hosts not on the connected network alas a
better algorithm has not been thought up that did not get shot down (heck, we
can not even get packet routing right...how do you expect to get mail routing
right?) Also many places are still using the host table mechanism and are
starting to suffer because of the size problems....alas they have received
temporary relief in the form of a 10% smaller NIC table.

Let us keep an eye toward the future but make that first couple of steps
instead of just dreaming about the future....

-Rudy