Re: Yet another X.400 vs SMTP question

Erik Huizer <Erik.Huizer@surfnet.nl> Thu, 27 May 1993 12:39 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03924; 27 May 93 8:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03920; 27 May 93 8:39 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07800; 27 May 93 8:39 EDT
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Thu, 27 May 1993 13:04:01 +0100
Date: Thu, 27 May 1993 13:04:01 +0100
X400-Originator: osi-ds-request@cs.ucl.ac.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/; haig.cs.uc.365:27.04.93.12.04.01]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Thu, 27 May 1993 13:04:00 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Erik Huizer <Erik.Huizer@surfnet.nl>
Message-ID: <9305271112.AA03224@survival.surfnet.nl>
To: Jock Gill <jgill@nsf.gov>
Cc: "James (J.K.) Ko" <jamesko@bnr.ca>, genovese@ophelia.nersc.gov, osi-ds@cs.ucl.ac.uk
In-Reply-To: <Pine.3.05a.9305262026.K29385-a100000@note1.nsf.gov>
Subject: Re: Yet another X.400 vs SMTP question
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903

Jock,

Interestingly enough the same debates rage through Europe currently. The
EEMA (European Email Association), which harbours the most important ADMD
and PRMD operators in Europe has invited Internet experts to talk on
Interconnection issues and possibillities on june 10th at Schiphol airport
(Amsterdam).

Especially in Europe where CEC regulations have led to a much broader
acceptance of X.400 as WAN E-mail protocol (the WAN is intentional) than
anywhere else, the National Service providers for Academic and research
networks, have lot's of experience with both RFC-822/Internet mail and
X.400, and of course with gateways between them.

The problem with X.400 as I see it is that it had the chance to become THE
E-mail protocol, from workplace to workplace. Due to the complexity of the
X.400 protocol, however, implementations so far a not delivering the quality
of userinterfaces, systemmanagement and routing capabilities that their
Internet based counterparts do.  

In the mean time Proprietary E-mail packeges have stormed the LANs
(CC:-mail, MS-mail etc.) with friendly and well integrated user interfaces
that will not easily be replaced by products that talk X.400 (or RFC-822 for
that matter). The more so because OSI conformant products for the LAN are
far from ubiquitous. 

Proprietary protocols require gateways to the WAN E-mail protocol of your
choice (X.400(84/88/93) or SMTP/RFC-822/MIME/PEM), and that will lead to
confusion, management problems, limited usage and overall loss of service.
Therefore it is probably best to make sure that proprietary protocol usage
is prevented by offering a standard alternative, that has enough choice in
implementations with a high quality of User interfaces, and a high quality
of routing and management infrastructure. Currently, The internet suite of
protcols wins on this front from the X.400 based suite. X.400(88) is coming
up and will certainly improve things, but at the same time the Internet
protocols improve likewise.

My view is that there is no way we get rid of the Internet mail protocols
anymore, nor can we get rid of X.400. What we should fight for is to keep
it limited to these two, and prevent Lotus, Novell and Microsoft of becoming
so dominant with their LAN-E-mail protocols and associated WAN tunneling
mechanisms, that we end up with even more than two Wide area E-mail
protocols.

I'll finnish this too long mail with a recommandation (It's European, so you
may ignore it :-)
Allowing the Internet protocols within GOSIP will thus improve the chances
of limiting the WAN E-mail protocols. If you don't do it people will search
for alternatives and end up with gateways to X.400 which will start
tunneling all kinds of unstandardised traffic.


Erik Huizer
SURFnet bv

(Also Internet Engineering Steering Group Applications Area Director)