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:
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 [17]. 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:
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.
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 [6] 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 [24]. 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:
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 [5].
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:
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:
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:
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.