RSX-DEV@DEC-MARLBORO.ARPA (John R. Covert) (02/24/84)
It is clear that the domain mechanism is the right mechanism for solving the addressing problem in a world internet. My earlier message on "addressing in the international environment" was misunderstood by many, though I did get quite a few useful responses. I wrote the message primarily in response to Lauren's message asking for an interim mechanism for dealing with domains and name servers in an environment where lots of UUCP(Lauren) systems are originating mail. Though many of these systems may be PCs, many more of them may be larger timesharing machines with hundreds of users. Lauren is correct in stating that once his software hits the streets, it will become a defacto standard. His implementation needs to be either sufficiently general to solve the whole problem or must be guaranteed to be upgraded at a future time. Guaranteeing upgrade is probably not realistic. Producing sufficient generality is also unlikely, so maybe all that can be hoped for is that we understand the problems in the international market. The international market has some special requirements caused by the fact that in most of the rest of the world (outside the U.S.) there is a monopoly on communications. All communications. One of the flaming responses I received asked "Why should I have to understand DECNET?" I went back and re-read the message I had sent, and nowhere had I even mentioned DECNET. Regardless of the protocol used, the rules for getting from point A to point B (if one of those points is in a country which does not permit the unrestricted interconnection of communications networks) can not permit a host to simply dump the message on another host and expect it to take care of all the PTT requirements, when a basic requirement is that no one may carry someone else's traffic. By carrying someone else's traffic, the monopoly of the PTT on message transport (whether the message is voice, data, or paper -- yes, I can't even legally hand carry someone else's letter part of the way towards its destination) has been damaged. For example, if machine X, located in country Y, wants to send a message to SRI-NIC.ARPA and UCL-CS.ARPA, country Y may require that the message be routed differently for each destination. Country Y may not permit messages to the U.S. to be routed via the U.K., or messages to the U.K. to be routed via the U.S. I'm not confusing domains with routing. Both of the names in the example above contain enough information to allow the host in country Y to do the right thing. But only after the names are further resolved. The machine in country Y cannot send the mail to a single known system which handles all mail to any ARPA host. The names have to somehow be resolved by a name server which is able to tell machine X the correct route for mail to each of the machines based on the location of machine X and the locations of SRI-NIC.ARPA and UCL-CS.ARPA. The domain system can handle this. Referencing both of these hosts with just ".ARPA" is a valid interim solution as we migrate to the domain structure. Eventually, just .ARPA is not enough to allow the host in country Y to deal with its PTT regulations. Within the ARPAnet we may want to be able to always specify just .ARPA and not be required to specify .ARPA.USA and .ARPA.GB (for example). Software which creates the headers in a message may have to be able to add country designators so that a "Reply all" command issued by a machine in country Y can function without involving name servers. Though there is little relationship between what goes on within the ARPAnet and what CCITT bodies do (since the ARPAnet is a research network), as the connections between the ARPAnet and external networks become common, the creators of these connections have to be sure that international agreements allowing the ARPAnet to extend beyond the boundaries of the U.S. are not violated. The ARPAnet is not the only network which is international in scope. DEC, IBM, and many other companies have built such networks. PTTs are within the rights granted to them by their monopoly status to refuse to allow any host on a private network to be connected to the public network unless the software in use on those hosts is demonstrated to obey the rules imposed by the monopoly. A UUCP host might, for example, be required to demonstrate to the PTT, before a modem could be connected to it, that it will only forward messages which originated within the organization owning the machine. Descriptions of the protocol to be used may be required to be submitted with the application for a modem connection license. As a final note, I should state that most of my experience has come from studying the requirements in Germany, primarily dealing with the interconnection of public and private networks. Remember that a network is a private network even if it operates only over public network facilities. It is private if the switching function is provided by a private entity. All of this discussion took place prior to the completion of the recommendations in the X.400 series. How the X.400 series will affect the environment in Germany is at the moment unknown. One of the more interesting requirements under the German Telecommunications Law is that if a new public service becomes available, private networks which provide the equivalent service must be taken out of service. As of last year, the DBP seemed to consider the Teletex service (which is an upgraded version of Telex with a larger character set and higher speed data transmission) as the service which would meet the electronic message needs of the future. They insisted that the service was a point-to-point service, i.e. a Teletex line could not be connected to a data processing system to allow distribution of messages within an organization. Other countries may have less restrictive, some may have similar, and some may have more restrictive regulations than Germany. And Lauren may have no plans for his product to be used outside the U.S. Be glad these problems don't exist in the U.S. --------