[comp.protocols.iso.x400] "Internet to X.400" problem.

Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/23/91)

Christian,

> Similarly to the "X.400 to Internet" problem, we may have to face a "Internet
> to X.400" problem someday. If you make the assumption that users dont have
> access to mapping table, then the Internet equivalent of:
>
>    /c=us/admd= /prmd=Internet/dd.RFC-822=user(a)some.place.edu/
>
> Is a gatewayed X.400 address, e.g. something as:
>
>    /C=us/ADMD= /PRMD=xnren/O=UW-Madison/OU=CS/S=Hansen/G=Alf/@x400.net
>
> Were the domain <x400.net> designates the x400 world for Internet users, on
> the same way that "/c=us/admd= /prmd=Internet/" designates the Internet world
> for X.400 users.

This was discussed as an alternative at the IETF meeting in St. Louis
March 12-13, and the conclusion was (quote from the minutes:)

"8. Specification of X.400 addresses in the RFC822 world

   After considerable discussion, it was agreed that RFC822 users should be
   able to address X.400 recipients in RFC822/Internet terms.  This
   implies the necessity of maintaining and distributing address mapping
   tables to all participating RFC987 gateways, at least in the short term.
   Other mapping strategies were discussed (loudly and enthusiastically), but
   it was shown that these alternate strategies would sometimes cause
   messages (or replies to messages) to pass through more than one gateway.
   Since this behavior would probably cause information to be lost in
   translation, it was quickly agreed that the alternate strategies were
   inferior to the good old table driven approach.

   Nevertheless, it was also pointed out that some X.400 addresses do
   not map cleanly to RFC822 addresses, even when the table driven
   mapping strategy is used.  For example, X.400 personal names which
   contain generation qualifiers, personal names which contain initials
   but no given name, and initials which contain periods can not be mapped
   to RFC822 symmetrically such that a reverse mapping is possible.
   Similarly, X.400 addresses which contain X.121 address elements
   (sometimes used for expressing fax telephone numbers), unique UA
   identifiers, or physical addressing attributes can not be mapped nicely.
   Consequently, it will be necessary for RFC987 gateways to generate RFC987
   address syntax occasionally.

   It was recommended that our RFC should contain guidelines for the
   creation of X.400 personal names.  In following these guidelines,
   users will avoid creating personal names which can not be mapped
   nicely between X.400 and RFC822.

   It was generally agreed that long term reliance upon static mapping
   tables is unacceptable.  Therefore, it was agreed that the X.400
   Operations working group should devise a strategy for using X.500
   directory services instead.

   Another option could be to use the DNS system for this purpose, if the
   X.500 infrastructure appears to be too premature."



So, the current view of the IETF X.400 Operations WG is to use mapping
tables, and improve the table distribution procedures.

Best regards,
Alf H.

Christian.Huitema@mirsa.inria.fr (Christian Huitema) (05/23/91)

Alf,

I certainly do not advocate that the full RFC addresses of the form
	/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS
should be used as "the general solution". They are gateway addresses, and have
all the inconvenient of gateway addresses, including the risk to pass through
more than one gateway that you mentionned.

I merely wanted to warn you that there will be cases when Internet mail users
see the address of they correspondant expressed in X.400 format, e.g. on the
business card of the enthusiastic RARE MHS supporters. These MHS users will
not necessarily have access to the mapping tables, even if these tables happen
to be stored in the X.500 DIT or in the Internet DNS. And a (fallback) solution
that does not require them to "flip a coin, guess a mapping" would certainly
be useful.

In fact, one can certainly envisage scenarios of the kind:

<joe.user@fantasy.edu> sends an E.Mail to
	/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS
This is routed to the nearest MHS gateway, which routes it through X.400.

/G=Alf/S=Hansen/X.400=etc.../ receives the mail, and replies. The reply is
routed through the nearest Internet gateway. That gateway is fully supplied
with tons of mapping tables, and the reply arrive to <joe.user@fantasy.edu>
with the a properly mapped "From" address, e.g. <Alf.Hansen@pilot.cs.wisc.edu>.
Joe User is at this stage very happy, and does not use the "unmapped" form
anymore.

I imagine that if you fail to organize this receipe for happiness in your MHS
specs, some of the IETF working group members are going to advocate quite
loudly that you missed something...

Christian Huitema

Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/24/91)

Christian,

> I merely wanted to warn you that there will be cases when Internet mail users
> see the address of they correspondant expressed in X.400 format, e.g. on the
> business card of the enthusiastic RARE MHS supporters. These MHS users will
> not necessarily have access to the mapping tables, even if these tables happen
> to be stored in the X.500 DIT or in the Internet DNS. And a (fallback) solution
> that does not require them to "flip a coin, guess a mapping" would certainly
> be useful.
>
> In fact, one can certainly envisage scenarios of the kind:
>
> <joe.user@fantasy.edu> sends an E.Mail to
> 	/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS
> This is routed to the nearest MHS gateway, which routes it through X.400.
>
> /G=Alf/S=Hansen/X.400=etc.../ receives the mail, and replies. The reply is
> routed through the nearest Internet gateway. That gateway is fully supplied
> with tons of mapping tables, and the reply arrive to <joe.user@fantasy.edu>
> with the a properly mapped "From" address, e.g. <Alf.Hansen@pilot.cs.wisc.edu>.
> Joe User is at this stage very happy, and does not use the "unmapped" form
> anymore.
>
> I imagine that if you fail to organize this receipe for happiness in your MHS
> specs, some of the IETF working group members are going to advocate quite
> loudly that you missed something...

As far as I can see, the IETF X.400 OPS WG is providing the usesr with a
"receipe for happiness" as you describe above. Our scheme says that (again
from the same minutes): "....Consequently, it will be necessary for RFC987
gateways to generate RFC987 address syntax occasionally" and therefore we
MUST be able to handle these addresses correctly. So, if users write
addresses like you describe above:

  /G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@local.gateway.somewhere

because this is the best guess, and the local.gateway.somewhere is a
real RFC-987/1148 gateway, it will work as you describe, and we will
maintain a population of happy users.

Best regards,
Alf H.