Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!orion.oac.uci.edu!ucivax!gateway
From: pays@mars.emse.fr (Paul-Andre Pays)
Newsgroups: comp.protocols.iso.x400
Subject: Re:  X.400 Questions
Message-ID: <9103271658.AA04384@mars.emse.fr>
Date: 27 Mar 91 17:05:20 GMT
Lines: 92
Approved: usenet@ICS.UCI.EDU
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/;
	Relayed; 27 Mar 91 17:58:12+0100
X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/;
	Relayed; 27 Mar 91 17:58:13+0100

> 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

>