mark (10/25/82)
I've been thinking about the UUCP mail problem for the last few weeks, especially in light of the comment that each level of the heirarchy is just a registry. I have become convinced that there must be a provision to heirarchically subdivide UUCP into manageable pieces. There are nearly 1000 known UUCP sites, and probably at least 1500 total UUCP sites. It's not going to be practical to have a complete database all over the net, and if we do, it will be out of date most of the time. Also, organizations will want to set up their own registries. With this in mind, I propose the following: Addresses look like user@domain, in accordance with the internet standard. domain will end in ".uucp" to indicate the UUCP network. (This is necessary to make the rest of the world able to reach us.) The second level will be the name of the organization. Additional levels will be optional and up to the organization to establish. The lowest level will be the particular machine. Thus, my address might be mark@cbosgd.btl.uucp where "btl" (Bell Telephone Labs) is the organization and "cbosgd" is the machine the mail goes to. BTL would be able to set up subdomains as they wish, provided they conform to the syntax, thus: mark@d.osg.cb.btl.uucp would be one (somewhat wordy) possibility, and another one would be m.horton@btl.uucp where the "btl" registry would be able to look up a person's name and translate it into the machine address. An organization (this could mean a company, a university, or even another network, such as BITNET, although there might be a convincing argument to get BITNET its own top level billing) having more than one machine would typically have a domain address such as "site.org.uucp". An organization with only one machine would simply be "site.uucp", and the organization would be encouraged to choose a machine name that is the same as their organization (within the UUCP restriction that the first seven characters must be unique). The routing algorithm would be controlled by sendmail, but basically it would send the message to the lowest level machine that is locally recognized. Each large organization (e.g. at least 2 machines) would have one or more "gateway" machines that all mail destined for that organization could be sent through. Thus, if my address were mark@cbosgd.btl.uucp, and someone sent me mail from a site that did not recognize cbosgd, it could send it to a "btl" machine (probably an alias for "owl", a likely gateway), which would look up cbosgd and forward the message to this machine. Each machine on UUCP would need only either (1) the directory of all top level machines and how to get to them, or (2) the name of a machine that does have all the top level machines, in which case all mail is forwarded to that machine. Note that there is nothing to force routing over these links. This kind of routing is merely available as a fall-back in case nothing more sophisticated is available. In practice, each site would probably augment the table of top level names with a local table of names that can be conveniently reached locally, so that local mail would go over the most efficient route. (Here, "local" means not only a link that connects two machines in the same organization, but also a link that is intended for the private use of the two organizations it connects, for example, a dialup link being paid for with real money from a budget that is feeling a squeeze.) There would be some conversion issues. I propose that initially, all 900 machines on UUCP be considered at the "top level" (under "UUCP"), and that as sites organize their gateways, sites will be gradually moved underneath their organization name. Thus, initially I would be mark@cbosgd.uucp, and this would change to mark@cbosgd.btl.uucp when the "btl" machine (or machines) are ready to go. Since BTL appears to account for about half the machines on UUCP, the size of the top level would decline substantially right away. The advantages to this scheme are many. It's easy to remember who the person you're sending mail to works for, but often you have to look up their area code, time zone, or even state. It makes use of our existing network without having to resort to geographically based algorithms (get it to Colorado, then let Colorado get it to the site.) It is not sensitive to the various strange links that always seem to exist. It is extensible by each group without needing permission from the rest of the net. It allows each group to maintain their own registry. And it fits in with the intent of the ARPA internet standard. Comments? Mark Horton
rah (10/25/82)
Mark's suggestion perpetuates what seems to me to be a flaw in the addressing scheme. Specifically, it seems that the transport mechanism i.e. UUCP, is specified, rather than the real information, which is that he is at Bell Labs. What if there was also a way to send mail to Mark via the ARPANET, ie. his address there might be something like mark@cbosgd.arpa or mark@cbosgd.btl.arpa . What if someone on wanted to send mail to Mark and addressed it as mark@cbosgd.btl.uucp but their machine didn't have any knowledge of how to send mail via uucp, but was on the ARPANET? Would it transform the address to mark@cbosgd.btl.arpa? Or would it waste the time and money to send it to some other machine on the ARPANET which knew about uucp and would then call the btl distribution machine to forward the mail via uucp to cbosgd? It seems to me that danger is that the "uucp" part of the address will be taken to specify a particular transport mechanism when it really is just a means of specifying a subset of the machines for addressing. I don't think we should use the names of transport mechanisms as domain names, but should pick domain names which are meaningful to humans as domains. Thus Mark's address should always be markhorton@btl and the mail routing system should have enough sense to figure out whether to send the mail over the arpanet, uucp, or some other link. Rich Hammond, npoiv!rah (BTL Neptune, NJ)
mark (10/25/82)
Re: Rich Hammond's comments: Mark's suggestion perpetuates what seems to me to be a flaw in the addressing scheme. Specifically, it seems that the transport mechanism i.e. UUCP, is specified, rather than the real information, which is that he is at Bell Labs. What if there was also a way to send mail to Mark via the ARPANET, ie. his address there might be something like mark@cbosgd.arpa or mark@cbosgd.btl.arpa . There is no reason btl couldn't also appear in the "arpa" domain, if ARPA were willing to add us. (In practice, they probably would add us only if we were to get a BTL machine on the ARPANET at some future date.) What if someone on wanted to send mail to Mark and addressed it as mark@cbosgd.btl.uucp but their machine didn't have any knowledge of how to send mail via uucp, but was on the ARPANET? If a mailer gets an address in a domain it isn't part of (this is a very common case) it asks a name server who is the gateway for that domain (e.g. some name server on the arpanet would tell it that the gateway for "uucp" is, say, arpanet host "Berkeley") and it forwards the mail to that host. Would it transform the address to mark@cbosgd.btl.arpa? Only if it knew that btl.arpa was the same as btl.uucp, which it might be configured to know. Or would it waste the time and money to send it to some other machine on the ARPANET which knew about uucp and would then call the btl distribution machine to forward the mail via uucp to cbosgd? Seems to me this isn't a waste of anything if that's the only way to get mail from their machine to cbosgd (which it probably would be). This is the fall-back case that happens when it doesn't have any better information. It's also probably the most common case when the mail must go from one network to another. It seems to me that danger is that the "uucp" part of the address will be taken to specify a particular transport mechanism when it really is just a means of specifying a subset of the machines for addressing. I don't think we should use the names of transport mechanisms as domain names, but should pick domain names which are meaningful to humans as domains. Thus Mark's address should always be markhorton@btl and the mail routing system should have enough sense to figure out whether to send the mail over the arpanet, uucp, or some other link. The name "uucp" denotes a registry of sites, and also denotes a particular transport mechanism. We could name our domain something besides "uucp", for example, CSNET is naming a component of their net "Phonenet", but it seems to me the obvious name for our registry is "uucp". In fact, the whole point of this registry is to enable the sites on UUCP to get mail from the other networks and each other. So the mechanism almost always WILL be uucp. If you're going to give my address as mark.horton@btl, this implies that "btl" has to be a top level name, known to all name servers and all registries. Since BTL is so large, we might be able to pursuade the rest of the world to give us a top level name. (But I'm skeptical - we don't even have an ARPANET link ourselves.) However, It's pretty farfetched to picture every single organization on UUCP (there are at least a few hundred of them) having a top level entry. The top level is specifically intended to have only a few entries. Organizations on the ARPANET are all bundled under the top level "arpa" entry - why would they give us better service than they give themselves? Also, can you picture the updating problems: every time a new org is added, every machine in the world that knows all the top level names has to be updated. A heirarchy is certainly needed. Mark
tihor (10/26/82)
#R:cbosgd:-274300:cmcl2:14900002:000:899 cmcl2!tihor Oct 25 19:12:00 1982 While Rich Hammond's point that the transpotr mechanism is not a nice top level domain because of the problems of multi-hosted sites (machines on more than one network) is a reasonable one, the use of the domain .UUCP is necessary to permit comunication with the ARPAnet without an additional level of header munging to convert into/outof ARPAnet mail format. In fact an organization could try to register as a top level domain with the Internet NIC (Network Information Center). As yet, there is no announced policy on who can be a top level domain. Certainly we at NYU will try to register if possible. Hopefully BTL would as well. Basically though the .UUCP suffix is the simplest way to avoid problems. This issue has been hashed over at some length in MSGGROUP and Header-People and one should check those ARPAnet lists' archives for the pro and con which was not gatewayed onto Usenet.
jerry (10/26/82)
I support Mark's proposal but I have a counter proposal for the name of the domain. I suggest "usenet" instead of "uucp". As has been suggested "uucp" has too much the flavor of a particular transport mechanism. "usenet" is already a network. Also I expect that netnews will eventually be the mechanism by which gateway machines maintain configuration files. A possible objection is that "usenet" already means full participant in netnews and some machines may be reachable that are not on "usenet" as currently defined. My response is: this is less confusing than the use of "uucp". Jerry Schwarz harpo!eagle!jerry
jwp (10/27/82)
I vote yes. John Pierce, Chemistry, UC San Diego ucbvax!sdscvax!sdchema
bstempleton (10/27/82)
Well, most of what Mark says is correct, but there are a few comments: 1) There is absolutely NO need to limit names of domains and hosts to 7 characters as is currently done with uucp. In an internet scheme, all host names must go through a decoder, and so we can build our decoders with no limit. They might have to map to uucp IF uucp is the transfer mode used for the mail. The mode might be Berknet or phonenet or arpanet or whatever. This should be invisible, of course. For some time, uucp names will coorespond to mail address names, but there is no reason for them to do so. 2) As Eric Allman pointed out to me, user@domain is a name, not a path. Thus our programs should be able to use this idea. Normally, to avoid overcomplication, user@host.domain will be a path, stating go to "domain" and it will know the way to "host". It turns out however, that we want an algorithm that can be smart. Thus of we get "horton@d.sg.cbo.btl.uucp" as an address, we will look up in our database the string: "d.sg.cbo.btl.uucp". If we find it, great, we know a direct path along some net to that machine. For example, we might call it directly via uucp. In this case, no need to send to any other machine. If we don't find it we strip off the lowest end and look for: "sg.cbo.btl.uucp". We may find it and let it worry about "d" or we may have to keep looking. Eventually, we'll come to "uucp" which being a top level domain we will definitely find in our database. Since we're a really dumb machine, we didn't find "btl.uucp" so the entry for "uucp" will be the address of a machine, perhaps ucbvax, which we do talk to and we figure knows how to figure out what we don't. Thus some machine must be sure it knows all domains in the uucp domain but that is not that hard. With the above scheme, we take advantage of all private paths so that the net is not wasted, and we only have to put our private paths into the database assuming the rest of the net handles these addresses. By the way, the entry in the database for such strings should probably consist of a mailer code and any argument parsing strings. For example, assuming you have a uucp direct connection to cbosgd your entry for "d.sg.cbo.btl.uucp" might be "uux - cbosgd!rmail %s", or if you didn't have a direct connect "uux - decvax!rmail cbosg!cbosgd!%s" which assumes decvax doesn't have an internet mailer itself and you talk to decvax. The nice thing about this scheme is that you can put in sites as you need them with whatever form of link you like. It is possible that the above database can even be maintained by automatic means from the L.sys on a pure uucp site. 3) There will probably be several "btl" machines around, just as there will be several such machines for other organizations. This will mean that then entry in "btl.uucp" will actually point to the closest of the known btl sites.
bstempleton (10/28/82)
As a further comment, I agree that the name "uucp" is incorrect for the domain we are in. Many of the machines in this domain are connected together by thinks like Berknet and others. More nets are coming all the time. At Waterloo, we even have a machine on the net that is a GCOS machine (Honeywell) and the link between it and our vaxen is certainly not uucp. I implemented this with the ! syntax so it would look like just another site on what used to be the uucp net. This means that even a name like the "unix" net is incorrect. Domains appear to be named by organizations, and the upper level domains can be named by the organizations that control them. For "arpa", for example, this is clear. The only thing you can say about this net is that it consists of private machines - ie. operated indpendently by private companies and institutions. Thus names like "private" or "misc" come to mind. But if we're going to do this, why not give it a geographical name, namely "na" for North America. Even better, give it two names (I assume this is possible), namely "North_America" and "na" the abreviation. Since there are machines in England and Australia on the net connected via really long haul uucp, we should give them domains "Australia" and "UK" or whatever. I would vote for those being top level domains, since they are whole nations and do sort of rate this. Down with the name UUCP!
mark (10/30/82)
I agree with Brad Templeton. Since we MUST build in a "nickname" mechanism, which UUCP lacks, so that we can have more than one name for the same site, there is no reason why the "official" name for a site can't be arbitrarily long, so long as the name it maps into for UUCP purposes is unique in the first 7 characters. For those of you who are worried about incredibly long host names, look at the ARPANET. They don't have any limit, and names seldom get longer than MITRE-BEDFORD. (They are also usually upper case, but that's their problem. The standard does say that case has to be ignored in host names, although, because of Multics, it's significant to the left of the @ sign.) There are also usually shorter nicknames for lazy people to type, e.g. USC-ISIB is also known as ISIB. The table containing such things as "uux - foovax!rmail user" is precisely what sendmail does, although it's parameterized so that you don't have to add one of these things for every site. So I think we're beginning to agree on the basic organization here. The one question that remains to be settled appears to be "what do we call ourselves?" (If there is disagreement on other issues, please speak up.) So far I've seen "UUCP", "USENET", "NORTH-AMERICA", and "NA", "PUBLIC", and "MISC". Let me state my opinions and I encourage others out there to speak up with theirs. Personally, I favor UUCP. One problem with UUCP is that some sites that would be in the UUCP domain simply do not run UUCP. I'm thinking of places like Fluke and UCSD, which are accessable only via UUCP, but in fact have a Berknet (or some other LAN) and thus many sites aren't directly on UUCP. This argument could be applied to some other places, such as Berkeley, Purdue, and Wisconsin, but in each case, these places have an ARPANET link and probably consider themselves primarily in the ARPANET domain. Thus, a site at Purdue might be PA.ECN.PURDUE.ARPA, but this site is not directly on the ARPANET. It's not quite the same, because these sites probably speak TCP/IP and are for all practical purposes on the ARPANET. But I think the intent is that they are "part of the ARPA internet community". Another problem with the UUCP name is that we may be stuck with it for 20 years, even when we're all running something better than UUCP (like smoke signals). The problem with USENET as a name is that it would even further confuse people that already think USENET and UUCP are the same network. It's also not strictly correct, since we want to include all sites running UUCP in the registry, even those who don't get news. This would, in turn, force us to come up with a new name for the network of sites getting news, and that's been debated before and turned down. The converse problem, sites that are on some other net, like the ARPANET, isn't really a big problem because there's no reason these sites can't appear in both registries. Unless, of course, hundreds of non-UUCP sites start getting news, in which case it will become unmanageable. I don't find PUBLIC or MISC appealing at all. These are both generic terms, and we are a specific network. Telenet is public too. NORTH-AMERICA or NA for those of us too lazy to type it is an interesting idea. There appear to be real barriers across the Atlantic which are difficult to traverse. There are European sites trying to get news now, but they are having severe phone problems (the connection is too noisy). Money should be an issue but doesn't seem to be. There is a UUCP link from decvax to mcvax in the Netherlands, and from mhtsa to some site in Austrialia. These links seem to be weak, costly, flakey, and unique. But it's hard to predict what will happen in the future - we certainly can't send much mail over these links, although right now all mail has to go over them. The main problem I see with this name is that it's awfully presumptuous of us. We are only one network in North America, certainly not THE network. We don't want to encourage people to route all their mail through our network. Also, the abbreviation NA is not very appealing, and the full spelling is awfully long. Another alternative is to invent yet another catchy name. I should warn that the domain name "UUCP" is beginning to gather momentum. It's now present in at least two pieces of software and is beginning to be used. It can still be changed, but not for long. For this reason, I suggest that we set a deadline of November 30, 1982, to decide what we're going to do. Hopefully even sooner. We are also running against the ARPA deadline of January 1, 1983. On that date, the ARPANET will switch over to TCP/IP and internet addressing. So we need to have something in place by then to be able to talk to them. Mark Horton
sjb (10/31/82)
If we're going to change the name at all, we might as well make it represent what we really are: a network that 'distributes' information electronically. So, how about something along the lines of EDDNET (Electronic Data Distribution Network)? Personally, I would just rather stay with UUCP. Many people already call it that, and what is going to happen when you change it? *MASS* confusion! Adam
bstempleton (11/01/82)
Mark says we are just one network among many. Network, shmetwork! What we are talking about here is a name for a domain, not a network. This is notably true because we are talking about several networks in this uucp domain. In fact, the only reason we have called it uucp is because the most common transport program is uucp. According to Postel's documents, initial domain names should have something to do with the organization above them. We are talking about the domain that has no enclosing organization. It is in this sense the "public" domain, or if we want to get slightly more selective, the "north-american" domain. In my opinion, this domain in some ways should be the root domain (the public one, not the continent name) and "arpa" should really be underneath it. The only problem with this is that it forces all machines to have too much information, since it is a good idea for each machine to know the top level domains. We can solve this by kludging it and creating a domain to shove sites that don't have another affiliation. Calling this domain "uucp" because that is what a shrinking percentage of the sites in it now use for mail is absolutely preposterous, and I would not want to have to explain the choice of that name to anybody! In the long run, our domains will most likely end up being named after continents, nations, states and provinces - after all, electronic mail will soon be used by the general public as soon as it wakes up to how much faster and more convenient it is. That's why I'm for grouping the machines of no enclosing organization on this continent in a "na" == "north-america" domain. If we can, I would like to see "arpa" put under this domain too. That is where it belongs. Also, that fact that a few programs have been written with the name "uucp" in them is no excuse. If such a parameter can not be changed within minutes in these programs then they should most definitely be trashed and rewritten from scratch by different programmers.
wapd (11/01/82)
I favor the name "USENET". It has absolutely no connotations, unlike NA, MISC, PUBLIC, UUCP and any other name that I have seen here. As far as confusion goes, picking any name can be traumatic. There will be "mass confusion" for about two weeks, and then everything will settle down. Bill Dietrich houxj!wapd
rick (11/02/82)
Near as I can tell the only objection to UUCP as a name for our domain
is that it ('uucp') happens to be the name of a program that is
currently used to transfer the bulk of the data that gets transferred
within our domain. If we ignore that fact (as will certainly be the
case if the uucp program falls into disuse at some future time) and
think of UUCP as meaning (something like) 'Un*x to Un*x Copy' then the
only remaining objection is that some of the systems in the UUCP
doimain are not Un*x (eg. Unice (sp?) or GCOS), but as long as those
systems 'look like' Un*x systems (in some sense) I (for one) am not
greatly troubled by that small inconsistency.
* UNIX is a trademark of Bell Laboratories.martin (11/04/82)
Adam Buchsbaum made a comment in 'net.columbia/net.space' months ago when someone wanted to change the name of net.columbia to net.shuttle because there were newer shuttles coming out with new names. Well now the same thing is happening with the domian name 'UUCP', even at the moment lots of news/mail/file-xfer's goes on without the aid of uucp, but still uses the ! notation (the uucp notation). UUCP has been good to us, it may have kept us away from our loved ones while finding why there's a core file in /usr/spool/uucp, or wondering what to do with all these spare D. files that appeared on your machine, lets honour it with a name in history (i know, it would take a long time to forget anyway). i think it would make a great way of describing a network where to get from A to B would probably have to go thru intermediate machines (as apposed to the ARPA way). The way the naming is structured there can be a uucp.na and uucp.europe same as there can be a btl.uucp.na and a btl.uucp.europe where btl could be "British Telecom Ltd" (i know, it isn't called that!). martin levy, bell labs, holmdel