Received: from rip.psg.com by fido.wps.com (5.67/1.34) id AA02535; Tue, 11 May 93 08:48:59 -0700 Received: by rip.psg.com (Smail3.1.28.1 #5) id m0nswZf-00030HC; Tue, 11 May 93 08:48 PDT Message-Id: Date: Tue, 11 May 93 08:48 PDT From: randy@psg.com (Randy Bush) To: tomj@fido.wps.com Subject: John on FidoNet Status: OR > Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU > Path: psgrain!uunet!noc.near.net!howland.reston.ans.net!paladin.american.edu!auvm!INFOODS.UNU.EDU!KLENSIN > Return-Path: <@AUVM.AMERICAN.EDU:owner-devel-l@AUVM.AMERICAN.EDU> > Return-Path: <@AUVM.AMERICAN.EDU:KLENSIN@INFOODS.MIT.EDU> > X-Envelope-to: DEVEL-L@AMERICAN.EDU > Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Content-transfer-encoding: 7BIT > Mail-System-Version: > Message-ID: <737126189.286103.KLENSIN@INFOODS.UNU.EDU> > Newsgroups: bit.listserv.devel-l > Date: Tue, 11 May 1993 09:16:29 -0400 > Reply-To: John C Klensin > Sender: Technology Transfer in International Development > > From: John C Klensin > Subject: Re: A Cheap and easy WAN > In-Reply-To: <01GY0US5QWGI0006J7@INFOODS.UNU.EDU> > Lines: 127 Warning: People who don't want to hear about email technology should stop reading. Right here. -------- Robert Johnston writes... >But, Fidonet in the G7 countries is an amatuer's ball game. UUCP/SMTP >mail is the tool of choice for most professionals. Robert, Emotionally and technologically, I really want to agree with you. In most practical terms, probably I do. But I think we have some misunderstanding here that might be worth trying to fix. I'm going to try to be objective below and confine my comments to facts, rather than my personal preferences (although those might be obvious in places). FIrst of all, it is not proper to talk about UUCP/SMTP as if it were one entity. SMTP is a mail transport protocol for TCP/IP networks, e.g., the IP-connected Internet. _It_ is almost certainly the "tool of choice for most professionals" with a lot of other things (including UUCP transports) acting as surrogates when the IP links are not available. That distinction, and the preference, is as true in Africa as it is in Washington, DC. We get away with talking about UUCP and SMTP and, for that matter, BITNET mail, as if they were the same thing because they all use "RFC 822" header formats and therefore represent about the same information in about the same ways. I put "RFC 822" in quotes because some provisions of that specification are, in practice, interpreted differently in different environments, something that has caused no end of problems. Mail moving from one of these systems into another must pass through mail transport gateways but, in principle, the translations should be easy and should involve no information loss. In practice, it apparently (I continue to be astonished by the number of screwups I see) isn't that easy, and nasty things occur at the boundaries, but we get by. We've also got a number of commercial email vendors who use proprietary, rather than RFC822, formats internally but who have managed to develop gateways that work really smoothly with the IP-Internet (and SMTP). In terms of market share, Compuserve and MCIMail figure prominently on that list. It is also worth noting that, in spite of the fact that the market share of the obsolete 1984 version is quite small and growing very slowly and that the production-use market share of the 1988 version is probably zero, X.400-based solutions are being aggressively pushed by a number of international organizations, notably the World Bank. Whether X.400 systems and SMTP/ RFC822 ones interoperate depends on your definitions and patience: differences in information model, lack of a standard presentation form for addresses, and difficulties in finding appropriate gateways and routes can make things very difficult. So, what, if anything, is wrong with FidoNet? Well, first and most important, it has a reputation as a low-end, poor person's, amateur toy among people who haven't studied it and think that anything they don't know and use is substandard. They should know better, but those attitudes are prevalent in the industry. In practice, it requires gateways to get traffic into the IP-SMTP "spine" that, de facto, ends up connecting all of the long-haul alternatives. But that isn't the problem--UUCP, BITNET, X.400, and the proprietary commercial email systems also require gateways. The sequential "I send it to him, who sends it to her, who sends it to you" architecture can result in very slow handling of mail, but UUCP uses exactly the same model with exactly the same risks. The difficulty is that its message header formats and information structures, like those of X.400, don't map obviously into SMTP and RFC822. In the case of X.400 the quantity of information is about the same or greater (although not obviously equivalent); in the FidoNet case, there is somewhat less. And, for X.400, a number of very smart people have spent years trying to rigorously define the mappings (resulting, most recently, in a 100+page document called RFC1327 that, I suspect, only a few dozen people in the world have actually read and studied) while this level of effort has not been applied to FidoNet (at least partially because it is a lot less complex). We should be working on ways to make FidoNet <-> UUCP/RFC822 and SMTP/RFC822 gateways more seamless, possibly by figuring out better ways to use more RFC822-like formats over FidoNet transports or by extending the formats in other ways to provide/preserve more information. If you temporarily ignore the message format and information loss problems, there is only one major difference between FidoNet and the "professional" UUCP, SMTP-over-IP, and NJE (BITNET) group. The problem with the latter mail protocols is that they assume links that are reasonably high reliability and that have low or zero cost per marginal message bit sent. FidoNet transport is designed to deal with the other extreme: messages are compressed to minimize line time, message sending can be restarted if links fail mid-transmission, etc. That makes it an appropriate technology for lots of developing areas; conversely, as other technologies advance, it may make it suboptimal--as compared to arrangements using more RFC822-compatable forms--in many situations in the G7 countries. I have to agree, however, that it tends to be isolating and create islands. While it shouldn't be the case, people tend to think about the whole network infrastructure on the basis of what they see locally and what they know from their local environment. At least in part because of its transport model, FidoNet users have developed vocabulary and ways of thought that make it difficult for them to communicate with UUCP or SMTP types. Some of them also get defensive about "their" technology in ways that makes migration more difficult than it should be when shifts in resources make other alternatives more reasonable. That is really unfortunate, but the same difficulties most assuredly occur between SMTP and UUCP users and between BITNET and SMTP users--this is not a unique FidoNet problem. What I find ironic here is that the most serious international mail interoperability problems are experienced with what people persist in thinking of as the very lowest-end (FidoNet) technology and with what they persist in thinking about as the highest-end one (X.400). >Just as a debate can >be levied re: Macs and DOS Clones, or Novel vs. Banyan, market share >leads directly to interoperatability. With email, one needs to be a little careful about this line of reasoning. Regardless of market share taken one enterprise at a time, many of these systems are designed for LANs and do not scale well to international networks. The gateways that are required to connect two identical systems over a WAN mail transport are sometimes of sufficiently lousy quality to cause very poor interoperability even among instances of identical products. --john