Re: Yet another X.400 vs SMTP question

["James (J.K.) Ko" <[e-mail]>]

I tend to agree with Erik that we will see more islands of email products 
and  protocols.  Indeed, X.400 (or OSI in that matter) failed because it 
came out too late and far too complex! The original idea was good 
but users just cannot wait for the perfect castle.  Users don't have
infinite time. They need something to work YESTERDAY. 

Here is what I see the problems:

Just take a look at the X.400 spec.: who is going to understand it?
And then there are so many holes in the spec. where users/implementors 
had to fill the holes. Many of these holes are LOCAL IMPLEMENTATION ISSUES!  
So where does it lead us to:  we see something called ECMA profile,
MAP/TOP Spec., and GOSIP profile...  yet another set of profiles!
More confusion!                 

Now comes the version issue: X.400 (88) is not compatible with X.400 (84).
Among other things, there is no such thing called p7,  message store,
or physical delivery in the X.400 (84) implementation. As a user, if 
you already invest in the X.400 (84) product, you are tossed.    
What does it tell us?  The technology is not stable.  Will users 
continue to invest on the technology?  The answer is obviously NO.   

Then there is a protocol conformance problem:  every X.400 product will
need to be certified and compliant with the local administrative authority.
That could take years to get the product certified.  As a user, why would
you want to do that? Why wasting my time on this while I can get something 
easy to work with and readily available. 

Also the ISO/CCITT spec. are usually driven by multi-government officials. 
It is a problem by itself.  Just take a look at the United Nations, you'll
find how decisions are made.  It sure takes a long time to get things to 
approve. Also, it is the very nature of the computing technology where things 
change everyday.  Someone told me that technology obsolete in 18 months! 
By the time officials see the need for changes, it is already four years late. 
While the proposal has to go through the ballatting process, many vendors
are on to something else.  So, in a nutshell, the ISO/CCITT spec. is 
at least ten steps behind.  And the unfortuate part: the ISO/CCITT 
recommendations are, for the most part, still in the revised paper spec. 

On top of all these, ISO/CCITT specs. are too ambitious. It attempts to 
cover everything. But the reality is you can't cover everything. You can't
have one size suite for everybody.  No two men wear the same size.
Just look at the spec itself, you can run TP0 and TP4. And you can 
choose different level of session protocols. These specs also accommodate 
FAX, VOICE, IMAGE, and DATA.  And what do we get today?  We make it for 
data, and fax in some cases. But, what about image and voice? Well, 
maybe another 10 years!  

Despite the existance of GOSIP profile, you'll find vendors continue
to build their products with a note "GOSIP" compliance. Basically it
means it is still proprietary but with hooks builtin to the X.400 
gateways so that it will minimally support the government procurement
requirements.

I don't want to say more about RFC822 because too many people talked 
about it already.  But I think ISO/CCITT should adapt the IETF approach
and make the ISO/CCITT specs more workable. 


James.