kre@ucbvax.ARPA (Robert Elz) (08/03/85)
Now we come to the sensitive area of routing. I would expect that most people can simply hit the 'n' key now, as routing simply doesn't matter at all (or shouldn't) to the average user. Mail is given an address, and posted. Sometime later it arrives at the address. Where its been in the meantime (in ordinary circumstances) simply doesn't matter at all. So, from here on, I'm going to assume that those of you who are left are mail/network implementors or administrators, who do sometimes need to know about routing and such. The first thing to notice, is that apart from the explicit routing semantics, the semantics (in each of the cases) simply specify the destination host. They provide *NO* information on how to get there. In particular, using a!b!c syntax for Peter Honeyman's attribute style addressing does not imply (necessarily) any routing at all. So, if there were two "down"'s, so Peter's address became "princeton!down!honey" this does *not* mean that mail to Peter is sent to "princeton" which then sends it to "down" which then delivers it. Of course, it might go that way, but that would be a coincidence. The "princeton" in the address is an attribute of "down", it indicates which of the two (assumed) "down"'s is the one that the mail is to get to. Similarly, in a domain type address, "kre@monet.berkeley.edu" does not mean to "send mail to edu, which sends it to berkeley, which sends it to monet", nor does it necessarily imply any other form of routing. We must consider two types of hosts, "dumb" ones, and "smart" ones (not forgetting that few hosts will actually sit at the extremes, most will be at an intermediate point somewhere). For any addressing semantics/syntax combination we choose, a truly "smart" host will have a complete list of every host that can be addressed, and all of the interconnections between them, plus as much other information as can usefully be used (delay and throughput on the links, costs, restrictions on paths that are legal, etc). From that it can then deduce an "optimal" route for the mail, using whatever definition of "optimal" happens to be the current vogue. A truly "dumb" host knows none of this, in the extreme case, all it knows is one other host to which it sends any mail not addressed to itself. In slightly less limited cases, it may know a small set of possible neighbours, and fixed routes to some hosts that can handle particularly tricky mail (anything not addressed to the originating host or one of its neighbours). The decision about which host to send to in such a case may even be made based upon what the final "domain" in the address is, or the value of one of the "attributes" in the address. In these cases it may appear to some people that the address is in some way a "route", but this is really simply nonsense. What's more, it doesn't matter if *every* host implements routing this way, the address is still *not* a route. One would hope that the mail would be continually passed to successively smarter hosts, until it reaches one smart enough to be able to plot a route to the destination. I don't know that much more need be said about routing, its an internal issue. It can be changed whenever the administrators want to change it, and for whatever reason they desire. All that's needed is that the mail system provide the address of the destination, and that some database (of whatever size is appropriate) is available to calculate the routes from. One thing to particularly note, is that in none of the semantic schemes is there (necessarily) a "central host" through which all mail passes. There may be such a host in any of the schemes. Everything depends on how the network is set up, and nothing stops one scheme being transformed into another with no notice.
jer@peora.UUCP (J. Eric Roskos) (08/05/85)
While this was an excellent (albeit long) discussion of the difference between syntax and semantics, illustrated in terms of the current debate, there is one point I must differ strongly with. > In these cases it may appear to some people that the address is in > some way a "route", but this is really simply nonsense. What's more, > it doesn't matter if *every* host implements routing this way, the > address is still *not* a route. One would hope that the mail would be > continually passed to successively smarter hosts, until it reaches one > smart enough to be able to plot a route to the destination. (You might expect that I would disagree with this, since this little Berkeleyism references implicitly one of my previous postings.) The problem here is that at some point you have to make a crossing from the pure naming-property of the domain naming scheme -- which, I suspect, is identical to the "attribute" naming scheme except inasmuch as the registration mechanism places a guarantee of essentially permanent uniqueness on a name chosen by the domain scheme, which is the real heart of the matter -- to the difficult task of generating a route from it. Now, Mr. Elz has argued quite successfully that any arbitrary name string is not a route. In fact, the optimizing mail routers demonstrate that even the 90-character-long site names generated by the non-INTERNET-mode Usenet software are not routes. When you interpret any arbitrary name string as "the name of the site" rather than "the way to get there," then you indeed do not have a route. But the moment that you say "I don't know how to get to sites with the subdomain A, so I will send it to a smarter host who does," the address does indeed become a route. It is a partial route, not a complete route, but the fact that you say "I don't know who taeoum.ASP.UUCP is, so I must send it to a smarter host... THIS smarter host: abc", you've done two things. First, the string taeoum.ASP.UUCP has been shown to be meaningless by you. It is NOT a name; it is a string. You don't know what taeoum.ASP.UUCP is, so you can't even say if something with a name matching that string even exists. (You can read Bertrand Russell's essays on the philosophy of mathematics and get into all kinds of side issues related to this, in fact.) Furthermore, you can't say taeoum.ASP.UUCP is the "name" of the smarter host abc, because clearly it's not. All taeoum.ASP.UUCP is, for you, is a "way to get there": a string specifying the manner in which you can go about (attempting to) deliver the message. As such, the string is a partial route. In fact, however, in saying the above, I have simply advanced a definition of "route," and argued that for a not-fully-smart host, some valid strings are not names. I have done this for a reason, though. I feel that in the UUCP network, routing is an important issue. I presently feel that the semantics imposed on the names chosen for UUCP sites should give sufficient semantic information to accomplish (at least partial) routing. By example, I will point out the arguments that "if someone's name is joe@ucbvax.berkeley.edu, how do you know how to get the mail to him, if ucbvax.berkeley.edu can be on more than one network?" which a few people have briefly alluded to in the recent past. Extending this example, at present, in my "it's not Berkeley" mail handler, I treat the string .EDU as meaning "it's on the ARPAnet," and I treat the string .UUCP as meaning "it's on the UUCP net," and route accordingly. I.e., I make the decision of "the way to get it there" based on a syntactically well-defined part of the name string. The reason for this is that putting some routing semantics into the name simplifies the routing. If the domain-name is merely a string, devoid of routing semantics, then SOME site, somewhere, may know how to get to the named site, but I have no way of finding out what site that is. I have to either be an omniscient nameserver, or send all my mail to one, because I can't do any better. But if the domain-name contains routing information, in the form I've described above, I CAN do better. I can send the message on to a site who knows how to get to the hosts with subdomain ASP, in my example, and this site does not have to be omniscient -- far from it. The work of routing is thereby distributed. These issues of semantics are, I think, at the heart of the current debates. I certainly agree wholeheartedly with Mr. Elz's statements (aside from those which claim some things are not worth considering, since their existence suggests that they ARE worth considering, rather than dismissing in this manner*; and the one I questioned above), but then I also agree with Mr. Honeyman and several of the others, as well. I think the semantics are what need to be clarified, and this needs to be done in a very practical way. In doing so, you have to be careful that, while keeping the pure theory firmly in mind, you don't so abstract yourself from the reality of the task at hand that you make it work less well thereby. *(This is what I meant by "little Berkeleyism," incidentally, lest you take offense at the wrong thing.) -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Frr ubj Tbq jvgu uvf yvtugavat nyjnlf fzvgrf gur ovttre navznyf, naq jvyy abg fhssre gurz gb jnk vafbyrag; juvyr gurfr bs n yrffre ohyx punsr uvz abg." -- Negnonavf