Lessons from History: Comparitive Case Studies Mohsen Banan public@mohsen.banan.1.byname.net Version 0.2 First Published: August 4, 2000 Last Updated: July 7, 2000 Copyright fcl 2000 Mohsen Banan Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. A Component of The LEAP Manifesto This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the LEAP protocols. For the complete collection of articles see The LEAP Manifesto [1 ], available at http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free Proto- cols Foundation website at http://www.FreeProtocols.org/LEAP/Manifesto/roadMap/index.html. 1 Contents 1 Introduction 3 2 Characteristics of Successful Protocols 3 3 Case Study I: The World Wide Web 5 3.1 Prerequisites . . . . . . . . . . . . . . . . 6 3.2 Open Protocol Specifications . . . . . . . 6 3.3 Open Standards Organization . . . . . . . 7 3.4 Widespread Client Software . . . . . . . 7 3.5 Widespread Server Software . . . . . . . 7 3.6 Open-Source Software . . . . . . . . . . 8 3.7 Service Providers . . . . . . . . . . . . . 8 4 Case Study II: Pretty Good Privacy 8 List of Tables 1 Protocol Success Stories . . . . . . . . . 5 2 Web Industry vs. Mobile Messaging In- dustry . . . . . . . . . . . . . . . . . . . * * 6 2 1 Introduction In general, protocols can have widely differing degrees of industry tenure. Some protocols achieve widespread adoption and usage, and persist as long-term industry stan- dards. Others never achieve widespread acceptance, or else have very short lifetimes before becoming obsolete or being eclipsed by competing protocols. There is no definitive set of circumstances which will guarantee either the success or failure of any particular protocol. Protocols succeed or fail as a result of a number of technical, cultural and business factors, each of which has complex effects and unpredictable results. The tech- nical merits of the protocol play an important role; how- ever, technical superiority alone is no guarantee of suc- cess. The LEAP Manifesto is about a particular set of pro- tocols: the Lightweight & Efficient Application Proto- cols, or LEAP. These protocols have been designed to address a particular industry need: the need for a set of highly efficient communications protocols. They are in- tended to be the foundation of an entirely new industry: the Mobile Messaging industry. It is our hope and our intention that the protocols suc- ceed in this purpose. It is our hope that these protocols become enduring industry standards, that they play a key role in the growth of the Mobile Messaging industry, and that they bring long-lasting benefits to the industry and the consumer. Those factors which influence the success or failure of protocols are therefore of great interest to us. In this article, we identify and discuss those characteristics of protocols which contribute to their success or failure. In this regard we can learn a great deal from history. This article therefore also includes several case studies of suc- cessful and failed protocols. 2 Characteristics of Successful Pro- tocols Although there are no guarantees, history shows that suc- cessful protocols tend have certain characteristics in com- mon. 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. Some of the characteristics which improve a proto- 3 col's chances are: 1. Good Technical Design. The more a protocol sat- isfies the technical requirements of the industry, the better its chances. This means that the protocol must primarily be an engineering construct, not a business one. 2. Open Development and Maintenance Processes. It is preferable for the protocol to be developed and maintained by open processes. This means that mechanisms should exist for public commen- tary on the protocol, and the protocol maintenance process should allow the participation of all con- stituencies that are affected by the protocol. 3. Open Availability Process. The protocol should be published and made available in a way that en- sures that it is freely, easily and permanently acces- sible 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. Not all successful protocols have all these attributes. Nevertheless, the history of protocol development demon- strates that the more a protocol conforms to these attributes, the more likely it is to become an enduring industry stan- dard. The characteristics of various protocols are listed in Table 1. The protocols are arranged in groups, where each group represents a set of competing protocols. The table lists the major characteristics of each protocol, along with its ultimate success or failure. Note that there is only one eventual winner in each group. Note how certain characteristics correlate well with eventual protocol success - for example, in all cases the winning protocol was free of usage restrictions. Other characteristics do not appear to influence the eventual out- come - for example, endorsement by a standards organi- zation does not greatly increase a protocol's chances. In the remainder of this article we provide case stud- ies of several successful and failed protocols. 4 Table 1: Protocol Success Stories 3 Case Study I: The World Wide Web Perhaps the best known example of a network industry based on a set of open protocols is the World Wide Web. In this section we identify the key factors that contributed to the extraordinary success of the Web Industry. Our use of the LEAP protocols to catalyze the growth of the Mobile Messaging industry is to some extent mod- elled on the World Wide Web. We have identified many of the key factors that led to the success of the Web, and we have implemented those same factors in the case of the LEAP protocols and the Mobile Messaging industry. In many ways, we are attempting to reproduce the same circumstances in the Mobile Messaging industry that pre- vailed in the Web Industry, with the expectation that this will generate similar results. Throughout this case study, as we discuss each fac- tor that led to the success of the Web Industry, we will identify the parallel factor that we believe will lead to the success of the Mobile Messaging industry. The factors that made the Web successful are summa- rized in Table 2, along with the corresponding factors for the Mobile Messaging industry. 5 _ _ ___ ___ ___ _____ _____ _____ _____ ______ _______ ________ ________ ________ __________ __________ __________ ___________ ____________ _____________ _____________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ___________________ ________________________ We_____b Industry __* *___Mobile Messaging Industry _____ ______ _______Prerequisites_______________ _____Wired Networks, _____ * * Wireless-IP Networks, _____ _____________________ Mu_____ltimedia PCs, ... __* *___Palmtop PCs, ... _____ ____ _______Open_Standards___________ _____ HTTP/HTML published as _____ * * ESRO/EMSD published as _____ ___________________ RF_____C-1945 & RFC-1866 _____ * * RFC-2188 & RFC-2524 _____ _______Standards_Organization___________W3_Consortium__ _____ * * EMSD.org _____ __ _______Client_Software_______ _____Browsers on all platforms _____ * * User-Agent software for _____ _______________ fr_____eely available * * _____Windows CE etc. freely available _____ _______Server_Software____ _____Plug & Play, ____* *_ Plug & Play, _____ __________ Fr_____eely available * *_____Freely available, or reasonable licensing _____ __ _______Service_Providers _____ mosaic.com, etc. _____ * * ByName.net, etc. _____ ______ Open-Source _____Apache, Netscape _____ * * Ready for Open-Source _____ Table 2: Web Industry vs. Mobile Messaging Industry 3.1 Prerequisites The Web Industry required that certain technological pre- requisites be in place. These included such things as wired networks and multimedia PCs. The Web Industry could not come into widespread existence until these pre- requisites were in place. For this reason the Web could not have materialized any earlier than 1993. Similarly, the Mobile Messaging Industry has its own set of technological prerequisites. These include widespread and reliable wireless networks, affordable and miniatur- ized modems, and affordable and miniaturized mobile de- vices. All of these prerequisites did not become fully sat- isfied until 1999. Therefore the Mobile Messaging indus- try could not have materialized any earlier than 1999. 3.2 Open Protocol Specifications The Web protocols are open and are based on the HTTP and HTML specifications, initially published as Informa- tional RFC-1945 and RFC-1866 respectively. Likewise, our Mobile Messaging protocols are com- pletely open and are based on the ESRO and EMSD spec- ifications, published as Informational RFC-2188 and In- formational RFC-2524. Hypertext multi-media information retrieval systems based on proprietary protocols existed before the Web came about. Now that HTML is widespread these pro- prietary protocols are all considered irrelevant. Similary, many wireless e-mail and mobile messag- ing systems based on proprietary protocols exist today. We believe that they will likewise be considered irrele- 6 vant when LEAP becomes widespread. There is another interesting parallel between the Web and Mobile Messaging protocols. The IESG inserted a critical note into the HTTP RFC cited above. More re- cently, the IESG has done exactly the same thing to both Mobile Messaging RFCs cited above. We regard this in- clusion of critical notes into foreign (i.e. not originated by the IESG) RFCs to be a manifestation of the IESG's prejudice against external protocols - a frame of mind sometimes referred to as Non Invented Here syndrome. 3.3 Open Standards Organization The Web Industry had the W3 Consortium. The Mobile Messaging industry has ESRO.org and EMSD.org. 3.4 Widespread Client Software At an early stage in the evolution of the Web, client soft- ware was made widespread for all major platforms. Similarly, a key requirement for the development of the Mobile Messaging industry will be to ensure that im- plementations of the LEAP protocols are made available for all major handheld devices. Specifically, for: - PalmPilot - Windows CE - EPOC We have made our implementations of device (i.e. client side) software for Windows CE and Win-32 avail- able through Neda's website. 3.5 Widespread Server Software At an early stage in the evolution of the Web, server soft- ware was made widespread for most major platforms. Similarly, a key requirement for the development of the Mobile Messaging industry will be the ready avail- ability of LEAP server software for platforms such as the Sun Solaris and Windows NT. Our implementation of LEAP server software is read- ily available for the Sun Solaris platform now, and will become available for Windows NT shortly. 7 3.6 Open-Source Software The availability of open-source software is extremely im- portant for the creation of network industries. Reference implementations of Web protocols were made widespread at an early stage in the evolution of the Web Industry. Open-source software will play a similarly crucial role in the Mobile Messaging industry. Full implementations of published LEAP protocols will be made available as free software in open-source form. Our strategy is to release the software in stages as it becomes ready and available. The first piece to be released is our Open C Platform [2 ]. The next piece will be the ESRO proto- col engine, followed by the EMSD device-side protocol engine, followed by the Message Center EMSD proto- col engine. Further, we will integrate the LEAP protocol engines with various other free software. The distribution mechanism for the software will be through http://www.MailMeAnywhere.org. 3.7 Service Providers At an early stage in the evolution of the Web, its industry leaders actively participated in the creation of web-based information and services. In a sense they acted as early Service Providers. Similarly, it will be necessary to provide an initial set of Subscriber Services based on the LEAP protocols. To satisfy this need we are hosting a number of LEAP-based subscriber services. 4 Case Study II: Pretty Good Pri- vacy The history of the PGP (Pretty Good Privacy) data en- cryption system provides an excellent example of the suc- cess of a protocol developed entirely outside the tradi- tional Standards Organization processes. PGP was es- sentially the creation of a single man: Phil Zimmermann. Armed with a vision and a belief in its value, Zimmer- mann single-handedly made PGP the dominant consumer encryption application - displacing the IETF alternatives in the process. PGP is a protocol for electronic data encryption, which at the time of its development and deployment was in di- rect competition with S/MIME, a protocol being devel- oped for the same purpose by the IETF. The key differ- 8 ences between PGP and S/MIME are summarized in Ta- ble ?? . One of the major advantages that PGP enjoyed was being the creation of a single person. Small groups have an inherent advantage over large ones in any coopera- tive venture; as the size of a group grows, the difficulties of communication and coordination become increasingly challenging. Phil Zimmermann took this advantage to the limit: as a one-man operation, he enjoyed maximum effi- ciences of communication and coordination. This is to be contrasted with S/MIME, which was de- veloped by the IETF using classical Standards Organi- zation processes. Under these processes, protocols are developed by committees, in the form of IETF Working Groups. Though this is a very reasonable way to conduct cooperative effort, it inevitably suffers from the friction associated with group action: communication overhead, time required to resolve misunderstandings or disagree- ments, and so on. Phil Zimmermann enjoyed an agility and an efficiency of action that the IETF process could not possibly match. Both PGP and S/MIME were open protocols, without any usage restrictions, and so neither protocol had any advantage in terms of openness. Both protocols were also eventually published as RFCs. However, it is interesting to note that S/MIME, enjoying its privilege as an in-house IETF protocol, sailed through an early RFC publication process. PGP, on the other hand, was not published as an RFC until much later, when it had become clear that PGP had achieved widespread acceptance. A further significant difference between PGP and S/MIME was the extent to which the two protocols were imple- mented in the form of open-source software. Both pro- tocols were implemented as open-source; however PGP had much wider open-source support than S/MIME. This undoubtedly contributed significantly to the success of PGP, and this attests to the power of open-source in en- couraging protocol acceptance. S/MIME was developed and endorsed by the IETF, a formal Standards Organization. PGP enjoyed no such en- dorsement, and was developed entirely independently of any formal standards body. In spite of this, PGP has now become the de facto world-wide standard for electronic data encryption. PGP is certainly not an isolated case. HTTP, the pro- tocol which forms the basis of world-wide Internet com- munications, was also developed and achieved prominence independently of any formal standards body. These and 9 many other protocols have become industry standards de- spite their lack of official endorsement. The conclusions that we can draw from the history of PGP and other protocols are that standards organizations do not have an exclusive monopoly on creativity and in- novation, and that official endorsement is not a prerequi- site for protocol success. The case of PGP and many other protocols supports our view that in general, innovation comes from small groups or individuals with vision, and not from commit- tees, working groups, and Standards Organizations. Phil Zimmermann has been an inspiration to every in- dividual or small group with an idea they believe in, but who find themselves at odds with an entrenched Stan- dards Organization. We believe the history of LEAP will provide similar inspiration. References [1] 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. [2] Neda Public Document. Open C Platform. Neda Published Document 103-103-01, Neda Communications Inc, Bellevue, WA, Octo- ber 1996. Online document is available at http://www.public.neda.com/pubs/biblio/103- 103-01/index.html. 10