Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!orion.oac.uci.edu!ucivax!gateway
From: pays@mars.emse.fr (Paul-Andre Pays)
Newsgroups: comp.protocols.iso.x400
Subject: Re: admd policies
Message-ID: <9101031058.AA19994@mars.emse.fr>
Date: 3 Jan 91 11:07:17 GMT
Lines: 38
Approved: usenet@ICS.UCI.EDU
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/;
	Relayed; 03 Jan 91 12:02:26+0100
X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/;
	Relayed; 03 Jan 91 11:58:53+0100

> 	...it seems to me that the real solution is to abandon the PRMD/ADMD
> 	abstraction completely
>
> And make life for both users and gateways a lot easier.
> >From the user perspective PRMD and ADMD are artificial
> entities, conveying no information whatsoever.
> And directly or indirectly they have effects that go
> beyond what you describe:

I refuse to comment again in detail this one which is one more time
mixing truth and stupidities.

  1. would the RFC devots please let sometime the people in charge of X.400
     try to organize their service as well as they can and the service allows
  2. Who, except maybe some RFC zelots, has decided that PRMD to PRMD
     communication was prohibited with X.400?
  3. Many important commercial companies are moving to X.400, and
  	like it or not, they insist in establishing connection only
  	with 1 (or a few) ADMD. That is mainly for security purposes.
  4. If a community decides to operate common services (this is
     for example the fax, telex, teletex gateways from ATLAS, or the
     RFC-987 gateway for our planned R&D admd) then the ADMD
     seems to be a convenient abstraction for this.
  5. Many more .....

I don't pretend that everything is fine with X.400. Obviously we
can feel the strong PTT influence, and certainly we have to resist it.
But our task, far from unfruitful criticism, is to organize and
move in such a way the X.400 mail service is more and more usable
(except for those who have decided not to use it).
Besides I would suggest the same zelots to take time  and do the work
that has been done between '84 and '88 to clarify and understand
ORnames and ORadresses.


Regards,

-- PAP