The basic problem that WAP purports to address is very real: that of providing website access from a cell phone. (More generally, the central web browsing problem is that of providing website access from miniaturized devices in general, including PDAs, pagers, etc. WAP is heavily oriented towards the cell phone in particular; however the required industry solution must address miniaturized devices in general.) A particular website may be very full-featured, including rich content which cannot be displayed on the limited cell phone display. In order for the phone to provide meaningful presentation of this website, an appropriate subset of the website content must be extracted and downloaded to the phone.
There is nothing bogus about this problem - only about the way WAP has gone about solving it. A key architectural component of the WAP solution is the WAP Gateway, which stands between the cell phone and the website, and which actively participates in the data extraction/download process. The catastrophic problem with this is that it totally violates the Internet End-to-End principle - the gateway is now interposed as an active authority between the client and the website.
Clearly, the WAP Gateway exists for business reasons, not engineering ones. Control of the gateway, together with control of the cell phone WAP software which can preferentially direct end-users to one gateway rather than another, creates enormous business opportunities for the gateway operator. This is the fundamental raison d'etre of the WAP Gateway; and everthing else in the WAP model, including the protocols themselves, falls secondary to this.
In other words, the entire WAP construct is an attempt by the wireless network operators and phone manufacturers to hijack the Mobile Web Browsing industry. If there was ever an example of the business dog wagging the engineering tail, this surely is it.
The basic motivation behind the WAP Gateway is aptly summed up in the following e-mail, posted to the IETF public mailing list by Phil Karn, an engineer at Qualcomm (itself a longtime WAP Forum member), in response to The WAP Trap. Material omitted from Mr. Karn's e-mail is indicated by ellipses; otherwise, he is quoted verbatim:
From: Phil Karn <karn@qualcomm.com>
To: public@MOHSEN.BANAN.1.BYNAME.NET
CC: ietf@ietf.org, karn@qualcomm.com
Subject: Re: WAP Is A Trap -- Reject WAP
Date: Tue, 20 Jun 2000 12:36:47 -0700 (PDT)
Message-Id: <200006201936.MAA26742@servo.qualcomm.com>
... I also scratched my head when WAP came out. It just didn't make any
technical sense. I see I'm not the only one; bravo for writing such a
good critique.
One thing missing from most block diagrams of WAP is the chute on the
bottom of the carrier's WAP gateway pouring out money. It's safe to
say that this chute is WAP's primary reason for existence.
... The Internet end-to-end model will once again prevail, putting the
cellular service providers back into their proper place as providers
of packet pipes, nothing more. And life will be good again. :-)
However, the wireless industry has now created the components required to solve the central web browsing problem the right way - and without WAP. In particular, two major developments have now rendered WAP completely irrelevant:
Figure 1 shows the protocol stacks for web browsing under three different implementations: the WAP architecture, an architecture based on XHTML, and an architecture based on XHTML and LEAP.
Furthermore, XHTML is an open, Internet-mainstream protocol, and conforms fully to the Internet End-to-End principle. The model of Figure 1(b) therefore provides Mobile Web Browsing the right way - i.e. based on a truly open industry model.
(Note: The model of Figure 1(b) is essentially the basis of the popular Japanese I-Mode system.)
For complete details about XHTML visit http://www.w3.org/MarkUp/. For information about W3C visit their website at http://www.w3.org/.
A disadvantage to the implementation of Figure 1(b) is that it requires the use of HTTP and TCP, which have serious inefficiency characteristics for the limited-size data transfer implied by miniaturized handheld devices. In the following sections we will see how the LEAP protocols can provide the required efficiency.
The implementation of Internet applications such as web browsing in the wireless arena places a very high premium on the efficiency of data transfer. Wide area wireless networks demand bandwidth efficiency; miniaturized devices demand power efficiency; and the end user demands reliability and minimum latency. The underlying wireless protocols must provide all the required efficiencies.
The claim is sometimes made that the need for efficiency in the wireless arena is a temporary one - that advances in wireless engineering technology (such as third generation (3G) systems and 802.11b[5]) will eliminate existing bandwidth limitations, obviating the need for efficient protocols. And indeed some high-speed networks have been implemented which demonstrate the capabilities of next-generation technologies.
However, thus far such implementations have been limited in scope. They have been limited to a relatively small coverage area, or they have been limited in terms of their support for active mobility - i.e. they support only static wireless devices. But the efficiency demands of wireless networks with very large coverage areas (i.e. nationwide or worldwide), and which support active, in-motion mobility, are very much greater. And despite future advances in network speed, efficiency will remain a desirable goal as long as the capacity of wide-area wireless networks remains finite.
For these reasons, efficiency will remain a crucial aspect of wireless network usage for some time to come.
Because of the very limited display capabilities of miniature handheld devices, Mobile Web Browsing of necessity involves the transfer of relatively small amounts of data. In other words, Mobile Web Browsing is an inherently limited data-size activity.
As connection-oriented protocols, HTTP and TCP are most efficient for large data transfers; however they provide very poor efficiency for short data transfers. This means that HTTP and TCP are sub-optimal protocols for Mobile Web Browsing, and the scenario of Figure 1(b), though open and WAP-free, is a highly inefficient implementation.
Therefore an appropriate set of protocols are required to provide the necessary efficiency; and we are proposing the LEAP protocols as candidates for this role.
The Lightweight & Efficient Application Protocols (LEAP) is a family of high-performance, efficient protocols that are ideal for mobile and wireless applications. In sharp contrast to WAP, the LEAP protocols are truly open, RFC published, and patent-free; and declarations of the patent-free nature of the protocols have been made to the Free Protocols Foundation. For a comprehensive description of the LEAP protocols see The LEAP Manifesto, available on-line at http://www.LeapForum.org/leap/.
In addition, open-source implementations of the LEAP protocols are
freely available through the MailMeAnywhere open-source software
distribution center; for details visit the MailMeAnywhere website at
http://www.MailMeAnywhere.org.
The initial focus of the LEAP protocols was on efficient Mobile Messaging, and the first two members of the LEAP family, EMSD (Efficient Mail Submission and Delivery; RFC-2524 [1]) and ESRO (Efficient Short Remote Operations; RFC-2188 [16]), were designed for this purpose. These protocols are now complete and in place, and a complete framework for the development of the open Mobile Messaging industry now exists. Given that, the focus of the LEAP Forum can move on to the next challenge: efficient web browsing.
Two members of the LEAP family of protocols are relevant to the web browsing application: ESRO and EHTD. ESRO provides reliable connectionless transport services which can be used for a variety of applications. For complete details on ESRO see the Manifesto article ESRO: A Foundation for the Development of Efficient Protocols, or visit the ESRO website at http://www.esro.org. EHTD (Efficient Hyper Text Delivery) is a hypertext transfer protocol which is optimized for the efficient transfer of short markup pages.
All the LEAP protocols are designed with a major emphasis on efficiency, and ESRO and EHTD together bring these efficiency benefits to the web browsing application. For short data transfers, EHTD is significantly more efficient than HTML, while ESRO is significantly more efficient than TCP - for example, TCP requires a minumum of 5 packets per transaction, whereas ESRO requires 2 or 3. For a detailed analysis of the efficiency of the LEAP protocols, see the Manifesto article Efficiency of EMSD [2]. That article analyses the efficiency of EMSD and ESRO specifically; however similar efficiency results can be expected in the case of EHTD and ESRO. In particular, ESRO and EHTD are highly efficient for the transfer of limited-size data, and are therefore ideal for the Mobile Web Browsing application.
Figure 1(c) shows how these protocols may be used in combination with XHTML and UDP [11] to provide a Mobile Web Browsing implementation that is completely open, WAP-free and efficient.
Note that the implementations of Figure 1(b) and Figure 1(c) are not mutually exclusive, but rather may be considered to be complementary. The connectionless protocol stack of Figure 1(c) is highly optimized for the short data transfers inherent to Mobile Web Browsing; whereas the connection-oriented stack of Figure 1(b) may be used for large data transfers whenever necessary.
ESRO is a complete, RFC-published protocol, for which open-source software implementations are ready and available for immediate deployment. The EHTD protocol, however, is still in its early stages of development. Those who wish to participate in the development of EHTD are invited to do so, and may do so via the LEAP Forum website at http://www.LeapForum.org.
The experience gained in the development of the WAP protocols can be of great assistance in the development of EHTD. In particular, the WAP specifications include various technical design errors, from which important lessons can be learned. In this regard the engineers who took part in the design of WAP, or who otherwise have a technical understanding of WAP, represent a particularly valuable resource. Their participation is encouraged and welcomed.
