Re: Yet another X.400 vs SMTP question
"James (J.K.) Ko" <jamesko@bnr.ca> Thu, 27 May 1993 15:09 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07874; 27 May 93 11:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07870; 27 May 93 11:09 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12681; 27 May 93 11:09 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.02718-0@haig.cs.ucl.ac.uk>; Thu, 27 May 1993 14:03:09 +0100
Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id <g.16191-0@bells.cs.ucl.ac.uk>; Thu, 27 May 1993 14:02:52 +0100
X400-Received: by mta x400gate.bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 27 May 1993 08:58:18 -0400
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 27 May 1993 08:58:10 -0400
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 27 May 1993 04:57:00 -0400
Date: Thu, 27 May 1993 08:57:00 +0000
X400-Originator: /DD.ID=1658744/G=James/I=JK/S=Ko/@bnr.ca
X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; bcars735.b.479:27.04.93.12.58.10]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: Yet anoth...
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "James (J.K.) Ko" <jamesko@bnr.ca>
X-Orig-Sender: "James (J.K.) Ko" <jamesko@bnr.ca>
Message-ID: <"10480 Thu May 27 08:58:13 1993"@bnr.ca>
To: Erik.Huizer@surfnet.nl
Cc: jgill@nsf.gov, genovese@ophelia.nersc.gov, osi-ds@cs.ucl.ac.uk
Subject: Re: Yet another X.400 vs SMTP question
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.
- Yet another X.400 vs SMTP question Tony Genovese
- Re: Yet another X.400 vs SMTP question Eric D. Williams
- Re: Yet another X.400 vs SMTP question Alf Hansen
- Re: Yet another X.400 vs SMTP question Jock Gill
- re: Yet another X.400 vs SMTP question James (J.K.) Ko
- Re: Yet another X.400 vs SMTP question Tony Genovese
- re: Yet another X.400 vs SMTP question Jock Gill
- Re: Yet another X.400 vs SMTP question Erik Huizer
- Re: Yet another X.400 vs SMTP question Steve Goldstein--Ph +1-202-357-9717
- Re: Yet another X.400 vs SMTP question James (J.K.) Ko
- re: Yet another X.400 vs SMTP question Tony Genovese
- Re: Yet another X.400 vs SMTP question Eric D. Williams
- Re: Yet another X.400 vs SMTP question Eric D. Williams
- Re: Yet another X.400 vs SMTP question Jon Crowcroft
- Re: Yet another X.400 vs SMTP question Colin Robbins
- Re: Yet another X.400 vs SMTP question Marco A. Hernandez
- Re: Yet another X.400 vs SMTP question Erik Huizer
- Re: Yet another X.400 vs SMTP question Erik Skovgaard
- Re: Yet another X.400 vs SMTP question Steve Kille
- Re: Yet another X.400 vs SMTP question Erik Skovgaard
- Re: Yet another X.400 vs SMTP question Jock Gill
- Re: Yet another X.400 vs SMTP question Jock Gill
- Re: Yet another X.400 vs SMTP question Erik Skovgaard
- Re: Yet another X.400 vs SMTP question Erik Skovgaard
- Re: Yet another X.400 vs SMTP question Alan.Young
- Re: Yet another X.400 vs SMTP question Julian Onions
- Re: Yet another X.400 vs SMTP question Steve Goldstein--Ph +1-202-357-9717
- Re: Yet another X.400 vs SMTP question Jock Gill
- Re: Yet another X.400 vs SMTP question pays
- Re: Yet another X.400 vs SMTP question Alf Hansen
- Re: Yet another X.400 vs SMTP question Sylvain Langlois
- Re: Yet another X.400 vs SMTP question Eric D. Williams
- Re: Yet another X.400 vs SMTP question Steve Kille
- Re: Yet another X.400 vs SMTP question Erik Skovgaard