Model
Version 1.2
March 1, 2001
This document describes the Lightweight & Efficient Application Protocols (LEAP), a set of protocols for mobile and wireless applications.
Verbatim Copying Permitted. Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for verbatim copying, except that this permission notice must be stated in a translation approved by the Copyright holder.
IBM and PC are trademarks of International Business Machines Corporation. Palm is a registered trademark of Palm, Inc. SUN is a registered trademark of Sun Microsystems. Windows is a registered trademark of Microsoft Corporation. Windows CE is a registered trademark of Microsoft Corporation. RIM, Research In Motion, and BlackBerry are trademarks of Research In Motion Limited. All other brands, product names and company names mentioned in this article may be trademarks or registered trademarks of their respective holders.
Model
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.
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.
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.
Where will the required protocols come from? Traditionally, industry-wide protocols have their origins in one of two sources:
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.
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.
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.
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.
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.
All the components that are needed to accomplish these goals are complete, in place, and ready to go. These components are:
http://www.esro.org
and
http://www.emsd.org
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.
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.
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.
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 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.
No one owns the LEAP protocols. The protocol specifications reside entirely in the public domain.
For more information, visit the LEAP Forum website at http://www.leapforum.org/.
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/.
For more information see the Free Protocols Foundation website at http://www.FreeProtocols.org.
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:
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:
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.
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.
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].
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.
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.
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/.
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/.
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.
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.
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.
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:
An illustration of how LEAP works is shown in Figure 21.4. As the figure shows, LEAP provides complete openness of interoperability among Mobile Messaging devices, message centers, and wireless networks.
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.
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.
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:
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.
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.
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.
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.
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.
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.
|
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.
Protocols come in all shapes and sizes, and from a variety of sources. Some are proprietary, intended for use exclusively by their developer. Others may be ``open'' in some sense, indicating that they are intended for more general, public usage. In this context, the word ``open'' can mean any one of several different things. It may mean nothing more than that the protocol has been published by its developer. The protocol may still be very tightly controlled: revision of the protocol may remain the exclusive right of the developer, the protocol may be protected by patent or copyright restrictions, and use of the protocol may require a licensing agreement. This is a very narrow, and to our mind misleading, use of the word ``open.''
At the other extreme, the protocol may be open to a very high degree of public accessibility: it can be published by an open mechanism such as RFC publication, undergo revision by means of public working groups, and be entirely free of usage restrictions. A protocol satisfying all these criteria can be said to be ``open'' in the broadest sense. Protocols are often referred to as ``open'' to imply that they are open in a broad sense, whereas in fact they are open only in the narrowest sense.
To a large extent, the character of a protocol is defined by the processes used to develop it. This article is about a particular set of protocols called called LEAP, or the Lightweight & Efficient Application Protocols. LEAP is a set of high-performance, efficient protocols intended for mobile and wireless applications.
The LEAP protocols are intended to be open in the absolutely broadest sense of the word; they are intended to be freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. The processes used to develop the LEAP protocols have been such as to ensure that they have these intended characteristics.
In this article we describe the LEAP development process. In the next section we provide a general description of the various phases of development that a protocol may go through. Then in subsequent sections we describe the specific processes used for the LEAP protocols at each phase of development.
In this article we also discuss the enormous economic influences that protocols can exert, and we point out the potential for corruption that inevitably accompanies this. We describe our general philosophy regarding protocol development, and we present what we consider to be the key principles which must be upheld in order to maintain protocol integrity in the face of corrupting influences. Finally, we provide justification for some of the protocol development choices we have made which others may consider to be unconventional or controversial.
Over its lifetime, a protocol typically goes through a number of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases:
Depending on its purpose, nature, and history, a protocol may undergo some, all, or none of these phases. Also, a protocol may iterate through phases (3) to (7) multiple times, as it undergoes maturation via repeated revision and re-publication.
In general, the developers of a protocol define and control the policy and processes to be applied to the protocol at every phase of development except (5) and (7). The developers have no direct control of (5) at all, and only minimal influence over (7).
The processes used at each phase of development determine the character of the resulting protocol. In the following sections of this article we will describe the processes applied to the LEAP protocols at each phase of development except (5).
The conception and early development of a protocol can take place in a variety of ways. A traditional source of Internet protocols is the IETF/IESG. Other sources of protocols are private businesses, the academic community, or even a single individual.
In the case of LEAP, initial development of the protocols was carried out by Neda Communications, Inc., a private business.
We believe that there is a tendency among established standards bodies to regard their own, officially sanctioned protocols as authoritative, while any other protocol is of questionable worth or validity. However, the history of protocol development does not support this view. Small groups of individuals have created protocols with far-reaching consequences (e.g. the World Wide Web), just as established standards bodies have created protocols which failed to achieved industry acceptance. For this reason we do not regard any one source of protocols as necessarily superior to any other.
It may be necessary to assign global parameters to a protocol.
In the case of LEAP, the necessary UDP port assignments for ESRO and EMSD have been made through the IANA.
If a protocol is intended to be an open protocol, as opposed to an in-house or proprietary one, then it must be made publicly available. This can be accomplished in various ways; the protocol can be self-published by the developer, or it can be published through an independent agency such as the Internet RFC Editor.
In common with other Internet protocols, the LEAP protocols have been published in the form of Internet RFCs [91], [5]. RFC publication provides a number of significant advantages:
For these reasons, RFC publication is the traditional, mainstream publication mechanism for Internet protocols, and virtually all Internet-related protocols are published this way. RFC publication of the LEAP protocols ensures that they are freely, easily and permanently accessible to anyone who wishes to use them.
If a protocol is intended to be open rather than proprietary, then the protocol developers may take steps to work towards a patent-free result.
In the case of a public protocol, the presence of patented components within the protocol is very undesirable. A public protocol provides a well-defined interoperability specification for an industry, so that businesses and other organizations can create products and services independently, which can then be relied upon to function and interoperate correctly. The protocol is a positive, enabling force for the entire industry.
In order for the protocol to play this role, anyone who wishes to implement and use it must be able to do so freely. The presence of patented components within the protocol places restrictions on its usage, and therefore undermines this purpose. Furthermore, the presence of the patent brings an enormously unfair market advantage to the patent holder. By exercising his patent rights, the patent holder can gain financial benefit from competing companies who wish to use the protocol, or can stifle competition altogether by denying the competing company the right to use the protocol at all.
Software patents thus pose a significant danger to protocols. In some cases patents become included in protocols by accident - that is, without deliberate intentionality on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a protocol, in an attempt to gain market advantage via ownership of the protocol.
In either case, the protocol can then be held hostage by the patent-holder, to the great disadvantage of anyone else who may wish to use it. Patented protocols thus have the effect of inhibiting free and open competition, and are therefore highly detrimental to the industry and the consumer.
The LEAP protocols are intended to be fully open and without usage restrictions of any kind. We have therefore exercised great diligence throughout their development to ensure their patent-freedom.
Various mechanisms exist for working towards a patent-free result. In developing the LEAP protocols, we have adopted a set of procedures defined for this purpose by the Free Protocols Foundation.
The Free Protocols Foundation, or FPF, is an independent, non-profit organization whose mission is to prevent the inclusion of patented components within protocols. The FPF has established a set of policies and procedures for protocol development that is designed to ensure, insofar as this is possible, that the resulting protocol is patent-free.
In general, there may be both an Author and a Working Group involved in the development of a protocol. The Author is the company, organization or other entity that has primary responsibility for the protocol. In some cases, the protocol may also undergo development at the hands of a Working Group - a set of independent individuals or companies who work cooperatively on the protocol, usually via public mailing lists. The FPF defines procedures for both Authors and Working Groups, allowing both to participate in the development of a protocol, while still maintaining the patent-free character of the protocol.
For example, both an Author and a set of Working Groups are involved in the development of LEAP. As noted above, the LEAP protocols were initially developed by Neda Communications, Inc., and this company continues to take primary responsibility for their maintenance. In addition, as described in Section 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.
Development of the LEAP protocols conforms in all regards to the processes and procedures of the Free Protocols Foundation. LEAP's compliance with these processes ensures, insofar as this is possible, that the LEAP protocols are, and will remain, patent-free.
We have adopted the FPF processes because they are available for use by any protocol developer, without the requirement that the developer be part of a formal standards organization. Various standards organizations include processes within their protocol development procedures which work towards patent-freedom. In general, however, these patent-free processes are created for the standards organization's internal use, and are not available for a protocol which is not officially sanctioned by the organization.
The FPF, on the other hand, is entirely egalitarian, providing the same level of support for patent-freedom to any protocol developer. To our knowledge, the FPF is unique in this regard.
Neda Communications, Inc., the original Author of the LEAP protocols, has made a declaration to the FPF that the LEAP protocols are intended to be patent-free. This declaration includes statements to the effect that:
The complete text of the declaration can be seen on the FPF website at http://www.FreeProtocols.org.
Protocols are usually not static, but instead typically undergo continued revision and enhancement. Depending on the character of the protocol, this may take place by closed, in-house processes, or by open and public ones. Since LEAP is intended to be a fully open protocol, it is maintained by fully open processes.
The LEAP protocols are developed and maintained through a set of public organizations. At present there are three of these:
Additional maintenance organizations are expected to be created as the LEAP protocol family grows.
None of these are standards organizations. They are simply forums to allow information exchange and cooperative effort relating to the LEAP protocols and technology.
Participation in these organizations takes place via various mailing lists which are hosted by each organization. Any interested company, organization or individual may participate by joining one or more of these mailing lists. Neither the organizations nor their mailing lists have any membership structure; nor does participation require any membership fees or other financial obligation.
For more information, and to subscribe to one or more mailing lists, visit the How To Participate area at any of the above websites.
In particular, ESRO.org and EMSD.org each host a Working Group mailing list. It is through the Working Group mailing lists that active development of the protocols takes place. Anyone may participate in the development of the ESRO and EMSD protocols by subscribing to the corresponding Working Group mailing list.
To subscribe to the ESRO Development Working Group mailing list, visit
http://www.esro.org/joinESROmailingList/esroSpec.html.
To subscribe to the EMSD Development Working Group mailing list, visit
http://www.emsd.org/joinEMSDmailingList/emsdSpec.html.
This open development process ensures that commentary and participation is open to any industry constituency that may be affected by the LEAP protocols.
Since the LEAP protocols are intended to be patent-free, the Working Groups must function in a way which preserves their patent-freedom. All LEAP protocol Working Groups therefore conform fully to the Free Protocols Foundation policies and procedures for Working Groups. These procedures ensure, insofar as possible, that a protocol remains patent-free despite undergoing collective development by a public Working Group. For more information, refer to the FPF website at http://www.FreeProtocols.org.
All Working Group contributors are required to adhere to these procedures. The Working Group imposes adherence to these procedures by requiring that all contributors agree to them as a condition of participation.
Both the ESRO Development Working Group and the EMSD Development Working Group have made declarations to the FPF that they conform fully to its patent-free policies and procedures. The text of these declarations can be seen on the FPF website.
The ultimate arbiter of any particular protocol is the industry itself, in which a multitude of individual decisions leads to the acceptance or rejection of the protocol. The acceptance of a protocol as a standard is therefore something that occurs independently of formal endorsement by a standards body.
Standards organizations such as the IETG/IESG certainly have no monopoly on innovation, creativity, or competence. Any company, organization or individual is capable of creating protocols that become successful, far-reaching industry standards, without the sponsorship or sanction of a standards body.
For example HTTP, the protocol which forms the basis of world-wide Internet communications, was developed and achieved prominence entirely independently of any formal standards body. The same is true of Pretty Good Privacy (PGP), now a world-wide encryption standard. These and many other protocols became industry standards despite lack of any official endorsement.
For these reasons we believe that official endorsement of a protocol as a standard has little meaning, and that genuine legitimacy for a protocol derives from its industry usage. We therefore have no immediate plans to subject the LEAP protocols to any formal standards track process. If and when they become widespread within the industry, we may at that time place them on standards track and seek their formal endorsement as a standard.
In general, protocols are a positive, enabling force for an industry. Protocols define an agreed-upon expected behaviour, allowing businesses to create products and services independently of one another, which can then be relied upon to interoperate correctly.
It may happen that one or more rival protocols arise, which address more or less the same industry need. Under these circumstances the rival protocols will effectively compete with one another, just as products and services do. It is usually most beneficial to the industry for there to be a single commonly-accepted protocol, so it is often the case that one protocol eventually displaces all others, thereby becoming an industry ``standard.''
In the early stages of formation of a new industry, this competition among protocols is of great benefit to the industry. As in the case of products and services, competition is a mechanism for selection of the best. Free and open competition allows the success or failure of protocols to be determined on the basis of their merits, and their fitness to serve the overall interests of the industry.
In an ideal world, the success of protocols would be determined exlusively on this basis. However, this is not an ideal world, and forces can arise which interfere with the free and fair competitive process. In particular, the adoption of a protocol by an industry can have enormous economic consequences. And where there is money, there is the potential for corruption.
Businesses may attempt to exercise control over protocols in various ways. During protocol development, they may seek to introduce patented components into the protocol, that they can subsequently exploit to their advantage. They may seek to control the protocol publication process, thereby allowing them to impose copyright restrictions on the protocols, or even make unilateral, unannounced changes to the protocol specifications. They may develop and/or maintain the protocol by means of closed, exclusionary processes, which deny broad technical review of the protocol, and allow its design to be dictated by minority business self-interests.
We believe that there are three basic, fundamental principles for defending against these sorts of underhanded activities. These are:
Each of these provides a vital assurance of protocol integrity. Patent-freedom ensures that a patent-holder cannot subvert free-market competition among products and services based on the protocol. RFC publication ensures that the protocol is freely available to anyone who wishes to use it. And maintenance by open organizations ensures that development of the protocol takes place by democratic, rather than oligarchic, processes.
This trilogy of principles represent the most basic guarantees of the integrity of a protocol. If any one of these things is missing, then this means that some attempt is being made to control or limit access to the protocol. In the case of a public protocol, there is no valid reason for doing this.
In addition to its general, industry-wide economic benefits, the adoption of a protocol also brings a unique set of benefits to its developer. These benefits consist of name recognition, and first-mover advantages in terms of development and sales of services and products based on the protocol. There may also be other significant benefits, such as those resulting from ownership of software patents related to the protocol.
These benefits can result in a huge financial windfall for the protocol developer. For this reason, the developer has an enormous vested interest in the adoption of his protocol in preference to any others. And this may lead the developer to promote his protocol in ways which subvert the free and fair competitive process among protocols. One of the ways a business may do this is by seeking to exert inappropriate influence or control over the activities of standards organizations. In particular, the developer may seek to have his protocol labelled as a ``standard,'' while denying this label to other protocols. Alternatively, a business or group of businesses may form their own ``standards organization'' as an exclusive promotional vehicle for their own protocol. In either case the standards organization is in effect in the pocket of Big Business, and their discriminatory labelling of their own protocol as a ``standard'' represents another form of corruption. Though this serves the self-interest of the developer, it is likely to cause the industry to adopt the ``wrong'' protocol - i.e. not the one that best serves its overall needs. This is enormously detrimental to the industry at large and the consumer.
The incentives for businesses to indulge in these underhanded tactics is in direct proportion to the size of the industry and the financial stakes. And in the wireless data communications industry, the stakes are very high indeed.
As a result of this, we are currently seeing an enormous amount of standards-related activity in the wireless arena. Since 1998 a large number of self-proclaimed standards organizations relating to wireless data have been created, are claiming legitimacy, and are attempting to impose their own protocols on the industry. Among these recently-formed groups are:
Each of these organizations is an independent entity, with its own claim of legitimacy, its own protocol publication mechanism, and its own set of restrictions and limitations on participation. Beyond the realm of specific wireless subnetworks, there is no reasonable need for this large number of independent standards organizations.
Many of these organizations are simply an instrument of Big Business. They are the result of a group of businesses forming an industry association or forum, for the purpose of branding their own protocol as a ``standard.''
At best, this labelling of some protocols but not others as ``standards'' is meaningless; it is a semantic shell game. And at worst, this labelling is an attempt by Big Business to market one set of protocols in competition with another. Marketing has its place in the promotion of a company's own products and services. But an industry protocol represents a public trust, and business marketing has no place in this arena.
We believe that the ultimate criterion of the legitimacy of a protocol is its acceptance and usage in the industry at large. And the industry at large is entirely capable of establishing its own winners and losers by means of free and fair competition among protocols. This arbitrary standards labelling serves only to corrupt this competitive process.
Our philosophy regarding protocol development requires only that the developer make sure that he adheres to the basic trilogy of principles described above. Beyond that, free and fair competition will do the rest.
By making it clear that these self-promoting consortia have no genuine legitimacy, we seek to reduce their influence and the harm they do to the industry.
We are developing the LEAP protocols independently of the IETF, and we have not sought out their formal endorsement by the IETF.
Our decision to work independently of the IETF is a result of our previous experiences with IETF. Based on our interactions with the IETF, we have concluded that the illegitimate influence that the IESG and the IAB exert over non-IETF protocol specifications is counterproductive. We believe that the IESG and IAB are both prejudiced against externally-generate protocols (a frame of mind sometimes referred to as Not Invented Here syndrome), and that they engage in the active supression of competing protocols which originate outside their own domain.
The IETF has become an autocratic organization that acts to suppress innovation rather than encourage it. Indeed, on its own mailing lists, the IETF acronym has been referred to as the ``Innovation Extermination Task Force,'' and the IETF/IESG/IAB has been referred to as a ``cult.'' We do not consider either of these characterizations as being in the least inappropriate.
Our conclusion is that Big Business and political interests have now taken over the critical decision making processes within the IETF/IESG/IAB. We have come to this conclusion after many years of attempting to work within the system to bring the IETF back to it its original intended purpose. Our interactions with the IETF relating to several issues are publicly available:
Based on the above records we have come to the conclusion that the IESG is now characterized by irresponsibility, incompetence and arrogance.
We believe that a lesser IETF will be a better IETF. The IETF has been a source of new protocols in the past, and there is no reason why it cannot continue to create and develop new protocols in the future.
But traditionally, the scope of IETF has gone far beyond this; the IETF has also claimed responsibility for judging, labelling and ratifying protocols. We believe that these IETF functions are unnecessary and inappropriate. All the functions that the IETF claims to provide can be accomplished by means of:
The 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.
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].
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.
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.
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.
Throughout this document, we will use the following terms with the meanings indicated:
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 [17].
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.
This document is available in several alternative formats at Free
Protocols Foundation website
(http://www.freeprotocols.org/freeProtocolProcess):
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.
Over its lifetime, a protocol typically goes through a number of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases:
Depending on its purpose, nature, and history, a protocol may undergo some, all, or none of these phases. Also, a protocol may iterate through phases 3 - 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.
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.
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.
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.
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:
Similarly, the Working Group may wish to make a declaration that:
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.
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.
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:
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.
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:
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.
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.
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.
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:
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.
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:
We encourage others to join us in resisting the granting and abuse of software and protocol patents.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.
Considering that:
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 [14], 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.
The requirements and goals driving the ESRO protocol and system design include the following:
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.
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.
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.
Remote Operations Services Element (ROSE) is specified in [20] and [21]. 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.
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].
Transaction/TCP is specified in [15] and [16]. 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.
Reliable Data Protocol (RDP) is specified in [41] and [40].
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.
Versatile Message Transaction Protocol (VMTP) is specified in [23].
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.
Transmission Control Protocol (TCP) is specified in [78] and [16].
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.
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.
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 [14].
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.
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.
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.
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/.
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.
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.
When designing applications which use ESRO services, a number of common issues often need to be considered. These include:
We discuss each of these in some detail below.
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.
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:
An example of the usage of all three of the above methods is provided by EMSD [5].
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].
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.
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.
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.
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.
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.''
Various efficient horizontal applications have been developed or are being developed using ESRO. These include:
A brief description of each is provided below.
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/.
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.
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.
Various efficient vertical applications have been developed or are being developed using ESRO. These applications include:
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.
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.
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.
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.
Throughout this article, we will make use of the following terms and definitions:
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.
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.
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.
EMSD consists of two independent components: the EMSD Format Standard, and the EMSD Protocol. These two components provide the following functions:
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.
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.
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.
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/.
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.
The EMSD protocols have been designed to accomplish three high-level goals:
Based on these goals, EMSD has been designed to satisfy the following design requirements:
The EMSD protocols make extensive use of existing technology, including:
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.
This section summarizes the rationale for the key design decisions that were made while developing the EMSD protocols.
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.
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.
|
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:
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.
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.
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.
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 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.
For complete instructions on how to obtain the EMSD protocols, visit the "Base Protocol Specifications" section of http://www.emsd.org/.
This article was originally published in October 1996. It is being included in the Manifesto, essentially unchanged from its original form.
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 ![[*]](file:/usr/local/lib/latex2html/icons/crossref.gif){kind=icon}
and
.
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.
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:
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:
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.
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.
|
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:
At Site Two:
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.
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.
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.
IP_PDU MailServer UA DATA TCP IP -------------------------------------------------------------------- 1 TCP .<------- TCP SYN -------- . 0 24 44 2 TCP . ------- TCP SYN ack ---->. 0 24 44 3 TCP .<------- Push ACK ------- . 0 20 40 (128) 4 SMTP . ----220 server ready --->. 116 136 156 5 TCP .<------- Push ACK ------- . 0 20 40 (196) 6 SMTP .<------- HELO <client>--- . 36 56 76 7 SMTP . ----250 server Hello --->. 111 131 151 8 TCP .<------- Push ACK ------- . 0 20 40 (267) 9 SMTP .<--MAIL FROM:<sender> --- . 32 52 72 10 SMTP . ----250 ... Sender ok--->. 39 59 79 11 TCP .<------- Push ACK ------- . 0 20 40 (191) 12 SMTP .<--RCPT TO:<rcpt>-------- . 33 53 73 13 SMTP .<----250...Recipient ok-- . 45 65 85 14 TCP .<------- Push ACK ------- . 0 20 40 (198) 15 SMTP .<------ "DATA" ---------- . 6 26 46 16 TCP . ------- ACK ------------>. 0 20 40 (86) 17 SMTP . ----354..end with "."--->. 50 70 90 18 TCP .<------- Push ACK ------- . 0 20 40 (130) 19 SMTP .<--Mail header+body ----- . 437 457 477 20 SMTP .<------ . --------------- . 5 25 45 21 TCP . ------- ACK ------------>. 0 20 40 (562) 22 SMTP . ------- 250 Ok --------->. 8 28 48 23 TCP .<------- Push ACK ------- . 0 20 40 24 TCP .<------- Push Reset ----- . 0 20 40 (128) ----------------------------------------------------------------------
Total IP Packet bytes: 1886 Message Length (header + body): 437 Total Overhead (TCP header + IP header): 1449 3.1.4 Message as Received Message-ID: <32249501.46FD@airdata.com> Date: Wed, 28 Aug 1996 11:50:41 -0700 From: Jia-bing Cheng <jcheng@airdata.com> Organization: AT&T Wireless Services X-Mailer: Mozilla 2.0 (Win16; U) MIME-Version: 1.0 To: j.cheng@pocketnet.net Subject: test3 X-URL: file:///c:/netscape/jbc.htm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 123456789012345678901234567890 12345678901234567890 1234567890
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.
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.
IP_PDU MailServer UA DATA UDP IP --------------------------------------------------------------- 1 UDP .<--Invoke header+body --- . 206 214 234 2 UDP . -----Response ---------->. 15 23 43 3 UDP .<------- Ack ------------ . 2 10 30 ---------------------------------------------------------------
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.
The # text below is provided as comments and does not appear in the received message.
P.!.0. ... 0..0z@."333. 333"<test1@emsd. neda.com> # FROM: 010/@)Jia-bing-pn Cheng<j.cheng@pocketnet.net> # RCPT: ......test4 # Subject: ....text/plain; charset=us-ascii # content-type 0C.A # 123456789012345678901234567890. # BODY: 12345679801234567890. 1234567890
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.
Please refer to Figure 7.1 above for this experiment.
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>.
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.
IP_PDU MailServer bluejeans DATA TCP IP -------------------------------------------------------------------- 1 TCP .<------- TCP SYN -------- . 0 20 40 2 TCP . ------- TCP SYN ack ---->. 0 20 40 3 TCP .<------- Push ACK ------- . 0 20 40 4 SMTP . ----220 server ready --->. 116 136 156 5 SMTP .<------- HELO <client>--- . 16 36 56 6 SMTP . ----250 server Hello --->. 95 115 135 7 SMTP .<--MAIL FROM:<sender> --- . 29 49 69 8 SMTP . ----250 ... Sender ok--->. 39 59 79 9 SMTP .<--RCPT TO:<rcpt>-------- . 44 64 84 10 SMTP .<----250...Recipient ok-- . 57 77 97 11 SMTP .<------ "DATA" ---------- . 6 26 46 12 TCP . ------- ACK ------------>. 0 20 40 13 SMTP . ----354..end with "."--->. 50 70 90 14 SMTP .<--Mail header+body ----- . 301 321 341 15 TCP . -------- ACK ----------->. 0 20 40 16 SMTP .<------ . --------------- . 5 25 45 17 TCP . ------- ACK ------------>. 0 20 40 18 SMTP . ------- 250 Ok --------->. 8 28 48 19 SMTP .<------- QUIT ----------- . 6 26 46 20 SMTP .--221 closing connection->. 46 66 86 21 TCP .<------- FIN ACK -------- . 0 20 40 22 TCP . -------- ACK ----------->. 0 20 40 23 TCP . ------- FIN ACK -------->. 0 20 40 24 TCP .<------- ACK ----------- . 0 20 40
Total IP Packet bytes: 1778
Message Length (header + body): 301
Total Overhead (TCP header + IP header): 1477
Received: by bluejeans. (SMI-8.6/SMI-SVR4) <09>id PAA24890; Fri, 13 Sep 1996 15:34:53 -0700 Date: Fri, 13 Sep 1996 15:34:53 -0700 From: jcheng@bluejeans Message-Id: <199609132234.PAA24890@bluejeans.> To: dnakano@griffey.nwest.airdata.com Subject: test1 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890
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:
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.
(arash) (vader)
IP_PDU Mailbox Client DATA TCP IP
---------------------------------------------------------------
1 DNS *<-- DNS Query ----------- . (dns)
2 DNS * -- DNS Reponse---------->.
3 TCP .<-- SYN req-------------- . 0 24 44 (conn)
4 TCP . ---SYN ACK ------------->. 0 24 44
5 TCP .<-- ACK ----------------- . 0 20 40
6 TCP . ---POP3 server OK ------>. 117 137 157 (auth)
7 TCP .<-- ACK ----------------- . 0 20 40
8 TCP .<-- AUTH twinkie -------- . 14 34 54
9 TCP . ---unknown command ----->. 45 65 85
10 TCP .<-- USER test-1 --------- . 13 33 53
11 TCP . ---user acpt,password? ->. 41 61 81
12 TCP .<-- PASS ****** --------- . 13 33 53
13 TCP . ---+OK ----------------->. 0 20 40
14 TCP . ---+OK mbox open 1 msg-->. 30 50 70 (trans)
15 TCP .<-- STAT ---------------- . 6 26 46
16 TCP . ---+OK 1 542------------>. 11 31 51
17 TCP .<-- UIDL 1 -------------- . 8 28 48
18 TCP . ---unknown command ----->. 43 63 83
19 TCP .<-- TOP 1 0 ------------- . 9 29 49
20 TCP . ---+OK Top of msg ------>. 503 523 543 (_header)
21 TCP .<-- LIST ---------------- . 6 26 46
22 TCP . ---+OK scan listing----->. 44 64 84
23 TCP .<-- RETR 1 -------------- . 8 28 48
24 TCP . ---+OK 542 msg body---->. 561 581 601 (_body)
25 TCP .<-- DELE 1 -------------- . 8 28 48
26 TCP . ---+OK msg deleted ----->. 21 41 61
27 TCP .<-- ACK ----------------- . 0 20 40
28 TCP .<-- QUIT ---------------- . 6 26 46
29 TCP . ---+OK ----------------->. 6 26 46
30 TCP . ---Sayonara ------------>. 14 34 54
31 TCP .<-- FIN ACK ------------- . 0 20 40
32 TCP . ---+OK sa--------------->. 6 26 46
33 TCP .<-- FIN ACK ------------- . 0 20 40
34 TCP . ---ACK ----------------->. 0 20 40
---------------------------------------------------------------
Total IP Packet bytes: 2731
Message Length (header+body): 561
Total Overhead: 2170
+OK 542 octets.. Return-Path: <muratd@neda.com>.. Received: from vader.neda.com by arash.neda.com (5.0/SMI-SVR4)... id AA04601; Wed, 18 Sep 1996 16:35:39 +0800.. Date: Wed, 18 Sep 1996 16:35:11 -0700 ().. From: Murat Divringi <muratd@neda.com>.. To: test-1@arash.neda.com.. Subject: test6.. Message-Id: <Pine.WNT.3.95.960918163418.-158025A-100000@vader.neda.com>.. X-X-Sender: muratd@zahak.neda.com.. Mime-Version: 1.0.. Content-Type: TEXT/PLAIN; charset=US-ASCII.. Content-Length: 66.. Status: .. .. 012345678901234567890123456789 .. 01234567890123456789 .. 0123456789 .. ..
Please refer to Figure 7.2 above for the experimental setup.
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.
(zahak) (198.62.92.35)
IP_PDU Mailbox Client DATA TCP IP
---------------------------------------------------------------
1 DNS *<-- DNS Query ----------- . (dns)
2 DNS * -- DNS Reponse---------->.
3 TCP .<-- SYN req-------------- . 0 24 44 (conn)
4 TCP . ---SYN ACK ------------->. 0 24 44
5 TCP .<-- ACK ----------------- . 0 20 40
6 TCP . ---IMAP2 server OK ----->. 78 98 118 (auth)
7 TCP .<-- ACK ----------------- . 0 20 40
8 TCP .<-- LOGIN test-1 **** --- . 28 48 68
9 TCP . ---ACK ----------------->. 0 20 40
10 TCP . ---LOGIN completed ----->. 27 47 67
11 TCP .<-- A001 SELECT INBOX --- . 21 41 61
12 TCP . ---ACK ----------------->. 0 20 40
13 TCP . ---A001 cmp 1 EXISTS --->. 110 130 150
14 TCP .<-- A002 NOOP ----------- . 13 33 53
15 TCP . -- A002 NOOP cmp ------->. 26 46 66
16 TCP .<-- A003 FETCH 1:1 ALL -- . 22 42 62
17 TCP . -- A003 FETCH evlp cmp-->. 364 384 404 (())
18 TCP .<-- A004 NOOP ----------- . 13 33 53
19 TCP . -- A004 NOOP cmp ------->. 26 46 66
20 TCP .<-- ACK ----------------- . 0 20 40
21 TCP .<-- A005 FETCH 1:1 FULL-- . 23 43 63
22 TCP . -- A005 FETCH 1:1 cmp--->. 431 451 471 (())
23 TCP .<-- A006 FETCH 1 RFC822hdr. 30 50 70
24 TCP . -- A006 FETCH 1 cmp hdr->. 708 728 748 (_header)
25 TCP .<-- A007 FETCH 1 body-----. 24 44 64
26 TCP . -- A007 FETCH 1 cmp body>. 125 145 165 (_body)
27 TCP .<-- ACK ----------------- . 0 20 40
28 TCP .<-- A008 SEARCH DELETED --. 23 43 63
29 TCP . -- A008 SEARCH cmp ----->. 38 58 78
30 TCP .<-- A009 LOGOUT --------- . 15 35 55
31 TCP . ---ACK ----------------->. 0 20 40
32 TCP . -- A009 LOGOUT cmp ----->. 80 100 120
33 TCP .<-- FIN ACK ------------- . 0 20 40
34 TCP . ---ACK ----------------->. 0 20 40
35 TCP . -- FIN ACK ------------->. 0 20 40
36 TCP .<---ACK ----------------- . 0 20 40
Total IP Packet bytes: 3593
Message Length (header+body): 833
Total Overhead: 2760
* 1 FETCH(RFC822.HEADER {646}..
Received: from arash.neda.com (arash [198.62.92.10]) by zahak.neda.com
(8.6.10/8.6.10) with SMTP id QAA16710 for <test-1@zahak>;
Wed, 18 Sep 1996 16:42:24-0700..
Received: from vader.neda.com by arash.neda.com (5.0/SMI-SVR4)...
id AA04617; Wed, 18 Sep1996 16:41:42 +0800..
Message-Id: <9609182341.AA04617@arash.neda.com>..
From: "test-1" <test-1@neda.com>..
To: <test-1@zahak.neda.com>..
Subject: test6..
Date: Wed,18 Sep 1996 16:41:13 -0700..
X-Msmail-Priority: Normal..
X-Priority: 3..
X-Mailer: Microsoft Internet Mail 4.70.1155..
Mime-Version: 1.0..
Content-Transfer-Encoding: 7bit..
Content-Type: text/plain; charset=ISO-8859-1..
Content-Length: 66....)..
A00006 OK FETCH completed..
* 1 FETCH (BODY[1] {70}..
012345678901234567890123456789 ..
01234567890123456789 ..
0123456789..
..
)..
A00007 OK FETCH completed..
Please refer to Figure 7.2 above for this experiment.
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.
IP_PDU UA MailServer DATA UDP IP --------------------------------------------------------------- 1 UDP .<--Invoke header+body --- . 299 307 327 2 UDP . -----Response ---------->. 2 10 30 3 UDP .<------- Ack ------------ . 2 10 30 ---------------------------------------------------------------
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.
From jcheng@airdata.com Tue Oct 01 16:16:31 1996
Date: 14 Sep 96 05:48:55 GMT
From: jcheng@airdata.com
Subject: TEST Subject
To: 333.333@
Message-ID: <199609132148.OAA24774@bluejeans.>
Content-Length: 66
X-Homepage: Visit our home page at http://www.airdata.com/
id OAA24774; Fri, 13 Sep 1996 14:48:55 -0700
1234567890 1234567890 1234567890
1234567890 1234567890
1234567890
The following paragraphs summarize the results obtained above. Results indicate that EMSD compares very favorably to other message transfer mechanisms.
|
|
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.
This study was performed with the support and assistance of AT&T Wireless Services.
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.
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).
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.
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.8.1 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.
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:
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.
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:
Several LEAP-based products and services are currently under development. These include MailMeAnywhere, ByName and ByNumber.
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.
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:
personal@homer.simpson.1.ByName.net
office@homer.simpson.1.ByName.net
urgent@homer.simpson.1.ByName.net
public@homer.simpson.1.ByName.net
mobile@homer.simpson.1.ByName.net
pager@homer.simpson.1.ByName.net
fax@homer.simpson.1.ByName.net
emergency@homer.simpson.1.ByName.net
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.
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.
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.
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,
"Sometimes when you fill a vacuum, it still sucks."
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:
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.
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:
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):
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.
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.
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.
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.
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:
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:
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:
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.
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:
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 prices.
The inclusion of patents in a standard entirely corrupts this process. The patent provides the patent-holder with a sustained and unfair market advantage. The losers are the industry as a whole, small companies, and the consumer.
Patents thus pose a significant danger to protocols. For this reason, the protocol development process must include mechanisms to address and eliminate patent restrictions. Such mechanisms exist, and are well-known and understood within the Internet community. For example, we refer the reader to RFC 2026, The Internet Standards Process - Revision 3 [17]. Section 10 of this document, Intellectual Property Rights, describes the policies and procedures followed by the IESG (Internet Engineering Steering Group) in this regard. Among other things, this section describes their policy regarding:
The IESG policy is an example of the effort typically made within the Internet community to work strenuously and diligently towards the goal of a patent-free protocol.
As another example, the Free Protocols Foundation publishes a set of policies and procedures for protocol development that ensures, as far as possible, that the resulting protocol is functionally patent-free. These procedures are fully documented in the Free Protocols Foundation Policies and Procedures, Version 1.0 [63]. Any development organization is free to adopt these procedures with regard to its own protocols.
The WAP Forum, clearly, has not followed the example set by the Internet community at large. Procedures such as those of the IESG and the Free Protocols Foundation are well understood within the Internet community, and by following such procedures the WAP Forum could have ensured patent-freedom of the WAP specification, had it wished to do so. However, it has not adopted such procedures, and as a result the WAP specification is in total violation of the principles of patent-freedom.
More than any other factor, it is the failure of the WAP Forum to work towards a patent-free specification that leads us to characterize the WAP specification as a trap. Two of the companies that participated in the development of the WAP protocol (Phone.com and Geoworks) own patents which they silently included in the protocol design. They remained silent until use of the protocol began to spread throughout the industry, and only then did they announce their patent ownership and demand royalties. In effect, these companies have booby-trapped the WAP specification with their patents.
The WAP Forum clearly does not share the Internet community's commitment to patent freedom. Indeed, the WAP Forum's attitude to patents appears to be diametrically opposed to this. To quote Ben Linder, VP of Marketing for Phone.com [25],
``By virtue of building a standard, each company contributes a small part of it. Then you trade with each other to keep implementing the standard.''
Mr. Linder seems to view patent rights as something to be traded among companies like baseball cards. Our question is: How are companies without any cards expected to participate in this trade?
The spirit of a healthy protocol is that it be open and free, a spirit which the WAP specification violates completely. The WAP Forum's characterization of WAP as an ``open, license-free standard'' is utterly preposterous.
Throughout its web site and printed materials, the WAP Forum repeatedly refers to its specification as a ``standard.'' The use of this term is inappropriate and misleading.
In common engineering usage, the term ``standard'' means certain specific things. It means a protocol or other specification which
(a) is supported and approved by an established, professional standards organization, and
(b) has achieved industry-wide acceptance and usage.
The WAP specification enjoys neither form of legitimacy. It is approved by no organization other than the WAP Forum itself, which has no standing as a professional standards body. Also, despite the claims made in the WAP Forum's promotional material, it has achieved little acceptance in the marketplace. Though marketing projections for use of WAP are very impressive, its actual usage in the U.S. remains limited.
The WAP Forum's use of the word ``standard'' implies that their specification carries some kind of formal authority; in fact, it has none. The WAP Forum's use of this term is marketing hype, not an objective statement of fact.
Any group of business interests can form a members-only club, generate a specification, publish it themselves, and call it whatever they wish. Regardless of the name they choose to attach to it, however, this does not make the result a ``standard'' in the conventional sense.
In addition to its procedural flaws, the WAP specification also includes serious technical deficiencies.
A detailed technical criticism of the WAP specification is beyond the scope of this document, and in this section we will do no more than provide a brief summary of the major issues. For a detailed analysis of WAP, the reader is referred to the article W* Effect Considered Harmful [86], in which author Rohit Khare argues the shortcomings and ultimate non-viability of the WAP specification.
The deficiencies in the WAP specification are glaring, obvious, and readily apparent to any competent data communications professional. A recent (January 2000) e-mail discussion thread on the IETF mailing list [50] makes this point quite plainly - this thread demonstrates clear consensus among professionals that the WAP specifications are not a technically sound engineering solution.
Many of the technical problems stem from a strategic design decision, made early in the design process. As noted in the Introduction, a new set of protocols are clearly needed to address the efficiency needs of mobile wireless devices. One approach to this would be to treat these devices as just another kind of Internet host. Under this approach, the existing Internet protocol architecture would remain in place, and to this would be added a small number of supplementary Internet protocols, designed to provide the power and bandwidth efficiency required by wireless devices and networks.
The other approach is to treat these mobile devices as a unique special case, requiring their own, entirely new set of protocols. Under this approach, the existing Internet protocol stack is discarded, and a completely new protocol stack is re-designed from scratch.
The WAP Forum made the early strategic design decision to take the latter approach. They have developed an entire stack of network protocols analogous to, but largely incompatible with, the existing Internet architecture. Not only has this approach required an enormous engineering effort on the part of the protocol designers and implementers, it has also given rise to a number of fundamental design errors.
A basic principle of data communications protocol design is that communications considerations must be de-coupled from user interface considerations. In other words, user interface issues must not be part of the protocol.
The WAP specification, however, violates this principle completely. It is tailored primarily to the physical characteristics of the hand-held mobile telephone, with its unique user interface characteristics. Accommodation is made to these characteristics throughout the specification, with the result that user interface issues are repeatedly combined and confused with communications issues. To put this in the language of data communications professionals: WAP presumes presentation.
The WAP designers justify this on the grounds that the combined technologies of wireless communications, and the mobile telephone, create a unique special case which warrants this departure from standard design principles. In fact, this is a strategic design error.
Because WAP is essentially a marketing construct, one of its goals has been to create mindshare within every segment of the wireless industry. In order to accomplish this goal, WAP has made extreme accommodation to existing wireless networks. The WAP specification claims to accommodate almost all existing networks, including several which are already obsolete in their usage and general design. This has significantly and unnecessarily increased the complexity of the specification.
The WAP specification claims to support all the following wireless networks: CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, Mobitex, SMS, USSD, CSD, IS-136.
Some of these networks, such as FLEX and ReFLEX, are not general-purpose wireless networks, and were neither intended nor designed to run Internet-centric application protocols of any kind. WAP's decision to accommodate such networks makes little sense in engineering terms. This decision can only have been based on marketing considerations - each additional network supported provides WAP with one more promotional bullet point. Engineering concessions to marketing are a fact of life in the world of consumer products, but they have no place in an industry-standard protocol.
Wireless networks are rapidly standardizing on IP, the Internet Protocol. Most modern wireless networks (e.g. CDPD, Packet CDMA) already support native IP, and we can expect that others will do so in the very near future. The convergence of wireless networks on IP at Layer 3 (the Network Layer) is already a technological reality, and it is inevitable that it will eventually become standard on all networks.
Therefore the correct approach to wireless application standardization is to accept IP as the standard service at Network Layer, and implement high-efficiency protocols above Layer 3.
Furthermore, the result of accommodating all these networks is that the specification is no longer Internet-centric. WAP insists that the specification is Internet-centric, but this claim is without substance. If one tries to accommodate all existing technologies one cannot claim that the result is Internet-centric - one simply cannot have it both ways.
WAP claims to achieve accommodation of this very wide range of networks by means of two lower layer protocols: Wireless Control Message Protocol (WCMP), and Wireless Data Protocol (WDP).
WCMP is an out-of-place imitation of ICMP. Since there are no multiprotocol wireless operators, use of WCMP is always addressed as a service provider specific mechanism. In other words, WCMP is largely irrelevant.
WDP is roughly equivalent to UDP. The only rationale for its reinvention is to accommodate airlink addresses and airlink restrictions on packet size. The equivalent of WDP could have been accomplished on a per-network basis outside the scope of wireless applications. In fact, the existence of WDP may become a hindrance towards evolution of existing wireless networks towards IP.
In general, backward compatibility is a worthy design goal. But in this particular case it is a wasted effort. The convergence of wireless networks towards IP is already a technological reality. The strength and benefits of ``IP On Everything'' by far outweigh the efforts in accommodation and backward compatibility.
WAP's choice has been to accommodate all existing old wireless networks - a fact which betrays its underlying market motivation.
Existing Internet protocols do not adequately meet the requirements of wireless data communications - on this point we are in complete agreement with the WAP Forum. However, we believe that the correct way to design the required protocols is to do so within the framework of the existing Internet protocol architecture - the new protocols should be compatible with and re-use existing protocols as much as possible.
The WAP designers, however, have taken precisely the opposite view. Instead of re-using existing protocols, they have created an entirely new set of protocols from scratch.
The main key piece of new technology in WAP is the Wireless Transaction Protocol (WTP). In many ways, WTP is the heart of WAP. WTP is responsible for delivering efficient reliability to applications. Even in that area, WAP could have re-used existing technology. Specifically, T/TCP [16] and ESRO [91], which had already been published as Internet RFCs, could have been used. While there may be some reasonable objections to the use of T/TCP due to its ``heaviness'' because of bundling with TCP, there is no reason why ESRO could not have been used instead of WTP. In fact, WTP is a poor attempt at accomplishing the services of ESRO.
Aside from WTP, in most cases WAP's new protocols are essentially the same as the previously existing protocols, but with minor modifications that render them incompatible with the original standard. The WAP specification discards and then re-designs almost every existing Web standard - for example, WAP replaces UDP with WDP, TLS with WTLS, HTTP with WTP, HTML with WML, and ECMAScript with WMLScript.
This large amount of re-invention is entirely unnecessary. There are many places throughout the design of the WAP protocols where the existing protocol structure could have been left untouched, but complemented by the addition of a limited number of new protocols, designed for optimal efficiency.
The scope of the WAP specification has also been expanded beyond what is needed or reasonable (e.g. WCMP, WDP). Again, the WAP designers justify all this re-invention and expansion of scope on the grounds that wireless mobile devices present a unique special case, requiring a completely new set of protocols. In fact there is nothing specific to wireless applications which justifies this exhaustive degree of re-invention.
In his paper Attacks against the WAP WTLS Protocol [52], author Saarinen describes in detail a number of security problems with WTLS. Here we provide a brief summary of the problems and their cause.
Although the WTLS protocol is closely modeled on the well-studied TLS protocol, a number of security problems have been identified with WTLS. These problems include: vulnerability to datagram truncation attack, message forgery attack, and a key-search shortcut for some exportable keys.
Most of the text in the WTLS specification has been adopted, word for word, from the TLS specification. However, many of the changes that were made by WAP Forum have led to security problems.
This is another case of the WAP Forum's deliberate deviation from the mainstream of the Internet causing difficulties.
As Khare discusses in greater detail [86], WAP's port numbering strategy is another example of botched reference-by-copy. Instead of obtaining legitimate WAP ports in the IANA-registered space, WAP uses the temporary private port space in the range of 49152 to 49159. In addition to the port numbers, TLS ciphersuite codes and HTTP methods were also not registered with IANA. Instead, the WAP Forum has created its own parallel IANA equivalent called WINA.
This is another case of WAP Forum's deliberate deviation from the mainstream of the Internet in the name of wireless, and for the purpose of maintaining control.
Beyond its procedural and technical flaws, we believe that WAP represents a fundamental misconception of what can feasibly be accomplished using cell phones, and what actual users are going to want to do with their phones.
Mobile Messaging, and Mobile Web Browsing, represent two very different forms of mobile communications activity. Mobile Messaging refers to the ability to send and receive personally directed messages, while Mobile Web Browsing refers to general information retrieval from anywhere.
Both of these bring undoubted value to the user, both can be accomplished on a cell phone, and the mobile user of tomorrow will certainly indulge in both activities. However, the value that the two activities bring to the user, and the suitability of the two activities to the cell phone, are very different.
Mobile Messaging allows important and/or time-critical information, which may require the user's immediate attention, to be pushed to him/her quickly. This is something which is of inherent and compelling value to the off-line, mobile user. By contrast, the desire of the mobile user to go back on-line for web access rarely has the same importance or urgency.
A basic question is: which of these two mobile applications represents the best initial value? We believe that Mobile Messaging is the right answer for initial mobile applications development.
The basic goal of the WAP specification is to allow Internet web browsing using mobile phones. The assumptions underlying this goal are, first, that web browsing capability can be adequately accomplished on a mobile phone, and second, that this is something that will be of significant value to mobile phone users.
However, we believe that neither of these assumptions is correct. First, the cell phone of today is a totally inappropriate device for the purpose of accessing the mature Internet. Not only is the cell phone user interface completely inadequate for general web page display, but the wireless network medium also imposes severe limitations on the speed, immediacy, and reliability of web page access. It is simply not practical to surf the web using today's four-line text displays, over a slow, congested network with unreliable coverage.
As Kevin Maney observes in his article Cell phones let the Web 'go mobile' [51]
``Web phones can be slow and frustrating. Click on The Weather Channel, for example, and the phone takes 6 or 7 seconds to send the request through the Sprint wireless network, into the Internet and to The Weather Channel's WAP-enabled Web server, then get back the next menu. On that menu, click ``cities,'' then wait a few more seconds before getting a request to enter a ZIP code. You do that using the phone keypad. A few seconds later, you get the report. Only about 10-15 words fit on the screen at one time. You scroll down to read it.''
It can be argued that future improvements in display technology may act to alleviate these difficulties, and this may very well be the case. However, the need for convenient portability of ``unconscious carry'' communications devices such as cell phones and pagers exerts tremendous design force towards reducing the size of these devices. The effect of this force is plainly apparent in the current trend towards extreme miniaturization of cell phones.
The design force towards miniaturization is something which is in direct opposition to display capability. For this reason, we believe that unconscious carry devices will continue to have severely limited display capabilities.
Second, there is the question of what people are actually going to do with the brand new medium of wireless data communications. How, and in what forms, will this medium become part of society? In ten years time we may have the answer, but today, nobody knows.
Of all forms of risk, prediction is the most gratuitous - yet none of us seems able to resist it. WAP's answer is that mobile web browsing will be enthusiastically embraced by society, and that it will be done via the cell phone device.
Our answer is that we doubt it. People will do things on a mobile basis that make sense to do while mobile - they will access the information that is most useful to them while away from the home or office. This includes such things as urgent e-mail messages, and highly specific urgent and important information. But it does not include general-purpose web browsing.
Web browsing is an interactive activity, for which the user requires a near real-time response. Furthermore, browsing, as the word indicates, is not an activity that has any urgency, and is therefore not something that there is a compelling reason to do while mobile. For both of these reasons, we believe that people will continue to do their web browsing at the home or office, and that web browsing will remain a marginal component of mobile communications.
It is true that the prospect of mobile Internet access has created tremendous excitement in the marketplace. And there is something magical about putting a cell phone in someone's hand, and providing a demonstration of live mobile Internet access. But the enchantment that this creates in the user stems from its technological novelty, not from its enduring day-to-day usefulness.
This is not to say that all Internet data access is without value to the user. On the contrary, consumers certainly will use their mobile phones for Internet data access. However, the nature and types of data they will access will be appropriate to the medium.
They will access data that they have a need for and can use while mobile, that does not require near-synchronous system interaction, and that can conveniently be accessed via a mobile device.
The single application that satisfies these criteria better than any other is mobile messaging, or e-mail. Interpersonal messaging has already become an indispensable aspect of modern life, and is now the dominant application for the fixed Internet. We believe that society will adopt mobile messaging with the same enthusiasm as conventional e-mail, and that it will achieve similar dominance on the wireless Internet.
There is presently an enormous amount of hype surrounding WAP. The WAP proponents have hyped its abilities far beyond what the consumer will actually be able to do with his or her cell phone.
There is a general perception that WAP will essentially put the entire Internet into the hands of the cell phone user. It is understood that a good deal of the form of a website may be lost in translation to the cell phone, though its basic textual content will be preserved. Beyond this, however, there is a perception that any website can be accessed in this way; i.e. that WAP will make the entire Internet content accessible via cell phone, just as it currently is via a conventional ISP.
However, this is not the case. WAP provides access to websites by translating the HTML coding of web pages into something that a cell phone can understand and display. What this means is that in order to get information from a website, the site must have a WAP-enabled server, and the server must be programmed to extract the website content that can be displayed on the miniature cell phone screen. In other words, if your favorite website is not WAP-enabled, you probably will not be able to access it through your cell phone.
For this reason, the tremendous hype surrounding WAP has yet to be backed up by commercially available WAP products and services. As Antony Bruno comments in his article Market gap producing WAP alternatives [19]
``A running joke among industry players has the WAP acronym meaning Where Are the Phones?''
WAP phones and services are not available in the marketplace, because the promises of WAP are simply not real.
The WAP specification is being promoted by the WAP Forum as a general-purpose wireless protocol, suitable for a wide variety of end-user devices, including PDAs such as PalmPilot. As noted in Section 10.3.1, however, WAP is in fact highly phone-centric - it is strongly oriented towards the mobile telephone physical device, despite the WAP Forum's claims of device-independence.
We note in passing that during the time that it was promoting the general-purpose nature of WAP, Unwired Planet, a founding member of the WAP Forum, changed its name to Phone.com. There are, of course, many good reasons why a company might wish to change its name. It strikes us as ironic, however, that while promoting the device-independence of WAP, this founding WAP Forum member abandoned a device-independent name in favor of a device-dependent one.
The WAP Forum claims to bring web browsing capability to the cell phone. However, the cell phone device is simply not equal to this task. Because of the user interface limitations of the cell phone - its very small screen and limited keypad - the resulting web browsing experience is clumsy and impractical.
Furthermore, use of the WAP specification to access web content requires the use of WAP gateways, which translate the WAP-enabled website content into a format which the end-user can access. These gateways are controlled by the Service Provider (typically the wireless phone service provider), not the information provider. This usage model is very much contrary to the existing Internet usage model, in which the Service Provider plays the role of an entirely passive intermediary between the website provider and the website reader. In other words the Service Provider functions purely as a pipe. In this model new website content becomes immediately available to all Internet users as soon as it is created by the website provider. This unrestricted connection between the creators and consumers of Internet content has been one of the keys to its extraordinary growth and vitality. Because of this open characteristic the Internet has been able to grow organically - i.e. spontaneously, autonomously, and without planning, control, or approval by any central authority.
In the WAP model, by contrast, the WAP gateway operated by the Service Provider plays the active role of translating and storing web content, and therefore controls access to the content by the end-user. New websites and new web content do not become available to the end-user without the active participation of the Service Provider. This places a layer of control and authority between the creator and consumer of website content, greatly diminishing the potential for unrestricted and organic growth of the Internet.
The premise of providing access to important information through a cell phone is certainly valid. As noted above, however, the nature and quantity of information that in practical terms can be delivered via a cell phone is severely constrained by the device itself.
The nature and quantity of information that can be delivered is sufficiently heavily constrained, that it can be adequately delivered using existing technologies.
The equivalent of most, if not all, of what WAP promises to deliver on a cell phone can very reasonably be accomplished using existing and already widespread technologies such as SMS. Indeed, this is already being accomplished today. Various companies, including Xypoint, AmikaNow!, Roku, ThinAirApps and Microsoft, are already providing services equivalent to WAP's claimed functionality. This is being done using existing cell phones and existing cellular services. For more information, and a more complete list of companies providing such services, see [19].
The screen user interface limitations of a cell phone are so severe, in fact, that its data access capabilities are almost always better served by its voice interface - with which, of course, all cell phones come equipped.
The genuine utility of WAP on a cell phone resides in those applications for which a visual data interface is superior to a voice interface - that is, in those applications for which screen and keypad are better suited than speaker and microphone. Given the limitations of the cell phone screen and keypad, however, this is an extremely narrow range of applications. In other words, if all you have is a tiny screen and a miniature keypad, then in most cases you are better off using the voice interface.
Use of the voice interface to access important or time-critical information is already fairly widespread. The implementation of increasingly reliable speech recognition and powerful text-to-speech systems can be expected to make data transfer via the voice interface even more convenient.
We have no argument with the notion that a world-wide standard is needed to address the requirements of wireless data applications. However, we believe that WAP is utterly unfit for this purpose. As we have shown in this article, WAP is the result of a closed design process within a members-only club. It remains tightly controlled by the WAP Forum, is crippled by patents, and is riddled with technical design errors. In the long run WAP is doomed to failure. In the short run it can only do harm to the industry and the consumer.
All of this could be the result of a series of colossal blunders by a well-meaning but spectacularly incompetent industry association. However, we do not believe that this is the case. We do not believe that the WAP Forum is well-meaning; on the contrary, we believe that their fundamental motivations are crass financial self-interest, coming at the expense of engineering and business integrity.
The WAP Forum could easily have taken steps to eliminate every one of the criticisms we have leveled against it, yet they have not done so. We invite them to tell us why.
The WAP Forum claim that WAP is an extension of the Internet, and is part of the Internet mainstream. Yet in no way has the development of WAP been consistent with Internet conventions. The specification could have been designed by an open design process, by the straightforward expedient of establishing open working groups and public mailing lists. There is ample precedent for this in the history of Internet protocol development. Yet the WAP Forum has not done so. Why not?
The WAP Forum could have ensured free and permanent availability of the specification by publishing them as RFCs, the mainstream method of publishing Internet protocols, and supported by extensive precedent. Again, they have not done so. Why not?
The WAP Forum could have worked diligently towards the goal of a patent-free protocol, by means of processes with well-understood industry precedent. Once more, they have not done so. Why not?
We can come to only one conclusion: WAP was designed to create unfair market advantage for its developers from the outset. They have maintained strict and close control of the protocol from the beginning, in complete violation of Internet conventions. The WAP Forum members have knowingly and deliberately incorporated their own patents within the specifications, and now are demanding royalties.
We can think of no better way to characterize such a process than as a trap. WAP is far from being an enabling force in the wireless industry. On the contrary, it is a gigantic and poorly-designed red herring created by narrow business self-interests. It is not a genuine engineering construct; it is a bogus marketing one.
A recent quotation from Greg Williams, Chairman of the WAP Forum, provides an excellent illustration of the WAP Forum's preference for members-only processes. Commenting on the recent highly public Geoworks patent infringement claim, he says [24],
``Companies in the WAP Forum generally settle licensing and cross-licensing deals between themselves.''
What can be done to prevent the spread of WAP? There are several possible steps that in principle could be taken:
One possibility would be to work with the WAP Forum - to engage them in a dialogue, and try to persuade them to correct the procedural problems described in Section 10.2. Among other things, this would require that they establish an open working group for maintenance of the protocol, initiate RFC publication of the protocol, and make every effort to lift all patent restrictions from the protocol.
However, this would amount to a complete reversal of the WAP Forum's mission and values, and it is naive to imagine that this is possible. At this point, we regard the WAP Forum as being beyond redemption.
This also leaves aside the question of what to do about the technical deficiencies of WAP - even with the WAP Forum's complete cooperation, a major effort would be required to create a sound engineering solution. Working to reform the WAP Forum, therefore, is not a useful approach.
Given that we can expect no help from the WAP Forum, the most useful thing that can be done quickly and easily is to spread the word about WAP. It is for this purpose that this exposé has been written.
Please join us in letting it be widely known that WAP is a trap. You may freely make and distribute copies of this article, provided the copyright and permission notices are preserved. You are encouraged to bring this article to the attention of the appropriate persons within your organization.
Rejecting WAP at engineering level means working to prevent WAP from being adopted in the design of devices and systems. This is primarily the responsibility of the engineering community within the wireless industry.
It is the responsibility of design engineers to evaluate the controversy surrounding WAP, and decide for themselves whether or not it is a sound engineering solution. If as an engineer you decide that it is not, then we encourage you to inform your manager of this, justify your position on technical grounds, and recommend alternatives.
To provide support for this, the Free Protocols Foundation maintains a set of informational resources on its website at http://www.freeprotocols.org/harmOfWap/main.html. These resources include references to various other papers and articles which corroborate the fraudulence of WAP. Please feel free to use these materials in any way you wish. We also invite you to contribute to the information pool at the Free Protocols Foundation - any comments, articles or other information may be submitted to the FPF via our website.
Rejecting WAP at consumer level means encouraging the end-users of hand-held wireless devices to refuse to purchase WAP devices - in other words, to boycott these devices.
However, the WAP question is a very complex technical and business issue, and it is not easy to convince the consumer that this is something worth caring about. A successful boycott requires an immediate, gut-level understanding of the issues on the part of the consumer. The WAP issue is not something that can easily be condensed into a ten-second sound bite.
In any case, WAP is not sufficiently widespread for a boycott to be effective. For these reasons we do not consider a consumer boycott to be a useful approach at this point. For the moment, WAP must be dealt with by the industry, not the consumer.
Regardless of the shortcomings of WAP, the fact remains that at some point the wireless industry must agree upon a standard protocol for efficient data communications. Ultimately, therefore, WAP can be displaced only by the adoption of a suitable alternative.
One traditional source of Internet protocols is the Internet Engineering Task Force, or IETF. To our knowledge, however, the IETF does not currently have a working group assigned to this task, and so no protocol can be expected from them in the near future. Even if the IETF were to assign a working group to this immediately, it typically takes 18 months to achieve a workable first-draft protocol. This time frame is far too long to address the industry's immediately pressing need.
Other traditional sources of protocols are private industry, and the academic community. However, thus far a suitable protocol has been forthcoming from neither of these sources. Although there is general consensus within the industry that an alternative protocol to WAP is desperately needed, no such protocol has yet been publicly proposed.
In this article, we would like to be the first to present an alternative: LEAP, the Lightweight and Efficient Application Protocol. LEAP is immediately available, and has all the characteristics required to displace WAP and become the basis of an industry standard. A brief description of LEAP is provided in the following section.
To the best of our knowledge, LEAP is the only viable alternative to WAP. However, we invite readers of this article to seek out and bring to our attention any other alternatives that may exist. At the Free Protocols Foundation, we are ready to support and publicize any viable, patent-free alternative to WAP that is made known to us. Such alternative protocols will be referenced at the FPF website at http://www.FreeProtocols.org, and included in future revisions of this article.
In summary, the best ways to prevent the harm of WAP are to spread the word, reject WAP at engineering level, and adopt alternatives. We encourage readers of this article to join us in opposing WAP in all of these ways.
Fortunately, an alternative to WAP exists: LEAP, the Lightweight and Efficient Application Protocol. LEAP consists of a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. LEAP presently includes the following component protocols:
Open source implementations of the ESRO and EMSD protocols are being made available as free software at: http://www.MailMeAnywhere.org/.
The LEAP protocols, in combination with existing Internet protocols, properly address the same set of requirements that WAP claims to address. They have all the preferred protocol characteristics described in Section 10.1.2. They are published as Internet RFCs, are publicly maintained, and suffer from none of the technical deficiencies ascribed to the WAP specifications. In addition, the LEAP protocols fully conform to the patent-free policies and procedures of the Free Protocols Foundation [63].
A comparison of LEAP to WAP, and justification of LEAP as the basis of an industry standard, is provided in LEAP: One Alternative To WAP [64], a companion article to this one. This article is available at the Free Protocols Foundation website at http://www.FreeProtocols.org.
A complete and detailed description of LEAP is provided in The LEAP Manifesto [65], available at the LEAP Forum website at http://www.LeapForum.org.
Anyone interested in participating in the development of the LEAP protocols is invited to join the mailing lists hosted at the above-mentioned websites. LEAP's development process is truly open and non-exclusive. There are no membership fees. Participation in the LEAP development process requires only that you commit to the patent-free intent of LEAP and the Free Protocols Foundation.
Over the last few years, data communications has expanded dramatically and forcefully into the wireless environment. A major new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality has placed 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.
Existing Internet protocols do not adequately meet these requirements. Therefore a new generation of efficient protocols is needed, to satisfy the demands of wireless applications. At some point, the wireless data communications industry must agree on a single set of protocols that satisfies its requirements.
In April 1998, a business association called the WAP Forum published the Wireless Application Protocol, or WAP. WAP is a set of specifications for wireless data communications using hand-held devices such as mobile phones and palmtop computers. The WAP specification provides the users of these devices with mobile data communications capabilities such as web-browsing and e-mail.
The WAP specification purports to be an open, license-free protocol that will unify and promote the growth of the wireless industry. The WAP Forum claims that the WAP specification satisfies all the requirements necessary to become the industry standard, and is aggressively promoting it as such.
In a previous article entitled The WAP Trap [66], however, we have argued that WAP is utterly unfit for its claimed purpose. In that article we described the desirable characteristics of enduring, industry-building protocols, and we demonstrated that the WAP protocols lack all of them.
Among other things we showed that WAP is the result of a closed design process within a members-only club, that it remains tightly controlled by the WAP Forum, is crippled by patent restrictions, and is riddled with technical design errors.
Our conclusion was that the WAP specification is not a genuine engineering construct; it is a bogus marketing one. Its purpose is to create unfair market advantage and bring short-term financial gain to its developers, rather than to provide long-term benefit to the industry at large and the consumer. Far from being an enabling force in the wireless industry, WAP is a poorly-designed red herring created by narrow business self-interests.
In the long run WAP cannot survive as a viable solution. In the short run, however, it can do considerable harm to the industry and the consumer.
In The WAP Trap we went on to discuss the steps that can be taken to prevent this harm. A crucial step will be for the industry to adopt an alternative to WAP as soon as possible. We concluded the article by presenting one alternative: LEAP, the Lightweight & Efficient Application Protocols.
In the present article, we will carry on where the previous article left off. The scope of The WAP Trap was limited to a critique of WAP, without actively promoting any particular alternative. The present article, on the other hand, is frankly partisan; our purpose here is to promote LEAP as an open alternative to WAP.
The authors of this article are participants in Free Protocols Foundation (FPF) activities, under whose auspices this article is being written. The mission of the FPF is to provide support for the development, maintenance, and promotion of patent-free protocols and software. It provides a forum in which developers can declare publicly that the protocols and/or software they have developed are intended to be patent-free, and that it is their intention to keep them permanently patent-free.
In addition, where the existence of patented components within protocols and/or software threatens their unrestricted usage and implementation, the FPF supports the promotion of patent-free alternative protocols and/or software. It is for this purpose that the current article is being written: to promote LEAP as a patent-free alternative to WAP.
In this article we will describe LEAP from both a technical and a procedural point of view. We will compare it to WAP, and will demonstrate that it has all the desired protocol characteristics that WAP lacks. Our conclusion will be that LEAP is destined to play a key role in the growth of the Mobile Messaging industry.
This article is one of several 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. Related articles are:
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.
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.
Thus far, professional protocol and standards producing associations, most notably represented by the IETF, have failed to produce an acceptable specification. The IETF continues to represent the tradition of simple protocols, a tradition which wireless communications has now made obsolete. Unfortunately, the IETF remains rooted in this tradition, and has not adapted to the new realities of wireless communications. Until it does so, the IETF will remain ineffective as a protocols and standards body. In the area of efficient protocols, the IETF is simply bankrupt.
It is now time for a new generation of protocols to be implemented, designed to address the need for performance, rather than simplicity.
The Lightweight & Efficient Application Protocols, or LEAP, are designed precisely to address this need. LEAP is the general framework for a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. LEAP is designed to address the technical requirements of the wireless data communications industry, and is oriented towards providing the greatest benefit to the industry and the consumer.
The LEAP protocols are patent-free, and open-source implementations of the protocols are being made available for a variety of devices and message-center platforms. The protocols are thus ready and available, and can be quickly distributed and implemented as a viable alternative to WAP.
LEAP originated in 1994 as part of the research and development initiatives of McCaw Cellular's wireless data group (now AT&T Wireless). 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 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.
In this section we will provide a brief technical overview of the LEAP
protocols. For a detailed description of LEAP, refer to The LEAP
Manifesto
[65], available at
http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.
html.
LEAP is a set of wireless application protocols that are optimized for delivering small messages over wireless networks. 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 a high premium on the efficiency of data transfer.
The LEAP protocols are up to five time more efficient than the ubiquitous SMTP e-mail messaging protocols. This increased efficiency translates into longer battery life for mobile phones, PDAs and other wireless Internet devices.
The LEAP protocols are layered. The lower layer, called Efficient Short Remote Operations (ESRO), provides reliable connectionless transport services which can be used for a variety of applications. For example, in addition to mobile messaging services, ESRO can be used as a transport service for credit card verification applications and efficient micro browsers. On top of ESRO is the layer called EMSD. EMSD is a messaging protocol that is highly optimized for the submission and delivery of short Internet e-mail messages.
Various other LEAP protocol components are in the process of being designed and implemented. See The Future of LEAP article in The LEAP Manifesto for more details.
All efficient applications have the requirement for an efficient transport mechanism. For this reason, the initial focus of the 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 a reliable connectionless transport mechanism, forming the foundation for the development of efficient protocols when TCP is too much and UDP is too little.
ESRO was published in September 1997 as Internet RFC-2188 [91]. Additional information about ESRO is available at http://www.esro.org/
The Efficient Mail Submission and Delivery (EMSD) protocol is built on top of ESRO, and is designed to address the Mobile Messaging application. EMSD provides for the submission and delivery of short (4 kilobytes or less) Internet e-mail messages. EMSD meets or exceeds the level of functionality, reliability and security provided by the existing SMTP protocols. EMSD is a great deal more efficient than existing Internet e-mail protocols.
EMSD was published in March 1999 as Internet RFC-2524 [5]. Additional information about EMSD is available at http://www.emsd.org/
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. The initial LEAP protocols, however, are designed to support the Mobile Messaging application, since this is the dominant application for wide-area wireless networks. Subsequent LEAP protocols are expected to address other applications as necessary.
We believe that a public protocol must conform to each of the following basic, fundamental principles:
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 Working Groups 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.
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.
Complete details of the LEAP development process are provided in a separate article within The LEAP Manifesto entitled The LEAP Protocol Development Model. The major aspects of the development process are summarized in the following sections.
As discussed in The WAP Trap, a highly desirable attribute of an industry standard protocol is that it be free from patents. The presence of patented components within a protocol undermines the ultimate purpose of the protocol: its unrestricted adoption and usage.
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.
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.
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. The only requirement is that participants must adhere to the principles and procedures of the Free Protocols Foundation, thus ensuring that the protocols remain permanently patent-free.
In The WAP Trap, we enumerated the characteristics of the WAP specifications that make them wholly unfit to play the role of an enabling industry protocol. These characteristics are summarized in Table 11.1, along with the corresponding characteristics of the LEAP protocols.
|
As noted in The WAP Trap, the WAP specifications include patented components. Unlike WAP, the LEAP protocols are entirely patent-free.
As noted previously, the LEAP protocols are published as Internet RFCs, ensuring permanent, unrestricted availability of the protocols. The WAP specifications, on the other hand, are self-published by the WAP Forum, and therefore do not carry the same assurances of unrestricted availability. The availability and permanence of the WAP specifications is only as good as that of the WAP Forum itself.
Furthermore, in order to download any particular WAP specification, a user must agree to a license agreement. By contrast, the LEAP protocols may be downloaded and distributed without any restrictions.
In addition, the WAP Forum's publishing philosophy carries no guarantee of stability. As of February 2000, each WAP specification carries on its title page the disclaimer, ``This document is subject to change without notice.'' By virtue of the RFC publication process, on the other hand, individual revisions of the LEAP protocols are permanently fixed.
LEAP's open maintenance processes are also in sharp contrast to WAP. Participation in the development of the WAP specifications requires payment of the $27,000 WAP Forum membership fee (as of February 2000), and takes place entirely behind closed doors. Unlike WAP, the LEAP protocols are maintained by public maintenance organizations in which anyone is free to participate.
The WAP protocols also include numerous technical deficiencies. For example, WAP is a broad-scope re-invention of existing protocols. The LEAP protocols, by contrast, consist of a small number of independent protocols that complement existing Internet protocols. Other WAP deficiencies are listed in Table 11.1; for a detailed discussion, see The WAP Trap.
There are also significant conceptual differences between LEAP and WAP, of which we will mention two here. First, LEAP is primarily oriented towards the mobile messaging (i.e. e-mail) application, whereas WAP is primarily oriented towards mobile web browsing. We believe that this represents a serious misunderstanding of the mobile data communications industry on the part of the WAP Forum. Hand-held mobile devices are extremely well-suited to the e-mail application, whereas their severe user interface limitations render them highly ill-suited to web browsing.
Second, LEAP and WAP take very different approaches to the messaging application. The LEAP approach, embodied in the EMSD protocol, is a complete and efficient submission and delivery model. The WAP approach, on the other hand, is a mailbox access and selective message retrieval model.
A consequence of this is that the WAP protocol has several unresolved issues relating to message delivery. For example, the WAP protocol does not support the ``push'' model of message delivery, in which time-critical messages are actively delivered to the recipient. The LEAP protocol, by contrast, fully supports the ``push'' model.
So the early history is known, and the eventual history we can predict with confidence. But what about the more immediate future? Our view is that, largely thanks to the WAP Forum, the industry has been significantly over-hyped, with the result that expectations now greatly exceed realities. Our prediction is that this period of soaring expectation will be followed by a period of general disillusionment and frustration, as these expectations are inevitably disappointed.
Sooner or later the industry must adopt a more realistic understanding of its technological and business challenges. Part of this understanding will consist of the recognition that the wireless industry must adopt a single set of truly open protocols. Only then will the industry be able to undergo stable and sustained growth.
WAP represents the era of hype and disillusionment. LEAP represents the era of realism and maturity.
Thus far our discussion has been entirely theoretical; we have demonstrated on paper that WAP is not viable, and that LEAP has all the characteristics necessary to be considered a viable alternative. However this is all academic until the protocols are implemented as software and deployed in real world systems.
In order for the LEAP protocols to become widely used, they must be implemented in the form of software solutions that are readily available for deployment by end-users. To this end, we have created software implementations of the protocols for most common platforms. Protocol engines have been implemented in the form of portable code which has been ported to a variety of platforms. On the device side, software has been implemented for pagers and cell-phones; for hand-held PCs and Palm Pilot (Palm OS, Windows CE, Palm PC); for Windows 98, Windows 95, and Windows NT; and for Pine (UNIX, Windows, DOS). On the message center side, software has been implemented for Solaris, Linux and NT.
All of this software will be made publicly available in the form of free software in open-source format. At present, we have created the structures necessary to allow ready access and downloading of the software in binary form. Foundation libraries of LEAP protocol engines called the ``Open C Platform (OCP)'' are subject to the GNU Library General Public License and are available as open-source software.
The software 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. We expect the availability of the entire suite of open-source software implementations described above to be completed by December 2000.
As noted above, the initial emphasis of LEAP is on the mobile messaging application. Protocol engines are only a single component of a bigger picture; in order to provide complete solutions to the user it is necessary to integrate these protocols into other existing pieces of software. Fully-integrated solutions which combine LEAP with other open-source and free software packages such as qmail, sendmail, fetchmail will also be made available.
We invite those interested in using, enhancing, porting and integrating this software to join the relevant mailing lists at http://www.MailMeAnywhere.org/
We will also initially ``prime the pump'' by providing free subscriber services through ByNumber.net and ByName.net. This will provide initial support for the implementation of the protocols in 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.
In this article we have promoted LEAP as one alternative to WAP. An obvious question is: Are there any other alternatives?
A traditional source of Internet protocols is the Internet Engineering Task Force, or IETF. To our knowledge, however, the IETF does not currently have a working group assigned to this task, and so no protocol specification which addresses the requirements for efficient Mobile Messaging can be expected from them in the near future. Even if the IETF were to assign a working group to this immediately, it typically takes 18 months to achieve a workable first-draft protocol. This time frame is far too long to address the industry's immediately pressing need.
Other traditional sources of protocols are private industry, and the academic community. However, thus far a suitable protocol has been forthcoming from neither of these sources. There is general consensus within the industry that an alternative protocol to WAP is required. Apart from LEAP, however, no such protocol has yet been publicly proposed.
To the best of our knowledge, therefore, LEAP is the only viable open and patent-free alternative to WAP.
All of the basic components that are needed to launch LEAP are complete, in place, and ready to go. These components are:
Together, these components represent a complete recipe for the success of LEAP. The protocols themselves are open and immediately available, and open-source implementations of the protocols are in the process of being made available as free software.
The combination of free protocols and open-source software is something which has enormous power. It is this combination of factors which has driven the overwhelming success of other industry standards such as Linux and the Web (HTTP/HTML). We believe that this same combination of factors will drive the acceptance of LEAP in the wireless data communications industry.
Finally, we do not claim that LEAP is technically ideal - like all engineering solutions it includes compromises. What we do claim is that LEAP is a good solution, and that its processes have integrity. Where the LEAP protocols fall short of the industry needs, the open maintenance processes will provide a mechanism by which they can evolve into a better solution.
Every aspect of LEAP is described in The LEAP Manifesto
[65], available at
http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.
html.
The LEAP Manifesto includes a technical description of the LEAP
protocols themselves, and a description of all the components required
to encourage their widespread usage. The LEAP Manifesto
consists of the following articles:
We first published the article The WAP Trap: An Exposé of the Wireless Application Protocol [66] in April 2000. At that time it was the most comprehensive condemnation of WAP written to date. In it we demonstrated that WAP is crippled by patents, the result of a closed design process, inappropriately controlled by the WAP Forum, and riddled with technical design errors. We exposed WAP for what it is: a fraudulent marketing construct. Our conclusion was that WAP must be rejected and replaced with a set of truly open, patent-free, technically sound, mainstream Internet protocols.
In April 2000 we were one of a relatively small number of voices sounding the WAP alarm. At that time WAP was massively over-hyped, and a major portion of the wireless industry had succumbed to the hype. To use a phrase right out of the WAP hype machine: WAP was hot.
But in September 2001, 17 months after initial publication of The WAP Trap, our analysis and predictions have been convincingly validated.
The message in The WAP Trap resonated within the industry, and it has experienced widespread distribution and readership. Partly because of this, there is now a growing awareness of the fundamental fraudulence of WAP. The engineering community was never seriously taken in by WAP in the first place, and our raising of the alarm has had the desired effect among the business and media communities. Numerous articles have been published which support our position, including:
The body of published articles includes several which quote us
directly or otherwise build on our work. The above articles and others
are available on the Free Protocols Foundation website at
http://www.FreeProtocols.org/harmOfWap/main.html.
We will continue to augment the Free Protocols Foundation library with additional relevant articles as
they appear.
In addition, The WAP Trap has now been translated into French, under the title Le WAP a la Trappe. The translation of The WAP Trap into French represents another step forward in our campaign to expose WAP. Both English and French versions of the paper are available in HTML, PDF and PostScript formats on the Free Protocols Foundation website at http://www.FreeProtocols.org/wapTrap/index.html.
Though the tide of favor has turned against it, the WAP hype machine continues to operate. And there remain many within the industry who are still unaware of the problems with WAP. We will continue to counter the WAP hype by writing and distributing articles such as The WAP Trap and WAP Scraps.
However, the primary purpose of this article is not just to say NO to WAP. This article focuses on what needs to be done after WAP.
As we discussed in The WAP Trap, WAP has many shortcomings. But one of the major issues from a consumer-acceptance point of view is that it represents the wrong starting-point wireless Internet application. Though wireless web browsing certainly has its place, its end-user value proposition is entirely overshadowed by that of another wireless Internet application: Mobile Messaging.
This statement is fully supported by the user experiences and market acceptance of these two applications. The extremely poor end-user experience of WAP-based web browsing is very well documented in the Nielsen Norman Group field study report WAP Usability: Deja Vu: 1994 All Over Again [81]. By contrast, the end-user value of Mobile Messaging is well evidenced by the market acceptance of BlackBerry and other messaging systems, which are enjoying widespread popularity.
BlackBerry and other Mobile Messaging solutions are experiencing this popularity despite the fact that they are all closed, proprietary systems. In order for the Mobile Messaging industry to reach its full potential, these closed systems must be replaced by an open industry model, based on truly open and free protocols. All the components required to enable this, including the necessary open protocols, are now in place; and the development of the open Mobile Messaging industry is now assured. For a detailed discussion of the open Mobile Messaging industry, see the Manifesto article Operation WhiteBerry [8].
As in the case of Mobile Messaging, an open industry model is essential in order for the Mobile Web Browsing industry to reach its full potential. With the open Mobile Messaging industry well on its way, it is now time to focus attention on the development of the open Mobile Web Browsing industry.
This paper is a follow-on paper to The WAP Trap. Both papers are endorsed by and published by the Free Protocols Foundation (FPF). The FPF is an independent public forum dedicated to the support of patent-free protocols and software. The FPF regards protocol and software patents as being highly detrimental to the industry and the consumer, and part of the FPF mandate is to oppose exceptionally harmful patents and patented protocols when they appear. One such patented protocol is WAP.
The FPF is a U.S. non-profit organization, and is tax-exempt under Section 501(c)(3) of the Internal Revenue Service regulations. All monetary contributions made to the FPF are tax deductible in accordance with these regulations. Any organization or individual wishing to support the goals of the FPF is encouraged to participate by joining the FPF mailing list, or by making an appropriate donation. For more information see the FPF website at http://www.freeprotocols.org.
One of the ways in which the FPF opposes patented protocols is by supporting and endorsing patent-free alternative protocols. This paper describes how WAP can be avoided by use of patent-free alternatives, and is therefore fully consistent with this mission. The purpose of this paper is to describe the development of the open Mobile Web Browsing industry. In particular, we will:
We gratefully acknowledge the assistance of the following persons in the preparation and review of this document: Andrew Hammoude and Pinneke Tjandana.
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. As noted above, part of the FPF mandate is to provide support for patent-free alternatives to patented protocols such as WAP. It is in the spirit of this mandate that this article is being written.
The basic problem that WAP purports to address is very real: that of providing website access from a cell phone. (More generally, the central web browsing problem is that of providing website access from miniaturized devices in general, including PDAs, pagers, etc. WAP is heavily oriented towards the cell phone in particular; however the required industry solution must address miniaturized devices in general.) A particular website may be very full-featured, including rich content which cannot be displayed on the limited cell phone display. In order for the phone to provide meaningful presentation of this website, an appropriate subset of the website content must be extracted and downloaded to the phone.
There is nothing bogus about this problem - only about the way WAP has gone about solving it. A key architectural component of the WAP solution is the WAP Gateway, which stands between the cell phone and the website, and which actively participates in the data extraction/download process. The catastrophic problem with this is that it totally violates the Internet End-to-End principle - the gateway is now interposed as an active authority between the client and the website.
Clearly, the WAP Gateway exists for business reasons, not engineering ones. Control of the gateway, together with control of the cell phone WAP software which can preferentially direct end-users to one gateway rather than another, creates enormous business opportunities for the gateway operator. This is the fundamental raison d'etre of the WAP Gateway; and everthing else in the WAP model, including the protocols themselves, falls secondary to this.
In other words, the entire WAP construct is an attempt by the wireless network operators and phone manufacturers to hijack the Mobile Web Browsing industry. If there was ever an example of the business dog wagging the engineering tail, this surely is it.
The basic motivation behind the WAP Gateway is aptly summed up in the following e-mail, posted to the IETF public mailing list by Phil Karn, an engineer at Qualcomm (itself a longtime WAP Forum member), in response to The WAP Trap. Material omitted from Mr. Karn's e-mail is indicated by ellipses; otherwise, he is quoted verbatim:
From: Phil Karn <karn@qualcomm.com>
To: public@MOHSEN.BANAN.1.BYNAME.NET
CC: ietf@ietf.org, karn@qualcomm.com
Subject: Re: WAP Is A Trap -- Reject WAP
Date: Tue, 20 Jun 2000 12:36:47 -0700 (PDT)
Message-Id: <200006201936.MAA26742@servo.qualcomm.com>
... I also scratched my head when WAP came out. It just didn't make any
technical sense. I see I'm not the only one; bravo for writing such a
good critique.
One thing missing from most block diagrams of WAP is the chute on the
bottom of the carrier's WAP gateway pouring out money. It's safe to
say that this chute is WAP's primary reason for existence.
... The Internet end-to-end model will once again prevail, putting the
cellular service providers back into their proper place as providers
of packet pipes, nothing more. And life will be good again. :-)
However, the wireless industry has now created the components required to solve the central web browsing problem the right way - and without WAP. In particular, two major developments have now rendered WAP completely irrelevant:
Figure 12.1 shows the protocol stacks for web browsing under three different implementations: the WAP architecture, an architecture based on XHTML, and an architecture based on XHTML and LEAP.
Furthermore, XHTML is an open, Internet-mainstream protocol, and conforms fully to the Internet End-to-End principle. The model of Figure 12.1(b) therefore provides Mobile Web Browsing the right way - i.e. based on a truly open industry model.
(Note: The model of Figure 12.1(b) is essentially the basis of the popular Japanese I-Mode system.)
For complete details about XHTML visit http://www.w3.org/MarkUp/. For information about W3C visit their website at http://www.w3.org/.
A disadvantage to the implementation of Figure 12.1(b) is that it requires the use of HTTP and TCP, which have serious inefficiency characteristics for the limited-size data transfer implied by miniaturized handheld devices. In the following sections we will see how the LEAP protocols can provide the required efficiency.
The implementation of Internet applications such as web browsing in the wireless arena places a very high premium on the efficiency of data transfer. Wide area wireless networks demand bandwidth efficiency; miniaturized devices demand power efficiency; and the end user demands reliability and minimum latency. The underlying wireless protocols must provide all the required efficiencies.
The claim is sometimes made that the need for efficiency in the wireless arena is a temporary one - that advances in wireless engineering technology (such as third generation (3G) systems and 802.11b[13]) will eliminate existing bandwidth limitations, obviating the need for efficient protocols. And indeed some high-speed networks have been implemented which demonstrate the capabilities of next-generation technologies.
However, thus far such implementations have been limited in scope. They have been limited to a relatively small coverage area, or they have been limited in terms of their support for active mobility - i.e. they support only static wireless devices. But the efficiency demands of wireless networks with very large coverage areas (i.e. nationwide or worldwide), and which support active, in-motion mobility, are very much greater. And despite future advances in network speed, efficiency will remain a desirable goal as long as the capacity of wide-area wireless networks remains finite.
For these reasons, efficiency will remain a crucial aspect of wireless network usage for some time to come.
Because of the very limited display capabilities of miniature handheld devices, Mobile Web Browsing of necessity involves the transfer of relatively small amounts of data. In other words, Mobile Web Browsing is an inherently limited data-size activity.
As connection-oriented protocols, HTTP and TCP are most efficient for large data transfers; however they provide very poor efficiency for short data transfers. This means that HTTP and TCP are sub-optimal protocols for Mobile Web Browsing, and the scenario of Figure 12.1(b), though open and WAP-free, is a highly inefficient implementation.
Therefore an appropriate set of protocols are required to provide the necessary efficiency; and we are proposing the LEAP protocols as candidates for this role.
The Lightweight & Efficient Application Protocols (LEAP) is a family of high-performance, efficient protocols that are ideal for mobile and wireless applications. In sharp contrast to WAP, the LEAP protocols are truly open, RFC published, and patent-free; and declarations of the patent-free nature of the protocols have been made to the Free Protocols Foundation. For a comprehensive description of the LEAP protocols see The LEAP Manifesto, available on-line at http://www.LeapForum.org/leap/.
In addition, open-source implementations of the LEAP protocols are
freely available through the MailMeAnywhere open-source software
distribution center; for details visit the MailMeAnywhere website at
http://www.MailMeAnywhere.org.
The initial focus of the LEAP protocols was on efficient Mobile Messaging, and the first two members of the LEAP family, EMSD (Efficient Mail Submission and Delivery; RFC-2524 [5]) and ESRO (Efficient Short Remote Operations; RFC-2188 [91]), were designed for this purpose. These protocols are now complete and in place, and a complete framework for the development of the open Mobile Messaging industry now exists. Given that, the focus of the LEAP Forum can move on to the next challenge: efficient web browsing.
Two members of the LEAP family of protocols are relevant to the web browsing application: ESRO and EHTD. ESRO provides reliable connectionless transport services which can be used for a variety of applications. For complete details on ESRO see the Manifesto article ESRO: A Foundation for the Development of Efficient Protocols, or visit the ESRO website at http://www.esro.org. EHTD (Efficient Hyper Text Delivery) is a hypertext transfer protocol which is optimized for the efficient transfer of short markup pages.
All the LEAP protocols are designed with a major emphasis on efficiency, and ESRO and EHTD together bring these efficiency benefits to the web browsing application. For short data transfers, EHTD is significantly more efficient than HTML, while ESRO is significantly more efficient than TCP - for example, TCP requires a minumum of 5 packets per transaction, whereas ESRO requires 2 or 3. For a detailed analysis of the efficiency of the LEAP protocols, see the Manifesto article Efficiency of EMSD [6]. That article analyses the efficiency of EMSD and ESRO specifically; however similar efficiency results can be expected in the case of EHTD and ESRO. In particular, ESRO and EHTD are highly efficient for the transfer of limited-size data, and are therefore ideal for the Mobile Web Browsing application.
Figure 12.1(c) shows how these protocols may be used in combination with XHTML and UDP [77] to provide a Mobile Web Browsing implementation that is completely open, WAP-free and efficient.
Note that the implementations of Figure 12.1(b) and Figure 12.1(c) are not mutually exclusive, but rather may be considered to be complementary. The connectionless protocol stack of Figure 12.1(c) is highly optimized for the short data transfers inherent to Mobile Web Browsing; whereas the connection-oriented stack of Figure 12.1(b) may be used for large data transfers whenever necessary.
ESRO is a complete, RFC-published protocol, for which open-source software implementations are ready and available for immediate deployment. The EHTD protocol, however, is still in its early stages of development. Those who wish to participate in the development of EHTD are invited to do so, and may do so via the LEAP Forum website at http://www.LeapForum.org.
The experience gained in the development of the WAP protocols can be of great assistance in the development of EHTD. In particular, the WAP specifications include various technical design errors, from which important lessons can be learned. In this regard the engineers who took part in the design of WAP, or who otherwise have a technical understanding of WAP, represent a particularly valuable resource. Their participation is encouraged and welcomed.
The WAP Forum has responded to the availability of XHTML by announcing WAP 2.0, which provides support for both XHTML and WML in the WAP protocol stack. This diminishes, but does not eliminate, the presence of the WAP Gateway in the WAP model. In addition, the in-place WAP 1.x architecture can claim to provide significant efficiency advantages over the connection-oriented stack of Figure 12.1(b).
However, all the other problems with WAP, detailed exhaustively in The WAP Trap and elsewhere, remain. Given the availability of truly open, Internet-mainstream alternatives, there is little remaining role for either the WAP specifications or the WAP Forum. At this point, WAP has become a salvage operation. There are three aspects to this salvage: engineering, business, and psychological.
Before throwing WAP out completely, it behooves us to examine the specifications to determine whether there is anything worthwhile that can be salvaged for incorporation or usage in the open industry models.
The general WAP architecture is shown in Figure 12.2. This figure is taken directly from the WAP specifications, and all nomenclature, acronyms etc. throughout this section are those of the WAP model. Starting from the bottom of the figure:
Since IP can be assumed to be present at Layer 3, UDP is entirely adequate at Layer 4. Therefore WDP is not needed at all, and can be scrapped completely.
Nevertheless, there may remain some worthwhile elements in WTLS. If the WAP Forum were to bring WTLS into conformity with the Internet mainstream by making patent-free declarations for it, publishing it as an RFC, and subjecting it to open review and maintenance procedures, then it may be worth examining for salvageable components.
Thus every component of the WAP protocol stack is either functionally unnecessary, made irrelevant by an open alternative, or misdesigned; with the possible exceptions of WSP and WTLS, which may have some salvage purpose.
Our analysis of the WAP stack is supported by various other studies which come to conclusions consistent with the above. A good starting point is the article W* Effect Considered Harmful [86], in which author Rohit Khare presents a detailed analysis of WAP, and demonstrates its shortcomings and ultimate non-viability.
A huge amount of money has been sunk into the WAP fiasco - a large number of wireless network operators placed their bets on WAP, and invested heavily. And the WAP infrastructure is now complete; all the pieces are built and in place. The problem is that it falls disastrously short of its expectations; and as a result few people need it, few want it, and few are using it [81]. Apart from empty hype and broken promises, the WAP Forum has little to show for its massive investment.
Under circumstances like this, people may find it difficult to halt the investment Juggernaut. WAP has a huge amount of mass and momentum - it has the mass of its enormous investment costs, and the momentum of its own hype machine. The WAP Forum members may make the mistake of believing that this investment is still worth something. They may make the mistake of believing their own hype.
But WAP is doomed, and its investment costs are now sunk costs. The only thing for the investors to do now is pull the plug on WAP and cut their losses. Continued investment in WAP represents the throwing of good money after bad, and will only result in greater bottom-line losses at the end of the day. The sooner WAP is recognized as a costly failure, the better.
Just about everybody joined the WAP Forum. The WAP Forum membership list is indeed impressive, including virtually every major player in the wireless and telecommunications industry. However, as we now know, this is not a meaningful endorsement of WAP. Rather, it is a testament to herd mentality and bet-hedging.
The arrival of XHTML and LEAP on the scene means that WAP is finished, and the WAP Forum has no significant role to play in the development of the wireless Internet industry. From this point on, the important work will no longer be taking place within closed forums such as WAP.
Given all of this, it is clear that the WAP Forum has little reason for continued existence, other than as a lame-duck organization with responsibilities that do not extend beyond face-saving activities for its members.
Much has happened in the 17 months since we first published The WAP Trap. The Internet bubble has burst catastrophically, causing the Nasdaq Composite Index to collapse from its peak of 5130 in March 2000 to around 1700 today - a staggering 67% loss of market capitalization.
And the WAP bubble has also burst. The fortunes of WAP are perhaps best represented by Openwave Systems, Inc. (formerly Phone.com, Inc.), one of the principal inventors and architects of WAP. The stock price of this company reached a peak of $208 in March 2000; at the time of writing in September 2001 it is trading at around $15 - a loss of 93%. Other WAP-related companies have experienced similar losses.
Meanwhile, the consumer has yet to see anything close to the promised ease and convenience of cell phone Internet access; and we are not aware of even a single company that has made significant profits from sales of WAP services.
WAP has been a colossal failure in financial terms. Its usage has not and cannot recoup its investment costs. Nevertheless, WAP has created fortunes for a privileged few.
The WAP business model is based on the traditional supply chain model, in which the financial and other needs of all potential gatekeepers are addressed throughout the supply chain. The creation of this supply chain has required the construction of a major infrastructure. Though this supply chain model cannot and will not work as intended, its construction has presented enormous profit-making opportunities for those in the right position.
These profits have derived from two major sources. The smaller of these consists of the profits associated with building the WAP infrastructure itself; in particular the huge development contracts that have been awarded, together with sales of WAP gateways and other equipment.
But it is the larger source that represents the truly spectacular opportunity. This opportunity has been based, not on building the WAP infrastructure, but on the fairy-tale promises and expectations that have been created alongside it. The enormous amount of hype surrounding WAP led to huge increases in stock prices and company valuations across the entire WAP industry - nowhere better represented than in the valuation of Phone.com itself.
Various WAP promoters were also investors and stockholders in key WAP companies. These investors/promoters participated actively and collectively in the hyping of WAP, drove valuations up to levels far beyond what was realistic or supportable, then sold their WAP-related stock to the public at vastly inflated prices. One could be forgiven for wondering whether the activities of the WAP promoters were intentionally directed towards this happy outcome. As the disappointing reality of WAP inevitably became clear, virtually all these inflated stock prices collapsed to less than 10% of their WAP-bubble peak, making fortunes for the investors, while leaving the public holding the empty WAP bag.
This type of activity is commonly referred to as a ``pump-and-dump'' scheme - an ugly phrase to refer to an ugly operation: the deliberate over-hyping of a stock with the intention of artificially inflating its price, then dumping it on an unsuspecting public. From the perspective of the unfortunate losers, the collective activities of the WAP insiders must be hard to distinguish from a pump-and-dump operation on a grand, industry-wide scale.
The WAP bubble was part of the more general Internet bubble, which represented the aggregate effects of a multitude of contributary bubbles similar to WAP. The WAP bubble was thus both a consequence of, and a cause of, the Internet bubble. To the extent that WAP was a consequence, the WAP promoters may shirk their responsibility for the WAP bubble. But to the extent that WAP contributed, they must then accept responsibility for the broader Internet bubble.
We have no objection to those who make fortunes on the basis of something real. Authentic entrepreneurs make fortunes by building companies which provide something of value to the consumer, and which create enduring value for their stockholders. Such people fully deserve the wealth created by their ingenuity, commitment and hard work.
Nor do we object to profitable stock trading in which no misrepresentation takes place. The stock prices of many companies were swept up and down along with the general Internet bubble; but in most cases this took place without gratuitous hyping by insiders. Those who sold near the peak made money at the expense of those who bought; but those are the breaks in the high-tech industry, and these are the risks that investors must accept.
But neither of these considerations applies to WAP. In the case of WAP little of value has been provided to the disappointed consumer, the value of company equity has been fleeting, and a minority of people have been greatly enriched at the expense of a duped majority. The WAP fortunes have been made by selling WAP-related stock at inflated prices, not by delivering WAP services to satisfied customers.
Furthermore, the WAP hype campaign continued, and still continues today, despite the fact that actual WAP usage remains dismal, and no one has ever made significant profits on the basis of WAP services. Given these facts, we find it scarcely conceivable that the WAP insiders were unaware that WAP was being hyped far beyond its reality, that stock prices were being driven to levels far beyond their sustainable value, and that they would inevitably collapse.
We are making no suggestion here that actual, prosecutable criminal fraud took place. But there can still be breach of trust, even though no law may have been broken. When we consider that the WAP model includes a gateway whose primary purpose is to generate revenue for its operator; when we consider that WAP is patented; that WAP is a shoddy engineering construction; that WAP is the pseudo-open creation of a pseudo-open forum, then we have to wonder if everything is entirely above board.
In our judgement, the activities of the WAP investors/promoters amount to fraud in all but the letter of the law. Our readers may come to their own conclusions.
Underhanded practices are a fact of life in the business world. But when such practices involve the creation of a large-scale engineering construct, and when they are based on the exploitation of vital industry protocols, this degrades the integrity of the engineering profession.
The engineering profession traditionally carries a responsibility to protect the safety and welfare of the public. An industry protocol is an engineering construct, held in public trust by the engineering community. It is the responsibility of the engineering community to defend this trust against exploitation by narrow business self-interests.
There are three fundamental principles for maintaining the integrity of public protocols [9]. These are:
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 technical engineering consensus, rather than business self-interest.
This trilogy of principles represents 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.
The creation of the WAP specifications has violated every one of these principles. The use of patents and other access-control mechanisms has been a traditional way of life in the highly business-oriented, oligarchic telecommunications industry. But the Internet industry is not like that. Openness and freedom from authority lie at the heart of the Internet, and in no small measure account for its extraordinary vitality and success. Patents and other business-oriented control devices have no place in this industry. Though WAP may try to pass itself off as an ``open Internet protocol,'' its roots in the telecommunications industry are plainly evident.
In The WAP Trap we challenged the WAP Forum either to provide valid reasons for their violation of the above principles, or to bring the WAP specifications into line with them. Seventeen months later, neither of these things has happened, and our challenge remains unanswered.
We now repeat our challenge. We challenge the WAP Forum to abandon their closed, members-only model of operation, make patent-free declarations regarding the WAP protocols, publish them as Internet RFCs, and subject them to genuine public review and maintenance procedures. By taking these steps, the WAP Forum will allow the possibility of what remains of WAP being incorporated into the mainstream Internet development model.
When first published in April 2000, The WAP Trap was well ahead of its time. At that time it represented a distinctly minority viewpoint, and seemed radical and extreme to many. Today it seems much less so.
The same may be true of this article. To the casual observer, the WAP Forum may appear to be a healthy organism, engaged in creating something important and worthwhile. WAP has not yet been fully discredited, and it may not for some time. Meanwhile, the naive or the inexperienced may find themselves impressed by the sheer scale of financial investment and engineering effort that has gone into WAP. Such observers may find themselves puzzled by, and skeptical of, our rhetoric. It may be hard to accept that something so big can be so fallacious; nevertheless, that is the fact.
In this paper we are lobbying for a Mobile Web Browsing based on a truly open industry model. By definition, WAP in its present form can play no role in such a model. Not all the things we are lobbying for will take place, and the things that do may not take place as soon as we would like. The LEAP protocols we are proposing may become part of this model, or they may not. The WAP salvage operation we are suggesting may contribute to this model, or it may not.
But the eventual outcome is clear. WAP is non-viable, and sooner or later the rest of the wireless industry will come to this realization. And at some point it will be replaced by a truly open solution.
In the meantime, we urge those engineers who have an interest in the ethics of their profession to distance themselves from WAP, because it is specious. Given a choice between WAP and something else, we encourage the engineering men and women of the wireless industry to invest their precious talents in something that has both business and engineering integrity.
The wireless data communications medium of today is struggling to define itself. It is clear that this medium is enormously important; it is also enormously complex, with major technical, societal and business consequences that no one fully understands.
Of the many questions that this new medium raises, two of the most basic are: (1) What is the most appropriate starting-point application, and (2) What is the best way to implement this application? In other words, what wireless application is of the most immediate and compelling value, and what is the most appropriate model for delivering this application?
We believe that the answers to these questions have now become clear. The right entry-point application is Mobile Messaging, and the right implementation model is an entirely open paradigm, based on open and free protocols.
Mobile Messaging is in complete harmony with the wireless medium, provides users with an incontrovertible value proposition, and has already achieved widespread market acceptance.
And a completely open paradigm is the right model for all large-scale communications systems. An open industry model provides the greatest benefit to the end user and the industry at large, by allowing free market entry and competition at any point within the Mobile Messaging solution domain. This in turn results in greatly increased business opportunities, more and better solutions for the end user, and unrestricted industry growth.
Unfortunately, these two key ideas are not well understood within the wireless industry. Numerous wireless initiatives are under way, but in all cases these are misdirected either because they are pursuing the wrong application, or because they are pursuing the right application but based on the wrong model.
As a result of this, the wireless industry of today is in a state of chaos. A large segment of the industry, most notably the WAP Forum, has mischaracterized the major entry-point application, and is pursuing wireless web browsing and other second-string applications.
Meanwhile, another industry segment is investing in the right application, but based on the wrong model. Mobile Messaging is the right application, but this industry segment is characterized by the existence of various closed, proprietary solutions such as BlackBerry and ReFLEX. The components of these competing systems do not interoperate, and they cannot build on each others assets. The result of this is the fragmentation of the Mobile Messaging market into a number of isolated islands of consumers, each committed to a particular solution and unable to take advantage of the assets of any other island.
The remedy to all this exists, in the form of a set of 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. In this article we describe how equivalent Mobile Messaging functionality to the existing closed systems can be provided, in the form of an entirely open solution based on the LEAP protocols. Our goal is to use the inherent power of truly open and free protocols to displace these closed solutions. We refer to the execution of this goal as Operation WhiteBerry.
WhiteBerry provides true Mobile Messaging, based on a set of open protocols - and therefore represents the right application and the right model. All the pieces required to implement WhiteBerry exist and are in place, and the openness of the WhiteBerry solution ensures that it will displace all existing closed solutions.
The wireless industry of today is characterized by systems which are closed, restricted, and which violate the Internet End-to-End principle. Two of these are of particular relevance:
WAP is discussed in detail in the article entitled The WAP Trap [66], while BlackBerry is discussed in the present article.
Our analyses of the WAP and BlackBerry systems are very different. As we argue in The WAP Trap, WAP is a bogus marketing construct that can bring nothing but harm to the industry and the consumer. WAP claims to be an open specification, but in fact it is anything but - on the contrary, it is booby-trapped with patents. Furthermore, the basic premise of WAP (namely, that of providing Web browsing capability on a cell phone) is inherently limited and impractical, and is the wrong starting point application.
Mobile Messaging systems such as BlackBerry, on the other hand, bring unquestionable value to the user, and these systems have experienced widespread usage as a result. Without exception, however, all existing Mobile Messaging system are closed, and the emerging competitive scenario is that of a struggle among these closed systems.
Thus, while part of the wireless industry now appears to understand the enormous importance of the Mobile Messaging application, it does not appear to understand the importance of the open model.
The solution to this closed-system battle is not another set of products and services. Rather, the solution is the industry-wide adoption of the right set of open protocols as the basis for interoperability and cooperation.
Throughout this article, we will take the BlackBerry system from RIM as a particular example of a closed Mobile Messaging system. In common with other messaging systems, BlackBerry brings unquestionable value to the user. But despite its end user value, BlackBerry remains a closed, single-vendor system, based on a set of proprietary protocols. The proprietary nature of the underlying protocols prevents competition on the basis of any of the constituent components of the BlackBerry system.
And this is something which is true in general: closed systems diminish competitive opportunity. It is, of course, entirely possible for a closed system to encounter competition in the form of another closed system. However, the market entry barriers and competitive challenges are far greater for a competing system than for a competing system component - such as a wireless modem, for example.
Therefore closed systems act to inhibit competition both at system level and component level. This inhibition of competition is all to the good of the company that owns the closed system - which is the fundamental raison d'etre for all closed systems, of course. However, this same inhibition of competition acts greatly to the detriment of the industry at large and the consumer.
In contrast to this emphasis on minority business self-interests, we are committed to the following principles:
These principles are emphasized throughout this article, and in general throughout The LEAP Manifesto [65].
In this article we describe how the equivalent functionality to BlackBerry can be implemented in the form of a completely open system, based on existing technologies and protocols. We refer to this open equivalent to BlackBerry as the WhiteBerry solution. In contrast to BlackBerry, WhiteBerry is a multi-vendor solution, allowing market entry and competition at any point within the Mobile Messaging technology chain. The result is greatly increased business opportunities throughout the Mobile Messaging industry, increased competition, and better solutions for the end user.
Though we are presenting WhiteBerry as an open alternative to BlackBerry, there is nothing unique about BlackBerry in this regard. WhiteBerry represents an open alternative to any closed Mobile Messaging system, including others besides BlackBerry such as Mail on the Run! from River Run Software Group, and ReFLEX from Motorola. We have chosen BlackBerry as the subject of this article because it is in widespread use, and at this point appears to be the market leader. However, the same principles of openness versus closedness apply equally to any closed Mobile Messaging system.
The entire WhiteBerry solution that we describe in this article is complete and available today. The key component of WhiteBerry is a set of mobile messaging protocols. These are complete, fully satisfy all necessary technical requirements, are truly open and patent-free, and have been published as RFCs. In addition, a comprehensive framework for the development of WhiteBerry implementations has been established. This framework consists of free, open-source software implementations of the protocols, an open public forum for the development and distribution of integration tools, an initial set of free Subscriber Services, and an initial end-to-end WhiteBerry implementation. Anyone can use these tools and facilities to create a fully functional WhiteBerry Mobile Messaging implementation immediately.
Furthermore, the WhiteBerry development framework is highly generalized, and goes beyond simply duplicating the limited capabilities of the BlackBerry system - it also allows the development of a more general set of wireless applications, including Instant Messaging and others. A discussion of some of the future possibilities of the WhiteBerry model is provided in Section 13.9.
We begin this article by discussing the general functional requirements for Mobile Messaging. We then describe how these requirements are provided by a typical closed system, using BlackBerry as an example. Next we provide a detailed description of the WhiteBerry model, and show how it provides equivalent functionality to BlackBerry, based on an open model. We then describe the WhiteBerry development framework, and discuss the security issues relating to Mobile Messaging.
The solution we propose is not just an academic, engineering exercise; it also has a well-founded business dimension. As will become clear later, there is a great deal of money to be made in Operation WhiteBerry.
The Free Protocols Foundation (FPF) is a non-profit organization dedicated to the support of patent-free protocols and software. The FPF views software patents as being extremely harmful to the industry and the consumer, and part of the FPF mandate is to oppose such patents when they appear. For more information see the FPF website at http://www.freeprotocols.org/.
Research In Motion (RIM), the manufacturer of the BlackBerry system, has recently been granted U.S. Patent # 6,219,694 on the basis of its BlackBerry technology, and is now suing a competing company (Glenayre Electronics, Inc.) for infringement against this patent. Therefore not only does BlackBerry limit competitive opportunity by virtue of being a closed system, but now RIM has taken a giant step beyond that in terms of anti-competitive practices: it is attempting to eliminate all competition entirely.
The FPF regards this patent as fundamentally invalid, and RIM's infringement claim as an egregious example of patent law abuse. For a detailed FPF position statement on this patent see the FPF paper Position Statement regarding the RIM Mobile E-Mail Patent Assertion [35], available on-line at http://www.FreeProtocols.org/rimBBPatent/main.html.
The FPF is strenuously opposing this patent by means of a variety of actions; see the above position statment for details. One of the general strategies by which the FPF opposes patented software is by supporting the creation and development of patent-free alternatives. Since Operation WhiteBerry describes an open, patent-free alternative to the closed and patented BlackBerry system, it is directly aligned with this strategy.
Therefore, as part of its broad compaign to oppose the RIM patent, the
Free Protocols Foundation endorses Operation WhiteBerry fully,
and is pleased to re-publish this revision of the paper on its own
website. Operation WhiteBerry was first published and remains
available on the LEAP Forum website at
http://www.LeapForum.org/operationWhiteberry/index.html.
The mobile user of today can choose from a variety of messaging technologies. At one extreme, the user may choose to carry a miniature paging device. At another extreme, he may choose to carry a laptop device which he can use to dial in to retrieve e-mail messages. Each of these technologies provides a particular set of capabilities and functionality to the mobile user.
Modern e-mail systems provide a comprehensive richness of message format, including To, From, CC and Subject fields, and the ability to include attachments. Traditional paging devices, by contrast, typically provide extreme simplicity of message format - in some cases no more than a 10-digit telephone number.
On the other hand, paging devices provide the user with a very high degree of portability, which cannot be matched by a laptop or even most palmtop devices. Furthermore, paging systems deliver messages directly to the recipient, who is then unilaterally alerted to their presence by the paging device. By contrast, e-mail systems usually do not provide this direct delivery capability, but instead require an explicit retrieval action on the part of the recipient.
The mobile user of tomorrow will expect and demand the best that each of these technologies can offer. While on the move, mobile users need to have important or time-critical information delivered to them. This information may be more complex than a 10-digit telephone number. And it may be necessary to present this information to the user immediately, without requiring him to dial in for messages. Users must be able to accept messages at any time, at any place, and on a device that they can carry anywhere.
In order to satisfy these requirements, a Mobile Messaging system must have the following characteristics:
The required Mobile Messaging system must therefore combine the message richness of typical e-mail, with the unconscious carry and push delivery characteristics of typical paging devices. We will refer to a messaging system that satisfies these criteria as a true Mobile Messaging system.
Unconscious carry, and the push mode of delivery, are essential requirements of the mobile user. Showing up to a romantic dinner carrying a laptop is idiotic. Showing up with a pager in your pocket is not (though answering it may be). And if much later your now-wife is soon to give birth, you certainly do not want to have to dial into your Message Center to discover that she has gone into labor. Information like this must be presented to you immediately, and wherever you happen to be.
To illustrate the shortcomings of closed messaging solutions, we will take the case of BlackBerry as a specific example. While the description and analysis throughout this section applies specifically to the BlackBerry system, similar principles apply to all closed messaging systems.
BlackBerry is a Mobile Messaging solution from Research In Motion (RIM). It satisfies all the Mobile Messaging requirements specified above: it provides users with general e-mail capability; the end user devices satisfy the unconscious carry criterion; and it supports the push mode of operation - incoming e-mails are delivered directly to the handheld device, which then immediately advises the user of their arrival.
BlackBerry can be used as a stand-alone Mobile Messaging system; alternatively, it can be integrated with a user's existing home or office e-mail account. In this case it appears to the user as a wireless extension of his existing desktop, corporate, or ISP-based e-mail service. The user can freely access and manage the wireless mailbox, while the system maintains synchronization with the land-based mailbox.
In the following sections, we will describe the major characteristics of the BlackBerry system. For complete details, see the BlackBerry website at http://www.blackberry.net/.
It is important to note that the BlackBerry messaging implementation represents nothing fundamentally novel. All the basic concepts, methods and processes represented in the implementation have been previously known and put into practice by others - RIM has merely packaged those concepts and brought them to the mass market.
The overall operation of the BlackBerry system is shown in Figure 13.1. All BlackBerry-specific components are shown shaded in this figure. (Note: Figure 13.1 and the following description represent our understanding of the BlackBerry system at the time of writing in February 2001. Because the system is closed and technical information regarding its operation is unavailable, we cannot guarantee the accuracy of this description; nor is there any assurance that RIM will not change the operation of the system in the future. The following description is based on RIM's promotional information, supplemented with our own educated assumptions where necessary. For the latest and most reliable information, refer directly to RIM's own materials.
Note also that our purpose in providing this description is not to reverse engineer the BlackBerry system; rather, it is to illustrate the characteristics of closed Mobile Messaging systems in general. Minor inaccuracies in our description of BlackBerry are therefore not of any great importance.)
The BlackBerry user is provided with a wireless handheld device, shown on the left side of the figure. The user has a choice of either of two alternative device styles: a pager-style form factor, or a palm-style form factor. The device has an integral wireless modem, allowing communications over the BellSouth Intelligent Wireless Network.13.1 The device is equipped with RIM's software implementation of their proprietary wireless-oriented protocol, allowing the device to communicate with the similarly equipped BlackBerry Message Center.
The mobile device is supported by the proprietary, RIM-operated BlackBerry Message Center, shown in the center of Figure 13.1. Any e-mails addressed directly to the mobile device are fielded by this Message Center using standard Internet protocols, then delivered to the mobile device using the proprietary RIM wireless protocols. The device modem remains on at all times to accept incoming messages, and the device notifies the user immediately whenever a new message arrives.
To send a message, the user composes the message then submits it to the BlackBerry Message Center via the RIM protocols. The Message Center then sends the message to its destination using standard Internet e-mail protocols.
More often, the user wishes his mobile messaging capability to function as a wireless extension of an existing e-mail account. The user may choose to have the BlackBerry system function as an extension of his Microsoft Outlook desktop mail application. In this case, the user installs the BlackBerry Desktop Redirector software on his PC. This situation is shown at the top of Figure 13.1.
The Desktop Redirector software integrates with the Microsoft Outlook mail application, and allows selected e-mails to be forwarded to the wireless device on the basis of user-defined e-mail filters. Properly qualified e-mails are forwarded to the BlackBerry Message Center using standard e-mail protocols, which then delivers them to the mobile device using the RIM protocols.
When the user sends a message, the BlackBerry Message Center sends the message to its destination as usual, but in addition sends a notification to the BlackBerry Desktop Redirector so as to maintain mailbox synchronization between the handheld device and the desktop mail application. Similar synchronization is maintained for any other action the user might take, such as message forwarding, deletion, etc. The mailbox synchronization protocols required to accomplish this are also proprietary to RIM.
For integration with corporate e-mail systems, RIM provides the BlackBerry Enterprise Server, which integrates with the Microsoft Exchange Message Center, as shown on the right of Figure 13.1. The BlackBerry Enterprise Server functions in much the same way as the Desktop Redirector, except that mail redirection and synchronization take place at the corporate Message Center, rather than the user's desktop mail application. As before, qualifying e-mails are forwarded to the BlackBerry Message Center, then delivered to the mobile device.
The BlackBerry system can also be integrated with certain third-party Service Providers; at the time of writing there are four of these: OneMain, RCN, Rogers AT&T, and PageNet Canada. The nature of the business relationship between RIM and these companies is unknown to us; our guess is that in each case RIM licenses the BlackBerry Enterprise Server to the Service Provider, which then integrates it with its in-house Message Center system. Regardless of the actual business arrangement the end result is the same: the Service Provider is then able to offer the BlackBerry system to its customers as a wireless extension of their regular e-mail account. This situation is shown in the lower right of Figure 13.1. The functional logistics in this scenario are essentially no different from integration with corporate Message Centers.
Mobile Messaging solutions such as BlackBerry have been well received by consumers. Users generally report a high level of customer satisfaction, and such systems have experienced steadily increasing adoption and usage. The basic reason for this is that these systems provide a tremendous value proposition to the user:
Mobile Messaging systems provide instant delivery of important or time-critical e-mail messages to mobile users, using an unconscious carry device. The mobile device is always on, and is guaranteed to get you the information you need, whenever, and wherever, you happen to be.
The market acceptance of systems like BlackBerry unequivocally confirms that Mobile Messaging, with the requirements defined in Section 13.2, is the killer application in the wireless data communications arena. Unconscious carry, push mode, and full e-mail functionality: these are the key characteristics that have established Mobile Messaging as a viable commercial concept. And these are the same characteristics that will define the Mobile Messaging industry of the future.
Despite its proven value proposition, BlackBerry remains a closed messaging solution. It is a proprietary package of integrated components and services, supplied by a single vendor.
The key component of the BlackBerry system consists of the protocols used for final-leg communication between the BlackBerry Message Centers and the mobile devices. However these protocols belong exclusively to RIM. They are heavily protected by patents, are not published or otherwise made available to potentially competing vendors, and are otherwise treated as trade secrets.
For this reason, BlackBerry consists of precisely the components and services defined by RIM. Because of the closed nature of the protocols, it is not possible for any other vendor to provide any alternative component of the BlackBerry solution. This is all very much by choice on the part of RIM, of course, who are executing a business model based on the classical ``sustainable advantage.''
An integrated package of components is required to bring Mobile Messaging capability to the end user. The various required components, and the way in which the BlackBerry system supplies these components, are summarized below:
BlackBerry is thus, from beginning to end, from A to Z, defined and controlled by RIM.
A further consequence of the closed nature of the RIM protocols is that they have received no external engineering scrutiny or validation. They are known to function adequately in the environment and usage patterns defined by the BlackBerry solution, but no information is available regarding their technical merits - for example, no data is available by which to judge the performance, reliability or scalability of these protocols.
In addition, no detailed information is available regarding the BlackBerry security implementation. Security issues are discussed in greater detail in Section 13.6.
Most of the closed aspects of the BlackBerry system do not directly affect the experience of the end user. For example, the typical user neither knows nor cares that the system is limited to the BellSouth Intelligent Wireless Network.
However, the closed nature of system is immediately evident to the end user in the form of the BlackBerry devices. While most users are extremely satisfied with the Mobile Messaging functionality of their device, they may be less than completely satisfied with its other features.
A device manufacturer may be able to do one thing very well, but it is extremely difficult to do everything well. BlackBerry provides Mobile Messaging functionality very well. The BlackBerry devices also provide the other standard PDA applications: calendar, address book, memopad, task list etc.; however, the BlackBerry implementation of these applications falls well short of others in the marketplace. For example, once users have experienced the superlative Graffiti text-entry interface of Palm devices, text entry on BlackBerry seems clumsy and frustrating.
Even apart from the merits of one device over another, there is the simple matter of taste and familiarity; people grow used to a particular device or application, and have a reluctance to change to something different.
As a general-purpose PDA, BlackBerry is inferior in many ways to other devices, most notably the popular Palm family. For this reason users find themselves carrying around two devices: their preferred PDA, plus BlackBerry as a specialized paging/messaging device. The solution to this inconvenience is abundantly obvious to the puzzled end user, who asks, ``Why must I carry both of these? Why does my preferred PDA not do what BlackBerry does?''
It is not that users have any dissatisfaction with the messaging functionality of BlackBerry - it is just that they would prefer to have this same functionality on their favorite PDA.
Clearly, what is required is for the Mobile Messaging capability of BlackBerry to be available on any mobile device - and WhiteBerry makes this possible.
Because the value proposition has now become so clear, various companies are eager to jump on the Mobile Messaging bandwagon, or have already done so. For those companies that already have existing relevant assets, this is not difficult to do. A good example is Palm, which has a tremendously powerful asset in the form of its installed base of approximately 11 million PDAs. These can be wireless enabled with a variety of existing modems, and can therefore readily form the basis for a Mobile Messaging solution. In addition to its very positive effect on their PDA sales, this would also provide Palm with immediate entry into the Subscriber Services business arena, a highly desirable and natural extension of their existing business model.
Palm thus has every reason to launch a Mobile Messaging solution: they have a vital asset, it is easy to do, and the business advantages are enormous. Evidently none of this is lost on Palm, who recently announced their intention to market wireless-enabled versions of their PDAs in the second half of 2001 [85]. Also, the opportunity to capitalize on the shortcomings of the BlackBerry devices is not lost on Palm CEO Carl Yankowski, who says:
``We can do everything that (Research In Motion) does not''
For reasons discussed in Section 13.7.4, there is a great temptation for businesses to implement closed and proprietary solutions. Thus far, every player to enter the Mobile Messaging arena has succumbed to this temptation. Palm has not yet provided information on whether it will be implementing a closed or an open messaging solution, or what the underlying protocols will be. However, we do not expect Palm to be any exception.
Other companies have been faced with a similarly clear-cut imperative to enter the Mobile Messaging market, and as a result there is now a multiplicity of messaging solutions available. In addition to BlackBerry, messaging solutions are currently being marketed by Glenayre, Skytel, Metrocall, Motorola and River Run. AOL has also recently joined the marketing fray with its Mobile Communicator product (though this is in fact the BlackBerry system re-marketed under AOL's name).
However, all of these are closed solutions, and are therefore subject to precisely the same limitations, and ultimate non-viability, as BlackBerry.
The companies who are developing and marketing these solutions are suffering from strategic myopia. The existence of a plethora of closed, non-interoperating Mobile Messaging solutions results in technological and market fragmentation, which clearly cannot persist in the long run.
Sooner or later, the Mobile Messaging industry must and will adopt an open solution model. Any closed solution is doomed to eventual (and we believe speedy) extinction.
The basic concept of WhiteBerry is to bring the same true Mobile Messaging functionality to the user as does BlackBerry - but based on a set of open protocols, as opposed to RIM's proprietary protocols.
BlackBerry is a single-vendor solution, in which every system component is defined and supplied by RIM. By contrast, WhiteBerry is a multi-vendor solution, in which the same functionality is provided by a series of products and services, and the necessary cross-vendor interoperability is guaranteed by the openness and integrity of the underlying protocols.
WhiteBerry is thus not merely a competing system to BlackBerry - it is radically different in nature. WhiteBerry is not owned by anyone, any more than the economy is owned by anyone. Since the underlying protocols are completely open, WhiteBerry will expose every part of the generic Mobile Messaging value chain to market entry, cooperation, and competition. Mobile Messaging will be transformed from its incarnation of today, consisting of a melange of closed, non-interoperating systems, into a true industry.
All the technological components required to implement WhiteBerry already exist and are in place. These components are:
(Note: Throughout this paper we will frequently make use of CDPD as a specific example of a Wireless IP network. We do this not because we necessarily believe that CDPD has any greater relevance than other networks, but because as the largest native IP public wireless network in the world today, it provides a ready and familiar example. The WhiteBerry solution is in no way limited or specific to CDPD - WhiteBerry is compatible with any Wireless IP network.)
Given that all these technological components are well established and readily available, the final component required to bring WhiteBerry to life is the right set of open protocols to tie everything together. As we will see in the following sections, these are now available too.
The key to the open Mobile Messaging industry is the right set of protocols.
Existing Internet e-mail protocols are not suitable for this purpose, because they are lacking in two major respects. First, they lack the necessary efficiency characteristics. Wireless networks are severely constrained by bandwidth limitations, and mobile devices 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 such as SMTP [79], IMAP [27] and POP [68] do not provide the required efficiency.
Second, existing Internet e-mail protocols do not properly support the push mode of delivery, which is an essential aspect of true Mobile Messaging. For more detailed discussions of the shortcomings of existing protocols, see the Manifesto articles EMSD: The LEAP E-Mail Component [7], and Efficiency of EMSD [6].
The inadequacy of existing protocols has been well demonstrated by the business failure of Mobile Messaging services based on them. Several service providers (Omnisky and YadaYada among others) have offered mobile e-mail services based on existing land-based Internet protocols such as POP, IMAP and SMTP. But because of the inefficiency of these land-based protocols, and because they do not support the push mode of delivery, these services are no match for true Mobile Messaging systems like BlackBerry.
Therefore a new generation of high-performance, efficient protocols is required to address the demands of the mobile and wireless environment. The necessary protocols must satisfy the following key functional requirements:
In addition to these technical requirements, the required protocols must be truly open. They must satisfy the conventions and criteria of openness that have come to be expected by the Internet mainstream community, ensuring that there are no restrictions whatsoever on their availability and usage. Specifically, the protocols must satisfy the following criteria:
All the above requirements are fully satisfied by 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.
LEAP is a layered family of protocols, of which two are of particular relevance to Mobile Messaging. The first of these is the Efficient Short Remote Operations protocol, or ESRO, published as RFC 2188 [91]. ESRO provides reliable connectionless transport services which can be used for a variety of applications, including but not limited to Mobile Messaging. For complete details on ESRO see the Manifesto article ESRO: A Foundation for the Development of Efficient Protocols, or visit the ESRO website at http://www.esro.org/.
Built on top of ESRO is the Efficient Mail Submission & Delivery protocol, or EMSD, published as RFC 2524 [5]. EMSD is a specialized native Internet messaging protocol which meets or exceeds the level of functionality, reliability and security provided by the existing SMTP protocols. EMSD has been designed with a major emphasis on efficiency, and fully supports the push mode of message delivery. For complete details on EMSD see the Manifesto article EMSD: The LEAP E-Mail Component, or visit the EMSD website at http://www.emsd.org/.
In addition to satisfying all the necessary functional and technical requirements, the LEAP protocols also fully satisfy the required openness characteristics. They are open in the broadest sense of the word: they are freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. For complete details, see the Manifesto article The LEAP Protocol Development Model [9].
In principle, the WhiteBerry solution could be based on any set of protocols that satisfies the necessary requirements. Other than LEAP, however, we are aware of no set of protocol specifications that satisfies these requirements. Though we have actively searched for alternatives, to the best of our knowledge no such alternative exists. As the basis for WhiteBerry, therefore, the LEAP protocols are both ideal and unique.
The way in which the WhiteBerry solution brings Mobile Messaging capability to the user is illustrated in Figure 13.2. All LEAP-specific components are shown shaded in this figure. This figure is somewhat similar to Figure 13.1, and the description of WhiteBerry in this section is similar to the description of BlackBerry in Section 13.3.1. However, there are also very significant differences between the two systems.
First, the user must be provided with some form of mobile handheld device, as shown on the left side of the figure. In the case of BlackBerry, this could only be one of the two form factors provided by RIM. In the case of WhiteBerry, this could be any unconscious carry device, such as a PDA, a cell phone, or a dedicated two-way pager, from any device manufacturer who has chosen to adopt the WhiteBerry model by LEAP-enabling the device.
The mobile device must be equipped with a wireless modem. In the case of BlackBerry, this is the integral RIM modem for the BellSouth Intelligent Wireless Network. In the case of WhiteBerry, this could be any suitably miniaturized modem, which supports any appropriate wireless network, such as GSM/GPRS, Metricom, Packet CDMA, or CDPD. Though the device may be turned off, the modem will normally remain on at all times to accept incoming messages.
The device must also be equipped with LEAP device software, allowing it to communicate via the LEAP protocols with LEAP-enabled Message Centers.
Next, the user must be provided with a LEAP-enabled Message Center to support his Mobile Messaging capability. In the case of BlackBerry, this role could only be played by the RIM-operated/licensed BlackBerry Message Center. In the case of WhiteBerry, however, there is considerably more versatility in how this service can be provided.
Under one scenario, Message Center service can be provided by an independent Subscriber Services provider, as shown in the center of Figure 13.2. Under WhiteBerry, this role can be played by any Message Center operator - for example, by any one of the large number of existing ISP companies. All that is required for an ISP or other Message Center operator to become a provider of LEAP-based Mobile Messaging services, is for them to install the necessary LEAP Message Center software.
Anyone with access to the Internet can now exchange e-mails with the mobile user. E-mails addressed to the mobile account are fielded by the Subscriber Service provider from the Internet e-mail system using standard Internet protocols, then delivered to the mobile device using the LEAP protocols.
The device modem remains on at all times to accept incoming messages, and the device notifies the user immediately (in any of the ways commonly used for pager notification, e.g. beep, buzz or vibrate) whenever a new message arrives. The user can then activate the device and read the message.
To send a message, the user enters the message then submits it to the LEAP service provider via the LEAP protocols. The service provider then sends the message to its destination using standard Internet e-mail protocols.
Users typically wish their mobile messaging capability to function as a wireless extension of an existing land-based e-mail account. For example, the user may wish the mobile device to act as an extension of a home or office desktop mail application, as shown at the top of Figure 13.2. This functionality is provided by installing the appropriate mail forwarding software on the desktop system. This software integrates with the desktop mail application, and allows messages to be selectively forwarded to the mobile device on the basis of user-defined e-mail filters. Properly qualified e-mails are forwarded to the LEAP service provider using standard e-mail protocols, then delivered to the mobile device using the LEAP protocols.
When the user submits a message from the mobile device, the LEAP service provider sends the message to its destination as usual, and in addition it can send a notification to the desktop mail application, to maintain mailbox synchronization between the handheld device and the desktop system.
Under a different scenario, there may be a need to bring Mobile Messaging capability to a corporate e-mail system, as shown at the bottom of Figure 13.2. This functionality is provided by installing the appropriate LEAP software in the corporate Message Center. This endows the corporate Message Center with the same LEAP-enabled functionality as the independent LEAP Subscriber Service provider, which is therefore not needed under this scenario.
Like the desktop software, the LEAP Message Center software allows e-mails to be selectively forwarded to the mobile device. But since the corporate Message Center is fully LEAP-enabled, these can be delivered directly to the mobile device using the LEAP protocols.
This aspect of WhiteBerry operation constrasts starkly with the BlackBer
