From randy@psg.com Tue May 11 08:49:08 1993
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: <m0nswZf-00030HC@rip.psg.com>
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: <MultiNet-MM(330)+TOPSLIB(156)+PMDF(4.2)@INFOODS.UNU.EDU>
> 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 <KLENSIN@INFOODS.UNU.EDU>
> Sender: Technology Transfer in International Development
> <DEVEL-L@AUVM.BITNET>
> From: John C Klensin <KLENSIN@INFOODS.UNU.EDU>
> 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