The WAP Trap

A Permanent Libre Published Content

---

The WAP Trap

An Expose of the Wireless Application Protocol

Document Number:	PLPC-100014   [ .bib ]
Version:	1.6
Dated:	April 3, 2000
Group:	LEAP
Primary URL:	http://www.freeprotocols.org/PLPC/100014
Federated Publications:	ByTopic -- ByContent
AccessPage Revision:	This AccessPage was produced on July 04, 2013 at 0:50 PDT (-0700)
Author(s):	Mohsen BANAN, Andrew Hammoude
Organization:	Free Protocols Foundation

AVAILABLE FORMATS

• PDF: -- 184K -- Provides the document in Portable Document Format.
• PS: -- 184K -- Provides the document in Postscript format for printing.
• HTML: -- 204K -- Displays the document as a web page.

SHORT DESCRIPTION

This article provides a detailed criticism of a set of specifications called the Wireless Application Protocol, or WAP. This article demonstrates that WAP is entirely unfit to play the role of a Mobile Messaging industry standard.

This article has been translated into French. The French translation is available as PLPC-100015.

---

FULL INLINE DOCUMENT

Contents

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,

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 article entitled Lessons from History: Comparitive Case Studies within 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 & Efficient Application Protocols. 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:

• 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.
• The LEAP Manifesto [13]. This document provides a complete analysis of the industry, and a detailed description of the LEAP protocols.

1.3.1 Alternative Formats

In addition to this English-language version, this document has also been translated into French under the title Le WAP a la Trappe. Both English and French versions are available in several alternative formats at the Free Protocols Foundation website
(http://www.FreeProtocols.org/wapTrap):

• ONE-HTML: Displays the entire document as a single web page.
• SPLIT-HTML: Displays the document as a set of linked web pages, starting from the Table of Contents.
• 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.
• PS: Provides the document in PostScript format for printing.
• 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, Rob Mechaley, and Pinneke Tjandana.

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 may 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:

• 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.
• 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.
• 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.
• 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:

• 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.
• Restricted Distribution. In order to download any particular WAP specification, a user must agree to a license agreement.
• 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.
• 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:

• U.S. Patent # 5,327,529 (Geoworks). Process of designing user’s interfaces for application programs.
• 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:

• Strong preference for the adoption of patent-free technology wherever possible.
• The prompt, forthright disclosure of any actual or potential patent rights which may affect the protocol.
• 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],

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]

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]

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],

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:

• Work to reform the WAP Forum.
• Spread the word about the WAP fraud.
• Reject WAP at engineering level.
• Reject WAP at consumer level.
• 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 exposé 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:

• 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/.
• 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/.
• 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 Forum website at http://www.LeapForum.org.

Anyone interested in participating in the development of the LEAP protocols is invited to join the mailing lists hosted at the above-mentioned websites. 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