Re: Yet another X.400 vs SMTP question

["Eric D. Williams" <[e-mail]>]

Jock,

Although many different types of E-Mail systems exist: LAN E-Mail (cc:Mail,
MS-Mail), X.400, RFC822/SMTP, MIME/E-SMTP, PROFS, et. al.  There is one key
element which deliniates the comparison and interoperability issues involved,
Directory Services aka. Address Mappings (Aliasing).

Within the architectures of most personal and organizational messaging systems
the idea of the "standard directory" has been mitigated by the desire to
increase market share, in the case of commercial vendors; and avoiding the
problem, in the case of many other messaging protocols.  Some "hacks" have been
made to alleviate the basic problem: Finding addresses; however, most mail users
would agree that the way to gather E-Mail addresses is to accrue adressing
information from messages recieved or from some type of flat file scheme.  Many
methods have been developed but not statndardized in the ISO/ANSI/IEEE sense.

These problems are now being addressed, as they relate to messaging, by an
attempt to develop X.500 "like" and X.500 Directory services to support
proprietary and other messaging systems and Application Protocol Gateways (read
this as Messaging Gateway in this context i.e. SMTP to X.400).  Erik brings up
an interesting point:

>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.

This is the crux of the problem.  For interoperability to flourish, transition
elements must be introduced into the architecture _first_ to alleviate the
confusion (new E-Mail addressing syntax(es), management problems (aliasing mail
addresses for transfer between gateway systems).  These are issues that face
many that wish to trial, or transition to, newer/more robust/emerging 
technologies.

An example of a key transition element is the Application Protocol Gateway (APG)
which supports X.400(84 and 88), X.400<->SMTP g/w services, as well as the
standards based approach of X.500 Directory services (DS) to provide address
mappings and address resolution for disparate mail DS and pointers to conversion
services, g/w et.al.


>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.

It is certainly true that each suite of protocols continues and will continue to
become more robust.  But the messaging protocol itself, and the benefits of
message routing and support of multimedia attachments, is only fully realized by
"all" when used in conjunction within a transition/coexistence architecture,
with the introduction of globalized DS.  For example:

X has a message with a unstructured binary attachment (say a MS-Word document),
and he wants to use his MIME messaging User Agent (UA) to send it to Z.  But Z
only has WordPerfect and cc:Mail.  The DS (the is potential only guy's, although
I think I read a survey where Mitre would like to see this :-) ) could at the
request of a Message Transfer Agent (MTA) or Gateway, look up the recipient (Z)
and hand off little tid bits like Z can only user WordPerfect, the Gateway/MTA
finds the body part via its MIME gateway component and reformats the body part,
or invokes a file conversion utility; pointed to by the DS, and has it converted
prior to cc:Mail transport.  To Z this is transparent (although we all know doc
conversions are never transparent ;-) ) and the integrity of the contents are
preserved (what X wants Z to see is his bold face stuff and italics...)

The comparison of messaging systems and TCP/IP v. GOSIP/OSI (this includes the
IGOSS) is a complex one indeed, especially when we introduce the proprietary
domain.  However it is _very_ important to remember that the general community
has and always will balk at the idea of turning on the switch at 12:00am and
going to a diferent system.  Transition elements must be introduced first and
schema for "mapping" the apropos services must be developed before the changes
are made (no matter how insignificant the change may seem).

BTW, I do have a draft document concerning issues faced during transition, and a
pretty detailed discussion of transition and conexistence of E-Mail systems.  I
think it presents a fair and concise analysis of the benfits and caveats of the
"standards" based messaging worlds.  I can make the document available in
postscript or fax it (about 30 pages) to your office, or courier it, as we are
in DC.  Any one else who would like to take a look or make comments drop me a
line.

To conclude:

It's not just who you ask, but also what you ask, to prevent a flame war.  X.400
(88) and X.400 (84) deployments have been mitigated by factors other than the
mere existence of P7 and true P3 (88), remember EDI is growing, and thats
primarily in the realm of X.400 (although I think some kludges have been made to
other "transports").  Also MIME, is very robust and in actual use can easily be
touted as the "up and coming" protocol of choice.  But I reiterate, with out DS
to synch. the various communities, none (I said none!) of these protocols, is
the clear winner.  X.400 (88) has facilities for the use of DS and others
(proprietary, et. al.) are following that path.  Also remember InterNIC is
planning a transition to a White Pages style DS to replace WHOIS and wouldn't be
nice to lookup a mail address from your desktop using Directory Assitance
(split-DUA for TCP) or LDAP/Mail enabled applications, for gateway addresses and
alias mappings.  Enough...Peace to all.  Please respond with comments.


Peace,

Eric

  Eric D. Williams     Integrated Systems and Communications, Inc.        ISC
1899 L Street N.W. Suite 500 - Washington, DC 20036-3884 - Voice [phone]
 [e-mail] or [e-mail] - Fax [phone] or [phone]
  "Implementing, Transitioning, and Coexisting = Integrated Solutions - Now!!"