The LEAP Protocol Development Model
The LEAP Protocol Development Model
|Document Number:||PLPC-100002 [ .bib ]|
|Dated:||August 4, 2000|
|Federated Publications:||ByTopic -- ByContent|
|AccessPage Revision:||This AccessPage was produced on April 09, 2013 at 0:30 PDT (-0700)|
|Author(s):||Andrew Hammoude, Mohsen BANAN|
|Organization:||Free Protocols Foundation|
- PDF: -- 128K -- Provides the document in Portable Document Format.
- PS: -- 112K -- Provides the document in Postscript format for printing.
- HTML: -- 120K -- Displays the document as a web page.
This article provides a description of the processes used to develop the LEAP protocols, and how and why these differ from conventional development processes. This article also includes a criticism of the IETF protocol development processes.
The LEAP Protocol Development Model
First Published: August 4, 2000
Last Updated: June 16, 2000
Copyright ©2000 Mohsen Banan
copies of this manual provided the copyright notice and
this permission notice are preserved on all copies.
This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the Lightweight &
Efficient Application Protocols (LEAP) protocols. For the complete collection of articles see The LEAP Manifesto [?], available
http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free Protocols Foundation website at
2 Protocol Phases of Development
2.1 Initial Protocol Development
2.2 Global Parameter Assignment
2.3 Protocol Publication
2.4.1 The Free Protocols Foundation
2.4.2 LEAP’s Adherence to the FPF Procedures
2.4.3 Author’s Patent-Free Declaration
2.5 Maintenance and Enhancement
2.5.1 Open Maintenance Organizations
2.5.2 Working Groups
2.5.3 Maintaining Patent-Freedom
2.6 Endorsement by a Standards Body
3 Economic Consequences of Protocols
3.1 Principles for Maintaining Protocol Integrity
4 Standards Organizations: Do They Mean Anything?
5 Our Independence of the IETF
5.1 Do We Need the IETF?
Protocols come in all shapes and sizes, and from a variety of sources. Some are proprietary, intended for use exclusively by their developer. Others may be “open” in some sense, indicating that they are intended for more general, public usage. In this context, the word “open” can mean any one of several different things. It may mean nothing more than that the protocol has been published by its developer. The protocol may still be very tightly controlled: revision of the protocol may remain the exclusive right of the developer, the protocol may be protected by patent or copyright restrictions, and use of the protocol may require a licensing agreement. This is a very narrow, and to our mind misleading, use of the word “open.”
At the other extreme, the protocol may be open to a very high degree of public accessibility: it can be published by an open mechanism such as RFC publication, undergo revision by means of public working groups, and be entirely free of usage restrictions. A protocol satisfying all these criteria can be said to be “open” in the broadest sense. Protocols are often referred to as “open” to imply that they are open in a broad sense, whereas in fact they are open only in the narrowest sense.
To a large extent, the character of a protocol is defined by the processes used to develop it. This article is about a particular set of protocols called called LEAP, or the Lightweight & Efficient Application Protocols. LEAP is a set of high-performance, efficient protocols intended for mobile and wireless applications.
The LEAP protocols are intended to be open in the absolutely broadest sense of the word; they are intended to be freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. The processes used to develop the LEAP protocols have been such as to ensure that they have these intended characteristics.
In this article we describe the LEAP development process. In the next section we provide a general description of the various phases of development that a protocol may go through. Then in subsequent sections we describe the specific processes used for the LEAP protocols at each phase of development.
In this article we also discuss the enormous economic influences that protocols can exert, and we point out the potential for corruption that inevitably accompanies this. We describe our general philosophy regarding protocol development, and we present what we consider to be the key principles which must be upheld in order to maintain protocol integrity in the face of corrupting influences. Finally, we provide justification for some of the protocol development choices we have made which others may consider to be unconventional or controversial.
Over its lifetime, a protocol typically goes through a number of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases:
- Initial Development. A protocol may be initially developed in a variety of ways, e.g. by a standards organization, a private business, or the academic community.
- Global Parameter Assignment. If necessary, global parameters must be assigned to the protocol, for example by the IANA.
- Publication. If the protocol is intended for public usage, as opposed to exclusive in-house usage, then it must be made publicly available, for example by being published as an Internet RFC.
- Patent-Freedom. If the developers of a protocol intend it to be patent-free rather than proprietary, then they must take appropriate steps to work towards a patent-free result.
- Industry Usage. The ultimate test of a protocol is whether or not it becomes widely accepted and implemented in the industry at large. This is an aspect of protocol evolution which is not under the direct control of its developer.
- Maintenance and Enhancement. Protocols frequently undergo revision and enhancement as a result of experience and/or changing industry requirements. Depending on the intended character of the protocol, this may take place by closed and proprietary processes, or by open and public ones.
- Endorsement by a Standards Body. Once a protocol has become accepted as an industry standard, it may receive the formal sanction of a standards body.
Depending on its purpose, nature, and history, a protocol may undergo some, all, or none of these phases. Also, a protocol may iterate through phases (3) to (7) multiple times, as it undergoes maturation via repeated revision and re-publication.
In general, the developers of a protocol define and control the policy and processes to be applied to the protocol at every phase of development except (5) and (7). The developers have no direct control of (5) at all, and only minimal influence over (7).
The processes used at each phase of development determine the character of the resulting protocol. In the following sections of this article we will describe the processes applied to the LEAP protocols at each phase of development except (5).
The conception and early development of a protocol can take place in a variety of ways. A traditional source of Internet protocols is the IETF/IESG. Other sources of protocols are private businesses, the academic community, or even a single individual.
In the case of LEAP, initial development of the protocols was carried out by Neda Communications, Inc., a private business.
We believe that there is a tendency among established standards bodies to regard their own, officially sanctioned protocols as authoritative, while any other protocol is of questionable worth or validity. However, the history of protocol development does not support this view. Small groups of individuals have created protocols with far-reaching consequences (e.g. the World Wide Web), just as established standards bodies have created protocols which failed to achieved industry acceptance. For this reason we do not regard any one source of protocols as necessarily superior to any other.
It may be necessary to assign global parameters to a protocol.
In the case of LEAP, the necessary UDP port assignments for ESRO and EMSD have been made through the IANA.
If a protocol is intended to be an open protocol, as opposed to an in-house or proprietary one, then it must be made publicly available. This can be accomplished in various ways; the protocol can be self-published by the developer, or it can be published through an independent agency such as the Internet RFC Editor.
In common with other Internet protocols, the LEAP protocols have been published in the form of Internet RFCs [?], [?]. RFC publication provides a number of significant advantages:
- World-Wide Access. RFC publication ensures world-wide access to the published protocol. There are numerous Web and FTP sites world-wide that carry the complete series of RFC documents – if a particular site is busy or unavailable, a person seeking an RFC can simply go to another.
- Unrestricted Access. A user may download an RFC publication completely freely, without incurring any legal restrictions whatsoever. All that is required to acquire the full text of an RFC is its number or title. There are no copying or other distribution restrictions attached to RFCs.
- Permanence. RFC publication is permanent. Even if the creator of a protocol should go out of business or otherwise become defunct, the RFC itself will remain in existence.
- Stability. Once published, an RFC is fixed – it cannot undergo change. If a new revision of the standard must be issued, this is handled by issuing the revision under a new RFC number.
- Quality Assurance. The RFC Editor maintains publication quality control, and will decline to publish a document which, in the Editor’s opinion, falls below the required technical and/or editorial RFC standards.
For these reasons, RFC publication is the traditional, mainstream publication mechanism for Internet protocols, and virtually all Internet-related protocols are published this way. RFC publication of the LEAP protocols ensures that they are freely, easily and permanently accessible to anyone who wishes to use them.
If a protocol is intended to be open rather than proprietary, then the protocol developers may take steps to work towards a patent-free result.
In the case of a public protocol, the presence of patented components within the protocol is very undesirable. A public protocol provides a well-defined interoperability specification for an industry, so that businesses and other organizations can create products and services independently, which can then be relied upon to function and interoperate correctly. The protocol is a positive, enabling force for the entire industry.
In order for the protocol to play this role, anyone who wishes to implement and use it must be able to do so freely. The presence of patented components within the protocol places restrictions on its usage, and therefore undermines this purpose. Furthermore, the presence of the patent brings an enormously unfair market advantage to the patent holder. By exercising his patent rights, the patent holder can gain financial benefit from competing companies who wish to use the protocol, or can stifle competition altogether by denying the competing company the right to use the protocol at all.
Software patents thus pose a significant danger to protocols. In some cases patents become included in protocols by accident – that is, without deliberate intentionality on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a protocol, in an attempt to gain market advantage via ownership of the protocol.
In either case, the protocol can then be held hostage by the patent-holder, to the great disadvantage of anyone else who may wish to use it. Patented protocols thus have the effect of inhibiting free and open competition, and are therefore highly detrimental to the industry and the consumer.
The LEAP protocols are intended to be fully open and without usage restrictions of any kind. We have therefore exercised great diligence throughout their development to ensure their patent-freedom.
Various mechanisms exist for working towards a patent-free result. In developing the LEAP protocols, we have adopted a set of procedures defined for this purpose by the Free Protocols Foundation.
The Free Protocols Foundation, or FPF, is an independent, non-profit organization whose mission is to prevent the inclusion of patented components within protocols. The FPF has established a set of policies and procedures for protocol development that is designed to ensure, insofar as this is possible, that the resulting protocol is patent-free.
In general, there may be both an Author and a Working Group involved in the development of a protocol. The Author is the company, organization or other entity that has primary responsibility for the protocol. In some cases, the protocol may also undergo development at the hands of a Working Group – a set of independent individuals or companies who work cooperatively on the protocol, usually via public mailing lists. The FPF defines procedures for both Authors and Working Groups, allowing both to participate in the development of a protocol, while still maintaining the patent-free character of the protocol.
For example, both an Author and a set of Working Groups are involved in the development of LEAP. As noted above, the LEAP protocols were initially developed by Neda Communications, Inc., and this company continues to take primary responsibility for their maintenance. In addition, as described in Section 2.5, continued enhancement and revision of the protocols takes place by means of various Working Groups.
Both the Author and the Working Group may wish to make public declarations regarding the patent-freedom of the protocol. The Author may wish to make an initial declaration that the protocol is intended to be patent-free; and the Working Group may wish to make a declaration that it operates according to the FPF Working Group procedures, thereby maintaining the patent-free nature of the protocol.
In addition to defining protocol development procedures, the FPF also acts as an independent, public forum in which Authors and Working Groups may make these declarations. Such declarations which are submitted to the FPF are published on its website.
For complete information on the Free Protocols Foundation and its procedures, see the FPF website at
Development of the LEAP protocols conforms in all regards to the processes and procedures of the Free Protocols Foundation. LEAP’s compliance with these processes ensures, insofar as this is possible, that the LEAP protocols are, and will remain, patent-free.
We have adopted the FPF processes because they are available for use by any protocol developer, without the requirement that the developer be part of a formal standards organization. Various standards organizations include processes within their protocol development procedures which work towards patent-freedom. In general, however, these patent-free processes are created for the standards organization’s internal use, and are not available for a protocol which is not officially sanctioned by the organization.
The FPF, on the other hand, is entirely egalitarian, providing the same level of support for patent-freedom to any protocol developer. To our knowledge, the FPF is unique in this regard.
Neda Communications, Inc., the original Author of the LEAP protocols, has made a declaration to the FPF that the LEAP protocols are intended to be patent-free. This declaration includes statements to the effect that:
- To the best of the Author’s knowledge, the protocol is not subject to any patent restrictions.
- It is the Author’s intention to maintain the protocol patent-free.
- In the event that the Author becomes aware of any patent restrictions relating to the protocol, or if a patent right assertion is made with respect to the protocol, the Author undertakes to make prompt disclosure of this fact to the FPF.
The complete text of the declaration can be seen on the FPF website at http://www.FreeProtocols.org.
Protocols are usually not static, but instead typically undergo continued revision and enhancement. Depending on the character of the protocol, this may take place by closed, in-house processes, or by open and public ones. Since LEAP is intended to be a fully open protocol, it is maintained by fully open processes.
The LEAP protocols are developed and maintained through a set of public organizations. At present there are three of these:
- LeapForum.org. The LEAP Forum is a central clearing-house for information and pointers relating to the LEAP protocols in general. For complete information, visit the LEAP Forum website at http://www.leapforum.org/.
- ESRO.org. ESRO.org is an open organization for the development and maintenance of the ESRO protocol. For complete information, visit the ESRO website at http://www.esro.org/.
- EMSD.org. EMSD.org is an open organization for the development and maintenance of the EMSD protocol. For complete information, visit the EMSD website at http://www.emsd.org/.
Additional maintenance organizations are expected to be created as the LEAP protocol family grows.
None of these are standards organizations. They are simply forums to allow information exchange and cooperative effort relating to the LEAP protocols and technology.
Participation in these organizations takes place via various mailing lists which are hosted by each organization. Any interested company, organization or individual may participate by joining one or more of these mailing lists. Neither the organizations nor their mailing lists have any membership structure; nor does participation require any membership fees or other financial obligation.
For more information, and to subscribe to one or more mailing lists, visit the How To Participate area at any of the above websites.
In particular, ESRO.org and EMSD.org each host a Working Group mailing list. It is through the Working Group mailing lists that active development of the protocols takes place. Anyone may participate in the development of the ESRO and EMSD protocols by subscribing to the corresponding Working Group mailing list.
To subscribe to the ESRO Development Working Group mailing list, visit
To subscribe to the EMSD Development Working Group mailing list, visit
This open development process ensures that commentary and participation is open to any industry constituency that may be affected by the LEAP protocols.
Since the LEAP protocols are intended to be patent-free, the Working Groups must function in a way which preserves their patent-freedom. All LEAP protocol Working Groups therefore conform fully to the Free Protocols Foundation policies and procedures for Working Groups. These procedures ensure, insofar as possible, that a protocol remains patent-free despite undergoing collective development by a public Working Group. For more information, refer to the FPF website at http://www.FreeProtocols.org.
All Working Group contributors are required to adhere to these procedures. The Working Group imposes adherence to these procedures by requiring that all contributors agree to them as a condition of participation.
Both the ESRO Development Working Group and the EMSD Development Working Group have made declarations to the FPF that they conform fully to its patent-free policies and procedures. The text of these declarations can be seen on the FPF website.
The ultimate arbiter of any particular protocol is the industry itself, in which a multitude of individual decisions leads to the acceptance or rejection of the protocol. The acceptance of a protocol as a standard is therefore something that occurs independently of formal endorsement by a standards body.
Standards organizations such as the IETG/IESG certainly have no monopoly on innovation, creativity, or competence. Any company, organization or individual is capable of creating protocols that become successful, far-reaching industry standards, without the sponsorship or sanction of a standards body.
For example HTTP, the protocol which forms the basis of world-wide Internet communications, was developed and achieved prominence entirely independently of any formal standards body. The same is true of Pretty Good Privacy (PGP), now a world-wide encryption standard. These and many other protocols became industry standards despite lack of any official endorsement.
For these reasons we believe that official endorsement of a protocol as a standard has little meaning, and that genuine legitimacy for a protocol derives from its industry usage. We therefore have no immediate plans to subject the LEAP protocols to any formal standards track process. If and when they become widespread within the industry, we may at that time place them on standards track and seek their formal endorsement as a standard.
In general, protocols are a positive, enabling force for an industry. Protocols define an agreed-upon expected behaviour, allowing businesses to create products and services independently of one another, which can then be relied upon to interoperate correctly.
It may happen that one or more rival protocols arise, which address more or less the same industry need. Under these circumstances the rival protocols will effectively compete with one another, just as products and services do. It is usually most beneficial to the industry for there to be a single commonly-accepted protocol, so it is often the case that one protocol eventually displaces all others, thereby becoming an industry “standard.”
In the early stages of formation of a new industry, this competition among protocols is of great benefit to the industry. As in the case of products and services, competition is a mechanism for selection of the best. Free and open competition allows the success or failure of protocols to be determined on the basis of their merits, and their fitness to serve the overall interests of the industry.
In an ideal world, the success of protocols would be determined exlusively on this basis. However, this is not an ideal world, and forces can arise which interfere with the free and fair competitive process. In particular, the adoption of a protocol by an industry can have enormous economic consequences. And where there is money, there is the potential for corruption.
Businesses may attempt to exercise control over protocols in various ways. During protocol development, they may seek to introduce patented components into the protocol, that they can subsequently exploit to their advantage. They may seek to control the protocol publication process, thereby allowing them to impose copyright restrictions on the protocols, or even make unilateral, unannounced changes to the protocol specifications. They may develop and/or maintain the protocol by means of closed, exclusionary processes, which deny broad technical review of the protocol, and allow its design to be dictated by minority business self-interests.
We believe that there are three basic, fundamental principles for defending against these sorts of underhanded activities. These are:
- RFC publication
- Maintenance by open organizations
Each of these provides a vital assurance of protocol integrity. Patent-freedom ensures that a patent-holder cannot subvert free-market competition among products and services based on the protocol. RFC publication ensures that the protocol is freely available to anyone who wishes to use it. And maintenance by open organizations ensures that development of the protocol takes place by democratic, rather than oligarchic, processes.
This trilogy of principles represent the most basic guarantees of the integrity of a protocol. If any one of these things is missing, then this means that some attempt is being made to control or limit access to the protocol. In the case of a public protocol, there is no valid reason for doing this.
In addition to its general, industry-wide economic benefits, the adoption of a protocol also brings a unique set of benefits to its developer. These benefits consist of name recognition, and first-mover advantages in terms of development and sales of services and products based on the protocol. There may also be other significant benefits, such as those resulting from ownership of software patents related to the protocol.
These benefits can result in a huge financial windfall for the protocol developer. For this reason, the developer has an enormous vested interest in the adoption of his protocol in preference to any others. And this may lead the developer to promote his protocol in ways which subvert the free and fair competitive process among protocols. One of the ways a business may do this is by seeking to exert inappropriate influence or control over the activities of standards organizations. In particular, the developer may seek to have his protocol labelled as a “standard,” while denying this label to other protocols. Alternatively, a business or group of businesses may form their own “standards organization” as an exclusive promotional vehicle for their own protocol. In either case the standards organization is in effect in the pocket of Big Business, and their discriminatory labelling of their own protocol as a “standard” represents another form of corruption. Though this serves the self-interest of the developer, it is likely to cause the industry to adopt the “wrong” protocol – i.e. not the one that best serves its overall needs. This is enormously detrimental to the industry at large and the consumer.
The incentives for businesses to indulge in these underhanded tactics is in direct proportion to the size of the industry and the financial stakes. And in the wireless data communications industry, the stakes are very high indeed.
As a result of this, we are currently seeing an enormous amount of standards-related activity in the wireless arena. Since 1998 a large number of self-proclaimed standards organizations relating to wireless data have been created, are claiming legitimacy, and are attempting to impose their own protocols on the industry. Among these recently-formed groups are:
- Wireless Application Protocol (WAP) Forum
- Mobile Internet Phone Services (MIPS) Forum
- Global Mobile Commerce Forum (GMCF)
- CDMA Development Group (CDG)
- Universal Wireless Consortium (UWC)
- GSM Alliance
- Global TDMA Forum
- Mobile Data Initiative
- Portable Computer & Communications Association (PCCA)
Each of these organizations is an independent entity, with its own claim of legitimacy, its own protocol publication mechanism, and its own set of restrictions and limitations on participation. Beyond the realm of specific wireless subnetworks, there is no reasonable need for this large number of independent standards organizations.
Many of these organizations are simply an instrument of Big Business. They are the result of a group of businesses forming an industry association or forum, for the purpose of branding their own protocol as a “standard.”
At best, this labelling of some protocols but not others as “standards” is meaningless; it is a semantic shell game. And at worst, this labelling is an attempt by Big Business to market one set of protocols in competition with another. Marketing has its place in the promotion of a company’s own products and services. But an industry protocol represents a public trust, and business marketing has no place in this arena.
We believe that the ultimate criterion of the legitimacy of a protocol is its acceptance and usage in the industry at large. And the industry at large is entirely capable of establishing its own winners and losers by means of free and fair competition among protocols. This arbitrary standards labelling serves only to corrupt this competitive process.
Our philosophy regarding protocol development requires only that the developer make sure that he adheres to the basic trilogy of principles described above. Beyond that, free and fair competition will do the rest.
By making it clear that these self-promoting consortia have no genuine legitimacy, we seek to reduce their influence and the harm they do to the industry.
We are developing the LEAP protocols independently of the IETF, and we have not sought out their formal endorsement by the IETF.
Our decision to work independently of the IETF is a result of our previous experiences with IETF. Based on our interactions with the IETF, we have concluded that the illegitimate influence that the IESG and the IAB exert over non-IETF protocol specifications is counterproductive. We believe that the IESG and IAB are both prejudiced against externally-generate protocols (a frame of mind sometimes referred to as Not Invented Here syndrome), and that they engage in the active supression of competing protocols which originate outside their own domain.
The IETF has become an autocratic organization that acts to suppress innovation rather than encourage it. Indeed, on its own mailing lists, the IETF acronym has been referred to as the “Innovation Extermination Task Force,” and the IETF/IESG/IAB has been referred to as a “cult.” We do not consider either of these characterizations as being in the least inappropriate.
Our conclusion is that Big Business and political interests have now taken over the critical decision making processes within the IETF/IESG/IAB. We have come to this conclusion after many years of attempting to work within the system to bring the IETF back to it its original intended purpose. Our interactions with the IETF relating to several issues are publicly available:
- The complete record of our communications with the IESG and RFC Editor relating to publication of RFC-2188 is available at http://www.esro.org/communicationRecord/index.html.
- The complete record of our communications with the IESG relating to the IESG invitation to place RFC-2188 on standards track is available at http://www.esro.org/noStdTrack/main.html.
- Our complaint regarding the delays in publication of RFC-2188 is available at
- The complete record of our communications with the IESG and RFC Editor relating to publication of RFC-2524 is available at http://www.emsd.org/communicationRecord/index.html.
Based on the above records we have come to the conclusion that the IESG is now characterized by irresponsibility, incompetence and arrogance.
We believe that a lesser IETF will be a better IETF. The IETF has been a source of new protocols in the past, and there is no reason why it cannot continue to create and develop new protocols in the future.
But traditionally, the scope of IETF has gone far beyond this; the IETF has also claimed responsibility for judging, labelling and ratifying protocols. We believe that these IETF functions are unnecessary and inappropriate. All the functions that the IETF claims to provide can be accomplished by means of:
- The Free Protocols Foundation
- The RFC publication process
- Maintenance by open Working Groups
- Free and fair competition among protocols
The first three items above are sufficient to ensure that a protocol is patent-free, is freely available, and is open to democratic and egalitarian development processes.
And the fourth item above provides a more than adequate mechanism for determining which protocols become enduring industry standards, and which fall by the wayside.
So what positive thing can the IETF offer that is not better provided elsewhere? The answer is: not much.
We have no objection to the IETF existing as an entity, developing protocols, and making them available for use. What we demand is that other protocols have exactly the same opportunities as those of the IETF. These consist of the opportunity to be made public, and the opportunity to be judged by means of open competition, and on the basis of their merits.
What we object to most strenuously, is the IETF/IESG/IAB arrogating to itself the power to quash protocols that it considers to be in competition to its own. This is not the job of the IETF/IESG/IAB; this is the job of fair competition.
We believe that the collective intelligence and expertise of the Internet technical community is adequate protection against widespread adoption of “wrong” protocols, and we believe that the market and the consumer can collectively make the right eventual decisions. The actions of irresponsible entities such as IESG and IAB, claiming illegitimate authority to select winners and losers at the time of initial publication of protocols, on the pretext of protecting the network and the consumer, in fact does more harm than good.