Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!lll-crg!lll-lcc!dual!ucbvax!A.BBN.COM!DDEUTSCH From: DDEUTSCH@A.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: DoD Representation at ISO Message-ID: <[A.BBN.COM]10-Jul-86.15:34:30.DDEUTSCH> Date: Thu, 10-Jul-86 15:34:00 EDT Article-I.D.: <[A.BBN.COM]10-Jul-86.15:34:30.DDEUTSCH> Posted: Thu Jul 10 15:34:00 1986 Date-Received: Fri, 11-Jul-86 23:03:26 EDT References: <4719.521343946@nrtc-gremlin.northrop.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa Continuing in the spirit of non-flaming... In 1978, when the IFIP 6.5 effort got going, a good many of the then-active participants in ARPAnet mail knew what was going on. They showed up at the initial meetings and gave papers. Some became involved in IFIP 6.5. Others did not. Maybe the costs and time involved in travelling to meetings had something to do with this. Whatever the cause, my impression at the time was that there was very little interest in this activity among the members of the ARPAnet community. On the other hand, information was available. Otherwise, how did the people at UBC come up with the EAN system so quickly? Writing standards can be very frustrating at times, especially if you have a particular idea of what is technically "right". Being technically "right" is sometimes not sufficient to get your idea adopted. In fact, what is "right" is often a matter of context. What is right in a standard are those technical features that help meet its design goals. The set of design goals that is right for one standard may not be right for another. In this case, the sets of design goals appropriate for ARPAnet and for CCITT mail standards are not identical. In the ARPAnet environment we prize fluidity, the ability of individual implementors to try their own ideas and to experiment over very short time frames. We also like to emphasize generality. In the commercial world, where the introduction of a single version of a product can take a long time and be very costly, it is important to be able to be stable. Every vendor wants to be able to add features, but no vendor wants to be forced to change products once they have been fielded. Product lifecycle costs and compatibility with existing systems are very important to the people who write commercial standards. Extensibility as a design goal is a good example of the differences and similarities between the ARPAnet and commercial worlds. When the authors of RFC 733 (the predecessor to RFC 822) began to work, there was a conscious decision to stay with the general design of RFC 680. They knew that this approach would not easily accomodate multimedia mail. Compatibility with RFC 680 mail systems was a more important consideration than extensibility to multimedia mail. The ARPAnet being a research environment, multimedia mail research could be done using an entirely different representation. In the CCITT, the ability to allow individual people and organizations to define their own message headers was less important than support for media other than text. So the X.400 series makes one set of tradeoffs about extensibility, while RFC 822 and SMTP make another. There really was quite a lot of technical debate at the CCITT X.400 meetings, some of it quite heated, 99.99% of it extremely intelligent. Few organizations are willing to spend the many, many thousands of dollars it takes to send representatives around the world to lots of meetings and then pick people who are ill-informed or stupid. Two of my lasting impressions of that group was how hard everybody worked, and how much everybody involved wanted to come up with a standard that would work. There *was* debate about other mechanisms to support P2 header extensions. The consensus was against them, so they were not adopted. As far as CCITT is concerned, there is extensibility for P2. Remember that X.400 is for the interface of systems at national/administration boundards. What goes on inside a country is not the concern of CCITT. If two countries want to agree to exchange messages with headers that go beyond those defined in P2, they can. That's why there is perDomainBilateralInfo. A single country/administration can decide on a way to support ad hoc extensions to P2 for internal use. That's perfectly okay, as long as those messages don't make it into other countries/administrations. The bottom line is that CCITT has different goals than we have on the ARPAnet, so it is not surprising to me that they came up with a different solutions. It is unfortunate and inconvenient that there isn't an isomorphic mapping between the two sets of specifications. In reality, compatibility with the ARPAnet is not an argument that will win the hearts and minds of many commercial vendors, even those located here in the USA. Incompatibility between X.400 and the ARPAnet is our problem, not theirs. That's just the way things are. Regards, Debbie P.S. I heartily agree with your observations about the MHS addresses. What do you think of the newer work on names and directory services?