161 lines
8.1 KiB
Plaintext
161 lines
8.1 KiB
Plaintext
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
|
|
|