jordan@ucbvax.ARPA (Jordan Hayes) (06/12/85)
Hmmm... seems like the UUCP community is taking this rfc920 stuff a little too seriously. It doesn't seem to make much sense for UUCP to even *try* to implement organizational domains. ARPA, on the other hand, almost *requires* it at this point. What's wrong with making UUCP a domain and then sub-domaining geographically under it? ARPA's routing topology is *nothing* like UUCP's. C'mon, guys, take a hint from the Aussies. No UUCP site administrator is going to give up calling the sites that she/he has built up trust for over the last few years, just because they aren't part of their domain anymore. UUCP is a wholy different community, with different requirements and limitations. The map even gives a good start as to how to break down UUCP. Hurrah for ARPA if it can be a conceptual net -- it has the facilities. UUCP DOESN'T. Make the best with what'cha got. UUCP still has phone bills and increasingly lousy long distance connections to deal with. /jordan
joe@fluke.UUCP (Joe Kelsey) (06/14/85)
Jordan - When is everyone going to realize that the point of domains is to separate the physical addressing from the naming? You asked what is wrong with setting up .UUCP as a top-level domain and using geographic subdomains? Well, I'll tell you there is a LOT wrong with that idea. For one thing, it creates artifical boundaries that people may confuse with routing. Domain names have absolutely nothing to do with routing. They have absolutely nothing to do with which other sites I choose to talk to - whether that communication be with UUCP or X.25 or TCP or ... Geographic domains would force a nation-wide company to make up useless names for their physically separated computers simply to satisfy someones idea that there is some "logic" to this scheme. There are going to be hosts with multiple network connections. The most useful part of the domain name scheme is the fact that a host has *exactly* one name. It may have multiple physical addresses - one for each physical network it is connected to - but it has the same *user visible* name on each network. Try thinking of the UUCP sitename as an address instead of a name, then you will be able to see the separation of *naming* from *addressing* and *routing*. /Joe
jww@sdcsvax.UUCP (Joel West) (06/25/85)
In article <8201@ucbvax.ARPA> jordan@ucbvax.ARPA writes: > In article <2323@icarus.fluke.UUCP> joe@fluke.UUCP (Joe Kelsey) writes: > > > I think that is important that anyone who is tempted to jump into the > > domain discussion consider that what we really want is a way to name > > hosts *independent* of their physical location or physical network > > address, since both of these are volitile. What we need is a user-intuitive > > way of finding out host names, then a set up protocols to implement some > > sort of limited distributed name server/resolver on the UUCP transport > > mechanism. This is possible, but an important step to take is to disconnect > > your idea of hostname from physically restricting ideas, like geographic or > > network addresses. > > Independent of "physical network address", yes, of course, but I don't > think that geographic reference in some instances is any more > restricting than organizational domains. ... should > a University in Germany be in the same domain as UC Berkeley because > it is a University? ARPA says yes. UUCP should say no. Geography is > counter-intuitive in the ARPA world. Not always in the UUCP world. Needless to say, I agree whole-heartedly with jordan. I would be willing to bet my (minimal) reputation on a vote from net.general as to whether the geographic approach is more "user-intuitive" than the NIC plan for each respondent's home address. In <2329@icarus.fluke.UUCP> joe@fluke attempts to reply: > When is everyone going to realize that the point of domains is to separate > the physical addressing from the naming? Joe, we realize that this is the "point" of those attempting to invent such domains. We just don't agree that this is a desireable "point" (read: "goal") for designing a mail system. > You asked what is wrong with setting up .UUCP as a top-level domain and > using geographic subdomains? Well, I'll tell you there is a LOT wrong with > that idea. For one thing, it creates artifical boundaries that people > may confuse with routing. I cross through 4 municipalities en route from work to home. These are artificial boundaries. When I make a phone call, I do not specify these intermediate cities--but the prefix of my home phone implicitly gives my city. The use of a geographic designator does not prohibit other routings. In my previous example, bonnie.nj.uucp would still talk directly to gould9.ca.uucp. And I might be so smart as to say that any message I get for ".nj.uucp" should go to bonnie, since she knows more New Jersey sites than I do (and I know more San Diego sites). My friends might also give me ".nj.uucp" addresses since I have a friend in New Jersey and they don't. >Domain names have absolutely nothing to do with routing. "Absolutely nothing" is a bit strong. When in doubt, X.ARPA will send Y.ARPA mail via ARPAnet, IMP's, tcp, etc. For example, that's how nosc.ARPA sends mail to nosc-frog.arpa, even though they're in the same building. In San Diego, a smart machine would send Y.SD.CA.UUCP to SDCC3.SD.CA.UUCP (or SDCC3.UCSD.EDU) which is a de facto name server for the 30+ mail machines here in town. > They have absolutely nothing to do with which other sites I choose > to talk to - whether that communication be with UUCP or X.25 or TCP or ... Again, I almost agree. I hope gould9.ca.uucp will still talk to sdcsvax.edu and nosc.mil. > Geographic domains would force a nation-wide company to make up useless > names for their physically separated computers simply to satisfy someones > idea that there is some "logic" to this scheme. I don't know anything about your company. But most of the nationwide companies I know -- such as computer companies -- will usually refer to Joe Blow from the "San Diego office" or "St. Paul office". My firm has offices in at least 15 cities and we normally refer to sending mail to the "LA office" or the "DC office". Needless to say, sending mail to AT&T in Holmdel, NJ would have to be more specific. > There are going to be hosts with multiple network connections. The most > useful part of the domain name scheme is the fact that a host has *exactly* > one name. Using unique host ids has disadvantages, but I'll stipulate this just to eliminate any controversy. :-) > It may have multiple physical addresses - one for each physical > network it is connected to - but it has the same *user visible* name on > each network. Try thinking of the UUCP sitename as an address instead > of a name, then you will be able to see the separation of *naming* from > *addressing* and *routing*. Just because I don't agree with you, don't think that means I don't understand domain naming, domain servers, and so on. It's fun to search through my uucpmap files to find a good route to a new site--that is, the first 3 or 4 times. After that, it's not fun. Automatic routing is essential to a complete electronic mail system. However, in the general UUCP world no true domains exist yet, and therefore their choice is totally arbitrary. Why not choose something that make sense more often than the NIC scheme? As Jordan notes, some of us pay for phone calls. Conversely, I route some messages to New Jersey and Illinois to get to Northern California, because the path is shorter--smart domain addressing might send it from San Diego to Silicon Valley in one hop. The general reaction I've heard to my original posting is that I had failed to realize that RFC920 was intended to meet the needs of the ARPA community, period. There is no reason it has any bearing at all on what the UUCP community does-- as long as we adopt some domain addressing scheme.
jordan@ucbvax.ARPA (Jordan Hayes) (06/27/85)
In article <943@sdcsvax.UUCP> jww@sdcsvax.UUCP (Joel West) writes: >The general reaction I've heard to my original posting is that I had failed >to realize that RFC920 was intended to meet the needs of the ARPA community, >period. There is no reason it has any bearing at all on what the UUCP >community does-- as long as we adopt some domain addressing scheme. Well, UUCP isn't under any pressure to conform to rfc920, unless of course they want to become a top level domain (which seems to be what Mark Horton is pushing for...). However, there's no reason to IGNORE it either. We don't want to exclude ourselves from the Big_Guys, ya know... /jordan ------- ARPA: jordan@ucb-vax.BERKELEY.EDU UUCP: jordan@ucbvax.UUCP WARHEADS: 37' 52.29" N 122' 15.41" W
pcelis@watdaisy.UUCP (Pedro Celis) (06/27/85)
In Article 484 of net.mail.headers: > > > > I think that is important that anyone who is tempted to jump into the > > > domain discussion consider that what we really want is a way to name > > > hosts *independent* of their physical location or physical network > > > address, ... > > In <2329@icarus.fluke.UUCP> joe@fluke attempts to reply: > > When is everyone going to realize that the point of domains is to separate > > the physical addressing from the naming? > > >Domain names have absolutely nothing to do with routing. > > Just because I don't agree with you, don't think that means I don't > understand domain naming, domain servers, and so on. ... > ... Conversely, I route some messages > to New Jersey and Illinois to get to Northern California, because > the path is shorter--smart domain addressing might send it from > San Diego to Silicon Valley in one hop. Once again. What does a domain scheme to NAME a host has to do with the ROUTE used to send messages to that host? -- ------ Arpa: pcelis%watdaisy%waterloo.csnet@csnet-relay.arpa CSNet: pcelis%watdaisy@waterloo.csnet UUCP: ...!{allegra,decvax}!watmath!watdaisy!pcelis
jonah@deepthot.UUCP (Jeff Lee) (06/28/85)
In response to: pcelis@watdaisy <7335@watdaisy.UUCP> >In Article 484 of net.mail.headers: >> >>>>I think that is important that anyone who is tempted to jump into the >>>>domain discussion consider that what we really want is a way to name >>>>hosts *independent* of their physical location or physical network >>>>address, ... >> >>In <2329@icarus.fluke.UUCP> joe@fluke attempts to reply: >>>When is everyone going to realize that the point of domains is to separate >>>the physical addressing from the naming? >> >>>Domain names have absolutely nothing to do with routing. > >Once again. What does a domain scheme to NAME a host has to do with >the ROUTE used to send messages to that host? Domain naming schemes relate to routing as follows: If you don't know how to route a message directly, you FORWARD the message to someone that you hope will know better. In general this means a server for the given domain. sysa.nj.UUCP could pass a message for sysb.ca.UUCP to any known system in the ca.UUCP sub-domain. If it doesn't know of any, it can pass it on to a "smarter" host in nj.UUCP or in UUCP (such as linus, decvax, ...). The reasons: (1) No host should *have* to know where every other host in UUCP resides. The routing tables would be rather large. Micros and minis should pass messages on to midis or mainframes which know better. (2) Connections change. What is a good route today may not be next week. If the message gets *closer* at each hop that's good enough. The problem lies in making sure that you are really getting closer. That is, that the host you forward to has a *better* idea (or at least equally good) of where to pass the message to. This way, routing can be done just one hop at a time. It doesn't matter whether you use geographic regions, corporate affiliations, or any other scheme to create the subdomains. Everyone shouldn't have to know the route to everybody else and those that don't should use the domain structures for partial routing. -- jonah (Jeff Lee @ Dept. of Comp. Sci., The University of Western Ontario) UUCP: ...!decvax!{utzoo|watmath}!deepthot!jonah MLNET: jonah@deepthot.UWO
guy@sun.uucp (Guy Harris) (07/02/85)
> Domain naming schemes relate to routing as follows: If you don't know > how to route a message directly, you FORWARD the message to someone that > you hope will know better. In general this means a server for the given > domain. Do you mean "network" (i.e., ARPANET/Internet, UUCP net, CSNET, etc.) or "domain"? A lot of the confusion in this debate is caused by thinking that there is a one-to-one correspondence between networks and domains. This need not be the case. Some systems assume that there is such a correspondence (i.e., some "sendmail.cf" files use a UUCP route generator and mailer if they see a host name that ends with ".UUCP", and use an ARPANET SMTP mail connection if they see a host name that ends with ".ARPA" - or route mail to a host with an ARPANET connection if they see ".ARPA"), but a host in domain ".COM" may be on the UUCP network, the ARPANET, or some private network. You can do routing by "brute force" by having a huge database of hosts and routes to them, or you could send all your outgoing mail to a "big brother" who does the routing for you, or... Think of name-to-(best)-route as a function (if a host has two or more equally good routes to it, pick one randomly). The value of a function from one finite set to another for a particular member of its domain can be computed by table lookup (i.e., the route database) or by "cleverer" techniques. Encoding part of the value in the input (i.e., using network names as domain names) is one such technique. However, this puts constraints on the use of domains; domains were intended as a way to simplify the administration of a host namespace, not as a way of cataloging all electronic mail networks. You can debate whether the UUCP network should be a domain with subdomains assigned for routing convenience, but it's not a foregone conclusion that this is the best way to go. > The problem lies in making sure that you are really getting closer. That > is, that the host you forward to has a *better* idea (or at least equally > good) of where to pass the message to. This way, routing can be done just > one hop at a time. > > It doesn't matter whether you use geographic regions, corporate > affiliations, or any other scheme to create the subdomains. Everyone > shouldn't have to know the route to everybody else and those that don't > should use the domain structures for partial routing. If you choose "any other scheme" to create the subdomains, you can choose one where the domains are set up for administrative convenience, not routing convenience, in which case there's no way to tell what a "closer" host might be simply by looking at the components of the target host's name. Guy Harris