The Meaning of Open Standards

 

 

Ken Krechmer, Fellow

International Center for Standards Research, University of Colorado

krechmer@csrstds.com

 

Abstract

 

This paper develops the argument that many Information Technology standardization processes are in transition from being controlled by standards creators to being controlled by standards implementers. The users of standardized implementations also have rights that they wish addressed. Ten basic rights of standards creators, implementers and users are identified and quantified. Each of these ten rights represents an aspect of Open Standards. Only when all ten rights are supported will standards be open to all.

 

 

1. Introduction

 

The personal computer revolution and the following internet wave have resulted in a huge influx of new stakeholders. With a material interest in the technical standards that proscribe their communications, these new stakeholders are making new demands on the standardization processes, often with the rallying cry, ?Open Standards.? As is usually the case, a rallying cry means different things to different people. This paper explores the full meaning of Open Standards. Only when everyone agrees on what Open Standards are, will it be possible to achieve them.

Open standards, open source, open architecture: all sound appealing, but what do they mean? Standards represent common agreements that enable communications, directly in the case of Information Technology (IT) standards and indirectly in the case of all other standards. Open standards, like open government, suggests greater rights to some constituencies. Explaining who the constituencies are and what rights they desire is the purpose of this paper. Open source is used to describe an open process of software development. Often open source development makes use of open standards for operating systems or software development tools, but the purpose of open source is to support continuous software improvement [1] while the purpose of open standards is to support common agreements that enable communications available to all. Open architecture refers to a system whose internal and/or external interfaces are defined by open standards. The term Standards Setting Organization (SSO) refers to any and all organizations that set, or attempt to set, what the market perceives as standards. The term ?formal SSO? refers to any SSO recognized directly or indirectly by a government entity. Consortia refers to SSOs but not formal SSOs.

It is common to think of standardization as the process of standards creation, but this view excludes those who implement the standard (implementers) and those who use the implementations of the standard (users). As example, Microsoft often refers to their implementation of Word as an open standard, meaning that they make Word widely available [2]. And it is common for a user organization to say, ?We have standardized on Microsoft Word,? meaning that they have agreed to use Word in their organization. It seems clear that the term open standards, at least to some, includes the open implementation or open use of standards as well as the open creation of standards.

As formal SSOs developed in the late 19th century, they focused, often with government approval, on supporting the creation of standards. This was quite reasonable as the standards stakeholders then were the creators of the standards [3]. In the late 20th century technology use exploded and the number of standards stakeholders increased dramatically. It was no longer practical for all stakeholders to be fairly represented during the standards creation process.

Through the middle of the 20th century, large integrated organizations (companies that bring together research and development, production and distribution of their products or services - e.g., Siemens, IBM, AT&T, Digital Equipment Corp.) had engineers who functioned, often on a full time basis, as the integrated organization?s standards creators. These standards engineers usually did not have product responsibility but supported the specific formal SSOs necessary for the broad aims of the integrated organization [4]. In the late 1980s, a new movement emerged where larger integrated organizations began supporting many different SSOs via specific product development groups that were largely autonomous from the larger organization [5]. This standardization proliferation movement marks the rise of the implementers? activity (independent product development group) in standardization.

Now most integrated organizations have few standards creation engineers assigned to specific SSOs and often support overlapping SSO efforts. This occurs because individual product development groups (implementers) within the integrated organization expect standardization activities to support their products rather than specific SSOs. Individual product development groups have no history or allegiance to a specific SSO and choose to support any SSO that best fits their specific product development and marketing needs. Often such a fit is made by sponsoring a new SSO to address the standardization requirements of a specific developer?s product implementation [6]. This paper proposes that product implementers have different goals than the standards creators they are replacing. What a product implementer considers an open standard may be quite different from what a standards creator considers an open standard. And his or her definition may also be different from what a user might consider an open standard. Only by identifying each constituency?s view can a complete description of Open Standards emerge.

 

2. The Formal SSO View of Open Standardization

 

Many SSOs? websites refer to the desirability of openness of standardization. There also appears to be wide interest among formal SSOs in open standards. Currently the formal SSOs follow rules to ensure what they consider an open standards creation process by requiring open meetings, consensus and due process.

The Institute of Electrical and Electronic Engineers (IEEE) states, ?For over a century, the IEEE-SA has offered an established standards development program that features balance, openness, due process, and consensus?[7].

The European Telecommunications Standardization Institute (ETSI) web site explains: ?The European model for telecom standardization allows for the creation of open standards?[8].

The American National Standards Institute (ANSI) National Standards Strategy for the United States (2002) states, ?The process to create these voluntary standards is guided by the Institute?s cardinal principles of consensus, due process and openness ....?[9].

However, the formal SSOs have few guidelines to ensure that procedures relating to the implementation or use of a standard are open. Even the idea that such procedures are needed is quite new. Many formal SSOs are comfortable addressing the standardization needs directly associated with the creation of standards but are still learning the needs of standards implementers and users.

 

3. Previous Definitions of Open Standards

 

J. West [10] defines ??open? for a standard as meaning rights to the standard made available to economic actors other than the sponsor.? This definition offers a succinct economic view of open standards.

B. Perens, the author of the Open Source definition [11], offers a software development perspective of Open Standards. He presents six principles and related practices. The principles proposed are: availability, maximize end-user choice, no royalty, no discrimination, extension or subset and predatory practices.

 

4. The Ten Rights that Enable Open Standards

 

This paper attempts to understand what open standards means to all the stakeholders by identifying and understanding all the different types of rights that may be desired by creators, implementers and users of standards. The term Open Standards may be seen from the following three perspectives:

1. The formal SSOs, as organizations representing the standards creators, consider a standard to be open if the creation of the standard follows the tenets of open meeting, consensus and due process.
2. An implementer of an existing standard would call a standard open when it serves the markets they wish, it is without cost to them, does not preclude further innovation (by them), does not obsolete their prior implementations, and does not favor a competitor.
3. The user of an implementation of the standard would call a standard open when multiple implementations of the standard from different sources are available, when the implementation functions in all locations needed, when the implementation is supported over the user?s expected service life and when new implementations desired by the user are backward compatible to previously purchased implementations.

These are the very different views from the creators, implementers and users of standards on what is an Open Standard. Their combined, reasonable, but not simple expectations translate into ten rights that enable Open Standards:

1.        Open Meeting - all may participate in the standards development process.

2.        Consensus - all interests are discussed and agreement found, no domination.

3.        Due Process - balloting and an appeals process may be used to find resolution.

4.        Open IPR - IPR related to the standard is available to implementers.

5.        One World - same standard for the same capability, world-wide.

6.        Open Change - all changes are presented and agreed in a forum supporting the five rights above.

7.        Open Documents - committee drafts and completed standards documents are easily available for implementation and use.

8.        Open Interface - supports migration and allows proprietary advantage but standardized interfaces are not hidden or controlled.

9.        Open Use - objective conformance mechanisms for implementation testing and user evaluation.

10.     On-going Support - standards are supported until user interest ceases rather than when implementer interest declines (use).

Comparing these ten rights with the economic rights identified by J. West [10] suggests that economic rights require further rights to exist. Economic rights cannot be maintained without supporting the political rights basic to a fair political process: balance, consensus and due process. In order for the economic rights associated with compatibility to be available, some technical process (Open Changes) and technical functionality (Open Interfaces) are also required. In order for specific economic rights associated with Intellectual Property Rights (IPR) to be available, specific SSO procedures must be used.

Comparing these ten rights to the six principles proposed by B. Perens [11]:

Availability is addressed by Open Documents.

Maximum end-user choice is addressed by Open Use.

No royalty is addressed under Open IPR.

No discrimination is addressed by Open Meeting, Consensus and Due Process.

Ability to create extension or subset is addressed by Open Interface.

Ability to prevent predatory practices is addressed by Open Change.

The six principles proposed by B. Perens map fully onto eight of the ten rights of Open Standards proposed. B. Perens does not directly address the desires for or against One World or the end user right of On-going Support. This is one affirmative test of the completeness of the rights of Open Standards proposed.

 

5. Standardization Areas of Influence

 

Each of the ten rights of Open Standards relates to one or more of Areas of Influence (AoI) of standardization: creators, implementers and users. There are specific economic drivers in each AoI:

• The creation of standards is driven by potential market development and market control issues.>
• The implementation of standards is driven by production/distribution cost efficiencies.
• The use of standards is driven by a potential cost reduction, due to the standard, on the user organization. In the case of standards used by political entities (e.g., countries), the use or avoidance of a standard may represent a political efficiency as well as or instead of an economic one.

While there is some overlap among these economic drivers, e.g., market development and distribution cost efficiency, each AoI has a distinct economic motivation. This makes it necessary to consider each area separately. The relation of the ten rights to the AoI is shown in Table 1, below.

 

Table 1. Creators, implementers and users have distinct economic motivation.

 

Rights		AoI
		Crea•‰or	ImpleåÌenter	User
1	Open Meeting	x
2	Consensus	x
3	Due Process	x
4	One World	x	x	x
5	Open IPR	x	x	x
6	Open Documents		x	x
7	Open Change		x	x
8	Open Interface		x	x
9	Open Use		x	x
10	On-going Support			x

 

6. Understanding the Ten Rights of Open Standards

 

The first four rights are at the heart of the World Trade Organization (WTO) Agreement on Technical Barriers to Trade, Code of Good Practice [12]. The ANSI view of open standards concept requires the first three concepts for all ANSI accredited standards organizations [13]. As Table 1 identifies, the first three rights are AoI for standards creators only. The fourth concept, One World, is supported by ANSI but not required. The fifth concept, Open IPR, has been formally added to the US standards development process by ANSI and many SSOs.

Currently the widest concerns regarding Open Standards focus on One World and Open IPR. One World addresses standards as barriers to trade or enablers of trade. Open IPR impacts the profitability of all communications equipment companies today. The additional five rights represent open standards rights which are emerging, but not yet fully supported by most SSOs. Table 1 identifies that the five additional rights are AoI of the implementers and users of the implementations of standards. Each of the ten rights is discussed in detail below.

 

6.1. Open Meeting

 

?All stakeholders can participate? is a mantra of many formal SSOs. But this mantra does not address all the desires for Open Meetings. Some formal SSOs (e.g., ITU) and many consortia (e.g., W3C) have a pay-to-become-a-member policy. Paying to become a member is a significant economic barrier when a potential standardization participant is not sure they are even interested in attending a single meeting. Participation expenses, unless quite low, are part of real barriers to participation for students, many users and even start-up companies in the field. Currently only a few SSOs such as the Internet Engineering Task Force (IETF, the standardization organization for the Internet), and the IEEE offer low cost-per-meeting participation.

Currently openness of meetings is deemed to be met (e.g., under many SSO requirements) if all current stakeholders can participate in the standards creation process. But, as technology has become more complex, user participation in standards creation has declined [14]. When the largest majority of stakeholders (users) no longer participate such a definition of open meetings is no longer functional.

Transparency is a useful concept to quantify both Open Meetings and Open Documents (see below). There are two broad indicators of the level of transparency possible in Open Meetings:

1. All stakeholders can pay to become a member (current status of many SSOs).

2. Any person/organization can participate in the standardization process with acceptable cost to join on a per meeting basis.

 

6.2. Consensus, and 6.3. Due Process

 

Like Open Meetings, Consensus and Due Process are considered basic by formal SSOs to the openness of the standards creation process. These concepts may even be seen as necessary to support the Open Meeting concept. Surprisingly, the IETF, which many find to be an example of a more open SSO, does not meet these criteria as the IETF Area Directors have a dictatorial level of power over the standardization process in their area [15].

Note that the first three rights of Open Standards only address the creation AoI of standardization. Most formal SSOs have not addressed the concepts of open standards beyond this. This is a significant omission that can only be viewed negatively by those who are more focused on the implementation and use AoI.

 

6.4. Open World

 

Open World is the principle of a single world-wide standard for a single purpose. This right is supported by the WTO to prevent technical barriers to trade. Politically this is a very contentious area. There are national standards for food processing that are based on religious beliefs (e.g., halal and kosher). There are standards for the environment, health, medical care, and social welfare that create an imbalance in cost between countries that implement them (richer) and countries that don?t (poorer). To avoid these contentious issues, most formal SSOs currently support, but do not require, coordination of their standards work with world-wide standards. This allows, but does not favor, divergent regional or national standards.

In the richer countries, the rise of consortia, the decline of publicly funded research, aggressive commercialism and weak SSO management make it more difficult to achieve a single standard for a single function world-wide. The five different incompatible versions of the 3G cellular standards are an example of these effects. Initially these five 3G versions will operate in different geographic areas, but eventually users will demand world-wide compatibility. It appears likely that standardization organizations will continue to proliferate and create incompatible standards for similar capabilities. This may be viewed as an indication of standardization disaster [16], or as an indication of the need to increase support of Open Interfaces (see 6.8, below).

 

6.5. Open IPR

 

Most formal SSOs and many consortia consider that Open IPR refers to the fact that holders of Intellectual Property Rights (IPR) must make available on Reasonable And Non-Discriminatory (RAND) terms their IPR (implementation). This is only part of the issue of Open IPR as RAND is not sufficient to allow other implementers to determine the impact of standards-based IPR on their costs. Competing implementers have a right to determine the exact cost of IPR before they accept its inclusion in a new standard. This issue has led many implementers to consortia as consortia often require commercial licensing of related IPR. This practice defines the cost of the IPR to the implementer. While commercial licensing is the least open process, it may not be more costly than the RAND approach.

0.        Commercial licensing may be the most prevalent approach to IPR arrangements. It is also the least transparent. In this case the holder of IPR and the potential implementer of the IPR agree privately on commercial terms and conditions for the implementer to use the holder?s IPR.

J. Band [17] describes four additional levels of increasing openness relating to IPR:

1.        Microsoft believes that interface specifications should be proprietary, but will permit openness by licensing the specifications to firms developing attaching (but not competing) products.

2.        The Computer Systems Policy Project (CSPP) also believes that interface specifications can be proprietary, but will permit openness by licensing the specifications on RAND terms for the development of products on either side of the interface.

3.        The American Committee for Interoperable Systems (ACIS) believes that software interface specifications are not protectable under copyright, and that therefore reverse engineering (including disassembly) to discern those specifications does not infringe the author?s copyright.

4.        Sun Microsystems believes that critical National Information Infrastructure (NII) software and hardware interface specifications should receive neither copyright nor patent protection. This fourth approach is discussed further under Open Change, below.

The above segmentation of IPR issues can be further refined:

The approach #2 (RAND - the manner of operation of most formal SSOs currently) might be more acceptable to implementers if an IPR arbitration function existed when IPR is identified during the creation/modification of a standard [18].

The approach #4 (no copyright or patents) - might be more acceptable to implementers if IPR on basic interfaces was prevented but IPR on proprietary extensions was allowed. This could be practical using the technical concepts of Open Interfaces, below.

 

6.6. Open Documents

 

Open Documents is the right to see any documents from an SSO. As a standardization right, this is connected to Open Meeting, above. The transparency of a meeting is closely related to the availability of the documents from the meeting. All standardization documentation falls into two classes: work-in-progress documents (e.g., individual technical proposals, meeting reports), and completed standard documents (e.g., standards, test procedures). Different AoI need to access these different classes of documents. Standards creators do not require Open Documents rights as they are involved in the creation of all the documents. Standards implementers need access to standards work-in-progress documents, to understand specific technical decisions, as well as access to completed standards. Implementation testers (users and their surrogates) need access to completed standards.

The Internet Society (ISOC) supports a non-government-recognized standards making organization, the IETF, which has pioneered new standards development and distribution procedures based on the internet itself. While the IETF does not meet the criteria for consensus and due process, the IETF is perhaps the most transparent standardization organization (see Table 3, below). Using the internet, the IETF makes available on the web both its standards, termed RFCs, and the drafts of such standards at no charge. In fact, using the facilities of the internet, committee discussion and individual technical proposals related to the development of standards can be monitored by anyone and response offered. This transparent development of IETF standards has been successful enough that some other SSOs have also increased their transparency (e.g., ETSI).

Ultimately, as technology use expands, everyone becomes stakeholders in technical standards. Using the internet, access to committee documents and discussion may be opened to almost all. In this way, informed choices may be made about bringing new work to such a standards committee, and potential new standardization participants could evaluate their desires to attend meetings.

There are three levels of transparency in Open Documents:

1. Work-in-progress documents are only available to committee members (standards creators). Standards are for sale (current state of most formal SSOs).

2. Work-in-progress documents are only available to committee members (standards creators). Standards are available for reasonable or no cost (current state of many consortia).

3. Work-in-progress documents and standards are available for reasonable or no cost (current state of IETF).

 

6.7. Open Change

 

Controlling changes is a powerful tool to control interfaces when system updates are distributed over the internet and stored in computer memory. Even with the most liberal of IPR policies (#4 in Open IPR, above), Microsoft would still be able to control its Windows Application Programming Interfaces (APIs) by distributing updates (changes) to users that updated both sides of the API interface. Without a similar distribution at the same time, competing vendors? products on one side of the same API could be rendered incompatible by a Microsoft update.

Standards creators do not require Open Change rights as they are always involved in all the documents. Standards implementers need access to changes to update their products. Implementation testers (users and their surrogates) need access to the current standards.

The only way that interfaces can remain open is when all changes are presented, discussed and approved openly (the first six rights). Considering today?s environment of computers connected over the Internet, identifying and requiring Open Change is vital to the concept of Open Standards. Surprisingly, this is not widely understood. The original judicial order to breakup the Microsoft personal computer operating system and application software monopoly did not directly address this key issue [19].

 

6.8. Open Interface

 

Open Interface is a technical approach that supports compatibility to previous systems (backward compatibility) and to future systems (forward compatibility) that share the same interface. The idea that Open Standards should embody such a principle is relatively new. But interest in Open Interfaces has been increasing due to the considerable success of Open Interfaces in facsimile (T.30), telephone modems (V.8 and V.32 auto baud procedures), and Digital Subscriber Line (DSL) transceivers (G.994.1).

One way of achieving Open Interfaces is to implement a new protocol termed an ?etiquette? [18]. Etiquettes are a protocol used only to negotiate other protocols and related options or features. The purpose of etiquettes is connectivity and expandability. Proper etiquettes provide:

• Connectivity, negotiating between two devices in different spatial locations to determine compatible protocols.
• Means to allow both proprietary and public enhancements to the interface that do not impact backward or forward compatibility.
• Adaptability, so that one communications system can become compatible with a different communications system.
• Easier system troubleshooting by identifying specific incompatibilities.

As long as the etiquette is common between the equipment at both ends, it is possible to receive the code identifying each protocol supported by the equipment at a remote site. Checking this code against a data base of such codes on the web or in a manual, the user can determine what change is necessary in his system or the remote system to enable compatibility.

One of the earliest etiquettes is ITU Recommendation T.30 which is used in all Group 3 facsimile machines. Part of its function includes mechanisms to interoperate with previous Group 2 facsimile machines while allowing new features (public as well as proprietary) to be added to the system without the possibility of losing backward compatibility. In another case, the ITU standard V.8 is used to select among the V.34 and higher modem modulations. More recent etiquette examples include, ITU G.994.1 for DSL, W3C Extended Markup Language (XML) and IETF Session Initiation Protocol (SIP).

As an example of the usefulness of Open Interfaces, consider Microsoft APIs. Assume that a standard based upon the Microsoft Windows API is created. Then any other vendor could create an OS to work with Microsoft?s applications or create applications to work with Microsoft?s OS. Assuming this standard API also supports an etiquette which allows the negotiation of new features across the standard API. Then, if any vendor (including Microsoft) identified a new function such as short message service or video conferencing that was not supported across the basic API, that vendor could offer the proprietary new function, using the etiquette, to users that purchased the new vendor?s OS and applications. Since an Open Interface etiquette supports proprietary extensions [20], each vendor controls the way the proprietary function is accessed across the API, but does not change the previous compatibility of systems using the API. In this manner a vendor may add proprietary value and gain appropriate economic rewards, based on the desirability of the vendor?s new function.

Seven technical features are necessary for an etiquette to support backward and forward compatibility over the broadest range of circumstances [20]. Based on which of these features is implemented, an Open Interface may be quantified. Currently the Open Interfaces function has only been applied to specific standards not as an SSO requirement, so no detailed quantification is offered in Table 3, below.

 

6.9. Open Use

 

Open Use identifies the value of conformance for implementers and users. To the implementers, some means is required to assure that their implementation of a standard works as they intended. To support this level of conformance, a testing event may be held (sometimes termed a plug-fest) where multiple implementers gather to check their implementations with each other. For the user a simpler conformance indication may be all that is necessary. As example, in the European Union (EU), the CE marking is the manufacturer?s indication that the product meets the essential safety requirements of all relevant EU Directives. The CE marking indicating safety conformance reduces the user?s safety concerns. Two levels of Open User are quantified:

 

1. Open Use via plug-fests or over the internet testing (implementer).

2. Open Use via identified conformance (user).

 

6.10. On-going Support

 

On-going Support of accredited standards is of specific interest to the users of standardized implementations as it can increase the life of their capital investment in equipment with standard interfaces. The support of an existing standard consists of four distinct phases after the standard is created (Table 2).

 

Table 2. Phases of standardization during a standard?s lifetime.

 

Phase	Activity	Description	AoI
1.	Create standards	The major task of SSOs	creators
2.	Fixes (changes)	Rectify problems identified in initial implementations	implementers
3.	Maintenance (changes)	Add new features and keep the standard up to date with related standards work	users
4.	Availability (no changes)	Continue to publish, without continuing maintenance	users
5.	Rescission	Removal of the published standard from distribution	users

 

These phases may be used to quantify the on-going support that a specific SSO provides by identifying which steps of the On-going Support process are publicly announced by a specific SSO. This is a difficult right to quantify as each SSO has different procedures for making each phase public.

It is difficult to interest users in the first phase of standardization [14]. Even the second phase standardization may be of more interest to the developers and implementers than the users. The next three phases, however, are where users have a clear interest in maintaining their investment. Greater user involvement in the later three phases of standardization could be practical using the internet to distribute related documentation. Greater user participation in these phases of standardization might also increase SSO membership and income. And specific SSOs, and the implementations standardized by that SSO, would be more valuable to users if the users recognized that the longevity of standards they had invested in were better protected by that SSO.

 

7. How Open are Different SSOs?

 

Table 3, below, offers the author?s quantification, based on a review of each SSO?s documentation (9/2004), of the specific rights these SSOs support. By quantifying the 10 rights of Open Standards it is practical to examine any standardization processes to determine what rights are supported and what rights are not and what economic shifts this causes. Then the political, social, economic, technical and business implications of the process may be more rigorously analyzed and understood.

 

Table 3. Rating the ten rights of Open Standards at different SSOs.

 

Requirements	ITU (note 2)	ETSI (note 2)	IEEE (note 2)	ATIS T1 (note 2)	W3C	IETF	Consortia (note 3)
1 Open Meeting	1	1	2	1	1	2	1
2 Consensus (note 1)	1	1	1	1	1	1	0
3 Due Process (note 1)	1	1	1	1	0	0	0
4 Open World (note 1)	1	0	0	0	1	1	1
5 Open IPR	2	2	2	2	4	3 (note 4)	0
6 Open Documents	1	3	2	3	1	3	2
7 Open Changes (note 1)	1	1	1	1	1	1	0
8 Open Interfaces	note 5	note 5	note 5	note 5	note 5	note 5	note 5
9 Open Use	0	1	0	0	1	1	2 (note 6)
10 On-going Support	2	4	2	2	4	4	1
Score	10	14	11	11	14	16	7

Note 1: For Requirements 2, 3, 4 & 7: Yes = 1, No = 0

Note 2: The ITU, ETSI, IEEE, and ATIS are formal SSOs.

Note 3: This hypothetical consortium is modeled on the description found at ConsortiumInfo.org [21].

Note 4: The IETF IPR policy desires a royalty free model, but is flexible.

Note 5: Open Interfaces has only been applied to specific standards.

Note 6: Many consortia support plug-fests and conformance testing as part of their members desire to promote associated products.

8. Conclusions

 

Sometimes commercial organizations like to term their work ?open standards? [2] when they meet just a few of the ten criteria identified. None of the SSOs discussed even address all of the ten rights described and each SSO differs significantly in the level of each right they do meet. So it should not be surprising that implementers and users consider all SSOs with a jaundiced eye. This attempt to quantify Open Standards suggests that this implementers? and users? view is a wise one.

While it is true that additional levels of each of the ten rights may emerge, the ten basic rights presented here are the broadest possible view of the meaning of Open Standards. Are fewer rights sufficient? That question can only be answered when each stakeholder understands the consequences of what they may be giving up. The comprehension of the rights that are supported by each SSO is usually buried in the fine print of the procedures of each SSO. Until each SSO clearly indicates which rights of Open Standards they support and at what level, Open Standards will just be another marketing slogan. These rights, like most others, won?t be achieved without a struggle. Heed the call, implementers and users, if you want Open Standards, demand your rights!

 

The author would like to thank the reviewers and co-chairs of the HICSS-38 Minitrack on Standards and Standardization for their excellent comments and suggestions.

 

9. References

 

[1] Eric Steven Raymond, Homesteading the Noosphere, section 2, August 25, 2000. http://www.csazar.org/interesting/The_Open_Source_Reader.pdf September, 2004.

 

[2] Bill Gates, ?Compete, Don?t Delete,? The Economist, June 13, 1998.

 

[3] Industrial Standardization, National Industrial Conference Board Inc., New York, 1929.

 

[4] Carl Cargill, Information Technology Standardization, Digital Press, page 114, 1989.

 

[5] Andrew Updegrove, ?Consortia and the Role of the Government in Standards Setting,? Standards Policy for the Information Infrastructure, editors: Brian Kahin and Janet Abbate, The MIT Press, Cambridge MA, 1995.

 

[6] Andrew Updegrove, ?Best Practices and Standard Setting (How the ?Pros? Do It),? The Standards Edge, Dynamic Tension, editor: Sherrie Bolin, Bolin Communications, 2004.

 

[7] IEEE web site http://standards.ieee.org/sa/sa-view.html September, 2004.

 

[8] ETSI web site http://www.etsi.org/%40lis/background.htm September, 2004.

 

[9] ANSI web site http://www.ansi.org/standards_activities/overview/overview.aspx?menuid=3 September, 2004.

 

[10] Joel West, ?What are Open Standards? Implications for Adoption, Competition and Policy,? paper presented at the Standards and Public Policy Conference, Federal Reserve Bank of Chicago, May 13-14, 2004.

 

[11] Bruce Perens, ?Open Standards Principles and Practice,? http://perens.com/OpenStandards/Definition.html September, 2004.

 

[12] WTO web site http://www.wto.org/english/tratop_e/tbt_e/tbtagr_e.htm#Annex%203 September, 2004

 

[13] Procedures for the Development and Coordination of American National Standards, American National Standards Institute, April 1998.

 

[14] Kenji Naemura, ?User involvement in the life cycles of information technology and telecommunications standards,? Standards, Innovation and Competitiveness, editors: R. Hawkins, R. Mansell and J. Skea, Edward Elgar Publishing Limited, UK and US, 1995.

 

[15] IETF Working Group Guidelines and Procedures, RFC 2418, September, 1998. >http://www.ietf.org/rfc/rfc2418.txt September, 2004.

 

[16] Carl Cargill, Sherrie Bolin, ?Standardization: a Failing Paradigm,? paper presented at the Standards and Public Policy Conference, Federal Reserve Bank of Chicago, May 13-14, 2004.

 

[17] Jonathan Band, ?Competing Definitions of ?Openness? on the NII,? Standards Policy for Information Infrastructure, editors: Brian Kahin and Janet Abbate, The MIT Press, Cambridge, MA, 1995.

 

[18] Carl Shapiro, ?Setting Compatibility Standards Cooperation or Collusion,? Expanding the Boundaries of Intellectual Property, edited by R. C. Dreyfuss, D. L. Zimmerman and H. First, Oxford University Press, Oxford, UK, 2001.

 

[19] United States District Court for the District of Columbia Civil Action No. 98-1232 (TPJ).

 

[20] Ken Krechmer, ?The Fundamental Nature of Standards: Technical Perspective,? IEEE Communications Magazine, Vol. 38 No. 6, p. 70, June, 2000.

 

[21] ConsortiumInfo.com web site: http://www.consortiuminfo.org/what September, 2004.