Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!orion.oac.uci.edu!ucivax!gateway From: Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) Newsgroups: comp.protocols.iso.x400 Subject: RE: Re: Smtp <---> X400 Message-ID: <910530135008*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> Date: 30 May 91 18:52:08 GMT References: <910530172517*/S=DAESCHLER/OU=KULTURWISSENSCHAFTEN/PRMD=UNI-TUEBINGEN/ADMD=DBP/C=DE/@MHS> Lines: 157 Approved: usenet@ics.uci.edu X400-Originator: Alf.Hansen@pilot.cs.wisc.edu Content-Identifier: 910530135008 In-Reply-To: <"910530172517 */S=DAESCHLER/OU=KULTURWISSENSCHAFTEN/PRMD=UNI-TUEBINGEN/ADMD=DBP/C=DE/"@MHS> X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 30 May 1991 13:50:21 +0000 X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed; Thu, 30 May 1991 13:50:11 +0000 X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen675629411.61hermit.cs.uw] Rainer, Before I answer your two new questions, I will give some short comments to some of the paragraphs in your message. To me it seems that your problems with X.400 is related to the specific software you are using. If the software was improved, or if you had been using other and better software products, perhaps your life with X.400 would have been easier... > I will answer Alf Hansens's answer on my previous posting. I found there > is not much disagreement between us. At the end, we all all want to improve > x400 Mail-handling, but we have to clarify the up-to-date situation, since > many problems are causes to the lack of knowledge about worldwide > existing X400 message handling systems and misinterpreting of > recommendation from the IETF X.400 OPS WG. When we have our draft RFC sent out for comments some time in near future, I hope we can sort out the mis-interpretations and get a better description of the situation when this is discussed in a wider forum. > >It is the recommenation from the IETF X.400 OPS WG not to use such > >addresses, and if I remember Christian's comment correctly, he did not > >suggest that this is the way to address X.400 users from the RFC-822 > >world. He just said that we must be prepared to handle these addresses, > >because they will be around for a while. > > > >Using your address example above, the recommendation from the IETF WG is > >that authorities in Japan should define an address mapping between X.400 > >and the RFC-822 world. A result could then be that the above address seen > >from RFC-822 will look like this: > > > > rainer.daeschler@testorg.ati.ati.jp > > This would be a good solution, but there is the first source of possible > errors. This sample has 4 domains, but the dot in "testorg.ati" is > part of an organisational name. On the other hand, it is no problem to > solve this problem with aliases at the topdomain-gateway, but for automatic > remapping it may cause conflicts. So the use of "." should be omitted in > names. Mapping tables will describe this. > >The address mapping definitions will handle this problem. The R&D MHS > >service providers in the UK, have in the new mapping tables to be > >implemented June 1st, for example defined that ADMD=GOLD 400 is mapped to > >gold-400.gb. The procedures for address mapping table coordination exist > >already, and the procedures will be continuously improved. > > How far is this standarized? It would be a good idea if there is a general > equatation like: > > (X.400:) xxxx yyyy = (smtp:) xxxx-yyy It is not standardized at all I am afraid. > This is not what I want to say. I just want to point out, that one > is confronted with different ways of writing even within the same > network. I can see the /=xx style addresses in headers of smtp-mail > passed by X400 gateway of German DFN. Imagine what happens if you > find an address like that in a letter or businesscard: > > /G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us This is not what I would print on my business card. I would print something according to the RARE definition: C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=Hansen; G=Alf This is not a description of a user-interface, but a way to exchange X.400 addresses between human beings. > 1.) Ositel here doesn't accept this order. Addresses have to start with > the country To me this seems to be an Ositel problem. > 2.) In DFN there must be an ADMD, even if it is blanked out. Yes, ADMD is mandatory and should always be presented, even if blank. > 3.) "/" is not regarded from Ositel as anything what has to do with > X400 Mail Again a user interface problem. Good products are flexible about this. Ositel would probably accept it if you print my version of the business- card address, with ;. > 4.) The following address caused the message "unknown keyword": > C=us;A= ;P=xnren;O=uw-madison;OU=cs;S=Hansen;G=Alf > > After I retraced the previous mail I found the problem: > > ....;OU=cs;S=Hansen;GI=Alf > ^ > I have to use GI instead of G Again, an improved user interface would do it. > This is just a poblem within DFN, another one is between the X400 networks > in Europe: > > c=de;a=dbp;p=organisation (University, etc.) > c=ch;a=arcom;p=switch;o=organisation (University, etc) > c=us;a= ;p=xnren;o=organisation (Univeristy, etc.) > > The networks DFN (represented by dbp), SWITCH and XNREN are identifies > completeley differently. If one sees all the X400 systems together, one > can't tell when to skip ADMD or whether a network itself is identified > by ADMD or PRMD. Perhaps an international RFC from the Internet, could contribute to a more unified situation. > In DFN we have a solutions like: > c=de;a=dbp;p=edu;o=wisc;ou=mac;ou=vms;s=userid > > It his hard to understand to send mail to the German PTT, to get it send to > the USA. EAN converts this address automatically from the the smtp-syntax > to X400-style and adds "c=de;a=dbp;" to it. So a user has simply to type > in the domain addres thes way he sees it on a business-card and would not > care about as long as it finds it way to its destination. Following the draft mapping decision made at the IETF meeting in St. Louis, this address would look like: C=us; ADMD= ; PRMD=Internet; DD.RFC-822=userid(a)vms.mac.wisc.edu everywhere, when implemented. > ---------------------------------------------------- > > > Thanks again Alf for your kind reply. Now I have 2 other questions. > X400 can be a carrier for other communication protokols like fax and > telex. > > (1) As far as I have heared, Switch, Sunet and the users of the commercial > Sprintmail ans ATI can address fax recipents. I would like > to know to which extend this is realized among the existing X.400 systems. > To tell you beforehand, DFN-users have only email available. There is probably a lot going on in the labs in this area, but in the operational service, as far as I know, nobody is offering other body- parts than text as an end user service (yet). Some X.400 service providers (ex. UNINETT in Norway) are providing, at least experimental, X.400 to FAX gateway services. PRMD XNREN is also working on this, and will provide an X.400 -> fax service. > (2) I would like to know how my address is mapped in other X400 systems. > Please cut & paste my address from the header into the mail-body and send > it to me directly. I will post the summary to the list. The aim is to find > out what variety of addressing-shemes actually exist. I will. Best regards, Alf H.