Subject: WAP Is A Trap -- Reject WAP

From: Mohsen BANAN-Public <[email-masked]>
Date: 20 Jun 2000 06:49:13 -0000

[ Please distribute this as widely as possible, wherever appropriate. ]

----

                   The WAP Trap

  An Expose of the Wireless Application Protocol

 Mohsen Banan <[email-masked]>
                       for:
           Free Protocols Foundation
          http://www.FreeProtocols.org

                  Version 1.6
                  May 26, 2000

Copyright (c) 2000 Free Protocols Foundation.

Published by:
Free Protocols Foundation
17005 SE 31st Place,
Bellevue, WA 98008 USA

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.

Contents
========

1   Introduction
   1.1  The Wireless Application Protocol (WAP)
   1.2  Characteristics of Successful Protocols
   1.3  About this Document 
       1.3.1  Alternative Formats 
       1.3.2  Acknowledgments 
       1.3.3  Conflict of Interest Disclosure

2   WAP - A Procedural Fraud   
   2.1  Not Open in Terms of Development and Maintenance 
   2.2  No Assurance of Availability and Stability
   2.3  Not Patent-Free 
   2.4  No Legitimacy as a Standard  

3   WAP - A Technical Failure
   3.1  User Interface Assumptions 
   3.2  Extreme Accommodation to Existing Networks
   3.3  Excessive Re-Invention in the Name of Wireless 
   3.4  Vulnerable Wireless Transport Layer Security (WTLS)
   3.5  Bungled Protocol Number Assignment 

4   WAP - A Basic Misconception 
   4.1  The Wrong Answer Initially:  Mobile Web Browsing 
   4.2  The Right Answer Initially:  Mobile Messaging
   4.3  Unsupported Claims 
       4.3.1  Not Device-Independent
       4.3.2  Limited Web Browsing Capabilities
       4.3.3  Existing Technology Adequate
       4.3.4  Voice Interface Adequate 

5   Conclusion:  WAP is a Trap 

6   Preventing the Harm of WAP  
   6.1  Reform the WAP Forum   
   6.2  Spread the Word about the WAP Fraud 
   6.3  Reject WAP at Engineering Level 
   6.4  Reject WAP at Consumer Level 
   6.5  Adopt an Alternative to WAP 

7   LEAP: One Alternative To WAP

1   Introduction
================

The new Internet reality is that of wireless
networks, providing service to legions of
miniaturized, hand-held mobile devices.  This
places an entirely new set of requirements on the
underlying communications protocols -- they must
provide the power efficiency demanded by hand-held
wireless devices, together with the bandwidth
efficiency demanded by wide area wireless
networks.

At some point, the wireless data communications
industry must agree on a common set of standard
protocols that satisfies these requirements.
Unfortunately, the road to an industry standard is
a rocky one.  The wireless industry is populated
by a number of disparate constituencies and
self-interests.  Among these constituencies are
the technical community, with its fundamental
mandate to create sound engineering solutions, and
the business community, ultimately driven by the
pursuit of profit and marketplace advantage.  The
differing agendas of these constituencies
frequently bring them into conflict.

In this confusing environment it can be very
difficult to distinguish between developments that
are genuine, enabling technologies, and those that
are ill-conceived wild-goose chases.

1.1   The Wireless Application Protocol (WAP)
---------------------------------------------

Into this chaotic arena comes WAP. On April 30
1998, a group of business interests published a
set of specifications referred to as the Wireless
Application Protocol, or WAP. WAP is a
specification for wireless data communications
using hand-held devices such as mobile phones and
palmtop computers.  Use of the WAP specification
allows mobile devices to communicate with the
Internet or an intranet, providing the users of
these devices with mobile data communications
capabilities such as web-browsing and e-mail.
The WAP specification was developed by the WAP
Forum, an industry association of wireless device
manufacturers, service providers, and software
companies.  The WAP Forum was founded in June 1997
by three mobile phone manufacturers (Ericsson,
Motorola and Nokia), together with the US software
company Phone.com (formerly Unwired Planet).  The
WAP specification is largely the product of these
four founding companies.  Further information
about the WAP Forum can be found at its website at
http://www.wapforum.org/.

The Wireless Applications Protocol purports to be
just what the doctor ordered:  a set of standards
that will unify the wireless data applications
industry.  WAP presents itself as an open,
license-free standard for wireless Internet
access.  It claims to be a well-designed
engineering construction, allowing free
interoperability among wireless industry vendors.
It claims to be an enabling technology that will
catalyze the development of the wireless industry,
to the ultimate benefit of the industry and the
consumer.

As we will argue in this article, however, WAP
satisfies none of these claims.

1.2   Characteristics of Successful Protocols
---------------------------------------------

Industry standards do not usually come about as
the result of an orderly design process.
Especially in the early stages of industry
development, protocols and standards arise
organically, and without the benefit of hindsight.
Because of this, early protocols are frequently
very much less than ideal.  As Bill Joy, the
founder of Sun Microsystems, puts it,

    "Sometimes when you fill a vacuum, it
    still sucks."

Though his phrasing leaves much to be desired, his
point is beyond debate:  the most appalling
solution is better than no solution at all.

However, history has shown that successful
protocols tend have certain characteristics in
common.  By a "successful" protocol, we mean one
which becomes accepted as an industry standard in
the face of competing protocols, endures as an
standard in the long term, and serves to promote
the growth of the industry.

The key characteristics of a successful protocol
are:

 1. Adequate Technical Design.  It should address
    the basic technical requirements of the
    industry.  This means that the protocol must
    primarily be an engineering construct, not a
    business one.

 2. Open Development and Maintenance Process.
    Some form of mechanism should exist for public
    commentary on the protocol.  The protocol
    should be maintained by a process that allows
    the participation of the various
    constituencies that are affected by the
    protocol.

 3. Open Availability Process.  It should be
    published and made available in a way that
    ensures that it is freely, easily and
    permanently accessible to anyone who wishes to
    use it.

 4. Freedom from Usage Restrictions.  There should
    be no restrictions on the use of the protocol.
    Anyone who wishes to base an application on
    the protocol should be able to do so without
    legal or financial hindrance of any kind.

Not all successful protocols have all these
attributes.  Nevertheless, as the history of
protocol development demonstrates, the more a
protocol conforms to these attributes, the more
likely it is to become an enduring industry
standard.  An analysis of several successful and
failed protocols, supporting this conclusion, is
provided in The LEAP Manifesto [13].

WAP claims to have all four of the above
attributes.  In fact, it has none of them.  WAP
has claimed center stage not because it fulfills
the needs of the industry, but because thus far,
no viable alternative has been presented.

1.3   About this Document
-------------------------

In this article we will show that WAP is entirely
unfit for the purpose being claimed for it.  We
will show that it is handicapped as a result of
the processes the WAP Forum has used to develop
it, and that it includes numerous serious
technical design errors.  Our conclusion will be
that the WAP specification is essentially a
marketing construct, rather than an engineering
one.  It is designed to provide short-term
financial benefit to a minority of the WAP Forum
members, rather than providing long-term benefit
to the industry at large and the consumer.

We will then enumerate and analyze the steps that
can be taken to prevent the harm of WAP. One of
the most crucial steps will be to identify
alternatives to WAP, and eventually adopt one of
these in place of WAP.

Finally, we will propose one alternative to WAP,
namely LEAP, the Lightweight and Efficient
Application Protocol.  We provide a brief
description of LEAP, and provide references to
where further information on LEAP can be found.
This article is one of a series of articles we
have written that analyze the current status of
the wireless data communications industry,
criticize WAP, and present our view of what is
truly needed to promote the growth of the
industry.  Other articles in this series are:

  o LEAP: One Alternative to WAP [12].  A
    companion paper to this one, taking over where
    this leaves off.  The scope of the current
    paper is largely limited to a critique of WAP.
    This companion paper describes a specific
    alternative to WAP.

  o The LEAP Manifesto [13].  This paper provides
    a complete analysis of the industry, and a
    detailed description of the LEAP protocols.

1.3.1   Alternative Formats
---------------------------

This document is available in several alternative
formats at the Free Protocols Foundation website
(http://www.FreeProtocols.org/wapTrap):

  o ONE-HTML: Displays the entire document as a
    single web page.

  o SPLIT-HTML: Displays the document as a set of
    linked web pages, starting from the Table of
    Contents.

  o PDF: Provides the document in Adobe Acrobat
    format.  Note that the Adobe Acrobat Reader is
    required to read this format.  The Acrobat
    Reader can be downloaded from the Adobe
    website.

  o PS: Provides the document in PostScript format
    for printing.

  o Text Only:  Provides the document in text-only
    format.

1.3.2   Acknowledgments
-----------------------

We gratefully acknowledge the assistance of the
following persons in the preparation and review of
this document:  Andrew Hammoude, Richard Stallman,
Bill Frezza and Rob Mechaley.

1.3.3   Conflict of Interest Disclosure
---------------------------------------

The authors of this article were also the initial
developers of LEAP, and therefore have a vested
interest in the success of LEAP over WAP.

However, we are also active participants in the
Free Protocols Foundation (FPF), under whose
auspices this article is being written.  As
participants in the FPF, we are fully committed to
its patent-free principles; principles which WAP
violates completely.  The mission of the Free
Protocols Foundation is to provide support for
patent-free protocols.  Part of this mission is to
provide support for patent-free alternatives to
patented protocols such as WAP. It is in the
spirit of this mission that this article is being
written.

The purpose of this article is not to promote LEAP
or any other particular alternative to WAP. The
purpose of this article is to expose the harm of
WAP and describe the steps that can be taken to
prevent it.  Any other viable alternatives to WAP
that are brought to our attention, and that
conform to the principles of the Free Protocols
Foundation, will be promptly referenced at the FPF
website, and included in subsequent versions of
this article.

The most recent version of this article,
describing all known alternatives to WAP, will be
maintained on the FPF website at
http://www.FreeProtocols.org.

2   WAP - A Procedural Fraud
============================

There are two distinct sets of problems relating
to WAP: procedural, and technical.  In this
section we will describe the procedural problems.
The procedural problems lie in the processes that
the WAP Forum has used to develop and disseminate
the WAP specifications.

2.1   Not Open in Terms of Development and Maintenance
------------------------------------------------------

A highly desirable attribute of an industry
standard protocol is that it be the result of an
open design process.  What this means is that,
somewhere along the line, the various
constituencies that have a stake in the protocol
be given a voice in its development.

This does not mean that the protocol must be
conceived and built from the ground up by
industry-wide consensus.  Indeed, this is usually
impractical, and of necessity, the first drafts of
any protocol are usually created by a small group,
functioning autonomously.

An open design process means only that at a
certain point, ownership of the protocol must
become public.  Beyond that point, the various
industry constituencies must be given an
opportunity to participate in its design, and the
design process must include mechanisms for
reaching consensus among conflicting lobbies.
Openness of design has two important benefits.
First, it allows the protocol to be subjected to
adequate technical review, ensuring that it is a
sound engineering solution.  Second, it prevents
the design of the protocol from being excessively
influenced by minority business self-interests.
An open design process provides vital assurance of
the integrity of the resulting protocol, in both
engineering and business terms.

The WAP specification is in complete violation of
these principles.  The specification has been
developed exclusively by the WAP Forum, entirely
behind closed doors, and without the benefit of a
single public mailing list for discussion and
review.  The WAP Forum permits no outside
influence over the specification; the only
institutions that my participate in its
development and maintenance are the WAP Forum
members themselves.

The WAP Forum claims that the specification is
open, on the grounds that any company or
organization is free to join the forum.  While
technically this is true, membership in the Forum
carries a $27,000 entrance fee (as of February
2000).  In practice, this fee effectively excludes
most small businesses, and virtually all academic
institutions.

The WAP Forum is therefore a highly restricted
subset of the business and academic community, and
influence over the specification is limited to
those companies that can afford this entrance fee.
The specification is thus the creation of a
limited constituency of the telecommunications
world; specifically, it is primarily the creation
of a set of telephone manufacturers.  Though
important, the telephone manufacturers represent
just a single component of the world of data
communications.  In creating WAP, grossly
inadequate consideration has been given to other
important disciplines and constituencies, such as
the Internet engineering community, the academic
community, and the small business community.

2.2   No Assurance of Availability and Stability
------------------------------------------------

An essential attribute of an industry standard
protocol is that it be freely and permanently
accessible to anyone who wishes to use it.  In the
Internet world, this is traditionally accomplished
by means of RFC publication.  RFC publication
provides the following important benefits:

  o World-Wide Distribution.  RFC publication
    ensures unrestricted world-wide distribution
    of the published protocol.  There are many Web
    and FTP sites world-wide that carry the
    complete series of RFC documents - if any one
    site is busy or unavailable, someone seeking
    an RFC can simply go to another.

  o Unrestricted Distribution.  A user may
    download an RFC publication completely freely,
    without incurring any legal restrictions
    whatsoever.  All that is required to acquire
    the full text of an RFC is its number or
    title.

  o Permanence.  RFC publication is permanent.
    Even if the creator of a protocol should go
    out of business or otherwise become defunct,
    the RFC will remain in existence.

  o Stability.  Once published, an RFC is fixed --
    it cannot undergo change.  If a new revision
    of the standard must be issued, this is
    handled by issuing the revision under a new
    RFC number.

The WAP specifications do not carry these same
assurances of free and permanent availability.
Rather than being published as an RFC or by
another third-party agency, the specifications are
self-published by the WAP Forum.  As a result of
this, each of the above benefits of RFC
publication is in some way diminished:

  o Limited Distribution.  The specifications are
    only available from a single source:  the WAP
    Forum itself.  If the WAP Forum web site
    should happen to be down, the specifications
    are simply unavailable.

  o Restricted Distribution.  In order to download
    any particular WAP specification, a user must
    agree to a license agreement.

  o Diminished Permanence.  The permanence of the
    WAP specifications is only as good as that of
    the WAP Forum itself.  If the WAP Forum should
    ever become defunct and cease operations, all
    its specifications will become orphaned.

  o Diminished Stability.  The WAP Forum does not
    guarantee the stability of its specifications.
    As of February 2000, each WAP specification
    carries on its title page the disclaimer,

    ``This document is subject to change without
    notice.''

This last item is particularly worrisome.  A key
attribute of a protocol is that any particular
revision of it be fixed -- indeed, this is the
very definition of a standard.  The WAP Forum's
disclaimer gives it the power to modify individual
revisions of the specification at will -- an
extraordinary power to hold over something that
purports to be an industry standard.  This is not
a purely theoretical concern -- the WAP Forum has
already exercised this power inappropriately [14].

Of overriding significance is the fact that the
WAP Forum has declined to publish its
specifications as RFCs.  For all the above
reasons, Internet-related protocols are always
published as RFCs -- this is the mainstream,
industry-standard, method for publication of
Internet protocols.  RFC publication is
well-understood and accepted within the Internet
community, and fully represents the spirit of
cooperation which is characteristic of this
community.  Quite simply, there is no good reason
to do otherwise.

Yet the WAP Forum has done otherwise.  Our
question is:  Why?  We can think of only three
plausible reasons:

 1. The specifications are so technically
    deficient that they do not meet the minimum
    standards required for RFC publication.

 2. The WAP Forum wishes to retain full control
    over the specifications, including the ability
    to change them at will, without regard to the
    resulting loss of stability.

 3. The WAP Forum wishes to impose copyright
    restrictions on the protocols beyond those
    provided by RFC publication.

Whatever the reason, the WAP Forum evidently does
not subscribe to the spirit of openness and
cooperation represented by RFC publication and
practiced by the Internet engineering community at
large.

2.3   Not Patent-Free
---------------------

An essential attribute of an industry building
protocol is that there must be no restrictions on
its usage.  In particular, there must be no patent
restrictions on the use of the protocol.

The WAP specification, however, is burdened with
several patent restrictions.  These include
patents held by certain members of the WAP Forum
itself, most notably Phone.com and Geoworks.
Patent infringement claims have already been made
by the holders of the following patents:

  o U.S. Patent # 5,327,529 (Geoworks).  Process
    of designing user's interfaces for application
    programs.

  o U.S. Patent # 5,809,415 (Phone.com, formerly
    Unwired Planet).  Method and architecture for
    an interactive two-way data communication
    network.

More patent infringement claims can almost
certainly be expected in the future.

One of the benefits of a standard protocol is that
it does not provide any advantage to one industry
player over another.  Anyone who wishes to develop
products and/or services based on the protocol may
do so, and may then compete with similar products
and/or services in a fair, open, free-market
environment.  In such an environment products
succeed or fail based on their merits, and the
benefits to the consumer are those traditionally
resulting from free-market competition:  better
products at lower prices.

The inclusion of patents in a standard entirely
corrupts this process.  The patent provides the
patent-holder with a sustained and unfair market
advantage.  The losers are the industry as a
whole, small companies, and the consumer.
Patents thus pose a significant danger to
protocols.  For this reason, the protocol
development process must include mechanisms to
address and eliminate patent restrictions.  Such
mechanisms exist, and are well-known and
understood within the Internet community.  For
example, we refer the reader to RFC 2026, The
Internet Standards Process -- Revision 3 [4].
Section 10 of this document, Intellectual Property
Rights, describes the policies and procedures
followed by the IESG (Internet Engineering
Steering Group) in this regard.  Among other
things, this section describes their policy
regarding:

  o Strong preference for the adoption of
    patent-free technology wherever possible.

  o The prompt, forthright disclosure of any
    actual or potential patent rights which may
    affect the protocol.

  o The steps to be taken to secure from the
    patent owner an unlimited, perpetual,
    non-exclusive, royalty-free license to include
    the patent as part of the protocol.

The IESG policy is an example of the effort
typically made within the Internet community to
work strenuously and diligently towards the goal
of a patent-free protocol.

As another example, the Free Protocols Foundation
publishes a set of policies and procedures for
protocol development that ensures, as far as
possible, that the resulting protocol is
functionally patent-free.  These procedures are
fully documented in the Free Protocols Foundation
Policies and Procedures, Version 1.0 [11].  Any
development organization is free to adopt these
procedures with regard to its own protocols.

The WAP Forum, clearly, has not followed the
example set by the Internet community at large.
Procedures such as those of the IESG and the Free
Protocols Foundation are well understood within
the Internet community, and by following such
procedures the WAP Forum could have ensured
patent-freedom of the WAP specification, had it
wished to do so.  However, it has not adopted such
procedures, and as a result the WAP specification
is in total violation of the principles of
patent-freedom.

More than any other factor, it is the failure of
the WAP Forum to work towards a patent-free
specification that leads us to characterize the
WAP specification as a trap.  Two of the companies
that participated in the development of the WAP
protocol (Phone.com and Geoworks) own patents
which they silently included in the protocol
design.  They remained silent until use of the
protocol began to spread throughout the industry,
and only then did they announce their patent
ownership and demand royalties.  In effect, these
companies have booby-trapped the WAP specification
with their patents.

The WAP Forum clearly does not share the Internet
community's commitment to patent freedom.  Indeed,
the WAP Forum's attitude to patents appears to be
diametrically opposed to this.  To quote Ben
Linder, VP of Marketing for Phone.com [7],

    ``By virtue of building a standard, each
    company contributes a small part of it.
    Then you trade with each other to keep
    implementing the standard.''

Mr.  Linder seems to view patent rights as
something to be traded among companies like
baseball cards.  Our question is:  How are
companies without any cards expected to
participate in this trade?

The spirit of a healthy protocol is that it be
open and free, a spirit which the WAP
specification violates completely.  The WAP
Forum's characterization of WAP as an ``open,
license-free standard'' is utterly preposterous.

2.4   No Legitimacy as a Standard
---------------------------------

Throughout its web site and printed materials, the
WAP Forum repeatedly refers to its specification
as a ``standard.''  The use of this term is
inappropriate and misleading.

In common engineering usage, the term ``standard''
means certain specific things.  It means a
protocol or other specification which

(a) is supported and approved by an established,
professional standards organization, and
(b) has achieved industry-wide acceptance and
usage.

The WAP specification enjoys neither form of
legitimacy.  It is approved by no organization
other than the WAP Forum itself, which has no
standing as a professional standards body.  Also,
despite the claims made in the WAP Forum's
promotional material, it has achieved little
acceptance in the marketplace.  Though marketing
projections for use of WAP are very impressive,
its actual usage in the U.S. remains limited.

The WAP Forum's use of the word ``standard''
implies that their specification carries some kind
of formal authority; in fact, it has none.  The
WAP Forum's use of this term is marketing hype,
not an objective statement of fact.

Any group of business interests can form a
members-only club, generate a specification,
publish it themselves, and call it whatever they
wish.  Regardless of the name they choose to
attach to it, however, this does not make the
result a ``standard'' in the conventional sense.

3   WAP - A Technical Failure
=============================

In addition to its procedural flaws, the WAP
specification also includes serious technical
deficiencies.

A detailed technical criticism of the WAP
specification is beyond the scope of this
document, and in this section we will do no more
than provide a brief summary of the major issues.
For a detailed analysis of WAP, the reader is
referred to the article W* Effect Considered
Harmful [14], in which author Rohit Khare argues
the shortcomings and ultimate non-viability of the
WAP specification.

The deficiencies in the WAP specification are
glaring, obvious, and readily apparent to any
competent data communications professional.  A
recent (January 2000) e-mail discussion thread on
the IETF mailing list [8] makes this point quite
plainly -- this thread demonstrates clear
consensus among professionals that the WAP
specifications are not a technically sound
engineering solution.

Many of the technical problems stem from a
strategic design decision, made early in the
design process.  As noted in the Introduction, a
new set of protocols are clearly needed to address
the efficiency needs of mobile wireless devices.
One approach to this would be to treat these
devices as just another kind of Internet host.
Under this approach, the existing Internet
protocol architecture would remain in place, and
to this would be added a small number of
supplementary Internet protocols, designed to
provide the power and bandwidth efficiency
required by wireless devices and networks.

The other approach is to treat these mobile
devices as a unique special case, requiring their
own, entirely new set of protocols.  Under this
approach, the existing Internet protocol stack is
discarded, and a completely new protocol stack is
re-designed from scratch.

The WAP Forum made the early strategic design
decision to take the latter approach.  They have
developed an entire stack of network protocols
analogous to, but largely incompatible with, the
existing Internet architecture.  Not only has this
approach required an enormous engineering effort
on the part of the protocol designers and
implementers, it has also given rise to a number
of fundamental design errors.

3.1   User Interface Assumptions
--------------------------------

A basic principle of data communications protocol
design is that communications considerations must
be de-coupled from user interface considerations.
In other words, user interface issues must not be
part of the protocol.

The WAP specification, however, violates this
principle completely.  It is tailored primarily to
the physical characteristics of the hand-held
mobile telephone, with its unique user interface
characteristics.  Accommodation is made to these
characteristics throughout the specification, with
the result that user interface issues are
repeatedly combined and confused with
communications issues.  To put this in the
language of data communications professionals:
WAP presumes presentation.

The WAP designers justify this on the grounds that
the combined technologies of wireless
communications, and the mobile telephone, create a
unique special case which warrants this departure
from standard design principles.  In fact, this is
a strategic design error.

3.2   Extreme Accommodation to Existing Networks
------------------------------------------------

Because WAP is essentially a marketing construct,
one of its goals has been to create mindshare
within every segment of the wireless industry.  In
order to accomplish this goal, WAP has made
extreme accommodation to existing wireless
networks.  The WAP specification claims to
accommodate almost all existing networks,
including several which are already obsolete in
their usage and general design.  This has
significantly and unnecessarily increased the
complexity of the specification.

The WAP specification claims to support all the
following wireless networks:  CDPD, CDMA, GSM,
PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT,
DataTAC, Mobitex, SMS, USSD, CSD, IS-136.
Some of these networks, such as FLEX and ReFLEX,
are not general-purpose wireless networks, and
were neither intended nor designed to run
Internet-centric application protocols of any
kind.  WAP's decision to accommodate such networks
makes little sense in engineering terms.  This
decision can only have been based on marketing
considerations -- each additional network
supported provides WAP with one more promotional
bullet point.  Engineering concessions to
marketing are a fact of life in the world of
consumer products, but they have no place in an
industry-standard protocol.

Wireless networks are rapidly standardizing on IP,
the Internet Protocol.  Most modern wireless
networks (e.g.  CDPD, Packet CDMA) already support
native IP, and we can expect that others will do
so in the very near future.  The convergence of
wireless networks on IP at Layer 3 (the Network
Layer) is already a technological reality, and it
is inevitable that it will eventually become
standard on all networks.

Therefore the correct approach to wireless
application standardization is to accept IP as the
standard service at Network Layer, and implement
high-efficiency protocols above Layer 3.

Furthermore, the result of accommodating all these
networks is that the specification is no longer
Internet-centric.  WAP insists that the
specification is Internet-centric, but this claim
is without substance.  If one tries to accommodate
all existing technologies one cannot claim that
the result is Internet-centric - one simply cannot
have it both ways.

WAP claims to achieve accommodation of this very
wide range of networks by means of two lower layer
protocols:  Wireless Control Message Protocol
(WCMP), and Wireless Data Protocol (WDP).

WCMP is an out-of-place imitation of ICMP. Since
there are no multiprotocol wireless operators, use
of WCMP is always addressed as a service provider
specific mechanism.  In other words, WCMP is
largely irrelevant.

WDP is roughly equivalent to UDP. The only
rationale for its reinvention is to accommodate
airlink addresses and airlink restrictions on
packet size.  The equivalent of WDP could have
been accomplished on a per-network basis outside
the scope of wireless applications.  In fact, the
existence of WDP may become a hindrance towards
evolution of existing wireless networks towards
IP.

In general, backward compatibility is a worthy
design goal.  But in this particular case it is a
wasted effort.  The convergence of wireless
networks towards IP is already a technological
reality.  The strength and benefits of ``IP On
Everything'' by far outweigh the efforts in
accommodation and backward compatibility.

WAP's choice has been to accommodate all existing
old wireless networks -- a fact which betrays its
underlying market motivation.

3.3   Excessive Re-Invention in the Name of Wireless
----------------------------------------------------

Existing Internet protocols do not adequately meet
the requirements of wireless data communications
-- on this point we are in complete agreement with
the WAP Forum.  However, we believe that the
correct way to design the required protocols is to
do so within the framework of the existing
Internet protocol architecture -- the new
protocols should be compatible with and re-use
existing protocols as much as possible.

The WAP designers, however, have taken precisely
the opposite view.  Instead of re-using existing
protocols, they have created an entirely new set
of protocols from scratch.

The main key piece of new technology in WAP is the
Wireless Transaction Protocol (WTP). In many ways,
WTP is the heart of WAP. WTP is responsible for
delivering efficient reliability to applications.
Even in that area, WAP could have re-used existing
technology.  Specifically, T/TCP [3] and ESRO [2],
which had already been published as Internet RFCs,
could have been used.  While there may be some
reasonable objections to the use of T/TCP due to
its ``heaviness'' because of bundling with TCP,
there is no reason why ESRO could not have been
used instead of WTP. In fact, WTP is a poor
attempt at accomplishing the services of ESRO.

Aside from WTP, in most cases WAP's new protocols
are essentially the same as the previously
existing protocols, but with minor modifications
that render them incompatible with the original
standard.  The WAP specification discards and then
re-designs almost every existing Web standard --
for example, WAP replaces UDP with WDP, TLS with
WTLS, HTTP with WTP, HTML with WML, and ECMAScript
with WMLScript.

This large amount of re-invention is entirely
unnecessary.  There are many places throughout the
design of the WAP protocols where the existing
protocol structure could have been left untouched,
but complemented by the addition of a limited
number of new protocols, designed for optimal
efficiency.

The scope of the WAP specification has also been
expanded beyond what is needed or reasonable (e.g.
WCMP, WDP). Again, the WAP designers justify all
this re-invention and expansion of scope on the
grounds that wireless mobile devices present a
unique special case, requiring a completely new
set of protocols.  In fact there is nothing
specific to wireless applications which justifies
this exhaustive degree of re-invention.

3.4   Vulnerable Wireless Transport Layer Security (WTLS)
---------------------------------------------------------

In his paper Attacks against the WAP WTLS Protocol
[10], author Saarinen describes in detail a number
of security problems with WTLS. Here we provide a
brief summary of the problems and their cause.

Although the WTLS protocol is closely modeled on
the well-studied TLS protocol, a number of
security problems have been identified with WTLS.
These problems include:  vulnerability to datagram
truncation attack, message forgery attack, and a
key-search shortcut for some exportable keys.
Most of the text in the WTLS specification has
been adopted, word for word, from the TLS
specification.  However, many of the changes that
were made by WAP Forum have led to security
problems.

This is another case of the WAP Forum's deliberate
deviation from the mainstream of the Internet
causing difficulties.

3.5   Bungled Protocol Number Assignment
----------------------------------------

As Khare discusses in greater detail [14], WAP's
port numbering strategy is another example of
botched reference-by-copy.  Instead of obtaining
legitimate WAP ports in the IANA-registered space,
WAP uses the temporary private port space in the
range of 49152 to 49159.  In addition to the port
numbers, TLS ciphersuite codes and HTTP methods
were also not registered with IANA. Instead, the
WAP Forum has created its own parallel IANA
equivalent called WINA.

This is another case of WAP Forum's deliberate
deviation from the mainstream of the Internet in
the name of wireless, and for the purpose of
maintaining control.

4   WAP - A Basic Misconception
===============================

Beyond its procedural and technical flaws, we
believe that WAP represents a fundamental
misconception of what can feasibly be accomplished
using cell phones, and what actual users are going
to want to do with their phones.

Mobile Messaging, and Mobile Web Browsing,
represent two very different forms of mobile
communications activity.  Mobile Messaging refers
to the ability to send and receive personally
directed messages, while Mobile Web Browsing
refers to general information retrieval from
anywhere.

Both of these bring undoubted value to the user,
both can be accomplished on a cell phone, and the
mobile user of tomorrow will certainly indulge in
both activities.  However, the value that the two
activities bring to the user, and the suitability
of the two activities to the cell phone, are very
different.

Mobile Messaging allows important and/or
time-critical information, which may require the
user's immediate attention, to be pushed to
him/her quickly.  This is something which is of
inherent and compelling value to the off-line,
mobile user.  By contrast, the desire of the
mobile user to go back on-line for web access
rarely has the same importance or urgency.

A basic question is:  which of these two mobile
applications represents the best initial value?
We believe that Mobile Messaging is the right
answer for initial mobile applications
development.

4.1   The Wrong Answer Initially:  Mobile Web Browsing
------------------------------------------------------

The basic goal of the WAP specification is to
allow Internet web browsing using mobile phones.
The assumptions underlying this goal are, first,
that web browsing capability can be adequately
accomplished on a mobile phone, and second, that
this is something that will be of significant
value to mobile phone users.

However, we believe that neither of these
assumptions is correct.  First, the cell phone of
today is a totally inappropriate device for the
purpose of accessing the mature Internet.  Not
only is the cell phone user interface completely
inadequate for general web page display, but the
wireless network medium also imposes severe
limitations on the speed, immediacy, and
reliability of web page access.  It is simply not
practical to surf the web using today's four-line
text displays, over a slow, congested network with
unreliable coverage.

As Kevin Maney observes in his article Cell phones
let the Web 'go mobile' [9]

    ``Web phones can be slow and frustrating.
    Click on The Weather Channel, for example,
    and the phone takes 6 or 7 seconds to send
    the request through the Sprint wireless
    network, into the Internet and to The
    Weather Channel's WAP-enabled Web server,
    then get back the next menu.  On that
    menu, click ``cities,'' then wait a few
    more seconds before getting a request to
    enter a ZIP code.  You do that using the
    phone keypad.  A few seconds later, you
    get the report.  Only about 10-15 words
    fit on the screen at one time.  You scroll
    down to read it.''

It can be argued that future improvements in
display technology may act to alleviate these
difficulties, and this may very well be the case.
However, the need for convenient portability of
``unconscious carry'' communications devices such
as cell phones and pagers exerts tremendous design
force towards reducing the size of these devices.
The effect of this force is plainly apparent in
the current trend towards extreme miniaturization
of cell phones.

The design force towards miniaturization is
something which is in direct opposition to display
capability.  For this reason, we believe that
unconscious carry devices will continue to have
severely limited display capabilities.

Second, there is the question of what people are
actually going to do with the brand new medium of
wireless data communications.  How, and in what
forms, will this medium become part of society?
In ten years time we may have the answer, but
today, nobody knows.

Of all forms of risk, prediction is the most
gratuitous -- yet none of us seems able to resist
it.  WAP's answer is that mobile web browsing will
be enthusiastically embraced by society, and that
it will be done via the cell phone device.

Our answer is that we doubt it.  People will do
things on a mobile basis that make sense to do
while mobile -- they will access the information
that is most useful to them while away from the
home or office.  This includes such things as
urgent e-mail messages, and highly specific urgent
and important information.  But it does not
include general-purpose web browsing.

Web browsing is an interactive activity, for which
the user requires a near real-time response.
Furthermore, browsing, as the word indicates, is
not an activity that has any urgency, and is
therefore not something that there is a compelling
reason to do while mobile.  For both of these
reasons, we believe that people will continue to
do their web browsing at the home or office, and
that web browsing will remain a marginal component
of mobile communications.

It is true that the prospect of mobile Internet
access has created tremendous excitement in the
marketplace.  And there is something magical about
putting a cell phone in someone's hand, and
providing a demonstration of live mobile Internet
access.  But the enchantment that this creates in
the user stems from its technological novelty, not
from its enduring day-to-day usefulness.

4.2   The Right Answer Initially:  Mobile Messaging
---------------------------------------------------

This is not to say that all Internet data access
is without value to the user.  On the contrary,
consumers certainly will use their mobile phones
for Internet data access.  However, the nature and
types of data they will access will be appropriate
to the medium.

They will access data that they have a need for
and can use while mobile, that does not require
near-synchronous system interaction, and that can
conveniently be accessed via a mobile device.
The single application that satisfies these
criteria better than any other is mobile
messaging, or e-mail.  Interpersonal messaging has
already become an indispensable aspect of modern
life, and is now the dominant application for the
fixed Internet.  We believe that society will
adopt mobile messaging with the same enthusiasm as
conventional e-mail, and that it will achieve
similar dominance on the wireless Internet.

4.3   Unsupported Claims
------------------------

There is presently an enormous amount of hype
surrounding WAP. The WAP proponents have hyped its
abilities far beyond what the consumer will
actually be able to do with his or her cell phone.
There is a general perception that WAP will
essentially put the entire Internet into the hands
of the cell phone user.  It is understood that a
good deal of the form of a website may be lost in
translation to the cell phone, though its basic
textual content will be preserved.  Beyond this,
however, there is a perception that any website
can be accessed in this way; i.e.  that WAP will
make the entire Internet content accessible via
cell phone, just as it currently is via a
conventional ISP.

However, this is not the case.  WAP provides
access to websites by translating the HTML coding
of web pages into something that a cell phone can
understand and display.  What this means is that
in order to get information from a website, the
site must have a WAP-enabled server, and the
server must be programmed to extract the website
content that can be displayed on the miniature
cell phone screen.  In other words, if your
favorite website is not WAP-enabled, you probably
will not be able to access it through your cell
phone.

For this reason, the tremendous hype surrounding
WAP has yet to be backed up by commercially
available WAP products and services.  As Antony
Bruno comments in his article Market gap producing
WAP alternatives [5]

    ``A running joke among industry players
    has the WAP acronym meaning Where Are the
    Phones?''

WAP phones and services are not available in the
marketplace, because the promises of WAP are
simply not real.

4.3.1   Not Device-Independent
------------------------------

The WAP specification is being promoted by the WAP
Forum as a general-purpose wireless protocol,
suitable for a wide variety of end-user devices,
including PDAs such as PalmPilot.  As noted in
Section 3.1, however, WAP is in fact highly
phone-centric -- it is strongly oriented towards
the mobile telephone physical device, despite the
WAP Forum's claims of device-independence.

We note in passing that during the time that it
was promoting the general-purpose nature of WAP,
Unwired Planet, a founding member of the WAP
Forum, changed its name to Phone.com.  There are,
of course, many good reasons why a company might
wish to change its name.  It strikes us as ironic,
however, that while promoting the
device-independence of WAP, this founding WAP
Forum member abandoned a device-independent name
in favor of a device-dependent one.

4.3.2   Limited Web Browsing Capabilities
-----------------------------------------

The WAP Forum claims to bring web browsing
capability to the cell phone.  However, the cell
phone device is simply not equal to this task.
Because of the user interface limitations of the
cell phone -- its very small screen and limited
keypad -- the resulting web browsing experience is
clumsy and impractical.

Furthermore, use of the WAP specification to
access web content requires the use of WAP
gateways, which translate the WAP-enabled website
content into a format which the end-user can
access.  These gateways are controlled by the
Service Provider (typically the wireless phone
service provider), not the information provider.
This usage model is very much contrary to the
existing Internet usage model, in which the
Service Provider plays the role of an entirely
passive intermediary between the website provider
and the website reader.  In other words the
Service Provider functions purely as a pipe.  In
this model new website content becomes immediately
available to all Internet users as soon as it is
created by the website provider.  This
unrestricted connection between the creators and
consumers of Internet content has been one of the
keys to its extraordinary growth and vitality.
Because of this open characteristic the Internet
has been able to grow organically -- i.e.
spontaneously, autonomously, and without planning,
control, or approval by any central authority.

In the WAP model, by contrast, the WAP gateway
operated by the Service Provider plays the active
role of translating and storing web content, and
therefore controls access to the content by the
end-user.  New websites and new web content do not
become available to the end-user without the
active participation of the Service Provider.
This places a layer of control and authority
between the creator and consumer of website
content, greatly diminishing the potential for
unrestricted and organic growth of the Internet.

4.3.3   Existing Technology Adequate
------------------------------------

The premise of providing access to important
information through a cell phone is certainly
valid.  As noted above, however, the nature and
quantity of information that in practical terms
can be delivered via a cell phone is severely
constrained by the device itself.

The nature and quantity of information that can be
delivered is sufficiently heavily constrained,
that it can be adequately delivered using existing
technologies.

The equivalent of most, if not all, of what WAP
promises to deliver on a cell phone can very
reasonably be accomplished using existing and
already widespread technologies such as SMS.
Indeed, this is already being accomplished today.
Various companies, including Xypoint, AmikaNow!,
Roku, ThinAirApps and Microsoft, are already
providing services equivalent to WAP's claimed
functionality.  This is being done using existing
cell phones and existing cellular services.  For
more information, and a more complete list of
companies providing such services, see [5].

4.3.4   Voice Interface Adequate
--------------------------------

The screen user interface limitations of a cell
phone are so severe, in fact, that its data access
capabilities are almost always better served by
its voice interface -- with which, of course, all
cell phones come equipped.

The genuine utility of WAP on a cell phone resides
in those applications for which a visual data
interface is superior to a voice interface -- that
is, in those applications for which screen and
keypad are better suited than speaker and
microphone.  Given the limitations of the cell
phone screen and keypad, however, this is an
extremely narrow range of applications.  In other
words, if all you have is a tiny screen and a
miniature keypad, then in most cases you are
better off using the voice interface.

Use of the voice interface to access important or
time-critical information is already fairly
widespread.  The implementation of increasingly
reliable speech recognition and powerful
text-to-speech systems can be expected to make
data transfer via the voice interface even more
convenient.

5   Conclusion:  WAP is a Trap
==============================

We have no argument with the notion that a
world-wide standard is needed to address the
requirements of wireless data applications.

However, we believe that WAP is utterly unfit for
this purpose.  As we have shown in this article,
WAP is the result of a closed design process
within a members-only club.  It remains tightly
controlled by the WAP Forum, is crippled by
patents, and is riddled with technical design
errors.  In the long run WAP is doomed to failure.
In the short run it can only do harm to the
industry and the consumer.

All of this could be the result of a series of
colossal blunders by a well-meaning but
spectacularly incompetent industry association.
However, we do not believe that this is the case.
We do not believe that the WAP Forum is
well-meaning; on the contrary, we believe that
their fundamental motivations are crass financial
self-interest, coming at the expense of
engineering and business integrity.

The WAP Forum could easily have taken steps to
eliminate every one of the criticisms we have
leveled against it, yet they have not done so.  We
invite them to tell us why.

The WAP Forum claim that WAP is an extension of
the Internet, and is part of the Internet
mainstream.  Yet in no way has the development of
WAP been consistent with Internet conventions.
The specification could have been designed by an
open design process, by the straightforward
expedient of establishing open working groups and
public mailing lists.  There is ample precedent
for this in the history of Internet protocol
development.  Yet the WAP Forum has not done so.
Why not?

The WAP Forum could have ensured free and
permanent availability of the specification by
publishing them as RFCs, the mainstream method of
publishing Internet protocols, and supported by
extensive precedent.  Again, they have not done
so.  Why not?

The WAP Forum could have worked diligently towards
the goal of a patent-free protocol, by means of
processes with well-understood industry precedent.
Once more, they have not done so.  Why not?

We can come to only one conclusion:  WAP was
designed to create unfair market advantage for its
developers from the outset.  They have maintained
strict and close control of the protocol from the
beginning, in complete violation of Internet
conventions.  The WAP Forum members have knowingly
and deliberately incorporated their own patents
within the specifications, and now are demanding
royalties.

We can think of no better way to characterize such
a process than as a trap.  WAP is far from being
an enabling force in the wireless industry.  On
the contrary, it is a gigantic and poorly-designed
red herring created by narrow business
self-interests.  It is not a genuine engineering
construct; it is a bogus marketing one.
A recent quotation from Greg Williams, Chairman of
the WAP Forum, provides an excellent illustration
of the WAP Forum's preference for members-only
processes.  Commenting on the recent highly public
Geoworks patent infringement claim, he says [6],

    ``Companies in the WAP Forum generally
    settle licensing and cross-licensing deals
    between themselves.''

6   Preventing the Harm of WAP
==============================

What can be done to prevent the spread of WAP?
There are several possible steps that in principle
could be taken:

  o Work to reform the WAP Forum.

  o Spread the word about the WAP fraud.

  o Reject WAP at engineering level.

  o Reject WAP at consumer level.

  o Adopt a viable alternative to WAP.

6.1   Reform the WAP Forum
--------------------------

One possibility would be to work with the WAP
Forum -- to engage them in a dialogue, and try to
persuade them to correct the procedural problems
described in Section 2.  Among other things, this
would require that they establish an open working
group for maintenance of the protocol, initiate
RFC publication of the protocol, and make every
effort to lift all patent restrictions from the
protocol.

However, this would amount to a complete reversal
of the WAP Forum's mission and values, and it is
naive to imagine that this is possible.  At this
point, we regard the WAP Forum as being beyond
redemption.

This also leaves aside the question of what to do
about the technical deficiencies of WAP -- even
with the WAP Forum's complete cooperation, a major
effort would be required to create a sound
engineering solution.  Working to reform the WAP
Forum, therefore, is not a useful approach.

6.2   Spread the Word about the WAP Fraud
-----------------------------------------

Given that we can expect no help from the WAP
Forum, the most useful thing that can be done
quickly and easily is to spread the word about
WAP. It is for this purpose that this expose has
been written.

Please join us in letting it be widely known that
WAP is a trap.  You may freely make and distribute
copies of this article, provided the copyright and
permission notices are preserved.  You are
encouraged to bring this article to the attention
of the appropriate persons within your
organization.

6.3   Reject WAP at Engineering Level
-------------------------------------

Rejecting WAP at engineering level means working
to prevent WAP from being adopted in the design of
devices and systems.  This is primarily the
responsibility of the engineering community within
the wireless industry.

It is the responsibility of design engineers to
evaluate the controversy surrounding WAP, and
decide for themselves whether or not it is a sound
engineering solution.  If as an engineer you
decide that it is not, then we encourage you to
inform your manager of this, justify your position
on technical grounds, and recommend alternatives.

To provide support for this, the Free Protocols
Foundation maintains a set of informational
resources on its website at
http://www.freeprotocols.org/harmOfWap/main.html.

These resources include references to various
other papers and articles which corroborate the
fraudulence of WAP. Please feel free to use these
materials in any way you wish.  We also invite you
to contribute to the information pool at the Free
Protocols Foundation -- any comments, articles or
other information may be submitted to the FPF via
our website.

6.4   Reject WAP at Consumer Level
----------------------------------

Rejecting WAP at consumer level means encouraging
the end-users of hand-held wireless devices to
refuse to purchase WAP devices -- in other words,
to boycott these devices.

However, the WAP question is a very complex
technical and business issue, and it is not easy
to convince the consumer that this is something
worth caring about.  A successful boycott requires
an immediate, gut-level understanding of the
issues on the part of the consumer.  The WAP issue
is not something that can easily be condensed into
a ten-second sound bite.

In any case, WAP is not sufficiently widespread
for a boycott to be effective.  For these reasons
we do not consider a consumer boycott to be a
useful approach at this point.  For the moment,
WAP must be dealt with by the industry, not the
consumer.

6.5   Adopt an Alternative to WAP
---------------------------------

Regardless of the shortcomings of WAP, the fact
remains that at some point the wireless industry
must agree upon a standard protocol for efficient
data communications.  Ultimately, therefore, WAP
can be displaced only by the adoption of a
suitable alternative.

One traditional source of Internet protocols is
the Internet Engineering Task Force, or IETF. To
our knowledge, however, the IETF does not
currently have a working group assigned to this
task, and so no protocol can be expected from them
in the near future.  Even if the IETF were to
assign a working group to this immediately, it
typically takes 18 months to achieve a workable
first-draft protocol.  This time frame is far too
long to address the industry's immediately
pressing need.

Other traditional sources of protocols are private
industry, and the academic community.  However,
thus far a suitable protocol has been forthcoming
from neither of these sources.  Although there is
general consensus within the industry that an
alternative protocol to WAP is desperately needed,
no such protocol has yet been publicly proposed.
In this article, we would like to be the first to
present an alternative:  LEAP, the Lightweight and
Efficient Application Protocol.  LEAP is
immediately available, and has all the
characteristics required to displace WAP and
become the basis of an industry standard.  A brief
description of LEAP is provided in the following
section.

To the best of our knowledge, LEAP is the only
viable alternative to WAP. However, we invite
readers of this article to seek out and bring to
our attention any other alternatives that may
exist.  At the Free Protocols Foundation, we are
ready to support and publicize any viable,
patent-free alternative to WAP that is made known
to us.  Such alternative protocols will be
referenced at the FPF website at
http://www.FreeProtocols.org, and included in
future revisions of this article.

In summary, the best ways to prevent the harm of
WAP are to spread the word, reject WAP at
engineering level, and adopt alternatives.  We
encourage readers of this article to join us in
opposing WAP in all of these ways.

7   LEAP: One Alternative To WAP
================================

Fortunately, an alternative to WAP exists:  LEAP,
the Lightweight and Efficient Application
Protocol.  LEAP consists of a set of
high-performance, efficient protocols which are
ideal for mobile and wireless applications.  LEAP
presently includes the following component
protocols:

  o Efficient Short Remote Operations Protocol
    (ESRO).
    
    ESRO can be thought of as a reliable
    connectionless transport mechanism, forming
    the foundation for the development of
    efficient protocols when TCP is too much and
    UDP is too little.  ESRO was published as
    RFC-2188[2] in September of 1997.  The ESRO
    protocol is publicly maintained and developed
    by ESRO.org at http://www.esro.org/.

  o Efficient Mail Submission and Delivery
    Protocol (EMSD).
    
    EMSD is designed to address the mobile
    messaging (e-mail) application.  EMSD was
    published as RFC-2524 [1] in March of 1999.
    The EMSD protocol is publicly maintained and
    developed by EMSD.org at http://www.emsd.org/.

  o Efficient Hyper Text Delivery Protocol (EHTD).
    
    EHTD is currently undergoing development and
    will provide efficient delivery of web pages.
    It is currently undergoing public development
    at http://www.freeprotocols.org/EHTD.

Open source implementations of the ESRO and EMSD
protocols are being made available as free
software at:  http://www.MailMeAnywhere.org/.

The LEAP protocols, in combination with existing
Internet protocols, properly address the same set
of requirements that WAP claims to address.  They
have all the preferred protocol characteristics
described in Section 1.2.  They are published as
Internet RFCs, are publicly maintained, and suffer
from none of the technical deficiencies ascribed
to the WAP specifications.  In addition, the LEAP
protocols fully conform to the patent-free
policies and procedures of the Free Protocols
Foundation [11].

A comparison of LEAP to WAP, and justification of
LEAP as the basis of an industry standard, is
provided in LEAP: One Alternative To WAP [12], a
companion article to this one.  This article is
available at the Free Protocols Foundation website
at http://www.FreeProtocols.org.

A complete and detailed description of LEAP is
provided in The LEAP Manifesto [13], available at
the LEAP website at http://www.LeapForum.org.

Anyone interested in participating in the
development of the LEAP protocols is invited to
join the Mailing Lists sections of the websites
mentioned above.  LEAP's development process is
truly open and non-exclusive.  There are no
membership fees.  Participation in the LEAP
development process requires only that you commit
to the patent-free intent of LEAP and the Free
Protocols Foundation.

References
==========

 [1] M. Banan. Neda's Efficient Mail Submission
     and Delivery (EMSD) Protocol Specification
     Version 1.3. Request for Comments
     (Informational) 2524, Neda Communications,
     Inc., February 1999. Online document is
     available at
     ftp://ftp.isi.edu/in-notes/rfc2524.txt.

 [2] M. Banan, J. Cheng, and M. Taylor.
     AT&T/Neda's Efficient Short Remote Operations
     (ESRO) Protocol Specification Version 1.2.
     Request for Comments (Informational) 2188,
     Neda Communications, Inc., September 1997.
     Online document is available at
     ftp://ftp.isi.edu/in-notes/rfc2188.txt.

 [3] B. Braden. T/TCP -- TCP extensions for
     transactions functional specification.
     Request for Comments (Experimental) 1644,
     Internet Engineering Task Force, July 1994.

 [4] S. Bradner. The Internet Standards Process --
     Revision 3. RFC 2026, Internet Engineering
     Task Force, October 1996. (Obsoletes
     RFC1602).

 [5] Antony Bruno. Market gap producing WAP
     alternatives. RCR News [Online], February
     2000. The copy of this article can be
     obtained at RCR News web site
     (http://www.rcrnews.com)..

 [6] ComputerWire, Inc. Geoworks' Intellectual
     Property Claims Could ``Kill WAP''.
     Computergram 2000, January 2000.

 [7] Corey Grice, John Borland. Geoworks Soars on
     Wireless Licensing Plans. Staff Writers, CNET
     News.com, January 2000.

 [8] IETF Mailing List. January 2000 E-mail
     Discussion Thread. IETF Organization, January
     2000. See the mailing list section of
     http://www.ietf.org.

 [9] Kevin Maney. Cell Phones Let the Web 'go
     mobile'. USA TODAY [Online], February 2000.
     The copy of this article can be obtained at
     USA TODAY web site
     (http://www.usatoday.com)..

[10] Markku-Juhani Saarinen. Attacks Against The
     WAP WTLS Protocol. University of Jyvaskyla,
     1999. Online document is available at
     http://www.jyu.fi/ mjos.

[11] Mohsen Banan. Free Protocols Foundation
     Policies and Procedures. FPF Published
     Document 108-103-01, Free Protocols
     Foundation, Bellevue, WA, January 2000.
     Online document is available at
     http://www.freeprotocols.org/pubs/biblio/108-103-01/index.html.

[12] Mohsen Banan. LEAP: One Alternative to WAP.
     FPF Published Document 108-102-02, Free
     Protocols Foundation, Bellevue, WA, February
     2000. Online document is available at
     http://www.freeprotocols.org/pubs/biblio/108-102-02/index.html.

[13] Mohsen Banan. Lightweight & Efficient
     Application Protocol (LEAP) Manifesto. FPF
     Published Document 108-101-01, Free Protocols
     Foundation, Bellevue, WA, January 2000.
     Online document is available at
     http://www.freeprotocols.org/pubs/biblio/108-101-01/index.html.

[14] Rohit Khare. W* Effect Considered Harmful. 4K
     Associates, April 1999. Online document is
     available at
     http://www.4K-Associates.com/4K-Associates/Library.html.

---

From: "Brijesh Kumar" <[email-masked]>
Date: Tue, 20 Jun 2000 10:30:31 -0400

Mohsen Banan,

I tried hard to agree what you said - but many inaccuracies and
assumptions made in the article made my task so hard that I had to
finally give up reading it. Having spent last several years in the
wireless industry, and also having written some "not-so-open" as you
say, but widely adopted wireless specifications nevertheless, I have
some sympathy with your cause. But you may need to weed out some of
the rhetoric that is not technically correct.

It is an open secret that wireless industry is a closed cartel of
three super heavyweights (Motorola, Ericsson, and Nokia) and two heavy
weights (Lucent and Nortel). There is no role for any smaller
organization in the set up. Hope God give you wisdom to  accept this
truth with cheerfulness, as many other small companies in the wireless
industry have accepted ;-).

Cheers,

--brijesh
(my personal opinion only, and  this in no way represents opinion of
my employer.)

PS: By the way, ReFLEX is perfectly fine for two way messaging
applications.

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Jun 2000 11:06:06 -0400

Mohsen BANAN-Public wrote:

> end-user.

I'm pretty sure this is inaccurate.  The content provider develops their
site in WML and hosts it on their own website; the service provider does
not translate it or store it (though they may cache it).

(I say "pretty sure" because I haven't done any WAP development,
only HDML.)

> New websites and new web content do not

This can be true (for different reasons), but not always.  The user may
not be able to go to an arbitrary URL; they have to entire the WAP world
via the service provider's home page, and get guided to the content sites
the provider wants them to see.  Some (most? all?) providers, though, will
provide a form to fill out to go to a URL (I know Sprint does); and some
cellphones may include a browser that lets the user enter a URL (I don't
know of any that do, but there's nothing to stop them).

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |That is correct. I'm out of fuel. My landing |
[email-masked]|gear is jammed. And there's an unhappy bald  |
|                |eagle loose in the cockpit.                  |
\==============================================================/

---

From: Phil Karn <[email-masked]>
Date: Tue, 20 Jun 2000 12:36:47 -0700 (PDT)

I've worked in the wireless data field for a long time, first in
amateur packet radio, then on CDMA digital cellular at Qualcomm.
Naturally, what I say here are only my personal opinions.

I also scratched my head when WAP came out. It just didn't make any
technical sense. I see I'm not the only one; bravo for writing such a
good critique.

One thing missing from most block diagrams of WAP is the chute on the
bottom of the carrier's WAP gateway pouring out money. It's safe to
say that this chute is WAP's primary reason for existence.

WAP has gotten as far as it has (which isn't very far) only because
cell phones are closed, proprietary devices. The end user has no
choice which software or protocols it runs. The vendors make that
decision for you.

The best defense against WAP is an open handheld platform that allows
end users (and independent vendors and open-source developers) to run
applications and network protocols of their own choice.  As long as
the service providers support IP (perhaps in addition to WAP), the
open platform users can just ignore WAP and run standard Internet
applications. And they can benefit from all the work currently being
done in the IETF and elsewhere on making the Internet protocols work
even better over wireless than they already do.

Consider a Palm Pilot connected to a cell phone. (Or built into one,
like the pdQ). The Pilot is about as open as handheld platforms
currently get, and it already supports a multitude of Internet
protocols (TCP/IP/PPP, SMTP, etc). It is *far* more capable as a
handheld data terminal than the tiny display and keypad on a cell
phone. Exploit that combination and WAP will die a well-deserved death
on the vine.

The Internet end-to-end model will once again prevail, putting the
cellular service providers back into their proper place as providers
of packet pipes, nothing more. And life will be good again. :-)

Phil

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jun 2000 04:59:15 +0859 ()

Phil;

> even better over wireless than they already do.

Please state your wish carefully.

IP is NOT enough.

> of packet pipes, nothing more. And life will be good again. :-)

IP over NAT is, in no way, end-to-end.

WAP and IP over NAT are equally bad.

See the attached mail in IETF more than a month ago.

							Masataka Ohta
--
Subject: Re: draft-ietf-nat-protocol-complications-02.txt
In-Reply-To: <[email-masked]> from "vinton
 g. cerf" at "Apr 30, 2000 06:20:48 am"
To: "vinton g. cerf" <[email-masked]>
Date: Mon, 1 May 2000 17:41:59 +0859 ()
CC: Matt Holdrege <[email-masked]>, Thomas Narten <[email-masked]>, 
 [email-masked]
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
Content-Length: 1614      
Status: RO

Vint;

> that's right - they use iMODE on the DOCOMO mobiles. iMODE and
> WAP seem to have that in common: a non-IP radio link protocol
> and an application gateway. Of course, this limits the applications
> to those that can be "translated" in the gateway, while an end to
> end system (such as the Ricochet from Metricom) would allow 
> essentially any application on an Internet server to interact
> directly with the mobile device because the gateway would merely
> be an IP level device, possibly with NAT functionality.
> With a JAVA interpreter or other similar capability in the
> mobile, one could imagine considerable competition for development
> of new applications. As it stands, only the applications NTT
> chooses to implement in the translating gateway are accessible.

An interesting thing is that iMODE is so successful that DOCOMO
is suffering from the usual problems (lack of scalability and
robustness) caused by violating the end to end principle.

iMODE is now infamous for its frequent service interruption.

DOCOMO users are refunded for the interruption.

> Since HTTP is one of the "applications" served, there is still
> a lot of room for competition, I suppose.

To make the competition fair, the important questions are:

	Is it fair if providers using iMODE or WAP are advertised
	to be ISPs?

	Is it fair if providers using NAT are advertised to be ISPs?

My answer to both questions is

	No, while they may be Internet Service Access Providers and
	NAT users may be IP Service Providers, they don't provide
	Internet service and are no ISPs.

Any oppositions?

						Masataka Ohta

---

From: Phil Karn <[email-masked]>
Date: Tue, 20 Jun 2000 13:22:09 -0700 (PDT)

>WAP and IP over NAT are equally bad.

I think you're overstating your case. Yes, IP over NAT is bad, but
it's nowhere near as bad as WAP. I don't meant to defend NAT, but
many/most existing Internet protocols and applications do work over it
with few if any fixes. Sprint PCS uses a NAT, but I'm still able to
plug my Linux laptop into my Qualcomm phone and do pretty much
everything I want -- download and send mail, login to home with SSH,
check a few web pages, etc. If all I had is WAP, I'd be stuck.

If you want, it is still possible to "reconstruct" a true end-to-end
IP service by tunneling it through a NAT with something vaguely
resembling mobile IP. Such a scheme would probably use UDP or TCP as
its encapsulation wrapper so the NAT would have port numbers to keep
it happy, and it would require a cooperating tunnel at the far end
with "real" IP addresses it can hand out. Ugly, yes. But it would
work, and if this became widespread enough it might even convince the
carriers to reform their ways. (I can dream, can't I?)
 
In the meantime, I see a growing business opportunity here for
companies wishing to provide such VPN/tunnel endpoint services for
those who don't want to set up local NATs to hang multiple computers
off their one-IP-address-per-user dialup, DSL or cable ISPs, or who
don't want to deal with their carriers' ever-changing dynamic IP
address assignments. This would also be a good way to bootstrap your
way to IPv6 when your local ISP isn't interested.

Phil

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jun 0 5:42:32 JST

Phil;

> it's nowhere near as bad as WAP.

If you think so, don't say "end-to-end".

> resembling mobile IP.

You can have IP over HTTP, IP over XML or IP over WAP equally easily.

The problem, however, is that the reconstruction point is an
intelligent gateway which violates the end to end principle.

							Masataka Ohta

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Jun 2000 16:55:18 -0400

Phil Karn wrote:

> with "real" IP addresses it can hand out.

PPP over ssh, maybe?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Peace, justice, morality, culture, family,   |
[email-masked]|sport, and the extinction of all other life  |
|                |forms!                                       |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Jun 2000 17:21:06 -0400

> intelligent gateway which violates the end to end principle.

Mmm, how so? I'd see it as a router, which just happens to run over a
higher-level protocol than most.  Not a great design, but it does (can)
give you end-to-end IP.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Your reality, sir, is lies & balderdash, and I|
[email-masked]|am pleased to say I have no grasp on it        |
|                |whatsoever!" --Baron Munchausen                |
\================================================================/

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jun 0 9:14:19 JST

John;

> higher-level protocol than most.

No, it is no router of the Internet. For example, your protocol does not
interact with the routing metric of the Internet.

> Not a great design, but it does (can)
> give you end-to-end IP.

Like NAT, it works most of the time, unless you try things
unsupported by the so intelligent gateway.

Of course, you can insist NAT offer end-to-end IP.

						Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Jun 2000 21:26:45 -0400

>  Sprint PCS uses a NAT,

wish I had known that before I bought one of their phones.

criminals.

Keith

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 21 Jun 2000 03:50:29 -0000

>>>>> On Tue, 20 Jun 2000 10:30:31 -0400, "Brijesh Kumar" <[email-masked]> said:

  Brijesh> It is an open secret that wireless industry is a closed cartel of
  Brijesh> three super heavyweights (Motorola, Ericsson, and Nokia) and two heavy
  Brijesh> weights (Lucent and Nortel). There is no role for any smaller
  Brijesh> organization in the set up. Hope God give you wisdom to  accept this
  Brijesh> truth with cheerfulness, as many other small companies in the wireless
  Brijesh> industry have accepted ;-).

I don't want that "wisdom".

I want to challenge the status quo based on the power
of truly open protocols, the Internet end-to-end
model and free software.

The WAP Trap paper is just a beginning ...

What you call super heavyweiths, I call dinosaurs.

Those "heavyweights" who have placed their bets on WAP,
are now caught in their own mess. 

WAP introduces the Phone Company -- equipped by the
likes of Phone.Com -- as a fictitious middle man
acting as a gate-keeper. While gate-keepers are an
integral part of the tele-com model, they have no
place in the data-com world.

I full agree with Phil Karn when he says:

>>>>> On Tue, 20 Jun 2000 12:36:47 -0700 (PDT), Phil Karn <[email-masked]> said:

  Phil> One thing missing from most block diagrams of WAP is the chute on the
  Phil> bottom of the carrier's WAP gateway pouring out money. It's safe to
  Phil> say that this chute is WAP's primary reason for existence.

  Phil> WAP has gotten as far as it has (which isn't very far) only because
  Phil> cell phones are closed, proprietary devices. The end user has no
  Phil> choice which software or protocols it runs. The vendors make that
  Phil> decision for you.

  Phil> ...

  Phil> The Internet end-to-end model will once again prevail, putting the
  Phil> cellular service providers back into their proper place as providers
  Phil> of packet pipes, nothing more. And life will be good again. :-)

As for,

  Brijesh> PS: By the way, ReFLEX is perfectly fine for two way messaging
  Brijesh> applications.

No. 

ReFLEX is not perfectly fine.

It is not IP based.

...Mohsen.

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 21 Jun 2000 04:14:46 -0000

>>>>> On Wed, 21 Jun 2000 04:59:15 +0859 (), Masataka Ohta <[email-masked]> said:

  >> of packet pipes, nothing more. And life will be good again. :-)

  Masataka> IP over NAT is, in no way, end-to-end.

Point taken. 

NAT is not end-to-end.  

End-to-end is good karma.

  Masataka> WAP and IP over NAT are equally bad.

We have two sets of problems and layering helps here.

At layer 3, we need to make things end-to-end.

At layer 7, the WAP approach is simply the wrong approach.

We need competition in the efficient appliction protocols
space. 

As you pointed out more than a month ago:

   Masataka> To make the competition fair, the important questions are:

  Masataka> 	Is it fair if providers using iMODE or WAP are advertised
  Masataka> 	to be ISPs?

  Masataka> 	Is it fair if providers using NAT are advertised to be ISPs?

  Masataka> My answer to both questions is

  Masataka> 	No, while they may be Internet Service Access Providers and
  Masataka> 	NAT users may be IP Service Providers, they don't provide
  Masataka> 	Internet service and are no ISPs.

Which in my thinking is equivalent of saying that WAP is at best an
Internet gateway model. Which is consistent to my position in The WAP
Trap paper ...

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 21 Jun 2000 10:40:40 +0200

From: Masataka Ohta <[email-masked]>
Subject: Re: WAP Is A Trap -- Reject WAP
Date: Wed, 21 Jun 0 5:42:32 JST

> You can have IP over HTTP, IP over XML or IP over WAP equally easily.

With IP over MIME you could even establish an IP connection over a mail
gateway, firewall bypassing... Hmm.... the same goes for http proxies.

> intelligent gateway which violates the end to end principle.

Havent we learned to love and hate these breaking of layering?

You can put basically anything over anything else when it comes to just moving
bits around. While doing this we get the additional benefits of increased
propagation delay, increased overhead, often complexer solutions and a new
bag of problems in the interworking area. Lovely. We can feed a lot of
research and engineer mouths this way.

Now, while NAT and WAP both intend to solve some problems, they provide ground
for new problems which naturally require new solutions. We should really ask
weither some of these problems really should be solved within that scope or
not. If IP over WAP is a bag of worms, maybe one should bypass WAP alltogether.
Where we know that neither ATM, IP or NAT solves all the problems neither will
WAP.

It is not really what you could do as what you should do. Naturally there is
allways politically and technical preferences which prohibits some solutions.

Cheers,
Magnus

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 21 Jun 2000 07:31:06 -0400

See <ftp://ftp.ietf.org//internet-drafts/draft-eastlake-ip-mime-03.txt>.

Donald

From:  Magnus Danielson <[email-masked]>
To:  [email-masked]
Cc:  [email-masked], [email-masked], [email-masked]
In-Reply-To:  <[email-masked]>
References:  <[email-masked]>
	    	<[email-masked]>
Message-Id:  <[email-masked]>
Date:  Wed, 21 Jun 2000 10:40:40 +0200

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 21 Jun 2000 14:35:18 +0200

From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
Date: Wed, 21 Jun 2000 07:31:06 -0400

> See <ftp://ftp.ietf.org//internet-drafts/draft-eastlake-ip-mime-03.txt>.

For once people could spend some time reading the security considerations.

Cheers,
Magnus

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 21 Jun 2000 11:05:43 -0400

> ReFLEX is not perfectly fine.

Hi Mohsen,

What kind of argument is this?

If it is not IP based it is not good ! This is an emotional response,
not a technical one. Using the same arguments, the whole phone system
isn't good because it has nothing to do with IP (or at least was true
till VoIP came), and same is true of all G2 TDMA, CDMA and GSM
cellular systems (and don't forget AMPS, CDECT and many other wireless
standards).

If you want to say that WAP is not good because it closes alternative
solutions, I very much agree with you (which a good reason to fight
for). But to say that an existing wireless standard that has millions
of users is no good, isn't a proper argument. I agree that ReFLEX is a
proprietary standard, and proprietary standards (with controlled
licensing as ReFLEX is) are bad for consumers - you can definitely
argue on that basis.

But you cannot argue on technical merits of the protocol itself
because it is very efficient in delivery of email messages. Using a 25
KHz channel it can support thousands of devices. It is not only very
efficient in usage of radio spectrum, and it is well known that
under-ground or in-building penetration of FLEX/ReFLEX systems is far
better than any other cellular systems. Of course, it is not designed
for interactive real time operations - but email doesn't require
sub-milli seconds response nor do many telemetry systems such as coke
machine and electric meters in houses. Even ARDIS network, the grand
daddy of wireless data networking in US, has nothing to do with IP.

The WAP's goal was to support just about every possible Radio layer.
It is all inclusive and does support IP devices (which use CDPD, GPRS
or CDMA/GSM - IWUs).
Moreover, TCP/IP isn't designed for wireless channels which have
limitations on bandwidth, frequent handovers, channel errors, and
periods when channel isn't available at all (of course, number of
solutions some of them are pure software hacks, such as snooping TCP
halfway at BS etc., have been proposed. Of course, we haven't yet
figured out how to initiate an application between two devices when
both sit behind NATs at this scale (try sending a TCP connection
message from one cellular phone to another cellular phone in the car
and assume that both have them have no permanent IP addresses !). You
will need true IPv6 without which IP with NAT isn't going to go long
distance in wireless devices.

What I wished to point out was that you definitely have a good
objective, but the approach is not right. The real issue is should all
technology be supported by a single set of WAP Forum derived
specifications. What is good for ReFLEX (@9600 bauds) isn't good for
CDPD at 19.2 Kbps and definitely isn't good at 170kbps GPRS, or 2
Mbits/sec G3 micro cells. I think there you have some good arguments.
Given that most cellular devices or systems come from three  super
heavy weights, and two heavy weights, any solutions that doesn't get
supported by some of them, has little  chance to get adopted in near
future. But try - you definitely can, and should.

Cheers,

--brijesh
Ennovate Networks Inc.
(my personal views only, and in no way reflect opinions of my
organization.)

---

From: Dennis Glatting <[email-masked]>
Date: Wed, 21 Jun 2000 10:47:37 -0700

I haven't read the WAP technical documents but I am struggling with
the concept of a protocol created by the WAP Forum being secure and
without snooping features. (I don't consider WTLS significant, rather
a feel good measure.) Would someone more knowledgeable on WAP and
their security model comment?

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 20 Jun 2000 19:02:39 +0100 (BST)

> (I say "pretty sure" because I haven't done any WAP development,

There's parsing/tokenisation/compression applied at the service
provider's gateway, which requires that all pages validate
correctly and strictly for this translation to work.

This and other implementation details are discussed in:

http://www.osopinion.com/Opinions/MikeBanahan/MikeBanahan1.html

some relevant bits of that:

  HOWEVER - and it'a big however - your phone is not talking the
  normal HTTP protocol to the remote web server; it is talking WAP to
  the intermediate gateway. The gateway fetches the WML page from the
  remote server and then converts it into WML bytecode - a compiled
  data stream - which is what the phone actually receives. 
  [..]
  The sad or funny bit, depending on your viewpoint, is that the
  gateway really is a compiler. If you miss a comma or a semicolon,
  or even forget to put quotes around an element's attributes, then
  your WML is erroneous. Presumably the gateway prints a suitable
  'syntax error at line 11' message on its console when this happens,
  but since HTTP is a one-way protocol there is no way that your web
  server can tell this and you won't get any feedback if you've got it
  wrong. On the Nokia 7110 that I use all that I see is 'Page cannot
  be displayed'. Believe me, these gateways are strict.

Just imagine how many webpages you'd be able to read if your proxy
cache insisted on validating them against a DTD before sending them to
you...

And from that anti-WAP polemic:

it's rms's 'do not use Tcl because I say so' all over again!

L.

will be quite happy if WAP fails on its own merits, thankyouverymuch.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Jun 0 14:19:21 JST

Mohsen;

> At layer 7, the WAP approach is simply the wrong approach.

I'm operating on all the  layers.

> We need competition in the efficient appliction protocols

As TCP/UDP port space is, so far without NAT, large enough, we don't
have any real problems.

> Internet gateway model. Which is consistent to my position in The WAP

Thank you.

						Masataka Ohta

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 22 Jun 2000 19:48:07 -0000

>>>>> On Tue, 20 Jun 2000 19:02:39 +0100 (BST), Lloyd Wood <[email-masked]> said:

  Lloyd> And from that anti-WAP polemic:

  Mohsen> We gratefully acknowledge the assistance of the
  Mohsen> following persons in the preparation and review of
  Mohsen> this document:  Andrew Hammoude, Richard Stallman,
  Mohsen> Bill Frezza and Rob Mechaley.

  Lloyd> it's rms's 'do not use Tcl because I say so' all over again!

Please target ALL your criticisms of "The WAP Trap" to it author,
Mohsen Banan. I wrote that paper. The paper represents my positions.

The heart of "The WAP Trap" revolves around patented protocols.

RMS's involvement in the Free Protocols Foundation is centered around
the harm of patented protocols. That is consistent with his track
record and leadership on this issue.

Do you have anything against patent-free protocols and in favor of
patented protocols?

If not, then you, RMS and I are on the same side of this issue.

  Lloyd> will be quite happy if WAP fails on its own merits, thankyouverymuch.

WAP will fail on its own merit.

The main issue here is "patents" and "protocols".

Most of the discussions on the IETF list so far has been techie-talk.

I also want to worry about the bigger picture.

Should we just wait for the next WAP, where businessmen and marketeers
pull another fast one on the industry?

My paper says that we can take certain steps to prevent that. 

...Mohsen.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 22 Jun 2000 21:03:13 +0100 (BST)

> Mohsen Banan. I wrote that paper. The paper represents my positions.

Since that paper is published by the Free Protocols Foundation, one
might assume that it is endorsed by the FPF, and that the positions
stated are, where not disclaimed, those of the FPF.

L.

I have trouble separating rms from GNU from FSF too.

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 23 Jun 2000 21:17:32 -0000

>>>>> On Wed, 21 Jun 2000 11:05:43 -0400, "Brijesh Kumar" <[email-masked]> said:

  Mohsen> No.
  Mohsen> 
  Mohsen> ReFLEX is not perfectly fine.
  Mohsen> 
  Mohsen> It is not IP based.

  Brijesh> Hi Mohsen,

  Brijesh> What kind of argument is this?

You used the words "ReFLEX is perfectly fine for ...".

I could have challenged that claim based on any of several points that
you yourself mentioned. I chose the IP argument because it is the most
powerful and least obvious one in the case of ReFLEX.

ReFLEX is not IP based and it could have been IP based.

  Brijesh> If it is not IP based it is not good ! This is an emotional response,
  Brijesh> not a technical one. Using the same arguments, the whole phone system
  Brijesh> isn't good because it has nothing to do with IP (or at least was true
  Brijesh> till VoIP came), and same is true of all G2 TDMA, CDMA and GSM
  Brijesh> cellular systems (and don't forget AMPS, CDECT and many other wireless
  Brijesh> standards).

The networks that you have mentioned above were in place before IP's
power became clear.  That is a legitimate excuse for their non IP
nature. I would say the knee of the curve was in 1992.

ReFLEX on the other hand can not use that excuse because it came after
1992. ReFLEX's Narrowband PCS licenses came out in 1995.

The remaining excuse for ReFLEX not being IP based is efficiency.

It is very feasible and reasonable to build a highly efficient IP
based slow wireless network. An initial such attempt using the
Narrowband PCS spectrum (same as ReFLEX) was called pACT. The failure
of pACT was due to AT&T's business withdrawal in 1997 -- not
technology. pACT could have been real competition for ReFLEX.

Derivatives of pACT related work are in use in bandwidth constrained
environments. The last leg of IP in wireless environments can be made
highly efficient.

In this day and age, citing efficiency as a rationale for building a
non-IP based network is a lame excuse.

Later you said:

>>>>> On Thu, 22 Jun 2000 11:39:11 -0400, "Brijesh Kumar" <[email-masked]> said:

  Brijesh> Let us take case of a CDPD device that has a IP address. CDPD has one
  Brijesh> of the largest coverage in US and is geared for data communication.
  Brijesh> Now CDPD works at 19.2 Kbps, and uses spare capacity from AMPs
  Brijesh> channel, and when no channel is available that a device looks for
  Brijesh> voice gaps in other channels to send data.

I am one of the primary architects of the CDPD Specifications --
starting with rev. 0.3 in Dec. 92.

I would like to believe that the main reason why CDPD is IP based is
because of my involvement. Prior to my involvement it was not IP
based.

  Brijesh> With these kind of losses TCP
  Brijesh> throughput tanks!. So we need a wireless medium aware version of TCP
  Brijesh> or some hacks for TCP to be efficient under losses (see relevant
  Brijesh> literature).

Others (Steve Deering, Vernon Schryver, ...) have already pointed out
that above layer 3, wirelessness is irrelevant. 

When it comes to wirelessness, above layer 3 the name of the game is
"EFFICIENCY" -- and all dimensions of it.

There is a place for something else in addition to TCP, but not for
the reasons that you mentioned. More on this later.

...Mohsen.

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 23 Jun 2000 18:28:02 -0400

> -----Original Message-----

Hi Mohsen,

Let me clarify this issue once again.

1. If FPF opposes WAP because it involves a patent, and a protocol
should be patent free, I guess most people on this list will agree
with you (though I doubt many people have much to do with WAP on this
list, and care about it).

2. If FPF says that all future wireless end devices should have IP so
that there is no need to have a solution like WAP gateways, I think
most people will agree with you on this too.  That is happening any
way.

3. If FPF says that vendors should go back and modify all current
cell-phones and pagers and cellular infrastructure components, discard
WAP protocols, and use UDP/TCP/IP based solutions; it is not going to
happen no matter how many people support this position on this list.
WAP is a short term solution for this generation's networks/devices,
and will automatically die when next generation network/devices
arrive.

You must position Free Software foundation's work to make WAP, or any
other future protocols free from any patent. You will find lot of
support on that issue. I think we all agree on this.

Cheers,

--brijesh
(personal opinion only)