Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!orion.oac.uci.edu!ucivax!gateway
From: Christian.Huitema@mirsa.inria.fr (Christian Huitema)
Newsgroups: comp.protocols.iso.x400
Subject: Re: admd policies
Message-ID: <9101030847.AA15433@jerry.inria.fr>
Date: 3 Jan 91 08:56:26 GMT
Lines: 49
Approved: usenet@ICS.UCI.EDU
In-Reply-To: Your message of 03 Jan 91 01:35:30 +0100. <139638@pyramid.pyramid.com>

Carl, Jerry,

In your message of 03 Jan 91 you state that:

>The big difference between Internet-type and ISO-type public networks is a
>matter of the *assumed* interface layer. Internet providers generally assume
>that any two hosts will interconnect at the network layer (via IP). 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. The X.400
>specification, on the other hand, clearly assumes the client nodes will
>interconnect at the application layer only. 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.

and many follow up comments on the same line. I think that this reflects an
erroneous conception of the relation between ISO, CCITT and the open layer
model. In fact, the difference between the two model are not so wide:

* the ISO model, as well as the INTERNET model, assumes that interconnection
takes place at the Network layer. The sad point is that there are two
different network layers, one connection less (CLNS, or ISO-IP) and one
connection oriented (CLNP, or ISO-X.25). Real connectivity will only take
place between hosts which select the same network layer, or which support both.

* the X.400 model was mostly pushed by organisations which did not want to
provide end to end network level connectivity to their hosts. X.400 is by no
way the only OSI application; it is in fact an exception, aimed at providing
gateways or "mail relays", similar to those which exists between the INTERNET
and UUCP or BITNET, or between the INTERNET and some corporate networks.
Indeed, the "friendly neighborhood authorized PTT" love it, and managed to
have CCITT install the ADMD/PRMD distinction within X.400.

Assuming that all applications will be relayed through X.400 is an error. It
is true that X.400, contrarily to SMTP/RFC-822, makes a clear difference
between enveloppe and content, and allows binary content; it is thus a
little bit easier to build up an "application responder" on top of X.400 than
on top of SMTP (This is the facility which is used for EDI). However, the
nature of X.400, the requirements of lock-step relaying + high quality of
service + complex addressing necessarily result in a much longer propagation
delay than that of a network layer datagram: the order of magnitude of X.400
delays is seconds, vs. milliseconds for IP or CLNS datagrams. Thus, any
"interactive" application needs end to end connectivity. This is in particular
the case of X.500!

In fact, this is an argument for the "get read of ADMD" line. If you need
connectivity for X.500, then you can use that connectivity for X.400. And you
can store the equivalent of "MX" and "A" records in X.500...

Christian Huitema