Re: Yet another X.400 vs SMTP question
"Eric D. Williams" <eric@isci.com> Thu, 27 May 1993 19:18 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11411; 27 May 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11407; 27 May 93 15:18 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa21903; 27 May 93 15:18 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03785-0@haig.cs.ucl.ac.uk>; Thu, 27 May 1993 19:00:11 +0100
Received: from uu5.psi.com by bells.cs.ucl.ac.uk with Internet SMTP id <g.28436-0@bells.cs.ucl.ac.uk>; Thu, 27 May 1993 18:59:48 +0100
Received: from port8.reston.pub-ip.psi.net by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA12878 for osi-ds@cs.ucl.ac.uk; Thu, 27 May 93 13:59:43 -0400
Message-Id: <9305271759.AA12878@uu5.psi.com>
Received: from isc1.isci.com by isc1.isci.com id <608-0@isc1.isci.com>; Thu, 27 May 1993 13:53:21 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Eric D. Williams" <eric@isci.com>
Subject: Re: Yet another X.400 vs SMTP question
To: Jock Gill <jgill@nsf.gov>, Erik Huizer <Erik.Huizer@surfnet.nl>
Cc: "James (J.K.) Ko" <jamesko@bnr.ca>, Tom Dewitt </PN=TOM.DEWITT/O=GSA2/PRMD=GOV+GSA2/ADMD=TELEMAIL/C=US/@sprint.com>, Tony Genovese <genovese@ophelia.nersc.gov>, OSI-DS <osi-ds@cs.ucl.ac.uk>
Date: Thu, 27 May 1993 13:53:18 -0400
Reply-To: jdavis@radiomail.net
Sensitivity: Personal
Conversion: Allowed
Conversion-With-Loss: Allowed
Encoding: 102 TEXT , 4 TEXT
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 +1(202)331-3990 ewilliams@isci.com or guru@isci.com - Fax +1(202)331-4049 or +1(202)872-0896 "Implementing, Transitioning, and Coexisting = Integrated Solutions - Now!!"
- 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