Will@uunet.uu.NET (03/26/91)
I have several questions regarding X.400:
1) Is there currently any definition of X.400 running over TCP/IP?
Assuming that the various Internet bodies see X.400 as the way to
go (by the way, do they?), then how will they transition from SMTP
style addresses to X.400 addresses?
2) I've noticed that a lot of vendors are using X.400 as a way to
gateway between different proprietary email systems (as opposed to
incorporating X.400 style addresses directly into the user interface
of the email product). Is my observation correct? In the case of
using X.400 as a gateway and not incorporating X.400 style addresses
into the user interface, does it then become the duty of the X.400
administrator to setup a correspondence in the gateway between the
X.400 name and each of the corresponding names in the proprietary email
system? This makes me think that X.400 would be expensive to maintain.
Thanks,
Will Estes Internet: Will@cup.portal.com
UUCP: apple!cup.portal.com!Willkoorland@vancouver.osiware.bc.ca (Neil Koorland) (03/27/91)
> 1) Is there currently any definition of X.400 running over TCP/IP? RFC 1006 specifies the mapping of ISO Transport over TCP, which is the most commonly used method of running X.400 over TCP/IP in the Internet. > Assuming that the various Internet bodies see X.400 as the way to > go (by the way, do they?), then how will they transition from SMTP > style addresses to X.400 addresses? There is a significant degree of support for X.400 in the Internet but not not universal or even majority support. In any case there is and always will be a need for SMTP<->X.400 gateways. The mapping between RFC 822 (format used by SMTP) and X.400 is specified in RFC 987 and RFC 1148, including the address mapping. > 2) I've noticed that a lot of vendors are using X.400 as a way to > gateway between different proprietary email systems (as opposed to > incorporating X.400 style addresses directly into the user interface > of the email product). Is my observation correct? In the case of > using X.400 as a gateway and not incorporating X.400 style addresses > into the user interface, does it then become the duty of the X.400 > administrator to setup a correspondence in the gateway between the > X.400 name and each of the corresponding names in the proprietary email > system? This makes me think that X.400 would be expensive to maintain. It really depends on the non-X.400 addressing structure. For some (e.g. RFC 822) there is an algorithmic mapping which requires minimal table maintenance. For others there is more administrative overhead. However the maintenance is not prohibitive with any reasonable system since most address mapping only affects the most significant portions of the address i.e. at the domain level. ----------------------------------------------------------------------------- Neil Koorland OSIware Inc. Tel: +1-604-436-2922 200-4370 Dominion St Fax: +1-604-436-3192 Burnaby, B.C. CANADA V5G 4L7 Internet: <koorland@vancouver.osiware.bc.ca> ------------------------------------------------------------------------------
pcl@pegasus.att.COM (03/27/91)
Will,
In regard to your question to "mhsnews" about email service providers
using X.400 as a gateway to other providers and how that gets reflected
in the user interface - I can explain a bit of what we do in AT&T Mail
(now part of AT&T EasyLink Services). We do use X.400 to gateway
with (many!) other service providers (other ADMDs), as well as to
connect to some of our customers who operate PRMDs. It is a gateway,
in that we do have our own (ASCII-based) message header format within
our network, but we also give our users a way of entering O/R addresses
when sending mail out to users in other domains. We give them a way
of abbreviating X.400 domain names into a single token, but they can
also spell out the complete O/R address if they choose - with either
form, they just have to prefix the address with "mhs!" to indicate that
it is to go through the X.400 gateway (in keeping with our general use
of UUCP-style addresses). So a (fictional) example address that shows
the syntax for sending to a PRMD user is the following:
mhs!/C=GR/AD=attmail/PD=Mt.Olympus/PN=Athena
("GR" is the ISO 3166 country code for Greece.
"AD" => ADMD; "PD" => PRMD; and "PN" => Personal Name;
all of this predates by several years the currently emerging
standards on visual representation of O/R addresses.)
Or, if I were originating this on a UNIX (r) system that is linked into
AT&T Mail, I would just prefix it with "attmail!" to get it to the AT&T
Mail service:
attmail!mhs!/C=GR/AD=attmail/PD=Mt.Olympus/PN=Athena
If there were such a PRMD, we might establish "olympus" as the
abbreviated name for it, the use of which would simplify the above
address to:
attmail!mhs!olympus/PN=Athena
(These domain abbreviations are only usable, and only visible, within
our network, of course - what goes across the X.400 link is the
standard O/R address form.)
Similarly, each of our users has an O/R address, the most complete form
of which includes the user's unique user-ID. So my O/R address is
/C=US/AD=attmail/PN=Paul_Lustgarten/DD.ID=plustgarten
("DD.ID" => the "ID" DDA; we use "_" for spaces separating the
components of a name)
If the name happens to be unique within our customer population (as
mine is), the DDA can be omitted and our gateway will still map the
O/R address into the appropriate user-ID, using our regular customer-
directory capabilities (which are available to any on-line users of our
service).
As you can see, this doesn't entail much administration
of individual names or addresses at the gateway!
Paul Lustgarten 908-576-2928
AT&T EasyLink Services plustgarten@attmail.COMpays@mars.emse.fr (Paul-Andre Pays) (03/28/91)
> From root Wed Mar 27 01:37:32 1991 > X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/; > Relayed; 27 Mar 91 01:37:31+0100 > Date: 27 Mar 91 01:37:31+0100 > From: Neil Koorland <koorland@vancouver.osiware.bc.ca> > To: Will@cup.portal.com > cc: mhsnews@uunet.uu.net, > mhsnews@ICS.UCI.edu > Message-ID: <9103261026*koorland@vancouver.osiware.bc.ca> > Subject: X.400 Questions > Autoforwarded: True > > Status: RO > > > 1) Is there currently any definition of X.400 running over TCP/IP? > > RFC 1006 specifies the mapping of ISO Transport over TCP, which is the > most commonly used method of running X.400 over TCP/IP in the Internet. > Agreed but not only on the internet. Besides, to my knowledge, this is the only rather widely available solution (M.PLUS, PP aso..) > > 2) I've noticed that a lot of vendors are using X.400 as a way to > > gateway between different proprietary email systems (as opposed to > > incorporating X.400 style addresses directly into the user interface > > of the email product). Is my observation correct? In the case of > > using X.400 as a gateway and not incorporating X.400 style addresses > > into the user interface, does it then become the duty of the X.400 > > administrator to setup a correspondence in the gateway between the > > X.400 name and each of the corresponding names in the proprietary email > > system? This makes me think that X.400 would be expensive to maintain. > > It really depends on the non-X.400 addressing structure. For some (e.g. > RFC 822) there is an algorithmic mapping which requires minimal table > maintenance. For others there is more administrative overhead. However This is not completely true. RFC <-> X.400 does not imply an algorithmic mapping! It has been proven that only a table driven approach is able to handle every situation. two approaches are available: 1. mapping between internet domain address and X.400 standard attributes It has to be table driven! The consequence was the RARE/COSINE coordination and distribution of the mapping tables. These mapping tables MUST be worlwide and installed in EVERY gateway in the world. It completely depends on the naming scheme chosen by one institution a./ in the ISO MHS world b./ in the internet world one real exemple internet: inrets.fr X.400: C=FR; A=ATLAS; P=RRTR; O=inrets; no algorithm will "guess" this RRTR value for you! the RARE/COSINE tables rfc-987.mapping1:O$inrets.PRMD$RRTR.ADMD$Atlas.C$Fr#inrets.fr# rfc-987.mapping2:inrets.fr#O$inrets.PRMD$RRTR.ADMD$atlas.C$fr# 2. the DDA (domain defined attributes) approach: DD.RFC-822=foo@inrets.fr; OU=pamir; P=inria; A=atlas; C=FR; DDA for the internet address plus the SDA of a gateway (== source routing) "/C=FR/ADMD=ATLAS/PRMD=RRTR;O=inrets;S=foo"@inria.inria.fr the equivalent in the opposite direction No tables are needed BUT some source routing needed!!! > the maintenance is not prohibitive with any reasonable system since > most address mapping only affects the most significant portions of > the address i.e. at the domain level. The experience shows that the maintenance is rather high with the first approach (the most widely used in the R&D community) The tables distributed yesterday are close to 100K big! The effort to maintain and distribute and install the tables is HIGH! In my mind the mapping table scheme will not be manageable within a few (2 3?) years. . need for every gateway to handle the correct mapping tables > > ----------------------------------------------------------------------------- > Neil Koorland Regards -- PAP >
koorland@vancouver.osiware.bc.ca (Neil Koorland) (03/28/91)
>> It really depends on the non-X.400 addressing structure. For some (e.g. >> RFC 822) there is an algorithmic mapping which requires minimal table >> maintenance. For others there is more administrative overhead. However > This is not completely true. > RFC <-> X.400 does not imply an algorithmic mapping! > It has been proven that only a table driven approach is able to handle > every situation. Your point is well taken. I deliberately oversimplified RFC987. The "minimal table maintenance" referred to those aspects which RFC987 cannot handle algorithmically. The point I was trying to make was that there was no implicit need to have a 1-to-1 mapping for every address , in response to Will's original question and concern. >> the maintenance is not prohibitive with any reasonable system since >> most address mapping only affects the most significant portions of >> the address i.e. at the domain level. > >The experience shows that the maintenance is rather high >with the first approach (the most widely used in the R&D community) >The tables distributed yesterday are close to 100K big! >The effort to maintain and distribute and install the tables >is HIGH! In my mind the mapping table scheme will not be >manageable within a few (2 3?) years. "Rather high" does still not mean "prohibitive", and although I understand the maintenance burden placed on RARE/COSINE administrators, not every gateway administrator has to deal with tables of such complexity. It's also worth mentioning that current work on MHS/Network management and Directory Services is intended to solve problems in this area in the 2-3 year timeframe. Regards, Neil Koorland
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (04/03/91)
Will, Some quick answers to your questions: > I have several questions regarding X.400: > > 1) Is there currently any definition of X.400 running over TCP/IP? It is not correct to say that it is an "International Standard", but "everybody" is running X.400 on top of RFC 1006/TCP/IP, including the R&D X.400 networks in Europe (who are also running on top of TP 0/X.25). > Assuming that the various Internet bodies see X.400 as the way to > go (by the way, do they?), NSF is funding an X.400 project here in Wisconsin with the goal to establish an experimental X.400 service in the Internet. The other large agencies (NASA, DoE, DoD) are all looking into X.400. > then how will they transition from SMTP > style addresses to X.400 addresses? You should join the new IETF X.400 Operations WG (list: ietf-osi-x400ops@pilot.cs.wisc.edu) We are discussing these problems, and we had good progress at our last meeting in St. Louis. > 2) I've noticed that a lot of vendors are using X.400 as a way to > gateway between different proprietary email systems (as opposed to > incorporating X.400 style addresses directly into the user interface > of the email product). Is my observation correct? Yes, and I forsee a lot of addressing mapping problems (X.400/ proprietary email system). In the Internet we are solving this mapping issue for RFC 822 addresses. > In the case of > using X.400 as a gateway and not incorporating X.400 style addresses > into the user interface, does it then become the duty of the X.400 > administrator to setup a correspondence in the gateway between the > X.400 name and each of the corresponding names in the proprietary email > system? This makes me think that X.400 would be expensive to maintain. X.400 itself it not more expensive to maintain than any other mail system. A collection of different mail systems interconnected via gateways, is expensive to maintain. Also, users lose functionality when the message passes a gatway. My conclusion is: Let us minimize the number of gateways. I am enclosing the current catalog of relevant documents from the IETF X.400 Operations WG. Send me a note if you want to be on the distribution list Best regards, Alf H. ========================================================================= Documents and documentation from the NSF X.400 Pilot Project are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, type "cd pub". Type "ls" to get a list of documents. The following files are available: Last modified Filename ------------------------------------------------------------------------------ Feb 22 1991 catalog.txt This catalog file. Feb 13 1991 88-to-84-downgrading-kille.txt Frb 18 1991 agenda-st-louis.txt Feb 13 1991 charter.txt Feb 7 1991 country-us.doc Feb 13 1991 dns-987.ps Feb 13 1991 dns-987.txt Jan 25 1991 how-to-join.txt Feb 13 1991 ixom-minutes.txt Feb 13 1991 mhs-md-1st-meeting-rep.txt Feb 13 1991 mhs-md-1st-meeting-slides.txt Feb 13 1991 mhs-md-2nd-meeting-info.txt Feb 22 1991 mta-us.doc Jan 14 1991 na-form.txt Jan 14 1991 na-statutes.txt Jan 14 1991 newsletter-1.txt Feb 22 1991 org-us.doc Jan 14 1991 prospectives.txt Feb 7 1991 rfc987-mapping1.doc Feb 7 1991 rfc987-mapping2.doc Feb 13 1991 status-cdc.txt Feb 13 1991 status-xnren.txt ------------------------------------------------------------------------------ Documents are located at: o CS-Department, UW-Madison Address: mhs-relay.cs.wisc.edu (128.105.8.53) For questions, please mail to c=us; admd= ; prmd=xnren; o=UW-Madison; ou=cs; pn=postmaster postmaster@pilot.cs.wisc.edu
osmith@acorn.co.UK (Owen Smith) (04/03/91)
In article <9103251645.2.11740@cup.portal.com> Will%cup.portal.com%portal@uunet.uu.net writes: >2) I've noticed that a lot of vendors are using X.400 as a way to >gateway between different proprietary email systems (as opposed to >incorporating X.400 style addresses directly into the user interface >of the email product). Is my observation correct? In the case of >using X.400 as a gateway and not incorporating X.400 style addresses >into the user interface, does it then become the duty of the X.400 >administrator to setup a correspondence in the gateway between the >X.400 name and each of the corresponding names in the proprietary email >system? This makes me think that X.400 would be expensive to maintain. Your observation is correct. A lot of vendors do use X.400 merely to gateway. Yes this can cause a lot of system management overhead (I know because I had to do it in my precious job). On the other hand, if you are lucky, or you plan carefully, or both, you can get away with algorithmic mappings or site aliases with username only subsitution. These kind of facilities make life a lot easier, although can be restrictive unless you have full proxy mappings as well. Data General's DG/X.400 gateway to CEO has the site alias and algorithmic mappings, but doesn't have proxy mappings. Data General's CS/X.400 (part of Communications Server) does have proxy mappings but is rather weak on the site alias and algorithmic stuff. Also last time I heard you couldn't actually buy CS/X.400. Owen. The views expressed are my own and are not necessarily those of Acorn.
Juha.Heinanen@funet.fi (Juha Heinanen) (04/05/91)
In article <910402094828*@MHS> Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) writes:
X.400 itself it not more expensive to maintain than any other mail system.
A collection of different mail systems interconnected via gateways, is
expensive to maintain. Also, users lose functionality when the message
passes a gatway. My conclusion is: Let us minimize the number of gateways.
I don't agree with this. An SMTP mail system doesn't require any
manual configuration of neighbor MTA it communicates with since there
is DNS. In X.400 world you must make explicit agreements between MTAs
that exchange messages and configure the relevant connection
information manually into the tables. This is true at least as long
as there is no directory system available for X.400.
--
-- Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958