Last update: 5 July 1995 by Jacob Palme E-mail:
Name Description Developed by X.400 Electronic mail ITU (CCITT) and ISO Internet mail Electronic mail IETF X.500 Directory systems ITU (CCITT) and ISO 8086 etc. Computer hardware Intel Power PC Computer hardware IBM and Apple BIOS Prom in personal computers IBM MS-Windows Graphical user interface Microsoft Motif Graphical user interface OSF C++ Programming language ISO Group 3 Telefacsimile ITU (CCITT) GSM Mobile phones ITU (CCITT) Postscript Page description language Adobe ISO 10646 Character codes ISOVery large sums of money are spent on international development of new standards in the computer area. The total sum is probably millions of dollars per year.
A large share of all standards do not turn out to be successes, in spite of the large sums which have been spent on developing them. Some see this as failures, and want to find methods for standards development which will create successful standards. Others see this as a natural part of the creative process which shapes the future. The success or failure of a standard can then be compared to a product which succeeds or fails on the market. Standards development in the computer area has some similarities to development and research. Computer standards are not mainly the documentation and refinement of already known and accepted techniques. Rather, standards work in the computer area is innovative work which changes our future.
Standards are of large importance for people and society. The existence of incompatible standards may cause large costs and risks for lost or corrupted information. On the other hand, if we do not accept development of more than one competing standard for the same task, development of new and better methods can be severely hindered.
The development of standards through international collaboration is often a lengthy process, and the long development time is sometimes an impediment to technical progress.
The main actors in standards work is producers of software, hardware and services in the computer area, plus occasional university researchers. Users are seldom represented, and the lack of user representation may cause standards to become less user-friendly than desirable. Standards in the computer area will influence many people, will control what they can and cannot do, and will thus in many ways govern their life. But there is very little scientific knowledge of this process.
Much has been written about individual standards, but mostly about technical aspects. There is very little research about the process between people which causes standards to be developed, about the costs and benefits of standards, about how they influence people and society. Considering the large importance of standards, and the large sums of money spent on standards development, there is a need for research on standards from other than purely technical aspects.
The goal of our research is not mainly to study technical aspects of standards. Rather, the goal is to study the human processes when standards are developed:
* How do people interwork during standards development?
* What is the process through which a standards is developed?
* What decides whether a standard is successful or not?
* How is marked, technical progress and competition influenced by standards?
* Is it true that standards developed by committees are less good than standards developed by clever individuals?
* How do standards influence the power structure in the computer market?
* How are risks influenced by standards?
* How do standards influence people and society?
* What are the effects of standards on work and private environments?
* Can standards development become more efficient and faster? Are there negative aspects of trying to speed up the standards development process?
* How are user needs represented in standards development, and what can be done to get better user needs representation?
* Which other parties are there, or should there be, in standards development?
* Would usage of information technology (like e-mail and computer conferencing, which is extensively used by IETF but not very much by ISO and ITU) improve the standards development process?
* The planned research will look at comparisons of the development of computer standards in ISO/IEC/CCITT/ITU and in IETF. ISO/IEC/CCITT/ITU has developed a series of standards based on the so-called OSI model (Open Systems Interconnection) while IETF has developed a competing series of standards based on Internet technology. There are large and interesting differences between the standards development processes in IETF and in the other organisations (see appendix 4 and 5).
* In which of the areas mentioned above would better results be achieved by changes in the methods for development of standards?
* Which problems are encountered when a standards is ready and being implemented, and how can these problems be reduced? How are errors and corrections to standards best handled?
* How extensible are IT standards to future needs? Which problems occur when existing standards are extended with new functionality?
* How are products tested for conformance to standards?
The research we are planning to do will not be able to give any final clarification of all these questions. It will only be a first approach at trying to understand this area. The research may however produce standards which will serve people and society in better ways.
This has not happened. Instead, the dominating network standards are AppleTalk, Novell Netware, TCP/IP and other similar protocols. The fastest growing wide-area network is the TCP/IP-based Internet. And the dominating protocol for electronic mail is still the Internet mail standards.
The most probable outcome is that we will have to live for a long time with two or more network worlds, which use different standards and protocols. Even if gatewaying is possible between standards, loss of information and functionality is inevitable. The more different in structure the application standards on each side of a gateway is, the more is the risk for information loss and other problems.
See for example the document ISO/IEC JTC 1/SC 6 N 7963.
Some quotes from that paper:
"the key objective of liaison is the convergence of the existing TCP/IP and OSI interconnection protocols and the joint development of a common platform to support future multimedia and hypermedia solutions. He highlighted the obvious benefits of a single converged solution, which are the reduction of the development effort required by the industry and the easier route to global interconnection. He was particularly anxious to halt the current media rhetoric about the rumoured battle of attrition between TCP/IP and OSI which is confusing users and tearing the industry apart. He urged all delegates to ensure that the liaison initiative is promulgated in all possible areas of the media on the grounds that this is a batter story than the worn out open warfare rhetoric."
"It was agreed that the single most effective action would be to obtain the release of a selected set of key ISO documents to the Internet Community for use within their electronic distribution system. This does not imply the release of copyright and the list would be restricted to those documents on which ISO would like Internet to base their development."
ISO/IEC work IETF work
(1) National bodies propose new work items. (1) Discussion of a new work item usually first
starts in some existing mailing list. Based on
such discussions, a member sends a proposal to the
Area Director (AD) for his application area. The
AD, after revision, forwards it, if accepted, to
the IESG, which forwards it to the IAB.
(2) New work items are accepted by JTC 1, usually (1) IAB decides to start a new working group to
after a mail vote to member bodies. The main develop a new standard.
obstacle for getting a new item accepted is the
requirements that at least five member bodies of
ISO should be willing to work on the new item.
(3) Experts meet for 2-3 yearly meetings lasting (3) Experts communicate via e-mail, combined with
1-2 weeks to develop a Draft Proposal (DP). face-to-face meetings during IETF plenary meetings
three times a year, to develop a Proposed Standard
(PS).
(4) The DP is sent to national bodies for checking (4) Implementors start to implement the proposed
and voting. standard.
(5) The DP is revised by experts. After this, work (5) Technical work continues to resolve issues
may go back to stage (4) above or go on to stage which arise during implementation.
(6).
(6) A Draft International Standard (DIS) is sent (6) When two independent implementations are ready,
out again for voting. the PS may progress to a Draft Standard (DS). The
two implementations need not be of product quality,
but they often are.
(7) Experts revise the DIS. After this, work may (7) Implementations and resolution of problems
again go to stage (4), (6) or on to stage (8). continue.
(8) An International Standard (IS) is ready. (8) When significant implementation and operational
experience has been obtained, the DS may be
elevated to a Standard (S). A requirement before a
DS can be elevated to a Standard is that multiple
complete and interpretable implementations exist
and that the protocol is of demonstrated utility to
the community. Features which have not been
implemented and demonstrated to be interoperable
are removed.
(9) Problems with the standard are reported, and (9) The need for an Implementors' Guide to resolve
resolved first in an Implementors' Guide (IG). The problems is not so large in IETF, since test
IG has no formal status but is in practice an implementations are in IETF done before the DS and
important document. S stage.
(10) Problem corrections and developments result (10) When new requirements arise, a revised
in an amendment to the IS. standard may be developed.
(11) Functional Standards group specify a subset (11) There is no need for functional standards in
of the the IS. IETF, since the requirements for implementations
before a standard can progress to the DS stage,
will weed out unnecessary and
difficult-to-implement functionality earlier in the
process.
The
stages to the left and to the right in the table above are not exactly similar.
The requirements for working implementations in IETF mean that a document in
the right part of the table above is often more mature than the corresponding
ISO/IEC document.
There may also be other reasons why ISO/IEC strive more for completeness, while IETF strive more for simplicity.
Arguments for using English-like words is that standards and standardised operations are easier to read and understand for non-experts. Debugging is also easier because the exchanged operations are more readable for humans. Arguments for ASN.1 is that the notation is not based on one particular natural language, and that computerised syntax analysis of ASN.1-coded operations is easier to do.
Problem Possible resolution
Neither organisation is willing to let the other This can be solved in the same way as it has
organisation have control of their standards. already been solved in co-working between JTC 1
and CCITT: By letting each organisation publish
its own standards, but trying to make them
compatible or even identical.
IETF tries to make standards simple and lean, while The IETF standard could be a subset of the
ISO tries to make standards complete. ISO/IEC standard. Note that by this we do not
mean that ISO/IEC make their standards first, and
that IETF then selects in that standard. we mean
that standards work is progressed in parallel in
both organisations, and that both organisations
produce input which will influence the standard
developed by the other organisation.
IETF often uses text-oriented coding techniques, Three alternatives: (a) Both organisations accept
while ISO/IEC often uses ASN.1. ASN.1 with the same coding rules. This is already
done in certain areas, for example Network
Management Information Bases. (b) ASN.1 is used
for specification, but text-oriented coding rules
(TER = Text-based Encoding Rules?) are used by
both organisations or at least by IETF. (c) Both
organisations develop standards which are similar
in function, but which differ in encoding rules
used.
IETF requires multiple complete and independent ISO/IEC should here adopt the IETF principle, at
working implementations before a standards is least for the subset of the standard which is
accepted. common between ISO/IEC and IETF.
IETF meets at different times than ISO/IEC. We see no easy solution of this, since IETF holds
all meetings with their technical groups in
parallel in the same place and time. The
experience from ISO/IEC earlier co-working with
CCITT is that different meetings with liaison
between them is not an efficient way to develop
standards. Possibly, the rapidly increasing
number of attendees at the IETF meetings will
cause them to split their meetings in time and
place, which would make it easier to have
collaborative meetings with ISO/IEC.
IETF uses electronic mail and other electronic Best would be if ISO/IEC adopted the IETF working
communication for much of their work. style. If this is not possible, liaison between
parallel processes will be necessary. At least
ISO/IEC documents should be available
electronically to the Internet community during
the standards development process.
ISO/IEC sell standards at high prices, ITU-T The advantages with electronically available
(formerly CCITT) sell the same standards at much standards documents are several: (1) Easy and
lower prices, IETF makes their standards available fast distribution. (2) Easy to scan a standard
for network downloading by anyone on the Internet. before deciding to use it or not. (3) Easier to
read and search for information in a
machine-readable document. Best would be if
ISO/IEC standards also would be available for
network downloading. If this cannot be achieved,
at least the IETF version of the standard should
be available for network downloading.
Formally, ISO directives state that standards In practice, the difference between the standards
should represent consensus. In practice, unanimous organisations is not as large as it can seem from
decisions are however not required. However, ITU-T the formal procedures. The proposal here is that
(formerly CCITT) has a stronger requirement for each organisation use its own decision procedures
consensus. IETF does not have such a strong on its version of the standard, but that the
requirement for consensus. technical groups try to make the standards in the
different organisations compatible.
IETF have stronger requirements than JTC 1 that the Both organisations will have to adapt to some
time schedule for developing a standard is extent to the working mode in the other
followed. The time schedules in IETF work is often organisation. Possibly, ISO could start its work
more tight than in ISO work. of developing user requirements before the formal
start of the work in IETF. Of course, in order to
ensure co-working, these user requirements have
to be revised based on IETF input, but this can
be done before the formal start of the IETF task.
People in either organisation sometimes believe More co-working should make people at both sides
that people in the other organisation are learn that people on the other side are in fact
impractical academics, incapable of producing also qualified technical people striving after
implementable standards. good and user-friendly standards.
(1) What is the difference between standards development procedure in ISO/IEC and in Internet. Can the procedure be modified to support better coworking?
(2) Should ISO/IEC adopt the Internet rule not to finally accept any standard until there are multiple interoperable and complete implementations of it? Some even claim that any function in the standard not implemented by multiple working implementations should be removed from the standard!
(3) Should ISO/IEC open standards work more for those who cannot afford to come to meetings? Should we use e-mail more in our work, as IETF does?
(4) The ISO/IEC custom to include many options as opposed to the Internet custom to make lean standards and later extend them.
(5) In what areas are ISO/IEC willing to adjust to Internet? Do we regard Internet and Internet gateways out-of-bounds for us to work on?
(6) Can our working documents be made available for network retrieval in the Internet?
(4) Can our standards be made available for network retrieval in the Internet?
(7) How can development of standards for gatewaying between OSI and Internet standards be supported by ISO/IEC?
(8) On the special topic of X.400 versus Internet mail, can a special study be made of possible future convergence routes?
(9) Can we, in our areas of work (Messaging and Distributed Office Architecture), establish collaborative procedures with IETF for future coworking with Internet?
(10) We suggest that SC 18 write a liaison letter to SC 6 and SC 29, who are also striving to find ways of co-working with IETF, telling them of our conclusions.
Internet RFC-1310 March 1992: The Internet Standards Process.
Internet RFC-1391 January 1993: The Tao of IETF; A guide for New Attendees of the Internet Engineering Task Force.
ISO/IEC JTC 1/SC 6 N 7963 8 March 1993: Notes of the Ad-Hoc Joint Meeting of SC 6/WGs 1, 2 and 4 Regarding Liaison Between ISO/IEC JTC 1/SC 6 and the Internet Community.
ISO/IEC JTC 1/SC 29 N 419 20 May 1993: Letter from the ISO/IEC ITTF to the Internet Society on Liaison with ISO/IEC JTC 1, Attachment: Letter from the Internet Society to the ISO/IEC ITTF.
Making Standards the IETF Way, by David Crocker, published in StandardView, August 1993.
I participated in a meeting with SG7 in November 1994 and at a meeting with IETF in December 1994. This paper presents my impressions of the similarities and differences between these two standards making groups.
Success IETF has been more successful than SG7 in getting its standards widely
used. There is no general agreement on why this is so. Some people claim
that the cause is the different methods of developing standards and styles
of the standards. Other people claim that the difference is caused by
subsidies to Internet or by different charging schemes.
Coding methods Most Internet standards usually encode the protocol elements as text
(somewhat similar to the text in program code in a programming language),
while SG7 usually uses a binary format controlled by specifications in a
specification language ASN.1. This difference makes it possible to read and
produce IETF protocol elements with an ordinary text editor. The writing of
computer software to code and decode information is also easier with the
IETF encoding methods. A disadvantage with the IETF encoding methods is
that certain characters must be forbidden or specially quoted in text
elements. Even though quoting sometimes allows such characters, many
implementations of IETF standards do not handle quoted text correctly, so
that quoted characters are in practice not acceptable. As an example, white
space between words in e-mail addresses is legal in the SG7 e-mail
standard, X.400, but in practice not allowed in the IETF e-mail standard.
Completeness of standards SG7 generally tries to define complete standards, covering all aspects of
an entire application, while IETF prefers partial standards covering the
most important aspects. SG7 standards generally are more complex and
contain more features than IETF standards. This also means that it is more
common for implementations of SG7 standards to cover only parts of the
features in the standard. This is however changing, IETF standards are
becoming more complex and feature-rich, and this means that more often
implementations of IETF standards cover only parts of the features in the
standard.
Use of e-mail IETF uses e-mail to communicate between meetings, and much of the important
technical work is done through e-mail. Only the most important issues are
left for face-to-face meetings. SG7 uses e-mail much less, and does more of
the technical work during meetings.
Frequency of meetings Both organisations have face-to-face meetings about 3 times a year.
Concurrency of meetings SG7 does most of the work in smaller subgroups which usually do not meat at
the same time, while IETF has all its face-to-face meetings the same week
(but with a few specialized meetings in-between).
Size of meetings The IETF meeting in December 1994 had more than a thousand participants,
and the usual number of participants in the working subgroups was 20-200.
The SG7 meeting in November 1994 had a little more than a hundred
participants, and the usual number of participants in the working subgroups
was 2-20. The large size of some of the subgroups made technical work more
difficult in some IETF face-to-face meetings, but this is counteracted by
the work done via e-mail in IETF.
Age of participants The most common age of participants in the IETF meeting was 25-45 years,
while the most common age in the SG7 meeting was 35-55 years.
Clothing People at the SG7 meeting more often wore a jacket and a tie, while jeans
was more common at IETF meetings.
Selection of participants Formally, only representants of member organisations of ITU, ISO and IEC
are allowed at their meetings, while anyone may attend an IETF meeting. In
practice, however, in my experience any expert is allowed to participate
also to the SG7 meetings.
Represented organizations Both in IETF and in SG7, the most common category of organizations
represented were service providers in the computer networking area. In SG7,
they usually represented Telecom companies, while in IETF, they usually
represented non-profit service providers. Manufacturers were also present
at both meetings, users seemed to be more represented at the IETF meeting.
Class of arguments Arguments during the SG7 meeting were more often political, one had the
impression that people more often argued in order to protect their
investments and market position, rather than in order to produce good
solutions. But of course technical arguments were common in both
organizations.
Financing Most of the cost in both organizations is provided by the organizations
where the participants were employed, each person paying for his own cost.
Some costs were provided by sponsors in both organisations, somewhat more
in SG7 than in IETF. Typical sponsors are local companies in the country
where a meeting is held. In SG7, Telecom companies were often sponsors, in
both SG7 and IETF, manufacturers were also often sponsors.
User viewpoints My impression is that user viewpoints are not well represented in either
organisation, but that user viewpoints are somewhat better represented in
IETF. SG7 and ISO has tried in formal ways to get better user
representation, but this has not been successful because there has not been
money available to pay for competent user representatives. The
organizations who choose to pay for employees to come to meetings thus seem
to prefer to pay for technical experts rather than user experts.
Competence The competence of the participants in both organizations is very high on
technical aspects, not always so high on user aspects.
Scheduling of tasks IETF splits the work into more working groups, each with a smaller subtask.
New, but smaller, work items are started more often by IETF.
Requirements for IETF requires two independent and working implementations before a
acceptance of a standard standards is accepted. SG7 often does not start implementation work until a
standard has been accepted. This difference has several effects: (a) Less
errors in IETF standards. (b) Less unimplemented features in IETF
standards. (c) Smaller time before implementations exist for IETF standards.
Time to produce a standard IETF takes less time both to start a new work item and to complete it to
the stage of a draft standard. The stage from draft standard to full
standards is however maybe even longer in IETF than in SG7. The longer
times in SG7 are partly caused by time-consuming postal votes to member
organizations in ITU and ISO/IEC. Another reason for the longer times in
SG7 is that e-mail is not used very much for standards works between
meetings.
New work items In ITU, new work items are mainly accepted only one every four year. In
ISO/IEC, new work items usually take about a year to be accepted. In IETF,
new work items can be accepted in much shorter time, and seldom takes more
than four months (the interval between two IETF meetings).
Production of a draft The time to produce a draft standard is usually 6-24 months in IETF, 24-36
standard months in SG7.
Production of a fully The stage from draft to fully accepted standard is usually 1-2 years in
accepted standard both organizations. The delays are however caused in different ways, in SG7
by postal votes to member organizations, in IETF by the requirements that
there must be two independent and interworking implementations before a
standard is accepted.
View of the other IETF participants often view the work done by SG7 with contempt. SG7
organization participants view the work done by IETF with envy combined with distrust.
There is little willingness on either side to cooperate with the other
organization.