Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!ucivax!gateway
From: Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen)
Newsgroups: comp.protocols.iso.x400
Subject: RE: Re: Smtp <---> X400
Message-ID: <910530171414*/G=Alf/S=Hansen/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS>
Date: 30 May 91 22:16:35 GMT
References: <9105302037.AA26193@mars.emse.fr>
Lines: 72
Approved: usenet@ics.uci.edu
X400-Originator: Alf.Hansen@pilot.cs.wisc.edu
Content-Identifier: 910530171414
In-Reply-To: <9105302037.AA26193@mars.emse.fr >
X400-Received: by mta pilot.cs.wisc.edu in /PRMD=xnren/ADMD= /C=us/; Relayed;
               Thu, 30 May 1991 17:14:25 +0000
X400-Received: by /PRMD=xnren/ADMD= /C=us/; Relayed;
               Thu, 30 May 1991 17:14:16 +0000
X400-Content-Type: P2-1984 (2)
X400-MTS-Identifier: [/PRMD=xnren/ADMD= /C=us/;hansen675641656.78hermit.cs.uw]

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.