Creation of a
Truly Open Mobile Messaging Solution
Last updated November 3, 2002
Copyright ©2001, 2002 Free Protocols Foundation
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.
This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the Lightweight &
Efficient Application Protocols (LEAP) protocols. For the complete collection of articles see The LEAP Manifesto ,
http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free Protocols Foundation website at
This article was first published in February 2001. Since that time the Mobile Messaging industry has continued to evolve. The BlackBerry and WhiteBerry solutions have both moved forward, and the industry itself has undergone various changes. As a result of these developments some of the information in this article is now out of date.
In this revision we are editing and updating all WhiteBerry-related information, so that this information is now complete and accurate as of November 2002.
However, we have not yet made extensive revisions to the BlackBerry-related parts of this paper, nor to those parts of the paper that describe the industry as a whole. All technical descriptions and statistical data were correct to the best our knowledge in February 2001, but they do not accurately reflect the situation today.
We intend to publish another major revision of this paper in 2003, in which we will update all BlackBerry-related and general industry information. In the meantime the reader is asked to bear in mind that all BlackBerry and industry information reflects the state of affairs as of February 2001, and may no longer be correct.
1.1 The Problem
1.2 The Solution
1.3 Complete and Available
1.4 Free Protocols Foundation Endorsement of Operation WhiteBerry
2 Mobile Messaging Requirements
3 The BlackBerry Solution
3.1 How BlackBerry Works
3.2 BlackBerry: Mobile Messaging Confirmation
3.3 BlackBerry: A Closed Solution
3.4 BlackBerry: Not All Things to All People
3.5 Strategic Myopia: More Closed Solutions
4 The WhiteBerry Solution
4.1 Technological Components of WhiteBerry
4.2 The Unifying Component: A Set of Open Protocols
4.3 The Key to WhiteBerry: The LEAP Protocols
4.4 How WhiteBerry Works
4.5 Putting Everything Together for the End User
4.6 Technical Challenges & Responses
4.6.1 A Word About Networks
4.7 WhiteBerry versus BlackBerry
4.7.1 WhiteBerry Patent Resistance
5 Framework for Development
5.1 Open-Source Software Implementations
5.2 The MailMeAnywhere Development Forum
5.3 ByName Subscriber Services
5.4 The WhiteBerry Resource Center
5.4.1 Initial WhiteBerry Implementation
6 Mobile Messaging Security
6.1 BlackBerry Security
6.2 WhiteBerry Security
7 The Business Case for WhiteBerry
7.1 Immediate Opportunity: Installed Hardware Base
7.2 Precedents for Success
7.3 Shifting Opportunities: Winners & Losers
7.4 Business Conservativism
8 Framework for Participation
8.1 Device Integration
8.1.1 Windows CE Enhancement
8.1.2 Palm OS Enhancement
8.2 Modem Integration
8.2.1 Challenge to Modem Manufacturers
8.2.2 Cell Phone Integration
8.3 Network Services Integration
8.3.1 Wireless ISP Integration
8.3.2 Wireless ASP Integration
8.4 Systems and Solutions Integration
8.4.1 Message Center Integration
8.5 How to Participate
8.5.1 Getting the LEAP Software
9 Beyond Operation WhiteBerry
9.1 Building on WhiteBerry
9.2 Building on LEAP
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 key 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 limited 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 that 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:
- The Wireless Application Protocol, or WAP
- The BlackBerry Mobile Messaging system
WAP is discussed in detail in the article entitled The WAP Trap , while BlackBerry is discussed in the present article.
Our analyses of WAP and BlackBerry 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, whereas 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 donnybrook 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 focus on narrow business self-interest, we are committed to the following principles:
- We are advocates of patent-free protocols.
- We are advocates of truly open systems, based on free protocols and open-source software.
- We are committed to the Internet End-to-End model. In this model the Internet serves merely as a passive communication pipe, allowing direct and unrestricted communication between client and server.
These principles greatly benefit the industry and the consumer, by promoting innovation, competition, and freedom of choice.
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 protocols and technologies. 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 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/.
In April 2001 Research In Motion (RIM), the manufacturer of the BlackBerry system, was granted U.S. Patent # 6,219,694 on the basis of its BlackBerry technology, then promptly sued a competing company (Glenayre Electronics, Inc.) for infringement against this patent. While BlackBerry already limits competitive opportunity by virtue of being a closed system, the assertion of this patent is a giant step beyond that in terms of anti-competitive practices: it represents an attempt by RIM 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 statement on this patent see the FPF paper Position Statement regarding the RIM Mobile E-Mail Patent Assertion , available on-line at http://www.freeprotocols.org/position-rim-6219694.
The FPF is strenuously opposing this patent by means of a variety of actions; see the above position statement 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
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, he1 may choose to carry a laptop device which he can use to dial in and retrieve e-mail messages. Each of these technologies provides a particular set of functions and capabilities to the mobile user.
Modern e-mail systems allow a comprehensive richness of message content, including To, From, Cc and Subject fields, and the ability to include attachments. Traditional paging devices, by contrast, typically allow very limited message content—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 arrival 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:
- Allow the full information content of modern e-mail. The limited message content of traditional paging devices is not adequate.
- Provide mobile messaging capability on an unconscious carry device—meaning that the device can readily be carried anywhere by the user, without moment-to-moment awareness of its presence. A palmtop is the maximum size form factor that can be considered to satisfy this requirement.
- Support the push mode of message delivery—meaning that messages are delivered directly to the recipient, without requiring an explicit poll or retrieval action.
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.
Note:This section contains technical descriptions of the BlackBerry system, as well as statistical and other data about the Mobile Messaging industry in general. At the time that this article was first published in February 2001, this information was correct to the best of our knowledge. However, at the time of current writing (November 2002), much of this information is now out of date. We intend to update this section in a subsequent revision; in the meantime the reader is asked to bear in mind that technical and statistical data throughout this section may no longer be correct.
To illustrate the shortcomings of closed messaging solutions, we will take the case of BlackBerry as an 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 worth noting that in technological terms, 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. What RIM has done that is genuinely new is to package those concepts and bring them to market as a consumer product.
The overall operation of the BlackBerry system is shown in Figure 1. All BlackBerry-specific components are shown shaded in this figure; all generic or third-party components are unshaded. (Note: Figure 1 and the following description represent our understanding of the BlackBerry system at the time this article was first published in February 2001. Furthermore, 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 palmtop-style form factor. The device has an integral wireless modem, allowing communications over the BellSouth Intelligent Wireless Network.2 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 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. Under one scenario, 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 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 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 that this article was first written in February 2001 there were 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 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 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 clear 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 immediately, wherever you happen to be.
The market acceptance of systems like BlackBerry unequivocally confirms that true Mobile Messaging, as defined in Section 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 BlackBerry supplies these components, are summarized below:
- Mobile device. Only the two RIM-manufactured BlackBerry devices are available. No other device, such as a Palm or Windows CE device, is currently supported. (Of course, RIM could readily provide support for these and other devices by licensing its software for use on third-party devices, and we would not be surprised if at some point they do exactly that. Even if they did, however, these would merely be additional device incarnations of the same BlackBerry system. The system would still remain closed, because the underlying protocols would remain closed and proprietary to RIM.)
- Wireless modem. Only the RIM modem which is integral with the device is supplied. No other modem is supported.
- Wireless network. As of the time of initial writing in February 2001, the BlackBerry system is based exlusively on the BellSouth Intelligent Wireless Network (and its Canadian extension, the Rogers AT&T Wireless Network). No other wireless network, such as GSM/GPRS or CDPD , , is supported.
- Message Center service. Message Center service for final-leg communications with the mobile device is provided exclusively by the RIM-operated BlackBerry Message Center. No other Message Center service may be used for this purpose.
- Protocols to tie these components together. BlackBerry is based on RIM’s proprietary protocols.
- Where necessary, integration with the user’s Desktop, Corporate, or ISP-based e-mail system. In the case of desktop integration, BlackBerry provides support for the Microsoft Outlook mailbox application only; no other mailbox applications, such as Netscape Messenger, are supported. In the case of integration with corporate Message Center systems, BlackBerry provides support for Microsoft Exchange only; no other Message Center systems, such as sendmail  or QMail , are supported. In the case of integration with third-party ISPs, RIM currently has licensing agreements with only four: OneMain, RCN, Rogers AT&T, and PageNet Canada; no others are presently supported.
- Integration of all these components into a packaged solution for the end user. The BlackBerry system is integrated and packaged exclusively by RIM.
Thus from beginning to end, BlackBerry is 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 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. And 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?”
Why not indeed. 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. 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 PDAs3 . 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 . 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 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.4
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:
- Mobile Devices & Platforms. A wide variety of mobile devices and platforms are available which satisfy the unconscious carry criterion, such as the Palm product line, Windows CE devices, and the already ubiquitious cellular telephone. Note that the BlackBerry end user devices are also part of the general pool of mobile devices, and if RIM wishes to participate in WhiteBerry on the basis of its mobile device technology, it can certainly do so.
- Wireless Networks. A variety of networks are in place that can provide the necessary coverage footprint,
in-building penetration, and bandwidth. These include: GSM/GPRS, Packet CDMA, and CDPD.
(Note: Throughout this paper we will frequently cite CDPD as an example of a Wireless IP network. This is 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.)
- Wireless Modems. A variety of wireless modems are available for the above networks, and in miniaturized form factors appropriate for unconscious carry usage. These include the AirCard product line from Sierra Wireless, and the Minstrel product line from Novatel.
- Message Center Systems. There are several commercially available Message Center systems that can provide generic back-end e-mail support. The major systems are: sendmail, QMail, and Microsoft Exchange.
- Subscriber Services. There exist a large number of ISPs and other Subscriber Services companies that already host Message Centers and provide e-mail service to their subscribers. Any of these can readily provide support for WhiteBerry Mobile Messaging.
Given that all these technological components are mature and 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 the Mobile Messaging domain, 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 size. These constraints place an extremely high premium on the efficiency of data transfer. Existing Internet protocols such as SMTP , IMAP  and POP  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 element of true Mobile Messaging. For more detailed discussions of the shortcomings of existing protocols, see the Manifesto articles EMSD: The LEAP E-Mail Component , and Efficiency of EMSD .
The inadequacy of existing protocols has been well demonstrated by the business failure of Mobile Messaging services based on them. Several service providers (Omnisky 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 just 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:
- Support the submission and delivery of short (e.g. 4 kilobytes or less) Internet e-mail messages, while meeting or exceeding the functionality of the existing SMTP protocols.
- Meet or exceed the reliability and security of the existing SMTP protocols.
- Support push mode for immediate message delivery.
- Provide the required efficiency characteristics. These include: minimization of the number of transmissions, minimization of the number of bytes transmitted, and minimization of the latency of message submission and delivery.
- Make reasonable trade-offs between specification complexity, implementation complexity, extensibility, scalability and efficiency.
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:
- They must be functionally free of patents, licensing requirements, or any other form of usage restriction.
- They must be published as stable specifications which are freely, easily, and permanently available to anyone who wishes to use them. The ideal availability mechanism is Internet RFC publication.
- They must be open to public review and commentary; and participation in the maintenance, revision and enhancement of the protocols must be open and free to any interested party. The maintenance process must also preserve the patent-freedom of the protocols.
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 that 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 . 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 . 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 .
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 2. All LEAP-specific components are shown shaded in this figure. This figure is somewhat similar to Figure 1, and the description of WhiteBerry in this section is similar to the description of BlackBerry in Section 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 can 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 can be any suitably miniaturized modem, which supports any appropriate wireless network, such as GSM/GPRS, 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 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 generic Internet 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 or vibrate) whenever a new message arrives. The user can then activate the device and read the message.
To send a message, the user composes 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 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 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 BlackBerry system, in which all messages must pass through the BlackBerry Message Center—even those forwarded from a peer Subscriber Service provider.
As described above, the WhiteBerry solution requires coordinated integration among several components. Figure 3 shows how these components fit together to provide true Mobile Messaging capability to the end user. If a sophisticated end user were to assemble these components himself, he would need to follow these steps:
- Acquire a suitable PDA; e.g. a Palm or Windows CE device.
- Decide on an appropriate wireless network; e.g. GSM/GPRS or CDPD.
- Acquire a wireless modem for the selected network, in a form factor compatible with the selected PDA; then attach the modem to the PDA. E.g. in the case of the Palm family of devices, and the CDPD network, suitable modems are available from Sierra Wireless and Novatel.
- Purchase a subscription to the selected network through an appropriate network Service Provider; e.g. AT&T or GTE.
- Activate the modem for use with the selected subscription, by configuring the modem as directed by the Service Provider.
- Download the appropriate WhiteBerry client software for the selected PDA; e.g. from MailMeAnywhere.org.
- Choose a WhiteBerry Message Center operator, e.g. ByName.net, and activate an e-mail account with that operator.
- (If desired) link the mobile e-mail account to an existing home or corporate e-mail account by installing and configuring a rule-based forwarder on the existing home or corporate desktop system; e.g. by use of the Microsoft Outlook autoforwarding facilities, or by use of FetchMail and ProcMail.
And that’s it. The user now has fully equivalent functionality to BlackBerry—but using his preferred choices of PDA, wireless network, wireless modem, network Service Provider, and Message Center operator. The user can assemble his WhiteBerry system using the best and/or most cost-effective option available for each component.
And if the user should happen to own a PDA/modem combination already, e.g. for wireless web browsing, then the user can provide himself with full Mobile Messaging capability at zero incremental hardware cost.
In principle, there is nothing to prevent an individual end user from doing all this for himself. In reality, of course, it is impractical for the typical user to do this on his own—which is why we have systems integrators. A systems integration company such as Omnisky can readily bundle together all the above components and present the end user with a complete, turnkey WhiteBerry solution.
These two scenarios (total assembly from scratch by the end user, vs. total third-party integration) represent two integration extremes. There are many shapes and sizes of partial integration lying between these extremes. For example, steps 3, 5 and 6 can readily be combined into a single product/service offering (as Omnisky does already, in fact, by packaging together a CDPD modem, AT&T account, and account activation as a wireless-enabling add-on for the Palm family of devices).
The open WhiteBerry paradigm allows a supplier to step into any conceivable market niche.
There are several challenges that can be made to the WhiteBerry model on technical and/or cost grounds. For example, the arguments can be made that wireless modems are too expensive to allow deployment of a cost-effective solution; or that battery longevity is too short to allow widespread acceptance by users.
However, these objections and others like them are ultimately without basis. In the case of the modem cost, and all other cost-related objections, the response is the same: modem and other hardware costs have been falling, and will continue to fall. There is nothing about any of the WhiteBerry hardware components to prevent them from eventually becoming available as inexpensive commodity items.
And there is no technical challenge that does not have a clear and straighforward resolution. To take the case of battery longevity, the responses are: (a) increased network cell density will reduce active device power consumption; (b) inactive device power consumption will be drastically reduced by implementation of network protocols for efficient device sleep mode, and also by close integration between the modem and the protocol software for sleep mode operation; and (c) inherent battery longevity will continue to undergo gradual improvement.
Clearly, there are no show-stoppers here. For a conclusive demonstration of this one need look no further than BlackBerry itself—if RIM can successfully bring a viable product to market, then so can others. And as the technical and cost considerations become even less relevant, things can only get easier.
In general, the desired characteristics of a network depend upon its intended usage. The ideal technical network requirements for paging, and for generalized wireless data transmission, are sufficiently different that these two applications have traditionally been considered to require different networks. Historically, paging networks (both one-way and two-way) have been considered unsuitable for generalized wireless data usage; while generalized wireless data networks have been considered inadequate for specialized paging and Mobile Messaging applications.
Because of this historical viewpoint, there is a continuing perception that only a certain class of networks are technically suitable for Mobile Messaging. However, this perception is incorrect.
The key functional criteria for suitability of a network for Mobile Messaging are:
- Coverage. In general, the greater the coverage footprint the better, but nationwide or global coverage is by no means essential. Depending on the requirements of the user, local or regional coverage may be more than sufficient.
- In-building penetration. In general, the higher the degree of in-building penetration the better. But again, depending on the usage pattern of the user, a lesser degree of in-building penetration may be adequate.
- Device miniaturization and battery lifetime. Today’s mobile professional expects an unconscious carry form factor, and at least two full days between battery recharges. Among other things, the density of the network transceivers must be sufficient to meet both these requirements. A variety of networks satisfy this requirement.
- Data throughput. In general, a very high data throughput capability is not an essential requirement for Mobile Messaging. Because messaging is an inherently asynchronous activity, based on a store-and-forward paradigm, data latency is not a major issue. Messaging is entirely feasible on networks with data rates as low as 2400 bits per second.
Based on the above, it can be seen that a broad range of networks are entirely suitable for Mobile Messaging.
The BlackBerry system is currently limited exclusively to the BellSouth Intelligent Wireless Network. This network scores high marks on all four criteria listed above, and is therefore well-suited to Mobile Messaging.
But it is by no means the only network that is suitable for this. And the WhiteBerry model allows any suitable wireless data network to be used, including GSM/GPRS, Packet CDMA, and CDPD—which collectively account for most of the wireless network market of today. With proper industry cooperation and integration, a messaging solution based on any of these networks can compete directly with closed solutions such as BlackBerry, or those based on the closed ReFLEX protocol.
The major differences between BlackBerry and WhiteBerry are summarized in Table 1.
In the world of closed systems, competition with BlackBerry takes the form of other proprietary turnkey systems, which provide similar functionality.
The WhiteBerry model is fundamentally different from this: it is an open industry model. Since the mobile messaging solution is based on a set of open protocols, each component of the solution is exposed to free competition. Vendors and service providers can now compete in every aspect of the mobile messaging solution: handheld devices, wireless modems, networks, message centers, and the provision of Subscriber Services to the user.
The result of this is not just a set of competing, closed, non-interoperating solutions. Rather it is a thriving industry, in which active and independent competition takes place within every component of the user’s ultimate value proposition.
As noted previously, RIM has been granted a U.S. patent on the basis of its BlackBerry technology, which potentially threatens other closed Mobile Messaging systems.
The WhiteBerry solution, however, enjoys a major advantage over closed systems in terms of its vulnerability to patents. Unlike BlackBerry and other closed systems, WhiteBerry is not a single static messaging solution; rather, it is a highly mutable meta-solution. That is, any particular WhiteBerry implementation is created by integrating together an appropriate set of components, so as to achieve the particular functionality desired by the systems integrator or the end user.
The components that go into any given WhiteBerry implementation may be drawn from a large family of components which includes the EMSD protocol engines, FetchMail, ProcMail, mail forwarders, and various others. Each of these components is independent, freely available, useful in its own right, and entirely unrelated to the RIM patent.
Because of this inherently component-based nature, the WhiteBerry solution is exceedingly resistant to the RIM patent claim, and indeed to patent infringement claims in general. By making all the necessary components freely and publicly available, WhiteBerry provides systems integrators and end users with a variety of methods and strategies to circumvent or nullify invalid patent assertions.
All the essential components required to implement WhiteBerry now exist. As discussed in Section 4.1, all the technological components (devices, modems, networks) are well established and readily available.
The necessary open protocols are also ready and available: the LEAP protocols are complete and have been published as Internet RFCs, and open support organizations for their continued revision and enhancement are up and running at LeapForum.org, ESRO.org and EMSD.org.
In addition, a framework for the development of WhiteBerry solutions has been established. This framework consists of:
- Open-source software implementations of the LEAP protocols for various devices and Message Center platforms
- An open public forum for the development and distribution of LEAP-related integration tools and facilities
- A set of free Subscriber Services to support immediate deployment of the WhiteBerry solution in end user devices
- A resource center providing starter kits for various types of implementor, and an initial end-to-end WhiteBerry implementation
Each component of this development framework is described in the following sections.
Open-source software implementations of the LEAP protocols are available for all major device and Message Center platforms.
Reference Protocol Engines have been implemented in the form of portable code, which has been ported to a wide variety of platforms and end user devices. On the device side, software has been implemented for pagers and cell phones; for palmtop devices (Windows CE, Pocket PC, Palm OS, EPOC)  ; for Windows 2000, Windows 98/95, and Windows NT; and for Pine (UNIX, Windows, DOS). On the Message Center side, software is available for Windows NT, Solaris, and Linux.
All of this software is freely and publicly available at the MailMeAnywhere open-source software distribution center. The software is available as free software, subject to the General Public License (GPL) . For complete details visit MailMeAnywhere at http://www.MailMeAnywhere.org.
The protocol engines provide the basic message submission and delivery capability for the mobile environment. But this capability must be supplemented by a variety of other tools and capabilities in order to bring a complete, well-integrated solution to the end user.
Among other things, the user must be provided with flexible tools for selecting which e-mail messages are forwarded to the mobile device, and which can remain in the fixed mailbox for later review. The end-user solution must also include facilities to ensure proper synchronization and continuity between the mobile account and the fixed account.
In addition, there is a need to provide Mobile Messaging solutions in a variety of contexts. A mobile user may have a fixed e-mail account in any of various shapes and sizes, such as a corporate account or an ISP-based account, and he may wish to control and administer his mobile capability in various ways, such as via his desktop mail application, or via his corporate or ISP-based mail server.
In order to deliver this broad heterogeneity of Mobile Messaging implementations, the integration and development community requires a variety of tools for accessing and processing the user’s fixed mailboxes. In particular, comprehensive and close integration of the LEAP protocol engines will be required with mail routers, mail retrievers, mailbox synchronizers, inbox filters and rule- and directory-based fowarders.
For this purpose, MailMeAnywhere includes an open public forum for the development and distribution of the necessary tools and capabilities. The MailMeAnywhere development forum is a public framework for the collective development and enhancement of LEAP integration tools on a continuous, on-going basis.
This open development model, based on open protocols and open-source software, ensures the availability of a rich and expanding suite of tools and accessories for integration of the WhiteBerry solution in various configurations and across multiple platforms.
This open, heterogeneous development model is in sharp contrast to BlackBerry’s narrow focus on Microsoft Outlook and Exchange.
The open WhiteBerry paradigm must address a classical bootstrapping problem: a useful WhiteBerry solution requires implementation of the LEAP protocols in both devices and Message Centers, each of which cannot function without the other.
A set of Subscriber Services has been created to address this problem. The ByName Services are a set of comprehensive, well-integrated, and highly personalizable computing and communications services. They are fully WhiteBerry-enabled, and can provide complete and immediate support for WhiteBerry end-user devices.
In addition to playing this WhiteBerry support role, the ByName Services are also the world’s first Libre Services. Libre Services are an extension of the principles of the Free Software movement to the domain of Internet Application Services. As Libre Services, the ByName Services are based entirely on patent-free protocols, and implemented exclusively in free and open-source software. As a result, the entire ByName construct can be copied and redistributed by anyone. Everything required to recreate the ByName Services in their entirety is freely available at the MailMeAnywhere software distribution site.
The ByName Services are implemented as a pair of sister sites:
My.ByName.net is a showcase site, demonstrating the concept and capabilities of Liber Services. My.ByName.com is a hands-on look-and-see environment, provided for try-out by the public. Anyone can sign up for a free account at My.ByName.com.
The two sites provide identical services, including complete WhiteBerry support. In particular, anyone can sign up for completely free WhiteBerry service at My.ByName.com.
The WhiteBerry Resource Center is a central location where developers can pick up everything they need to begin implementing WhiteBerry solutions. A set of starter kits are available, providing the resources required by various types of implementor: individual, corporate, ISP/ASP, or systems integrator. For complete details visit the resource center at http://www.mailmeanywhere.org/wbStartKit/
The starter kits provide complete step-by-step descriptions of how to build a WhiteBerry solution. As a case-study example, we will describe the experiences of an individual implementor—let’s call her Lisa Simpson. The steps Lisa followed and the choices she made in assembling her WhiteBerry system are summarized in Table 2. The numbered steps in this table correspond to the generic steps described in Section 4.5 and Figure 3.
At the end of this process Lisa had her very own, fully functional, true Mobile Messaging solution—and so can you.
The WhiteBerry Resource Center also provides an initial WhiteBerry implementation, which can be freely used as a development tool by anyone—for examination, enhancement, or as the starting point for further implementations.
An initial base implementation, of course, is not the same thing as a comprehensive, market-ready messaging solution. But the existence of this implementation clearly demonstrates the viability of WhiteBerry as a complete, end-to-end messaging solution. It means that WhiteBerry is not just an idea—it is an actual working system, which is up and running today.
We claim in this article that WhiteBerry meets or exceeds the entire functionality of BlackBerry. There is one possible objection that could be made to this statement: that, as described, WhiteBerry does not match BlackBerry’s claimed security functionality.
In their promotional literature, BlackBerry claims to provide “end-to-end” security using Triple DES encryption technology. A casual reading of this would lead one to believe that BlackBerry provides full message encryption all the way from the sending mail application to the receiving mail application—i.e. all the way from the point of origin to the point of delivery. In the Internet world, this is conventionally what “end-to-end” means.
In fact, the BlackBerry system only provides encryption between the BlackBerry handheld and the corporate e-mail account. This provides security only for messages originating in or being delivered to the in-house corporate e-mail system. In the case of generic e-mails, which may be transmitted to/from any point on the Internet, BlackBerry provides no security whatsoever beyond the point of relay at the corporate system.
In other words, one of the ends being referred to in BlackBerry’s claim of “end-to-end” security is not the ultimate user mail application, but the corporate account. BlackBerry thus only provides security over part of the transmission route from sender to recipient. This is rather like going out to do battle wearing a suit of armor that only offers protection from the waist down—it is only slightly better than no armor at all.
Therefore BlackBerry does not provide true End-to-End security, and RIM’s use of this term is disingenuous and misleading. The claimed security is limited and superficial, providing only a degree of psychological reassurance to the user—it is more of a security blanket than genuine security.
Furthermore, since the BlackBerry system is closed, details of the actual security implementation are unknown, and have not been subjected to external review. RIM’s description of its security method may be adequate for marketing purposes, but this does not provide sufficient information for a formal engineering validation.
In general, e-mail users can achieve true End-to-End security by means of the existing PGP  or Secure MIME (S/MIME) ,  technologies. These are the two methods most commonly used for e-mail security today. However, if these technologies are to provide true End-to-End security, they must be implemented at both ends—i.e. at both the sending and receiving e-mail applications. But since the BlackBerry devices are closed, it is not possible for a BlackBerry user to make use of these or any other independent security mechanisms.
Therefore not only does the BlackBerry system not provide genuine End-to-End security, its closed nature also precludes implementation of genuine End-to-End security by any other means.
There is no doubt that security is of major importance in the e-mail domain. However, the basic Internet e-mail protocols (SMTP, POP and IMAP) were originally designed without adequate consideration for the security issues. Because of this, and because of certain flaws in the implementation of these protocols, the Internet e-mail structure of today includes serious security compromises.
Nevertheless, the existence of the above security compromises has not prevented the widespread adoption and usage of Internet e-mail. Today, much of the daily e-mail traffic still takes place without any formal security protection. In the case of those messages which do require secure transmission, additional security mechanisms are typically applied.
There is a perception that there is a greater need for security in the wireless world than in the wired world, because of the far greater ease of physical access to the wireless communication channel. However, most modern IP-based networks already provide a confidential data link at Layer 2, usually obviating the need for additional over-the-air, point-to-point confidentiality mechanisms.
Things have changed a great deal since the early days of Internet e-mail, and today’s security expectations and requirements exceed the capabilities of existing protocols.
Mobile Messaging must be a seamless and consistent extension of the existing Internet e-mail structure. Likewise, in order to provide true end-to-end security over both the wired and wireless Internet, the security mechanisms for Mobile Messaging must be an integral part of the overall Internet e-mail structure. Since WhiteBerry is designed as a natural extension of Internet e-mail, it provides the same or better level of security as the existing SMTP protocols.
Also, the WhiteBerry paradigm fully supports the implementation of existing Internet e-mail security mechanisms such as PGP or S/MIME. For those e-mail applications that require it, true End-to-End security can readily be implemented in the context of WhiteBerry by means of these technologies.
However, the currently available implementations of PGP and S/MIME are not the ideal solution for the Mobile Messaging domain. The major factor that is genuinely different in the wireless world is the set of constraints imposed by device miniaturization. For this reason, and in contrast to the wired world, there is a crucial need for efficiency. The currently available implementations of PGP and S/MIME impose undesirably heavy computational demands on the CPU-limited mobile devices, and also impose undesirable message transmission overhead on the bandwidth-limited wireless networks.
Therefore the long-term solution to the need for security in the wireless domain is to provide mainstream security mechanisms such as PGP and S/MIME, but based on more efficient public key algorithms and mechanisms such as elliptic curve cryptography. This is the WhiteBerry approach to security, and one of the planned future tasks will be to extend the LEAP protocols to provide efficient security mechanisms. It is anticipated that this work will take place at EMSD.org.
In addition, generalized security services (in particular authentication and confidentiality) can be provided by establishing a Secure Short Remote Operations (SSRO) layer on top of ESRO. It is anticipated that work related to SSRO will take place at ESRO.org.
Meanwhile, the existing WhiteBerry security mechanisms are adequate for most wireless e-mail traffic, and where necessary they can be augmented by conventional End-to-End security mechanisms.
The Mobile Messaging industry of today is limited and fragmented by the existence of a number of competing, non-interoperating, closed solutions. For this reason the industry remains only a fraction of its eventual size and scope.
By shifting competitive engagement from system-level to component-level, the open WhiteBerry solution will change everything. WhiteBerry will expose the entire Mobile Messaging value chain to market entry, resulting in a flood of innovation, cooperation and competition, and catalyzing enormous industry growth.
There is a substantial segment of the messaging market that can be targetted without any product development effort whatsoever, and with minimal sales effort. This segment consists of those users who can be provided with the WhiteBerry solution immediately and at virtually zero cost, because they already own the necessary hardware.
Any user who owns an appropriate device/modem combination is a latent WhiteBerry user. To take the example of a specific network (say CDPD) and a specific device (say Palm), note that every person who owns a Palm device and a compatible CDPD modem can become a WhiteBerry user at zero hardware cost. All that such users need is the necessary LEAP software. The same applies to other network/modem/device combinations.
This pre-enabled market segment is quite substantial. In terms of modems, as of February 2001 there is an estimated existing installed base of between 250,000 and 300,000 PDA-compatible CDPD modems; and the installed base of other wireless IP modems such as Packet CDMA is also rapidly growing. In terms of devices, there is an estimated installed base of around 20 million PDAs such as Palm, Windows CE, etc. . It is also worth noting that a user who owns one of these components (i.e. device or modem) but not the other can be provided with WhiteBerry functionality at correspondingly discounted incremental hardware cost.
Furthermore, since the owners of these components are already known to the component vendor, they can be targetted directly. A ready-made marketing/distribution channel to these users is immediately available to the appropriate hardware manufacturer or integrator. Companies who can take immediate advantage of this include modem manufacturers such as Novatel and Sierra Wireless, and hardware integrators such as Omnisky.
In summary, the installed base of device/modem owners represents a golden business opportunity because:
- This is a large market segment
- These users can be provided with equivalent functionality to BlackBerry at zero cost, as opposed to the high cost of BlackBerrry
- These users are precisely known and reachable
This segment therefore provides the opportunity for very rapid initial deployment and propagation of the WhiteBerry solution. Beyond this segment, deployment of WhiteBerry solutions in general requires extremely low development cost, while offering truly gigantic upside potential.
The skeptical reader may have doubts that the LEAP-based WhiteBerry solution can succeed, on the grounds that it is a market newcomer, going head-to-head with an already established competitor—a sure-fire recipe for business failure.
This belief, however, represents a basic misunderstanding of the fundamental nature of WhiteBerry and BlackBerry. These are not peer competitors; rather, they are two entirely different business models, one of which has inherent long-term viability, while the other does not.
History shows that, other things being equal, the underdog loses. But in the case of BlackBerry and WhiteBerry, other things are far from equal. BlackBerry is a closed commercial construct; while WhiteBerry is an open and egalitarian industry enabler. Under these circumstances, history has very different lessons to teach.
In this case, a repeated historical pattern is for a new concept or technology to be initially deployed in the form of one or more closed, commercial implementations. Once these commercial implementations have proved the basic value proposition, they are followed by free and open implementations of the same concept, which then overtake and supplant the commercial implementations. There is no shortage of historical precedent for this. Consider the following examples:
- The proprietary networking protocols SNA from IBM, and DECnet from DEC, both of which were followed and rendered obsolete by TCP/IP
- Various closed operating systems, followed and rendered obsolete by GNU/Linux
- More recently, ASP (Microsoft’s server-based web development tools) followed and supplanted by PHP
In every one of these cases an entrenched solution, representing commercial vested interests and with aggressive industry backing, was supplanted by an open equivalent that at the outset had no industry backing at all. Anyone interested in the future of closed messaging systems would do well to study these case histories.
The BlackBerry/WhiteBerry scenario follows precisely the same pattern, and this is why WhiteBerry can and will prevail.
From the point of view of the commercial interests they supplant, these open usurpers have the effect of ruining a profitable business, typically without any apparent profit motivation on the part of the open system proponents. To the commercial interests, this appears to be an act of economic vandalism—the destroying of a viable business opportunity, for no good reason. For this reason, these open systems are often characterized as market “spoilers.”
But this is a narrow view. At the very least, open systems merely shift economic benefit from one place to another. And in virtually all cases, the industry-wide adoption of open systems results in greatly increased overall economic benefits.
WhiteBerry will certainly act as a spoiler for the closed Mobile Messaging industry. Simply by distributing LEAP in the form of open-source software solutions, we can ruin the market for any closed messaging solution.
In so doing, we will shift economic benefit from the closed system purveyors, to the many users who would otherwise have purchased a closed solution. But our intention is to accomplish far more than this simple dollar shift—our intention is to create greatly increased opportunities and benefits.
The key to accomplishing this resides in the participation of others. With this participation, WhiteBerry will move beyond being a mere industry “spoiler,” and will create enormous new business opportunities. We actively welcome and encourage such participation.
The losers in this will be the closed-system marketeers such as RIM. But the winners will be the many more companies who are able to participate in the Mobile Messaging market—and the end user who will benefit from the resulting competition and innovation.
In the data communications world, the era of the closed system is dying. This is because it has now become clear that:
In the domain of large-scale interconnected systems, open systems always displace closed systems.
The historical precedents for this are clear and irrefutable; yet despite this observation, businesses doggedly persist in deploying closed systems such as BlackBerry, or pseudo-open ones such as WAP. One may reasonably ask: Why is this? What is the great allure for businesses of closed systems?
The answer is that historically, closed systems have provided precisely the sort of classical sustainable advantage that MBAs are taught to seek. And there are certainly many business arenas in which closed systems do, in fact, provide a long-term competitive advantage.
However, the domain of large-scale interconnected systems is not one of them. In this domain things work differently, and here closed systems inevitably lose to open systems. But this domain is new, and its new rules are not yet well understood within the mainstream of business theory. Business thinking remains rooted in the traditions of conventional products and services, and continues to apply traditional principles to an entirely new domain, to which these principles do not apply.
But the opportunities for closed systems are diminishing. The time lag between the deployment of a closed system, and its supplantation by an open equivalent—i.e. its period of profitable tenure—is growing shorter. There is no better example of this than WhiteBerry itself, which is broadsiding BlackBerry even before it has fully left the ground.
At watershed moments like this, in which there is some sort of fundamental technological migration, the business community is always the last to know.
A perfect example is the case of wired e-mail. As recently as 1990, all members of the Electronic Mail Association (EMA) were in business terms solidly committed to X.400 (i.e. e-mail based on the telecommunications infrastructure, as opposed to the Internet infrastructure) as the long-term e-mail solution. But in the engineering world it was always perfectly clear that Internet e-mail (i.e. SMTP, POP etc.) would win out over telecommunications e-mail—as, of course, it did.
The evolution of WhiteBerry will likely be no different. At this point, WhiteBerry may seem radical and implausible to the business world, but this merely represents a general lack of understanding and imagination on the part of business. In the engineering world, the case for WhiteBerry is already conclusive. Initially therefore, it will be the responsibility of the engineering community to lead the way forward.
We refer to the widespread industry adoption of the WhiteBerry model, appropriately enough, as Operation WhiteBerry. The intended scope of Operation WhiteBerry is extremely broad. We are not proposing the creation of single integrated solution to compete with BlackBerry. Rather, we are proposing that WhiteBerry appear in multiple implementations within every component of the Mobile Messaging value chain:
- On all appropriate device platforms: Palm, Pocket PC, HandHeld PC, EPOC, cell phones
- Over all appropriate wireless networks: GSM/GPRS, Packet CDMA, CDPD, Wi-Fi/802.11
- Integrated with all appropriate mailbox applications: Microsoft Outlook, Netscape Messenger
- Integrated with all appropriate Message Center systems: sendmail, QMail, Microsoft Exchange
- In all appropriate scales and configurations: desktop, corporate, ISP
Clearly, this is not something that can be accomplished by any single company acting alone. In order to achieve the full potential scope of Operation WhiteBerry, participation and action throughout the entire Mobile Messaging industry will be required.
Operation WhiteBerry is first and foremost an engineering construct as opposed to a business one—we are not promoting a business model, or actively soliciting business partnerships. Operation WhiteBerry is an analysis of an industry problem, a proposed solution, and a roadmap for implementing this solution.
We intend to move forward with the implementation of this solution. We will continue to expand and enrich the development framework described in Section 5. We will continue to create additional device and Message Center software implementations of the LEAP protocols, and distribute these in the form of free, open-source software. Based on the starting point WhiteBerry implementation, we will create new and enhanced implementations. And we will continue to promulgate the WhiteBerry model throughout the engineering community.
By means of these activities, we expect to create a grass-roots awareness and adoption of the WhiteBerry model throughout the industry.
However, the scope of this awareness and adoption will be greatly augmented, and its pace will be greatly accelerated, by the proactive participation of others; and for this reason we have established a comprehensive framework to accommodate and support such participation. Details of this framework are provided in Section 8.5.
We therefore invite and encourage active participation throughout the industry community. The major challenges and opportunities are described in the following sections.
A variety of LEAP protocol engines are already complete and available. A base device LEAP protocol engine is available in the form of portable software that can be integrated with various devices, operating systems and platforms. A number of such device-side portations and integrations have already been completed, and portations to additional devices and platforms are in progress.
A Java/J2ME implementation of ESRO (a lower-layer LEAP protocol) has also been completed, allowing immediate deployment of ESRO in Java-enabled cell phones. Development of a Java implementation of EMSD is currently in progress; when complete this will allow deployment of the full WhiteBerry solution on Java-enabled phones.
All existing portations and implementations are freely available at MailMeAnywhere.org; in-progress implementations will be made available as they are completed.
Palm and Windows CE are the two most important device platforms for initial implementation of WhiteBerry, and open-source implementations of the LEAP protocols already exist for both these platforms. However, as described below, there are opportunities for enhancement, and we invite others to participate in this.
In addition, we invite others to port the LEAP software to additional general-purpose device platforms, based on the existing open-source implementations. In particular, we invite cell phone manufacturers to include the LEAP protocols as an integral part of their next generation devices.
Integration of the LEAP protocol engine with Windows CE has been facilitated by the existence of well defined APIs (Application Programming Interfaces) in the Microsoft Windows CE environment.
A standard mail application called Inbox is bundled with all Windows CE devices. Microsoft has defined a generic mail transport service provider interface underneath Inbox, which allows alternative mail submission and delivery protocols to be integrated with Inbox. Microsoft has also defined a winsock interface which provides access to UDP and TCP by third party applications.
These well defined APIs allow a new mail submission and delivery protocol to be integrated with Inbox in the Windows CE environment. For more information see the Manifesto article EMSD on Windows CE . The existing open-source implementation is available at http://www.mailmeanywhere.org. See Section 5.4 for more details.
In addition, recent versions of Windows CE now support the push mode of delivery, which, as we have noted, is an essential element of true Mobile Messaging. For these reasons, the existing portation/integration of the LEAP protocols with the Windows CE environment is mature and fully functional, including immediate delivery and notification to the user.
However, there are at least two desirable enhancements which can be made to the existing Windows CE integration:
- The Inbox mail application is fundamentally based on the classical e-mail retrieval (poll) paradigm, rather than
the pager-style delivery (push) paradigm. Though Windows CE now supports this paradigm, it is an add-on
feature which is not well integrated as a native capability of Inbox.
We invite the designers of the Inbox mail user agent to correct this shortcoming. We invite them to think of the Inbox application not just as a traditional mail user agent, but also as a paging application, and to include the appropriate facilities as a native part of the mail service provider interface. Meanwhile, implementations of LEAP in the Windows CE environment must take responsibility for this.
- In order to minimize battery power usage, it is very desirable for the integrated solution to make use of the wireless modem’s sleep mode of operation. The existing implementation of LEAP in the Windows CE environment includes the necessary virtualization layers for this purpose; however, the participation of the modem manufacturer is required to complete the necessary integration.
By now the importance of playing a major role in the Mobile Messaging industry cannot be lost on Microsoft. And Microsoft has a powerful set of directly relevant assets (MSN, Exchange, Windows CE etc.). Microsoft could easily build a closed Mobile Messaging solution based on these assets, and the temptation to do so must be very strong. However, we urge them to resist this temptation. Rather, we urge them to consider the long-term consequences of an open solution. These consequences include enormous industry growth, and corresponding benefits to the owners of assets precisely like those of Microsoft. Therefore a strategic decision by Microsoft to eschew closed in favor of open is not just an act of good corporate citizenship (not that this has ever been a major consideration for Microsoft)—it is also good business.
The inclusion of WhiteBerry capability has the effect of transforming a Windows CE device into a true Mobile Messaging device, and therefore represents an extremely powerful value-added component. In fact, we believe that the WhiteBerry value proposition is sufficiently strong to justify full integration of this capability into the operating system.
We therefore invite Microsoft to embrace the open WhiteBerry paradigm by including a complete implementation of EMSD as an integral part of the Windows CE distribution, rather than relying on third parties to do the necessary OS integration.
A mail application is included as a standard component in the Palm OS environment. In contrast to Windows CE Inbox, however, the Palm OS mail application has only a very basic set of features and capabilities. Also in contrast to Windows CE, in Palm OS there do not exist well defined APIs for integration of alternative mail protocols.
For this reason, integration of the LEAP protocol engine in the Palm OS environment has not been as convenient as in Windows CE.
To complicate matters further, various third party mail user agents have now become widely available for Palm OS (largely because of the inadequacy of the standard Palm OS mail application), with a variety of different user interfaces. Because of this multiplicity of incompatible Palm OS mail applications, each integration of LEAP with Palm OS is specific to a particular mail user agent.
The existing implementation of LEAP for Palm OS  is specific to the standard mail application, based on file access. This implementation is available at MailMeAnywhere.org. Further integrations and portations of LEAP for the Palm OS environment are currently in progress.
Like Microsoft, Palm has a powerful messaging-related asset in the form of its family of devices. Unlike Microsoft however, Palm has succumbed to the temptation to build a closed solution based on this asset; it has recently announced its intention to bring a Mobile Messaging solution to market by the middle of 2001 . As in the case of Microsoft, and for precisely the same reasons, we urge Palm to reconsider this decision.
Just as for Windows CE, WhiteBerry capability represents a powerful value-added component for Palm OS, and again justifies its full integration into the operating system. As in the case of Microsoft, therefore, we also invite Palm and Handspring to adopt the open WhiteBerry paradigm by including a complete implementation of EMSD as an integral part of Palm OS.
More than any other constituency, the participation of the wireless modem manufacturers is essential for Operation WhiteBerry. We invite modem manufacturers such as Sierra Wireless and Novatel to include the LEAP protocols as an integral part of their next generation devices.
In addition, there is a requirement for tight integration between the modem and the protocol software for proper sleep mode operation. The modem must always remain ready to receive messages; then as soon as a message arrives the modem must wake up, acknowledge it at the correct level, and deliver it to the user. The current level of integration is inadequate for this. The involvement of the modem manufacturers is essential to achieve the required integration.
Historically, modems have been thought of as a device that resides at or below Layer 3, and modem manufacturers continue to think of them this way.
However, the wireless modem is the key, non-generic hardware component of any Mobile Messaging device. The combination of a wireless modem and a PDA is fully capable of being a Mobile Messaging device—all that is required is that the LEAP protocol engine be included with the modem.
Our challenge to modem manufacturers is therefore this: Why not think of your device, not just as a pure Layer 3 device, but as a Mobile Messaging device? What reason is there to limit yourself to building and marketing modems, when the proven market application is Mobile Messaging devices? The costs of moving into this market are negligible, while doing so provides the following major business advantages:
- Allows immediate entry into the applications market above Layer 3.
- Makes your product of immediate value to the end user, allowing you to target this market directly.
- Allows you to establish a direct relationship with the end user, including brand-name awareness on the part of the end user.
- As modems increasingly become a commodity item, allows your product to remain distinct from generic competitors.
The traditional technological role of modems, that their manufacturers continue to maintain as a self-imposed limitation, is no longer valid. By stepping beyond this limitation, modem manufacturers can address a gigantic new market.
To direct our challenge towards a specific set of companies, we will take the case of the CDPD network as an example. The major manufacturers of CDPD modems are: Sierra Wireless, Novatel, Tellus and Nextcell (now Enfora). So our challenge to these four companies is this: What argument do you have with any of this?
The discussion we have presented above is not limited to the traditional add-on modem, but applies more generally to any appropriate airlink device. In particular, the discussion applies to cell phones that have data communications capabilities. While airlink functionality is usually provided to a PDA device by means of an add-on modem, the airlink requirement can in principle also be provided by a data-capable cell phone—provided the cell phone has a suitable means of communicating with the PDA.
Under such circumstances the add-on modem can be dispensed with, and the user can be provided with Mobile Messaging capability by means of a data-capable cell phone, closely integrated with a PDA. Since both the cell phone and the PDA can be best-in-class, user’s-choice devices, this represents a very powerful implementation of the WhiteBerry model. This scenario is described in greater detail in the Manifesto article WhiteBerry and BlueTooth .
An alternative to the physically separate cell phone and PDA is the integrated cell phone/PDA, which provides the user with voice communications, Mobile Messaging, and traditional PDA data management capabilities, all in a single device.
Regardless of the relationship between the cell phone and the PDA, we invite the cell phone manufacturers to adopt the Internet End-to-End model, and include the LEAP protocols as an integral part of their devices. Note that in the case of Java-capable cell phones, the availability of the Java/J2ME implementation of LEAP allows the phone to be immediately WhiteBerry-enabled.
Existing network infrastructures are already adequate for Mobile Messaging applications; however, there are several technical enhancements that can improve the value proposition to the end user.
The key network-based user expectation is ensured reachability. In other words the user wants to be able to go anywhere, and still be confident that he will get his messages. The way in which the network can raise the satisfaction of this expectation is by means of increased coverage. Therefore a steadily increasing coverage footprint will result in steadily increasing end user satisfaction.
A further network-related user requirement is battery lifetime. Two specific ways in which the network can increase battery longevity are by means of increased cell density, and by the implementation of network protocols for highly efficient device sleep mode.
Perhaps more important than these technical enhancements, network operators must also modify their business thinking, or run the risk of being bypassed.
Existing telecommunications-based and phone-based Mobile Messaging solutions are severely limited. Although Short Message Service (SMS) has experienced widespread usage it is not IP-based, and is therefore inconsistent with the Internet model. For this reason it cannot be considered a long-term strategic solution, and will eventually be replaced by mainstream Internet solutions.
The continued focus of the telecommunications industry on non-end-to-end services such as SMS is a hindrance to the development of the Mobile Messaging industry. The telecommunications industry must recognize that their continued investment in dead-end technologies like SMS and WAP is counterproductive, and must shift their focus towards alignment with the Internet model.
The crucial issue with regard to network operation—both in technical terms and in business terms—is that of conformity to the Internet End-to-End model. While a wireless network such as CDPD may conform to the Internet End-to-End model in technical terms, its operators may greatly inhibit End-to-End usage by means of their business practices. They may limit End-to-End usage by means of high pricing of such usage, while simultaneously subsidizing network access by controlled gateways such as WAP. The result is that in practical terms the network is only available for privileged, non-End-to-End usage—it becomes what is sometimes referred to as a Walled Garden.
This type of access-controlling business practice has historically been very successful for network operators, and it remains a well entrenched part of their business thinking. However, times have changed, and it has now become greatly to their advantage to commit fully to the Internet End-to-End model. In this model, the network operator is first and foremost a Layer 3 access provider. The network operator may also be a systems integrator, or an application service provider. But it must do so fairly, and it must fully respect the equal access principle.
The fundamental goal of a network operator is to generate high volumes of premium-revenue traffic through its network. By adopting the open WhiteBerry model and the Internet End-to-End model, network operators can greatly increase both the volume and the revenue-generating value of the traffic they carry. This is because:
- Mobile Messaging consists of inherently high-premium traffic, since its primary value is in delivering urgent messages or time-critical information to the user
- The open WhiteBerry model generates greatly increased volumes of this high-premium traffic
- The WhiteBerry model requires that the underlying network conform fully to the Internet End-to-End model
Inevitably, some network operators will realize this sooner than others, and we can also expect a general reluctance on the part of the operators to change their business models. However, the inherent growth characteristics of the End-to-End model, and competitive forces among the network operators, will ensure its eventual adoption.
In the longer term, a variety of other mobility-oriented applications and services will need to be integrated with the Mobile Messaging application. We believe that eventually, all such services will be based on the same sort of open model as WhiteBerry.
We invite Application Service Providers (ASPs) such as AOL, Yahoo and AT&T to participate in the general concept of open-model services—i.e. services which are based on free protocols and open-source software, and which are fully consistent with the Internet End-to-End model. As a starting point, we invite these providers to integrate the appropriate members of the LEAP family of protocols into their suite of Subscriber Services.
An example of open-model services, available for examination and inspiration, is provided by the free ByName Services at http://www.ByName.net. The ByName Services are the world’s first Libre Services, based entirely on patent-free protocols and free software.
By integrating the LEAP Message Center software into their existing messaging services, Application Service Providers can offer WhiteBerry service immediately. Our challenge to ASPs is this: What possible reason is there to do otherwise? Consider the following:
- Wireless applications are undergoing explosive growth
- Wireless networks are converging on IP
- LEAP-based Message Center software is available as free, open-source software
It is clear that the costs are negligible, while the benefits are huge.
As described in Section 5.4, it is already possible to put together a fully functioning WhiteBerry Mobile Messaging solution based on existing products, software and services. However this requires specialized knowledge, and is time-consuming and inconvenient. The typical individual or corporate consumer cannot be expected to do this sort of custom integration.
The typical WhiteBerry consumer will require a complete, fully-integrated, out-of-the-box working solution—like BlackBerry, in fact. Clearly, there is a major systems integration opportunity here.
We therefore invite systems integrators such as Omnisky to assemble all the required components into a multi-platform, turnkey solution for the end user.
As we have previously noted, Omnisky and other service providers have already marketed mobile e-mail solutions based on inadequate land-based Internet protocols, which, not surprisingly, have done extremely poorly in the face of the superior functionality of BlackBerry. By adopting the LEAP-based WhiteBerry model, these companies can deliver true Mobile Messaging functionality which equals or exceeds that of BlackBerry.
The Message Center software arena is currently dominated by three major systems: the Unix sendmail system, QMail, and Microsoft Exchange. These are therefore the most important Message Center systems for initial implementation of WhiteBerry, and the LEAP protocols must be integrated as a specific mail submission and delivery component of these systems.
We therefore invite the developers of Message Center software to create and/or enhance integration of LEAP with these systems. We also invite the developers and integrators of complete, customer-premise Message Center solutions to incorporate LEAP into their existing products.
In addition, a major opportunity exists for the integration of the core WhiteBerry capability (i.e. wireless submission and delivery) with a variety of other messaging features and tools such as: rule-based message processing and forwarding, custom mailbox synchronizers, firewall bypasses, and Message Center management tools. By means of these and other integration implementations, Message Center integrators can build a rich and diverse capability on top of WhiteBerry.
Organizations and individuals who wish to participate in Operation WhiteBerry can do so in several ways, and there are a number of resources available to assist such participation. These resources include:
- The LEAP Forum at
- The EMSD Organization at
- The ESRO Organization at
- The MailMeAnywhere open-source software distribution center and development forum at
EMSD.org, ESRO.org and MailMeAnywhere.org are oriented towards engineering development and usage of the LEAP protocols. ESRO.org and EMSD.org are development forums for their respective protocols, while MailMeAnywhere hosts a public forum for the collective development and enhancement of LEAP protocol engines and integration tools.
LeapForum.org is oriented towards coordinating usage of the LEAP protocols from a business development perspective; it provides a means for companies to announce their participation in Operation WhiteBerry, seek out business partners, and coordinate cooperative effort.
All of these forums host a number of mailing lists to enable different forms of participation.
Organizations and individuals who wish to participate in the development and enhancement of the LEAP protocols themselves can do so via the appropriate mailing lists at EMSD.org and ESRO.org.
Those who wish to participate in WhiteBerry from a systems integration point of view will need to determine what components are available, and evaluate their merits. By joining the relevant mailing lists at MailMeAnywhere.org, integrators can advise component suppliers of their requirements and interests; while suppliers can let integrators know about available products and components.
We also welcome and encourage participation by individual or ad hoc users such as early self-integrating adopters, individual programmers, or those who wish to contribute written materials. Programmers who wish to enhance the LEAP software or port it to new environments can build on the existing GPL code, then return their enhancements to the base software through MailMeAnywhere.org. Those who are interested in promoting the WhiteBerry model may do so by contributing additional material to The LEAP Manifesto, revising existing material, translating the Manifesto into foreign languages, or contributing written materials to other forums.
Participants who wish to implement the WhiteBerry model will need to get the necessary LEAP software, and there are three basic options for doing this. First, free open-source software implementations for both devices and message centers is available at MailMeAnywhere.org. This open-source software is distributed under the GNU General Public License (GPL), permitting a broad range of uses of the software. Those wishing to use this free software are invited to join the relevant mailing lists at MailMeAnywhere.org. MailMeAnywhere also provides various other resources to support usage and growth of this free software base.
There are certain situations in which use of the GPL is not appropriate, such as the incorporation of software into cellular phones. Under these circumstances the source code can be licensed from a commercial supplier such as Neda Communications, Inc. (http://www.neda.com).
As a third option, WhiteBerry adopters may develop LEAP software on their own, based on the patent-free protocol RFCs. Those wishing to do so are encouraged to join the relevant mailing lists at EMSD.org and ESRO.org.
In this article we have focussed on LEAP and WhiteBerry in terms of a specific application, namely, interpersonal Mobile Messaging. But this is just the beginning. WhiteBerry is also the starting point for a more general set of wireless messaging applications and usages; and the LEAP protocols are the starting point for a more general set of Internet services.
The WhiteBerry model can be augmented and expanded in various ways to create new wireless messaging applications; the following are some examples.
- Broader forms of usage. Note that person-to-person messaging is a special case of a more
general set of communications scenarios, which also includes person-to-machine, machine-to-person, and
machine-to-machine messaging. Existing e-mail applications already encompass these other scenarios; for
example, person-to-machine messaging applications include the use of e-mail robots which can be invoked by
the user to accomplish various tasks; while machine-to-person messaging applications include various sorts of
automatic e-mail alert and notification services.
All this existing capability can be immediately brought to the wireless world by means of WhiteBerry. In other words, in addition to providing interpersonal Mobile Messaging services, WhiteBerry can also function as a generalized efficient message transfer infrastructure, which generic applications can use to deliver message-related services to the user.
- Greater richness of content. The capabilities of WhiteBerry can also be expanded in terms of richness of
information content. Though the content of interpersonal messages typically consists of plain text only, this
basic information payload can be augmented with more complex forms of content—for example, a variety
of MIME attachments have been defined which greatly enhance the utility of conventional e-mail. Similar
content-expanding features can readily be brought to the wireless domain by incorporation into the WhiteBerry
Note that the implied message shortness of the WhiteBerry model is not necessarily in conflict with richness of content. This simply means that such content must be appropriate to the wireless and mobile domain—it must bring added value to the user, without violating message size restrictions. An example of such content is the use of embedded responses, in which the message originator provides the recipient with a set of pre-defined, multiple-choice replies from which to select .
- Expanded usage patterns. E-mail has traditionally been considered an asynchronous activity, and unsuitable
for real-time or near-real-time usage. However, since a mobile user is available for communication to a far
greater extent than a desktop user, and since the efficiency of the LEAP protocols permits very rapid message
exchange, various interactive applications can be built on top of WhiteBerry.
A good example is Instant Messaging. Note that in this application the exchanged messages are by nature very short, and therefore the efficiency of EMSD brings a significant performance premium. The LEAP protocols can readily be used to extend existing Instant Messaging capabilities to mobile devices. This extension of the WhiteBerry model requires only simple integration with existing Instant Messaging solutions, and with existing facilities such as Presence Management and Location Management.
- Location-based applications. The availability of mobile device location information enables numerous location-based applications such as taxi dispatch, driving directions, local weather conditions, availability of local products & services, emergency assistance, and many more. Location information can also be integrated with Mobile Messaging services to provide the user with a powerful set of new applications. For a comprehensive and imaginative survey of the location-based services domain, see WaveMarket’s white paper entitled Location, Presence and Event-Driven Mobile Applications, available on the WaveMarket website at http://www.wavemarket.com/. Many of the applications described in that document can be built on top of WhiteBerry.
It is also worth noting that the LEAP family of protocols has broader scope than just WhiteBerry messaging. WhiteBerry is part of a larger family of LEAP-based applications, which also includes other applications such as LEAP-based web applications. These applications can be tightly integrated, so as to provide a consistent package of capabilities to the user.
Note in particular that use of ESRO is not limited to WhiteBerry. ESRO is a generic enabling foundation, upon which a variety of efficient applications can be built. For more information on generalized uses of ESRO, refer to the Manifesto article ESRO: A Foundation for the Development of Efficient Protocols.
In Operation WhiteBerry we have established a framework that can continue to be built upon to bring tremendous benefits to the wireless industry and the consumer.
BlackBerry has conclusively established the validity of the Mobile Messaging value proposition. The popularity of BlackBerry clearly demonstrates the large user demand for this type of service, and the correspondingly large market opportunity. There can no longer be any doubt about the future growth and importance of the Mobile Messaging industry.
The Mobile Messaging industry of today is populated by a number of systems which are closed, which do not interoperate, and which violate the Internet End-to-End principle. In the long run this situation is untenable. Sooner or later, the industry must adopt a single set of open protocols that guarantee industry-wide interoperability. This will enable market entry and competition across the entire Mobile Messaging value chain. The result will be better solutions for the consumer, and enormous market rewards for the providers of those solutions.
The opportunity to do this now exists. The three key technological components are all in place:
- A variety of suitable unconscious carry devices are available, and at the right price points
- Suitable IP-based wireless networks with adequate coverage are in place, and there is a continuing convergence of all networks towards IP
- Wireless modems are available for a variety of networks, and with adequate battery life
The final enabling component is a set of truly open and free protocols; and this last piece is now also available in the form of LEAP.
Given that everything is in place, there remains only one obstacle to the open Mobile Messaging industry: the will of the industry itself. Operation WhiteBerry is no longer a matter of technological development. It is now a matter of consensus, collaboration and integration.
There is nothing in this article that is remotely theoretical or speculative. All the technological components for WhiteBerry are real and operational now. Any data communications professional can acquire the necessary components, and begin enjoying his fully functional WhiteBerry mobile messaging system today. A systems integrator or industry alliance can create a fully integrated open equivalent to BlackBerry and bring it to market within 90 days.
RIM has demonstrated the enormous market potential of Mobile Messaging, and is reaping the profits. Meanwhile, the entire community of potentially competing device manufacturers, modem manufacturers, network service providers, Message Center operators, and systems integrators stands idly by, gazing blankly off into space.
At the time of writing in November 2002, the state of the Mobile Messaging industry resembles nothing so much as a surreal game of musical chairs, in which nobody seems to have realized that the music has stopped. The chairs are all sitting there, empty. There ought to be a mad scramble to sit in them. Yet inexplicably, there is not.
But sooner or later, there certainly will be. And those industry players that realize this soonest, and stake their claims quickest, will be the ones that enjoy the most commanding first-mover advantage.
We gratefully acknowledge the assistance of the following persons in the preparation and review of this document: Payman Arabshahi, German Burtscher, Matt Champagne, John Coffey, Murat Divringi, Tom Huseby, Bahman Khamneian, Pean Lim, Derrell Lipman, Mike Marks, Daryoush Mehrtash, Mark Taylor, and Pinneke Tjandana.
 Mohsen Banan. Efficiency of EMSD. A component of LEAP Manifesto, LEAP Forum, January 2000. Online document is available at http://www.LEAPForum.org/leap.
 Mohsen Banan. EMSD: The LEAP E-mail Component. A component of LEAP Manifesto, LEAP Forum, January 2000. Online document is available at http://www.LEAPForum.org/leap.
 Mohsen Banan. The LEAP Protocol Development Model. A component of LEAP Manifesto, LEAP Forum, January 2000. Online document is available at http://www.LEAPForum.org/leap.
 Mohsen Banan. WhiteBerry and BlueTooth. A component of LEAP Manifesto, LEAP Forum, January 2000. Online document is available at http://www.LEAPForum.org/leap.
 Mohsen Banan. LEAP on Palm OS. A component of LEAP Manifesto, LEAP Forum, September 2001. Online document is available at http://www.LEAPForum.org/leap.
 Free Protocols Foundation. Position Statement regarding the RIM Mobile E-Mail Patent Assertion. FPF Published Document, Free Protocols Foundation, July 2001. Online document is available at http://www.freeprotocols.org/position-rim-6219694.
 Mohsen Banan. EMSD on Windows CE. Neda Published Document 103-101-01.02, EMSD Organization, 1998. Online document is available at http://www.emsd.org/pubs/biblio/103-101-01-02/index.html.
 Mohsen Banan. Embedded Response Mime Message Type. Neda published document, Neda Communications Inc, February 1999. Online document is available at http://www.emsd.org/documents/whitePapers.html.
 Mohsen Banan. Lightweight & Efficient Application Protocol (LEAP) Manifesto. Technical Report 108-101-01, LEAP Forum, Bellevue, WA, January 2000. Online document is available at http://www.leapforum.org/LEAP/Manifesto/completeManifesto.
 Mohsen Banan. The WAP Trap. FPF Published Document 108-102-01, Free Protocols Foundation, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/wapTrap.