info-vax@ucbvax.ARPA (06/27/85)
From: jww@SDCSVAX.ARPA (Joel West) (ttyj0) From postnews Tue Jun 25 00:23:11 1985 Subject: Re: RFC920 domains Newsgroups: net.mail.headers Keywords: domains cow patties References: <918@sdcsvax.UUCP> <532@deepthot.UUCP> <8066@ucbvax.ARPA> <2329@icarus.fluke.UUCP> 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. From postnews Tue Jun 25 00:24:23 1985 Subject: Re: RFC920 domains Newsgroups: net.mail.headers Keywords: domains cow patties References: <918@sdcsvax.UUCP> <532@deepthot.UUCP> <8066@ucbvax.ARPA> <2329@icarus.fluke.UUCP> 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. From postnews Wed Jun 26 22:36:05 1985 Subject: VT240 upgrades Newsgroups: net.graphics,net.periphs DEC recently announced a new whiz-bang upgrade to the VT240. It supposedly adds both performance and capability. I bought my VT240 about 6 months ago, and was quoted about $350 for the upgrade. Since I (my company) bought it for the day I get the time to sit down and figure out how to make pretty pictures, I don't know enough about what it can do to know whether it's worthwhile.... Does anyone know what it entails, and what its practical value is? I'd also be interested in hearing from anyone with experience using a VT240 or 241. In particular, I've heard the performance sucks. Also, I'm curious whether people are using it as a Regis device (for which there's no software) or as a 4014 emulator. PS: The 240 becomes a 241 by buying a new monitor (according to a DEC rep) Is this a worthwhile use of money?