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.