Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!rpi!usc!jarthur!ucivax!gateway From: DAESCHLER@kulturwissenschaften.uni-tuebingen.dbp.de Newsgroups: comp.protocols.iso.x400 Subject: RE: Re: Smtp <---> X400 Message-ID: <910531211739*/S=DAESCHLER/OU=KULTURWISSENSCHAFTEN/PRMD=UNI-TUEBINGEN/ADMD=DBP/C=DE/@MHS> Date: 31 May 91 19:36:59 GMT Lines: 212 Approved: usenet@ics.uci.edu X400-Originator: DAESCHLER@KULTURWISSENSCHAFTEN.uni-tuebingen.dbp.de In-Reply-To: <910528112421*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed; Fri, 31 May 1991 14:24:18 +0000 X400-Received: by /PRMD=UNI-TUEBINGEN/ADMD=DBP/C=DE/; Relayed; Fri, 31 May 1991 14:17:40 +0000 X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=UNI-TUEBINGEN/ADMD=DBP/C=DE/;ZDV-UNI-TUE1457910531211740-AGg] I see the discussion about adsressing problems is getting very enthusiastic. The comments of Alf Hansen and Paul-Andre Pays rose new questions. ----------------------------------------------------- Alf Hansen ----------------------------------------------------- >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... This is true, but I am afraid that the bugs here are not only caused throug not ready developed software, there are obviously a lot of bugs in the realization of X400 Mail in German Research Network. for Example, I tried the address /c=de/admd=dbp......./pn=daeschler with EAN (VAX/VMS X400 mailsoft) it accepted this address without any complain, but the mail never showed up at its destination. There was not even a notification of undeliverable message. >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 ;. The more advanced EAN was able to handle "/", but the mail simply disapeared in the net. So the net must be responsible, too. You are right, a good software should handle both delimiters. If we receive an address throug email, we need not to care about it, since it will be transformed by the software into the proper local syntax. We are in trouble if somebody writes an address down on a peace of paper: "Why don't you send me a message to...." > >> 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 > I only see an advantage in this adressing sheme, if I can influence the routing with this adressing sheme. Imagine the German PTT would charge me extra money or simply refuse to transfer Mail to the Swiss Internet (this is just an example), I could address the site with: c=ch;a=arcom;p=internet;DD.RFC-822=userid(a)domain.domain.ch Did I understand this correct? Otherwise I would rather suggest the way UUCP handles mail. Actually all what a UUCP mailer knows, is knowing a few sites and what to do, if there is an unknown. This is the principel of the smarthost. This sounds like an contrary statement, but it only aplies to the user-interface. If I input the adress /c=us/a=argo/p=xnren.... the "smarthost" is not active, since ADMD and PRMD are known objects. If I input userid(a)domain.bitnet, or uerid(a)domain.domain.country there will be automaically a convertion to C=us; ADMD= ; PRMD=Internet; DD.RFC-822=userid(a)domain.domain.country C=us; ADMD= ; PRMD=Internet; DD.RFC-822=userid(a)domain.bitnet It would be logical to have a PRMD uucp and bitnet, but it is not necessary, since one can leave it to the Internet to find the next gateway. The user would still find this very cryptic, but as long he has not to put it together himself and it will find it's desitnation, he would not care. What do you think about a solution "smarthost=Internet-Gateway"? Software-manufactuers must be encouraged to include this convertional step, of course. >> (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. It is offered for SUNET (Sweden) and SWITCH (Swiss). Don't forget the comercial X400 Services of the PTT. DBP and ATI already offer Telex nd Telefax in combination with X400 Mail. What is the problem to invent it in the research networks? Is this a technical problem, or is this an accounting problem? I can I imagine, that it is not easy to account FAX-services from a research network, since the information has to use in case of FAX lines not supported by governmental founds. ------------------------------------------------------------- C=fr;A=atlas;P=emse;O=emse;OU=mars;S=pays;FFN=Paul-Andre Pays ------------------------------------------------------------- > >Right or use the soon to be published ISO/CCITT variant > G=Alf; S=Hansen; O=UW-Madison; OU1= cs; P=xnren; A= ; C=us; ^^ ^^ >But note that as long it is only for exchange between human being >that the attribute order or the exact keyword choice does not deserve >a new "Holly War". Are you sure this is correct? I don' know the ISO/CCITT recommendation, but this looks rather like misprint then a logic X.400 adress to me. > >> > 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. The Internet world has no problems at all, just type it the way it is written, and leave all the problems to the gateways, that's it!!! > 1.Part of the current mess comes from the fact that the us had not > made any mapping choice for the domains (edu, mil, gov ...) under > "us" authority, and thus, each country had to provide it's own > mapping. As far as Internet and UUCP are concerned, those domain-names are no a problem at all. The national backbone has all the domains registered and knows were to send the messages. Whether there is a single "us" among them in a list of others, or a few "edu, mil, gov, org.." doesn't make much difference. Other networks have to be identified, too. There must be also extracted those domains who only look like US-sites. ....bonn.edu = uni-bonn.de ....sub.org = @ira.uka.de the topdomain of ther German SUBNET. The German backbone will intercept mail send to this sites and send it directly to the apropiate address without crossing the atlantic. >One may certainly dream of a UA (X400 UA) allowing you >to type only the "userid@foo.bar.edu" and nicely >genearting the appropriate SA attributes : C=us; A= ; ... for you > I hope it will exist soon EAN does it, but you have to stick to a VAX running VMS --------------------------------------------------------------- C=us;A= ;P=xnren;O=uw-madison;OU=cs;S=Hansen;GI=Alf;FFN=Alf Hansen --------------------------------------------------------------- >I am not sure if I got your last point here. If 2 X.400 users communicate, >they use the X.400 addresses. If the user-interface allows it, the >X.400 addresses can be presented on RFC-822 form, but this does not >mean that the message has to go through 2 gateways. > >We are trying to put together the first draft of the RFC describing >the requirements for Internet PRMDs, and under routing I will propose >that X.400 messages should not leave the X.400 world and come back >again. this could be neccessary, if X400 services don't know each other. s=/pn=reinhard.moller/o=testorg.ati/admd=ati/co=jp/;o=sprint;p=com;a=dbp;c=de It is hard to believe, but this is a valid address. Since DFN is not aware of the existence of ATI, I have to contact the Internet- Gateway. Fortunately EAN doesn't make any syntax-check on "S=" and passes its contents without any comments to the Internet-gateway. Now, with Ositel it is impossible to get in touch with ATI, if wouldn't have another mailing system available. regards Rainer -------------------------+------------------------------------- Rainer Daeschler | Telex.: 7-262867 utzv d Tuebingen University | Fax: +49 7071 293989 Dep. of Japanese Studies | Tel.: +49 7071 296985 Wilhelmstr.90 | 7400 Tuebingen /Germany | agda001@convex.zdv.uni-tuebingen.de | daeschler@mailserv.zdv..... -------------------------+-------------------------------------