jh@tut.fi (Juha Heinanen) (12/29/90)
in december 10, 1990 issue of communications week international there was an article titled 'bt stands alone'. the article gives some light on who can be an admd and what an admd is supposed to do. first it says: "the term admd was originally used to describe an international telegraph and telephone consultative committee operator with authority to route domestic and international email. such a definition does not apply in deregulated telecoms market, such as the u.k. the u.k draft standard defines an admd as any value-added service operator that agrees to interconnect its services with others." then it goes on and says that british telecom opposes the draft and has been reluctant to interconnect, for example, with sprint because of competive reasons. now bt "has told sprint that it will interconnect, but only for a fee and only to private systems that have selected public uses". what can be learned fron this regarding academic email provision? to me the message is that we can and, in fact, should establish academic admds in all those countries where the local law doesn't prohibit it. in addition, we should be ready to interconnect them with as many other admds as practical. for example, the basic rule could be that we are ready to interconnect with anybody else on pier-to-pier basis provided that a flat rate network interconnection can be somehow arranged, ie. we don't want volume based bills. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
pays@mars.emse.fr (Paul-Andre Pays) (12/30/90)
> > what can be learned fron this regarding academic email provision? to > me the message is that we can and, in fact, should establish academic > admds in all those countries where the local law doesn't prohibit it. > in addition, we should be ready to interconnect them with as many > other admds as practical. for example, the basic rule could be that > we are ready to interconnect with anybody else on pier-to-pier basis > provided that a flat rate network interconnection can be somehow > arranged, ie. we don't want volume based bills. complete approval 1. establish R&D admds as soon as possible the specificity relying . on the potential "customer" base . on some specific services (such as RFC987 gateway operation) . on the transport infrastructure used (ie. as much as possible national and international R&D networks) 2. interconnect with as many others admd as possible . all other R&D admd (whenever feaseable) . all "commercial" admds accepting peer to peer conditions That means in many countries starting lobbying to have this scheme accepted by Academic and R&D people on one hand and Telecom people on the other. I would be really interested to know about the current situation in different countries and may be exchanging that kind of information may help (just by showing that this is being done in many other countries). What about foe eache country having a statement on the current situation and what is being planned and expected difficulties a s o.? -- PAP
hrs1@cbnewsi.att.COM (Herman R Silbiger) (12/30/90)
In article <JH.90Dec28185808@etana.tut.fi>, jh@tut.fi (Juha Heinanen) writes: > > in december 10, 1990 issue of communications week international there > was an article titled 'bt stands alone'. the article gives some light > on who can be an admd and what an admd is supposed to do. > > first it says: "the term admd was originally used to describe an > international telegraph and telephone consultative committee operator > with authority to route domestic and international email. such a > definition does not apply in deregulated telecoms market, such as the > u.k. the u.k draft standard defines an admd as any value-added service > operator that agrees to interconnect its services with others." > Any e-mail provider that offers its services to the public on a non-discriminatory basis can be considered an ADMD. An ADMD has published tariffs and other regulations. A PRMD is a private organization, where only members of the organization can use the service. > what can be learned fron this regarding academic email provision? to > me the message is that we can and, in fact, should establish academic > admds in all those countries where the local law doesn't prohibit it. > in addition, we should be ready to interconnect them with as many > other admds as practical. for example, the basic rule could be that > we are ready to interconnect with anybody else on pier-to-pier basis I thought only shipping companies operated on a pier-to-pier basis 8-) > provided that a flat rate network interconnection can be somehow > arranged, ie. we don't want volume based bills. > -- > -- Juha Heinanen, Tampere Univ. of Technology, Finland If the "academic" email provision is available to anyone who wants to use it, it could be an ADMD. If it is only open to members of the academic community it would be a PRMD. The above is only my unofficial interpretation of the standards. Herman Silbiger hsilbiger@attmail.com
pays@mars.emse.fr (Paul-Andre Pays) (12/31/90)
> Any e-mail provider that offers its services to the public on a > non-discriminatory basis can be considered an ADMD. An ADMD has published Would you elaborate a little bit about this non-discriminatory? what does this mean exactly? is that sure? why this requirement? > tariffs and other regulations. A PRMD is a private organization, where only > members of the organization can use the service. > > > If the "academic" email provision is available to anyone who wants to use it, > it could be an ADMD. If it is only open to members of the academic community > it would be a PRMD. > > The above is only my unofficial interpretation of the standards. Again I disagree I don't see any reason for an ADMD to be forced to accept any customers. In my mind this has nothing to do with the role of an ADMD, and is only a PTT ot PTT like view. Besides you are missing one point (probably due to a still "monopolistic" point of view): Many "academic" institutions will subscribe to one or more commercial ADMD (eg ATLAS here in France, or myabe ATTmail), thus being a PRMD. Additionaly these institutions because of a R&D network infrastructure, because of gateway problems .... will also subscribe to an "academic" admd (the model defines precisely this as an ADMD, the requirements being that the ADMD establish agreement with the other ADMDs). Your view of a single PRMD for the academic community is completely unrealistic; this precisely why we need to establish as soon as posssible "R&D" ADMDs. Regards, -- PAP . > > Herman Silbiger > hsilbiger@attmail.com > >
rdthomps@vela.acs.oakland.edu ("Robert D. Thompson") (01/01/91)
In article <1990Dec30.014356.11120@cbnewsi.att.com> hrs1@cbnewsi.att.COM (Herman R Silbiger) writes: >In article <JH.90Dec28185808@etana.tut.fi>, jh@tut.fi (Juha Heinanen) writes: >> >> in december 10, 1990 issue of communications week international there >> was an article titled 'bt stands alone'. the article gives some light >> on who can be an admd and what an admd is supposed to do. >> Could someone please give me the address of the publisher of "communications week international" Thanks, --- Robert
Juha.Heinanen@funet.fi (Juha Heinanen) (01/03/91)
in finland funet has established a not-for-profit admd called fumail and it has formal gateway agreement with two finnish for-profit admds, called mailnet and elisa. -- juha
csg@pyramid.pyramid.COM ("Carl S. Gutekunst") (01/03/91)
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.... <csg>
Christian.Huitema@mirsa.inria.fr (Christian Huitema) (01/03/91)
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
Piet.Beertema@cwi.nl (01/03/91)
...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
pays@mars.emse.fr (Paul-Andre Pays) (01/03/91)
> ...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
Stef@ICS.UCI.EDU (Einar Stefferud) (01/07/91)
This is a reply to the whole string of ADMD policy messages --- It is critical to understand and use the correct mind set when discussing this topic. FIRST, CCITT only addressed policy and operational X.400 issues relating to ADMD-to-ADMD and ADMD-to-PRMD transfers! CCITT did not speak to any other topic, such as PRMD-to-PRMD transfers. By this I mean that they did not speak! Their lips were seen to not move. In the parlance of the standards industry, this means that such things were left to be resolved as local matters (at national or lower levels) or with bilateral agreements. So, it is permitted (and clearly not prohibited) to transfer messages with P1 or P3 (and now with P7) across PRMD boundaries, even when the involved MTAs are in different countries, unless one (or the other) of the involved countries has a legal prohibition against such transfers. Note that it is not the CCITT that recommends prohibition of such transfers! It is the involved country making a "local" national decision, independent of any CCITT recommendation. Any country has the right to implement any such restriction if it wishes, based on its sovereign rights, within the confines its signed treaties. SECOND, It is entirely possible to set up a Service Management Domain (the INTERNET is one already, whether anyone has noticed or not) that provides transfer services between consenting MTAs in consenting Management Domains (of the PRMD or ADMD persuasion) without requiring that the Service Management Domain Name be present in any of the the ORAddresses in the messages that are transferred. Such a Service Management Domain might well use a combination of TCP/IP, X.25 or other network protocols, as long as they do not violate the P1, P3, or P7 standards (and applicable implementation agreements, et al). A good example of such a Service Management Domain would be SHAPE (the NATO military command operation) which will have to find ways to transfer mail among the many units of different countries that are under its command. NATO and SHAPE have been grouping for ways to do this, and have considered becoming a ADMD, a PRMD, and a COUNTRY, but have not (as far as I can tell) discovered that they only need to set up routing tables in their MTAs, and get on with transferring the mail! Third, routing is not ever required (even by the CCITT 1984 X.400 recommendation text) to be through ADMDs between PRMDs! Period! FULL STOP! FOURTH, The SEMANTIC of what is an ADMD is a (local) national matter. It is not to be decided by this forum, or by any international technical of standards body. It must be decided by each country, within the contexts and limits of the treaties that underlay the ITU (International Telecommunications Union), which govern the behavior of any telecommunications service that provides public communications across international boundaries. (I do not wish to expound on the ITU rules here because I am not an adequate expert in this realm.) Suffice to say that these rules are interpreted differently in each country, so that the national decision on the SEMANTICS of ADMD and PRMD must be different in each country. This should help to explain why we have so many different (but possibly all correct) interpretations of the X.400 standards when it comes to ADMD policy. What is right and obvious for Country A is not likely to be obvious or right for country B. So, I suggest that we not argue about what is absolutely right or wrong for all co8untries, and discuss what we are each doing in the way of making national decision, in the spirit of sharing our experiences and workign toward interworking within the context of different national decisions in each country. FIFTH, Given all of this, it is not at all clear to me that the INTERNET should become and ADMD, or even an PRMD, since it is already and un-named Service Management Domain (and working quite well in this mode). I should note that the RARE R&D-MHS is another "un-named" Service Management Domain that is working quite well (without its name appearing in any ORAddresses). [Routing tables really can do the job!] Cheers...\Stef
Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (01/08/91)
> > complete approval > 1. establish R&D admds as soon as possible > the specificity relying > . on the potential "customer" base > . on some specific services (such as RFC987 gateway operation) > . on the transport infrastructure used (ie. as much as > possible national and international R&D networks) > 2. interconnect with as many others admd as possible > . all other R&D admd (whenever feaseable) > . all "commercial" admds accepting peer to peer conditions I remember Harald Alvestrand (RARE MHS Project) some long time ago proposed to register and use ADMD=COSINE (or R&D or RARE or something) in all R&D MHS countries. He did not get much support then..... Even if it is not possible to establish such a common address base (ADMD) for all R&D MHS participants, we should continue the work to establish a common platform regarding quality of service and connectivity for the R&D MHS Service, as suggested by PAP. Best regards, Alf H