Re: Yet another X.400 vs SMTP question

Steve Kille <> Fri, 28 May 1993 20:00 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa13849; 28 May 93 16:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13840; 28 May 93 16:00 EDT
Received: from by CNRI.Reston.VA.US id aa20915; 28 May 93 16:00 EDT
Received: from by with Internet SMTP id <>; Fri, 28 May 1993 19:18:36 +0100
Received: from by with SMTP (PP) id <>; Fri, 28 May 1993 19:20:38 +0100
To: Erik Skovgaard <>
Subject: Re: Yet another X.400 vs SMTP question
Phone: +44-71-721-7582
In-reply-to: Your message of Thu, 27 May 1993 09:10:42 -0700. <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 May 1993 19:20:33 +0100
Message-ID: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <>


A man of your experience in messaging technology and the market really
should know better than to send out a message containing such arrant

 >From: (Erik Skovgaard)
 >Subject: Re: Yet another X.400 vs SMTP question
 >Date:  Thu, 27 May 93 09:10:42 -0700

 >You must be kidding!
 >No wonder, you do not think much of X.400 when all you have used is PP.
 >Although the effort is appreciated, I must tell you that PP is not up to
 >par with commercial implementations.  

PP should now be considered a commercial implementation.   The ISODE
Consortium is supplying it as base technology, and there are a number
of (large and small) vendors offering PP based products.   If you
would like further information, please contact <>

PP has a  research community heritage.   There are some difficulties
with this, and these are the primary motivation behind the formation
of the ISODE Consortium.   However, these are more than compensated
for by the richness of the overall functionality of PP (this is the
wrong place to go into this).

PP compares very favourably with all other commercial X.400
implementations, and in many areas PP is a clear market leader.

 >The code is bulky, 

There is some truth here, although it is mostly a reflection of the
broad functionality offerred by PP and ISODE as a whole.

 >slow and has

Not true.   This really is not an issue with PP.   Some of the busiest
sites on the Internet use PP for message switching.

 >not passed conformance testing.

Not true.   Would you like me to send you a copy of the PCTR? 

 >I have used X.400 for many years (since 1984) and have not found any
 >RFC-822 mailer that is as good.  

This clearly gets down to aesthetics.   Some users like and would die
for the strangest of interfaces.   As a strong promoter of X.400,  I
have clearly heard the message that the availability of good UAs is a big
issue (i.e., I disagree with you here).

 >But I am even out of date.  Some of
 >the newver X.400 Remote UA products are very good.

I will definitely agree here.   There are a number of very attractive
products that have been introduced recently, and X.400 is looking much
much better than a year back.

 >So let's agree that it is a matter of taste and stop this rediculous
 >badmouthing of X.400 that some people on Internet seem to indulge in.

There are valid points, and you should listen.   

 >No matter how much people try, X.400 cannot be stopped since it
 >serves the need of many large organizations and governments - the
 >customers that *pay* for products and services.

You are essentially saying that X.400 will happen because it is
inevitable.  I think that the GOSIP style of procurement has done vast
damage to X.400, as it has lead to many products which are
unbelieveably awful.   They meet GOSIP requirements, but in no way
address user needs.    This sort of product has done great disservice to
X.400, and led to much of the disillusion of the form expressed on
these lists.

I believe that X.400 will succeed - but that this is by no means
inevitable.  The window to restore credibility is not that wide.
X.400 will succeed partly on the basis of postioning and partly on the
basis of technical richness.    There are no over-riding deficencies.
Even the  addressing does have some benefit, and addresses a
lot of the practical issues of service provision by multiple
providers.   The success of X.400 will depend on vendors taking a
user-oriented view, and building product as opposed to protocol

 >Any typos are to be blamed on line noise - a problem with connectionless

Good grief!  You are saying that because TCP is built on a
connectionless IP, that there will be corruption of characters?  I
guess that we should all move to X.25. I trust that this important new
insight is being shared with the APS (Asynchronous Protocol Alliance).

 >Cheers,                         ....Erik.

Steve Kille
ISODE Consortium