dave@wisc-rsch.arpa (Dave Cohrs) (07/28/85)
I've been sitting quite for a while since last being chastised by Mr. Honeyman, however, I find a need to put my two-cents worth in again. In <9390@ucbvax.ARPA> ucbvax!kre (Robert Elz) says: > 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). I agree, Robert. We are here in the real-world of uucp with new sites popping up at random and many old ones coming out of the closet and exposing names that are age-old, but now create duplicates. A domain, because of it's authority over a certain area (physical or political, I don't care) will guarantee proper delivery of a piece of mail, assuming you can get to the host in the first place. I think that Peter is confusing the hostname itself with the routing needed to get there. Uucp provides a good method for routing (RFC822 routing should be banned and the author should repent his actions!) but RFC822 syntax provides a good domain naming syntax. Pathalias is a good first-step, but is not the answer to everyones problems. Add domain naming to pathalias (give it a domain-name, it gives you a route, hey, that sounds like a nameserver) and you have a much more powerful program. In <2968@topaz.ARPA> hedrick@topaz.UUCP (Chuck Hedrick) says: > 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. > 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. I think it's perfectly reasonable that the user specify the domain name. I mean, how many levels are you going to have? A three-level name is quite explicit for most applications. A four level domain should be able to handle anyone's needs (I think that's how AT&T domains would look). Most of the people who would complain here are the ones who are pushing for domain-style names now, so let them reap what they sow. If a user sends message to local sites, it is reasonable to cut domains (if I send to user@batman, it should choose the local batman, but if I specify a long domain, it goes the full route). For users who send to people at far-away sites, they can easily make personal aliases for each of them so they only have to type the domain once. No need to make a new mechanism when an old one will work just as well. ----- Now we switch gears for a bit and talk about address rewriting: In <10077@Glacier.ARPA> glacier!reid (Brian Reid) writes: > Automatic address rewriting in the current mail world has the problem that > it doesn't know what addresses to rewrite, and cannot. Furthermore, it makes > it impossible for a person to know his own address. If I send you a message > to honey%down@princeton, somebody's mailer can rewrite it so you see a > message sent to princeton!down!honey. But what if the message has a CC > field? I think this is why some mail systems have a distinction between the message itself and it's envelope. If a standard format could be created for the internal address (the one you see on the 'From:' or 'To:' lines) people wouldn't touch them. A domain name here would be absolutely necessary so replies could get back and whatnow. The address in the envelope can be rewritten at will, as long you don't muck things up for people downstream, because it's the one that should include the routing info in the first place. In <580@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: > 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. Which points out that Peter also sees the need for authoritative hostname servers, only he sees it on a smaller scale. However, until the route that the mail takes and the address of the recipient are divorced, there are going to be problems with collisions and mis-routing. The route that USMail takes is separate from the address on the front of the letter (as is the medium). The route a phone-call takes is separate from the number you dial. Shouldn't we take a lesson from these institutions that have reasonably well-working delivery systems? Domain naming, combined with a routing server can provide better service than what we have now. One without the other may work for some people, but can't solve the problems described above. 'nuf said (for now). -- Dave Cohrs (608) 262-1204 ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave dave@wisc-romano.arpa
honey@down.FUN (Peter Honeyman) (08/02/85)
dave describes a scheme in which user@batman goes to the local batman while user@batman.domain goes to some faraway batman. i agree, and follow precisely this scheme. as a case in point, we have an ncr tower here named bilbo (blame some undergraduate, not me). if i mail to bilbo!root (or root@bilbo, if you prefer), it goes to said tower. to get to the other two bilbo's out there, i have to give a more complete address. dave goes on to describe a scheme in which users exploit personal aliases for frequently needed addresses of faraway places, summarizing by saying "No need to make a new mechanism when an old one will work just as well." does anyone else see a certain irony in this statement? he finishes by urging consideration of the postal and telecommunications networks as solutions for our troubles with naming and routing. i suggest we consider the costs while we ponder their effectiveness. peter