Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!jarthur!ucivax!gateway
From: Piet.Beertema@cwi.nl
Newsgroups: comp.protocols.iso.x400
Subject: Re: admd policies
Message-ID: <9101030942.AA22884@piring.cwi.nl>
Date: 3 Jan 91 09:52:02 GMT
Lines: 37
Approved: usenet@ICS.UCI.EDU
In-Reply-To: Your message of 2 Jan 91 19:16:53 GMT .
	<139638@pyramid.pyramid.com>


	...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:

	When I send RFC822 e-mail, I almost always open a direct SMTP/TCP/IP
	connection to the receiving host, even when multiple Internets are
	involved. To send X.400 mail, I open up an MTA-to-MTA connection with
	my provider (that is, my ADMD), then the provider does header cracking
	and address resolution, and forwards the mail.
	My summary expression of this is, "Internet public networks provide you
	*access*. ISO public networks provide you *service*."
Call it "service" or not, technically speaking it brings
back the old days of store-and-forward mail, which we had
got rid of in the internets. But in the end the success in
both cases depends on the (mail) system on the client nodes,
and the X.400 intermediates don't really provide much of a
"value added service".
Politically speaking the situation is much worse: RFC822 in
combination with the DNS enables you to deliver your mail
directly to the recipient host or to a (possibly fallback)
host within the recipient organisation, where the route to
that host(s) may - according to IP's very nature - well be
a multi-link route, i.e. a route *not* controlled by one
single organisation. In X.400 on the other hand, your whole
mail flow is under control of your "service" provider. And
the service providers together represent as many potential
(temporary) points of failure; this may even lead to loss
of mail, where (temporary) loss of an IP route to a host
won't ever cause that.


	Piet