Re: DoD Representation at ISO

10 Jul 1986 15:34-EDT

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

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

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

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.



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?

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:34 GMT