[ Please distribute this as widely as possible, wherever appropriate. ]
----
The WAP Trap
An Expose of the Wireless Application Protocol
Mohsen Banan <public(_at_)mohsen(_dot_)banan(_dot_)1(_dot_)byname(_dot_)net>
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.