mckenzie@J.BBN.COM (Alex McKenzie) (07/08/86)
It might be worth commenting briefly on the amount of representation which the DoD protocols HAVE had in ISO. Attendance at ISO meetings is restricted to individuals who represent recognized NATIONAL standards organizations. For most of the OSI work that means ANSI in the US, and as an ANSI representative in an ISO meeting it is your job to support the ANSI view; if you push some other view you will not be acredited to attend the next ISO meeting. As in any other social/technical/political arena, one has to establish a reputation of credibility before other members of the group will begin to pay serious attention to you. Thus to be effective in ISO, one needs to build up credibility in ANSI, convince ANSI to adopt your view as the US position, start going to ISO meetings to build up credibility, and finally convince ISO to adopt the US position. Within ANSI there are all sorts of competing pressures, and similarly within ISO there are all sorts of national positions to be resolved. The US National Bureau of Standards (within Dept of Commerce) has had a long-standing program of attempting to influence the adoption of US national (ANSI) and international (ISO) standards for data communications which meet the needs of the US government. A major factor in the definition of "the needs of the US government" has been the DoD protocol suite. The NBS sent representatives to almost every relevant ANSI and ISO meeting for about 5 years to push the DoD TCP and IP protocols and, in my opinion, performed a great national service in doing so. In spite of the constant stream of complaints in this mailing list about how the job done was imperfect (and it certainly was imperfect), I think that the ISO has adopted network and transport protocols which the TCP/IP community can live (and prosper) with if it wants to. As far as the IEEE 802 issue is concerned, there was far less DoD input into this via NBS, on the grounds that TCP/IP is supposed to provide for interconnection of packet networks built according to arbitrary standards, and therefore if one has TCP/IP or TP4/Connectionless-network one doesn't need to constrain the design of individual subnets (like 802.3) to any great degree. Disclaimer: As program manager of a BBN contract effort for NBS to support the development of protocol standards, I was heavily involved in the work described above and may therefore view its results more favorably than others who have viewed the activity from the sidelines. Alex McKenzie BBN
leong@ANDREW.CMU.EDU.UUCP (07/09/86)
While it is true that ISO meetings are restricted to individuals who represent recognized NATIONAL standards organizations, it is interesting to note that ISO standards have been heavily influenced by other standard organisations with much more open membership such as IEEE, CCITT and EMAC (which has strong US representations with names such as IBM, DEC, Honeywell etc.) In most cases, ISO simply rubber stamp proposals from such bodies. The IEEE802 standards are a case in point. Other examples are the great similarlity between the Transport Protocol, ECMA-72 and the ISO/DP8072/3; the Office Document Architecture, ECMA-101 and ISO DP8613. It is nice to know that BBN is contracted by NBS (and, hence, ANSI - a voting member of ISO) to support the development of protocol standards since it is also heavily involved with the ARPANET activities. However, it is not clear how much BBN is influencing the NBS standards using experience learned from the ARPANET world. Furthermore, judging by the furor with TP-4, it definitely is not doing a good job keeping the ARPNET people informed on the development of those standards. (It is interesting to note that BBN has prepared for NBS a set of very detail and excellent specifications for the Transport Protocol way back in 1980/1 which is practically the same as the ISO standard). While it is probably not part of their job to keep people informed, it does have the disadvantage that it will not get input from people who is supposed to be actively involved and sometimes knowledgable in networking. In view of the fact that every one seems to be climbing on the standard bandwagon this days, it is my contention that the people of the TCP/IP world should be kept informed of the activites of the standard setting bodies as well as participating directly or indirectly. Otherwise, we will only have ourselves to blame if the world comes up standards which is both strange and may be a little bit stupid. (Of course we can always ignore the rest of the world - until funding runs out). Standards that have come up so far that influence our work to different degree without any significant inputs from the ARPNET world are : X25, Tranpsort Protocol, Session Protocol, IEEE standards, X400. Potentially interesting protocols being developed at this momement : Internet protocol, more on X400, Office Document Architecture, File Transfer Access and Management protocol. Leong
mckenzie@J.BBN.COM (Alex McKenzie) (07/09/86)
John, 1) It is not my experience that ISO is in the habit of "rubber stamping" standards developed by other groups. The ECMA proposals for Transport were extensively modified by input from other groups, ESPECIALLY NBS in the Class 4 portion, following the original ECMA submission in about 1980. I agree that IEEE 802 may be rubber-stamped. I think the others you mentioned have undergone change and evolution in ISO after initial submission by the other groups, although I'm not intimately familiar with all of them. BBN has not been under contract from NBS for participation in the standards process for about 1.5 years (except Virtual Terminal work, which is also ended, but more recently) due, as I understand it, to NBS budget constraints. This is apparently one of those areas where the current administration believes private industry will do an adequate job without government support. NBS has repeatedly insisted on the sole right to distribute documentation prepared by BBN under NBS contract. We tried, without success, to change this several times, since our output was text files stored on ARPANET-accessible computers. BBN has, at least sporadically, tried to help inform the ARPANET community. In particular, I point with pride to the fact that we manually input the entire text of substantial ISO documents to make them available as RFCs (892,905,926, 941). Of course, one can always do more. In my opinion you are simply wrong when you say that the ISO Transport protocol was developed "without any significant inputs from the ARPNET world".
DDEUTSCH@A.BBN.COM (07/09/86)
I must disagree when you mention X.400 as a standard that was developed "without any significant inputs from the ARPANET world." X.400 had its inception in IFIP 6.5, which was (and still is) open to all interested parties and has had a good number of members from the ARPAnet community. The ARPAnet experience with electronic mail was extremely important when the CCITT began to build upon the IFIP work. The details are different, but many of the basic ideas were carried through. Yes, X.400 doesn't use RFC 822 to represent message. Yes, it uses a different form of addressing. But the underlying structure of headers and text, and the definitions of the message headers themselves, draws heavily upon ARPAnet experience. Likewise, the P1 protocol was designed with SMTP and the old MAIL option to FTP in mind. (I can think of at least four members of the American delegation who were quite familiar with ARPAnet mail protocols. In fact, at least three of us had been involved in the development and/or implementation of ARPAnet mail and other protocols.) If it weren't for the wide-spread success and implementation of ARPAnet-style mail, there probably wouldn't be an X.400 series at all. We'd all be contemplating teletex as the ultimate in electronic mail standards. I cannot claim to be unbiased in this discussion. I, too, worked on commercial standards (including X.400) under NBS funding to BBN. Feel free to factor that into your reading of this message! Cheers, Debbie Deutsch
mrose@nrtc-gremlin (Marshall Rose) (07/10/86)
Appologies in advance for this message which may be interpreted as a flame:
Well, to be completely honest, when I first saw the x.400 stuff
three years ago, my knee-jerk reaction was "what is this trash,
haven't these guys heard of the ARPAnet?" Fortunately, for all
involved including myself, I have calmed down quite a bit.
IFIP 6.5 may be open to any and all interested parties, but not too
many people in the ARPA Internet knew what was going on. If there
really were three or four of the ARPA mail experts doing X.400
stuff, in hindsight, they should have gone back to school, since
X.400 missed quite a bit of the ARPA mail philosophy. (Appologies
in advance to the four people I've just maligned.) For example, the
lack of extensibility in the P2 heading part is AMAZING. How could
that get left out? I would feel better about the incompatibilities
between 822/821 and P2/P1 if the latter were at least a proper
superset of the former. But when a bunch of people sat down to spec
an ARPA/MHS gateway (chaired by an IFIP WG6.5 subcommittee chair, no
less), it became painfully obvious that some things were just plain
orthogonal, and anyone with ARPAnet experience must have been gone
when the drafting/voting took place.
I could start ranting and raving about how the first X.400
implementations I've seen are repeating all the same mistakes we
made in the ARPAnet, but you get my bias. For example, because of
it's typed-data nature, X.400 makes it harder to mistake a user
interface for a user agent, but people are still trying to do this.
The whole addressing problem is another nightmare, which I hope
someone is going to resolve real soon. Otherwise, we are going to
start seeing the X.400 equivalent of %'s in MHS addresses. Except
now we can put source routing in names instead of addresses!
Now I suppose that all of this is the usual coming up on the power
curve, and that eventually we'll start seeing some forward progress
instead of sideways progress. I hope.
Again, sorry for the flames,
/mtrstef@nrtc-gremlin (Einar Stefferud) (07/10/86)
I think it is important, though flaming is most always more fun, to see if there is a useful middle road through this swamp. Yes, it is a swamp! Debbie is dead right about how we would be looking forward to the glories of TELETEX as the mainstay of International EMail, if it had not been for a small cadre of ARPANAUGHTS who banded together under the IFIP flag to develop the basic UA/MTA Computer Mail Model which is the underpinning of X.400. TELETEX is upscale TELEX, and its view of the world is that of a network of terminals, which put ink on paper according to electric signals that come in over a wire. Its basic concept is that of remote printing. TELETEX is your basic electronic stone and chisel. Interesting, but ... X.400 MHS adopted the ARPANET developed view of Net-Mail, with inter- computer file-file text transfers as its basic mail transfer mechanism. TELETEX and X.400 are basically orthoganal to each other. X.400 has all the right concepts in its foundations, but the architects did not all understand how the parts should be assembled. So, we have headers, but they are not defined to be extensible, yet. We have a hierarchical addressing scheme, but it is tainted with a need for names to be route- dependent. If we are not very very careful, all the ughlyness of our wonderful @%.! source rooted internet routing addresses will reappear in X.400, complete with P2 envolope address munging in the MTA relays. One of the biggest problems I see, in trying to work with the ISO TOP/MAP, et al, communities is to get them to understand that TCP/IP is not the enemy. This is not easy when all I can show them is ranting and raving such as I see here, even from my friends who are working with me in the TOP/MAP ISO community. So, how about lets find a way to get hte ISO documents from the NBS and elsewhere, and make them available on SRI-NIC, after the fashion of RFCs. I bet that if we try to get this stuff and make it available, we can get a better view of what is going on, and find a way to make positive contributions to the future of the coming global internet. Lets face it, the internet is what we should call a MegaTrend (following the naming tradition of John Naisbitt). The Internet is going to happen, and X.400 is going to happen. We are headed for an ISO Sea and an X.400 Sea, and there is no way for any TCP/IP or SNA or DECNET Islands to stop it from happening. So lets get with it and help to make it work for us. My objective is to get the ISO and X.400 stuff to working weel enough that the arguements over TCP/IP and SMTP/822 become simply irrelevant. I cannot think of a better fate for them. Think on it - Are you part of the problem or part of the solution? Best - Stef PS: If you are interested in the "routing information in names" problem, I will be pleased to send along a statement of the problem in X.400 terms. - /S
DDEUTSCH@A.BBN.COM.UUCP (07/10/86)
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?
mrose@nrtc-gremlin.UUCP (07/11/86)
I am beginning to understand the political realities of standards
organizations and committees, although personally, I think it
constitutes more of an "explanation" than a "defense".
Thanks for letting me know from someone who was there.
/mtrCERF@A.ISI.EDU.UUCP (07/11/86)
Debbie, I found your message well phrased and persuasive. Having spent the last three years in a commercial environment, I can relate to the difference between CCITT goals and ARPANET/INTERNET. Even CCITT has some narrowness in its thinking relative to the business side of messaging - my impression thus far is that much less progress has been made on the side of interexchange accounting and reconciliation than has been made on the technical side. Another factor which affects CCITT and ISO choices is simply the size of the deliberative body and the mechanisms which are needed to achieve agreement. In the ARPANET world, at least for a part of its history, it was possible to take arbitrary decisions and enforce them because ARPA paid for the work, it was experimental, and the community was not relying on it to make a product which generated profit. In the CCITT/commercial world, the requirements are rather more difficult to meet and there is no arbiter of last resort; only the plenary general assembly meetings and the circulation of draft standards for voting. I think the ARPANET/INTERNET community should be proud that the technology it spawned has captured commercial and international attention - the fact that it emerged somewhat differently from the design we have is almost unavoidable. Just like TCP/TP4 and DOD IP and ISO IP. If there are technical flaws in the international standards which make them unworkable, then we ought to articulate them, but if they can be made to work, then we should do our best to use them so as to achieve compatibility with a much broader segment of the world than just our existing research base. Of course, I am much in favor of pressing on to develop the next set of ideas in the research environment; I just don't expect the research work to emerge in the commercial world in verbatim form (look at X.25 vs ARPANET, for example!). Vint Cerf