Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site noscvax.UUCP Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!noscvax!cunningh From: cunningh@noscvax.UUCP Newsgroups: net.mail Subject: Re: *uucp* addresses Message-ID: <275@noscvax.UUCP> Date: Sat, 19-Nov-83 14:19:26 EST Article-I.D.: noscvax.275 Posted: Sat Nov 19 14:19:26 1983 Date-Received: Tue, 22-Nov-83 01:43:41 EST References: <935@mit-eddie.UUCP>, <939@mit-eddie.UUCP> Organization: Naval Ocean Systems Center, San Diego Lines: 32 An extension of the idea of having tables in the ARPANET bridges would be to have path tables, and appropriate software to generate the full uucp address within the uucp (actually usenet) 'backbone' sites. >From the point of view of someone not at a backbone site, he or she would then only have to address messages as follows: !!! It would then be up to the backbone site to determine a (hopefully reasonably optimized) route to the final site, fill in that portion of the address, and then forward. This would require some reliable software, and routing tables within (only) the backbone sites. It might put too much of an extra computational burdon on the backbone sites, also. At non-backbone sites, I presume that 'preferred' backbone sites would be normally used. A backbone site handling too much traffic could complain to sending sites, and suggest an alternative backgone site to route to. This is similar, but certainly more informal, than the way ARPANET 'internet gateways' work. Unfortunately, if it becoms more convenient to routinely route all non-local uucp through backbone sites, those sites will certainly experience an increase in traffic. But, hopefully, there will be a measureable decrease in error messages. -- Bob Cunningham ..sdcsvax!noscvax!cunningh 21 17' 35" N 157 49' 38" W MILNET: cunningh@nosc-cc