The WAP Trap An Expose of the Wireless Application Protocol Mohsen Banan for: Free Protocols Foundation www.FreeProtocols.org Version 1.6 First Published: April 3, 2000 Last Updated: May 26, 2000 1 Copyright fcl 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. ii Contents 1 Introduction 1 1.1 The Wireless Application Protocol (WAP) . . . . . . . . . . . . . . . . . . . . .* * . 1 1.2 Characteristics of Successful Protocols . 2 1.3 About this Document . . . . . . . . . . 3 1.3.1 Alternative Formats . . . . . . . 4 1.3.2 Acknowledgments . . . . . . . . 4 1.3.3 Conflict of Interest Disclosure . 4 2 WAP - A Procedural Fraud 5 2.1 Not Open in Terms of Development and Maintenance . . . . . . . . . . . . . . . . 5 2.2 No Assurance of Availability and Stabil- ity . . . . . . . . . . . . . . . . . . . . * * . 6 2.3 Not Patent-Free . . . . . . . . . . . . . 8 2.4 No Legitimacy as a Standard . . . . . . 11 3 WAP - A Technical Failure 11 3.1 User Interface Assumptions . . . . . . . 12 3.2 Extreme Accommodation to Existing Net- works . . . . . . . . . . . . . . . . . . . * * 13 3.3 Excessive Re-Invention in the Name of Wireless . . . . . . . . . . . . . . . . . * * 14 3.4 Vulnerable Wireless Transport Layer Se- curity (WTLS) . . . . . . . . . . . . . . 15 3.5 Bungled Protocol Number Assignment . 16 4 WAP - A Basic Misconception 16 4.1 The Wrong Answer Initially: Mobile Web Browsing . . . . . . . . . . . . . . . . . 17 4.2 The Right Answer Initially: Mobile Mes- saging . . . . . . . . . . . . . . . . . . . * * 18 4.3 Unsupported Claims . . . . . . . . . . . 19 4.3.1 Not Device-Independent . . . . 20 4.3.2 Limited Web Browsing Capabil- ities . . . . . . . . . . . . . . . .* * 20 4.3.3 Existing Technology Adequate . 21 4.3.4 Voice Interface Adequate . . . . 21 iii 5 Conclusion: WAP is a Trap 22 6 Preventing the Harm of WAP 23 6.1 Reform the WAP Forum . . . . . . . . . 23 6.2 Spread the Word about the WAP Fraud . 24 6.3 Reject WAP at Engineering Level . . . . 24 6.4 Reject WAP at Consumer Level . . . . . 25 6.5 Adopt an Alternative to WAP . . . . . . 25 7 LEAP: One Alternative To WAP 26 iv 1 Introduction The new Internet reality is that of wireless networks, pro- viding service to legions of miniaturized, hand-held mo- bile devices. This places an entirely new set of require- ments on the underlying communications protocols - they must provide the power efficiency demanded by hand- held wireless devices, together with the bandwidth effi- ciency demanded by wide area wireless networks. At some point, the wireless data communications in- dustry 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 in- dustry is populated by a number of disparate constituen- cies 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 specifi- cations referred to as the Wireless Application Proto- col, 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 speci- fication allows mobile devices to communicate with the Internet or an intranet, providing the users of these de- vices 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 man- ufacturers, service providers, and software companies. The WAP Forum was founded in June 1997 by three mo- bile phone manufacturers (Ericsson, Motorola and Nokia), together with the US software company Phone.com (for- merly 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 1 what the doctor ordered: a set of standards that will unify the wireless data applications industry. WAP presents it- self as an open, license-free standard for wireless Internet access. It claims to be a well-designed engineering con- struction, allowing free interoperability among wireless industry vendors. It claims to be an enabling technology that will catalyze the development of the wireless indus- try, to the ultimate benefit of the industry and the con- sumer. As we will argue in this article, however, WAP satis- fies none of these claims. 1.2 Characteristics of Successful Protocols Industry standards do not usually come about as the re- sult 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 Microsys- tems, 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 bet- ter than no solution at all. However, history has shown that successful protocols tend have certain characteristics in common. By a "suc- cessful" protocol, we mean one which becomes accepted as an industry standard in the face of competing proto- cols, 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 engi- neering 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 partic- ipation of the various constituencies that are af- fected by the protocol. 3. Open Availability Process. It should be published and made available in a way that ensures that it is 2 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. Any- one who wishes to base an application on the pro- tocol should be able to do so without legal or finan- cial hindrance of any kind. Not all successful protocols have all these attributes. Nevertheless, as the history of protocol development demon- strates, the more a protocol conforms to these attributes, the more likely it is to become an enduring industry stan- dard. An analysis of several successful and failed proto- cols, supporting this conclusion, is provided in the article entitled Lessons from History: Comparitive Case Studies within The LEAP Manifesto [12 ]. 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 Fo- rum 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 con- struct, 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 Proto- cols. 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 writ- ten 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: 3 - LEAP: One Alternative to WAP [11 ]. 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 [12 ]. 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 docu- ment 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 Pro- tocols 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 Con- tents. - PDF: Provides the document in Adobe Acrobat for- mat. Note that the Adobe Acrobat Reader is re- quired 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 for- mat. 1.3.2 Acknowledgments We gratefully acknowledge the assistance of the follow- ing persons in the preparation and review of this docu- ment: 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 develop- ers 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 4 article is being written. As participants in the FPF, we are fully committed to its patent-free principles; princi- ples 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 Foun- dation, 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 proto- col 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 con- ceived and built from the ground up by industry-wide consensus. Indeed, this is usually impractical, and of ne- cessity, 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. Be- yond that point, the various industry constituencies must be given an opportunity to participate in its design, and the design process must include mechanisms for reach- ing consensus among conflicting lobbies. 5 Openness of design has two important benefits. First, it allows the protocol to be subjected to adequate tech- nical review, ensuring that it is a sound engineering so- lution. Second, it prevents the design of the protocol from being excessively influenced by minority business self-interests. An open design process provides vital as- surance 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 insti- tutions that may participate in its development and main- tenance 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, member- ship 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 institu- tions. The WAP Forum is therefore a highly restricted sub- set of the business and academic community, and influ- ence 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 telecommu- nications world; specifically, it is primarily the creation of a set of telephone manufacturers. Though important, the telephone manufacturers represent just a single com- ponent 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 com- munity, and the small business community. 2.2 No Assurance of Availability and Sta- bility 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 tra- ditionally accomplished by means of RFC publication. RFC publication provides the following important ben- efits: - World-Wide Distribution. RFC publication en- sures unrestricted world-wide distribution of the pub- 6 lished 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 in- curring 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 busi- ness or otherwise become defunct, the RFC will remain in existence. - Stability. Once published, an RFC is fixed - it can- not undergo change. If a new revision of the stan- dard must be issued, this is handled by issuing the revision under a new RFC number. The WAP specifications do not carry these same as- surances 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 pub- lication is in some way diminished: - Limited Distribution. The specifications are only available from a single source: the WAP Forum it- self. 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 speci- fications 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 sub- ject to change without notice." This last item is particularly worrisome. A key at- tribute of a protocol is that any particular revision of it be fixed - indeed, this is the very definition of a standard. 7 The WAP Forum's disclaimer gives it the power to mod- ify 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 theoreti- cal concern - the WAP Forum has already exercised this power inappropriately [13 ]. 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 ques- tion is: Why? We can think of only three plausible rea- sons: 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 re- strictions 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 In- ternet 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 particu- lar, 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: 8 - 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 Un- wired Planet). Method and architecture for an in- teractive 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 en- vironment 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 cor- rupts 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 con- sumer. Patents thus pose a significant danger to protocols. For this reason, the protocol development process must include mechanisms to address and eliminate patent re- strictions. Such mechanisms exist, and are well-known and understood within the Internet community. For ex- ample, we refer the reader to RFC 2026, The Internet Standards Process - Revision 3 [3 ]. Section 10 of this document, Intellectual Property Rights, describes the poli- cies and procedures followed by the IESG (Internet En- gineering 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 proto- col. - 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 pro- tocol. 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. 9 As another example, the Free Protocols Foundation publishes a set of policies and procedures for protocol de- velopment that ensures, as far as possible, that the result- ing protocol is functionally patent-free. These procedures are fully documented in the Free Protocols Foundation Policies and Procedures, Version 1.0 [10 ]. Any develop- ment organization is free to adopt these procedures with regard to its own protocols. The WAP Forum, clearly, has not followed the ex- ample set by the Internet community at large. Procedures such as those of the IESG and the Free Protocols Founda- tion 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 devel- opment 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 be- gan to spread throughout the industry, and only then did they announce their patent ownership and demand royal- ties. 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 diametri- cally opposed to this. To quote Ben Linder, VP of Mar- keting for Phone.com [6 ], "By virtue of building a standard, each com- pany 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 ex- pected 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 com- pletely. The WAP Forum's characterization of WAP as an "open, license-free standard" is utterly preposterous. 10 2.4 No Legitimacy as a Standard Throughout its web site and printed materials, the WAP Forum repeatedly refers to its specification as a "stan- dard." The use of this term is inappropriate and mislead- ing. 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, pro- fessional standards organization, and (b) has achieved industry-wide acceptance and usage. The WAP specification enjoys neither form of legit- imacy. It is approved by no organization other than the WAP Forum itself, which has no standing as a profes- sional 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" im- plies 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 specifica- tion is beyond the scope of this document, and in this section we will do no more than provide a brief sum- mary of the major issues. For a detailed analysis of WAP, the reader is referred to the article W* Effect Consid- ered Harmful [13 ], in which author Rohit Khare argues the shortcomings and ultimate non-viability of the WAP specification. The deficiencies in the WAP specification are glar- ing, obvious, and readily apparent to any competent data communications professional. A recent (January 2000) e- 11 mail discussion thread on the IETF mailing list [7 ] makes this point quite plainly - this thread demonstrates clear consensus among professionals that the WAP specifica- tions are not a technically sound engineering solution. Many of the technical problems stem from a strate- gic 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 In- ternet protocol stack is discarded, and a completely new protocol stack is re-designed from scratch. The WAP Forum made the early strategic design de- cision to take the latter approach. They have developed an entire stack of network protocols analogous to, but largely incompatible with, the existing Internet architec- ture. 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 de- sign 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 prin- ciple 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 specifi- cation, with the result that user interface issues are re- peatedly combined and confused with communications issues. To put this in the language of data communica- tions 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 prin- 12 ciples. 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 ex- isting wireless networks. The WAP specification claims to accommodate almost all existing networks, including several which are already obsolete in their usage and gen- eral design. This has significantly and unnecessarily in- creased the complexity of the specification. The WAP specification claims to support all the fol- lowing 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 nei- ther intended nor designed to run Internet-centric appli- cation protocols of any kind. WAP's decision to accom- modate such networks makes little sense in engineering terms. This decision can only have been based on market- ing 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. 13 WAP claims to achieve accommodation of this very wide range of networks by means of two lower layer pro- tocols: 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 mecha- nism. In other words, WCMP is largely irrelevant. WDP is roughly equivalent to UDP. The only ratio- nale 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 accommoda- tion and backward compatibility. WAP's choice has been to accommodate all existing old wireless networks - a fact which betrays its underly- ing 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 Fo- rum. 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 deliver- ing efficient reliability to applications. Even in that area, WAP could have re-used existing technology. Specifi- cally, T/TCP [2 ] and ESRO [14 ], which had already been published as Internet RFCs, could have been used. While 14 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 proto- cols, but with minor modifications that render them in- compatible with the original standard. The WAP specifi- cation 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 unnec- essary. 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 ex- panded 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 mo- bile devices present a unique special case, requiring a completely new set of protocols. In fact there is noth- ing 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 [9 ], 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 prob- lems have been identified with WTLS. These problems include: vulnerability to datagram truncation attack, mes- sage 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. How- ever, 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 dif- 15 ficulties. 3.5 Bungled Protocol Number Assignment As Khare discusses in greater detail [13 ], 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 devi- ation 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, rep- resent two very different forms of mobile communica- tions activity. Mobile Messaging refers to the ability to send and receive personally directed messages, while Mo- bile 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 activi- ties. 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 at- tention, to be pushed to him/her quickly. This is some- thing which is of inherent and compelling value to the off-line, mobile user. By contrast, the desire of the mo- bile 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 appli- cations represents the best initial value? We believe that Mobile Messaging is the right answer for initial mobile applications development. 16 4.1 The Wrong Answer Initially: Mobile Web Browsing The basic goal of the WAP specification is to allow Inter- net web browsing using mobile phones. The assumptions underlying this goal are, first, that web browsing capabil- ity can be adequately accomplished on a mobile phone, and second, that this is something that will be of signifi- cant value to mobile phone users. However, we believe that neither of these assump- tions is correct. First, the cell phone of today is a totally inappropriate device for the purpose of accessing the ma- ture Internet. Not only is the cell phone user interface completely inadequate for general web page display, but the wireless network medium also imposes severe limi- tations on the speed, immediacy, and reliability of web page access. It is simply not practical to surf the web us- ing 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' [8 ] "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 net- work, 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 be- fore 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 conve- nient 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 capabili- ties. 17 Second, there is the question of what people are actu- ally 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 em- braced 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 spe- cific 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, brows- ing, 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 brows- ing will remain a marginal component of mobile commu- nications. 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 cre- ates in the user stems from its technological novelty, not from its enduring day-to-day usefulness. 4.2 The Right Answer Initially: Mobile Mes- saging This is not to say that all Internet data access is with- out value to the user. On the contrary, consumers cer- tainly will use their mobile phones for Internet data ac- cess. However, the nature and types of data they will ac- cess 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 bet- 18 ter than any other is mobile messaging, or e-mail. In- terpersonal messaging has already become an indispens- able aspect of modern life, and is now the dominant ap- plication 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 surround- ing 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 essen- tially 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. Be- yond 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 dis- play. 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 web- site 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 [4 ] "A running joke among industry players has the WAP acronym meaning Where Are the Phones?" WAP phones and services are not available in the mar- ketplace, because the promises of WAP are simply not real. 19 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 ori- ented towards the mobile telephone physical device, de- spite 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 sim- ply 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 con- trolled by the Service Provider (typically the wireless phone service provider), not the information provider. This us- age 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 Ser- vice 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 cre- ators 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 au- thority. In the WAP model, by contrast, the WAP gateway op- erated by the Service Provider plays the active role of 20 translating and storing web content, and therefore con- trols access to the content by the end-user. New web- sites and new web content do not become available to the end-user without the active participation of the Ser- vice Provider. This places a layer of control and author- ity between the creator and consumer of website content, greatly diminishing the potential for unrestricted and or- ganic growth of the Internet. 4.3.3 Existing Technology Adequate The premise of providing access to important informa- tion 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 accom- plished using existing and already widespread technolo- gies such as SMS. Indeed, this is already being accom- plished today. Various companies, including Xypoint, AmikaNow!, Roku, ThinAirApps and Microsoft, are al- ready 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 ser- vices, see [4 ]. 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 applica- tions 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 im- 21 plementation of increasingly reliable speech recognition and powerful text-to-speech systems can be expected to make data transfer via the voice interface even more con- venient. 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 wire- less data applications. However, we believe that WAP is utterly unfit for this purpose. As we have shown in this ar- ticle, 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 incompe- tent 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 in- tegrity. The WAP Forum could easily have taken steps to elim- inate 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 straight- forward 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 perma- nent 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 to- wards 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? 22 We can come to only one conclusion: WAP was de- signed to create unfair market advantage for its devel- opers from the outset. They have maintained strict and close control of the protocol from the beginning, in com- plete 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 en- abling 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 engi- neering 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 [5 ], "Companies in the WAP Forum generally set- tle 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: - 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. 23 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. Work- ing 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 no- tices are preserved. You are encouraged to bring this arti- cle 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 them- selves 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 Foun- dation maintains a set of informational resources on its website at http://www.freeprotocols.org/harmOfWap/main.html. These resources include references to various other pa- pers 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 infor- mation pool at the Free Protocols Foundation - any com- ments, articles or other information may be submitted to the FPF via our website. 24 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 pur- chase WAP devices - in other words, to boycott these devices. However, the WAP question is a very complex tech- nical 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 un- derstanding 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. Ul- timately, therefore, WAP can be displaced only by the adoption of a suitable alternative. One traditional source of Internet protocols is the In- ternet Engineering Task Force, or IETF. To our knowl- edge, however, the IETF does not currently have a work- ing 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 in- dustry, 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 des- perately 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 Ap- plication Protocol. LEAP is immediately available, and has all the characteristics required to displace WAP and become the basis of an industry standard. A brief descrip- tion of LEAP is provided in the following section. 25 To the best of our knowledge, LEAP is the only vi- able 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 Foun- dation, 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 engineer- ing 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 connection- less transport mechanism, forming the foundation for the development of efficient protocols when TCP is too much and UDP is too little. ESRO was pub- lished as RFC-2188[14 ] in September of 1997. The ESRO protocol is publicly maintained and devel- oped by ESRO.org at http://www.esro.org/. - Efficient Mail Submission and Delivery Proto- col (EMSD). EMSD is designed to address the mobile messag- ing (e-mail) application. EMSD was published as RFC-2524 [1 ] in March of 1999. The EMSD proto- col 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 cur- rently undergoing public development at http://www.freeprotocols.org/E* *HTD. Open source implementations of the ESRO and EMSD protocols are being made available as free software at: http://www.MailMeAnywhere.org/. 26 The LEAP protocols, in combination with existing Internet protocols, properly address the same set of re- quirements that WAP claims to address. They have all the preferred protocol characteristics described in Sec- tion 1.2. They are published as Internet RFCs, are pub- licly maintained, and suffer from none of the technical deficiencies ascribed to the WAP specifications. In addi- tion, the LEAP protocols fully conform to the patent-free policies and procedures of the Free Protocols Foundation [10 ]. 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 [11 ], 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 pro- vided in The LEAP Manifesto [12 ], 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 devel- opment process is truly open and non-exclusive. There are no membership fees. Participation in the LEAP de- velopment process requires only that you commit to the patent-free intent of LEAP and the Free Protocols Foun- dation. 27 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. On- line document is available at ftp://ftp.isi.edu/in- notes/rfc2524.txt. [2] B. Braden. T/TCP - TCP extensions for transac- tions functional specification. Request for Com- ments (Experimental) 1644, Internet Engineering Task Force, July 1994. [3] S. Bradner. The Internet Standards Process - Revi- sion 3. RFC 2026, Internet Engineering Task Force, October 1996. (Obsoletes RFC1602). [4] Antony Bruno. Market gap producing WAP alter- natives. RCR News [Online], February 2000. The copy of this article can be obtained at RCR News web site (http://www.rcrnews.com).. [5] ComputerWire, Inc. Geoworks' Intellectual Prop- erty Claims Could "Kill WAP". Computergram 2000, January 2000. [6] Corey Grice, John Borland. Geoworks Soars on Wireless Licensing Plans. Staff Writers, CNET News.com, January 2000. [7] IETF Mailing List. January 2000 E-mail Discus- sion Thread. IETF Organization, January 2000. See the mailing list section of http://www.ietf.org. [8] 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).. [9] Markku-Juhani Saarinen. Attacks Against The WAP WTLS Protocol. University of Jyvaskyla, 1999. Online document is available at http://www.jyu.fi/ mjos. [10] Mohsen Banan. Free Protocols Foundation Poli- cies 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. 28 [11] Mohsen Banan. LEAP: One Alternative to WAP. A component of LEAP Manifesto 108- 102-02, LEAP Forum, Bellevue, WA, Febru- ary 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-102- 02/index.html. [12] Mohsen Banan. Lightweight & Efficient Applica- tion Protocol (LEAP) Manifesto. Technical Re- port 108-101-01, LEAP Forum, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-101- 01/index.html. [13] Rohit Khare. W* Effect Considered Harmful. 4K Associates, April 1999. Online document is available at http://www.4K-Associates.com/4K- Associates/Library.html. [14] M. Taylor, J. Cheng, and M. Banan. AT&T/Neda's Efficient Short Remote Operations (ESRO) Proto- col Specification Version 1.2. Request for Com- ments (Informational) 2188, Neda Communica- tions, Inc., September 1997. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2188.txt. 29