Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jarthur!ucivax!gateway From: csg@pyramid.pyramid.COM ("Carl S. Gutekunst") Newsgroups: comp.protocols.iso.x400 Subject: Re: admd policies Message-ID: <139638@pyramid.pyramid.com> Date: 2 Jan 91 23:35:07 GMT References: Organization: Pyramid Technology Corp., Mountain View, CA Lines: 65 Approved: usenet@ICS.UCI.EDU x-attn: jns X-Previously-To: ctnews!pyramid!ames!comp-protocols-iso-x400@ames.arc.nasa.GOV ReSent-To: mhsnews@ICS.UCI.EDU Let me be radical, and borrow a page from the Internet. I can still remember quite vividly my outrage when I read X.400 for the first time, and realized that by definition, if you were Joe Schmoe you were a PRMD, forbidden to talk directly to other PRMDs; and your only connection to the outside world is through your friendly neighborhood authorized PTT. Rather than setting up research or other non-commercial ADMDs, it seems to me that the real solution is to abandon the PRMD/ADMD abstraction completely, and examine the true boundaries, not the politically fabricated ones. You can certainly define two types of network providers: public (including commercial, research, and educational), and private. The distiction here is simply whether or not network access is offered to outside organizations. But the X.400 PRMD and ADMD abstraction goes well beyond this, and into the realm of nameservice. 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. My summary expression of this is, "Internet public networks provide you *access*. ISO public networks provide you *service*." If you are willing to pay for that service, fine; but I think I like more control over my destiny. While it is possible for Internet nodes to exchange mail the way X.400 would like you to do, the reverse is *not* possible: as yet, the ISO stacks have no nameservice. And it is nameservice that makes the Internet work the way that it does. The nameserver software is available to anyone who wants to use it, and the Internet provides a variety of well-known master nameservers, some of which overlap, but others that cover just their own physical domain. I can pay my network provider to handle all these issues for me; or I can configure my own nameserver, this giving me control over my own routing. ISO has X.500; but that's not what you want. X.500 is a white-pages service, intended for lookup of users, not nodes or domains. This makes it far too bloated and complex for basic nameserver operations. (And frankly, I am concerned about the white pages services that already exist being an invasion of privacy, never mind a world-wide interconnected X.500 capability.) So, what I am calling for is an ISO nameservice standard. With this, anyone who choses can be an "ADMD" in the sense of controlling their own addressing and routing. They can talk with other nodes on other networks directly at network layer, without an unknown (and uncontrollable) amount of intermediate munging. You can then query the public nameservers of your chosing, paying fees appropriate to the particular service. As an intermediate "standard," I'm planning for my X.400 to be able to use a compatible variant of BIND. Why not? It's certainly not ideal, but it works. Someone out there is certainly going to object to my cavalier discarding of one of the more fundamental principles of X.400, to say nothing of inventing my own protocols. Too bad. Unless we in the user community grab the ISO protocols by the horns and make them work, then we can kiss 'em goodbye. It's already too late (I think) for ISO Transport; let's see if we can make X.400 work before it drowns in a sea of politics. I'm open to corrections and flames; I'm still a babe in the ISO woods....