Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cheops.cis.ohio-state.edu!karl From: karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.protocols.tcp-ip Subject: Re: New Host-Requirement RFCs Message-ID: Date: 27 Oct 89 16:46:32 GMT References: <8910252236.AA14405@alw.nih.gov> Sender: news@tut.cis.ohio-state.edu Organization: Ohio State Computer Science Lines: 108 In-reply-to: raf@cu.nih.gov's message of 25 Oct 89 22:37:28 GMT raf@cu.nih.gov writes: But CompuServe is essentially a single host No, it most emphatically is not. There are numerous subdomains of compuserve.com. E.g., csi.compuserve.com CompuServe, Incorporated (employees) doi.compuserve.com US Department of the Interior ncr.compuserve.com NCR is a CompuServe business services customer and if there weren't blocks in place on both sides of the gateway, these would work: fax.compuserve.com email => FAX mci.compuserve.com (oh, just imagine what MCI would have thought of that...:-) CompuServe has hundreds (thousands?) of business services customers, plus connections to (what I understand is) quite a variety of external gateways. They are all addressable. Internally, an address somebody@csi.compuserve.com translates to something twisted like ">csi:somebody." There are 3rd-level subdomains of doi.compuserve.com as well (e.g., fws.doi.compuserve.com, mms.doi.compuserve.com); I don't even know how those addresses map internally. When you have a network of many non-Internet hosts operated by independent organizations the problem becomes much more difficult. I operate nameserver and mailer arrangements in varying levels of peculiarity for something like 20 organizations, not including anything at Ohio State proper. That's the sort of thing I do in my spare time, for fun. Anyone with a serious, job-dedicated need to do such things could manage an order of magnitude more than that with little change in complexity. One can either adopt domain naming on the non-Internet network (as the UUCP network did, I believe) or build some sort of translation between the two name spaces into the gateway. Neither one is necessarily very easy to do. If it isn't trivial to do, then the organization's internal mailer arrangement is in a serious state of disrepair, and deserves to be overhauled anyway. CompuServe's internal arrangement appears to me to be internally consistent, so the mapping is truly trivial. There was no internal overhaul in their case. In fact, the original, proof-of-concept alpha test gateway didn't affect any software on the CompuServe side at all. CompuServe literally didn't know what I'd built until I told them (by writing mail to relevant people through the gateway, of course :-). In the latter case, the biggest problem is getting all the organiztions registered and collecting the information to do the translation. Each organization can be responsible for providing such a collection of registry information. If the organization can't provide that sort of information, I really must question their ability to manage email of any kind. Even FIDONet manages that (fidonet.org, IFNA [International FIDONet Association]). And when you are done, users still have to be aware of two forms of addresses. CompuServe users are aware of only one generic style of addressing: ">GatewayName:WhateverThatGatewayUnderstands". Thus, they address FAX stuff as >fax:phone#, and MCIMail users as >mci:someusername, and Internet sites as >internet:user@host.domain. Very generic, in their view. Similarly, I prefer only one addressing standard, domain style, and that's all I have to deal with for CompuServe. If I'm on XYZ net (which does not use domains) and I want to tell my friend on the Internet how to mail to me, I will still have know the name of my host on the Internet. That is exactly why the concept of the DNS works so well. Tell me, on what network does CompuServe exist, that they get email of any kind? You don't know - you don't have to know, and that's the whole point of domains. They remove the transport-centric forms of mail addressing and leave that to lower levels of software which care where the bytes get sent. Users don't (shouldn't) care. The idea of telling someone "I'm on XYZ net" is passe'. (BTW, if you're guessing, no, CompuServe is not UUCP-based, either. Should I have created "B-Protocol Net" and then tried to tell everyone, "CompuServe is addressable as user.name@compuserve.bprot," after the fashion currently required by non-DNS-cognizant BITNET sites? Only inertia keeps .BITNET alive.) For that matter, on what network is, e.g., MorningStar.COM or HDL.ORG or UDayton.EDU, entities for which I also do nameservice and mailer support? Same response: You don't know because you shouldn't care. The mail "just gets there." If your network doesn't use domains, it should, and it is very clear to me that this is not because it is "the Internet standard," but rather because it works, from anywhere. All you need is a way to query the DNS registries. UUCP does this via comp.mail.maps info, the Internet via nameservers. P.S. - If it's all so easy, how come the From address in the message that I am replying to had an ! in the local part? My mailers and news software generate @-format DNS, RFC-compliant addresses in every case except for UUCP mail gatewaying, and even then, it's still usually @-format. I posted my note as a Usenet news article, guaranteed to have been in @-format as karl@cheops.cis.ohio-state.edu. If you've got a ! in the From: address, it's because somebody's gateway mailer botched the job. An error in implementation does not invalidate the standards which were supposed to have been implemented. --Karl