W3C home > Mailing lists > Public > ietf-discuss@w3.org > September 2000

The LEAP Manifesto -- Executive Summary

From: Mohsen BANAN <public@mohsen.banan.1.byname.net>
Date: Mon, 18 Sep 2000 01:18:33 -0700 (PDT)
Message-Id: <200009180818.BAA14084@rostam.neda.com>
To: discuss@apps.ietf.org, ietf-mmms@imc.org, ietf@ietf.org






                    The
Lightweight & Efficient Application Protocol
                   (LEAP)
                 Manifesto



  Shaping the Future of Mobile & Wireless
           Applications Industry

             A Call to Action



             EXECUTIVE SUMMARY


                Mohsen Banan
     <public@mohsen.banan.1.byname.net>



                Version 0.5
               July 17, 2000


Copyright (c)2000 Mohsen Banan.


Permission is granted to make and distribute verbatim
copies of this manual provided the copyright notice and
this permission notice are preserved on all copies.



Contents
========


1  Executive Summary

   1.1 Technological Scope
   1.2 Efficiency is the Key Requirement
   1.3 Conventional Origins of Protocols
   1.4 Expect the Unexpected
   1.5 Our Solution
   1.6 A Brief History of LEAP
   1.7 Making Our Solution Widespread
   1.8 Complete and Ready
   1.9 Getting the Complete Manifesto



1  Executive Summary
====================

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

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

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

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

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

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


1.1  Technological Scope
------------------------

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

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

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


1.2  Efficiency is the Key Requirement
--------------------------------------

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

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

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

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

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

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


1.3  Conventional Origins of Protocols
--------------------------------------

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


 1. The major players in the industry itself.  In
    the case of wireless communications, this
    means the major telecommunications and
    wireless network companies.

 2. Professional protocol and standards producing
    associations.  In the case of wireless
    communications, this means the IETF, ITU, ISO,
    ANSI, TIA and others.

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

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


1.4  Expect the Unexpected
--------------------------

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

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


1.5  Our Solution
-----------------

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

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

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

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

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

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

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

Our Efficient Mail Submission and Delivery (EMSD)
protocol is built on top of ESRO, and is designed
to address the Mobile Messaging application.
Both of these protocols have been published as
Internet RFCs:  ESRO as RFC 2188, and EMSD as RFC
2524.  RFC publication ensures that the protocols
are freely, easily and permanently accessible to
anyone who wishes to use them.

Note that this also is in stark contrast to WAP,
which is self-published by the members-only WAP
Forum.  Furthermore, the WAP Forum reserves the
right to make unilateral changes to its protocols;
each of the WAP protocols carries on its cover
page the disclaimer, ``subject to change without
notice.''
Publication of a protocol as an Internet RFC
ensures that the protocol will remain stable and
permanently available to anyone who wishes to use
it, and for this reason is the mainstream Internet
publishing method.  The declining of the WAP Forum
to publish their specifications as Internet RFCs
suggests either that the forum wishes to retain an
inappropriate degree of control over the
specifications, or that the specifications do not
meet the minimum technical standards required for
RFC publication.


1.6  A Brief History of LEAP
----------------------------

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

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

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


1.7  Making Our Solution Widespread
-----------------------------------

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

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

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

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

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

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


1.8  Complete and Ready
-----------------------

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


The Protocols. The protocols are well-designed,
    meet all the technical requirements of the
    industry, and are published as RFCs -- the
    mainstream Internet publishing procedure.
    http://www.rfc-editor.org provides the
    complete text of RFC 2188 and RFC 2524.

Open Maintenance Organizations. The protocols are
    maintained at EMSD.org and ESRO.org, allowing
    open and non-exclusionary participation in the
    maintenance of the protocols.
    http://www.esro.org and http://www.emsd.org
    provide complete details.

Freedom from Patents. The protocols are
    patent-free to the best of our knowledge, and
    are guaranteed to stay that way.  This ensures
    permanent, unrestricted access to the
    protocols.
    http://www.FreeProtocols.org provides further
    information.

Open-Source Software Implementations. These are
    being made available for a wide variety of of
    platforms and end-user devices:  pagers and
    cell-phones; hand-held PCs (Windows CE, Palm
    PC) and Palm Pilot; Windows 98, Windows 95,
    and Windows NT; Pine (UNIX, Windows, DOS).
    http://www.MailMeAnywhere.org provides
    complete details.

Free Subscriber Services. These are provided to
    support initial deployment of the protocols in
    end-user devices.
    http://www.ByName.net and
    http://www.ByNumber.net provide complete
    details.


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


1.9  Getting the Complete Manifesto
-----------------------------------

This Executive Summary provides an overview of
what we are trying to do.  For complete details on
every aspect of our vision, see the full
manifesto, available at the LEAP Forum website at
http://www.LEAPForum.org/leap

This Executive Summary and the full Manifesto are
available in HTML, PostScript, PDF, and plain text
formats.
Received on Monday, 18 September 2000 04:37:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:27 GMT