Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!uunet!jarthur!ucivax!gateway From: Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) Newsgroups: comp.protocols.iso.x400 Subject: "Internet to X.400" problem. Message-ID: <910523102746*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> Date: 23 May 91 15:29:03 GMT References: <9105230822.AA07026@jerry.inria.fr> Lines: 64 Approved: usenet@ics.uci.edu X400-Originator: Alf.Hansen@pilot.cs.wisc.edu Content-Identifier: 910523102746 In-Reply-To: <9105230822.AA07026@jerry.inria.fr > X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 23 May 1991 10:27:58 +0000 X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 23 May 1991 10:27:49 +0000 X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen675012469.12hermit.cs.uw] 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 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.