greg@ncr-sd.UUCP (Greg Noel) (01/01/70)
In article <1451@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >We looked at the possibility of doing the ihnp4/post style thing as >part of a standard. (Basically, mail to ihnp4!mark.r.horton works, >as will as ihnp4!gjm, the former is a person name, the latter a host.) >There was one killer problem: what do you do with ihnp4!horton? Is >it a login name or a surname? What if it's both? How do you decide >this syntactically, given the layering of a real system? I assume that gjm is a login id, not a host. Or maybe you went to a party where Gary was a host??? Anyway, the heuristic used by ihnp4's code seems to be that if a name has a dot in it, it is syntatctically a person-name to be resolved. I suspect that if I sent mail to ihnp4!horton it would tell me that "horton" was not a known user (although that may be a bad example -- how about ihnp4!bourne?). I suppose the question is how many systems use login names (mail identifiers) that routinely include periods (or underscores, or some separator we can agree on). Somehow, > ihnp4!/pn=Horton_Mark_R or even /pn=mark.horton@ihnp4 (is that slash required?) isn't as aesthetic as mark.horton@ihnp4 although this may be a case where only the mail transfer agent has to deal with such strangenesses and the user agents can hide the uglyness. >which is a special case of a more general MHS X.400 address. .... I've heard about X.400, but I'm afraid I don't know much about it. Is there a copy that I can get easily? Even an ARPAnet copy would be OK; I think I might be able to get my ARPAnet relay to FTP it for me. >As to accepting a public domain piece of software, the issues have >nothing to do with the mailer, but rather involve market demand and >support. If there is market demand for such a feature and a program >to do it were dropped into their lap, the only real questions are >whether it fits into the long term plans, and whether resources can >be allocated to support it. None of these issues is at all clear. Food for thought...... -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
greid@adobe.UUCP (Glenn Reid) (08/05/85)
There are lots of problems with the current mail system, as I don't have to point out to anybody. I think that many things can be learned simply by looking at the U.S. Postal Service, like it or not, which works. For example: on USENET, people are basically at liberty to decide what their site will be called, and what usernames are valid at that site, which starts all these so-called name collisions with mailers. I point out to you that there is far more likelihood for name collisions in street naming (done locally), people naming (done locally), and town naming (also done locally). The Post Office is perfectly happy to let you decide what to call yourself, and where you live. So should USENET be. What they do, however, is to decree that State names need to be uniform, and ZIP codes, even more so. They basically will not deliver a letter without a ZIP code on it, as well they shouldn't. (Debatable). It makes sense for electronic mail to follow some similar convention, which should allocate geographic (probably) zones in which the mail addresses are to be evaluated, and have several levels of delivery. To draw another analogy, consider the various lines on a USmail address. The Post Office starts reading AT THE BOTTOM, not at the top. Why not have more than one line for electronic mail messages, like so: Address: adobe!greid Area: SILICON.VALLEY State: CA ZAPcode: 94303-852-0271 (arbitrary) The problem at the moment is that net addresses are dependent upon machine names, which is never going to be constant for long. There need to be basic geographic or policital address conventions, with a mechanism for deciding what computer is actually going to deliver the mail. Then any given mailer only has the responsibility of getting the message first to the proper geographic area, then some computer who claims to represent that area (or zip-code, if you will), can forward it from there. "THAT IS A DOMAIN," I can hear people shouting. Perhaps, but domains at present are set up at random and without any particular heirarchical or geographic method. There is no standard. And the domain names are completely arbitrary. If they were broken down, say, by STATE NAME, then it would be reasonable for each computer to maintain a table of all 50 states and where to deliver mail that it receives with that State name in it. An 'aliasing' system, which doesn't really require that my computer know anything about the real route. For instance, if I send mail bound for Massachusetts from my computer, (we have no direct links to MA), our mailer looks in its table under MA and finds: decwrl. Aha. decwrl is in California, everybody knows that. But my mailer sends it to decwrl anyhow. Decwrl then looks at the message and says, "Aha. Massachusetts." In decwrl's table under MA might be MIT-something, so it sends it there. And so on. This means that the return route MIGHT NOT BE THE SAME as the sending route, but who cares? It allows for path optimization, changing routes very simply, and for more sensible routing in general. The next problem arises once the mail gets into the proper state, but that is where the ZAP code comes in (or whatever). First, decwrl (or whoever) will look at the first line of the address. If it doesn't know the address, it will look at the ZAP code, to determine where next to send it. Again, this code will evaluate to another computer name, but it can be changed ON THAT MACHINE without ever changing the net address that the original sender types in at his end. And computers in California would only need to maintain tables for areas in california, and so on. This would work. Why don't we do it? Glenn Reid ..decwrl!adobe!greid
lauren@vortex.UUCP (Lauren Weinstein) (08/06/85)
One of the problems with state-based schemes (or any system that doesn't encourage the use of direct or semi-direct hops--that is, local exceptions to "route to the state handler" routings), is that it tends to put a tremendous amount of load on the particular site that is acting as that gateway (usually for free) and encourages what might be called "sloppiness" in tables. My own view is that local tables should only resort to sending to "gateway" machines for a geographic area (or a logical area, which makes more sense the way some regions are set up) when more specific local information isn't known. For example, many sites call vortex directly. If mail is addressed to vortex.UUCP (for example) they should call directly if possible. Sites that have specific enough information to route to vortex would use whatever information they have, even for multiple hops. Only if all else failed would routing be done through the top-level domain and subdomains (e.g. CA). If too much reliance is put on "gateway" subdomain servers, they will swamped. Also, in many cases routing will be much slower than more direct routes. For example, getting to vortex is generally much faster through a number of East coast machines than the most common West coast machines--and tables should be aware of that fact whenever possible. If all mail to vortex routed through the theoretical CA site, rather than using better information when available, not only would that CA site be footing unnecessary costs but message turnaround time would be increased as well. --Lauren--
chris@umcp-cs.UUCP (Chris Torek) (08/08/85)
Let me see if I can take Lauren's suggestion and get pseudo-code out of it. If I ever get shanghaid into hacking mailers, I would probably implement the "UUCP" "domain" like this: rmail: given <string>!<string>, just forward by direct UUCP to the first host in <string>, doing what rmail has always done with these. If it fails, return to sender. Rmail is a transport system, not a router. Note that I ignore any @-signs in <string>!<string>. rmail: given <string> with no !s, hand it to mailer. mailer: given <string>!<string> with no @-signs, just hand it off to uux. (Pretend to be a transport system; no routing.) mailer: given <user>@<string.UUCP>, look up "string" in our local UUCP database and see if we have a route for it. (I.e., given "cbosgd.att.uucp" see if we know how to get to "cbosgd.att".) If so, then it should hopefully be a fully specified ! string, and I hand that straight to uux (without even looking at it). (In this case I would get "seismo!cbosgd" as the full route. Note that you can put arbitrary stuff in the database if you think it will "work right".) Otherwise, do a "nameserver lookup" on the "domain" part of "string" (excluding UUCP---there is no top level uucp name server), again by a local UUCP database lookup (different database though). E.g., if I don't know "cbosgd.att" then I look for "att". If I can get there, then I take the string I get back from that, append the original address, and hand *that* to uux. Just for completeness, here's an example if I get (say) user@tinyhost.smalluniv.bigcity.calif.uucp: 1. look under "full routes for hosts" for tinyhost.smalluniv.bigcity.calif.uucp; fails. 2. look under "partial routes for domains" for smalluniv.bigcity.calif.uucp; fails. 3. look under "partial routes for domains" for bigcity.calif.uucp; fails. 4. look under "partial routes for domains" for calif.uucp; succeeds; I get "seismo!vortex" (vortex is such a smart router :-) ), so I send to seismo!vortex!user@tinyhost.smalluniv.bigcity.calif.uucp In other words, if I don't have a route for the full domain name, I will try to find a route for what I have put into my database as the "domain server" for the partial domain. It is entirely the responsibility of *me* to have correct data in my UUCP database. My database can be as extensive (or not) as I want. Also, I am depending on myself (again) not to put "dumb" hosts in my "partial routes for domains" table. I could (it would be a bad idea but I could) put myself in for something, causing a mail loop. I could also put a host in that I thought was smart, but actually wasn't, again causing a mail loop. If I find I've done that, I change my database. Also, if I am a "partial route for domains" for someone else for maryland.uucp, then things work too. Suppose someone else, let's call him otherguy@hishost.hisuniv.uucp just to give him a "full name", uses my scheme to send to user@sphinx.ee.maryland.uucp and gets me as his partial route for maryland.uucp. He sends to hplabs!hao!seismo!umcp-cs!user@sphinx.ee.maryland.uucp. Now (if everyone is using my algorithm, or if they're running v7 rmail), that finally gets here and all the ! stuff has been used up and rmail gets "user@sphinx.ee.maryland.uucp". Since this doesn't have !s, rmail pops it over to the mailer, which looks up sphinx.ee.maryland.uucp and finds it, and sends the mail off to "eneevax!umd-sphinx!user"---which is the right place. (Or maybe it can only handle ee.maryland.uucp and routes it to "eneevax!user@sphinx.ee.maryland.uucp" for further processing.) Finally, down!honey can still do his tricksy pathalias stuff and send to what I label "user@sphinx.ee.maryland.uucp" by sending to "princeton!seismo!umcp-cs!eneevax!umd-sphinx!user", and that works too. (Isn't backwards compatibility fun?) Of course, this does not address what happens in the user interface, nor with crossover between DARPA Internet and UUCP (but we're not supposed to do that anyway). I'll think about that later. . . . Another problem is that I have this huge UUCP routing database duplicated at lots of UUCP sites. down!honey just has a huge pathalias database duplicated at lots of UUCP sites, which is clearly better, right? :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
chris@umcp-cs.UUCP (Chris Torek) (08/08/85)
Whoops, last point (I promise!---at least until someone starts arguing): if one uses my scheme and has an empty "partial routes for domains" database, then the situation is just like when we used to just look up the uucp hostname in the flat-namespace-database (which is what we are doing right now). If both db's are empty, then the situation is like it was under V7: one must always use full routes, rather than domainified names. (Sorry about the typo (it's shanghaied, not shanghaid)....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jlm@stl.UUCP (John "Rainbow" Messenger) (08/09/85)
Lauren is quite right to stress the importance of a mailer using direct paths whenever possible. My understanding of the domain-based scheme is that forwarding to the next-higher-subdomain-host is done only when a route is not known to the destination. The advantages of not using the "pass it to my next-higher-domain-host" approach except when necessary are cost, speed, non-overloading of that host and preservation of net anarchy (ie if you pass everything up, then down, the guy at the top is in control in a big way - what happens if he crashes? or stops cooperating? - passing messages directly keeps you (more) independant of the hosts above). -- -- John Messenger (...!mcvax!ukc!stc!stl!jlm)
henry@utzoo.UUCP (Henry Spencer) (08/11/85)
> ... If they were broken down, say, by STATE NAME, then > it would be reasonable for each computer to maintain a table of all 50 > states and where to deliver mail that it receives with that State name > in it. ... This sort of idea has come up before. The problem is that geography in general, and state boundaries in particular, has little to do with good routing. The classic case, which I *think* has now been cleared up, is that for a long time there were two disjoint sets of machines in Colorado, with no in-state links between them. Geography does show some correlation with routing, mostly because long-distance charges are tied to geography, but arbitrary groupings are hard to avoid if you want a solid basis for routing decisions. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jww@sdcsvax.UUCP (Joel West) (08/15/85)
>In article <5866@utzoo.UUCP>, Henry Spencer writes > This sort of idea has come up before. The problem is that geography in > general, and state boundaries in particular, has little to do with good > routing. The classic case, which I *think* has now been cleared up, is > that for a long time there were two disjoint sets of machines in Colorado, > with no in-state links between them. Geography does show some correlation > with routing, mostly because long-distance charges are tied to geography, > but arbitrary groupings are hard to avoid if you want a solid basis for > routing decisions. Anyone of us who has thought about the problem and still likes geography is aware of this distinction. Many of my (gould9) best links are out-of-town, and for a while, all of them were. I have no direct links to anywhere in usa.ca.n, but plenty to att.nj and usa.fl. However, geographic domains have several advantages: 1) They are unambiguous, clear, and indisputable. If I know henry is in Toronto, then I know his domain is "ON.CAN" (or whatever). I don't have to guess what his organization is. When he joins the net (if he's a new user) he doesn't have to agonize over which domain to join and, in fact, to domain headquarters (domainhq@cbosgd.IL.USA) will automatically grep and grok "Ontario" and spit out ON.CAN 2) In terms of reliability, geographic is as good as any. Sure, there are some cases where geographic is bad--I now would send to any Calif. AT&T site via ihnp4. However, no scheme will be perfect and the choice is really arbitrary. 3) It keeps phone costs down. When the net explosion hits, a lot of needless phone calls out of state will eliminate the desireability of UUCP at many sites. Perhaps it will tend to encourage people to use more sensible routings rather than crossing the country three times. 4) It will encourage more local ("free") connections. People will tend to exchange connections with major sites in their area. I think this is a good thing. 5) DOMAINS != ROUTES As has been noted, domains are a logical address space, and only imply routings for the dumbest of sites. Almost any site can replace "rmail" with something that goes through a pathalias database. Those paths will be optimally routed for frequent correspondents. If an occasional message to an unknown site is confused by a misleading domain and takes a suboptimal route, so what? If it arrives, it's better than the present system. Joel West CACI, Inc. - Federal (c/o Gould CSD) {decvax!sdcsvax,ihnp4!bonnie}!gould9!joel gould9!joel@NOSC.ARPA
jer@peora.UUCP (J. Eric Roskos) (08/19/85)
>> Geography does show some correlation with routing, mostly because long- >> distance charges are tied to geography ... > 3) It keeps phone costs down. I have a little doubt about this, because the change in the phone charges is not a linear function of the distance. Thus delivering a message by 3 "short" hops usually costs a lot more than delivering it by two longer ones (or, ESPECIALLY, one to a particular state, and then one by a non-local intrastate call). The geographic domains also don't take into account the fact that many large corporations have special phone arrangements to reduce their costs for calls within the company. > 5) DOMAINS != ROUTES ... and only imply routings for the dumbest of sites. Well, then, offer a counter-argument. I've already advanced an argument that domains do equal routes in many cases for all but an omniscient nameserver; and that, in fact, domain-ed site names can't even be considered to be "names" in a formal sense of the word. [It would help to define "route", though.] -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Gurl ubyq gur fxl/Ba gur bgure fvqr/Bs obeqreyvarf..."
greg@ncr-sd.UUCP (Greg Noel) (08/21/85)
In article <1156@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >If I ever get shanghaid [sic] into hacking mailers, I would probably >implement the "UUCP" "domain" like this: > > [I tried to cut this down to the portion I wanted to talk about, but > it still ended up 50 lines. Instead, I recommend that you go back and > read the original article; there's much food for thought. The thing > I wanted to discuss was the section on his "mailer."] > Hmmmmmm...... This is very interesting, since it parallels what I have been thinking about. However, instead of a database that converts host.in.a.domain into partial!path!prefix to be handed to uux, I would propose that the data base convert it into a command. So, in your example, you would convert "tinyhost.smalluniv.bigcity.calif.uucp" into something like "uux -<%F seismo!rmail (vortex!%U@%H)" which would then be expanded into "uux -</tmp/mailXXXXX seismo!rmail (vortex!user@tinyhost...etc...uucp)" and executed. Assuming I got the uux syntax correct, this is semanticly equivalent to what you are suggesting and has the advantage of being able to utilize whatever outbound channel is appropriate, not just uux. As I see it, there are several issues, given here in no particular order: - What about partial matches? What if I said tinyhost.bigcity.calif? Or even just tinyhost.calif and it was unambiguous? Should I be a good guy and just quietly correct the address? Or should I noisily blast out a message telling of the change? Or how do I resolve an ambiguous name? It's obvious that it should be reflected to the user for resolution, but in the best of all possible worlds, it should only require an indication of which of the possible addresses was correct. - Is is possible to automaticly (or semi-automaticly) update the database? Seemingly, it would be only a fairly minor modification to pathalias to allow it to generate this database. (Sorry, Peter, but it seems that domains and pathalias \do/ mix.) The difficult, nasty, and potentially impossible problem would seem to be to create the appropriate incantation for cross-domain mail. - How would we address the switchover? Since netnews seems to be the major distribution agency for all of us, would it be possible to send it out as part of the news distribution? On the one hand, that would seem to be a relatively painless mechanism; on the other, we all know how easy it is to get all the sites to upgrade their news systems. (I think that it should be part of the netnews package, and it should live in /usr/lib/news/dmail. At least you could then have a pretty good idea if the recieving site ran it.....) (BTW, I'll bet you didn't know that it is possible to send a full path name as a command via uux. All it takes is for the full path name to be in L.cmds. I do this for commands that I don't want local users to access directly. I've wondered why rmail and rnews weren't treated this way......) - There should be some way of getting the mail to the right person even if they don't know the username. By analogy with the post office, I recieve mail as "Greg Noel," "Gregory Noel," "J. Gregory Noel," "J. G. Noel," and sometimes even "Occupant." (I told the postoffice that the latter individual no longer lived there, but they \won't/ forward the mail to him.....) Anyway, I should be able to send mail to mark.horton@cb.att.uucp and have it arrive, even though I don't know that his username is "mark" and his account is on the "d" machine of OSG (Operating System Group?) this week; this same database could also serve as a uniform method of forwarding mail if someone moves. The issue here is how to set up something that would resolve names without them being fully specified; i.e., if I tell it that "j.gregory.noel" is really "greg", what can it do with "greg.noel"? Or, what could it do with "steve.bourne"? - Once we get this working, how do we get it picked up by the major vendors, specificly AT&T and Berkeley? How will it work along side of (in conflict with?) the standard mailer? Delivermail? Sendmail? But all of this is moot unless this somehow gets turned into a program. Did I hear you volunteering to be shanghaied? If so, I'll offer to help; I probably have about as much copious spare time as Spaf, but it is of some importance to my company, even if they don't know it yet. And to the rest of you who've been adding more heat than light on this topic, how about a little constructive help? There are more issues than I have identified above; what are they? Why would the scheme outlined by Chris and amended above \NOT/ work? Peter, we already know from your previous papers that pathalias can convert a hostname into a transfer channel (link) and a remaining path; what else is required to produce a database of commands (or other incantations) that actually cause the mail to be sent? -- Onward...... -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
chris@umcp-cs.UUCP (Chris Torek) (08/24/85)
[As Greg says, read the parent article, it's too hard to summarize here.] As far as the internal format of my proposed database, I was intentionally leaving that unspecified; we already have a database that uses "printf-like" format controls (the host name is straight text, with a single occurrence of "%s" for the user name; in fact, the string is handed to sprintf inside sendmail, if I understand Bruce's hacks correctly). It is definitely an implementation issue, and printffy formats are probably the way to go. (Note that with Greg's format I could easily use the proposed "bang domain name" scheme, mapping userX@hostY.partialroutedom to %R!%D!%U, where %R is the route, %D is hostY.partialroutedom, and %U is userX, in this case. Also note that the scheme used is per-host, another very nice feature during experimentation periods at different hosts....) As for final delivery to a real user given a (potentially ambiguous) real name (as opposed to a mail identifier---on Unix systems this is one's login name), that should certainly be standardized, but it is a separate issue from mapping fully-qualified host names (whether they be pathalias- found by examining uucp edge databases or whether they be domain names) to routes, and probably belongs in a separate program (the local host mail deliverer in our case). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
greg@ncr-sd.UUCP (Greg Noel) (08/29/85)
I got a surprising amount of mail about this -- usually what I post seems to not draw any replys at all. (Maybe I'm not controversial enough!) In any event, I thought I'd hit some points that seemed to have caused some confusion. As context, I got a note telling me that Mark Horton's "smail" program (which is what creates those strange return addresses that look like ...!cbosgd!cbosgd.att.uucp!...) does a lot of what Chris and I were discussing. I dropped a line to Chris about it; apparently he has gotten a Beta (Alpha?) test version to play with. I managed to get a copy of the documentation and have looked it over, and although there are some things I would have done differently, there is a lot of careful thinking that has gone into the program. When can \I/ get it? In article <1370@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >[As Greg says, read the parent article, it's too hard to summarize here.] > >(Note that with Greg's format I could easily use the proposed "bang >domain name" scheme, mapping userX@hostY.partialroutedom to %R!%D!%U, >where %R is the route, %D is hostY.partialroutedom, and %U is userX, >in this case. Also note that the scheme used is per-host, another >very nice feature during experimentation periods at different >hosts....) That's what I had in mind. The ideal would be that the server would be flexible enough (have enough printffy codes) that any routing scheme could be used, as needed. There would potentially be several programs that provided input to the hosts-to-routes data base (I can envision a program that directly converted hosts.txt, for example) and it would be very easy to experiment with differing schemes. To clear up something that several people seemed confused about, I would like to have \no/ specific knowledge about output channels in the server; I would create the complete command that would conceptually be executed directly by the system() function (although I would probably optimize the actual command execution the same way that "make" does). In other words, it would map a domain name into a mailer command, filling in whatever is necessary to see to it that the mail gets delivered. In other word, \all/ of the routing decisions would be made outside of the mail server. In particluar, the "don't use the ARPAnet unless there is no choice" decision would be made by the routing program, \not/ by the mailer itself. It is quite possible that several routers could be developed, each catering to a different community and embodying different decision criteria. One program might be used on a home computer that would know how to route to neighbors and would route everything else to a smart friend while another program might be useful to the host that has nothing but direct connections (say, on a LAN). >As for final delivery to a real user given a (potentially ambiguous) >real name ..., that should certainly be standardized, but >it is a separate issue from mapping fully-qualified host names >... to routes, and probably belongs >in a separate program (the local host mail deliverer in our case). The concept of a name-resolver was well-received, although it seemed to be new to a lot of people. Some seemed to think that I originated the idea. Sorry, 'tain't so. I believe that several sites within AT&T run such a name resolver; ihnp4 is one that I know about. I just wanted the facility to be more readily available. (It may even be possible to use the ihnp4 code -- does anyone know the history of that program? Or more information on what it will do?) CSnet also has a facility for sending a query to a central database which will try to resolve it into a mail ID that can be used manually. Not only that, there is at least one machine has a name server that runs finger on a name you send it and it mails you the result. Anyway, you identify the exact problem area. Indeed, the local host mail deliverer should do such a thing. The point is, which one? Practically all mail servers, "smail" included, assume that they know how to deliver mail to the local system and go right ahead and do it. If it is going to be standardized, and I agree that it should be, now is as good a time as any, and it would probably be easier to do it in a domain mail server, since the routing decision for "this person unknown" or even "person-name data base not supported" looks a lot like the routing decision for a unknown domain -- i.e., route it to a smarter neighbor. Several people pointed out the issue of ambiguity and imprecise specification of user names, apparently not realizing that steve.bourne is ambiguious. I agree, it's a difficult thing to do right. I would err on the side of returning the mail and giving the possible resolutions. Presumably, if this became common, user-level mail handlers could detect this returned mail and just allow the user to pick the right one and automaticly resend the mail. Obviously, there's a lot to be considered. Then again, it may not be possible. One of my respondants suggested that AT&T is moving away from RFC-based things and that they may not accept a public-domain version of their mail-name resolver. Anybody have any insight on this? -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
mark@cbosgd.UUCP (Mark Horton) (09/02/85)
In article <271@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >The concept of a name-resolver was well-received, although it seemed to >be new to a lot of people. Some seemed to think that I originated the >idea. Sorry, 'tain't so. I believe that several sites within AT&T run >such a name resolver; ihnp4 is one that I know about. I just wanted the >facility to be more readily available. (It may even be possible to use >the ihnp4 code -- does anyone know the history of that program? Or more >information on what it will do?) We looked at the possibility of doing the ihnp4/post style thing as part of a standard. (Basically, mail to ihnp4!mark.r.horton works, as will as ihnp4!gjm, the former is a person name, the latter a host.) There was one killer problem: what do you do with ihnp4!horton? Is it a login name or a surname? What if it's both? How do you decide this syntactically, given the layering of a real system? As a result, the standardized syntax for personal names will probably look something like this: ihnp4!/pn=Horton_Mark_R which is a special case of a more general MHS X.400 address. In some ways this is not as pretty, but we know how to implement it in all cases. >Then again, it may not be possible. One of my respondants suggested that >AT&T is moving away from RFC-based things and that they may not accept a >public-domain version of their mail-name resolver. Anybody have any >insight on this? AT&T is too large to be moving in only one direction at once. Right now there seem to be three major directions: UUCP bang syntax, RFC920 domain syntax, and X.400 MHS syntax. The long term favorite is MHS. As to accepting a public domain piece of software, the issues have nothing to do with the mailer, but rather involve market demand and support. If there is market demand for such a feature and a program to do it were dropped into their lap, the only real questions are whether it fits into the long term plans, and whether resources can be allocated to support it. None of these issues is at all clear. Mark
peter@graffiti.UUCP (Peter da Silva) (09/03/85)
> > Address: adobe!greid > Area: SILICON.VALLEY > State: CA > ZAPcode: 94303-852-0271 (arbitrary) > > For instance, if I send mail bound for > Massachusetts from my computer, (we have no direct links to MA), our mailer > looks in its table under MA and finds: decwrl. Aha. decwrl is in California, > everybody knows that. But my mailer sends it to decwrl anyhow. Decwrl then > looks at the message and says, "Aha. Massachusetts." In decwrl's table > under MA might be MIT-something, so it sends it there. And so on. > > This means that the return route MIGHT NOT BE THE SAME as the sending > route, but who cares? It allows for path optimization, changing routes > very simply, and for more sensible routing in general. This is the first sensible scheme I have seen. I don't, however, see the reason for the ZAPCODE or even the local code. States are fine... how about the following: TX!shell!graffiti!peter We'll have to add something to deal with the TX for the smart mailers. Dumb mailers can just send to someone who knows TX. Nobody need to assign names: there already is such an assignment. So for me to get to CA!ucbvax!fair all I'd have to do would be to mail to someone who has the memory and a recent enough mailer to support state name addressing, like, say ut-sally (don't hit me, John!). If too much stuff is going through ut-sally, I get a nasty letter back & start sending stuff through ihnp4. Or through someone else. This way no-one NEEDS to take on an excess load. shell!ut-sally!CA!ucbvax!fair shell!ihnp4!CA!ucbvax!fair You would just make sure your path was unambiguous up to some major site, one which you are certain wasn't going to change their name. Most people are capable of handling short routes in their heads... they're simpler than most addresses. This would not break existing dumb mailers (and some are far dumber than anything the domain-types can possibly imagine), nor would it put undue strain on gateways (they just need to know how to get to a given state, possibly through their own net to another gateway. Or they could even act as dumb mailers & forward stuff to the ghods). So it looks like a domain. It doesn't require either changing the syntax, a task harder than you might think, nor creating a central authority. I don't expect anyone to pay any attention to me, since I'm just a lowly peon who can't afford a machine big enough to compile pathalias on... but in case anyone has got this far, consider it...
mark@cbosgd.UUCP (Mark Horton) (09/11/85)
In article <278@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >In article <1451@cbosgd.UUCP> mark@cbosgd.UUCP (Mark Horton) writes: >>We looked at the possibility of doing the ihnp4/post style thing as >>part of a standard. (Basically, mail to ihnp4!mark.r.horton works, >>as will as ihnp4!gjm, the former is a person name, the latter a host.) >>There was one killer problem: what do you do with ihnp4!horton? Is >>it a login name or a surname? What if it's both? How do you decide >>this syntactically, given the layering of a real system? > >I assume that gjm is a login id, not a host. Or maybe you went to a >party where Gary was a host??? Yes, I meant login-id. I noticed the typo shortly after it was too late to fix. Sorry, Gary. >Anyway, the heuristic used by ihnp4's code seems to be that if a name >has a dot in it, it is syntatctically a person-name to be resolved. I >suspect that if I sent mail to ihnp4!horton it would tell me that "horton" >was not a known user (although that may be a bad example -- how about >ihnp4!bourne?). I suppose the question is how many systems use login >names (mail identifiers) that routinely include periods (or underscores, >or some separator we can agree on). Somehow, >> ihnp4!/pn=Horton_Mark_R >or even > /pn=mark.horton@ihnp4 (is that slash required?) >isn't as aesthetic as > mark.horton@ihnp4 >although this may be a case where only the mail transfer agent has to >deal with such strangenesses and the user agents can hide the uglyness. > The X.400 standard allows you to send to an address with the following semantics: "the guy in XYZ Inc whose surname is Horton" (the syntax is all binary so I can't type it here, besides I don't have it memorized.) Using dots, there is no way to generate this, e.g. ihnp4!horton would be how it's done, but that's ambiguous. A trailing dot causes lots of problems, especially typographical ambiguity ``send it to "ihnp4!horton."'' and human factors/error handling considerations. Also, the ihnp4 scheme doesn't handle generational qualifiers such as "Jr" or "III". When you add them, you get a result that makes it impossible to pick out which word is the surname (at least, I can't figure out how to do it.) While I really do like the ihnp4 syntax, I can't see how to generalize it to handle full X.400 semantics. The proposals aren't as pretty, but they work. >>which is a special case of a more general MHS X.400 address. .... > >I've heard about X.400, but I'm afraid I don't know much about it. Is >there a copy that I can get easily? Even an ARPAnet copy would be OK; >I think I might be able to get my ARPAnet relay to FTP it for me. I'm told there is no machine readable copy (Xerox has an out of date one, there are lots of fonts and tables.) You should be able to order a copy from OMNICOM (for a significant charge) at 703-281-1135. Mark
jer@peora.UUCP (J. Eric Roskos) (09/11/85)
> If too much stuff is going through ut-sally, I get a nasty letter back & > start sending stuff through ihnp4. Or through someone else. This way no- > one NEEDS to take on an excess load. > I don't expect anyone to pay any attention to me, since I'm just a > lowly peon who can't afford a machine big enough to compile pathalias > on... but in case anyone has got this far, consider it... The scheme you have described is what I have been calling the "distributed nameserver" scheme, which in MY "lowly peon" opinion, is the way to do it. I disagree with the geographic sudomain scheme for cost reasons, but aside from that, you have just described the routing string generated by a nameserver when it routes a message to the next nameserver down the line. PS - you don't have to compile pathalias on your machine to use the approach we've been talking about. I certainly don't have it on my PC (which has only 1 500K and 1 1MB floppy disk... hardly enough for the pathalias database!). -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Nalgvzr gbzbeebj, gur cubar'yy evat, naq lbh'yy or ba lbhe jnl. Onpx ubzr va Buvb, gurl jba'g oryvrir lbh..."
gds@mit-eddie.UUCP (Greg Skinner) (09/15/85)
There isn't any way for ihnp4 to know that ihnp4!horton is actually
ihnp4!cbosgd!mark, especially if thefre is a horton on ihnp4. However,
if there isn't, I suppose this simple scheme can be used when you only
know the last name.
when mailing to host!user,
if "user" maps to a local name on host, deliver it to user (ie. search
/etc/passwd),
else, apply the database searcher to "user" (the only problem is that
there may be many "user"'s in the database, and I don't know if it is
politically correct to return a list of possible completions of "user"
to the sendng agent)
else, just return the mail as usual.
Gary and Mark, is this currently done from outside AT&T? I know it's
done internally.
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.edugds@mit-eddie.UUCP (Greg Skinner) (09/15/85)
There isn't any way for ihnp4 to know that ihnp4!horton is actually
ihnp4!cbosgd!mark, especially if there is a horton on ihnp4. However,
if there isn't, I suppose this simple scheme can be used when you only
know the last name.
when mailing to host!user,
if "user" maps to a local name on host, deliver it to user (ie. search
/etc/passwd),
else, apply the database searcher to "user" (the only problem is that
there may be many "user"'s in the database, and I don't know if it is
politically correct to return a list of possible completions of "user"
to the sendng agent)
else, just return the mail as usual.
Gary and Mark, is this currently done from outside AT&T?
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.edujsq@im4u.UUCP (John Quarterman) (09/18/85)
In article <1617@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: (>> is quotes from Peter da Silva) >> If too much stuff is going through ut-sally, I get a nasty letter back & >> start sending stuff through ihnp4. Or through someone else. This way no- >> one NEEDS to take on an excess load. > >> I don't expect anyone to pay any attention to me, since I'm just a >> lowly peon who can't afford a machine big enough to compile pathalias >> on... but in case anyone has got this far, consider it... > >The scheme you have described is what I have been calling the "distributed >nameserver" scheme, which in MY "lowly peon" opinion, is the way to do it. >I disagree with the geographic sudomain scheme for cost reasons, but aside >from that, you have just described the routing string generated by a >nameserver when it routes a message to the next nameserver down the line. The incident he referred to did not involve a nameserver: it involved me trying to keep my system from being swamped. In other words, he's proposing manual routing by somebody other than the sender. Thank you very much, but I decline the privilege of being the manual nameserver for central Texas. Your scheme, on the other hand, is reasonable. -- John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq ARPA Internet and CSNET: jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPA
gjm@ihnp4.UUCP (Gary J. Murakami) (09/18/85)
ihnp4 currently expects addresses in the form ihnp4!first.last in order to access the corporate directory as a nameservice. There is no guarantee that this will work at any given time since the directory periodically changes without notice. I've had some ideas for years on how to allow more exact specification of people information, but I haven't had the time to do any implementing. FYI, as Peter and Lauren (thanks for the appreciation) have mentioned, I'm leaving Comp Center Networking Department at Indian Hill to go to New Jersey to work on Datakit Exploratory Development in Piscataway/Liberty Corners. I hope to transition most of the ihnp4 related work to several other people (details to follow). I'm hoping that the level of service will not degrade to much, and I'll probably try to pitch in where necessary. However most of the postmaster queries will be answer by other people or by form letter. -Gary (still reachable via ihnp4!gjm)
peter@graffiti.UUCP (Peter da Silva) (09/24/85)
> In article <1617@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: > (>> is quotes from Peter da Silva) > >> If too much stuff is going through ut-sally, I get a nasty letter back & > >> start sending stuff through ihnp4. Or through someone else. This way no- > >> one NEEDS to take on an excess load. > > > >The scheme you have described is what I have been calling the "distributed > >nameserver" scheme, which in MY "lowly peon" opinion, is the way to do it. > >I disagree with the geographic sudomain scheme for cost reasons, but aside > >from that, you have just described the routing string generated by a > >nameserver when it routes a message to the next nameserver down the line. > > The incident he referred to did not involve a nameserver: it involved > me trying to keep my system from being swamped. In other words, he's > proposing manual routing by somebody other than the sender. Thank > you very much, but I decline the privilege of being the manual nameserver > for central Texas. (1) I never suggested that any one machine be "the" nameserver for anywhere. What's to stop 3 or 4 sites from taking on that task? Or 6? Or as many as are needed? (2) Did I refer to an incident? All I said was that if too much mail goes through a given machine... and since you seem to be acting as the ad-hoc nameserver for central Texas you seemed to be a convenient example... then you will be told so and you can use someone else. (3) I was further back in old messages than I thought, since I've seen other, more experienced, netters suggest pretty much the same thing since my suggestion seems to be redundant. However I would like to suggest that however domains/nameservers/etc are set up they use the only syntax that everyone understands... "!" syntax.