next up previous contents index
Next: A Brief History of Up: Executive Summary Previous: Expect the Unexpected   Contents   Index

Our Solution

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

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

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

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

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

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

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

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

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

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

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


next up previous contents index
Next: A Brief History of Up: Executive Summary Previous: Expect the Unexpected   Contents   Index