honey@down.FUN (Peter Honeyman) (09/14/85)
i see that lauren resolves .UUCP (and *default*!) to ihnp4. let's all do that and see how long we get away with it. after all, when gary leaves indian hill, no one will be minding the store. peter
lauren@vortex.UUCP (Lauren Weinstein) (09/15/85)
Ha ha. Actually, that was for example purposes only. Couldn't think of a better example at the time. In practice, I have lots of locally known "good" routes that avoid sending things down the default paths in 99% of the cases. As a sidenote, Gary deserves a vote of appreciation for everything he's done at ihnp4. When he leaves, we may find out how much we've taken ihnp4 for granted. --Lauren--
lauren@vortex.UUCP (Lauren Weinstein) (10/10/85)
I was hesitating about entering this current fray, but I guess I'd better.
There are indications that demand for UULINK is quite high, and there's
the possibility that there could be a lot of nodes running it
in some not-too-long period of time. As such, the manner in which
I handle domain support inside the package may be of some
interest, since there are going to be a lot of nodes out there using it.
(Note: UULINK is my MSDOS uucp/mail/basic netnews package which is starting
to go out now).
Basically, I took the class-3 (complex) site description and implemented
the basic functionality to make it work. Both User@Site.Domain and
...!Site.Domain!User syntax is supported, so all of the compatibility
issues do work. I went to great pains to come up with something that
would work both when talking to dumb sites that will never change
their software and to smart sites. I also handle both left-right and
right-left address parsing issues, but I won't go into the details
of that here. The basic functionality of my domain handling is
based on a single file, which can be small or large as desired.
A fragment from a sample file looks like this:
cbpravo.cbosgd.UUCP cbosgd 3
cbosgd.ATT.UUCP cbosgd 3
ATT.UUCP cbosgd 3
allegra.UUCP allegra 1
ihnp4.UUCP ihnp4 3
ism780.UUCP ism780 1
bellcore.UUCP bellcore 1
trwspp.UUCP trwspp 1
research.UUCP ihnp4!research 1
sdcrdcf.UUCP randvax!sdcrdcf 1
psivax.UUCP randvax!sdcrdcf!psivax 1
.UUCP ihnp4 3
.ARPA ihnp4!ucbvax 2
.GOV ihnp4!ucbvax 2
.COM ihnp4!ucbvax 2
.BITNET ihnp4!ucbvax 2
*default* ihnp4 3
This table provides all of the routing requirements for a small site
with a "few" outside connections. It includes full routing information
for sites where full routing is known to be best (where full may
mean a multi-hop path--it does not necessarily imply a one-hop path, just
that the path is fully qualified to some point), and provides for
routing to "smarter" sites for domains and/or subdomains where
we don't have enough information for full routing. It also
handles the real-world situation of smart and dumb hosts. The
number in the third field specifies the "smartness" of the final
host in the path. 3 is smartest, we can drop full domain addresses
right in its lap. 2 is dumber, and 1 is "dumbest" yet. There are also
a variety of alphabetic options that can be further used to control
the manner in which addressing information is passed along, in modes
that range from very smart to very simple.
The point of this is that it WORKS. My Beta sites have been using
it to route User@Site.Domain addresses through the existing network
and through other sites running my code. My own code falls into
class 3 (smart) so even the lowly PC's can handle the domain
addresses even with limited resources. The routing table can be as
complete or simple as the individual site wishes, depending on how
much you want to (or can) push off onto other sites with more
complete tables.
Note that the word "dumb" in this case says nothing about the
intelligence of the system administrators at a site, it only
refers to the ability of a site to handle domain addresses
in various forms!
One of the advantages of this system is that it requires very little
(if any) cooperation from other hosts, since it will happily route
through dumb hosts as well as smart ones. I don't put it forth as
THE solution to the routing problems, but I mention it as a
solution that I've found to work well in my MSDOS package.
--Lauren--
{ihnp4, decvax, seismo, clyde, trwrb}!vortex!laurenadams@calma.uucp (Robert Adams) (10/16/85)
> > cbpravo.cbosgd.UUCP cbosgd 3 .... > .BITNET ihnp4!ucbvax 2 > *default* ihnp4 3 ... > It also > handles the real-world situation of smart and dumb hosts. The > number in the third field specifies the "smartness" of the final > host in the path. 3 is smartest, we can drop full domain addresses > right in its lap. 2 is dumber, and 1 is "dumbest" yet. ... > --Lauren-- The idea of rating a site by it "smartness" is a great idea. I have had problems sending mail because I didn't realize there was a site in the path that was going to mangle addresses in the header. I always figured that a new field should be added to the uucp map wherein a site could specify its "smartness": "I only do bang addresses" or "I know about .ARPA addresses", or "I map bang addresses into Internet addresses and then reroute them". Sites could even say "I know about the .XYZ domain" so, as long as "domains" made sure they had enough links (all non-centralized, of course) you could do domain like addressing. With information like this, one could figure out (or at least make a better guess) at the address to ship mail too. adams@calma.UUCP -- Robert Adams or ...!{ucbvax,sun}!calma!adams
chris@minnie.UUCP (Chris Grevstad) (10/19/85)
adams@calma.uucp (Robert Adams) says: >> (Lauren's examples and comments about 'smart' ratings > >The idea of rating a site by it "smartness" is a great idea. I >have had problems sending mail because I didn't realize there >was a site in the path that was going to mangle addresses in the >header. Mark Horton suggested that solution way back in January in a paper entitled _UUCP Mail Transmission Format Standard_. He had three classes of hosts, each understanding a greater range of addressing modes. The dumbest being one that only understood complete bang paths and the smartest understanding bang format and domain format addresses. > .... I always figured that a new field should be added to >the uucp map wherein a site could specify its "smartness": "I only >do bang addresses" or "I know about .ARPA addresses", or "I map >bang addresses into Internet addresses and then reroute them". >Sites could even say "I know about the .XYZ domain" so, as long >as "domains" made sure they had enough links (all non-centralized, >of course) you could do domain like addressing. >With information like this, one could figure out (or at least >make a better guess) at the address to ship mail too. > This would be very good information for the mailers that could utilize it. It's unfortunate that we can't have some sort of dynamic (more than on a monthly basis) routing information available. One other comment: I agree with Lauren when he states (paraphrased) that the important issue is that of user convenience and utility. All of the magic should take place inside and present to the user a simple interface. I would love to be able to type 'mail lauren@vortex.So-Ca.UUCP' and not have to worry about the routing. My mailer should be able to determine a route from routing tables or should be able to pass it off to a more knowledgeable neighbor, like Lauren's default ihnp4. If the user wants to specify a path, then the 'site1,site2,site3:lauren@vortex' syntax is available. The mailer can then determine if the smartness of site1 and either pass the same address off to him or convert the above address into a uucp route. C'mon guys, let's try and make it easier for the users. BTW, we will soon have a mailer as described above available for beta testing if anyone is interested. -- Chris Grevstad {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!chris ucbvax!calma!nrcvax!chris ihnp4!nrcvax!chris If things don't change, they will probably remain the same.