Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site sdcrdcf.UUCP Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!decvax!tektronix!hplabs!sdcrdcf!lwall From: lwall@sdcrdcf.UUCP (Larry Wall) Newsgroups: net.mail Subject: Re: Will it ever work? Message-ID: <2230@sdcrdcf.UUCP> Date: Tue, 6-Aug-85 15:38:18 EDT Article-I.D.: sdcrdcf.2230 Posted: Tue Aug 6 15:38:18 1985 Date-Received: Mon, 12-Aug-85 21:13:53 EDT References: <47300002@hpfclo.UUCP> Reply-To: lwall@sdcrdcf.UUCP (Larry Wall) Organization: System Development Corp. R+D, Santa Monica Lines: 103 (This is also a reply to the fourth article from Robert Elz on routing.) In article <47300002@hpfclo.UUCP> jad@hpfcla.UUCP (jad) writes: > Perhaps the UUCP domain [may I say domain here?] needs some kind > of central authority. First, is this at all feasable? We won't > ever see all the machines owned and operated by the same entity, > so there has to be some kind of coordination!! Domains do offer > this coordination, if done properly... the question is how do we > get everyone to agree to move? Or better yet, CAN IT BE DONE??? Obviously we can't force everyone to change their software without starting a civil war. The real question is, can we change just some of the systems and reap any benefit from doing so? Robert Elz has pointed out that there are three possible schemes: 1) attributes 2) domains 3) explicit routing He rejects 3 on the basis that it doesn't work well. Which is perfectly true, as we have been finding out by experience. Nevertheless, since 3 is what we currently do, those sites which do not upgrade their software will continue to do 3. Robert Elz mentioned a couple of kinds of site, which I would like to define as follows: smart knows about addresses; knows about routes dumb knows about addresses; doesn't know about routes To this we must add: enlightened knows about addresses (either smart or dumb) really-dumb doesn't know about addresses; doesn't know about routes pseudo-smart doesn't know about addresses; thinks it knows about routes We assume that all machines, including really-dumb ones, can forward messages to their neighbors. (Note that the prototypical uucp machine is really-dumb (no insult intended).) We also assume that everyone knows that not everyone can afford a smart machine, and the dumb machines are to be treated as civilized citizens. Now, suppose for a moment that we have a network of only smart and dumb machines (no really-dumb or psuedo-smart ones). The dumb machines have no problem--they just forward unrecognized addresses to smarter machines. The smart machines have the problem of what to do with a route once they've determined it. How do they get the message to actually follow the route they've determined? There has to be some way for the smarter machine to tell the dumber machine "Hey, I know where you ought to send this, so don't try to be either smart or dumb, just do thus-and-so." (I leave it as an open question whether a machine ought to be allowed decide it's smarter than the previous smart machine and modify the route given to it.) Even with this idealized setup, we need to differentiate the address from from the route. The idea is that the address is immutable, while the routing information may be incomplete, or not even exist yet. It is the job of smarter hosts to suggest a better (not necessarily best) route. Hopefully, whenever a route gets used up, you're someplace that can extend the route in the proper direction, based on the immutable address. (I.e., you're at a smarter machine, or the destination.) Now, back to the real world. Adding in really-dumb machines basically changes nothing, under three conditions: 1) You can specify the route to them such that they can forward to their neighbor. 2) You can pass the remaining part of the suggested route through them to the next site. 3) You can pass the (immutable) address through as well. I believe that most vanilla uucp sites can do all of this, as long as we keep the distinction between address and route. The big difficulty, as I see it, is that lots of people have been trying to smush both ideas into one header line, and it won't work. True, RFC whatever says that you can put both a route and an address into one header line via the baroque @host1,@host2... syntax. But you can't--and get this--you can't use that format to communicate the suggested route to a really-dumb machine that only knows bang notation. In order for smart and really-dumb machines to coexist, the smart machine must know more than the suggested route--it must also know how to communicate that route to (and through) the really-dumb machine. It must also know how to communicate the route with dumb and smart machines. A good question is whether there is a common way to specify routes to both enlightened machines, and really-dumb machines. It would certainly help if they could use the same form of routing, but my gut feeling is that the answer is "no go". If so, then smart systems will have to keep a database on how to fool their neighbors into doing the right thing, AND on how to get them to pass the correct information to the site after them, and the site after that, etc. There is one more wrench in the works: the pseudo-smart machine. This is a machine that does route optimization in an obsolete fashion. It may be that there is NO way to hand such a machine a suggested route, and know that it's going to do it correctly. I doubt there's a complete technological solution to this, but it may be possible to get most such machines to do the right thing by giving them an abbreviated route, something they can't easily foul up, and having a way to pass the real route through (transparently to the pseudo-smart machine) to an enlightened machine on the other side. Larry Wall {allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall