avolio@decuac.UUCP (Frederick M. Avolio) (07/19/85)
We have seen discussions in this space regarding DOMAIN-style addressing of sites vs. strict path addressing with systems having -- basically -- a map of the world to facilitate mailing. A few folks have pointed out the problems we are starting to see with 1) numerous name collisions and 2) more and more personal computers on networks, etc. as unique "sites." A recent posting to net.newsite gives an example of both. Not only do we have a site name used which is already used by a site in Montana, but we have not one but two home computers announced as news sites. Lest you think I am "The Grinch" or some other fiend who does not like kids, etc. let me assure you that nothing could be further from the truth. I just point this out as an example of what is wrong with the idea of a pathaliases data base containing paths to all known sites on all known nets. -Fred
dave@uwvax.UUCP (Dave Cohrs) (07/19/85)
> I just point this out as an example of what is wrong with the > idea of a pathaliases data base containing paths to all known sites on > all known nets. I agree that pathalias, as it currently exists has problems, especially for a site like any here at U of Wisconsin, where we are on (pick n): USENET, ARPAnet, BITNET, CSNET (sort of) and probably others I don't know of. The 4.3 Bind server doesn't do it either, from what I can tell. It will tell me the Internet address of a site, but how about giving me the address of the uucp site dino at wisconsin (which can't work, for no better reason than that UUCP isn't a domain)? If pathalias had the idea of a domain name-space incorporated with it, I think the problems would be less. Speaking of duplicate sitenames, has anyone else noticed that there is a site named odin both in NJ and somewhere in Great Britain? What's worse is that pathalias thinks that the fastest way to get to another site on the localnet in GB containing odin is through NJ. -- Dave Cohrs ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave dave@wisc-romano.arpa
honey@down.FUN (Peter Honeyman) (07/20/85)
i don't have a problem with name collisions. i use the (undocumented) private host declaration in pathalias to make such hosts invisible. pathalias then generates routes through but not to these hosts. my mailer runs routes given by mail and netnews through pathalias and a route parser. i am generally satisfied with the results. my database currently includes mod.map.uucp, arpa, csnet, bitnet, and dec enet (with mailnet coming soon). that's about 10,000 hosts. i reiterate: i don't have a big problem with host name collisions. i have a much bigger problem with foreigners (i.e., arpanauts) trying to shove standards down my throat. i plan to post a recent edition of pathalias within the next 10 days (as soon as my correspondents report back that it still works). the parser should follow sometime in august. peter appendix: here's some output from the parser. ========== princeton!ulysses!cbosgd!ulysses!princeton!down!honey@cbosgd.ATT.UUCP host == ulysses user == cbosgd!ulysses!princeton!down!honey@cbosgd.att.uucp the parser found four credible candidates and merged them to get the result shown. someone's broken mailer put it in this confused state. ========== princeton!ihnp4!cfg!ukc!dar@ubu.uucp host == cfg user == ukc!dar@ubu.uucp i don't know how this got to me! ========== princeton!seismo!USER%purdue@csnet-relay.ARPA host == purdue user == user note that the parser decided against the two candidate parses that require bouncing around on arpanet or csnet. ========== princeton!allegra!ucbvax!vortex!lauren@rand-unix.arpa host == rand-unix user == vortex!lauren my database doesn't know about rand-unix -> vortex, but the mail gets through anyway. ========== princeton!allegra!ulysses!mhuxj!ihnp4!inuxc!pur-ee!uiucdcsp!shilling host == pur-ee user == uiucdcsp!shilling again, no data on pur-ee -> uiucdcsp, but it's ok. ========== princeton!astrovax!dartvax!forwarder.dartmouth@csnet-relay.CSNET host == dartvax user == forwarder.dartmouth@csnet-relay.csnet someone at dartmouth thinks it's good practice to obscure the user name when gatewaying from csnet; i don't agree. also, it would have helped to know the relationship between dartvax and dartmouth (i think the latter is a "domain"). ========== princeton!ihnp4!ucbvax!pleasant@rutgers.ARPA host == rutgers user == pleasant gotcha. ========== princeton!ihnp4!ucbvax!jk01%tufts.csnet@csnet-relay.arpa host == tufts user == jk01 gotcha. ========== princeton!ihnp4!mit-eddie!jfw@mit-ccc.ARPA host == mit-eddie user == jfw@mit-ccc.arpa again, missing data prevents a complete parse, but that's ok. ========== princeton!seismo!hao!hplabs!sri-unix!reihar@ucla-locus.arpa host == sri-unix user == reihar@ucla-locus.arpa correct, but only by accident. using the real host name (ucla-cs) instead of the alias leads to real trouble. ========== princeton!seismo!hao!hplabs!sri-unix!reihar@ucla-cs.arpa host == princeton user == seismo!hao!hplabs!sri-unix!reihar@ucla-cs.arpa this is a compromise between three reasonable parses. i'd call it a complete failure, actually. hey, no one's perfect. ========== princeton!allegra!ucbvax!Jon_Tara%Wayne-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA host == mit-multics user == jon_tara%wayne-mts%umich-mts.mailnet that's the best it can do until i incorporate mailnet data. ========== x!y@z host == x user == y@z pathological --there actually \is/ a host called x! since the parser couldn't get anywhere with down->x and down->y, it ran pathalias on x and y ran recursively on the result, princeton!clyde!frog!x!y@z. ========== princeton!meetix.yktvmv@ibm-sj host == ibm-sj user == meetix.yktvmv uses the princeton -> csnet link. =========== that's it for the examples. the total running time for these 14 examples was about 7 seconds cpu time, 16 seconds real time, on a 750. for more info, see my paper with parseghian in the proceedings of the winter '85 usenix (dallas).
avolio@decuac.UUCP (Frederick M. Avolio) (07/24/85)
In article <531@down.FUN>, honey@down.FUN (Peter Honeyman) writes: > i don't have a problem with name collisions. i use the (undocumented) > private host declaration in pathalias to make such hosts invisible. > pathalias then generates routes through but not to these hosts... > > my database currently includes mod.map.uucp, arpa, csnet, bitnet, and > dec enet (with mailnet coming soon). that's about 10,000 hosts. i One still then has to, by hand I guess, "fix" the collisions such that if I want to send mail to Illinois, it does not try to go through host osiris which exists in IL as well as at Johns Hopkins Univ Hospital (local to us), for example. Even if this is automated, how do I indicate which is the "real" osiris, for example, for my site? And why should I have to choose. (I may want to send to osiris in the midwest sometime.) But, still... 10,000 names! And between the time I send this and someone reads this, 500 new personal computers have gotten hung off of various hosts on the network. (80% of which are named something unoriginal, like peanut or elrond...) If I know a user address is user@d1.d2.d3.....dN.ATT.UUCP I don't have to know anything except the best path to a site which handles whatever of the above domain mess I "understand." (In this case, probably .ATT.UUCP.) Or if I know I want to send to user joe on host joe on DEC's Enet, and I don't know how to get to an Enet gateway, all I have to do is know to get it to a smart UUCP host (smart being a well advertised host like seismo or cbosgd or down or decuac or just one with a little larger picture of the world) who will send it to decuac or decwrl. In this way *every* host can know how to get to at least one "smarter" host. And it is easy for *lots* of hosts to know paths to 100 other (some smarter) hosts. But not many hosts will want to have to keep current a list of 10? 20? 100 thousand node names. And not one host should or will have to. -Fred
honey@down.FUN (Peter Honeyman) (07/25/85)
re 10,000: yes, 10,000. ain't no big thang. re osiris: i have osiris marked as "private", consequently my route database doesn't show any route whatsoever to osiris. osiris!user is incompletely specified, thus erroneous. to get there, you have to further specify the host name, e.g., aplvax!osiris!user, or uiucdcs!osiris!user. does it sound like domains? it's not. re collisions: how do i detect collisions? easy: when mail fails due to a host name collision, i mark my pathalias input files accordingly. (it's not an error until it's an error.) re domains: of course, if you prefer to send mail to honey@down.FUN.PRINCETON.EDU, well, that's your business; i'll continue to recommend down!honey. re smarter neighbors: i have the good fortune to have worked with an outstanding collection of co-authors. between nowitz, redman, bellovin, and parseghian, i have participated in the development of the unchallenged leader among uucp's, the principal unix mail router, and the only route parser of any significance. now tell me: who is my smarter neighbor? cbosgd!cbosgd.att.uucp? be serious. what's more, consider the following contradiction. it's great to have a router and a database because it makes high quality mail service immediately accessible. it's a drag having a high quality mailer, because my stupid neighbors use up my cycles, clog my modem, add to my phone bills, and (irony!) interfere with my own mail delivery. for many sites, it's appropriate to use a smarter neighbor: consider upas, the v8 mailer (see portland proceedings). on the other hand, someone, somewhere has to be smart, and who knows? even dumb computers might strive for advancement. peter
kre@ucbvax.ARPA (Robert Elz) (07/27/85)
In <537@down.FUN> Peter Honeyman made a fairly persuasive case for not using domains, but for using uucp style addresses instead, with a smart parser to work out what where you wanted your mail to go, and find a route to get there. One problem with this is ambiguous names - two sites with the same name. Peter's solution to that is to (rightly) notice that in that case, just giving the name is insufficient, you have to provide more information. The extra information that he suggests is the name of a uucp neighbour of the badly named site. This works, as no site can talk to two others of the same name. The problem with this "solution", is that addresses aren't anything that can be relied on. Peter's address in his scheme would be "down!honey". Today. Tomorrow it might not be, as anyone, anywhere can create another "down", making "down!honey" ambiguous. Peter's address is now "princeton!down!honey". I'm not sure how anyone could explain to users that the unrelated actions of some site on the other side of the world, on some unrelated network (Peter's scheme has lots of networks rolled into it) has suddenly invalidated what used to be a perfectly good address. Of course, things don't end there. All that needs to be done now is to make another node "princeton" and connect it to the new "down" and Peter's address changes again. Now it is "seismo!princeton!down" or "seimens!princeton!down" or any of dozens more. Apart from the original name change, we now have the problem that Peter has lots of different addresses, and it takes a very smart piece of code to deduce that they all specify the same person. The final straw is that none of these nodes actually need to exist - all I need to do to foul up lots of people's mail to Peter, if I feel unkind to him, is to add dozens of dummy hosts to my route maps, connected just the same way that they are in real life. It would be possible to set things up so that just about the only legal address for Peter would be a fully specified uucp path (just like we used to have to use, and many places still do). Somehow i can't believe that this is a practical solution This is the principal difference with domains. A domain is an *authority*. That is, there is some responsible entity who alone can make new names in the domain. Peter's scheme assumes mutual cooperation, which in some environments can be assumed, but can't be in others. In a mail system that you want to work everywhere, you simply have to allow for the bastards (like me) as well as the good guys (like Peter). Don't be misled by syntax trivia - it makes no difference whether domain names are expressed cbosgd.att.uucp!mark or uucp!att!cbosgd!mark or even mark@cbosgd.att.uucp What's important is the issue of who is allowed to create new names that are expected to be recognised in other places. Some kind of naming authority is essential if this network is to continue to grow and be useful. That's exactly what a domain is (and a domain is no more than that). Robert Elz ucbvax!kre
hedrick@topaz.ARPA (Chuck Hedrick) (07/28/85)
You describe a problem with conventional UUCP addressing, namely that down!honey is unique only until there is another down, at which point you have to use princeton!down!honey, etc. Unfortunately, domains have an exactly similar problem. As long as everyone uses the full domain name, they are unique. But I do not expect my users to use red.rutgers.edu every time they want to send a message to red. Indeed the domain specs allow for abbreviations, e.g. red and red.rutgers. It is likely that most domain implementations will allow such abbreviations (in order to prevent lynching of the implementor by irate users), and that most users will use them. In that case, we will address down!honey as honey@down, until there is another down, at which point we will change to honey@down.princeton, etc. There are certainly advantages to down.princeton over princeton!down. It does not specify a route. So as we have to add more "." suffixes to down, we do not end up constraining the route, as we do when we add "!" prefixes. However in practice, this advantage is not likely to be serious. There is a de facto separation of machines into major and minor network links. Presumably no one is going to get away with having a second UUCP machine called allegra. I conjecture that almost all machines are within one or two links of a machine so major that duplication will not happen. So in practice there is unlikely to be any worse problem with ! syntax than domain syntax.
mark@cbosgd.UUCP (Mark Horton) (07/28/85)
In article <9390@ucbvax.ARPA> kre@ucbvax.ARPA (Robert Elz) writes: >I'm not sure >how anyone could explain to users that the unrelated actions >of some site on the other side of the world, on some unrelated >network (Peter's scheme has lots of networks rolled into it) >has suddenly invalidated what used to be a perfectly good address. Very true. What's a little scary is that MHS (that's the new international standard for electronic mail which is about to be thrust upon us by all the common carriers) has this same drawback. >Some kind of naming authority is essential if this network >is to continue to grow and be useful. That's exactly what >a domain is (and a domain is no more than that). Well, sort of. Actually, a domain has implicitly associated with it a naming space, with a set of syntax rules. An ARPA domain has rules like "no two children of the same parent in the domain tree can have the same name" and "names are made up of letters, digits, and hyphens, and upper/lower case isn't significant." An MHS domain (yes, MHS has domains too) has rules like "names are X.409 Printable Strings (made up of nearly any printing characters) and addresses may need extra attributes, like the Zip Code of the recipient, to disambiguate among possibly identical children of a parent in the tree."
avolio@decuac.UUCP (Frederick M. Avolio) (07/28/85)
In article <9390@ucbvax.ARPA>, kre@ucbvax.ARPA (Robert Elz) writes: > In <537@down.FUN> Peter Honeyman made a fairly persuasive case > for not using domains, but for using uucp style addresses instead ... > One problem with this is ambiguous names - two sites with the same > name. Peter's solution to that is to (rightly) notice that in > that case, just giving the name is insufficient, you have to > provide more information... The problem with this "solution", is that > addresses aren't anything that can be relied on. The more important difference is that with "Peter's solution," there are two kinds of hosts or mailers: smart and dumb. With a domain addressing scheme, there can be degrees of "smartness." In this way well-defined hosts will be responsible for a particular name- space. Any host can know about all hosts in the world if it wants, but practically speaking no one host will. But it is reasonable for a host or two, for example decwrl or decuac, to make sure it can always handle things intended for DEC sites (either the domain DEC as it is used today meaning DEC's internal Enet, or company-wide in general which would include non-Enet sites such as decvax, mogwai, hjuxa, and so on...). Then any host in the world can handle user@host.DEC if they can get to one of the two mentioned hosts. They need only know one path for all of .DEC. And this is a very important feature if one wants uninterrupted mail service. Fred.
henry@utzoo.UUCP (Henry Spencer) (07/29/85)
> This is the principal difference with domains. A domain is > an *authority*. That is, there is some responsible entity > who alone can make new names in the domain. ... > Some kind of naming authority is essential if this network > is to continue to grow and be useful. ... Oh goody, a volunteer! :-) More seriously, this is a real and fundamental problem of any attempt to set up a central naming authority: what happens when the volunteer labor burns out? Who is going to pay for the man-hours needed, in perpetuity? -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
kre@ucbvax.ARPA (Robert Elz) (07/30/85)
The quotes ('>' lines) in this article are from article <2968@topaz.ARPA>,
submitted by hedrick@topaz.ARPA (Chuck Hedrick).
> In that case, we
> will address down!honey as honey@down, until there is another down, at
> which point we will change to honey@down.princeton, etc.
No no no. Abbreviated domain addresses mean that the rest of the "local"
domain is appended. There cannot be "another down" in this case.
If I am on "monet" a host at Berkeley, and I want to mail to "dali",
another host, I can use "mail fred@dali" as the "dali" will be
expanded to "dali.berkeley.edu" - the "berkeley.edu" being the
domain from "monet.berkeley.edu". Should a "dali" suddenly turn
up at ucla, I can still address Berkeley's as "fred@dali", to
get to the one at ucla I would need to use "fred@dali.ucla.edu"
(or "fred@dali.ucla" - as the ".edu" can be appended from monet's
domain). It is essential that addresses be a constant for mail
systems to be workable.
>
> There are certainly advantages to down.princeton over princeton!down.
> It does not specify a route.
Again, no. This is just syntax. Neither has any real advantage
over the other, either syntax can be defined with good or bad
semantics. The semantics was what is important.
> Presumably no one is going to get away with
> having a second UUCP machine called allegra.
This was just what I was saying that I can do with Peter Honeyman's
scheme. Not only can I have an allegra, I can also have ihnp4,
cbosgd, decvax, and anything else I like. What's going to stop me???
(Actually, decvax might be a little difficult because of the trademarks,
but lets not get into that can or works here)
I agree with remarks made by Brian Ried, and Fred Avolio. Mark Horton's
were right too, except it seemed that he implied that there were no
syntax rules in "uucp" style addresses. That's not true. They have
rules for what is a legal address just as domain addresses do. I
didn't bother to point out that the rules might be different, as I didn't
really consider that to be an difference that anyone would really care
about. As long as there are going to be rules, it doesn't matter a lot
whose set of rules we adopt.
Robert Elz ucbvax!kre kre@ucb-vax.berkeley.eduhokey@plus5.UUCP (Hokey) (07/30/85)
Chuck's point about abbreviations is well-taken and almost correct. While it may be reasonable for his mailer to accept "red" as an abbreviation for "red.rutgers.edu", that abbreviation *must* be expanded to a fully qualified name before it leaves his site. This way, unambiguous names are available and there is no additional effort required by the user. Furthermore, when people reply to the messages, they don't have to type anything else because the recipients are already given with fully specified domain addresses. I disagree with your point that we can rely on reasonable behavior to prevent somebody else from calling their site "allegra". Eventually, problems will occur, and I would rather solve the problem than increase the size of my dongle to handle the additional situation. There is already too much one has to know in order to accomplish anything. -- Hokey ..ihnp4!plus5!hokey 314-725-9492
jordan@ucbvax.ARPA (Jordan Hayes) (07/31/85)
In article <2968@topaz.ARPA> hedrick@topaz.UUCP (Chuck Hedrick) writes: >In that case, we >will address down!honey as honey@down, until there is another down, at >which point we will change to honey@down.princeton, etc. Well, honey@down is really only legal if one of two things are true: a) if you have a direct connection to down b) if your site and down have a common parent ------------ Jordan Hayes jordan@ucb-vax.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
jordan@ucbvax.ARPA (Jordan Hayes) (07/31/85)
In article <9467@ucbvax.ARPA> kre@ucbvax.ARPA (Robert Elz) writes: >If I am on "monet" a host at Berkeley, and I want to mail to "dali", >another host, I can use "mail fred@dali" as the "dali" will be >expanded to "dali.berkeley.edu" - the "berkeley.edu" being the >domain from "monet.berkeley.edu". Should a "dali" suddenly turn >up at ucla, I can still address Berkeley's as "fred@dali", to >get to the one at ucla I would need to use "fred@dali.ucla.edu" >(or "fred@dali.ucla" - as the ".edu" can be appended from monet's Well, there's a problem with that. What you describe *works*, but not because of the "expansion" of the fred@dali to fred@dali.berkeley.edu... How do you know what is the "local domain" ? How do you infer this? It is possible for a host to be a member of more than one domain (with valid addresses in each...). For instance, this machine could be both ucb-vax.berkeley.edu and ucbvax.ucb.nca.uucp and either should work correctly. Now, if i send to fred@ihnp4 (which has a direct link to ucbvax and thus should need no qualification), will you expand ihnp4 to be ihnp4.berkeley.edu ? I hope not. UUCP shows that you can have "peers" (i.e., direct connections) that are of a different domain than you. Also, fred@dali.ucla shouldn't work from here (you should need the .edu, because it's a common *grand*parent we share, not a parent. Do I need to know all the domains above me (i.e., purdue, mit, cmu, ucla, etc...) ..? It would be nice to be able to cache this info somehow, but i don't see how you can require me to know about all the "aunts and uncles" that I have (at least in the UUCP world). ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
honey@down.FUN (Peter Honeyman) (08/02/85)
robert wants to know who will stop him from naming his machines allegra, ihnp4, decvax, etc. indeed, naming computers after famous computers has a certain charm. nonetheless, i presume you will be discouraged from doing so by the same people that stop me from calling my machine ucb-vax.berkeley.edu. peter
honey@down.FUN (Peter Honeyman) (08/02/85)
jordan states that a host may be a member of more than one domain.
possibly he is referring to the following passage from rfc819:
In reality, anomalies may exist violating the in-tree model of naming
hierarchy. Overlapping domains imply multiple parentage, i.e., an
entity of the naming hierarchy being a child of more than one domain.
It is conceivable that ISI can be a member of the ARPA domain as well
as a member of the USC domain (Figure 2). Such a relation
constitutes an anomaly to the rule of one-connectivity between any
two points of a tree. The common child and the sub-tree below it
become descendants of both parent domains.
U
/ | \
/ . \
. . ARPA
. . | \
USC | \
\ | .
\ | .
ISI
Figure 2
Anomaly in the In-Tree Model
Some issues resulting from multiple parentage are addressed in
Appendix B. The general implications of multiple parentage are a
subject for further investigation.
on the other hand, rfc920, "Domain Requirements" states:
The domain is part of the host name. Thus if USC-ISIA.ARPA changes
its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
changed its name. This means that any previous references to
USC-ISIA.ARPA are now out of date. Such old references may include
private host name to address tables, and any recorded information
about mailboxes such as mailing lists, the headers of old messages,
printed directories, and peoples' memories.
it appears to me that the issue was resolved in favor of domain uniqueness.
peterkre@ucbvax.ARPA (Robert Elz) (08/03/85)
In article <548@down.FUN>, honey@down.FUN (Peter Honeyman) writes: > robert wants to know who will stop him from naming his machines > allegra, ihnp4, decvax, etc. indeed, naming computers after famous > computers has a certain charm. > > nonetheless, i presume you will be discouraged from doing so by the > same people that stop me from calling my machine ucb-vax.berkeley.edu. No no - that's exactly the difference. There is some (one, two, three..) fixed site that maintains the list of what are legal names in the "edu" domain, another that looks after what is legal in the "berkeley" domain. The whole rest of the universe believes names in those domains if and only if those "registry" sites put them in their lists. There is no equivalent in the uucp graph model (attributed names). Data is collected from anyone and everyone, there is no authority to determine whether my "decvax" is the real "decvax" of the one in New Hampshire is. Note, in neither case can anyone stop me calling my machine "decvax", the difference is what mechanism is there for determining which of them they should consider to be 'decvax'. Of course, there's nothing stopping the uucp world banding together and asking the uucp mapping project to delete (or simply not include) duplicated names. Then the world would only believe the uucp names that they publish, and all would be fine. Someday, someone might realize that its taking about a month to get an answer from the uucp mappers as to whether their proposed name is acceptable or not. Being intelligent, they may just do a deal with the mapping people - "I will call all my machines with names that start with the prefix 'mit-', you reserve all names that look like that for me, I will just allocate names for myself, and send you the resulting list". Does anyone see a pattern emerging? Does it really make a difference whether the naming scheme they agree to adopt is a "mit-" prefix, or a ".mit" suffix? Robert Elz ucbvax!kre kre@monet.berkeley.edu
honey@down.FUN (Peter Honeyman) (08/05/85)
robert objects to my assertion that "the same people that stop me from calling my machine ucb-vax.berkeley.edu" will prevent me from naming my machine decvax. objection well taken; let me be more precise. the same social processes will keep me from doing so. this is orthogonal to the authority issue, after all nothing prevents a uucp administrator from giving his machine a crank name, domain-like or otherwise (which is robert's point). peter