agda001@mailserv.zdv.uni-tuebingen.de ("R. Daeschler") (05/26/91)
Hi everybody,
I followed the ungoing discussion about Addressing problems
between domain addressing and X400 addressing style.
an addressing like /c=us/adamd......./@X400net, Ch. Huitema
suggested, already exists in form of the Spintmail/Telemail
gateway:
/pn=rainer.daeschler/o=testorg.ati/ADMD=ati/c=jp/@sprint.com
ATI is a commercial X400 Mailservice belonging to Telemail/Sprintmail.
This works fine with my smpt-mailer here, but some local mailers
refuse to handle it.
It is impossible for any smtp-Mailer to handle for example
"/ADMD=British Telecom". The British PTT was clever enough to accept
also adresses like uk.british-telecom and uk.bt if they are addressed
from outside.
My X400 address here is:
c=de;a=dbp;p=uni-tuebingen;ou=kulturwissenschaften;s=daeschler
while our Smtp-Mail gateway uses "/c=", in DFN (German Research
Network) we have to use "c=XX;a="
As you see, the way X400 addresses are written are not the
same everywhere. It much easier to address a German DFN-site with
its's domain-address rather than using X400 Style. It is
more secure to leave the convertion to the gateway, than
doing it by yourself. Why? Look at the address above. One
has to know, that German Universities don't use
o=organization, other institutions do. But if you address
it with
daeschler@kulturwissenschaften.uni-tuebingen.dbp.de
you don't have to care about this problem.
How should an inocent novice know, that he has to leave
the ADMD empty it he addresses
c=no;a= ;p=uninett;o=uninett@s=mhsnews ?
His collegues in the internet would never notice, that
there might be a problem.
As you see, each X400 network should have an gateway, where
domain-style addresses are converted to X400. This keeps
the X400 nets free from bouncing mails.
Unless on doesn't stop this incomaptible variety of addressing shemes
in the X400 world, there is little chance that it will substitute the
smtp-mail and UUCP-mail in future.
The way German DFN accepts domain addresses ist a solution,
but addressing shemes are still very unrational if it is
done in it's own X400 system.
If one sends mail *within X400* using domain-style, it is
only supported by the software EAN for VAX/VMS.
The Ositel for UNIX adopted for DFN is still buggy.
While EAN is able to change an domain-address to
X400 style using the "compose" command, Ositel forces
the input of X400 style. Further ist doesn't accept
any /=DD.XX style address. This means, that existing
forms of addresse can't be adressed, if someone has
the wrong software. The software available is machine
depended.
Please don't forget, one major argument for OSI is not
to be dependent from manufacturers from certain brands.
Now I would be dependent on Digital Equipment here, because
there is no reasonable software offered for other machines
and supported by the DFN.
I think in the development of X400 networks we should not start to
create a science, only dealing with the problem how to address whom. A
novice user should be able to use addresses as easy as using a
phonenumber. Further we should more empahasis the transperancy of the
system to contact other networks. Most people we contact are not in
the network we are ourself. Now, either I spend all my time in learing
the secrets of mailing into other networks myself, or I have to invite
the system-manager to a beer (probably more) to encourage him to spend
half an hour to figure out what I all have to keep in mind if I
address this and this address.
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.....
-------------------------+-------------------------------------Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/28/91)
Rainer, I am representing the IETF WG trying to solve your problems, the IETF X.400 Operations WG. The European group, the RARE WG1 (on MHS) is also trying to make it easy for X.400 end-users like you. There have been some progress during the last few years, but the situation is at the moment far from ideal. However, if we can make the right choises now, the future situation could improve considerably. The IETF X.400 OPS WG is working on an RFC describing the requirements for an Internet PRMD, and if we do our job well, the addressing chaos will disappear WHEN THE RFC HAS BEEN IMPLEMENTED, and that may still take some time. One of the goals is that all addresses are replyable, end-users should just use the addresses provided, and not worry about gateways and other operational details. It should be clear to evarybody in the X.400 or RFC-822 worlds, how they should address an end-user in the other world. Some comments to your message: > an addressing like /c=us/adamd......./@X400net, Ch. Huitema > suggested, already exists in form of the Spintmail/Telemail > gateway: > > /pn=rainer.daeschler/o=testorg.ati/ADMD=ati/c=jp/@sprint.com > > ATI is a commercial X400 Mailservice belonging to Telemail/Sprintmail. > > This works fine with my smpt-mailer here, but some local mailers > refuse to handle it. 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 > It is impossible for any smtp-Mailer to handle for example > "/ADMD=British Telecom". The British PTT was clever enough to accept > also adresses like uk.british-telecom and uk.bt if they are addressed > from outside. 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. > My X400 address here is: > > c=de;a=dbp;p=uni-tuebingen;ou=kulturwissenschaften;s=daeschler > > while our Smtp-Mail gateway uses "/c=", in DFN (German Research > Network) we have to use "c=XX;a=" If I understand you correctly, your gateway is not behaving as it should. Ask your gateway manager to contact DFN to get advice. > As you see, the way X400 addresses are written are not the > same everywhere. It much easier to address a German DFN-site with > its's domain-address rather than using X400 Style. It is > more secure to leave the convertion to the gateway, than > doing it by yourself. Why? Look at the address above. One > has to know, that German Universities don't use > o=organization, other institutions do. But if you address > it with > > daeschler@kulturwissenschaften.uni-tuebingen.dbp.de > > you don't have to care about this problem. I agree with you that to omit O in some cases and use O in some other cases is not good for the end-users. > How should an inocent novice know, that he has to leave > the ADMD empty it he addresses > > c=no;a= ;p=uninett;o=uninett@s=mhsnews ? > > His collegues in the internet would never notice, that > there might be a problem. > > As you see, each X400 network should have an gateway, where > domain-style addresses are converted to X400. This keeps > the X400 nets free from bouncing mails. > > Unless on doesn't stop this incomaptible variety of addressing shemes > in the X400 world, there is little chance that it will substitute the > smtp-mail and UUCP-mail in future. You are right, clever mapping decisions can hide some of the X.400 related problems from the RFC-822 users. "Pure" X.400 users may look at this differently, because they are used to X.400 addresses, and they may even like them because they may reflect the organizational structure better than the RFC-822 addresses (at least in some cases). The X.400 users, on the other hand, need an easy description of how to address RFC-822 users. The IETF X.400 OPS WG recommends as ageneral rule to use Domain Defined Attributes (DDAs) of type RFC-822, but this is a separate issue... > The way German DFN accepts domain addresses ist a solution, > but addressing shemes are still very unrational if it is > done in it's own X400 system. > > If one sends mail *within X400* using domain-style, it is > only supported by the software EAN for VAX/VMS. > > The Ositel for UNIX adopted for DFN is still buggy. > > While EAN is able to change an domain-address to > X400 style using the "compose" command, Ositel forces > the input of X400 style. Further ist doesn't accept > any /=DD.XX style address. This means, that existing > forms of addresse can't be adressed, if someone has > the wrong software. The software available is machine > depended. > > Please don't forget, one major argument for OSI is not > to be dependent from manufacturers from certain brands. > > Now I would be dependent on Digital Equipment here, because > there is no reasonable software offered for other machines > and supported by the DFN. You are right, some X.400 software is better than others, and you should choose the software suiting you best. However, in the case of X.400 there is not much really good products to choose from, although I know that the list of products used in DFN is quite long. > I think in the development of X400 networks we should not start to > create a science, only dealing with the problem how to address whom. A > novice user should be able to use addresses as easy as using a > phonenumber. Further we should more empahasis the transperancy of the > system to contact other networks. Most people we contact are not in > the network we are ourself. Now, either I spend all my time in learing > the secrets of mailing into other networks myself, or I have to invite > the system-manager to a beer (probably more) to encourage him to spend > half an hour to figure out what I all have to keep in mind if I > address this and this address. Agree completely. As I said in the beginning, the goal is to just use the address provided. This requires better operational procedures between E-mail/Gateway managers. The progress in this area is slow, but there is a progress. Best regards, Alf H IETF X.400 Operations WG Chairman.
DAESCHLER@kulturwissenschaften.uni-tuebingen.dbp.de (05/30/91)
Dear "Osis", this will give you a taste of German X.400 flair. This is the way mail is received with Ositel/400, the for the SUN/UNIX system favorized X.400 mailsoft of German Research Network (DFN). I am sure some of us like to analyze the traces, at least I do. > > - OSITEL/400 message - > >Abgesendet am: 28/05/91-18:43:31 >Empfangen am: 28/05/91-20:47:39 >Verursacher: C=us;A= ;P=xnren;O=uw-madison;OU=cs;S=Hansen;GI=Alf;FFN=Alf Hansen >Erstempfaenger: C=de;A= ;P=uni-tuebingen;O=zdv;OU=mailserv;S=agda001;FFN=R. Daeschler >Empfaenger von Kopien: C=no;A= ;P=edu;O=uci;OU=ics;S=mhsnews > C=us;A= ;P=xnren;O=uw-madison;OU=cs;S=ietf-osi-x400ops >Betreff: Re: Smtp <---> X400 >Als Antwort auf: "9105251734.AA28968(a)mailserv.zdv.uni-tuebingen.de " >Querverweise: "9105251734.AA28968(a)mailserv.zdv.uni-tuebingen.de" >Dringlichkeit: normal >Automatisch weitergeleitet: 1 > >RFC-822-Headers: >X400-Originator: Alf.Hansen@pilot.cs.wisc.edu >X400-Mts-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen675447864.35hermit.cs.uw] >X400-Content-Type: P2-1984 (2) >Content-Identifier: 910528112421 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. >Some comments to your message: > >> an addressing like /c=us/adamd......./@X400net, Ch. Huitema >> suggested, already exists in form of the Spintmail/Telemail >> gateway: >> >> /pn=rainer.daeschler/o=testorg.ati/ADMD=ati/c=jp/@sprint.com >> >> ATI is a commercial X400 Mailservice belonging to Telemail/Sprintmail. >> >> This works fine with my smpt-mailer here, but some local mailers >> refuse to handle it. > >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. >> It is impossible for any smtp-Mailer to handle for example >> "/ADMD=British Telecom". The British PTT was clever enough to accept >> also adresses like uk.british-telecom and uk.bt if they are addressed >> from outside. > >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 Gateways could be programmed to transfer even unknown addresse this way: >> My X400 address here is: >> >> c=de;a=dbp;p=uni-tuebingen;ou=kulturwissenschaften;s=daeschler >> >> while our Smtp-Mail gateway uses "/c=", in DFN (German Research >> Network) we have to use "c=XX;a=" > >If I understand you correctly, your gateway is not behaving as it should. >Ask your gateway manager to contact DFN to get advice. 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 1.) Ositel here doesn't accept this order. Addresses have to start with the country 2.) In DFN there must be an ADMD, even if it is blanked out. 3.) "/" is not regarded from Ositel as anything what has to do with X400 Mail 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 >> daeschler@kulturwissenschaften.uni-tuebingen.dbp.de >> >> you don't have to care about this problem. > >I agree with you that to omit O in some cases and use O in some other >cases is not good for the end-users. 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. >The X.400 users, on >the other hand, need an easy description of how to address RFC-822 users. >The IETF X.400 OPS WG recommends as ageneral rule to use Domain Defined >Attributes (DDAs) of type RFC-822, but this is a separate issue... 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. Now our computer-center will stop operating the VAX here from next month on, and all X400 users must change to the UNIX-implementation, Ositel, what lacks of any converting intelligence. .... >Alf H >IETF X.400 Operations WG Chairman. ---------------------------------------------------- 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. (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. With best regards Rainer Dep. of Japanese Studies Tuebingen University / Germany
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/31/91)
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.
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (05/31/91)
Paul-Andre Pays writes: > Most of today problem comes from the wish to see the world > through a single (RFCdomain name based) naming scheme, > even when using X.400 tools. > I can understand it (numbers of RFC sites vs number of X400 sites) > but it is a brain damaged decision leading to such stupidities > as 2 X400 users having their mail going through 2 gateways > (double conversion) only because they only print they RFC > address on their business cards... 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. > 4. ORaddress ('84 ORnames) are indeed brain damaged as they mix > adressing and naming. ORaddresses which have to give enough > information for routing decision are ant will remain > unfriendly for the end-user. The only nice soluation for users > will be the X.500 directory which will allow to ignore > ORaddresses (the condition being the organisations adopt > a user friendly naming scheme) > plus > much improved X.400 SW to ease the user work at designing > recipients... Sure, this is indeed the long term goal. But we can't just sit down and wait for an international X.500 infrastructure. Even without X.500, X.400 is useful, so we have to do something on the X.400 side while the X.500 people are strugling for the X.500 infrastructure. I think better formal links between X.400 and X.500 initiatives could be useful to reach some progress here. > > > > 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. > > Alf, > this is a human user representation (suitable for business card???) > but it is a UA and other product matter to provide a user friYndly > input of this kind of address: > One may certainly dream of a UA accepting > the DD.RFC-822 as userid@foo.bar.edu > and nicely and silently genrating the (a) instead of "@". > it already exists > One may certainly dream of a UA with windows and forms > to enter only the attributes values (and not the types) > it already exists > 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 To "exist" and to "be publicly available" does not mean the same thing, unfortunately. Who will buy an expensive OSI product when you can get something better free? I am sure that the OSI technology is better than most of the existing technologies, but nobody has MADE AVAILABLE an OSI package with the same integrated set of services (X.400, X.500, FTAM corresponding to SMTP, DNS, FTP). Best regards, Alf H.
pays@mars.emse.fr (Paul-Andre Pays) (05/31/91)
> From: Alf Hansen <Alf.Hansen@pilot.cs.wisc.edu> > > > 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. The point was that you are right but how a X.400 UA user will know that a given recipient is a X.400 user if the only knowledge he has ia RFC domain name on the business card? In such a case users tend to use DD.RFC-822 to input the given address (plus the SDA of the nearest gateway they know)... You cann't ask this guy to know about what kind of equipment other institutiions are using, You can't ask this guy to have in mind the thousands of mapping entries, You can't even ask this guy to use a UA with accees to the mapping tables... In short the conclusion is: it is MANDATORY for people using X.400 UA to advertise their ORnames (they may optionaly add the RFC mapping) but it must be known that they use X.400 and what is the ORname. The problem is not for the MTA and Gateways but for the human users when they will input recipients addresses. > > To "exist" and to "be publicly available" does not mean the same thing, > unfortunately. Who will buy an expensive OSI product when you can get > something better free? I am sure that the OSI technology is better than > most of the existing technologies, but nobody has MADE AVAILABLE an OSI > package with the same integrated set of services (X.400, X.500, FTAM > corresponding to SMTP, DNS, FTP). Right and wrong, depends about whom you speak about? Yes research labs tend to refuse to pay for that kind of application SW, but they don't represent the bulk of email users (potential users) and that is probably the main difference with smtp, now Email is spreading wide in the industry. These people don't mind the origin of a product as long as 1. it suits their needs, 2. it is maintained, 3. they have guarantees from the vendor; they need to buy their soft from commercial houses!. Another aspect is the self contradiction in the "something better", if the free software does not provide the correct and easy and friendly input of ORnames, while commercial product does then the "free software" is no longer the better. Regards -- PAP
DAESCHLER@kulturwissenschaften.uni-tuebingen.dbp.de (06/01/91)
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..... -------------------------+-------------------------------------
pays@mars.emse.fr (Paul-Andre Pays) (06/03/91)
> 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. We debated the issue of uucp and bitnet PRMD and/or the solution of DD.BITNET DD.UUCP (similar to DD.RFC-822) and finaly for the simp0licity it gives on the user side we decided in France to only have one* SDA set and one DDA type C=FR; A=red; P=internet; with DD.RFC-822=user(a)sub.dom.top DD.RFC-822=user(a)site.bitnet DD.RFC-822=user(a)site.uucp only one*: of course this is for nationaly defined mappings we use C=us; A= ; P=Internet; for US controlled top-level domains smarthost: Let me just signal that all 3 french WEps use M.PLUS which can be configure to act as a smarthost/smartgateway: M.PLUS routes DD.RFC822 attributes on the basis of the RFC domain described by the DD.RFC-822 value, whatever the associated SDA might be. This is really a nice feature extremely useful for this strategy. > > ------------------------------------------------------------- > 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. > I am wainting for the last version of the ISO/CCITT draft but the last but one was indeed promoting the form I have given as an example. Additionaly, if I remember well there was some reasoning for this choice. In my mind the only important issue is to decide at last for a single universal representation and as long as it is "keyworded" I am not ready to spend energy on discussing the order of these. SW and interfaces have to be smart enough. -- PAP
DAESCHLER@kulturwissenschaften.uni-tuebingen.dbp.de (06/05/91)
Varieties of X.400 Adresses Here are the variation of addresses I received. Unfortunately I got only three replies ----------------------------------- Paul-Andre Pays> ----------------------------------- SMTP-style: daeschler@kulturwissenschaften.uni-tuebingen.dbp.de ----------------------------------- Alf Hansen> ----------------------------------- >This is how your X.400 address looks like seen from my ARGO X.400 >system. > c=DE/admd=DBP/prmd=UNI-TUEBINGEN/ou=KULTURWISSENSCHAFTEN/pn=DAESCHLER >Does not look too bad to me. To my understanding /PN=daeschler is wrong. Either /PN=rainer.daeschler or /S=daeschler would be correct, or not? ----------------------------------- Bjorn Myrstad ----------------------------------- > This is what the message header looks like when I received it > through the distribution list with our EAN-based X.400 mail system: > Originator: C=no;PRMD=uninett;O=uninett;S=distribution;G=MHSnews > From: <C=DE;ADMD=DBP;PRMD=UNI-TUEBINGEN;OU=KULTURWISSENSCHAFTEN;S=DAESCHLER> > To: Alf Hansen <C=us;PRMD=xnren;O=uw-madison;OU=cs;S=Hansen;G=Alf>, <C=no;PRMD=uninett;O=uninett;S=mhsnews> This are not enough samples to show the variety of X.400 addressing shemes in use, but I promised to post the results. C=us;A= ;P=xnren;O=uw-madison;OU=cs;S=Hansen;GI=Alf;FFN=Alf Hansen ^^ I wonder is there is any site outside wher GI instead of G is in use. Further I wonder whether FFN is defined. I have only seen it at my received Ositel-mails. regards Rainer