Notes on Standards making

by Jacob Palme

Last update: 5 July 1995 by Jacob Palme E-mail:

Klick here to download this file in RTF format (for neat printing with Microsoft Word).

This document contains a description of a research project which we have not yet started, but which we may start if we get the necessary funding.

Problem description

Standards play a very important role in the computer field. Software and equipment in the computer field is almost always made up of different modules which have been developed by different people and organisations. Examples of such modules: Computer hardware, operating system, compilers for programming languages, user interface development tools, networking tools etc. Some well-known and important standards in the computer area are:
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                                     ISO                                 

Very 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.

Standards work in ISO/ITU and IETF

This appendix is a document developed by us, and submitted to ISO in 1993 and revised in 1994.


In the 1980-s, those of use who were involved with X.400 development believed that X.400 would rapidly become the dominant international standard for electronic mail. In the same way, developers of other OSI standards have believed that their standards would replace older non-OSI standards.

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.

SC 6 is planning to co-work with IETF

Noting this, ISO/IEC JTC 1/SC 6 has started to investigate whether closer coworking between OSI and Internet standards development would be possible.

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."

SC 29 is planning to co-work with IETF

Also ISO/IEC JTC 1/SC 29 is discussing co-working with the IETF in the area of coded representation of audio, picture, multimedia and hypermedia information, see document ISO/IEC JTC 1/SC 29/N 419.

ITU-T (formerly CCITT) does not have formal liaison with IETF

ITU-T (formerly CCITT) does not have formal liaison with IETF. However, in the technical work, informal co-operation with IETF should be possible in spite of this.

Comparing the IETF and ISO/IEC standards process

The IETF and ISO/IEC standards processes have many similarities, as can be seen from the comparison below:
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    
(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) 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   

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.

Contents of standards

ISO/IEC standards tend to be more complex and contain more functionality than IETF standards. One reason for this may be that ISO/IEC standards do not require implementations before their standards are ready. Often, there are functions in ISO/IEC standards which are never implemented, so that real implementations correspond to subsets of the standards. In IETF, functions which are not implemented are removed from the standards by the requirement that the standard should only contain functions which have at multiple complete, interoperable and independent implementations.

There may also be other reasons why ISO/IEC strive more for completeness, while IETF strive more for simplicity.

Coding techniques

Most ISO/IEC standards use ASN.1 as their specification language and a standardised encoding rule, usually BER, as their coding format. Some IETF standards use ASN.1, but many of them instead use a more text-oriented format. This means that the IETF format will often be based on English-language words and phrases used as syntactical delimiters and position makers. There are exceptions, for example SGML is an ISO/IEC standard which uses a text-oriented coding format. One can also note that in the programming language area, ISO/IEC uses English-like verbs and delimiters.

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.

How can ISO/IEC co-work better with IETF?

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     
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.                   

Proposals for SC 18

We suggest that better coworking between ISO/IEC and Internet standards protocols would be very valuable also in the areas of Message Handling Systems and Distributed Office Architecture. Because of this, we propose that ISO/IEC JTC 1/SC 18 discuss how to obtain collaboration with Internet standards work in the future. This discussion could include the following subtopics:

(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.


Note: Internet RFC documents are easily downloadable using anonymous FTP or Gopher in the Internet.

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.

Notes from participation in an IETF meeting

A comparison of IETF and ITU standards work

IETF (Internet Engineering Task Force) and Study Group 7 of the ITU (International Telecommunications Union) are the two major standards making organizations in the computer network area. ITU does its work in close co-operation with the JTC 1 (Joint Task Commission) of the ISO (International Standards Organisation) and IEC (International Electrotechnical Commission). For short, I will in the rest of this paper use the term SG7 as an abbreviation for ITU Study Group 7 in co-operation with ISO and IEC.

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     
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              
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          
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