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