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:
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 [3], [1]. RFC publication provides a number of significant advantages:
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
http://www.FreeProtocols.org.
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:
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:
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
http://www.esro.org/joinESROmailingList/esroSpec.html.
To subscribe to the EMSD Development Working Group mailing list, visit
http://www.emsd.org/joinEMSDmailingList/emsdSpec.html.
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.