sewilco@mecc.UUCP (Scot E. Wilcoxon) (09/02/86)
Is it acceptable for one site to have more than one name?
I don't want to start Domain_vs_Routing up again, but if a site
has a Domain name and is one more than one network then
the site should have a name on each network, right?
Example: A site on both .EDU and .UUCP should be registered
classification scheme is used.
I haven't seen anything which stated if more than one name was
possible.
(Let's not argue about existence of a UUCP registry, it's an
example hopefully also valid for subdomains.)
--
Scot E. Wilcoxon Minn Ed Comp Corp {quest,dicome,meccts}!mecc!sewilco
45 03 N 93 08 W (612)481-3507 {{caip!meccts},ihnp4,philabs}!mecc!sewilco
"BOOKS" in five-foot neon letters means pictures are sold there.jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) (09/02/86)
Scot E. Wilcoxon <sewilco@mecc.UUCP> writes:
Is it acceptable for one site to have more than one name?
I think it is. It's probably not an optimal solution, but it's
acceptable. I know it's not forbidden.
If a site has a Domain name and is one more than one network
then the site should have a name on each network, right?
Well, yes and no. The example you used was one of a machine in both
the UUCP world and the Internet world (you said ".EDU and .UUCP" but there
is no real .UUCP ... rehash). In any case, there are sites that are on
two networks and have separate names. Case in point is ames-titan.arpa
and "nike", two totally unrelated names on the same hardware. Rochester
does this too. Our configuration at nike will be changing soon but it
will remain confused for some time ... eventually, nike will become
ames and ames-titan.arpa will become ames.arpa (or, ames.arc.nasa.gov
when .ARPA goes away), so I would look for a consolidation into one
name, regardless of transport mechanisms.
/jordanmark@cbosgd.UUCP (Mark Horton) (09/03/86)
Yes, it's possible to have more than one name. cbosgd will answer to cbosgd, cbosgd.UUCP, cbosgd.ATT.UUCP, and cbosgd.ATT.COM. You do have to pick one primary name which you use on outgoing mail, but there's no reason you can't have other names (even nicknames.) There is an effort at the NIC to discourage nicknames, but there's no denying that you have to support the old names for awhile on upward compatibility grounds. And most hosts answer to a physical name (.UUCP, .BITNET, .CSNET, or .ARPA) address in addition to an organizational name (.EDU, .COM, .GOV, etc.) You can argue that since .UUCP doesn't exist (in the eyes of the NIC) that it doesn't count. The same argument can be made for .BITNET and .CSNET. But .ARPA does exist, and so it does have to work. (And it does work just fine.) It is fair to state that names other than the primary name should be viewed as upward compatibility support which eventually go away. This applies to hosts that move their names in the tree due to a reorganization (splitting of a subdomain, for example) as well as motion toward the organizational names. Names like "cbosgd" should be viewed as abbreviations for the full name, not nicknames. Mark
reid@decwrl.DEC.COM (Brian Reid) (09/04/86)
In article <2502@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >Yes, it's possible to have more than one name. cbosgd will answer to >cbosgd, cbosgd.UUCP, cbosgd.ATT.UUCP, and cbosgd.ATT.COM. You do have >to pick one primary name which you use on outgoing mail, ... I claim that this is false. If a host is on several networks, it is quite possible for it to have a different name on each network, and the name that you use on outgoing mail must be the true name of the host on the network over which the mail is being sent.
werner@ut-ngp.UUCP (Werner Uhrig) (09/05/86)
In article <2502@cbosgd.UUCP>, mark@cbosgd.UUCP (Mark Horton) writes: > Yes, it's possible to have more than one name. cbosgd will answer to > cbosgd, cbosgd.UUCP, cbosgd.ATT.UUCP, and cbosgd.ATT.COM. You do have > to pick one primary name which you use on outgoing mail, but there's > no reason you can't have other names (even nicknames.) There is an > effort at the NIC to discourage nicknames, but there's no denying > that you have to support the old names for awhile on upward compatibility > Recently, the aliases SEISMO and MCC were dropped from the HOSTS-table distributed by NIC, which made me quite unhappy as now I have remember to type SEISMO.CSS.GOV and MCC.COM everytime ... now this may seem an insignifi- cant effort, but you just wait until you have to type those darn stupid domains on every single address .... And I thought that the computer was there to make life easier ??? Of course, there was no notification of this change anywhere that you might expect the average user to read, and figuring out what was expected as an address instead of MCC or SEISMO wasn't of just seconds for anyone, not even minutes. If this is kept up by NIC, I can just see a lot of unhappy people having messages delayed, bounced back, and having to waste time to figure out what domain is needed, every time another site has their good-old basic name removed from the table. It's ok for mailers of 2 different machines talking to each other to express addresses with all the domain-glory, but what did users have to be bothered with this ???!!! Of course, there is the problem when 2 or more sites choose the same nick-name, but that should have been solved by resulting in a warning with the different sites getting listed in a menu to choose from. It would also help if the mailer on this and other machines would be able to handle a personal alias-list for sites, as well as for users. But then again, I'm not sure it can be called progress if NIC's removal of the nick-name SEISMO would result in every user adding SEISMO = SEISMO.CSS.GOV to the personal alias-list. > > You can argue that since .UUCP doesn't exist (in the eyes of the NIC) > that it doesn't count. The same argument can be made for .BITNET > and .CSNET. But .ARPA does exist, and so it does have to work. > (And it does work just fine.) > I won't even comment on that stupid ARPA policy of "sticking the head in the sand ..... > > It is fair to state that names other than the primary name should be > viewed as upward compatibility support which eventually go away. > This applies to hosts that move their names in the tree due to a > reorganization (splitting of a subdomain, for example) as well as > motion toward the organizational names. Names like "cbosgd" should > be viewed as abbreviations for the full name, not nicknames. > > Mark Whereas it is quite ok for any change to occur that the mailer-software worries about, it is just as important that such changes are transparent to the user who never should even need to become aware of such changes. Maybe it is just nostalgia, but my experience with Email 2+ years ago used to be quite satisfactory and reliable - but ever since this change-over to the domain-style addressing has begun, rare are the days when I don't have to waste extra time "hand-knitting" an acceptable Email-path because my mailer can't deal with the reply-address contained in a message, or because some site changed their address somehow "domain-style". Not to mention the time lost taken up by a message bouncing around the system until it brought back to my attention as "undeliverable" ... I know, some of the above mentioned problems have to do with the mailer on this machine not being "the latest model" (or me not knowing all the fancy new features), but I tell you, it is no fun, switching machines, OS, and type of net several times a day, each one with it's own "particularities" caused by the new domain-style addresses .... Cheers, ---Werner (I've been meaning to get this of my chest for quite a while now .... .... I do feel better now that I've aired my frustrations !!!)
henry@mit-trillian.MIT.EDU (Henry Mensch) (09/05/86)
It's rather ironic that, while the alias SEISMO (for SEISMO.CSS.GOV) was decommissioned, the alias SEISMO.ARPA is still maintained as a nickname... -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Henry Mensch | Technical Writer | MIT/Project Athena henry@athena.mit.edu ..!mit-eddie!mit-athena!henry
metzger@heathcliff.columbia.edu (Perry Metzger) (09/05/86)
The following message is a flame against people who think that domains put too much strain on their minds. Anyone offended by it is asked not to read further. In article <3920@ut-ngp.UUCP> werner@ut-ngp.UUCP (Werner Uhrig) writes: >Recently, the aliases SEISMO and MCC were dropped from the HOSTS-table >distributed by NIC, which made me quite unhappy as now I have remember to >type SEISMO.CSS.GOV and MCC.COM everytime ... Poor guy. He had to use his mind a bit. And of course asking him to make his own aliases for commonly used addresses in his .mailrc would be too much of a strain on him. >now this may seem an insignifi- >cant effort, but you just wait until you have to type those darn stupid >domains on every single address .... It does seem like an insignificant effort, and I do type it on every single address, whether an alternate still exists or not. >And I thought that the computer was >there to make life easier ??? Thanks to domains, computers can now handle the task that your system manager used to fret over. In fact, around here our '20s ran out of host table space and then we had to choose which sites to drop from our name space, which meant that obscure bitnet sites, some of which I conversed with regularly, had to go first. Thanks to domains, this sort of thing will never happen again, and once the switchover is complete, service will be better than ever before. No more need to recompile to get a larger and larger host table, no need for weekly updates from the NIC. Everything will run smoothly and automatically. >Of course, there was no notification of this >change anywhere that you might expect the average user to read, The NIC has been telling us for some time that sites may have their old style names dropped at any time, and that we should switch over ASAP. The fact that you chose to ignore it is not anyone else's problem. As soon as a site gets a domain style name, I use it, even if the old one still exists. >and figuring >out what was expected as an address instead of MCC or SEISMO wasn't of just >seconds for anyone, not even minutes. You never heard of GREP, have you. And the thought of trying grep seismo /etc/hosts never crossed your mind. This is not suprising. At any rate, I just tried it, and it worked fine. It took 3 seconds. >If this is kept up by NIC, I can just >see a lot of unhappy people having messages delayed, bounced back, and having >to waste time to figure out what domain is needed, every time another site >has their good-old basic name removed from the table. How did you figure out what "Plain-Old Basic Name" was needed in the first place? Is it THAT MUCH more difficult for you? Does a change of the time your favorite show was on lead you to panic for weeks since you won't make the effort to check your TV Guide? Besides, Now I KNOW where a machine was. Before, you had no idea what organization FooVax belonged to, but now you know since it is Foo.Bar.COM that it belongs to Bar Corp. >It's ok for mailers >of 2 different machines talking to each other to express addresses with all >the domain-glory, but what did users have to be bothered with this ???!!! Because otherwise the system is useless, since you have to store around all the tables anyway if the user isn't to be bothered with it. Next I suppose you want to eliminate host names and just address things to a unique user name so you don't have to be bothered with remembering where your associate is. Never mind the number of "Bill"s and "Chris"s on the net. And having to remember the host name is an exact analogy of having to remember the domain name. >Of course, there is the problem when 2 or more sites choose the same nick-name, >but that should have been solved by resulting in a warning with the different >sites getting listed in a menu to choose from. That is a user interface problem. If you want a system like that, write one. No one is stopping you. >It would also help if the mailer >on this and other machines would be able to handle a personal alias-list >for sites, as well as for users. But then again, I'm not sure it can be >called progress if NIC's removal of the nick-name SEISMO would result in >every user adding SEISMO = SEISMO.CSS.GOV to the personal alias-list. 1. Write a modification to your mailer, if you like. No one is stopping you. 2. Why do the extra 6 characters in the name bother you so much? Do you rebel against using zipcodes, too? 3. I call it progress when a time will come (soon) when a site can add as many machines as it likes without worrying about it. Perry Metzger ...!seismo(.CSS.GOV! Ha! I can remember it!)!columbia!heathcliff!metzger
werner@ut-ngp.UUCP (Werner Uhrig) (09/05/86)
In article <1091@mit-trillian.MIT.EDU>, henry@mit-trillian.MIT.EDU (Henry Mensch) writes: > > It's rather ironic that, while the alias SEISMO (for SEISMO.CSS.GOV) > was decommissioned, the alias SEISMO.ARPA is still maintained as a > nickname... > I could think of several other words but "ironic" .... Henry also pointed out to me (in a private message - thanks, Henry) that MCC is a valid nickname in the latest HOSTS-table from NIC. I checked the one on the site I mainly live on (R20.UTEXAS.EDU, a DEC-20), and, lo-and-behold, MCC is back in the table. (I swear, it was not there, when the problem first popped up). I'm trying to investigate .... I wonder what other sites have changed, or are changing, and where such things get announced (somewhere, that you may expect to come to the attention of the general user population) ---Werner
rick@seismo.CSS.GOV (Rick Adams) (09/07/86)
I had the NIC remove the SEISMO alias, they did not do it on their own. The idea is simple, if we ARE going to domain based names, then let's get rid of the non-domained names. If we aren't why should anyone bother to go through the agony of converting to domain server based hosts tables. ---rick
werner@ut-ngp.UUCP (Werner Uhrig) (09/08/86)
In article <41448@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: > > > I had the NIC remove the SEISMO alias, they did not do it on their own. > > The idea is simple, if we ARE going to domain based names, then let's get rid > of the non-domained names. If we aren't why should anyone bother to > go through the agony of converting to domain server based hosts tables. ...interesting. the cause was a little self-righteous arm-twisting by an individual fed up with the lack of progress trying to create a lot of squealing users who will then descend on their local site-administrator to demand explanation why the software hasn't been upgraded yet .... well, while I sympathize with your frustration, Rick ..... the problem is, of course, that such action also impacts *SEVERELY* the user interface and causes all kind of aggravation and wasted time for users, while not necessarily changing the pace of conversion (so it seems locally). It just adds to the problem and agony. Removing SEISMO from the NIC-table, BTW, only caused some sites to add an entry for Seismo in their local tables. I'm all for computers talking "domain-addresses" - I am against users having to deal with that aggravation. Or is anyone out there very keen on explaining to a "heavy" (think of Ted Koppel, Kaspar Weinberger, Edsgar Dikstra) why in this day and age of Fifth Generation computers, Expert Systems, and (shudder) Star-Wars, a user has to now learn that SEISMO has become SEISMO.CSS.GOV, UTEXAS-20 is now R20.UTEXAS.EDU, and UT-NGP has become NGP.CC.UTEXAS.EDU. I bet such an individual is also likely to be able to explain away the confusion of my mother-in-law with the long-distance mess which came out of the break-up of AT&T. (but I digress...) If you add up the total of aggravation caused net-wide by the time all sites come out of their "coocoon" ..., well, that will be a lot of man-years .... maybe it can be used as an excuse why Star-Wars will be late .... The net-wide impact on the user-interface for the general users of the net HAD TO be taken into account when proposing and planning the change, and having misjudged that would be an interesting topic to get roasted for (think '60 Minutes') It is my impression that computers and the net as a whole (think of Email, News, File Transfers, etc, for which site-name, domain-style or not, are important) are no longer just for the entertainment of hackers, but are supposed to serve "the rest of the world" to whom "grep" and "etc/hosts" can justifiably remain a mistery. [ this in reference to the posting by metzger@heathcliff.columbia.edu (Perry Metzger @ Columbia University CS Department) earlier in this group, who seems to be living in a world of only UNIX machines, where learning the names of UNIX-commands and system-files is a precondition for existence. Fortunately, Perry, you are of a dying breed (I hope, anyway), needed to keep the current generation of computers and software functioning, but hardly the "typical profile" for which the computers are here to provide service to. [ I hope I'll be forgiven for this little slap back - I have a hard time ignoring his comment "Poor guy. He had to use his mind a bit. ...." but I have no intentions to consider Perry's message as a basis for any continued serious discussion. - sorry to throw this in to this follow-up to the message from Rick, to whom no disrespect is intended - Rick' reasons and grievance, I understand ]
guy@sun.UUCP (09/08/86)
> the problem is, of course, that such action also impacts *SEVERELY* the user > interface and causes all kind of aggravation and wasted time for users, Only if the users haven't been properly notified of the impending change; I believe the disappearance of non-domained nicknames has been warned about for some time. It ain't Rick's fault if your site administrators didn't warn you. > Removing SEISMO from the NIC-table, BTW, only caused some sites to add an > entry for Seismo in their local tables. > > I'm all for computers talking "domain-addresses" - I am against users having > to deal with that aggravation. From your first comment, it seems that you can hide this from users by adding an entry for "seismo" to your local tables. What's the problem? > ...why in this day and age of Fifth Generation computers, Expert Systems, > and (shudder) Star-Wars, a user has to now learn that SEISMO has become > SEISMO.CSS.GOV, UTEXAS-20 is now R20.UTEXAS.EDU, and UT-NGP has become > NGP.CC.UTEXAS.EDU. Well, aside from the fact that the first and third items in your list are buzz words and research projects, and nobody that I know of has felt motivated to build an instance of the second item to figure out mail addresses yet, this changeover is no worse than, say, the changeover to all-digit dialing, or changes caused by splitting up area codes. Yes, they're painful, but it's a *one-time* cost. The net result, at least in theory, is that with name space administration being decentralized you won't have to work as hard to avoid name collisions. Imagine Sun putting all of its machines on the Internet - not bloody likely, but let's use it as an example. There are ~1600 hosts on our internal net; I suspect the chances that one of their names would duplicate the name of a host already on the Arpanet would be rather high. If the names are of the form "<host>.sun.com", however, we'd just have to avoid duplication within our domain. I'm damned if I'm going to change my machine's name just because somebody at the University of Southern North Dakota also decided to call their machine "gorodish"... And as for "typing those darn stupid domains on every single address", *I* certanly don't find it a problem. My ".mailrc" file certainly helps, since the people I'm likely to send mail to are all in there. If you're really concerned about naive users, consider that those users are likely not to want to think about host names *at all* when sending mail; I'd like to be able to send mail to "Joe Blow" and have the computer worry about where his mailbox resides. If the mail system can do that for you, it's irrelevant whether the name of the target host is "seismo" or "seismo.css.gov" or whatever. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
louie@umd5 (Louis Mamakos) (09/08/86)
Before everyone starts moaning and groaning about having to type those 'long'
domain style names, and the disservice we're doing to our users consider that
this is an improvement. Yes, that's right. It's important to get users in
the habit of fully qualifying their names to eliminate confusion. We added
a machine called 'VENUS.UMD.EDU', with the obvious nicname 'VENUS'. Person
send mail to 'VENUS'. Mail trys to get delivered to ISI-VENUS.ARPA or
something. Person is real confused why this is.
Don't forget, these domain style names are a TRANSPORT issue, not a user
interface one. You can present the user with any interface he desires. If
you don't like the one he sees now, write your own. A lot of people have
worked hard to get this domain stuff usable. I personally like being able
to lookup names of new hosts that aren't in the NIC host table yet.
--
Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center
Internet: louie@trantor.umd.edu
UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louieavolio@decuac.DEC.COM (Frederick M. Avolio) (09/08/86)
Isn't all this sort of like what must've gone on with the evolution of
telephone numbers? It is *much* easier for a person to pick up a
phone, tap the hook two or three times and say "Get me Mary Jones
at the Algonquin Hotel." Well, then there were phone numbers. No
problem. 5 numbers. Then 7. But, long distance?! No problem...
"Hello, long distance? Get me Cleveland. Clevland? I need to speak
to Mary Jones at the Rocky River Motel."
But... What ho! Direct Dialing! You mean I have to remember 10
numbers for someone? So it goes.
What do people who compain about having to type "user@seismo.css.gov"
instead of "user@seismo" do when they address a letter for USPS
delivery? You have to specify street *and* street number! City *and*
state!
--
Fred @ DEC Ultrix Applications Center
INET: avolio@decuac.DEC.COM * Fight the Fight *
UUCP: {decvax,seismo,cbosgd}!decuac!avolio * Rescue the Unborn *louie@umd5 (Louis Mamakos) (09/09/86)
In article <1053@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: > >Isn't all this sort of like what must've gone on with the evolution of >telephone numbers? It is *much* easier for a person to pick up a >phone, tap the hook two or three times and say "Get me Mary Jones >at the Algonquin Hotel." Well, then there were phone numbers. No >problem. 5 numbers. Then 7. But, long distance?! No problem... >"Hello, long distance? Get me Cleveland. Clevland? I need to speak >to Mary Jones at the Rocky River Motel." > >But... What ho! Direct Dialing! You mean I have to remember 10 >numbers for someone? So it goes. But Fred, don't forget long distance carrier codes and country/city codes for international calling. And you thought seismo.css.gov is hard to type or remember! -- Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@trantor.umd.edu UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
henry@mit-trillian.MIT.EDU (Henry Mensch) (09/09/86)
In article <1053@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: > >Isn't all this sort of like what must've gone on with the evolution of >telephone numbers? It is *much* easier for a person to pick up a >phone, tap the hook two or three times and say "Get me Mary Jones >at the Algonquin Hotel." There is *nothing* that stops me from picking up the receiver, hitting the zero key, and telling the operator to "get me Mary Jones at the Algonquin Hotel." It simply costs more. On the other end, bozo@seismo won't always mean bozo@seismo.css.gov; the domain naming system isn't compatable with the old convention. Those who have always picked up the phone and asked for person A at place B can still do this, but folks who mail to bozo@seismo now have to mail to bozo@seismo.css.gov. A change in action is required. This is the difference. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Henry Mensch | Technical Writer | MIT/Project Athena henry@athena.mit.edu ..!mit-eddie!mit-athena!henry
werner@ut-ngp.UUCP (Werner Uhrig) (09/09/86)
> What do people who compain about having to type "user@seismo.css.gov" > instead of "user@seismo" do when they address a letter for USPS > delivery? You have to specify street *and* street number! City *and* > state! talking about Apple and Oranges .... what is at issue here is *NECESSARY* complexity in network Email and how to deal with that in the MOST USER-FRIENDLY way possible ... My argument is that, as long as there is no second site SEISMO on the net it is an atrocity for people to get slapped in the face by the mailer which all of a sudden disavows knowing SEISMO. And, BTW, what is your image of how the *average* user finds out that it is now supposed to be SEISMO.CSS.GOV? Simply *KNOW* what CSS.GOV is and that it is the *obvious* choice? HAH !! Know about "grep" and "/etc/hosts" (and the format of entries in that file)? Fat chance - would work only on UNIX-machines, anyway, on other machines the HOST-tables may not even be user-accessable. Ask your local expert? Right, what do you think he'll tell the third person that calls and asks how he can now reach john@xyzvax or jane@abc-ibm1? Giving them the phone-number of the people responsible for removing the simple aliases without worrying about the user-impact comes to mind ..... (remember, we have seen nothing yet. imagine the terror of *ALL* sites dropping their basic alias.) And dealing with the complexity of multiple aliases in a user-friendly fashion isn't such a difficult problem either (that is ancient problem with several acceptable solutions). First, if there are only few aliases, simple list me a menu of choices to pick from. Second, if there are lots of "matches" try to narrow down the "hits" by asking for additional info, possibly listing some classification keywords. Sound familiar? And after one time of this interactive help, you are likely to remember that SEISMO is now SEISMO.CSS.GOV, if for no other reason than to avoid the delay of the interactive menu .... and for those that happen to forget? no harm done - no insults to their mental capacity called for: here comes the menu again .... As the number of users and sites increases we will, of course, approach a problem not dissimilar to that of sending UPS-mail today. I'll worry about that when we get there, but nothing I have said is any less valid in result ....
rick@seismo.CSS.GOV (Rick Adams) (09/09/86)
In article <3945@ut-ngp.UUCP>, werner@ut-ngp.UUCP (Werner Uhrig) writes: > all of a sudden disavows knowing SEISMO. And, BTW, what is your image of > how the *average* user finds out that it is now supposed to be SEISMO.CSS.GOV? > Simply *KNOW* what CSS.GOV is and that it is the *obvious* choice? HAH !! Well, if we stick to facts, my machine has not generated "seismo" in a return address for at least 2 years. Probably closer to 3. It has been seismo.css.gov since about June 1985 and seismo.ARPA for at least a year before that. If you were replying to mail, it must have been over 2 years old. Or, you didn't notice the return address change in over 2 years. Or, your local system is incorrectly butchering the return address. It was hardly "all of a sudden". How many years are obsolete addresses supposed to be supported? --rick
mark@cbosgd.UUCP (Mark Horton) (09/09/86)
What it boils down to is this: we're moving from a flat name space ("seismo")
to a tree structured name space ("seismo.css.gov"). A flat name space is
easier for the users, as long as the user already knows the name to use.
But as the electronic world grows, flat name spaces become unmanageable.
Can you imagine the telephone model "Operator? Get me John Smith."
being used on a worldwide telephone network? There's a horrible ambiguity
problem (which "John Smith" do you want?) and a routing problem ("where
should I look to find John Smith's phone line?"). Expecting that every
host will always be callable with a single, flat, name like "seismo"
is impossible - you run into name collisions if you don't have a central
registry, and long delays and high costs for registering new hosts if
you do have a registry. (There's also the problem that no one registry
is recognized by everybody: UUCP, BITNET, ARPANET, DEC, etc, all have
their registries, and their own bilbo's and vortex's.)
The price you pay is that you have to type "seismo.css.gov". The benefit
you get is that now, using the same standard syntax, you can communicate
with the rest of the world, such as UUCP (cbosgd.ATT.COM) which you had
to kludge through a gateway address before.
Now, it is a good idea for a particular implementation to try to maintain
upward compatibility when making a change of this magnitude. For example,
on UUCP, we encourage RFC976's addresses like rick@seismo.css.gov, but
we also support ihnp4!seismo!rick and rick@seismo.uucp for upward
compatibility. (We don't promise that these will continue forever,
however.) I would think that on the ARPANET, a mail system that
sees rick@seismo would assume that rick@seismo.ARPA was meant, but
evidently many implementations don't do this.
Those of you (both of you?) complaining about seismo.css.gov should
be grateful you aren't using an X.400 system. (This is what the
phone companies will probably be forcing upon you within 10 years,
since it's now an international standard.) You'll have to run some
nonstandard user interface and fill out a form, like this:
Country USA
ADMD AT&T
PRMD ARPA
Organization Center for Seismic Studies
DDA=Machine seismo
PName:
Surname Adams
Given Name Rick
These names are considered so untypeable that everyone assumes you'll
get it somehow (probably off a piece of incoming mail) and save it
in an alias file.
Markjanssen@milano.UUCP (09/09/86)
In article <1053@decuac.DEC.COM>, avolio@decuac.DEC.COM (Fred Avolio) writes: > What do people who compain about having to type "user@seismo.css.gov" > instead of "user@seismo" do when they address a letter for USPS > delivery? You have to specify street *and* street number! City *and* > state! Actually, just number, street, and ZIP will do. Names are for internal sorting at the address. Bill -- Bill Janssen, MCC Software Technology 9430 Research Blvd, Austin, Texas 78759 ARPA: janssen@mcc.com PHONE: (512) 339-3682 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!janssen
rs@mirror.UUCP (09/09/86)
Smail, distributed in volume 7 of mod.sources, is a UUCP domain
mailer that requires no changes to Unix source. It is free for
the asking from your nearest mod.sources archive site, or the
moderator.
ELM, distributed in volume 6 of mod.sources, is a UUCP domain
mailer/user agent that requires to changes to Unix source. It
is free for the asking from your nearest mod.sources arhive site,
or the moderator.
UUmail, distributedin Volume 4 of mod.sources, is a UUCP domain
mailer that requires no changes to Unix source. It is free for the
asking from your nearest mod.sources archive site, or the moderator.
Listings of the mod.sources arhives and archive sites are done
every couple of months or so in the newsgroup mod.sources.
>/* Written 4:25 am Sep 7, 1986 by mc68020@gilbbs.UUCP in mirror:net.mail */
> That's all right. Obviously, only wealthy sites with source licenses
>should be on the net anyway, right folks?
>tom keller
>{ihnp4, dual}!ptsfa!gilbbs!mc68020
>/* End of text from mirror:net.mail */
No, you don't have to be wealthy, you just have to have some common
sense and intelligence, and be willing to do a bit of research before
shooting off your mouth. Apparently it's easier to get wealthy.
----
Rich $alz {mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!rs
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA 02140
Telephone: 617-661-0777 "Hi, mom!"lamy@utai.UUCP (Jean-Francois Lamy) (09/10/86)
In article <2528@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >Those of you (both of you?) complaining about seismo.css.gov should >be grateful you aren't using an X.400 system. > [...] >nonstandard user interface and fill out a form, like this: Just what are you complaining about? Such information would be useful only for querying a registry, and I've never had to use anything like this in the system I've been using for 2 years (EAN). In fact, the X.400 networks in Canada, Norway, Sweden, Italy and Switzerland all use domain-based addressing exclusively, and gatewaying is absolutely transparent (even to .uucp, .edu, .com, .bitnet and some of .uk). What's more, I've even checked if there were 'lamy's registered in Switzerland and Canada and got the answer in 20 minutes (with both registries 3500miles away from me). I'm all for standards. -- Jean-Francois Lamy AI Group, Dept of Computer Science CSNet: lamy@ai.toronto.edu University of Toronto EAN: lamy@ai.toronto.cdn Toronto, ON, Canada M5S 1A4 UUCP: lamy@utai.uucp
mark@cbosgd.UUCP (Mark Horton) (09/10/86)
In article <2303@utai.UUCP> lamy@utai.UUCP (Jean-Francois Lamy) writes: >Just what are you complaining about? Such information would be useful >only for querying a registry, and I've never had to use anything >like this in the system I've been using for 2 years (EAN). > >In fact, the X.400 networks in Canada, Norway, Sweden, Italy and >Switzerland all use domain-based addressing exclusively, and >gatewaying is absolutely transparent (even to .uucp, .edu, .com, >.bitnet and some of .uk). This comes as a surprise to me, having been told by Europeans that EAN is not really very X.400. (It's an ARPA style domain mail system with an X.400 MTA interface.) Now I happen to LIKE ARPA-style domain systems, but the last I heard, EAN-style systems would have great difficulty sending mail to a true X.400 spirit system with arbitary attributes. (Perhaps EAN has fixed this since I heard.) I also understood that while EAN was being installed in many European sites, it was because there was nothing else available, and Europe was writing some more X.400 spirited software which they planned to use instead of EAN. And I would be very surprised to find out that the X.400 networks themselves were set up to use domains as the network addressing standard. (It would be a pleasant surprise, however.) Perhaps some folks in Europe can set the record straight. Mark
avolio@decuac.DEC.COM (Frederick M. Avolio) (09/11/86)
In article <2308@milano.UUCP>, janssen@milano.UUCP writes: > In article <1053@decuac.DEC.COM>, avolio@decuac.DEC.COM (Fred Avolio) writes: > > ...? You have to specify street *and* street number! City *and* > > state! > Actually, just number, street, and ZIP will do. Names are for > internal sorting at the address. Actually (doesn't make a buzzer go off in your head when someone starts with "actually..."?) in many places the post office will ask for a list of family names of people at the address who will be receiving mail. (Perhaps to avoid mis-directed mail?) Maybe this is only in rural delivery areas. Maybe it is just for my post office. -- Fred @ DEC Ultrix Applications Center INET: avolio@decuac.dec.com * Fight the Fight * UUCP: {decvax,seismo,cbosgd}!decuac!avolio * Rescue the Unborn *
campbell@maynard.UUCP (Larry Campbell) (09/11/86)
In article <78700006@mirror> rs@mirror.UUCP writes: > Smail, distributed in volume 7 of mod.sources, is a UUCP domain > mailer that requires no changes to Unix source. ... > > UUmail, distributedin Volume 4 of mod.sources, is a UUCP domain > mailer that requires no changes to Unix source. ... Um, am I wrong, or do both of these require a pathalias-generated database? Pathalias doesn't run on 16-bit machines. I'd love to run smail, but need a pathalias database. Not everyone can afford a Sun or a VAX just to crunch paths. Sorry if this sounds like a whine... I know I could spend a week hacking pathalias to use temp files, if only I had a spare week... -- Larry Campbell The Boston Software Works, Inc. ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109 UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
barry@adelie.UUCP (Barry A. Burke) (09/12/86)
In article <343@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >In article <78700006@mirror> rs@mirror.UUCP writes: >> Smail, distributed in volume 7 of mod.sources, is a UUCP domain >> mailer that requires no changes to Unix source. ... >> >> UUmail, distributedin Volume 4 of mod.sources, is a UUCP domain >> mailer that requires no changes to Unix source. ... > >Um, am I wrong, or do both of these require a pathalias-generated >database? Pathalias doesn't run on 16-bit machines. I'd love to Um,, you're wrong. There's two ways of using the stuff provided with smail: 1) Hand build a simple database in pathalias format that simply reflects all your direct connections, and have sendmail forward everything it can't handle to a nice nearby neighbor- inother words, handle everything the same way you do ARPA mail now (I have all my `slave' systems route to my domain server, and he figures out the best-way); 2) have one of your pathalias-based nieghbors send you the gateways for all the top-level domains. Anything you can't handle can then be routed to the "volunteer" gateway for handling. Pathalias makes things nice, but Everybody doesn't have to run it. Many of the sites connected to us simply send mail to "adelie!<anyhost>!user" and let my mailer figure it out from there. I'm sure most other sites will be able to find a fiendly neighbor within a hop or two. Then all you gotta do is let smail know how to get there.... -- LIVE: Barry A. Burke, (617) 499-6370 USPS: Adelie Corporation, 125 CambridgePark Drive Cambridge, MA 02140 UUCP: ..!{harvard | ll-xn | mirror }!adelie!barry ARPA: barry%adelie.UUCP@harvard.HARVARD.EDU
avolio@decuac.DEC.COM (Frederick M. Avolio) (09/12/86)
In article <343@maynard.UUCP>, campbell@maynard.UUCP (Larry Campbell) writes: > In article <78700006@mirror> rs@mirror.UUCP writes: > > Smail, distributed in volume 7 of mod.sources, is a UUCP domain > > mailer that requires no changes to Unix source. ... > Um, am I wrong, or do both of these require a pathalias-generated > database? Pathalias doesn't run on 16-bit machines. I'd love to Yes. That is to say, yes you are wrong. Smail, at least, does not require a pathalias data base. All you need is the info in the u.Path files and manually typed paths from your host to eh handful of sites mentioned therein. -- Fred @ DEC Ultrix Applications Center INET: avolio@decuac.dec.com * Fight the Fight * UUCP: {decvax,seismo,cbosgd}!decuac!avolio * Rescue the Unborn *
sample@ubc-ean.UUCP (Rick Sample) (09/12/86)
In article <2530@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >This comes as a surprise to me, having been told by Europeans that >EAN is not really very X.400. (It's an ARPA style domain mail >system with an X.400 MTA interface.) EAN is completely X.400. The limitation in the first distribution of EAN is that it cannot generate or handle arbitrary X.400 addresses, it uses an EAN specific subset. Although the user interface appears ARPA-like, the internals have nothing to do with any ARPA protocols. > Now I happen to LIKE ARPA-style >domain systems, but the last I heard, EAN-style systems would have >great difficulty sending mail to a true X.400 spirit system with >arbitary attributes. (Perhaps EAN has fixed this since I heard.) The first distribution did indeed have these problems, although they were overcome by construction of gateways that performed address translations. This method was employed over a year ago to interconnect with an experimental X.400 system at KDD, Japan. Note that almost all X.400 implementations use only a subset of the X.400 addressing attributes. The next disribution of EAN will be able to accept and generate arbitrary X.400 addresses, using an string encoding based on Steve Kille's RFC. The current development version of EAN has exchanged messages with other X.400 implementations which used different addressing schemes. Rick Sample, University of British Columbia
ahby@meccts.UUCP (Shane P. McCarron) (09/13/86)
In article <343@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >Pathalias doesn't run on 16-bit machines. I'd love to >run smail, but need a pathalias database. Not everyone can afford >a Sun or a VAX just to crunch paths. > >Sorry if this sounds like a whine... I know I could spend a week >hacking pathalias to use temp files, if only I had a spare week... Here in Minnesota, we have a service where a directly connected site can have this site generate a pathalias database for you. There are a number of sites around the country that provide access to the USENET maps. Maybe they would be willing to provide this service as well. I have the software (scripts, actually), and would certainly be willing to pass it along to anyone interested. Alternately, maybe regional sites could be set up to coordinate such a service. It's not really that difficult, and the actual processor time used is pretty minimal. The biggest problem is sending the completed database over the phone, which can take a little time (even when it is compressed). If anyone is interested in attempting to set up region database distribution centers, drop me a line. I think I could at least try to coordinate the effort. -- Shane P. McCarron UUCP ihnp4!meccts!ahby MECC Technical Services ATT (612) 481-3589 "Sinners can repent, but stupid is forever."
dougm@ico.UUCP (Doug McCallum) (09/13/86)
In article <1057@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: >In article <343@maynard.UUCP>, campbell@maynard.UUCP (Larry Campbell) writes: >> In article <78700006@mirror> rs@mirror.UUCP writes: ... >require a pathalias data base. All you need is the info in the u.Path >files and manually typed paths from your host to eh handful of sites If you really want all the paths, you can always talk one of your neighbors into generating the paths for you. Pathalias has the option of generating the paths for sites other than the one it is running on.
grr@cbmvax.cbm.UUCP (George Robbins) (09/14/86)
In article <343@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: > >Um, am I wrong, or do both of these require a pathalias-generated >database? Pathalias doesn't run on 16-bit machines. I'd love to >run smail, but need a pathalias database. Not everyone can afford >a Sun or a VAX just to crunch paths. > >Larry Campbell The Boston Software Works, Inc. Actually pathalias can be made to run on a 16-bit machine fairly easily, it's just that you will only be able to process a fairly small subset of the mod.map database. Here are some alternatives: 1) Talk some bigger site, perhaps at a uucp neighbor to generate a pathalias database relative to your site. It is quite easy to do. Alternativly, you can take their database, and manually edit it so that you go route through their site except where you care to optimize. 2) Find a reasonably local site that does auto-routing and route your mail through there. Some will reroute, whether you like it or not, and some only if your address is incomplete. 3) Manually generate a pathalias style database, or do it incrementally using whatever size chunck of database you can cram through pathalias on you configuration. Note that the generated paths do not really have to be optimal, just good enough that your mail stands a reasonable chance of getting through. Also, the database really doesn't have to be updated all that often. Every six months is probably fine for a leaf site or replying to news postings, assuming that you manually update the database when your mail bounces. ------ There's a certain price associated with taking full advantage of the net and the available software. It's painful that it's so high, and amazing that it's so low... them unless -- George Robbins - now working for, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jsq@im4u.UUCP (John Quarterman) (09/14/86)
EAN is not real X.400, according to everyone I've talked to who claims
to understand X.400 or to have implemented it.
--
John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq
ARPA Internet and CSNET: jsq@im4u.UTEXAS.EDU, jsq@sally.UTEXAS.EDUisrael@umcp-cs.UUCP (Bruce Israel) (09/14/86)
In article <3044@columbia.UUCP> metzger@heathcliff.columbia.edu.UUCP (Perry Metzger) writes: >The following message is a flame against people who think that >domains put too much strain on their minds. Anyone offended >by it is asked not to read further. Yeah, I'm offended by it. I feel that you are gratuitiously insulting people, instead of addressing (what I consider) to be legitimate points. >Poor guy. He had to use his mind a bit. And of course asking him to >make his own aliases for commonly used addresses in his .mailrc would >be too much of a strain on him. You can't alias a host, just an address! I tend to send mail thru seismo to various uucp addresses, so I can't alias strange-site!stranger-site!some-luser@seismo to being at seismo.css.gov since I don't know before hand all the UUCP addresses that I might use. And keep in mind that not every front-end mailer has a personal aliases feature. >It does seem like an insignificant effort, and I do type it on every >single address, whether an alternate still exists or not. Yeah, so do I, but that's because I'm knowledgeable about domains and mailers. I maintain the mail system here, and my rule of thumb for adding things to it is that our users should NOT have to become network experts to send mail. Do you think that everyone should remember all UUCP paths, also? After all, it's the same thing from a users point of view. site1!site2!site3!user is like saying to go to site3 which is in the domain of site2 which is in the domain of site1, which is a domain that we know of. Maybe we should get rid of pathalias also? >You never heard of GREP, have you. And the thought of trying >grep seismo /etc/hosts >never crossed your mind. This is not suprising. At any rate, I just tried >it, and it worked fine. It took 3 seconds. Again, you are assuming knowledgeable people. Many of the users here don't know about network files like /etc/hosts, and they shouldn't have to. It should be handled automatically. >>It would also help if the mailer >>on this and other machines would be able to handle a personal alias-list >>for sites, as well as for users. But then again, I'm not sure it can be >>called progress if NIC's removal of the nick-name SEISMO would result in >>every user adding SEISMO = SEISMO.CSS.GOV to the personal alias-list. > >1. Write a modification to your mailer, if you like. No one is stopping you. I have. I haven't added SEISMO = SEISMO.CSS.GOV to it yet, but I've considered it. However, asking 1000 busy sys admins to each modify their mail system to do something reasonable like this is a bit much, wouldn't you agree? If you don't agree, maybe DEC and IBM etc. should sell computers without OS's, and if you want to do anything special on your computer (like file system storage), then you can write your OS that does exactly what you want it to do! Now, don't interpret this message as a flame against domain-based addressing. I think all your points about why DBA is necessary and useful are valid ones (which is why I deleted those parts of the message without replying). My point is that you don't require extra complexity from users unless it's necessary. If there is only one SEISMO, then mail person@SEISMO should translate out to person@SEISMO.CSS.GOV. If there are more, then mail to that address should return an ambiguous address message, so that the user could more completely specify the address. Case in point: The University of Maryland mail system. I have it set up to work as follows: 'mail user' will go to the user on the current machine, if he exists. If not, it will go to the machine on our local network that the user's account is on. These tables are kept up to date automatically. The rationale is that users should not have to remember on which machine another local user lives. 'mail person@arpa-site' will go to the arpanet site. 'mail person@site.otherdomain', i.e. .bitnet, .csnet, etc. will be routed to a system that can route to the domain. Users need not remember what relays handle what domains. 'mail person@uucpsite' will expand uucpsite to the pathalias route, and go via that route. The idea is that if a person's mail addressing request is unambiguous, that request should be handled, and not subjected to unneccessary complexities. Enough necessary complexities are going to be added when converting the net to DBA with nameservers, without having to add complexities that aren't necessary. Bruce -- Bruce Israel University of Maryland, Computer Science Dept. {rlgvax,seismo}!umcp-cs!israel (Usenet) israel@Maryland (Arpanet)
zben@umd5 (Ben Cranston) (09/16/86)
In article <3437@umcp-cs.UUCP> israel@umcp-cs.UUCP (Bruce Israel) writes: > My point is that you don't require extra complexity from users unless > it's necessary. If there is only one SEISMO, then mail person@SEISMO > should translate out to person@SEISMO.CSS.GOV. If there are more, > then mail to that address should return an ambiguous address message, > so that the user could more completely specify the address. As I am rapidly becoming blue in the face repeating, this is a prescription for a (perceived) breakdown in the future, when the second Seismo comes along and the user perceives that "something that used to work dont any more". > Case in point: The University of Maryland mail system. In point of fact Bruce maintains mail for the Department of Computer Science's machines (this becomes important later). I maintain the software at UMD2 and various people maintain the software on our Unix machines, most notably Louis Mamakos. Bruce Crabill does the dirty work on the IBM mainframes. > I have it set up to work as follows: > 'mail user' will go to the user on the current machine, if he exists. > If not, it will go to the machine on our local network that the user's > account is on. These tables are kept up to date automatically. The > rationale is that users should not have to remember on which machine > another local user lives. This can be done because the Computer Science Department's users are limited in number and closely communicate. What works for 100 users does not always work for 10,000 (consider the N log N time to sort their names, for example). In particular, the Department owns its own machines, and can make the rule: "if there exists a jim@foo and a jim@bar they are the same person!" stick. With every department on campus owning its own computers, *I* cannot make such rules. Thus this scheme cannot in the general case be make to work. > 'mail person@arpa-site' will go to the arpanet site. > ... > 'mail person@uucpsite' will expand uucpsite to the pathalias route... And what, pray tell, happens if there is a name that belongs to both the Internet and UUCP name spaces? One takes precedence over the other? If so, then a new name popping up in the superior domain deactivates the same name in the inferior domain. Users come to you and say "Yesterday I could send to bob@bozo but today it doesn't work any more!". It's a good thing you don't have to support any REAL users... > Bruce Israel > University of Maryland, Computer Science Dept. > {rlgvax,seismo}!umcp-cs!israel (Usenet) israel@Maryland (Arpanet) Ben Cranston University of Maryland, Computer Science Center Systems Programming Group ^^^^^^ -- umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS"
friesen@psivax.UUCP (Stanley Friesen) (09/16/86)
In article <1109@mit-trillian.MIT.EDU> henry@athena.mit.edu writes: >On the other end, bozo@seismo won't always mean bozo@seismo.css.gov; >the domain naming system isn't compatable with the old convention. >Those who have always picked up the phone and asked for person A >at place B can still do this, but folks who mail to bozo@seismo now >have to mail to bozo@seismo.css.gov. A change in action is required. >This is the difference. Actually, my main problem is: how do I find out the domain address of a site? Is there a network equivalent of a phonebook or directory assistance somewhere? If not, is there reasonable way to find out that, say, seismo is actually seismo.css.gov? I have had trouble with this before. Many postings from ARPANET have pseudo-domain names. That is, they list themselves as site.ARPA rather than using a full domain name. Unfortunately, some of the gateways no longer accept names of that format. --- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ??
stuart@BMS-AT.UUCP (Stuart D. Gathman) (09/17/86)
In article <3437@umcp-cs.UUCP>, israel@umcp-cs.UUCP (Bruce Israel) writes: > My point is that you don't require extra complexity from users unless > it's necessary. If there is only one SEISMO, then mail person@SEISMO > should translate out to person@SEISMO.CSS.GOV. If there are more, > then mail to that address should return an ambiguous address message, > so that the user could more completely specify the address. If you are using smail, there is a simple solution: add a 'seismo' line to the /usr/lib/uucp/paths file with your editor. Assuming the domain address is already there, both references to seismo will now work. As far as I can see, the domain structure does not take away any existing features of bang routing. You are still free to type: 'foo!bar!foobar!barfoo!foofoo!barbar!seismo!barf!user' if you wish. The pathalias database in conjunction with smail provides a convenient way to enter 'user@barf' instead. Unfortunately, the network maps are passing 6 Megs in size. That is a lot to broadcast monthly, and some machines can't handle a database that size. On my AT, pathalias can grow to about 900K before getting canned by Xenix. This will handle thousands of paths, but will not handle the entire network. :-( (The overhead for broadcasting maps grows exponentially with the number of machines in the network!) The domain structure provides a way to enter 'user@barf.org.COM' and keep only the path to 'gateway.COM' in your pathalias database to handle all 'user@*.COM' addresses. In fact, I think you could get by with only 1 path entry in /usr/lib/uucp/paths for '.UUCP'. That machine would handle all your mail. It in turn could (conceivably) have only three entries for '.EDU', '.GOV', and '.COM'. If everybody did this, that one machine would be swamped. So, you keep 4 paths in your paths file. Now all your mail get routed through the gateways for '.UUCP', '.EDU', '.COM', '.GOV'. (The UUCP gateway can handle the machines that are not registered if it has a map of them all.) The more paths you keep in your database, the more machines share the work of routing your mail. In many cases (e.g. seismo) you might already have the full routing information available. The point is that domains allow the pathalias database to be distributed around the network. This reduces map maintenance overhead tremendously, as well as reducing the size of database to keep on your machine. Here is an example for 'user@SEISMO.CSS.GOV': (.UUCP implied) first, find SEISMO.CSS.GOV. If found we have a complete route. otherwise, find .CSS.GOV. If found, forward message to there. otherwise, find .GOV. If found, forward message to there. otherwise, find .UUCP. If found, forward message to there. otherwise, we are stuck and can't deliver the mail. If the user types 'user@seismo' instead: first, find seismo. If found we have a complete route. otherwise, find .UUCP. If found, forward so they can look up 'seismo' for us. otherwise, we are stuck. Of course, 'foo!bar!..!..!seismo!user' will still work. If, however, a machine on the way is running smail, it might try to find a shortcut to seismo from its paths file and change the routing. (This option is configured when installing smail.) This can be annoying if the short cut doesn't work. P.S. I am just reading up on this myself and am explaining it partly to help my own understanding. Please correct me (and I'm sure somebody will) if any thing I said is incorrect. -- Stuart D. Gathman <..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>
richl@tektools.UUCP (Rick Lindsley) (09/17/86)
In article <3437@umcp-cs.UUCP> israel@umcp-cs.UUCP (Bruce Israel) writes: > > My point is that you don't require extra complexity from users unless > it's necessary. If there is only one SEISMO, then mail person@SEISMO > should translate out to person@SEISMO.CSS.GOV. If there are more, > then mail to that address should return an ambiguous address message, > so that the user could more completely specify the address. What do you do in boundary conditions? Like, say there is only one seismo now, but next week seismo.com springs into life. What do you do with the users who complain "well, 'user@seismo' USED to work fine". You tell them that you need more specificity now. They tell you that 99% of their mail goes to seismo.css.gov; why not make the 1% of the other mail have to do all that nasty extra typing, and make "seismo" an alias for "seismo.css.gov"? Don't laugh; it's happened here. > Case in point: The University of Maryland mail system. > > I have it set up to work as follows: > > [ ... ] > > 'mail person@arpa-site' will go to the arpanet site. > > 'mail person@uucpsite' will expand uucpsite to the pathalias route, > and go via that route. Aha. So what do you do with "vortex"? Does it go via arpa because that is first in your hierarchy? Sensible, but what do you do when you are used to sending to user@foovax, a uucp site, and suddenly an arpa site called foovax appears. Do you issue an error message? Do you know require the folks to say foovax.uucp? Either way, the behavior has changed, and the users complain. My response has been to push domaining whenever possible, and warning that while user@site is resolved in a certain order as a courtesy, that user@site 's interpretation is subject to change. If you want to be SURE, use user@site.domain, or if domain is UUCP, then use a specific a!b!c!user. We also offer a "pathto" program which searches these things in the indicated order so you can tell when default interpretations have changed. Rick Lindsley co-Postmaster @ tektronix
israel@umcp-cs.UUCP (Bruce Israel) (09/20/86)
In article <1246@umd5> zben@umd5.umd.edu (Ben Cranston) writes: > >As I am rapidly becoming blue in the face repeating, this is a prescription >for a (perceived) breakdown in the future, when the second Seismo comes along >and the user perceives that "something that used to work dont any more". Well, that is already true, since my users have been saying "'person@seismo' used to work, and don't any more". As I will say below, domains are necessary and beneficial. >This can be done because the Computer Science Department's users are limited >in number and closely communicate. What works for 100 users does not always >work for 10,000 (consider the N log N time to sort their names, for example). This is a ridiculous argument (the sorting time portion, I mean). You don't need to sort 10,000 names nightly; you find the difference, (names deleted, names added), and then modify your already sorted list by the differences. > >In particular, the Department owns its own machines, and can make the rule: >"if there exists a jim@foo and a jim@bar they are the same person!" stick. >With every department on campus owning its own computers, *I* cannot make >such rules. Thus this scheme cannot in the general case be make to work. Agreed. Its obvious that such a scheme requires consistent user names across all machines. My point is not that everyone should do this, and I was not suggesting that you do it for the university either. To re-explain my point (since you didn't seem to get it); I was addressing the person whose message I was replying to, whose argument was proof by intimidation and insult ("You can do what you want with more complexity, so you are a crybaby for wanting to do things in a simpler fashion"). I feel that complexity should only be gone to as necessary, and was holding up what I developed at UM as an example of how to make things easier for users without loss of generality or power, NOT as the way everyone should do it. I also was not arguing against domains; I feel that domains are a necessary complexity that in the long run will offer many advantages over a flat naming scheme. >It's a good thing you don't have to support any REAL users... { /* begin flame mode */ Give me a fucking break! We've got around 700 users on our local network. I don't know where you get this fucking superiority shit from! If you are so good in terms of having REAL users, maybe you should come upstairs to our lab and instruct us on how YOU deal with REAL users. What do you do, hit them over the head with a club when they ask questions? Based on the above shit, it's no wonder you don't look at simplifying things for naive users; if you treat them that way, they are probably afraid to ask questions so you don't realize you have any naive users! } /* end flame mode */ Sir, I don't know what axe you have to grind with the department lab, and I'm not really interested either, but let me explain something to you; we have the same general purpose that I assume you do, that being, to run our systems so as to support our user community in the best fashion we know how. Contrary to your obvious belief, our people and your people are not on opposite sides, and I'm sorry if you feel that we are. >Ben Cranston Bruce Israel P.S. flame wars are not necessary or appreciated in net.mail, so if you have any replies to the above flame portion, you can either send them to /dev/null or to me, as you feel is appropriate based on content. -- Bruce Israel University of Maryland, Computer Science Dept. {rlgvax,seismo}!umcp-cs!israel (Usenet) israel@Maryland (Arpanet)
desj@brahms.BERKELEY.EDU (David desJardins) (09/20/86)
In article <205@BMS-AT.UUCP> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes: > >(The overhead for broadcasting maps grows >exponentially with the number of machines in the network!) If this were true the entire capacity of the net would long ago have been given over to maps. The per-site cost should grow linearly; i.e., as the size of the map itself. Thus the total net-wide cost will grow quadratically in the number of hosts in the network. -- David desJardins
mcvoy@rsch.WISC.EDU (Flip Wilson II) (09/22/86)
In article <205@BMS-AT.UUCP> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes: >The pathalias database in conjunction with smail provides >a convenient way to enter 'user@barf' instead. Unfortunately, the >network maps are passing 6 Megs in size. That is a lot to broadcast >monthly, and some machines can't handle a database that size. On >my AT, pathalias can grow to about 900K before getting canned by >Xenix. This will handle thousands of paths, but will not handle >the entire network. :-( Just a note to those who need to make the pathalias database managable on very small machines (ie no disk space). The current method of storing the database is "time-optimal", ie you give it a key and it gives you a full path to that key. One database query. This is great for speed, but it's space worst case. There is a way to get space-optimal by paying time penalty. It's quite simple: For each key store the hop which immediately preceeds the key. Then lookups are a loop in which you build the path backwards until you reach the root (your host machine). For example: to store the path seismo foo!bar!glarch!seismo Store seismo glarch glarch bar bar foo And to build the path you would 1) look up seismo: path = [glarch!seismo] 2) look up glarch: path = [bar!glarch!seismo] 3) look up bar: path = [foo!bar!glarch!seismo] 4) Recoginize that foo is one of the sites to which you have a link and stop. Notes: 1) this is space optimal, it takes 2N -1 units of storages where N is the space to store one key. For 5000 nodes, each ~10 chars, this is 10,000 bytes. 2) This is time worst case. For a N hop path you have N lookups. I assume that you are using the dbm routines, otherwise this is prohibitive. 3) I have implemeted a hacked version of this. If someone wants to clean it up and post it, I'll send him/her what I've done.
rick@seismo.CSS.GOV (Rick Adams) (09/22/86)
Also, note that the time worst case isn't really all that bad. Here is a breakdown of ALL of seismos pathalias routes: 205 ! 2650 !! 3466 !!! 1404 !!!! 554 !!!!! 142 !!!!!! 28 !!!!!!! 2 !!!!!!!! 1 !!!!!!!!! The vast majority of the lookups are only a few accesses.o ---rick
zben@umd5 (Ben Cranston) (09/27/86)
Bruce, I don't want a flame war. That's why I'm not compounding the quoting.
If you will go back and read your own posting you will see that you were
(perhaps inadvertantly) claiming to speak for the entire University.
Your 700 user figure doesn't particularly impress me. The Sperry has over
700 LISTED mailboxes, not to mention the UNLISTED ones. Then there are the
IBM systems, all the machines at Electrical Engineering, and the other people
on campus.
You Computer Science Department people need to acknowlege that there are
other people around who use computers...
Let's take this argument off-line.
--
umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92
umd2.BITNET "via HASP with RSCS"