The Lightweight & Efficient Application Protocols (LEAP) Manifesto

Using Free Protocols & Free Software to build

the Mobile & Wireless Applications Industry

Document Number:	PLPC-100012   [ .bib ]
Version:	1.3
Dated:	October 1, 2001
Group:	LEAP
Primary URL:	http://www.freeprotocols.org/PLPC/100012
Author(s):	Mohsen BANAN, Andrew Hammoude
Organization:	Free Protocols Foundation

SHORT DESCRIPTION

This document describes the Lightweight & Efficient Application Protocols (LEAP), a set of protocols for mobile and wireless applications.

AVAILABLE FORMATS

• PDF: -- 1.6M -- Provides the document in Portable Document Format.
• PS: -- 13M -- Provides the document in Postscript format for printing.
• HTML: -- 3.2M -- Displays the document as a web page.

---

FULL INLINE DOCUMENT

This document describes the Lightweight & Efficient Application Protocols (LEAP), a set of protocols for mobile and wireless applications.

Contents

List of Figures

List of Tables

Chapter 1
Executive Summary

Until now, the Internet has been largely based upon simple protocols. However, the era of simple protocols is now over. The new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality places an entirely new set of requirements on the underlying communications protocols: they must now provide the power efficiency demanded by hand-held wireless devices, together with the bandwidth efficiency demanded by wide area wireless networks.

It is now time for a new generation of protocols to be implemented, designed to address the need for performance, rather than simplicity.

The industry-wide adoption of this new generation of powerful and efficient protocols will have enormous consequences. Protocols addressing the correct requirements will become the lynchpin of a huge new industry. The stakes are enormous, and ferocious competition is to be expected within all segments of the industry. All manner of wild claims and misrepresentations are also to be expected. At the time of writing, the main claimant to the protocol throne is the Wireless Applications Protocol, or WAP. However, WAP will eventually prove to be entirely inadequate to the role being claimed for it.

We have designed a set of protocols, the Lightweight & Efficient Application Protocols, or LEAP, which we believe is destined to displace WAP and become the de facto industry standard. These protocols, published as Internet RFC-2524 and RFC-2188, are designed to address all the technical requirements of the industry, and are oriented towards providing the greatest benefit to the industry and the consumer.

This manifesto is about our vision of the future of the Mobile and Wireless Applications Industry. In the remainder of the manifesto we present the details of our vision, and we justify our claims. We justify our assertion that the industry needs a new generation of protocols, we explain why our protocols fulfil this need, and we describe how and why these protocols will achieve dominance.

The protocols are free, open and in place. Open-source software implementations of the protocols are available for all major platforms. The combination of free protocols and open-source software ensures acceptance of the protocols in the Internet mainstream. There can be no stopping this.

1.1 Technological Scope

Most of our discussion throughout this Manifesto is framed in terms of a particular technology, namely, Mobile Messaging. It is important to bear in mind, however, that Mobile Messaging is just one aspect of a broader technology: Mobile Consumer Data Communications. Mobile Consumer Data Communications refers to the general ability of an end-user to send and receive digital data at a hand-held device via a wireless network. This technology includes Mobile Messaging as a special case, but also includes other wireless data transfer capabilities such as general Internet access, web browsing, etc.

Much of the discussion set forth in this Manifesto applies with equal force to all mobile data communications applications, not just that of messaging. However, it is currently well understood that the dominant application for mobile data communications is, in fact, Mobile Messaging, not web browsing or other Internet applications. Therefore throughout this Manifesto we will focus our attention on the messaging application.

Though our discussion will be framed in terms of Mobile Messaging, the reader should bear in mind that the same principles apply to all forms of mobile data communications.

Also, whenever we speak of the Mobile Messaging industry, we are referring to the totality of what is required to accomplish effective mobile messaging capabilities for the end user.

We are not referring to the implementation of mobile messaging on any particular device, such as a mobile phone, PDA, palmtop PC, laptop PC, or two-way pager. Similarly, we are not restricting our focus to any specific technologies or standards, nor are we restricting our focus to a specific market or set of subscriber services.

Rather, we are referring to the entire set of technologies and constituencies which are required to enable Mobile Messaging. This includes: mobile handheld devices and their manufacturers, wireless modems and their manufacturers, wireless data networks and their operators, ISPs and other service providers, and the set of protocols and software implementations required to allow interplay and cooperation among these various consituencies.

Our purpose in writing this Manifesto is very ambitious: we wish to describe our vision of all that is required to build the entire Mobile Messaging industry.

1.2 Efficiency is the Key Requirement

Engineering is the art of making intelligent trade-offs between conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power efficiency, and bandwidth efficiency.

The 1980s and 1990s were the decades of simple protocols - protocols such as the very aptly named Simple Mail Transfer Protocol (SMTP), and Simple Network Management Protocol (SNMP). A great deal of the success of these and other Internet protocols can be attributed to their simplicity.

The first generation of network engineers and network operators were only able to view network communications in relatively simple terms. It was appropriate to cater to that simplicity with simple protocols. A key reason for the success of these early protocols is the lack of technical sophistication on the part of first-generation network engineers and operators.

Simple protocols are easier to make widespread than “good” protocols (meaning those which have better capabilities and performance), for the basic reason that network engineers and operators are able to adopt and implement simple protocols much more easily than “good” protocols.

However, things have changed. Network communications has now expanded dramatically and forcefully into the wireless and mobile data communications arena, and wireless applications demand efficiency. The move to wide-area wireless has significantly shifted the location of the ideal engineering balance between simplicity and performance - moving it away from simplicity, and towards performance.

We therefore need a new generation of high-performance, efficient protocols, to cater to the demands of wireless applications. The point is sometimes made that the need for efficiency in the wireless arena is a temporary one – that advances in wireless engineering technology in the form of third generation (3G) systems will eliminate existing bandwidth limitations, obviating the need for efficient protocols. As long as the capacity of wireless networks remains finite, however, the need for efficiency will persist. Efficient usage is an inherent requirement for any finite resource, therefore the requirement for efficient bandwidth usage and battery longevity is permanent.

1.3 Conventional Origins of Protocols

Where will the required protocols come from? Traditionally, industry-wide protocols have their origins in one of two sources:

1. The major players in the industry itself. In the case of wireless communications, this means the major telecommunications and wireless network companies.
2. Professional protocol and standards producing associations. In the case of wireless communications, this means the IETF, ITU, ISO, ANSI, TIA and others.

Unfortunately, neither of these groups has produced a set of protocols which meets the industry’s needs. The first group above, represented by a set of telephone companies, has generated the WAP specification. However, as we will argue in detail later, this specification is grossy unfit for its claimed purpose. Among other things it is poorly designed, not the product of open peer review, and crippled with Intellectual Property Right (IPR) restrictions. It is essentially a business construct, not an engineering one. In the long run WAP cannot possibly survive as a viable solution. In the short run it can only have a destructive effect on the wireless industry.

The second group above, most notably represented by IETF, has likewise failed to produce an acceptable standard. IETF represents the tradition of simple protocols, a tradition which wireless communications has made obsolete. Unfortunately, IETF remains rooted in this tradition, and has not adapted to the new realities of wireless communications. Until it does so, IETF will remain ineffective as a protocols and standards body. In the area of efficient protocols, IETF is simply bankrupt.

1.4 Expect the Unexpected

Fortunately, there are other sources of innovation. One of these is the radical new development that comes out of nowhere, taking everybody by surprise. Typically this originates in the actions of a small group of independent experts, with a deep understanding of the technology and industry, and who are passionate about and committed to its health and vigor.

Note that the World Wide Web itself originated in neither of the traditional sources, but instead came from an entirely different and unexpected direction: a group of physicists at the CERN laboratory in Switzerland. As another example, Pretty Good Privacy (PGP), now the de facto standard for electronic data encryption, also came from neither traditional source. It was essentially the creation of a single man: Phil Zimmermann. Armed with a vision and a belief in its value, Zimmermann single-handedly made PGP the dominant consumer encryption application - displacing the IETF alternatives in the process.

The solution to the current wireless application dilemma is also likely to come from an unexpected source – and we believe that we are that source. In the world of the Internet, we have learned to expect the unexpected.

1.5 Our Solution

We have developed a set of protocols which we believe address all aspects of the industry’s needs. Beyond their purely technical requirements, a fundamental requirement of all industry-building protocols is that they be completely open and free from patents and other IPR restrictions – either because no patents actually exist, or because reasonably non-restrictive licenses are granted by the patent holder. In the rest of this document, this is what we mean when we speak of “patent-free” protocols.

The presence of patented components within a protocol is extremely undesirable, since this undermines the ultimate purpose of the protocol: its unrestricted adoption and usage. The process that we have followed in developing our protocols has been such as to ensure that they are entirely open and, as far as this can be guaranteed, patent-free. A significant part of this process consists of our full committment to the processes and procedures of the Free Protocols Foundation (FPF).

The FPF is an organizational framework for the development and maintenance of free protocols. It allows developers to declare publicly that the protocols they have developed are intended to be patent-free, and that it is their intention to keep them patent-free into perpetuity. We have made this declaration through the Free Protocols Foundation with regard to our own protocols.

Note that this is in sharp contrast to the WAP protocols, which include severe IPR restrictions. This creates an unfair market advantage in favor of the initial WAP designers. Our intention is to create a protocol which does not favor any one industry player over another, and places competition where it belongs: on the merits of each company’s individual products and services.

We have created the general framework for a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. We refer to this general framework as the Lightweight & Efficient Application Protocols (LEAP).

The need for efficient protocols extends across all aspects of wireless data communications, including e-mail, web browsing, and other applications. The LEAP architecture accommodates all of these applications. Our initial implementation, however, is focussed on the Mobile Messaging application, since we believe that this is the dominant application for wide-area wireless networks.

All efficient applications have the requirement for an efficient transport mechanism. For this reason, the initial focus of our protocol development effort has been on creating a general efficient transport mechanism. The resulting protocol is referred to as Efficient Short Remote Operations (ESRO). ESRO is a reliable, connectionless transport mechanism, forming the foundation for the development of efficient protocols when TCP is too much and UDP is too little.

Our Efficient Mail Submission and Delivery (EMSD) protocol is built on top of ESRO, and is designed to address the Mobile Messaging application.

Both of these protocols have been published as Internet RFCs: ESRO as RFC 2188, and EMSD as RFC 2524. RFC publication ensures that the protocols are freely, easily and permanently accessible to anyone who wishes to use them.

Note that this also is in stark contrast to WAP, which is self-published by the members-only WAP Forum. Furthermore, the WAP Forum reserves the right to make unilateral changes to its protocols; each of the WAP protocols carries on its cover page the disclaimer, “subject to change without notice.”

Publication of a protocol as an Internet RFC ensures that the protocol will remain stable and permanently available to anyone who wishes to use it, and for this reason is the mainstream Internet publishing method. The declining of the WAP Forum to publish their specifications as Internet RFCs suggests either that the forum wishes to retain an inappropriate degree of control over the specifications, or that the specifications do not meet the minimum technical standards required for RFC publication.

1.6 A Brief History of LEAP

LEAP originated in 1994 as part of the research and development initiatives of McCaw Cellular’s wireless data group (now AT&T Wireless Services). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS network also.

By 1996 McCaw Cellular was fully committed to paging, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless message transport and delivery system. Neda Communications, Inc., an independent consulting company working under contract to McCaw Cellular, played a significant role in the development of the required system. Neda Communications had also been involved from the outset in the development of the CDPD specification.

In 1997 however, soon after the purchase of McCaw Cellular by AT&T, the latter company abandoned narrowband PCS paging altogether. Prior to this event, Neda Communications had secured from AT&T the necessary rights to continue independent development of the protocols. Therefore, recognizing the eventual future need for these protocols, Neda then undertook to continue development of the protocols independently of AT&T. They were eventually completed by Neda, published as RFCs, and now form the cornerstone of the LEAP protocols.

1.7 Making Our Solution Widespread

Our ultimate goal is to make these protocols widespread. Developing and publishing a set of protocols, however, is just the beginning. Protocols become accepted as standards as a result of public review, modification by consensus, and ultimately by standing the test of usage in the industry at large.

To provide a forum for these processes, we have created EMSD.org and ESRO.org. Each of these organizations allows public review of the respective protocol, and provides a mechanism for correction and enhancement of the protocol as a result of collective experience. Any interested person can become a member of these organizations and participate in the further development of the protocols. The only requirement for membership is that participants must adhere to the principles and procedures of the Free Protocols Foundation, ensuring that the protocols remain permanently patent-free.

Note that this also is in sharp contrast to WAP. Participation in WAP, far from being open and public, requires a $27,000 membership fee (as of February 2000), and takes place entirely behind closed doors.

In order for the protocols to become widely accepted, they must be implemented in the form of software solutions that are readily available for deployment by end-users. We have therefore created open-source software implementations of the protocols for most common platforms. Protocol engines are available in the form of portable code which has been ported to a variety of platforms. On the device side, software is available for Windows CE, Palm OS, EPOC, and others. On the message center side, software is available for NT, Solaris, and Linux.

As noted above, our initial emphasis is on the Mobile Messaging application. Protocol engines are only a single component of a larger picture; in order to provide complete solutions to the user it is necessary to integrate these protocols into other existing pieces of software. To that end we have created MailMeAnywhere.org, where fully-integrated solutions in open-source format are made available to the user.

We will initially “prime the pump” by providing free subscriber services through ByName.net and ByNumber.net. This will provide initial support for adoption of the protocols by end-user devices. Usage of the protocols among a sufficient number of user devices will then provide the motivation for usage among the message center systems.

1.8 Complete and Ready

All the components that are needed to accomplish these goals are complete, in place, and ready to go. These components are:

The Protocols.

The protocols are well-designed, meet all the technical requirements of the industry, and are published as RFCs – the mainstream Internet publishing procedure. The complete text of RFC 2188 and RFC 2524 is available at:

http://www.rfc-editor.org

Open Maintenance Organizations.

The protocols are maintained at EMSD.org and ESRO.org, allowing open and non-exclusionary participation in the maintenance of the protocols. For complete details see:

http://www.esro.org and
http://www.emsd.org

Freedom from Patents.

The protocols are patent-free to the best of our knowledge, and are guaranteed to stay that way. This ensures permanent, unrestricted access to the protocols. For more information see:

http://www.FreeProtocols.org

Open-Source Software Implementations.

These are being made available for a wide variety of of platforms and end-user devices, including: pagers and cell-phones; hand-held PCs (Windows CE, Palm PC) and Palm Pilot; Windows 98, Windows 95, and Windows NT; Pine (UNIX, Windows, DOS). For complete details see:

http://www.MailMeAnywhere.org

Free Subscriber Services.

These are provided to support initial deployment of the protocols in end-user devices. For complete details see:

http://www.ByName.net and
http://www.ByNumber.net

Collectively, the above components represent a complete recipe for the success of the LEAP protocols. All the pieces of the puzzle are complete, and there are no missing pieces.

1.9 How to Participate

As noted above, the LEAP protocols are entirely open, and any interested person or organization may participate in their development. To participate in the development of the LEAP protocols in general, visit the LEAP Forum website at http://www.leapforum.org/. To participate in the development of specific members of the LEAP family of protocols, visit the ESRO.org website at http://www.esro.org/, or the EMSD.org website at http://www.emsd.org/.

All of the above websites host mailing lists for commentary and general information exchange regarding the protocols. In particular, ESRO.org and EMSD.org host Working Group mailing lists for active development of their respective protocols.

In addition, we invite participation in the development of The LEAP Manifesto itself. We expect that as the LEAP family of protocols grows and becomes implemented on additional platforms, additional articles will be included in the Manifesto. Any person or organization may submit information or articles that they feel are appropriate for inclusion in the Manifesto; any such material will be given due consideration by the Manifesto editor.

In addition, we would welcome the translation of key Manifesto articles into foreign languages. One such translation has already taken place; the Manifesto article The WAP Trap is now available in French under the title Le WAP a la Trappe. Other key articles that would be greatly desirable in foreign language translations include LEAP: One Alternative to WAP, and Operation WhiteBerry. Persons interested in writing foreign language translations are asked to contact the Manifesto editor at info@leapforum.org.

We also invite general commentary and criticism of the Manifesto. Please let us know of any errors, omissions or ambiguities you may find in the Manifesto. Any input or commentary should be submitted to the Manifesto editor at info@leapforum.org.

1.10 Who We Are

Throughout the Manifesto, we frequently refer to ourselves in the first person, and we also refer to several organizations and domains that are in some way related to the LEAP protocols. The question may be asked, who exactly are “we”? Who are the authors of the Manifesto, and what is their relationship to the organizations involved in the development of LEAP? Who owns LEAP? In this section we provide the answers to these questions.

Mohsen Banan.

Mohsen Banan is the principal editor of The LEAP Manifesto; he is also the author of many of its component articles. Several other authors also wrote and/or contributed material to certain component articles; these are acknowledged in the appropriate articles. First-person references throughout the Manifesto refer to the principal editor, Mr. Banan.

Mr. Banan is also the president of Neda Communications, Inc. He is also the president and a board member of the Free Protocols Foundation.

Neda Communications, Inc.

Neda Communications, Inc. is a private, for-profit company located in Bellevue, WA. Neda provides consulting services and develops products and services relating to wireless data communications.

Neda has independently led the development of the LEAP protocol specifications since 1997. Neda has also developed a comprehensive set of software implementations of the LEAP protocols, which it intends to subject to the GNU Public License and make freely available.

The LEAP Protocols.

The design and development of the LEAP protocols was primarily carried out by several engineers working at Neda Communications, Inc. The development effort was led and coordinated by Mohsen Banan. RFC-2188 was published jointly by Neda and AT&T personnel. RFC 2524 was published individually by Mohsen Banan. As the primary author of both RFCs, patent-free declarations for both protocols were made by Mohsen Banan and on behalf of Neda.

No one owns the LEAP protocols. The protocol specifications reside entirely in the public domain.

The LEAP Forum.

The LEAP Forum is a clearing house for information and pointers relating to the LEAP protocols. The LEAP Forum is not a standards organization, it is not a legal entity of any kind, and it is not a membership organization. The LEAP Forum maintains a mailing list for the free interchange of information and commentary regarding the LEAP protocols. Any interested person or organization may subscribe to the mailing list. The LEAP Forum website and mailing list are presently hosted by Neda equipment and network resources, and managed by Neda personnel.

For more information, visit the LEAP Forum website at http://www.leapforum.org/.

ESRO.org and EMSD.org.

ESRO.org and EMSD.org are open organizations for the development and maintenance of the ESRO and EMSD protocols respectively. Neither organization is a standards organization, nor a legal entity of any kind, nor a membership organization. They are simply forums to allow information exchange and cooperative effort relating to the LEAP protocols and technology.

Both organizations maintain several mailing lists, to which any interested person or organization may subscribe. The ESRO and EMSD websites and mailing lists are presently hosted by Neda equipment and network resources, and managed by Neda personnel.

In particular, each organization hosts a Working Group mailing list for active development of the corresponding protocol. Mohsen Banan is the current chairperson of both Working Groups, with responsibility for coordinating the Working Group development effort.

For complete information, visit the appropriate website at either
http://www.esro.org/ or http://www.emsd.org/.

Free Protocols Foundation.

The Free Protocols Foundation is a 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 that the resulting protocol is patent-free. The LEAP protocols conform fully to these policies and procedures. Free Protocols Foundation board members include Mohsen Banan and Richard Stallman.

For more information see the Free Protocols Foundation website at http://www.FreeProtocols.org.

1.11 About The LEAP Manifesto

The purpose of The LEAP Manifesto is to provide a complete description of the LEAP protocols and their intended role in the development of the Mobile Messaging industry. The Manifesto includes:

• An overview of the Mobile Messaging industry, and a description of the essential factors that are required for its long term success and growth.
• A technical description of the LEAP protocols themselves.
• A description of the process used to develop the LEAP protocols, and how and why this differs from the conventional development process.
• Technical descriptions of key aspects of the LEAP protocols, including their efficiency, and their implementation on Windows CE devices and Palm OS devices.
• An analysis of several closed Mobile Messaging solutions (e.g. WAP), and a description of LEAP’s superiority to these closed solutions.
• A description of our strategy for encouraging widespread usage of the LEAP protocols, including the distribution of open-source software implementations of the protocols, and the availability of free subscriber services.

1.11.1 Manifesto Organization

The LEAP Manifesto is organized as a series of largely independent articles. Each of these articles stands on its own, and can be read and understood independently of the others. Together, these articles provide a complete picture of the Mobile Messaging industry and the role of the LEAP protocols. Since each article is intended to be self-contained, some material is duplicated in more than one article.

The LEAP Manifesto consists of the following articles:

• Executive Summary. An overview summary of the entire LEAP Manifesto. The Executive Summary provides a brief description of all the major elements of the manifesto.
  First Published: 2000/8/4 Last Updated: 2000/12/5
  Article formats: [HTML] [PDF] [PS] [Text Only]
• Part I: The LEAP Protocols
  • Overview of the LEAP Protocols. A general overview description of the LEAP protocols.
    First Published: August 4, 2000
    Last Updated: August 8, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • The LEAP Protocol Development Model. 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.
    First Published: August 4, 2000
    Last Updated: June 16, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • Free Protocols Foundation Policies and Procedures A description of the Free Protocols Foundations processses to ensure the development and maintenance of patent-free protocols.
    First Published: March 29, 2000
    Last Updated: June 26, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • ESRO: A Foundation for the Development of Efficient Protocols. A technical description of ESRO, the transport mechanism component of LEAP.
    First Published: August 4, 2000
    Last Updated: August 9, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • EMSD: The LEAP E-Mail Component. A technical description of EMSD, the e-mail component of LEAP.
    First Published: August 4, 2000
    Last Updated: July 14, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • Efficiency of EMSD. A technical paper analyzing the efficiency characteristics of EMSD and comparing its efficiency to other e-mail protocols.
    First Published: October 23, 1996
    Last Updated: August 16, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • A Brief History of LEAP. A summary of the major events in the evolution of the LEAP protocols.
    First Published: August 4, 2000
    Last Updated: September 20, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • The Future of LEAP. A description of the planned future development of LEAP, including descriptions of several LEAP-based products and services which are currently under development.
    First Published: August 4, 2000
    Last Updated: June 14, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
• Part II: LEAPing Over Closed Solutions
  • The WAP Trap. A detailed criticism of a set of specifications called the Wireless Application Protocol, or WAP. This article demonstrates that WAP is entirely unfit to play the role of a Mobile Messaging industry standard.
    First Published: April 3, 2000
    Last Updated: May 26, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • LEAP: One Alternative to WAP. A point-by-point comparison of the LEAP protocols to the WAP specifications. This article demonstrates that LEAP has all the desirable characteristics of an industry standard protocol that WAP lacks.
    First Published: August 4, 2000
    Last Updated: December 6, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • WAP Scraps. A discussion of what can be salvaged from what remains of WAP.
    First Published: August 28, 2001
    Last Updated: August 28, 2001
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • Operation Whiteberry. A description of how equivalent functionality to the closed BlackBerry mobile messaging solution can be implemented based on a completely open model, using existing open-source software implementations of LEAP, and existing off-the-shelf hardware components.
    First Published: February 27, 2001
    Last Updated: November 3, 2002
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
• Part III: Making LEAP Widespread
  • Strategy for Making LEAP Widespread. A description of our strategy for encouraging widespread usage of the LEAP protocols, including the distribution of open-source software implementations of the protocols, and the availability of free subscriber services.
    First Published: August 4, 2000
    Last Updated: August 8, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • EMSD on Windows CE. A technical paper describing the architecture and implementation of EMSD on Windows CE devices.
    First Published: March 3, 1997
    Last Updated: August 16, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • LEAP on Palm OS. A technical paper describing the architecture and implementation of LEAP on Palm OS devices.
    First Published: September 27, 2001
    Last Updated: September 27, 2001
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • LEAP in JAVA. A technical paper describing the architecture and implementation of LEAP in JAVA.
    First Published: February 4, 2003
    Last Updated: February 4, 2003
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]

    LEAP on Linux Based PDAs. A technical paper describing the architecture and implementation of LEAP on Linux Based PDAs.
    First Published: September 27, 2001
    Last Updated: September 27, 2001
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]

  • Trying out LEAP. A step-by-step, hands-on demonstration of how the LEAP protocols can be used to turn any Windows CE device into a fully functional Mobile Messaging device.
    First Published: June 12, 1998
    Last Updated: June 12, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • WhiteBerry and Bluetooth. A description of how WhiteBerry and Bluetooth can be used in combination to bring new and enhanced messaging capabilities to the mobile professional.
    First Published: July 27, 2001
    Last Updated: July 31, 2001
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • Use of EMSD for Mail Notification. A description of how EMSD can be used to provide a general Mail Notification service.
    First Published: TBD
    Last Updated: TBD
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
  • Lessons From History: Comparative Case Studies. An analysis of the factors which lead to the success or failure of protocols, including discussions of several historical case studies.
    First Published: August 4, 2000
    Last Updated: July 7, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]
• Part IV: The Mobile Messaging Industry
  • The Mobile Messaging Industry. An overview of the Mobile Messaging industry, and a description of the essential factors that are required for its long term success and growth.
    First Published: August 4, 2000
    Last Updated: August 10, 2000
    Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only]

1.11.2 Draft Articles

The LEAP Manifesto is a work in progress, and various additional articles are planned for future inclusion in the Manifesto.

Some of these future articles already exist in draft form, and are available for review in the Draft Documents section of the LEAP Forum website at http://www.leapforum.org/draft-leapManifesto/. As these and other articles are completed, they will be incorporated into the Manifesto.

1.11.3 Getting the Manifesto

The LEAP Manifesto and all of its component articles are available in multiple formats, including HTML, PDF, PostScript, and plain text. You can view or download the Manifesto in any of these formats from the LEAP Forum website at http://www.LeapForum.org/leap/index.html. The LEAP Manifesto is also available at the Free Protocols Foundation website at http://www.FreeProtocols.org/leap/index.html.

Part I
The LEAP Protocols

Chapter 2
Overview of the LEAP Protocols

2.1 Introduction

The key component of the Manifesto is a set of mobile messaging protocols called the Lightweight & Efficient Application Protocols, or LEAP. LEAP is a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. This article provides a brief overview of the LEAP protocols; complete details are provided elsewhere in The LEAP Manifesto [65].

2.2 The Need for Efficiency

Engineering is the art of making intelligent trade-offs between conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power efficiency, and bandwidth efficiency.

The 1980s and 1990s were the decades of simple protocols - protocols such as the very aptly named Simple Mail Transfer Protocol (SMTP), and Simple Network Management Protocol (SNMP). A great deal of the success of these and other Internet protocols can be attributed to their simplicity.

The first generation of network engineers and network operators were only able to view network communications in relatively simple terms. It was appropriate to cater to that simplicity with simple protocols. A key reason for the success of these early protocols is the lack of technical sophistication on the part of first-generation network engineers and operators.

Simple protocols are easier to make widespread than “good” protocols (meaning those which have better capabilities and performance), for the basic reason that network engineers and operators are able to adopt and implement simple protocols much more easily than “good” protocols.

However, things have changed. Network communications has now expanded into the wireless and mobile data communications arena, and wireless applications demand efficiency. The move to wide-area wireless has significantly shifted the location of the ideal engineering balance between simplicity and performance - moving it away from simplicity, and towards performance.

Wireless networks are constrained by bandwidth limitations, and the hand-held devices they serve are constrained by limitations such as display size, battery capacity, and memory capacity. These constraints place an extremely high premium on the efficiency of data transfer.

Existing Internet protocols do not provide the required efficiency. We therefore need a new generation of high-performance, efficient protocols, to cater to the demands of wireless applications. The point is sometimes made that the need for efficiency in the wireless arena is a temporary one – that advances in wireless engineering technology in the form of third generation (3G) systems will eliminate existing bandwidth limitations, obviating the need for efficient protocols. As long as the capacity of wireless networks remains finite, however, the need for efficiency will persist. Efficient usage is an inherent requirement for any finite resource, therefore the requirement for efficient bandwidth usage and battery longevity will remain.

2.3 Technical Overview of LEAP

The LEAP protocols are intended to be an enabling catalyst for the growth of the wireless-IP based Mobile Messaging industry, and have been designed with this goal in mind from the outset. They have been designed as a genuine enabling technology which will bring enormous benefits to the industry and the consumer. They are a sound engineering construction based on true openness and patent-freedom.

The LEAP protocols a general-purpose solution to the problem of efficient message transfer, and their use is not limited to any particular device type or network. In particular, LEAP is compatible with all wireless-IP networks. Examples of wireless networks which provide native support for LEAP are CDPD, GSM, packet CDMA, and PCS.

The basic organization of the LEAP protocols is shown in Figure 2.1.

---

---

2.3.1 The ESRO Layer: Efficient Transport Services

As shown in Figure 2.1, the LEAP protocols are layered. The lower layer is called Efficient Short Remote Operations, or ESRO. The ESRO layer provides reliable connectionless transport services which can be used for a variety of applications. For example, in addition to mobile messaging services, ESRO can also be used as a transport service for credit card verification applications and efficient micro browsers.

For more information on ESRO see the article ESRO: A Foundation for the Development of Efficient Protocols within The LEAP Manifesto, or visit the ESRO website at http://www.esro.org/.

2.3.2 The EMSD Layer: Efficient E-Mail

One of the efficient application layers built on top of ESRO is called Efficient Mail Submission & Delivery, or EMSD. EMSD is the component of LEAP that addresses the Mobile Messaging application.

EMSD is a specialized native Internet messaging protocol. It defines a similar set of services to the existing SMTP protocols. It defines a complete set of rules for message submission (end-user device to server) and message delivery (server to end-user device). EMSD meets or exceeds the level of functionality, reliability and security provided by the existing SMTP protocols.

Though its use is not limited to wireless networks, EMSD has been designed specifically to address the requirements of wireless networks, such as CDPD, Wireless-IP, Mobile-IP. In particular, EMSD has been designed with a very strong and clear emphasis on efficiency.

EMSD is highly optimized for the submission and delivery of short (typically 4 kilobytes or less) Internet e-mail messages, and is therefore extremely well suited to the wireless environment. EMSD improves on existing messaging protocols by optimizing the exchange between the server and the end-user device, both in terms of the number of bytes transferred and the number of transmissions. Because of the required timeliness of the messages, mailbox access protocols like POP and IMAP are not used. EMSD is the only truly open messaging protocol that is specifically designed for the wireless network environment.

EMSD is a natural extension of the existing Internet e-mail environment, and accommodates the two-way paging model of usage, in which time-critical messages are ”pushed” to the recipient.

Any network or network operator which faces significant bandwidth and capacity limitations can benefit from the use of EMSD. Any user of a network who must bear high costs for measured network usage can benefit from the use of EMSD.

The initial use of EMSD is expected to be primarily to provide Mobile Messaging services over IP-based wireless networks. However, EMSD can also function as an adjunct to Mail Access Protocols for ”Mail Notification Services.”

For more information on EMSD see the article EMSD: The LEAP E-Mail Component within The LEAP Manifesto, or visit the EMSD website at http://www.emsd.org/.

2.3.3 The EHTD Layer: Efficient Web Browsing

The Efficient Hyper Text Delivery (EHTD) layer is a hypertext transfer protocol which is optimized for the efficient transfer of short markup pages. EHTD is the component of the LEAP protocols which facilitates web browsing. Along with EMSD, EHTD also benefits from the reliable efficient services of ESRO. A multiplicity of efficient markup languages can be used in conjunction with EHTD. Development of the EHTD protocol is currently in progress.

2.3.4 Other Efficient LEAP Applications

Various other efficient application protocols are either under development, or anticipated for future development. One of these is the Efficient Dictionary protocol, or E-DICT, which will enable efficient access to dictionaries and other look-up data structures. A starting point for the E-DICT protocol is currently being created. In developing E-DICT, we intend to build on the existing work already done in the context of the DICT protocol.

We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementations of ESRO-based instant messaging, chat, white pages, and others.

2.4 Efficiency Characteristics of LEAP

All LEAP protocols are designed with efficiency in mind. In this section we describe the efficiency characteristics of EMSD, the LEAP e-mail protocol. Other LEAP protocols deliver similar efficiency benefits.

Most existing Internet e-mail protocols are designed with simplicity, and continuity with SMTP traditions, as two of the primary design requirements. These requirements are in conflict with efficiency of data transfer, and for this reason most existing Internet e-mail protocols are not efficient.

EMSD, on the other hand, has been designed with efficiency as its primary requirement. For this reason, EMSD is a great deal more efficient than existing Internet e-mail protocols.

A detailed efficiency study of the LEAP protocols is provided in the article entitled Efficiency of EMSD [57] within The LEAP Manifesto. That article presents various efficiency studies which compare the efficiency of EMSD to other e-mail protocols such as SMTP, POP and IMAP, and which demonstrate the efficiency advantages of EMSD.

In this section we provide a brief summary of EMSD’s efficiency characteristics. A comparison of the efficiency of the EMSD protocol to other messaging protocols is provided in Figure 7.3, which shows the delivery traffic overhead for EMSD and three other e-mail protocols: SMTP, IMAP and POP.

---

---

As the figure shows, EMSD is much more efficient than SMTP, POP and IMAP. For submission and delivery of short e-mail messages, EMSD is up to five times more efficient than the ubiquitous SMTP e-mail messaging protocols, both in terms of the number of packets transmitted, and in terms of number of bytes transmitted. Even with pipelining and other possible optimizations of SMTP, EMSD remains up to three times more efficient than SMTP, both in terms of the number of packets transmitted, and in terms of number of bytes transmitted.

By minimizing the network traffic required to send and receive messages, EMSD meets the needs of the mobile communicator. The extreme efficiency of the EMSD protocol translates into bandwidth efficiency, which in turn translates into:

• Efficient use of carrier bandwidth, and therefore increased capacity for network operators
• Longer battery life for mobile phones, PDAs and other wireless Internet devices
• Cheaper network usage costs for the end-user
• Reduced latency for the end-user
• Improved support for marginal coverage areas

2.5 LEAP: A Basis for Convergence

An illustration of how LEAP works is shown in Figure 22.4. As the figure shows, LEAP provides complete openness of interoperability among Mobile Messaging devices, message centers, and wireless networks.

---

---

LEAP will thus have the effect of unifying the entire Mobile Messaging industry under a set of open Internet Protocol (”IP”) standards and protocols so that, in the manner of the World Wide Web, all of the Mobile Messaging networks will effectively operate as one.

In order to achieve this convergence, it is not sufficient for the Mobile Messaging industry merely to adopt a set of common protocols. Many would claim that WAP is in fact just such a set of common protocols. However, a further essential attribute of the required protocols is that they must be a truly integral, “end-to-end” part of the Internet, as opposed to “gateways” which accommodate unnecessary gatekeepers and middlemen.

LEAP is based on the concept of the Internet end-to-end model, in which direct communication between the client and the server assumes that the role of the network service provider is merely that of a pipe – i.e. a passive communication conduit. The Internet end-to-end model assumes that both ends are under the control and choice of the user, and that the servers are widespread, from a variety of providers, and under no specific administration or control. The Internet end-to-end model is in sharp contrast to the traditional phone company and telecommunications approach, which inserts gateways between the two ends, and creates control and exploitation opportunities for the telecommunication operators.

Bearing in mind that the natural convergence of all wireless networks to IP at Layer 3 is well under way and rapidly progressing, the key remaining requirements are: efficiency, lightweightness, miniaturization, and conformance to the Internet end-to-end model. LEAP fulfils all of these requirements. By serving as the necessary missing link, LEAP will become the ultimate basis for convergence.

The mobile e-mail component of LEAP is EMSD. In the spirit of the Internet end-to-end model, the EMSD protocol will facilitate the convergence of the IP-based two-way paging industry, and Internet e-mail, in a natural and transparent manner.

2.6 The End-User’s Experience

The entire LEAP family of protocols bring efficiency and functionality benefits to the user of miniaturized mobile devices. In this section we describe the user’s experience of an EMSD-enabled device.

Mobile users may not always have the benefit of a wired connection, because of their frequent mobility. They may have a permanent computing system elsewhere, at which they can review large messages at their leisure (for example, messages containing Word documents, Excel spreadsheets, images, etc.). While on the move, however, they need to be kept apprised of important information that requires their immediate attention. Such information cannot wait for them to find the time to set up a laptop and dial in to check for messages. They must be able to accept messages immediately, at any time, and on a device that they can carry anywhere.

The experience of the end-user in using LEAP-based Mobile Messaging technology is illustrated in Figure 13.2.

---

---

The user equips him/herself with an EMSD device. The EMSD device could be a dedicated two-way pager, or a hand-held device (such as a PalmPC) with a wireless (for example CDPD) modem. While the device can be turned off, the modem will remain on at all times to accept incoming messages.

Anyone with access to the Internet can now send a message to this user. The EMSD Service Provider accepts the message from the Internet e-mail system via standard Internet protocols, then delivers the message to the user’s device via EMSD protocols. Since the modem is always on, the message can be accepted at any time, and the user can be notified immediately (in any of the ways commonly used for pager notification) that a message has arrived. The user will then activate the EMSD device and read the message.

To send a message the user enters the message, then submits it to the EMSD Service Provider via the EMSD protocols. The Service Provider then acts like a standard Internet Service Provider and sends the message to its destination.

The end-user device may have a limited display area and a limited keyboard. This is very much the case for today’s cell phones, for example. If so, both the end-user and his/her correspondents may wish to make use of canned messages to facilitate their communication. These canned messages may be defined by the system or end-user device, or they may defined by the message originator as embedded multiple-choice responses.

Figure 13.2 illustrates how the Mobile Messaging needs of a typical user (we’ll call him Joe) are provided by the LEAP technology. This figure includes all the required technological components, and shows how they interoperate to satisfy Joe’s needs. The figure includes three major components:

1. Joe requires some form of handheld mobile device, such as a cell phone or a PDA. This component is shown on the left side of the figure. The device must include the appropriate LEAP device software, allowing it to use the LEAP protocols to communicate with LEAP-enabled Message Centers, either directly over the Internet, or via a Subscriber Service system.
2. Joe requires a set of Subscriber Services to support his Mobile Messaging capability. This component is shown in the center of the figure.
3. Joe may also wish to have LEAP-based Mobile Messaging capability on a Personal Desktop system at home, or on a Corporate Intranet system at his office. These components are shown on the right side of the figure.

If Joe receives a generic (i.e. non-LEAP) e-mail message over the Internet, then this will be fielded by his Subscriber Service provider, then forwarded to Joe’s mobile device using the LEAP protocols.

Meanwhile, e-mails for Joe may be received in either his home or office mailbox systems. Joe may configure either of these systems to forward certain e-mails to his mobile device on a selective basis. If so, the qualifying e-mails will be forwarded to him directly over the Internet, using the LEAP protocols. The Subscriber Services system need not be involved in the transmission of these forwarded e-mails, since they are being sent from one LEAP-enabled system to another.

In summary, the end-user experience described above represents a superset of the capabilities of the RIM BlackBerry [tm] system. The market success of BlackBerry clearly demonstrates the large user demand for this kind of service. By providing the same functionality of BlackBerry in a completely open fashion, the benefits to the consumer will be that much greater. For further discussion, see the article Operation WhiteBerry in The LEAP Manifesto.

2.7 The LEAP Development Process

The LEAP protocols are intended to be open in the fullest 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. Therefore the processes and procedures used throughout the development and maintenance of the LEAP protocols have been such as to endow them with these characteristics, and to ensure their integrity as public protocols.

A detailed description of the LEAP development process is provided in the article entitled The LEAP Protocol Development Model within The LEAP Manifesto. In the following sections we provide a brief summary of the major development principles.

2.7.1 Patent-Freedom

The development and maintenance of the LEAP protocols conforms fully to the policies and procedures of the Free Protocols Foundation. In particular, Neda has declared to the Free Protocols Foundation that the LEAP protocols are patent-free to the best of its knowledge, and that it intends to keep them patent-free permanently. For more information see http://www.FreeProtocols.org.

2.7.2 RFC Publication

Both protocols have been published as Internet RFCs; ESRO in September 1997 as RFC-2188 [91], and EMSD in March 1999 as RFC-2524 [5]. RFC publication is the mainstream Internet publishing procedure, ensuring that the protocols are freely, easily and permanently accessible to anyone who wishes to use them.

2.7.3 Open Maintenance Organizations

To provide an open forum for the continued development and maintenance of the LEAP protocols, Neda has established a public organization for each protocol.

The ESRO and EMSD protocols are maintained, respectively, by ESRO.org at http://www.esro.org/, and by EMSD.org at http://www.emsd.org/.

Each of these organizations allows public review of the respective protocol, and provides mechanisms for enhancement of the protocol as a result of collective experience.

Any interested person may participate in the further development of the protocols. Participation in the development process is entirely open and non-exclusive; there are no membership fees.

2.8 LEAPing over WAP

A set of specifications called the Wireless Application Protocol, or WAP, exists already, and purports to do the same things that LEAP does. However, the WAP specifications are entirely unfit for their claimed purpose, and are doomed to technological and political failure. A detailed criticism of WAP and justification of these statements is provided in an article called The WAP Trap [66] within The LEAP Manifesto.

LEAP is an alternative to WAP, that does in fact what WAP does only in fiction. For a point-by-point comparison of LEAP to WAP, see the article entitled LEAP: One Alternative to WAP [64] within The LEAP Manifesto.

Those characteristics of WAP that make it wholly unfit to be the industry standard are summarized in Table 11.1, along with the corresponding characteristics of the LEAP protocols.

2.9 A Brief History of LEAP

LEAP originated in 1994 as part of the research and development initiatives of McCaw Cellular’s wireless data group (now AT&T Wireless Services). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS network also.

By 1996 McCaw Cellular was fully committed to paging, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless message transport and delivery system. Neda Communications, Inc., an independent consulting company working under contract to McCaw Cellular, played a significant role in the development of the required system. Neda Communications had also been involved from the outset in the development of the CDPD specification.

In 1997 however, soon after the purchase of McCaw Cellular by AT&T Wireless, the latter company abandoned the wireless messaging project. Prior to this event, Neda had secured from AT&T the necessary rights to continue independent development of the protocols. Therefore, recognizing the eventual future need for these protocols, Neda then undertook to continue development of them independently of AT&T. They were eventually completed by Neda, published as RFCs, and now form the basis of the LEAP protocols.

Prior to abandoning wireless messaging, AT&T Wireless Services invested several million dollars in related development work. In creating LEAP, therefore, Neda was able to build upon a large abandoned investment by AT&T Wireless.

Chapter 3
The LEAP Protocol Development Model

3.1 Introduction

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.

3.2 Protocol Phases of Development

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:

1. 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.
2. Global Parameter Assignment. If necessary, global parameters must be assigned to the protocol, for example by the IANA.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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).

3.2.1 Initial Protocol Development

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.

3.2.2 Global Parameter Assignment

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.

3.2.3 Protocol Publication

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 [91], [5]. 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.

3.2.4 Patent-Freedom

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.

The Free Protocols Foundation

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

LEAP’s Adherence to the FPF Procedures

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.

Author’s Patent-Free Declaration

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.

3.2.5 Maintenance and Enhancement

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.

Open Maintenance Organizations

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.

Working Groups

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.

Maintaining Patent-Freedom

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.

3.2.6 Endorsement by a Standards Body

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.

3.3 Economic Consequences of Protocols

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.

3.3.1 Principles for Maintaining Protocol Integrity

We believe that there are three basic, fundamental principles for defending against these sorts of underhanded activities. These are:

• Patent-freedom
• 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.

3.4 Standards Organizations: Do They Mean Anything?

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.

3.5 Our Independence of the IETF

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
  http://www.esro.org/iesgNote/index.html.
• 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.

3.5.1 Do We Need the IETF?

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.

Chapter 4
Free Protocols Foundation Policies and Procedures

4.1 Introduction

4.1.1 The Patent Debate

At the time of writing, there is an on-going debate within the software industry regarding software patents. Like many others within the industry, at the Free Protocols Foundation we regard the historical tradition of patents as being entirely inappropriate for software.

We consider software patents to have the effect of inhibiting free and open competition within the software industry, and to be extremely detrimental to the industry and the consumer. A complete discussion of the software patent issue is outside the scope of this document. For more information on this subject see [1] or [2].

4.1.2 How Patents Affect Protocols

Patents are applied to software, not to protocols. It is not possible to patent a protocol; in general only a process or an algorithm can be patented. However, a protocol may include a patented algorithm as an integral part of its specification. In this case, any software implementation of the protocol requires the use of patented software. That is, a patented process is an inherent part of the protocol.

Even if a protocol does not explicitly decree the use of a specific patented software process, it may still be the case that any practical implementation of the protocol requires the use of patented software components. The protocol could in principle be implemented in a way which avoids the use of patented software; in practice, however, the result would be a significantly inferior implementation, for example in terms of efficiency.

In either case, the protocol effectively implies the use of patented software. We will refer to any such protocol as a patented protocol. That is, a patented protocol is any protocol whose practical implementation requires the use of patented software components.

We will use the term patent-free protocol, or just free protocol, to refer to a protocol which is functionally free from software patents. By “functionally free from software patents,” we mean either that the protocol is truly free from patents, or if the protocol does imply the use of patented software, that the patent-holder has granted non-restrictive rights to include the patented software components in implementations of the protocol.

In either case, the result is that the protocol can be freely implemented and used by anyone, without encountering significant restrictions.

4.1.3 Difficulties Relating to Software and Protocol Patents

Because of the current state of affairs regarding software patents, it is no longer possible to be absolutely certain that any particular protocol is patent-free. Whether or not a new invention or technology violates any existing patents has traditionally been determined by means of a patent-search – a direct search and examination of all relevant pre-existing patents. In the case of a physical technology, this yields a more or less definitive answer as to whether or not the technology violates any existing patents.

In the case of software, however, it is not possible to answer this question with the same degree of certainty. The basic reason for this lies in the very high degree of subtlety and complexity of modern software systems. A software system may contain hundreds or thousands of individual software constructs, any one of which may potentially violate an existing patent. Furthermore, it is very difficult to establish a taxonomy of existing software patents. A taxonomy is required to guide the patent-search process – the taxonomy defines which patents are “related” to the technology under search. Without a well-defined and meaningful taxonomy, it is not possible to define an appropriate scope of search.

In other words, a software system may contain a small universe of software constructs. Meanwhile, the Patent and Trademark Office has established a small universe of software patents. Unfortunately, there is no way to establish with certainty, that none of the elements of one universe also reside in the other universe.

To make matters worse, there can be room for dispute regarding whether or not a particular software construct violates a particular patent. The patent-holder may claim that it does, while the software developer claims that it does not. If the two parties are unable to come to agreement, the issue can only be resolved in the courts.

Finally, because of the delay between a company filing a patent application and the granting of the patent by the PTO, it is entirely possible for a company to conduct a software patent-search with negative results, only to discover subsequently that a patent has been granted after-the-fact, which now places its software in violation.

For all these reasons, it has now become essentially impossible to establish with certainty that a particular piece of software is, and will remain, truly patent-free. Likewise, it has become impossible to establish with certainty that a particular protocol is, and will remain, patent-free.

4.1.4 Terminology

Legal rights such as patents and copyright are sometimes referred to collectively as “Intellectual Property Rights.” Although this is a very commonly used term, we will avoid using it in this document.

Along with other authors, we object to the use of this term on the grounds that it blurs the distinction between intellectual items and material ones. The law allows ownership rights to be asserted with regard to both types of item, and therefore both may be considered in some sense to be “property.” However, we regard intellectual entities such as software and protocols to be fundamentally different in nature to material items, and worthy of entirely different legal treatment relating to questions of ownership. For more discussion about this point, see [3].

Where necessary, we will use explicit terms such as “patent,” or “copyright,” to refer to legal rights relating to intellectual constructs.

Definitions

Throughout this document, we will use the following terms with the meanings indicated:

• Truly Patent-Free Protocol. A protocol that can be implemented in the form of entirely patent-free software. A Truly Patent-Free Protocol contains no limitations whatsoever on its dissemination and use, and may be freely implemented by anyone, without restriction.
• Functionally Patent-Free Protocol. A protocol for which there are either no known software patent restrictions, or where software patent restrictions are known to exist, non-restrictive usage rights have been obtained from the patent-holder.
• Free Protocol Specification. A protocol that conforms to the policies and procedures of the Free Protocols Foundation relating to patents, copyright, and confidentiality. These procedures are set forth in Section 4.6.
• Declared Patent-Free Protocol. A protocol for which a declaration has been made, to the Free Protocols Foundation, that it conforms to the procedures of Section 4.6.
• Author of a Protocol. The individual, company or organization, or the set of individuals, companies or organizations, who are responsible for the creation, development, maintenance, or enhancement of the protocol specification.
• Working Group. An open-ended set of individuals or organizations who collectively work towards the creation, development, maintenance, or enhancement of the protocol specification.
• Free Protocol Development Working Group. A Working Group which has voluntarily elected to adhere to, and be bound by, the policies and procedures of the Free Protocols Foundation regarding patent-freedom.
• Free Protocol Developer. A contributor to a Free Protocol Development Working Group.

4.1.5 About the Free Protocol Processes and Procedures

This document establishes a set of policies and procedures for protocol development that is designed to ensure, as far as this is possible, that the resulting protocol is functionally patent-free. The purpose of these procedures is to create a resulting protocol that is either free from patent restrictions, or for which non-restrictive usage rights have been obtained from the patent-holder. These procedures are set forth in Section 4.6.

The procedures of Section 4.6 are based on a similar set of procedures defined by the IESG (Internet Engineering Steering Group). Specifically, the FPF procedures are an extension of Section 10, Intellectual Property Rights, of RFC 2026, The Internet Standards Process – Revision 3 [22].

That section defines the procedures to be followed by the IETF (Internet Engineering Task Force) relating to patent-freedom. However, the scope of RFC 2026 is largely limited to the needs of the IESG itself; in particular, the patent-related procedures of Section 10 of RFC 2026 are limited to standards-track documents and other IETF-specific purposes. Thus, while these patent procedures may be entirely adequate for the needs of the IETF, they are not adequate to dealing with patent-freedom in a more general setting.

The processes and procedures in Section 4.6 of this document are therefore an extension of the RFC 2026 procedures, designed to address the need for patent-freedom procedures in general. They are intended to be a set of general-purpose processes which can be adopted by any protocol development organization.

4.1.6 About this Document

This document is available in several alternative formats at Free Protocols Foundation website
(http://www.freeprotocols.org/freeProtocolProcess):

• ONE-HTML: Displays the entire document as a single web page.
• SPLIT-HTML: Displays the document as a set of linked web pages, starting from the Table of Contents.
• PDF: Provides the document in Adobe Acrobat format. Note that the Adobe Acrobat Reader is required to read this format. The Acrobat Reader can be downloaded from the Adobe website.
• PS: Provides the document in PostScript format for printing.
• Text Only: Provides the document in text-only format.

4.2 The Protocol Development Process

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.

Also, protocols can have widely differing periods of industry tenure. Some protocols never achieve widespread acceptance and usage, or else have very short lifetimes before becoming obsolete or being eclipsed by competing protocols. Other protocols become highly successful, and persist as long-term industry standards.

4.2.1 Phases of Development

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:

1. Initial development.
2. Global parameter assignment.
3. Publication.
4. Patent-free declarations.
5. Industry usage.
6. Maintenance and enhancement.
7. Endorsement by 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 - 7 multiple times, as it undergoes maturation via repeated revision and re-publication. As described later, the Free Protocols Foundation plays a role in only two of these phases. For completeness, however, in the following sections we provide a brief description of each phase, along with commentary on the FPF’s philosophy regarding the protocol development process.

Initial Protocol Development

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.

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.

At the Free Protocols Foundation, we do not regard any one source of protocols as necessarily superior to any other. We believe that any coordination of activities can generate useful protocols, and we are ready to provide the same support for patent-freedom regardless of the initial source of the protocol.

Global Parameter Assignment

If necessary, global parameters must be assigned to the protocol, e.g. by the IANA. The Free Protocols Foundation plays no role in this process.

Protocol Publication

If the protocol is intended to be an open protocol, as opposed to an exclusively 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.

Ideally, the protocol should be published in a way which allows permanent and unrestricted access to the protocol by anyone wishing to implement it. In the case of Internet protocols, this is usually accomplished by RFC publication.

Patent-Free Declarations

Depending on their intentions, the developers of a protocol may take steps to work towards a patent-free result, and they may wish to make certain declarations to that effect.

In general, there may be both an Author and a Working Group involved in the development of a protocol. The Author is the person, company, 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.

Both the Author and the Working Group may wish to make 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. As described later in this document, it is not possible to make an absolute guarantee that a protocol is, and will remain, completely patent-free. The best an Author can do is make a good-faith declaration that:

• To the best of his knowledge the protocol is not subject to any patent restrictions.
• It is the Author’s intention to maintain the protocol patent-free.
• If any patent restrictions relating to the protocol become known to the Author, he will make prompt disclosure of this.

Similarly, the Working Group may wish to make a declaration that:

• The protocol has been developed in such a way as to ensure that no patented components have been intentionally introduced into the protocol.
• If any patent restrictions relating to the protocol become known to the Working Group, it will make prompt disclosure of this.

One of the roles of the Free Protocols Foundation is to provide a public forum in which such declarations can be made. Any such declaration which is submitted to the FPF will be published on our website at
http://www.FreeProtocols.org. Examples of previously submitted declarations may be seen at that location.

Industry Usage

The ultimate test of a protocol is whether or not it becomes widely accepted and implemented in the industry. If a protocol is largely unused, or eclipsed by a competing protocol, then it is largely irrelevant.

Maintenance and Enhancement

Protocols are usually not static, but instead typically undergo revision and enhancement in response to experience and/or changing industry requirements. Depending on the intentions of the Authors, this may take place by closed and proprietary processes, or by open and public ones. In the case of a truly open protocol, the development process should allow commentary and participation by all the constituencies that are affected by the protocol.

In some cases, continued development and enhancement of the protocol is accomplished by means of a public Working Group. Also depending on the Authors’ intentions, the Working Group may function in a way which preserves the patent-freedom of the protocol, and the Working Group may wish to make a declaration to this effect.

Two things are required in order to achieve these goals. First, the developers must establish and follow a set of Working Group operating procedures that will have the effect of preserving the patent-freedom of the protocol. Second, the developers must make a public declaration that the Working Group follows these procedures.

A developer can achieve both of these things without the assistance of the Free Protocols Foundation. The development organization can establish its own set of Working Group operating procedures, and can independently announce that the Working Group follows them.

However, the Free Protocols Foundation provides a means of accomplishing these things which is external to, and independent of, the development organization itself. It is for this purpose that the FPF primarily exists. First, the FPF defines a clear and unambiguous set of Working Group processes and procedures which ensure, as far as possible, that the resulting protocol will remain functionally patent-free. Any development organization is free to adopt these procedures with regard to its own protocol. Second, the FPF provides an external forum in which the developer may declare publicly that its Working Group follows these procedures.

The FPF Working Group procedures are designed to:

• Ensure that no patented components can be intentionally introduced into the protocol as a result of the Working Group activities.
• Provide remedies in the case of unintentional introduction of patented components into the protocol. These remedies consist of prompt publication of the fact of the patented component, and an attempt to secure non-restrictive usage rights from the patent holder.

Endorsement by a Standards Body

The ultimate arbiter of protocols is the industry itself, in which a multitude of individual decisions leads to the acceptance or rejection of any particular protocol. The acceptance of a protocol as a standard is therefore something that occurs independently of formal endorsement by a standards body.

Nevertheless, once a protocol has become accepted as an industry standard, it is often the case that it receives the formal sanction of a standards body.

4.2.2 Role of the Free Protocols Foundation

It is sometimes the case that many of the above phases of development take place under the direction of a single institution, or a group of tightly coupled institutions. For example, when developing protocols the IETF/IESG/IAB traditionally claims authority for all aspects of development except for (5), over which, of course, it has no direct control.

At the Free Protocols Foundation, we consider it undesirable to place control of multiple aspects of the development process in the hands of any single institution. First, this can include built-in conflicts of interest. For example, if a standards body is responsible both for developing protocols and publishing industry protocols, the body may be inclined to favor publication of its own protocols in preference to competing protocols from other sources, or it may be inclined to place inappropriate commentary within competing protocols. The IETF/IESG has a history of doing both of these things.

As another example, if the Maintenance and Enhancement responsibility is closely-held by a developing company or group of companies, this process may be biased in favor of the companys’ interests, rather than those of the industry at large.

Furthermore, a large spread of responsibility within a single institution can lead to bureaucratization of its activities; the energy of the organization can become directed towards maintaining its internal bureaucracy, rather than serving the needs of its consumers. In other words, the institution can become authority oriented, as opposed to responsibility oriented. The historical evolution of the IETF/IESG/IAB is a classic example of this.

For these reasons, the Free Protocols Foundation is in favor of decoupling, as much as possible, the responsibility for the various aspects of development. A separation of powers greatly lessens the potential for conflicts of interest. Furthermore, an organization with limited responsibility can be discarded, reformed, or replaced more easily than one with very broad responsibility. Separation of powers thus provides a greater degree of choice, and therefore competition, within the protocol development process.

The Free Protocols Foundation is therefore in favor of placing responsibility for the various phases and aspects of development in the hands of independent organizations with limited agendas. We favor delegating the Protocol Publication phase to a truly independent third-party entity, such as the Internet RFC Editor. We favor handling the Maintenance and Enhancement phase by means of a variety of truly open public working groups, not just the IETF. Both of these steps ensure unbiased processing of the protocol.

In the same spirit, we favor placing responsibility for working towards patent-freedom in the hands of an independent organization. It is primarily for this reason that the Free Protocols Foundation exists. The role of the Free Protocols Foundation is to place those aspects of the protocol development process which relate to patent-freedom in a common, central, public location. The various other aspects of the development process have been described only to place the role of the FPF in its proper context; the FPF plays no role in those aspects.

In our model of the protocol development process, the scope of FPF activities is limited to two items exclusively:

• (4) Patent-free declarations, and
• (6) Maintenance and enhancement,

and the Free Protocols Foundation has no agenda other than this.

Note that the role played by the FPF regarding protocol patents is somewhat analogous to the role played by the RFC Editor regarding protocol publication. RFC publication provides a means of publishing, via an independent agency, Internet protocols which have been produced by a variety of sources.

Similarly, the FPF represents a means of dealing with patent issues by an independent agency. Hitherto, this responsibility has been taken by multiple standards bodies, each of which has been obliged to define its own processes and procedures relating to patents. By adopting the FPF procedures, a standards body or development organization can make use of a set of general services established by an external agency.

4.2.3 Coordination of Activities

As noted in the previous section, the FPF is in favor of distributing responsibility for the various aspects of protocol development, rather than consolidating all these aspects under the umbrella of a single organization, such as the IETF.

The objection may be made, that this distribution of responsibility creates coordination difficulties. It can be argued that vertically-integrated organizations like the IETF play a valuable role in terms of coordination of activities, and that it is more difficult to coordinate the activities of multiple independent organizations. In particular, it can be said that the IETF assists in the logical and orderly development of multiple protocols, by establishing a common architecture and structure for sets of related protocols.

However, we believe that this objection is unfounded. It has been well demonstrated, for example by the development of Linux, that multiple independent entities can coordinate their development efforts extremely effectively. In any event, the advantages to be gained from a separation of powers certainly exceed the drawbacks.

4.3 The Free Protocols Foundation

4.3.1 General Philosophy

At the Free Protocols Foundation, we consider that patented protocols are very undesirable. A protocol is a general agreement within an industry that things will be done in a certain way. It represents an agreed-upon expected behavior, providing common ground for cooperation among a variety of disparate entities: private businesses, academic institutions, government, and individuals. The protocol allows any of these entities to create products, services, applications, etc., and provides the necessary assurances that these offerings will function and interoperate in a well-defined way. 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, and without restrictions. The presence of patented components within the protocol places restrictions on its usage, and therefore serves only to undermine 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.

We have no objection to companies seeking market advantage by means which benefit the consumer and the industry. Such means include the creation of superior products and services, or the exercising of legitimate patents on physical processes. But we strenuously object to the seeking of market advantage by attempting to lay claim to the protocol itself.

The presence of a patent within a protocol is at best absurd, pointless, and self-defeating. And at worst, it represents an attempt by corrupt business interests to gain market advantage at the expense of the industry and the consumer.

4.3.2 Purpose, Activities and Scope

The Free Protocols Foundation is a nonprofit corporation, incorporated in the State of Washington.

The principal purpose of the Free Protocols Foundation is to act as an independent public forum for the support of patent-free protocols. We do this by means of the following major activities:

• By providing an independent, external forum in which an Author may make an initial declaration that a protocol is intended to be patent-free.
• By defining a set of patent-related Working Group procedures which, if followed, ensure that the resulting protocol will remain functionally patent-free. Any development organization is free to adopt these procedures with regard to its own protocols.
• By providing an independent, external forum in which a Working Group may make a public declaration that it follows these procedures.
• Whenever patent rights are asserted with respect to any protocol which has been declared patent-free to the FPF, by publishing a statement of the patent right assertion.
• Whenever patent rights are known to exist with respect to a protocol which has been declared patent-free to the FPF, by assisting in obtaining from the patent-holder a non-restrictive license to implement the patented process as part of the protocol.

The scope of activities of the Free Protocols Foundation is limited to those activities which provide support for free protocols, and which oppose the mis-use of patented protocols.

In particular, the Free Protocols Foundation does not develop protocols itself, nor does it participate in the development of the protocols of other organizations. The FPF does not evaluate or provide any commentary on the technical merits of protocols.

Also, the FPF does not make any independent verification of whether or not a developer actually adheres to the processes and procedures of Section 4.6. The FPF does no more than record the fact that the development organization has made the declaration that it conforms to those procedures.

4.3.3 Other Activities

In addition to its activities undertaken to support the development of patent-free protocols, the FPF may also take actions to oppose the creation and promotion of patented protocols. These actions may consist of any of the following:

• Acting as a clearing house for information and articles relating to protocol patent-freedom.
• Supporting the creation and development of patent-free alternative protocols to existing patented protocols.
• Alerting legislators of the harmful effects of software and protocol patents, and lobbying for changes in the way software patents are granted.
• Alerting the United States Patent and Trademark Office (PTO) of the harmful effects of software and protocol patents, and lobbying for changes in the way sofware patents are granted.
• Supporting fights against invalid software patents in the courts.
• Boycotting companies which misuse software and protocol patents.

We encourage others to join us in resisting the granting and abuse of software and protocol patents.

4.4 Free Protocol Development Working Groups

It is often the case that protocols are developed, or maintained and enhanced, by means of public Working Groups. A Working Group may enter into participation at various stages in the protocol’s development.

In many cases, the creation and initial development of a protocol is done by a single Author or a small team of core developers. Once an initial basis for the protocol is in place, a larger public Working Group is then formed, which takes over responsibility for maintenance and enhancement of the protocol. In this case, the Working Group begins participating at stage (6), Maintenance and enhancement.

In other cases, a Working Group may be formed in order to do the initial creation and development work itself. In this case, the Working Group begins participating at the very beginning, at stage (1), Initial development.

Working Groups typically communicate amongst themselves by means of working group mailing lists, together with occasional physical meetings as necessary. Under these circumstances, it is possible for a large number of contributors to participate in the development of a protocol.

The processes and procedures of Section 4.6 include provisions whereby patent-freedom can be maintained for a protocol despite its being developed by a public Working Group. These provisions consist of a set of procedures that, if followed by the Working Group, will keep the protocol functionally patent-free. A key provision is that anyone who participates in the Working Group is required to adhere to these procedures. That is, the Working Group must impose adherence to its procedures on all Working Group contributors.

Note that the FPF does not manage Working Group mailing lists itself, nor does it maintain a list of Working Groups which have adopted the FPF’s processes and procedures. Though the FPF does provide a mechanism whereby Working Groups may make a declaration that they conform to the FPF Working Group procedures, it does not provide a mechanism whereby individual contributors may make such a declaration.

The role of the FPF regarding Working Groups is limited to that of establishing a minimal set of policies and procedures that contributors may choose to adopt in order to maintain a patent-free protocol. This minimal set of policies relates only to patents, copyright and confidentiality. All other procedures are at the discretion of each individual Working Wroup.

4.5 Patent-Free Declarations

4.5.1 Author’s Declaration

Any Author may make an initial patent-free declaration to the Free Protocols Foundation relating to a protocol. This declaration should include 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 a patent right restriction relating to the protocol, or a patent right assertion is made with respect to the protocol, the Author will make prompt disclosure of this fact to the Free Protocols Foundation.

Any such statement provided to the FPF will be published on the FPF website. Examples of statements previously provided to the FPF can be found in the Author’s Declarations section of the FPF website.

4.5.2 Working Group Declaration

If a Working Group participates in the development and/or maintenance and enhancement of a protocol, it may make a declaration that its protocol maintenance and enhancement procedures conform to the FPF Processes and Procedures regarding patent-freedom. A Working Group may do this by providing the Free Protocols Foundation with a statement that its protocol development process conforms to the processes and procedures set forth in Section 4.6.

Any such statement provided to the FPF will be published on the FPF website, and the corresponding protocol will be added to the list of those declared to conform to the FPF’s patent-free policies and procedures.

Examples of statements previously provided to the FPF can be found in the Free Protocols Working Group Declarations section of the FPF website. The list of declared-conforming protocols is available in the List of Free Protocols Specifications and Their Declarations section of the FPF website.

4.6 Patents, Copyright and Confidentiality - Policy Statement

In this section we define a set of policies and procedures which ensure that a protocol will remain functionally patent-free. Any Working Group is free to make use of these procedures as part of their development process. A key component of these procedures is that every member of the Working Group is required to abide by the procedures.

4.6.1 Policy Statement Principles

Because of the difficulties relating to software patents described in Section 4.1.3, it is not possible to be absolutely certain that a protocol is truly patent-free. The scope of these policies and procedures is therefore limited to ensuring that a protocol is patent-free as far as is practically possible. The purpose of the procedures is to codify the following principles:

• Author’s Patent-Free Intent Declaration. When a developer makes a patent-free declaration to the FPF, a key part of the declaration is that of intent. That is, the declarer is making the statement that to the best of the declarer’s knowledge the protocol is patent-free, and that it is the declarer’s intention to keep it so.
• On-Going Patent-Free Contributions. By becoming a member of a Working Group, every contributor to the on-going maintenance and enhancement of the protocol is required to adhere to principles and procedures which preserve patent-freedom of the protocol.
• Working Group’s Declaration When a Working Group makes a declaration to the FPF, the effect of this declaration is that the Working Group’s activities conform to a set of processes that ensure, as far as possible, that the resulting protocol specification is functionally patent-free.
• Patent Assertion Disclosure If a patent assertion is made subsequent to the declaration, the declarer undertakes to make prompt announcement of this to the Free Protocols Foundation. The Free Protocols Foundation maintains a record of all patent right assertions that have been made against any of its listed protocols. This record is available in the Notices of Claimed Rights section of the FPF website.
• Obtaining Non-Restrictive Usage Rights. In the event that the developer becomes aware of a patent restriction relating to the protocol, the developer will attempt to obtain non-restrictive usage rights for the protocol.

4.6.2 General Policy

In all matters of patent and confidentiality rights and procedures, the intention of the FPF is to benefit the Internet community and the public at large, while respecting the legal rights of others.

4.6.3 Confidentiality Obligations

No Free Protocol Developer shall make any contribution to the Free Protocol Working Group that is confidential. No contribution that is subject to any requirement of confidentiality or any restriction on its dissemination shall be included in any part of a Free Protocol Specification.

4.6.4 Rights and Permissions of All Contributions

By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions on his own behalf, on behalf of the organization (if any) he represents and on behalf of the owners of any proprietary rights in the contribution. Where a submission identifies contributors in addition to the contributor(s) who provide the actual submission, the actual submitter(s) represent that each other named contributor was made aware of and agreed to accept the same terms and conditions on his own behalf, on behalf of any organization he may represent and any known owner of any proprietary rights in the contribution.

1. Some works (e.g. works of the U.S. Government) are not subject to copyright. However, to the extent that the submission is or may be subject to copyright, the contributor, the organization he represents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited, perpetual, non-exclusive, royalty-free, world-wide right and license to the Free Protocols Foundation and the Free Protocol Working Group under any copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution.
2. The contributor acknowledges that the Free Protocol Working Group and the Free Protocols Foundation have no duty to publish or otherwise use or disseminate any contribution.
3. The contributor grants permission to reference the name(s) and address(es) of the contributor(s) and of the organization(s) he represents (if any).
4. The contributor represents that the contribution properly acknowledges major contributors.
5. The contributor, the organization (if any) he represents, and the owners of any proprietary rights in the contribution agree that no information in the contribution is confidential and that the Free Protocol Working Group and the FPF may freely disclose any information in the contribution.
6. The contributor represents that he has disclosed the existence of any proprietary or patent rights in the contribution that are reasonably and personally known to the contributor. The contributor does not represent that he personally knows of all potentially pertinent proprietary and patent, confidentiality and copyright rights owned or claimed by the organization he represents (if any) or third parties.
7. The contributor represents that there are no limits to the contributor’s ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor.

4.6.5 FPF Role Regarding Free Protocol Specifications

1. Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any Free Protocol Specification, and brought to the attention of the FPF, the FPF shall prepare a note, to be included in the next revision of the Free Protocol Specification, indicating the existence of such rights, or claimed rights.
2. The FPF encourages all interested parties to bring to its attention, at the earliest possible time, the existence of any patent rights pertaining to Free Protocol Specifications.
3. Where the FPF knows of rights, or claimed rights under (1), the FPF shall assist the Free Protocol Working Group in attempting to obtain from the claimant of such rights, a written assurance with respect to the relevant protocol specification(s), that any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms.

Chapter 5
ESRO: A Foundation for the Development of Efficient Protocols

5.1 Overview of ESRO

All efficient applications have the requirement for an efficient transport mechanism. For this reason, part of the initial focus of the LEAP protocol development effort has been on creating a general efficient transport mechanism. The resulting protocol is referred to as Efficient Short Remote Operations, or ESRO. ESRO is the efficient transport layer protocol for several LEAP applications. ESRO is a reliable connectionless transport mechanism, forming the foundation for the development of efficient protocols when TCP is too much and UDP is too little.

The need for efficient protocols extends across all aspects of wireless data communications, including e-mail, web browsing, and other applications. The LEAP architecture accommodates many of these applications based on the use of ESRO.

ESRO was published as RFC-2188 [91] in September of 1997. The ESRO protocol is publicly maintained and enhanced by ESRO.org at http://www.esro.org/. Patent free declarations have been made with respect to ESRO through the Free Protocols Foundation.

5.1.1 The Need for ESRO

Considering that:

• Many vertical applications in the wireless environment need a reliable, efficient and lightweight data transfer mechanism.
• Existing Internet transport protocols (TCP/UDP) do not address these requirements adequately.
• Today, most vertical applications either implement their own ad hoc reliability service on top of UDP, or else use non-standard middleware.
• A reliable connectionless transport protocol based on open specifications is needed.
• Remote Operations is superior to reliable connectionless transport as an application development paradigm.

ESRO has been designed to address these specific needs.

The need to address the requirements that the ESRO protocol addresses has been well recognized for quite a long time. As early as 1995 such requirements were being discussed within the Internet research community. In particular, RFC-955 [19], entitled “Towards a Transport Service for Transaction Processing Applications,” demonstrates recognition of the need for ESRO. A more recent document, RFC-2757 [67], entitled “Long Thin Networks,” again recognizes the demand for such a protocol.

In the past, this unaddressed demand has given rise to a variety of product oriented proprietary solutions (as opposed to open protocols) which are often referred to as “Middleware Products.” This has been particularly widespread in the wireless industry. Often these solutions are vendor specific and do not scale.

5.1.2 ESRO Requirements and Goals

The requirements and goals driving the ESRO protocol and system design include the following:

1. Provide reliability in an efficient manner for a wide range of vertical applications (e.g. wireless).
2. Specify an Internet open protocol.
3. Minimize the number of transmissions.
4. Minimize the number of bytes transmitted.
5. Be fast; minimize latency.
6. Be power efficient, and show respect for the resource limitations of mobile platforms, including memory, CPU, and battery power limitations.
7. Be lightweight; accommodate miniaturized devices.

5.1.3 Terminology

A description of ESRO includes references to a number of basic data communications concepts and ideas. Because of the informal, ad hoc, and often inconsistent terminology used within the Internet technical community, many of these concepts are referred to by a variety of different names throughout various documents and RFCs. Many of the RFCs mentioned below refer to ESRO-related concepts in an inconsistent manner.

In contrast to this, the ESRO specification uses the well defined and precise terminology of the “Open Systems Interconnection Reference Model” [76]. In this paper we will also adhere to the same precise terminology.

An example of the use of imprecise terminology is the term “Transaction Processing.” Various other protocol specifications refer to the concept of “Remote Operations” as “Transaction Processing.” In our terminology, however, Transaction Processing goes above and beyond Remote Operations, and also includes the concepts of Commitment, Concurrency and Recovery, and chained (related) Remote Operations which may be built on top of ESRO.

5.2 Other Related Protocols

The overall model of ESRO is similar to and consistent with many existing protocols. The distinguishing characteristic of ESRO is its efficiency. Also, the scope of ESRO is very narrow and well defined. The options and selections that it provides for are few and clear.

A brief comparison of ESRO to other similar protocols is provided in the sections below.

5.2.1 RPC

Remote Procedure Call (RPC) is specified in RFC-1831 [89] and RFC-1833 [88].

The RPC specifications define a remote procedure model that is essentially the same as ESRO. However, the notation of RPC uses a syntax which is quite different from that of ESRO. RPC can rely on a connection-oriented or a connectionless transport mechanism. When using the connectionless mechanism, the retransmission and reliability issues are considered to be beyond the scope of the RPC specification. RPC is usually used in combination with External Data Representation, XDR (RFC-1832) [90].

When using RPC over UDP, no meaningful reliable transport mechanism is defined. For this reason use of RPC over UDP has been limited to LANs.

5.2.2 ROSE

Remote Operations Services Element (ROSE) is specified in [24] and [25]. ROSE is a complete and heavyweight traditional OSI application which assumes availability of all of the underlying OSI layers.

The ESRO protocols can accomplish short operations with much less overhead than ROSE.

5.2.3 WAP’s WTP

The Wireless Appliction Protocol (WAP) includes a layer which is similar to ESRO, called “Wireless Transaction Protocol” (WTP) [4].

The WTP specification was published after ESRO was published, and is similar in functionality to ESRO. In many ways WTP can be considered to be patterned after ESRO; however, WTP is in fact a step backwards.

The clear and simple Remote Operations model of ESRO is renamed as “Wireless Transactions” in an inappropriate context. The notation specification conventions are not used, and the state machines are not as robust.

More importantly, the WTP specifications are not stable, have not been published as Internet RFCs, and have not been declared to be patent free.

As early as 1995, those involved in the development of WTP were made aware of LSROS and ESRO. The only reason we know of for their re-specification of WTP, rather than re-use of ESRO, is the WAP Forum’s desire for control.

More details on the problems of the WAP Forum’s approach are provided in the article The WAP Trap [66].

5.2.4 T/TCP

Transaction/TCP is specified in [20] and [21]. T/TCP is a backwards-compatible extension of TCP which provides efficient transaction-oriented service in addition to virtual-circuit service.

Use of T/TCP often involves replacing existing TCP implementations. This non-evolutionary aspect of T/TCP is one of the reasons why T/TCP has not been widely adopted.

Various lessons can be learned from why T/TCP has not been widely adopted.

5.2.5 RDP

Reliable Data Protocol (RDP) is specified in [43] and [42].

RDP can be considered to be a specialized TCP, specified for particular circumstances in which some of TCP’s facilities are needed.

One of the reasons why RDP has not been heavily used is because the set of specialized circumstances that it addresses do not justify the cost of implementing it. RDP allows for many options and selections, which makes its use difficult.

Various lessons can be learned from why RDP has not been widely adopted.

5.2.6 VMTP

Versatile Message Transaction Protocol (VMTP) is specified in [26].

VMTP can be considered to be a specialized transport protocol, targeted for what it calls the transaction model of communications.

One of the reasons why VMTP has not been heavily used is because it tries to address too broad of a software engineering-centric model. VMTP allows for many options and selections, which makes its use difficult.

Various lessons can be learned from why VMTP has not been widely adopted.

5.2.7 TCP

Transmission Control Protocol (TCP) is specified in [78] and [21].

TCP is mature, well understood and stable. Congenstion control and flow control mechanisms for TCP have been developed over the years, and incorporated into TCP implementations.

The simplest and shortest TCP interaction involves 5 PDU exchanges. For applications wishing to accomplish short and occasional communications in less than 5 PDU exchanges, ESRO is more efficient that TCP.

5.2.8 UDP

UDP (User Datagram Protocol) is specified in [77].

UDP is a very simple and thin layer on top of IP, which does not provide reliability or sequence ordering. Applications requiring a reliable connectionless transport need to build on top of UDP. ESRO provide an efficient and reliable transport service on top of UDP.

5.2.9 UDP Plus Ad Hoc Re-Transmissions

Various protocols have added their own specific re-transmission policies on top of UDP to make it more reliable.

Examples of such efforts include the Domain Name System (DNS) [55] [56], Network Time Protocol (NTP) [54], and NNTP for Usenet News Reading.

These efforts have all resulted in incomplete and limited solutions. The problems with such approaches were understood as early as 1985 [19].

5.3 The ESRO Protocol

The ESRO specification describes the service model, the notation and the protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Operation and Remote Procedure Call services. The emphasis of the ESRO service definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g. CDPD) usage in mind.

The ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead. ESRO supports segmentation and reassembly, concatenation and separation, as well as multiplexing for service users (applications).

ESRO allows for trade-offs between efficiency and reliability by specifying both 2-way handshake and 3-way handshake based protocols.

The ESRO specifications also define a notation and the services provided by an application-service element to support interactive applications in a distributed systems environment. A Remote Operation is invoked by one entity; the other entity attempts to perform the Remote Operation and then reports the outcome of the attempt.

Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of ESRO. However, identification (tagging) of the encoding mechanism in use (e.g. XDR, BER, PER) is supported by ESRO.

A variety of applications can use the ESRO protocol. Some early applications which use ESRO include: efficient short message submission and delivery, credit card authorization, and white pages lookup.

5.3.1 Efficiency Characteristics of ESRO

The key requirement driving the design of ESRO is efficiency. Reliable transfer of a short message using TCP involves 5 transmissions at a minimum. Reliable transfer of a short message using ESRO involves only 3 or 2 transmissions.

For many applications in which optimization of efficency is desired, it is likely that elimination of the extra 2 transmissions which are inherent to TCP, justifies deviation from it and use of ESRO instead.

The efficiency premium realized by the use of ESRO rather than TCP can be very significant. For example, EMSD (a mail submission and delivery protocol that uses ESRO) can be upto 5 times more efficient than SMTP, while maintaining precisely the same level of reliability and security. The paper entitled “Efficiency Study of EMSD vs. SMTP/POP3/IMAP” [57] quantifies the efficiency of ESRO in comparison to traditional TCP based applications.

5.3.2 Why We Adopted the Remote Operations Model

ESRO is a reliable connectionless transport mechanism.

A reasonable question is: Why did we design ESRO’s service interface to be based on the Remote Operations model?

Many Internet protocols are ”text-based” on top of TCP. And the “here is some text” followed by “here is some more text” followed by “here is some text in response” has become the tradition of simple Internet protocols. Protocols designed on the basis of this ”text-based” approach have a good track record of acceptance throughout the Internet, primarily because they are simple to understand and simple to implement.

When efficiency matters, however, the traditional text exchange model can be better expressed by the client requesting a particular operation from the server, and the server responding with the results of that operation, thereby eliminating the traditional “text-based” chit-chat. With such an approach, the design of the protocol becomes a natural fit for the remote operations model.

For short interactions, a reliable connectionless transport mechanism and the Remote Operations model are simply the same thing. The formalism of Remote Operations is an asset that ESRO exploits.

ESRO provides a service which supports interaction of applications based on a remote operation model. A Remote Operation is invoked by one entity; the other entity attempts to perform the Remote Operation and then reports the outcome of the attempt. The ESRO protocol is designed to be able to support a large variety of applications.

5.3.3 RFC Publication of the ESRO Protocol

The ESRO protocol is completely open. It has been published as RFC-2188.

For information on how to obtain the ESRO protocol, visit the ”Base Protocol Specifications” section of
http://www.esro.org/.

5.3.4 Maintenance of the ESRO Protocol via ESRO.org

ESRO.org is a public organization which enables and facilitates the development, maintenance and enhancement of protocols and related technologies which address the efficiency requirements of generic Internet applications.

Anyone interested in participating in the development of the ESRO protocol can join ESRO.org by visiting the ”Joining the ESRO.org and Related Mailing Lists” section of http://www.esro.org/.

Patent-free declarations have been made with respect to ESRO and RFC-2188 through the Free Protocols Foundation.

5.4 Use of ESRO

The ESRO protocol is designed to be able to support many applications, such as mobile messaging, directory services, micro-browsers, dictionary lookup (white and yellow pages), data sensors monitoring, telemetry, dispatch, and credit card authorization applications.

In this section we discuss various considerations that protocol developers and application designers should make when designing applications which use ESRO.

We then build on this by providing various examples.

5.4.1 Common ESRO Application Design Considerations

When designing applications which use ESRO services, a number of common issues often need to be considered. These include:

• Presentation – Syntax and Encoding
• Operation Reliability
• Idempotency – Duplication Detection
• Failure Detection and Re-Tries
• Segmentation/Re-Assembly
• Congestion and Flow Control
• Security Considerations: Authentication, Confidentiality, Authorization

We discuss each of these in some detail below.

Presentation – Syntax and Encoding

Using the remote operations model, Argument, Result and Error parameters are communicated between the invoker and the performer.

The application designer must choose and specify the particular syntax and encoding to be used.

Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of ESRO. However, identification (tagging) of the encoding mechanism in use is supported by ESRO.

The choice of encoding mechanism by the developers often revolves around the efficiency requirements, the complexity of the application to be designed, the availability of tools (e.g. XML, XDR, ASN parser and compilers) and the familiarity of the developer with the tools.

ESRO can accomodate any syntax and encoding, including: plain text, XML, ASN.1 (BER, PER etc.) and XDR.

The ESRO specification introduces one notation in ASN.1 for representation of Operations. This in no way ties the use of ESRO to ASN.1. Any syntax and encoding can be used, and use of any notation for representation of Operations is not mandatory.

Operation Reliability

Different applications may need various levels of failure detection for various operations. Any one of the following three methods may be needed to accomplish the desired reliability and semantics of various aspects of applications:

• 2-Way Handshake
• 3-Way Handshake
• 3-Way Handshake with Verify

An example of the usage of all three of the above methods is provided by EMSD [5].

Idempotency – Duplication Detection

Some operations are idempotent in nature, that is, they can be performed more than once without causing harm. However, other operations are non-idempotent, and should therefore be performed only once. In the case of non-idempotent operations, the performer should be able to detect duplicate operations, and perform each non-idempotent operation only once.

Examples of non-idempotent operations are Submission and Delivery of messages, which should not be performed more than once. Examples of idempotent operations are enquiries of date and time, which can be performed more than once without harm.

ESRO Services do not detect duplicate invocation of operations. As a result, the application should detect duplication when the same operation instance is invoked more than once.

An example of how this can be accomplished in a coherent manner can be found in Section 4 of RFC-2524, entitled “Duplicate Operation Detection Support” [5].

Failure Detection and Re-Tries

Based on ESRO’s notification of Failures, the application must take necessary measures to re-try the operation.

Depending on the nature of the application, use of a general spooler which supports persistence may be reasonable.

Segmentation/Re-Assembly

ESRO provides Segmentation and Re-Assembly, as well as Concatenation and Separation, inside the protocol. However, an application may choose to provide segmentation and re-assembly above ESRO services.

The specific requirements of the application and the nature of the networks in use may justify such a design.

Congestion Control and Flow Control

The ESRO protocol includes flow control, and allows for various re-transmission timers policies to be implemented. Such policies may include exponential back-off and adaptive retransmission algorithms. These allow for the use of self-adjusting timers to determine and dynamically set timers to effectively adjust data traffic in the event the link is slower than usual due to congestion or other network or system conditions.

However, specification of retransmission timers policies was deliberately not included in the ESRO protocol. Often ESRO will be used on the edges of the Internet, where the characteristics of network behavior between the Invoker and the Performer are deterministic and stable. In such environments, a custom re-transmission timers policies is more effective than a generic one. For example, timer profiles specific to CDPD or GSM wide area networks which assume the servers are at the edges of the Internet can be tailored to optimize performance. In practice, early usages of ESRO are likely to be in such environments.

Congestion Control was also deliberately not included in the ESRO protocol, and is intended to sit on top of ESRO. This is for two reasons.

First, indications of congestion in the IP protocol suite violate layering principles, and use of such indications would have made the congestion control mechanism limited to IP. Use of ESRO over non-IP packet networks (such as GSM) is highly desirable in the short term.

Second, the indication and source congestion need not be limited to purely network resources, and indications of congestion may come from a variety of sources. In practice, ESRO based congestion control is primarily server driven. Design of ESRO applications should include Congestion Control mechanisms.

An example of how Congestion Control on top of ESRO may be designed can be found in SubmissionControl and DeliveryControl sections of RFC-2524, [5]. Such control facilities and design makes use of ESRO and EMSD well suited for the End-To-End Internet usage model.

Security

Different applications may need various levels of security facilities. It is the requirements and scope of the individual application that drives the nature of security facilities that are appropriate to use.

In many cases, the key required security facilities are Authentication, Confidentiality and Authorization. The trade-offs between complexity, efficiency and reliability are best made on a case-by-case basis.

In the specific case of Efficient Mail Submission & Delivery (EMSD) [5], the existing mainstream Internet security mechanism of Pretty Good Privacy (PGP) can be used to provide end-to-end security facilities.

As an underlying general facility, ESRO itself does not provide any generalized security facilities. At some point in time, it makes good sense to create a common security framework for LEAP which is consistent with the broader Internet security framework.

We will start incorporating common security features when they become widespread in the broader Internet. When Network Layer Security, Transport Layer Security, PKI, etc. are widespread, they will be incorporated as common facilities within LEAP.

5.5 Example Applications

A variety of applications can make use of the ESRO protocol. In this section we mention and provide references to a number of ESRO based applications. Based on the broadness of their usage and intended audience, we categorize them as either “Horizontal Applications” or “Vertical Applications.”

5.5.1 Horizontal Applications

Various efficient horizontal applications have been developed or are being developed using ESRO. These include:

• EMSD: Mobile and Wireless Messaging, Modern Two-Way Paging
• EHTD: Efficient Micro-Browsing
• E-DICT: Efficient Dictionary Lookup

A brief description of each is provided below.

5.5.2 EMSD: Efficient E-Mail

One of the efficient application layers built on top of ESRO is called Efficient Mail Submission & Delivery, or EMSD. EMSD is the component of LEAP that addresses the Mobile Messaging application.

EMSD is highly optimized for the submission and delivery of short (typically 4 kilobytes or less) Internet e-mail messages, and is therefore extremely well suited to the wireless environment. EMSD improves on existing messaging protocols by optimizing the exchange between the server and the end-user device, both in terms of the number of bytes transferred, and in terms of the number of transmissions. For more information on EMSD see the article EMSD: The LEAP E-Mail Component within The LEAP Manifesto, or visit the EMSD website at http://www.emsd.org/.

5.5.3 EHTD: Efficient Web Browsing

The Efficient Hyper Text Delivery (EHTD) layer is a hypertext transfer protocol which is optimized for the efficient transfer of short markup pages. EHTD is the component of LEAP which facilitates web browsing. Along with EMSD, EHTD also benefits from the reliable efficient services of ESRO. A multiplicity of efficient markup languages can be used in conjunction with EHTD. Development of the EHTD protocol is currently in progress.

5.5.4 Other Efficient Horizontal Applications

Various other efficient application protocols are either under development, or anticipated for future development. One of these is the Efficient Dictionary protocol, or E-DICT, which will enable efficient access to dictionaries and other lookup data structures. A starting point for the E-DICT protocol is currently being created. In developing E-DICT, we intend to build on the existing work already done in the context of the DICT protocol.

We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementations of ESRO-based instant messaging, chat, white pages, and others.

5.5.5 Vertical Applications

Various efficient vertical applications have been developed or are being developed using ESRO. These applications include:

• Wireless credit card verification
• Wireless automated teller machine (ATM)
• Dispatch applications
• Telemetry
• Wireless T.V. ratings
• Vehicle tracking (GPS applications etc.)

There are a set of common architectural characteristics to most of these vertical applications. These common characteristics are illustrated in Figure 5.1. In this figure, the box labeled “Thin Reliability Layer” represents the position of ESRO.

---

---

The combination of ESRO as the efficient transport mechanism, the systems modeling represented in Figure 5.1, and the methods described in Section 5.4.1 can greatly facilitate and expedite development of efficient vertical applications.

5.6 Existing Implementations of ESRO

A Reference Implementation of ESRO in the form of free software in open-source format is being made available at http://www.MailMeAnywhere.org/.

We expect to have the ESRO protocol engine software components subject to the GNU General Public License available at this location by September 2000.

On the device side, software will be made available for most generic platforms, including PalmOS, EPOC, WindowsCE, Windows9X, and Windows-NT. On the server side, software will be available on Solaris, Linux and NT.

In addition to open-source format, the ESRO Reference Implementation will also be made available for the above mentioned platforms as a ready-to-use Toolkit.

For a current list of ESRO free and commercial software products, visit the ”Products and Services” section of http://www.esro.org.

5.6.1 ESROS Application Programming Interface

The “ESRO API Specification” [58] defines the ESRO Application Programming Interface (API). This specification maps ESRO service primitives into C language function calls. This document is available at
http://www.esro.org/documents/API.html.

Chapter 6
EMSD: The LEAP E-Mail Component

6.1 Introduction

This article provides a description of the Efficient Mail Submission & Delivery protocol, or EMSD. EMSD is the e-mail component of the LEAP family of protocols.

The entire family of LEAP protocols has been designed with efficiency as a primary requirement, and each component protocol brings efficiency and functionality benefits to the users of miniaturized mobile devices. In particular, EMSD brings these efficiency benefits to the e-mail, or Mobile Messaging, application.

Mobile Messaging is just one of several applications for which there is a high efficiency premium in the mobile and wireless arena. Other applications which demand efficiency in the mobile environment are such things as web browsing, dictionary look-up, etc. From an industry-building perspective, however, e-mail is the most critically important of all wireless and mobile data communications applications. Mobile Messaging provides the user with a unique communications facility: the immediate delivery of important and time-critical information to the mobile recipient, wherever and whenever he/she happens to be. This is a capability which is not provided by phone, Fax, or any other tool in the modern user’s array of communications options.

In fact, this capability represents the principal value of wide-area wireless networks to the end user, and this is why e-mail remains the dominant application for wide-area wireless networks. Furthermore, miniature hand-held mobile devices are extremely well-suited to the e-mail application. The same is not true for other applications, such as web browsing.

For all these reasons, e-mail is the key industry-building application, and this is why EMSD represents the right starting point for the LEAP family of protocols.

6.1.1 Terminology

Throughout this article, we will make use of the following terms and definitions:

• MTS. Mail Transfer System.
• Mail Submission. Mail submission refers to the process of putting mail into the Mail Transfer System (MTS).
• Mail Delivery. Mail delivery refers to the process of the MTS putting mail into a user’s final mailbox.
• SMTP. Simple Mail Transfer Protocol.
• MUA. Mail User Agent.
• EMSD-P. EMSD Protocol.
• EMSD-FS. EMSD Format Standard.
• EMSD-UA. EMSD User Agent.
• EMSD-SA. EMSD Server Agent.

6.2 Existing Internet Mail Submission and Delivery

Mail transmission in the Internet did not arise as a result of well-planned engineering processes; rather, it grew and evolved in a more organic way.

At present, most mail submission and delivery throughout the Internet is done by means of the Simple Mail Transfer Protocol, or SMTP. SMTP was originally defined as a message transfer protocol – that is, a means to route (if necessary) and deliver mail by putting finished (i.e. complete) messages in a mailbox. Originally, users connected to servers from terminals, and all processing occurred on the server. Today, a split-MUA (Mail User Agent) model is common, in which MUA functionality occurs both on the user’s own system, and the server.

In the split-MUA model, the process of getting a message to the user is accomplished by access to a mailbox on the server, using protocols such as POP and IMAP. Also, in the split-MUA model, the user’s access to his/her message is based on a ”Message Pull” paradigm, in which the user is required to explicitly poll his/her mailbox to retrieve mail. Message delivery based on a ”Message Push” paradigm, in which mail is delivered directly to the user without polling, is presently not supported.

Despite its original definition as a message transfer protocol, in the split-MUA model, SMTP is often used for message submission. The widespread use of SMTP for submission has become a reality, regardless of whether this is a good or a bad thing.

6.3 Overview of EMSD

EMSD is a messaging protocol that is highly optimized for the submission and delivery of short Internet e-mail messages. The EMSD protocol addresses all the shortcomings in the existing Internet mail system described in the previous section. EMSD properly supports the Message Push mode of operation, and it provides an alternative mechanism to SMTP for message submission. And most important of all, it does this with a major emphasis on efficiency.

6.3.1 Protocol Layering

As shown in Figure 6.1, the LEAP protocols are layered. The lower layer, called Efficient Short Remote Operations (ESRO), provides efficient reliable connectionless transport services which can be used by a variety of applications. For example, in addition to Mobile Messaging services, ESRO can also be used as a transport service for credit card verification applications and efficient micro browsers.

EMSD is built on top of ESRO. The reliability requirements for message submission and message delivery in EMSD are the same as for existing e-mail protocols. The EMSD protocol provides reliable connectionless mail submission and delivery services.

---

---

6.3.2 EMSD Protocol Components

EMSD consists of two independent components: the EMSD Format Standard, and the EMSD Protocol. These two components provide the following functions:

1. EMSD Format Standard (EMSD-FS)

   EMSD-FS is a non-textual form of compact encoding of Internet e-mail (RFC-822) messages, which facilitates efficient message transfer. EMSD-FS is used in conjunction with the EMSD-P (described below), but is not in any way a general replacement for RFC-822. EMSD-FS defines a method of representation of short interpersonal messages. It defines the ”Content” encoding (Header + Body). Although EMSD-FS contains end-to-end information, its scope is purely point-to-point. EMSD-FS relies on EMSD-P for the transfer of the content to its recipients.

2. EMSD Protocol (EMSD-P)

   EMSD-P is responsible for wrapping a limited size EMSD-FS message in a point-to-point envelope, and submitting or delivering it. EMSD-P performs the envelope encoding. EMSD-P relies on the services of Efficient Short Remote Operations (ESRO) as specified in RFC-2188 [91] for transporting the point-to-point envelope. Some of the services provided by EMSD-P include: message originator authentication, and optional message segmentation and re-assembly. EMSD-P is expressed in terms of abstract services using the ESRO notation.

Together, the EMSD Protocol and Format Standard define the protocols used to transfer messages between an EMSD Server Agent (EMSD-SA), for example a Message Center, and an EMSD User Agent (EMSD-UA), for example a Two-Way Pager.

Figure 6.2 illustrates how EMSD defines the communication between a specific EMSD-UA and a specific EMSD-SA. The Message Transfer System may include a number of EMSD-SAs, and each EMSD-SA may have any number of EMSD-UAs with which it communicates.

---

---

It is important to note that EMSD-P and EMSD-FS are not end-to-end, but instead focus on the point-to-point transfer of messages. The two points being referred to are the EMSD-SA and EMSD-UA. EMSD-P functions as an element of the Internet mail environment, providing end-to-end services (i.e. EMSD-User to any other Messaging Originator or Recipient).

The EMSD services use the Efficient Short Remote Operations (ESRO) services. They also use the Duplicate Operation Detection Support Functions. These functions guarantee that an operation is performed no more than once.

6.3.3 Efficient Short Remote Operations (ESRO)

The EMSD protocol specifications define the protocols between the EMSD Device and the EMSD Server. EMSD is built on top of, and requires the services of, ESRO (Efficient Short Remote Operations). This EMSD requirement was the major motivation for the development of ESRO; however, ESRO has been developed to be independent of EMSD.

ESRO defines a notation and the services provided by an application-service element to support interactive applications in a distributed systems environment. The scope of ESRO services is not limited to EMSD. ESRO is designed to be able to support other applications, such as finger/limited directory service.

The ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead. ESRO supports segmentation and reassembly, concatenation and separation, as well as multiplexing for service users (i.e. applications).

The ESRO service is similar to and is consistent with other Remote Procedure Call services. The major emphasis of the ESRO service definition and the ESRO protocol is on efficiency. ESRO has been designed specifically with wireless network (e.g. CDPD) usage in mind.

The service model, the notation, and the protocol for ESRO are fully specified in RFC-2188 [91]. The EMSD Protocol uses ESRO to accomplish reliable connectionless mail submission and delivery.

For more information on ESRO, see the article entitled ESRO: A Foundation for the Development of Efficient Protocols within The LEAP Manifesto, or visit the ESRO website at http://www.esro.org/.

6.3.4 Anticipated Uses of EMSD

Any network or network operator which faces significant bandwidth and capacity limitations can benefit from the use of EMSD. Any user of a network who must bear high costs for measured network usage can benefit from the use of EMSD.

The initial use of EMSD is expected to be primarily to provide Mobile Messaging services over IP-based wireless networks. However, EMSD can also function as an adjunct to Mail Access Protocols for ”Mail Notification Services.”

Mail submission and delivery take place at the edges of the network. It is likely that multiple mail submission and delivery protocols will be developed, each addressing the specific requirements of a particular user’s environment. Such diversity on the edges of the network is beneficial, and with the right protocols, this diversity does not adversely affect the integrity of the mail transfer system. EMSD is the basis for the mail submission and delivery protocol to be used when the user’s environment demands efficiency.

6.4 EMSD Design Goals and Requirements

The EMSD protocols have been designed to accomplish three high-level goals:

1. Define the new ”world” of Efficient Mail Submission & Delivery
2. Define a remote operations service that can handle messaging and other standard networking applications
3. Make EMSD an extension of the existing Internetworking world

Based on these goals, EMSD has been designed to satisfy the following design requirements:

1. Support the submission of short mail messages with the same (or better) level of functionality as the existing Internet mail protocols.
2. Support the delivery of short mail messages with the same (or better) level of functionality as the existing Internet mail protocols.
3. Function as an extension of the existing mainstream Internet mail.
4. Minimize the number of transmissions.
5. Minimize the number of bytes transmitted.
6. Be quick: minimize the latency of message submission and delivery.
7. Provide the same level of reliability (or better) as the existing e-mail protocols.
8. Accommodate varying sizes of messages: the size of a message may determine how the system deals with the message, but the system must accommodate it.
9. Be power efficient and show respect for mobile platform resources, including memory and CPU levels, as well as battery power longevity. In other words, be client-light and server-heavy.
10. Be highly extensible. Different users will demand different options, so the solution cannot require every feature to be a part of every message. Likewise, usage will emerge that is not currently recognized as a requirement. The solution must be extensible enough to handle new, emerging requirements.
11. Be secure. Provide the same level of security (or better) as the existing e-mail protocols. Content confidentiality, originator/recipient authentication, and message integrity must be available options to users.
12. Be easy to implement: re-use existing technology as much as possible.

The EMSD protocols make extensive use of existing technology, including:

• RFC-822
• ASN.1
• Basic Encoding Rules
• Internet mail

By using these established technologies, the design of EMSD avoids the expense and other problems associated with ”re-inventing the wheel.” The above technologies have been thoroughly tested, and have proven to be reliable solutions for the problems they address (e.g. message format, reliable message delivery, encoding and compacting). The EMSD specifications cater to users who enjoy the advantages of this new technology, but at the same time want to be connected to the rest of the existing Internet e-mail world. Figure 6.3 shows how the Global and EMSD worlds complement one another.

The Internet e-mail community is shown in the lower half of the figure. This world is connected to the EMSD Internet e-mail system.

---

---

6.5 Rationale for Key Design Decisions

This section summarizes the rationale for the key design decisions that were made while developing the EMSD protocols.

6.5.1 Deviation from the SMTP Model

SMTP is the main mail transport mechanism used throughout the Internet. It is widely deployed and well understood by many engineers who specialize in Internet e-mail. For these reasons, protocols based on or derived from SMTP or more likely to become widely deployed throughout the Internet.

However, SMTP is highly inefficient for the transfer of short messages. SMTP is inefficient both in terms of the number of transmissions, and in terms of the number of bytes transmitted. Even when fully optimized with PIPELINING, SMTP remains significantly inefficient.

The submission of a short message using SMTP requires 15 transmissions. The submission of a short message with SMTP and PIPELINING requires 9 transmissions. The submission of a short message with EMSD (EMSD-P and ESRO) requires only 3 transmissions (in a typical case).

The key design requirement of EMSD is efficiency. Because of the 3 fold (at least) gain in efficiency, this justifies the deviation from the SMTP model.

Efficiency Comparison of SMTP and EMSD

Table 6.1 shows the number of N-PDUs exchanged for the transfer of a short Internet e-mail when using SMTP, SMTP with PIPELINING, QMTP, and EMSD. The names used for identifying the PDUs are informal names.

6.5.2 Use of ESRO Instead of TCP

In order to provide the same level of reliability that the existing e-mail protocols provide for short messages, it is clear that a reliable underlying service is needed. UDP [80], by itself, is clearly not adequate.

Use of TCP however, involves three phases:

1. Connection Establishment
2. Data Transfer
3. Disconnect

The reliable transfer of a short message using TCP involves a minimum of five transmissions, as is the case with QMTP.

Again, the key design requirement of EMSD is efficiency. Therefore deviation from TCP is justified, because this eliminates the two extra transmissions that are an inherent characteristic of TCP.

The ESRO protocol, as specified in RFC-2188 [91], provides reliable connectionless remote operation services on top of UDP [80] with minimum overhead. ESRO supports segmentation and reassembly, concatenation and separation.

The reliable transfer of a short message using ESRO involves 3 transmissions, as is the case with EMSD-P.

6.5.3 Use of the Remote Procedure Call (RPC) Model

Many Internet protocols are ”text-based.” On the other hand, few Internet protocols are RPC-based. Protocols designed on the basis of the ”text-based” approach have a better track record of acceptance throughout the Internet.

However, considering that message submission and delivery in EMSD involves no more than two data exchanges, the text-based model becomes the same as an operation. Furthermore, the RPC model is the natural way of using ESRO.

6.5.4 Use of ASN.1

In order to minimize the number of bytes transfered, efficient encoding mechanisms are needed.

Among today’s encoding mechanisms, ASN.1 has the unique feature of separating the abstract syntax from the encoding rules. By selecting ASN.1 as the notation used for expressing EMSD’s information objects, EMSD has the flexibility of using the most efficient encoding rules, such as Packed Encoding Rules (PER), when they are available.

Efficient encoding can always be better performed when the syntax of the information is known. In general, encoding and compression techniques which use the knowledge of the syntax of the information produce better results than those compression techniques that work on arbitrary text.

6.6 Relationship of EMSD to Other Mail Protocols

EMSD is designed to be a companion to existing Internet mail protocols. It is designed to fit within the many protocols already in use for messaging, as well as those already in use for networking.

Figure 6.4 shows how EMSD fits in with the other major messaging protocols. The RFCs referenced in the figure are current at the time of this writing, but could be updated or made obsolete at any time.

---

---

The various Internet mail protocols provide different sets of capabilities for mail processing. Table 6.2 summarizes the capabilities of SMTP, IMAP, POP and EMSD in the following areas of functionality:

• Mail Submission
• Mail Delivery
• Mail Routing (Relay)
• Mail Retrieval
• Mailbox Access
• Mailbox Synchronization

The number of X’s in each cell of the table denotes the extent to which a particular function is supported by a particular protocol.

Table 6.2 clearly demonstrates that combinations of these protocols can be used to complement one other in providing rich functionality to the user. For example, a user interested in highly mobile messaging functionality can use EMSD for the submission and delivery of time-critical and important messages, and use IMAP for comprehensive access to his/her mail-box.

6.7 Obtaining the EMSD Protocols

For complete instructions on how to obtain the EMSD protocols, visit the ”Base Protocol Specifications” section of http://www.emsd.org/.

Chapter 7
Efficiency of EMSD

Preface

This article was originally published in October 1996. It is being included in the Manifesto, essentially unchanged from its original form.

7.1 Introduction

We provide here an overview of both SMTP and EMSD, to compare and contrast their features and to lay the groundwork for analysis of the experimental results in Sections ?? and ??.

SMTP

According to RFC 821[79], the objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. The SMTP design is based on the following model of communication:

As the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP, which may be either the ultimate destination or an intermediate.

Following this, the sender-SMTP sends a MAIL command indicating the sender of the mail. If the receiver-SMTP can accept mail it responds with an OK reply. The sender-SMTP then sends a RCPT command identifying a recipient of the mail. If the receiver-SMTP can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The sender-SMTP and receiver-SMTP may negotiate several recipients. When the recipients have been negotiated, the sender-SMTP sends the mail data, terminating with a special sequence. If the receiver-SMTP successfully processes the mail data it responds with an OK reply. Note that the dialog is purposely lock-step, one-at-a-time.

SMTP provides two mechanisms for the transmission of mail: directly from the sending user’s host to the receiving user’s host when the two host are connected to the same transport service, or via one or more relay SMTP-servers when the source and destination hosts are not connected to the same transport service. The mail commands and replies have a rigid syntax. Replies also have a numeric code.

Thus it can be seen that for the exchange of any one message with SMTP, a number of transactions must be completed. EMSD attempts to improve efficiency by cutting down on this number and simplifying the process for the case of short messages.

7.1.1 Efficient Mail Submission & Delivery

The EMSD specifications define the protocols between an EMSD Device and an EMSD Server. EMSD requires ESROS (Efficient Short - Remote Operation Services) [91]. The EMSD-P&FS consist of two independent components: Efficient Mail Submission & Delivery Protocol (EMSD-P) and EMSD Format Standards (EMSD-FS).

EMSD-FS is responsible for defining the format of a limited size interpersonal message. It defines the ”Content” encoding (Header + Body) and the end-to-end envelope. It relies on EMSD-P for the transfer of the content to its recipients.

EMSD-P is responsible for wrapping a limited size message in a point-to-point envelope and submitting or delivering it. EMSD-P performs the envelope encoding and relies on the services of ESROS for transporting the envelope. Some of the services of EMSD-P include message originator authentication and optional message segmentation and re-assembly. The Efficient Mail Submission & Delivery Protocols are designed with three high level goals:

• Define the new ”world” of Efficient Mail Submission & Delivery
• Define a remote operations service that can handle messaging and other standard networking applications
• Make Efficient Mail Submission & Delivery an extension of the existing internetworking world

These goals will prevent, whenever possible, the expense and associated problems of ”re-inventing the wheel.” The EMSD Protocols make heavy use of existing technology:

• RFC-822
• ASN.1
• Basic Encoding Rules
• X.400 and Internet e-mail

These technologies have been thoroughly tested and have proven to be reliable solutions for the problems they address (e.g. message format, reliable message delivery, encoding and compacting). The EMSD Specifications allow for users who enjoy the advantages of this new technology and at the same time want be connected to the rest of the existing messaging world.

7.2 Study Overview

We have chosen to compare the efficiency of using EMSD to the efficiency obtained by other submission and delivery protocols in this study. While it is debatable whether EMSD can be placed at the same level as the test protocols, we nonetheless feel that a study such as this is quite useful and provides a common denominator to discuss various aspects of EMSD performance.

The experiments cover both submission (from a mobile unit) and delivery (to a mobile unit). Under submission we looked at comparing EMSD and SMTP. The delivery experiments tested EMSD vs. SMTP, POP, and IMAP. In all cases a single uniform test message was relayed between two devices (a recipient or sender, and a mail server) and the data traffic recorded. Although you cannot compare EMSD directly to any one messaging protocol, because each protocol is designed to perform a specific function, you can compare the results obtained by each messaging solution. The following table illustrates the functions supported by each protocol. Note that EMSD is the most like SMTP.

7.3 Submission

Please refer to Figure 7.1 below, which shows the setup for the following two submission experiments in detail. The experimental setup involves:

At Site One:

• A ”sender”: Toshiba Laptop running Windows 3.1 and Chameleon Winsock TCP/IP stack from NetManage
• A ”receiver”: Sun Sparc running Solaris 2.4
• A ”mail server”: Sun Sparc running Solaris 2.4
• A sniffer that monitors packet movement at the juncture of the above three devices, recording two-way traffic

At Site Two:

• A Message Test Center: Sun Sparc running Solaris 2.4.

The two setups are linked to each other over a number of routers across the Internet.

In both cases below, we are interested exclusively in analyzing the recorded data between the sender laptop and the Unix mail server (in the case of SMTP submission), or the EMSD Message Test Center (in the case of EMSD submission). Thus the ”receiver” shown below, although necessary to submit the message, does not enter into our study picture directly.

---

---

7.3.1 SMTP Submission from PC to Unix

Message Submission Process

Message was submitted from the Laptop to the Unix mail server. To submit a message from the laptop, Netscape’s Mail User Agent on Windows 3.1 was utilized. From the file menu on Netscape, ”New Mail Message” was selected, popping up a mail window. The message was typed in, a recipient (the ”receiver” in Figure 7.1) was specified, and ”Send” was then clicked. The sniffer recorded the exchange of data between the sender and the mail server that was ¡nwestmail.nwest.airdata.com¿ implementing sendmail.

Protocol Trace

The following is the protocol trace recorded by the sniffer. After TCP synchronization and acknowledgment, a virtual circuit is established between the sender’s Netscape Mail User Agent and sendmail on the mail server, and data is exchanged after specifying the sender and recipient addresses.

Measurement Results

7.3.2 EMSD Submission from PC to Unix

Message Submission Process

The message was submitted from the laptop using Neda’s EMSD Mail User Agent version 0.9 on Windows 3.1, to Neda’s EMSD Message Test Center. EMSD-Pine version 3.91 was used to submit the message from the laptop. After invoking Pine, and typing ”C”, a new message was composed and then sent via ¡CTRL X¿. A direct connection was then established between the EMSD Mail User Agent on the laptop and the EMSD Message Test Center, and the message was relayed. The sniffer recorded exchange of data between the sender and Neda’s EMSD Message Test Center which was ¡emsd.neda.com¿ implementing ESROS.

Protocol Trace

The following is the protocol trace recorded by the sniffer. As compared to the SMTP protocol trace in section 7.3.1, you can see the exchange is quite brief.

Measurement Results

Total IP Packet bytes: 307

Message Length (header + body): 206

Total Overhead (EMSD header + UDP header + IP header): 101

Total IP bytes in the case of EMSD submission as compared to SMTP submission is down by a factor of 6; the header count is down by a factor of 2.6; and total overhead is down by a factor of 14, representing major savings in data traffic.

Message as Received

The # text below is provided as comments and does not appear in the received message.

7.4 Delivery

Similar to the submission experiments above, we also conducted analogous delivery tests. The first experiment on SMTP delivery is essentially the complement of the SMTP submission experiment described above, and uses the same setup as in Figure 7.1. The second and third delivery experiments are with POP and IMAP servers and are described in their corresponding sections below. The final experiment is on EMSD delivery and also uses the same setup as in Figure 7.1. We then compare the performance of EMSD delivery versus the other three delivery methods.

7.4.1 SMTP Delivery from Unix to Unix

Please refer to Figure 7.1 above for this experiment.

Message Delivery Process

The message was delivered to the Unix receiver from the Unix mail server. Both were implementing sendmail and the message was delivered via standard SMTP. The sniffer recorded the exchange of data between the recipient and the mail server, which was ¡nwestmail.nwest.airdata.com¿.

Protocol Trace

The following is the protocol trace recorded by the sniffer. After TCP synchronization and acknowledgment, a virtual circuit is established between the recipient’s Mail User Agent and sendmail on the mail server, and data is exchanged after specifying the sender and recipient addresses.

Measurement Results

Total IP Packet bytes: 1778

Message Length (header + body): 301

Total Overhead (TCP header + IP header): 1477

Message as Received

7.4.2 Message Delivery via POP Mailbox

Please refer to Figure 7.2 below, which shows the setup for the following two delivery experiments in detail. The experimental setup at Neda Communications involves the following:

• A POP Server: Sun Sparc running Solaris 2.4.
• An IMAP Server: Sun Sparc running Solaris 2.4.
• A ”receiver”: IBM Thinkpad Laptop running Microsoft TCP/IP on Windows 95
• A sniffer that monitors packet movement at the juncture of the above three devices, recording two-way traffic

---

---

Message Delivery Process

The message was delivered to the laptop from the POP server. After invoking Microsoft’s Internet Explorer 3.0 on the laptop and bringing up MS Internet Mail, the new message was automatically retrieved from the POP server. The sniffer recorded traffic data between the POP server and the recipient.

Protocol Trace

Measurement Results

Total IP Packet bytes: 2731

Message Length (header+body): 561

Total Overhead: 2170

Message as Received

7.4.3 Message Delivery via IMAP Mailbox

Please refer to Figure 7.2 above for the experimental setup.

Message Delivery Process

Message was delivered to the laptop from the IMAP server. After invoking PC-Pine, the new message was automatically retrieved from the IMAP server. The sniffer recorded traffic data between the IMAP server and the recipient.

Protocol Trace

Measurement Results

Total IP Packet bytes: 3593

Message Length (header+body): 833

Total Overhead: 2760

Message as Received

7.4.4 EMSD Delivery from Unix to PC

Please refer to Figure 7.2 above for this experiment.

Message Delivery Process

The message was delivered to the laptop, running Neda’s EMSD Mail User Agent version 0.9 on Windows 3.1, from Neda’s EMSD Message Test Center. The sniffer recorded exchange of data between the recipient and Neda’s EMSD Message Test Center which was ¡emsd.neda.com¿ implementing ESROS.

Protocol Trace

Measurement Results

Total IP Packet bytes: 387

Message Length (header+body): 299

Total Overhead: 88

Comparing EMSD delivery with SMTP delivery we see that total IP packets in the case of EMSD delivery is down by a factor of 4.6, and total overhead is down by a factor of 16.8.

In the case of POP retrieval, total IP bytes in the case of EMSD delivery is down by a factor of 7, and total overhead is down by a factor of 24.7.

Finally for IMAP delivery, total IP packets in the case of EMSD delivery is down by a factor of 9.3, and total overhead is down by a factor of 31.4.

Message as Received and Decoded

7.5 Results Summary

The following paragraphs summarize the results obtained above. Results indicate that EMSD compares very favorably to other message transfer mechanisms.

---

---

7.6 Conclusion

Results of the experiments show the dramatic efficiency gain of EMSD over all the other protocols under test.

However, it should be noted that EMSD was specifically designed for efficient short messaging in the context of mobile wireless devices, and thus from inception was meant to be more efficient than protocols designed to handle a wider variety of messages. Deployment and use of EMSD similarly is geared towards messaging scenarios that are a subset of the current global messaging world, such as palmtop devices exchanging messages over an airlink. At the other extreme, in a traditional office environment, concerns like efficient use of communications infrastructure and maximizing the battery life of the devices do not necessarily apply to tethered devices plugged to a standard wall outlet and a high speed (non-air) networking infrastructure.

Within its own domain, EMSD does its job efficiently and admirably and as is clear from the results of this study, is a highly competitive alternative to other messaging protocols.

7.7 Acknowledgments

This study was performed with the support and assistance of AT&T Wireless Services.

Chapter 8
A Brief History of LEAP

8.1 Overview

The origins of the LEAP protocols go back to 1994, when they originated as part of the research and development initiatives of McCaw Cellular’s wireless data group (now AT&T Wireless Services). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS network also.

By 1996 McCaw Cellular was fully committed to paging, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless messaging system. Neda Communications, Inc., an independent consulting company working under contract to McCaw Cellular, played a key role in the development of the required system. Neda Communications had also been involved from the outset in the development of the CDPD specification.

In 1997 however, soon after the purchase of McCaw Cellular by AT&T Wireless, the latter company abandoned the wireless messaging project entirely. Prior to this event, Neda Communications had secured from AT&T the necessary rights to continue independent development of the protocols. Therefore, recognizing the eventual future need for these protocols, Neda then undertook to continue development of them independently of AT&T. They were eventually completed by Neda, published as RFCs, and now form the basis of the LEAP protocols.

8.2 Time-Line History

A time-line history of the significant events relating to LEAP is provided below. Note that the name LEAP is relatively new; this acronym was coined in early 2000. Prior to 1997, the research and development work which would eventually lead to the creation of LEAP was referred to by the general name of Limited Size Messaging (LSM).

Much of the LSM work was sponsored in various ways by McCaw Cellular, then later by AT&T Wireless Services (AWS). Two divisions of AWS are referred to in the time-line below. First, the Wireless Data Division (WDD) of AWS led much of the LSM-related development work. WDD was the division of AWS which had major responsibility for the CDPD (Cellular Digital Packet Data) network.

Later, the Messaging Division of AWS also made use of the LSM technology in the context of their Narrowband PCS (NPCS) network. In the context of Narrowband PCS, LSM was referred to by the general name of pACT (personal Air Communications Technology).

Summer 1994:

The basic concept of providing wireless e-mail services over the CDPD network was first analyzed.

January 1995:

AWS began creating the LSM protocol specifications. This work was carried out as a joint effort between the Wireless Data Division, and the NPCS Group within the Messaging Division.

January 1995:

AWS began development of the reference implementation of the LSM protocols for both Message Centers and Devices.

June 1995:

WDD submitted the LSM specifications to the CDPD Forum. The WDD made various LSM-related direction statements, and produced several press releases. This resulted in significant press coverage of LSM. Early development of the WAP protocols had the benefit of seeing this public release of LSM technology, and was based in part upon it.

December 1995:

Neda’s reference implementation of LSM was completed and ready for demonstration and testing.

December 1995:

AWS sent out Requests For Proposal to potential large-scale Message Center suppliers.

February 1996:

Neda’s LSM device implementation interoperated with Aldiscon’s Message Center.

March 1996:

Sema Group UK was selected as the production Message Center supplier by AWS.

April 1996:

The pACT Vendor Forum was formed. The initial forum members included Ericsson, PCSI, Aldiscon, AT&T, Casio, NEC, Novatel, Research in Motion, and Sema Group UK.

July 1996:

Neda completed interoperability tests against the PCSI pACT pager.

August 1996:

AWS issued the equivalent of a VAR agreement to Neda for development and distribution of the LSM software.

September 1996:

Neda supplied LSM technology (in the form of source code) to Sema Group UK, and assisted Sema in the development of Message Center products for AWS.

November 1996:

AWS changed the LSM strategy for pACT from two-way to “mostly one-way plus.”

December 1996:

Neda’s palmtop LSM became ready for general testing.

January 1997:

Sema Group UK delivered its first release of the LSM Message Center product.

January 1997:

The Messaging Division of AWS licensed Neda’s LSM product set.

February 1997:

Neda’s LSM implementation interoperated with Sema Group UK’s LSM implementation.

February 1997:

WDD terminated funding of LSM-related work, and focussed instead on early development of WAP.

March 1997:

On March 17, AWS terminated the two-way paging project entirely. The NPCS Group of the Messaging Division was abruptly shut down, all employees were reassigned, and all vendor work terminated. Later the same year, the two nationwide Narrowband PCS licenses belonging to AWS were sold.

April 1997:

Neda began development of EMSD and the Enhanced Two-Way Paging (ETWP) products.

September 1997:

Efficient Short Remote Operations (ESRO) protocol was published as Internet RFC 2188.

June 1998:

The Windows CE efficient e-mail implementation was publicly released by Neda.

August 1998:

ETWP Subscriber Services and web access were made available.

November 1998:

Open maintenance organization EMSD.org was established to support public enhancement of the EMSD protocol.

January 1999:

Open maintenance organization ESRO.org was established to support public enhancement of the ESRO protocol.

February 1999:

Efficient Mail Submission & Delivery (EMSD) protocol was published as Internet RFC 2524 by Neda.

March 2000:

Neda made patent-free declarations to the Free Protocols Foundation with respect to RFC 2188 and RFC 2524.

This brings us up to the present. Our plans for the future of LEAP are described in a separate article in this Manifesto, entitled The Future of LEAP.

8.3 Acronym Apology

We live in the age of the acronym. Our language is now littered with more acronyms than at any other time in history, with more being added every day. We are inundated, swamped, awash with acronyms. We even have an acronym (TLA) for referring to acronyms.

The right acronym can make all the difference between the success and the failure of a product or idea, and for this reason considerable effort sometimes goes into creating just the right acronym.

In some cases the result is an acronym which is in good harmony with what it represents: PAWS (Progressive Animal Welfare Society); MADD (Mothers Against Drunk Driving). In other cases the acronym has good force and immediacy, but is not especially relevant to what it represents: NOW (National Organization of Women). On the other hand, the striving for a catchy acronym can lead to a labored and contrived construction: DARE (Drug Abuse Resistance Education).

In some cases no thought at all is given to the aesthetics of the acronym, resulting in one which is both pointless and clumsy: AFTRA (American Federation of Television and Radio Artists); or even worse, one which carries an actively negative connotation: SAG (Screen Actors’ Guild).

As can be imagined, the search for the right acronym for our protocols has given rise to a protracted and sometimes emotional debate. Prior to 1997, while the protocols were undergoing development at AT&T Wireless Services, they were referred to as LSM, standing for Limited Size Messaging. When Neda began independent development of the protocols in 1997, the early, working name for the protocols was EAPS, standing for the Efficient Application Protocol Suite. This of course, is a purely engineering construction, describing the basic nature and purpose of the protocols perfectly. However, the word EAPS makes those of us with more aesthetic sensibilities physically ill.

The working name EAPS was eventually displaced by the name WHIP, standing for the Wireless High-Performance Internet Protocols. WHIP has a good strong personality, and is therefore more likely to remain in the mind of the hearer. An important component of our Manifesto strategy is capturing mindshare. In today’s deafeningly noisy Internet environment, any assistance is welcome.

The price to be paid for this, of course, is that WHIP is contrived and inaccurate. First, the use of the word ”Wireless” is inappropriate. There is nothing about the protocols which restricts them to wireless applications. Certainly, they have been designed with the needs of wireless applications in mind, but their major defining characteristic is their efficiency, which makes them appropriate for use in many applications, wireless and otherwise. Also, the hyphenated phrase ”High-Performance” has been deliberately chosen to provide the coveted ”H.” A more accurate word would be Efficient, but there is nothing remotely memorable about ”WEIP.”

For these reasons, the name WHIP caused considerable distress among the engineering segment of the development team. Nevertheless, despite its contrived nature, WHIP persisted as a very strong candidate. This is because WHIP provides a compelling and very hard-to-resist payoff: it allows us to say, with spectacular alliterative effect:

However, first and foremost we are engineers, not marketeers, and in the end the inherent inaccuracy of WHIP proved to be intolerable, and regretfully, we abandoned it.

Our final choice is LEAP, standing for the Lightweight and Efficient Application Protocols.¹ This leaves both the engineers and the linguists equally dissatisfied. It has some personality, though not as much as WHIP. And it is reasonably accurate, though not as accurate as EAPS. But it is a choice we can all live with.

Chapter 9
The Future of LEAP

9.1 Where We Are Today

At the time of writing in June 2000, the basic structure of the LEAP protocols is complete and in place. The key component protocols have been published as Internet RFCs, and public support organizations for the continued development and maintenance of the protocols have been created. All aspects of the LEAP development and maintenance processes conform fully to the basic trilogy of principles that we espouse: patent-freedom, RFC publication, and openness of maintenance.

Our next major challenge will be to promote the usage of LEAP throughout the Mobile Messaging industry. We will facilitate and encourage the adoption of LEAP by the following mechanisms:

• We will provide free, open-source software implementations of the LEAP protocols for major device platforms such as PalmPilot and Windows CE. This free software will be distributed through
  http://www.MailMeAnywhere.org.
• We will provide free, open-source software implementations of LEAP which are fully integerated with major Message Center platforms such as Sendmail and Qmail. This free software will also initially be distributed through http://www.MailMeAnywhere.org.
• We will provide free Subscriber Services. These free services will initially be provided through
  http://www.ByName.net.

The underlying purpose of this is to eliminate all economic and legal hindrances which might otherwise inhibit the adoption and usage of LEAP. We accomplish this by means of the patent-freedom of the protocols themselves, the availability of free, open-source software implementations the protocols, and the availability of free support services. The result of this is that the costs of implementing LEAP, other than the associated overhead costs, are zero.

By means of this strategy, we intend to make LEAP widespread throughout every segment of the Mobile Messaging industry. Our eventual goal is for LEAP to become the natural choice for Mobile Messaging applications.

9.2 Invitations to Participate

This is an ambitious goal, and cannot be accomplished without the cooperation and participation of others within the industry. We invite others to participate in the following arenas:

• Anyone who is interested in ESRO and EMSD is invited to participate in their development through ESRO.org and EMSD.org.
• Additional protocols are needed to enable efficient web browsing. A starting point for this, called EHDP (Efficient Hypertext Delivery Protocol), is currently being created. In developing EHDP we intend to build on the work of WAP and the W3 Consortium, and re-use the ESRO technology. We invite others to join us in this development effort.
• Additional protocols are needed to enable efficient access to dictionaries and other look-up data structures. A starting point for this, called EDICT (Efficient Dictionary protocol), is currently being created. In developing EDICT, we intend to build on the existing work already done in the context of the DICT protocol. We invite others to join us in this development effort.
• We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementations of ESRO-based instant messaging, chat, white pages, and others.

• Based on the existing open-soure software implementations for end-user devices, we invite others to enhance the PalmPilot and Windows CE implementations, and to port LEAP to additional general-purpose device platforms.
• We invite telephone manufacturers and wireless data modem manufacturers to include the LEAP protocols as an integral part of their next generation devices.
• We invite Message Center software developers to enhance and better integrate the Message Center LEAP software.

  We invite Subscriber Services providers such as AOL, Yahoo, MCI and AT&T to participate in the general concept of providing free services based on free protocols and open-source software, and to integrate LEAP into their suite of Subscriber Services. A model of this concept is provided by our own free service at www.ByName.net.

  Each of the LEAP protocols is a component which must be integrated into larger solutions. In particular, we invite the developers of customer-premise Message Centers to incorporate LEAP into their existing products.

9.3 Preview of Coming Attractions

Several LEAP-based products and services are currently under development. These include MailMeAnywhere, ByName and ByNumber.

9.3.1 MailMeAnywhere.org

In order to make use of the LEAP protocols convenient and widespread, we are providing implementations of the protocols as free and open-source software. Binary formats of the software for a variety of platforms are available. In order to provide complete solutions, the LEAP protocol components are integrated with various other free software components, forming consistent and coherent bundles. Since the initial LEAP components are oriented towards interpersonal messaging, the initial software distribution takes place through http://www.MailMeAnywhere.org.

MailMeAnywhere is a distribution center for free and open-source software which relates to LEAP, or which facilitates use of the LEAP protocols. Device implementations are available for a large number of general-purpose device platforms. Message Center implementations have been integrated with Qmail and Sendmail.

To learn more about MailMeAnywhere, see the website at http://www.MailMeAnywhere.org.

9.3.2 ByName.net and ByNumber.net

In order to make use of LEAP protocols convenient and widespread, we are also providing an initial free subscriber service which integrates the LEAP protocols into a variety of other services. We are delivering these services through the ByName.net domain. ByName provides a set of free services, based on free protocols which have been implemented as free software. The ByName services are highly personalized and are based on the user’s identity – ByName is based on the user’s name, while ByNumber is based on a numerical user ID.

A conventional e-mail account typically provides the user with a single address, usually of the form “someName@someDomain.com.” This provides the user with a single mailbox, to which all mail for that address is sent.

This becomes inconvenient when the owner uses the account for multiple types of incoming e-mail. For example, the user may use the account for both personal and work-related mail, to subscribe to various mailing lists, and to participate in usenet groups. Over time the user may get onto a large number of mailing lists, resulting in an incoming e-mail stream spanning a very wide dynamic range of importance, from urgent personal e-mail, all the way down to meaningless spam.

E-mail applications typically deal with this by providing the user with tools to manage and prioritize mail. These consist of inbox sorters and filters to eliminate spam and prioritize incoming messages based on the originator or subject.

The ByName.net service provides a better way. ByName provides you with multiple mailboxes and addresses, each of which can be dedicated to a particular type of e-mail. Furthermore, these various addresses have a simple and uniform naming scheme, based on the one symbol that is most dear and personal to you: your own name. ByName includes your name in the domain part of the address, and appends various selectors in front of the @ sign. For example, a particular subscriber might have the following addresses and mailboxes:

This provides our anti-hero with a consistent set of e-mail boxes that he can use for different purposes – one address for personal mail, a different one for work-related mail, and so on. Homer now has control over the routing of his e-mail without having to use a mail sorter or filters.

Your home page is also based on your name; Homer’s is http://homer.simpson.1.ByName.net.

To learn more about the ByName service and to apply for an account, see the website at
http://www.ByName.net.

The ByNumber.net service provides a complementary service to ByName, based on numbers rather than letters. ByNumber enables devices with digit-only origination capability (e.g. conventional telephone keypads) to send e-mail messages, and provides a unified way of sending messages to pagers, two-way pagers, faxes and e-mail accounts.

To learn more about the ByNumber service, see the website at
http://www.ByNumber.net.

Part II
LEAPing Over Closed Solutions

Chapter 10
The WAP Trap

10.1 Introduction

The new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This places an entirely new set of requirements on the underlying communications protocols – they must provide the power efficiency demanded by hand-held wireless devices, together with the bandwidth efficiency demanded by wide area wireless networks.

At some point, the wireless data communications industry must agree on a common set of standard protocols that satisfies these requirements. Unfortunately, the road to an industry standard is a rocky one. The wireless industry is populated by a number of disparate constituencies and self-interests. Among these constituencies are the technical community, with its fundamental mandate to create sound engineering solutions, and the business community, ultimately driven by the pursuit of profit and marketplace advantage. The differing agendas of these constituencies frequently bring them into conflict.

In this confusing environment it can be very difficult to distinguish between developments that are genuine, enabling technologies, and those that are ill-conceived wild-goose chases.

10.1.1 The Wireless Application Protocol (WAP)

Into this chaotic arena comes WAP. On April 30 1998, a group of business interests published a set of specifications referred to as the Wireless Application Protocol, or WAP. WAP is a specification for wireless data communications using hand-held devices such as mobile phones and palmtop computers. Use of the WAP specification allows mobile devices to communicate with the Internet or an intranet, providing the users of these devices with mobile data communications capabilities such as web-browsing and e-mail.

The WAP specification was developed by the WAP Forum, an industry association of wireless device manufacturers, service providers, and software companies. The WAP Forum was founded in June 1997 by three mobile phone manufacturers (Ericsson, Motorola and Nokia), together with the US software company Phone.com (formerly Unwired Planet). The WAP specification is largely the product of these four founding companies. Further information about the WAP Forum can be found at its website at http://www.wapforum.org/.

The Wireless Applications Protocol purports to be just what the doctor ordered: a set of standards that will unify the wireless data applications industry. WAP presents itself as an open, license-free standard for wireless Internet access. It claims to be a well-designed engineering construction, allowing free interoperability among wireless industry vendors. It claims to be an enabling technology that will catalyze the development of the wireless industry, to the ultimate benefit of the industry and the consumer.

As we will argue in this article, however, WAP satisfies none of these claims.

10.1.2 Characteristics of Successful Protocols

Industry standards do not usually come about as the result of an orderly design process. Especially in the early stages of industry development, protocols and standards arise organically, and without the benefit of hindsight. Because of this, early protocols are frequently very much less than ideal. As Bill Joy, the founder of Sun Microsystems, puts it,

Though his phrasing leaves much to be desired, his point is beyond debate: the most appalling solution is better than no solution at all.

However, history has shown that successful protocols tend have certain characteristics in common. By a ”successful” protocol, we mean one which becomes accepted as an industry standard in the face of competing protocols, endures as an standard in the long term, and serves to promote the growth of the industry.

The key characteristics of a successful protocol are:

1. Adequate Technical Design. It should address the basic technical requirements of the industry. This means that the protocol must primarily be an engineering construct, not a business one.
2. Open Development and Maintenance Process. Some form of mechanism should exist for public commentary on the protocol. The protocol should be maintained by a process that allows the participation of the various constituencies that are affected by the protocol.
3. Open Availability Process. It should be published and made available in a way that ensures that it is freely, easily and permanently accessible to anyone who wishes to use it.
4. Freedom from Usage Restrictions. There should be no restrictions on the use of the protocol. Anyone who wishes to base an application on the protocol should be able to do so without legal or financial hindrance of any kind.

Not all successful protocols have all these attributes. Nevertheless, as the history of protocol development demonstrates, the more a protocol conforms to these attributes, the more likely it is to become an enduring industry standard. An analysis of several successful and failed protocols, supporting this conclusion, is provided in the article entitled Lessons from History: Comparitive Case Studies within The LEAP Manifesto [65].

WAP claims to have all four of the above attributes. In fact, it has none of them. WAP has claimed center stage not because it fulfills the needs of the industry, but because thus far, no viable alternative has been presented.

10.1.3 About this Document

In this article we will show that WAP is entirely unfit for the purpose being claimed for it. We will show that it is handicapped as a result of the processes the WAP Forum has used to develop it, and that it includes numerous serious technical design errors. Our conclusion will be that the WAP specification is essentially a marketing construct, rather than an engineering one. It is designed to provide short-term financial benefit to a minority of the WAP Forum members, rather than providing long-term benefit to the industry at large and the consumer.

We will then enumerate and analyze the steps that can be taken to prevent the harm of WAP. One of the most crucial steps will be to identify alternatives to WAP, and eventually adopt one of these in place of WAP.

Finally, we will propose one alternative to WAP, namely LEAP, the Lightweight & Efficient Application Protocols. We provide a brief description of LEAP, and provide references to where further information on LEAP can be found.

This article is one of a series of articles we have written that analyze the current status of the wireless data communications industry, criticize WAP, and present our view of what is truly needed to promote the growth of the industry. Other articles in this series are:

• LEAP: One Alternative to WAP [64]. A companion paper to this one, taking over where this leaves off. The scope of the current paper is largely limited to a critique of WAP. This companion paper describes a specific alternative to WAP.
• The LEAP Manifesto [65]. This document provides a complete analysis of the industry, and a detailed description of the LEAP protocols.

Alternative Formats

In addition to this English-language version, this document has also been translated into French under the title Le WAP a la Trappe. Both English and French versions are available in several alternative formats at the Free Protocols Foundation website
(http://www.FreeProtocols.org/wapTrap):

• ONE-HTML: Displays the entire document as a single web page.
• SPLIT-HTML: Displays the document as a set of linked web pages, starting from the Table of Contents.
• PDF: Provides the document in Adobe Acrobat format. Note that the Adobe Acrobat Reader is required to read this format. The Acrobat Reader can be downloaded from the Adobe website.
• PS: Provides the document in PostScript format for printing.
• Text Only: Provides the document in text-only format.

Acknowledgments

We gratefully acknowledge the assistance of the following persons in the preparation and review of this document: Andrew Hammoude, Richard Stallman, Bill Frezza, Rob Mechaley, and Pinneke Tjandana.

Conflict of Interest Disclosure

The authors of this article were also the initial developers of LEAP, and therefore have a vested interest in the success of LEAP over WAP.

However, we are also active participants in the Free Protocols Foundation (FPF), under whose auspices this article is being written. As participants in the FPF, we are fully committed to its patent-free principles; principles which WAP violates completely. The mission of the Free Protocols Foundation is to provide support for patent-free protocols. Part of this mission is to provide support for patent-free alternatives to patented protocols such as WAP. It is in the spirit of this mission that this article is being written.

The purpose of this article is not to promote LEAP or any other particular alternative to WAP. The purpose of this article is to expose the harm of WAP and describe the steps that can be taken to prevent it. Any other viable alternatives to WAP that are brought to our attention, and that conform to the principles of the Free Protocols Foundation, will be promptly referenced at the FPF website, and included in subsequent versions of this article.

The most recent version of this article, describing all known alternatives to WAP, will be maintained on the FPF website at http://www.FreeProtocols.org.

10.2 WAP - A Procedural Fraud

There are two distinct sets of problems relating to WAP: procedural, and technical. In this section we will describe the procedural problems. The procedural problems lie in the processes that the WAP Forum has used to develop and disseminate the WAP specifications.

10.2.1 Not Open in Terms of Development and Maintenance

A highly desirable attribute of an industry standard protocol is that it be the result of an open design process. What this means is that, somewhere along the line, the various constituencies that have a stake in the protocol be given a voice in its development.

This does not mean that the protocol must be conceived and built from the ground up by industry-wide consensus. Indeed, this is usually impractical, and of necessity, the first drafts of any protocol are usually created by a small group, functioning autonomously.

An open design process means only that at a certain point, ownership of the protocol must become public. Beyond that point, the various industry constituencies must be given an opportunity to participate in its design, and the design process must include mechanisms for reaching consensus among conflicting lobbies.

Openness of design has two important benefits. First, it allows the protocol to be subjected to adequate technical review, ensuring that it is a sound engineering solution. Second, it prevents the design of the protocol from being excessively influenced by minority business self-interests. An open design process provides vital assurance of the integrity of the resulting protocol, in both engineering and business terms.

The WAP specification is in complete violation of these principles. The specification has been developed exclusively by the WAP Forum, entirely behind closed doors, and without the benefit of a single public mailing list for discussion and review. The WAP Forum permits no outside influence over the specification; the only institutions that may participate in its development and maintenance are the WAP Forum members themselves.

The WAP Forum claims that the specification is open, on the grounds that any company or organization is free to join the forum. While technically this is true, membership in the Forum carries a $27,000 entrance fee (as of February 2000). In practice, this fee effectively excludes most small businesses, and virtually all academic institutions.

The WAP Forum is therefore a highly restricted subset of the business and academic community, and influence over the specification is limited to those companies that can afford this entrance fee. The specification is thus the creation of a limited constituency of the telecommunications world; specifically, it is primarily the creation of a set of telephone manufacturers. Though important, the telephone manufacturers represent just a single component of the world of data communications. In creating WAP, grossly inadequate consideration has been given to other important disciplines and constituencies, such as the Internet engineering community, the academic community, and the small business community.

10.2.2 No Assurance of Availability and Stability

An essential attribute of an industry standard protocol is that it be freely and permanently accessible to anyone who wishes to use it. In the Internet world, this is traditionally accomplished by means of RFC publication. RFC publication provides the following important benefits:

• World-Wide Distribution. RFC publication ensures unrestricted world-wide distribution of the published protocol. There are many Web and FTP sites world-wide that carry the complete series of RFC documents - if any one site is busy or unavailable, someone seeking an RFC can simply go to another.
• Unrestricted Distribution. 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.
• Permanence. RFC publication is permanent. Even if the creator of a protocol should go out of business or otherwise become defunct, the RFC 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.

The WAP specifications do not carry these same assurances of free and permanent availability. Rather than being published as an RFC or by another third-party agency, the specifications are self-published by the WAP Forum. As a result of this, each of the above benefits of RFC publication is in some way diminished:

• Limited Distribution. The specifications are only available from a single source: the WAP Forum itself. If the WAP Forum web site should happen to be down, the specifications are simply unavailable.
• Restricted Distribution. In order to download any particular WAP specification, a user must agree to a license agreement.
• Diminished Permanence. The permanence of the WAP specifications is only as good as that of the WAP Forum itself. If the WAP Forum should ever become defunct and cease operations, all its specifications will become orphaned.
• Diminished Stability. The WAP Forum does not guarantee the stability of its specifications. As of February 2000, each WAP specification carries on its title page the disclaimer, “This document is subject to change without notice.”

This last item is particularly worrisome. A key attribute of a protocol is that any particular revision of it be fixed – indeed, this is the very definition of a standard. The WAP Forum’s disclaimer gives it the power to modify individual revisions of the specification at will – an extraordinary power to hold over something that purports to be an industry standard. This is not a purely theoretical concern – the WAP Forum has already exercised this power inappropriately [86].

Of overriding significance is the fact that the WAP Forum has declined to publish its specifications as RFCs. For all the above reasons, Internet-related protocols are always published as RFCs – this is the mainstream, industry-standard, method for publication of Internet protocols. RFC publication is well-understood and accepted within the Internet community, and fully represents the spirit of cooperation which is characteristic of this community. Quite simply, there is no good reason to do otherwise.

Yet the WAP Forum has done otherwise. Our question is: Why? We can think of only three plausible reasons:

1. The specifications are so technically deficient that they do not meet the minimum standards required for RFC publication.
2. The WAP Forum wishes to retain full control over the specifications, including the ability to change them at will, without regard to the resulting loss of stability.
3. The WAP Forum wishes to impose copyright restrictions on the protocols beyond those provided by RFC publication.

Whatever the reason, the WAP Forum evidently does not subscribe to the spirit of openness and cooperation represented by RFC publication and practiced by the Internet engineering community at large.

10.2.3 Not Patent-Free

An essential attribute of an industry building protocol is that there must be no restrictions on its usage. In particular, there must be no patent restrictions on the use of the protocol.

The WAP specification, however, is burdened with several patent restrictions. These include patents held by certain members of the WAP Forum itself, most notably Phone.com and Geoworks. Patent infringement claims have already been made by the holders of the following patents:

• U.S. Patent # 5,327,529 (Geoworks). Process of designing user’s interfaces for application programs.
• U.S. Patent # 5,809,415 (Phone.com, formerly Unwired Planet). Method and architecture for an interactive two-way data communication network.

More patent infringement claims can almost certainly be expected in the future.

One of the benefits of a standard protocol is that it does not provide any advantage to one industry player over another. Anyone who wishes to develop products and/or services based on the protocol may do so, and may then compete with similar products and/or services in a fair, open, free-market environment. In such an environment products succeed or fail based on their merits, and the benefits to the consumer are those traditionally resulting from free-market competition: better products at lower