The Lightweight & Efficient Application Protocols (LEAP) Manifesto Using Free Protocols & Free Software to build the Mobile & Wireless Applications Industry Mohsen Banan public@mohsen.banan.1.byname.net Version 1.2 March 1, 2001 This document describes the Lightweight & Efficient Application Protocols (LEAP), a set of protocols for mo- bile and wireless applications. Copyright fcl 2000-2001 Mohsen Banan Verbatim Copying Permitted. 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. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for verbatim copying, except that this permission notice must be stated in a translation approved by the Copyright holder. Trademark Information IBM and PC are trademarks of International Business Machines Corporati* *on. Palm is a registered trademark of Palm, Inc. SUN is a registered trademark of Sun Microsystems. Windows is a registered trademark of Microsoft Corporation. Windows CE is a registered trademark of Microsoft Corporation. RIM, Research In Motion, and BlackBerry are trademarks of Research In Motion Limited. All other brands, product names and company names mentioned in this article may be trademarks or registered trademarks of their respective holders. Contents 1 Executive Summary 1 1.1 Technological Scope . . . . . . . . . . . 2 1.2 Efficiency is the Key Requirement . . . . 3 1.3 Conventional Origins of Protocols . . . . 4 1.4 Expect the Unexpected . . . . . . . . . . 5 1.5 Our Solution . . . . . . . . . . . . . . . . 5 1.6 A Brief History of LEAP . . . . . . . . . 7 1.7 Making Our Solution Widespread . . . . 8 1.8 Complete and Ready . . . . . . . . . . . 9 1.9 How to Participate . . . . . . . . . . . . 9 1.10 Who We Are . . . . . . . . . . . . . . . 10 1.11 About The LEAP Manifesto . . . . . . . 12 1.11.1 Manifesto Organization . . . . . 13 1.11.2 Draft Articles . . . . . . . . . . . 17 1.11.3 Getting the Manifesto . . . . . . 17 I The LEAP Protocols 19 2 Overview of the LEAP Protocols 21 2.1 Introduction . . . . . . . . . . . . . . . . 21 2.2 The Need for Efficiency . . . . . . . . . . 21 2.3 Technical Overview of LEAP . . . . . . . 22 2.3.1 The ESRO Layer: Efficient Trans- port Services . . . . . . . . . . . 23 2.3.2 The EMSD Layer: Efficient E-Mail 24 2.3.3 The EHTD Layer: Efficient Web Browsing . . . . . . . . . . . . . 25 2.3.4 Other Efficient LEAP Applications 25 i ii CONTENTS 2.4 Efficiency Characteristics of LEAP . . . . 25 2.5 LEAP: A Basis for Convergence . . . . . 27 2.6 The End-User's Experience . . . . . . . . 28 2.7 The LEAP Development Process . . . . . 31 2.7.1 Patent-Freedom . . . . . . . . . . 31 2.7.2 RFC Publication . . . . . . . . . 32 2.7.3 Open Maintenance Organizations 32 2.8 LEAPing over WAP . . . . . . . . . . . . 32 2.9 A Brief History of LEAP . . . . . . . . . 33 3 The LEAP Protocol Development Model 35 3.1 Introduction . . . . . . . . . . . . . . . . 35 3.2 Protocol Phases of Development . . . . . 36 3.2.1 Initial Protocol Development . . . 37 3.2.2 Global Parameter Assignment . . 38 3.2.3 Protocol Publication . . . . . . . 38 3.2.4 Patent-Freedom . . . . . . . . . . 39 3.2.5 Maintenance and Enhancement . 42 3.2.6 Endorsement by a Standards Body 44 3.3 Economic Consequences of Protocols . . 44 3.3.1 Principles for Maintaining Proto- col Integrity . . . . . . . . . . . . 45 3.4 Standards Organizations: Do They Mean Anything? . . . . . . . . . . . . . . . . . 46 3.5 Our Independence of the IETF . . . . . . 48 3.5.1 Do We Need the IETF? . . . . . . 49 4 Free Protocols Foundation Policies and Proce- dures 51 4.1 Introduction . . . . . . . . . . . . . . . 51 4.1.1 The Patent Debate . . . . . . . . 51 4.1.2 How Patents Affect Protocols . . 51 4.1.3 Difficulties Relating to Software and Protocol Patents . . . . . . . 52 4.1.4 Terminology . . . . . . . . . . . 53 4.1.5 About the Free Protocol Processes and Procedures . . . . . . . . . . 54 4.1.6 About this Document . . . . . . 55 CONTENTS iii 4.2 The Protocol Development Process . . . 56 4.2.1 Phases of Development . . . . . 56 4.2.2 Role of the Free Protocols Foun- dation . . . . . . . . . . . . . . * * 60 4.2.3 Coordination of Activities . . . . 62 4.3 The Free Protocols Foundation . . . . . 63 4.3.1 General Philosophy . . . . . . . 63 4.3.2 Purpose, Activities and Scope . . 63 4.3.3 Other Activities . . . . . . . . . 64 4.4 Free Protocol Development Working Groups . . . . . . . . . . . . . . . . . . . . .* * . 65 4.5 Patent-Free Declarations . . . . . . . . . 66 4.5.1 Author's Declaration . . . . . . 66 4.5.2 Working Group Declaration . . . 67 4.6 Patents, Copyright and Confidentiality - Policy Statement . . . . . . . . . . . . . 67 4.6.1 Policy Statement Principles . . . 67 4.6.2 General Policy . . . . . . . . . . 68 4.6.3 Confidentiality Obligations . . . . 68 4.6.4 Rights and Permissions of All Con- tributions . . . . . . . . . . . . . * *69 4.6.5 FPF Role Regarding Free Proto- col Specifications . . . . . . . . . 70 5 ESRO: A Foundation for the Development of Efficient Protocols 71 5.1 Overview of ESRO . . . . . . . . . . . . 71 5.1.1 The Need for ESRO . . . . . . . 71 5.1.2 ESRO Requirements and Goals . 72 5.1.3 Terminology . . . . . . . . . . . 73 5.2 Other Related Protocols . . . . . . . . . . 73 5.2.1 RPC . . . . . . . . . . . . . . . . * * 73 5.2.2 ROSE . . . . . . . . . . . . . . . 74 5.2.3 WAP's WTP . . . . . . . . . . . 74 5.2.4 T/TCP . . . . . . . . . . . . . . . 74 5.2.5 RDP . . . . . . . . . . . . . . . . * *75 5.2.6 VMTP . . . . . . . . . . . . . . 75 5.2.7 TCP . . . . . . . . . . . . . . . . * * 75 iv CONTENTS 5.2.8 UDP . . . . . . . . . . . . . . . * *76 5.2.9 UDP Plus Ad Hoc Re-Transmissions 76 5.3 The ESRO Protocol . . . . . . . . . . . . 76 5.3.1 Efficiency Characteristics of ESRO 77 5.3.2 Why We Adopted the Remote Op- erations Model . . . . . . . . . . 77 5.3.3 RFC Publication of the ESRO Pro- tocol . . . . . . . . . . . . . . . * * 78 5.3.4 Maintenance of the ESRO Proto- col via ESRO.org . . . . . . . . . 78 5.4 Use of ESRO . . . . . . . . . . . . . . . 79 5.4.1 Common ESRO Application De- sign Considerations . . . . . . . . 79 5.5 Example Applications . . . . . . . . . . . 82 5.5.1 Horizontal Applications . . . . . 83 5.5.2 EMSD: Efficient E-Mail . . . . . 83 5.5.3 EHTD: Efficient Web Browsing . 83 5.5.4 Other Efficient Horizontal Appli- cations . . . . . . . . . . . . . . * * 84 5.5.5 Vertical Applications . . . . . . . 84 5.6 Existing Implementations of ESRO . . . . 84 5.6.1 ESROS Application Programming Interface . . . . . . . . . . . . . * *86 6 EMSD: The LEAP E-Mail Component 87 6.1 Introduction . . . . . . . . . . . . . . . . 87 6.1.1 Terminology . . . . . . . . . . . 88 6.2 Existing Internet Mail Submission and De- livery . . . . . . . . . . . . . . . . . . .* * 88 6.3 Overview of EMSD . . . . . . . . . . . . 89 6.3.1 Protocol Layering . . . . . . . . . 89 6.3.2 EMSD Protocol Components . . . 89 6.3.3 Efficient Short Remote Operations (ESRO) . . . . . . . . . . . . . . 92 6.3.4 Anticipated Uses of EMSD . . . . 92 6.4 EMSD Design Goals and Requirements . 93 6.5 Rationale for Key Design Decisions . . . 95 6.5.1 Deviation from the SMTP Model 95 6.5.2 Use of ESRO Instead of TCP . . . 96 CONTENTS v 6.5.3 Use of the Remote Procedure Call (RPC) Model . . . . . . . . . . . 97 6.5.4 Use of ASN.1 . . . . . . . . . . . 97 6.6 Relationship of EMSD to Other Mail Pro- tocols . . . . . . . . . . . . . . . . . . . * * 98 6.7 Obtaining the EMSD Protocols . . . . . . 99 7 Efficiency of EMSD 101 7.1 Introduction . . . . . . . . . . . . . . . . 101 7.1.1 Efficient Mail Submission & De- livery . . . . . . . . . . . . . . . * *102 7.2 Study Overview . . . . . . . . . . . . . . 103 7.3 Submission . . . . . . . . . . . . . . . . 104 7.3.1 SMTP Submission from PC to Unix104 7.3.2 EMSD Submission from PC to Unix106 7.4 Delivery . . . . . . . . . . . . . . . . . . 1* *08 7.4.1 SMTP Delivery from Unix to Unix . . . . . . . . . . . . . . . . . * *. 108 7.4.2 Message Delivery via POP Mailbox109 7.4.3 Message Delivery via IMAP Mail- box . . . . . . . . . . . . . . . . * *112 7.4.4 EMSD Delivery from Unix to PC 114 7.5 Results Summary . . . . . . . . . . . . . 115 7.6 Conclusion . . . . . . . . . . . . . . . . 116 7.7 Acknowledgments . . . . . . . . . . . . 117 8 A Brief History of LEAP 119 8.1 Overview . . . . . . . . . . . . . . . . . 119 8.2 Time-Line History . . . . . . . . . . . . 120 8.3 Acronym Apology . . . . . . . . . . . . 122 9 The Future of LEAP 125 9.1 Where We Are Today . . . . . . . . . . . 125 9.2 Invitations to Participate . . . . . . . . . 126 9.3 Preview of Coming Attractions . . . . . . 127 9.3.1 MailMeAnywhere.org . . . . . . 127 9.3.2 ByName.net and ByNumber.net . 128 vi CONTENTS II LEAPing Over Closed Solutions 131 10 The WAP Trap 133 10.1 Introduction . . . . . . . . . . . . . . . 133 10.1.1 The Wireless Application Proto- col (WAP) . . . . . . . . . . . . 133 10.1.2 Characteristics of Successful Pro- tocols . . . . . . . . . . . . . . . * *134 10.1.3 About this Document . . . . . . 135 10.2 WAP - A Procedural Fraud . . . . . . . 137 10.2.1 Not Open in Terms of Develop- ment and Maintenance . . . . . . 138 10.2.2 No Assurance of Availability and Stability . . . . . . . . . . . . . 139 10.2.3 Not Patent-Free . . . . . . . . . 141 10.2.4 No Legitimacy as a Standard . . 143 10.3 WAP - A Technical Failure . . . . . . . 144 10.3.1 User Interface Assumptions . . . 144 10.3.2 Extreme Accommodation to Ex- isting Networks . . . . . . . . . 145 10.3.3 Excessive Re-Invention in the Name of Wireless . . . . . . . . . . . . 146 10.3.4 Vulnerable Wireless Transport Layer Security (WTLS) . . . . . . . . . 147 10.3.5 Bungled Protocol Number As- signment . . . . . . . . . . . . . 148 10.4 WAP - A Basic Misconception . . . . . 148 10.4.1 The Wrong Answer Initially: Mo- bile Web Browsing . . . . . . . . 149 10.4.2 The Right Answer Initially: Mo- bile Messaging . . . . . . . . . . 151 10.4.3 Unsupported Claims . . . . . . 151 10.5 Conclusion: WAP is a Trap . . . . . . . 154 10.6 Preventing the Harm of WAP . . . . . . 155 10.6.1 Reform the WAP Forum . . . . 156 10.6.2 Spread the Word about the WAP Fraud . . . . . . . . . . . . . . . 1* *56 10.6.3 Reject WAP at Engineering Level . . . . . . . . . . . . . . . . . * *. 156 10.6.4 Reject WAP at Consumer Level . 157 CONTENTS vii 10.6.5 Adopt an Alternative to WAP . . 157 10.7 LEAP: One Alternative To WAP . . . . 158 11 LEAP: One Alternative to WAP 161 11.1 Introduction . . . . . . . . . . . . . . . 161 11.1.1 The WAP Trap . . . . . . . . . 161 11.1.2 About this Document . . . . . . 162 11.2 The Need for Efficiency . . . . . . . . . . 163 11.3 LEAP: The Lightweight & Efficient Ap- plication Protocols . . . . . . . . . . . . 165 11.3.1 A Brief History of LEAP . . . . 165 11.3.2 Technical Overview of LEAP . . 166 11.3.3 Processes and Procedures . . . . 167 11.4 Comparison of LEAP to WAP . . . . . . 169 11.4.1 Patent Restrictions . . . . . . . 169 11.4.2 Openness of Publication . . . . 169 11.4.3 Openness of Maintenance . . . . 170 11.4.4 Technical Deficiencies . . . . . 170 11.4.5 Initial Focus . . . . . . . . . . . 170 11.4.6 Hype versus Reality . . . . . . . 171 11.5 Making LEAP Widespread . . . . . . . 172 11.6 Other Alternatives to WAP . . . . . . . 173 11.7 Summary . . . . . . . . . . . . . . . . . 174 11.7.1 The LEAP Manifesto . . . . . . . 175 12 WAP Scraps 177 12.1 Introduction . . . . . . . . . . . . . . . . 177 12.1.1 Claiming the Day . . . . . . . . . 177 12.1.2 Mobile Web Browsing: An Open Industry Model . . . . . . . . . . 178 12.1.3 About this Document . . . . . . . 179 12.2 Mobile Web Browsing: Past, Present and Future . . . . . . . . . . . . . . . . . . . * *181 12.2.1 The Past: WAP . . . . . . . . . . 181 12.2.2 The Present: XHTML . . . . . . 182 12.2.3 The Importance of Efficiency . . 183 12.2.4 The Future: XHTML + LEAP . . 184 12.2.5 Invitation to Participate . . . . . . 186 viii CONTENTS 12.3 WAP: A Salvage Operation . . . . . . . . 186 12.3.1 Engineering Salvage: Scrapping WAP Layer by Layer . . . . . . . 187 12.3.2 Business Salvage: Cutting Finan- cial Losses . . . . . . . . . . . . 189 12.3.3 Psychological Salvage: Saving Face189 12.4 In Pursuit of Integrity . . . . . . . . . . . 190 12.4.1 The WAP Hype Machine Fraud . 190 12.4.2 Protocol Integrity . . . . . . . . . 192 12.4.3 Engineering Integrity . . . . . . . 194 13 Operation Whiteberry 195 13.1 Introduction . . . . . . . . . . . . . . . . 195 13.1.1 The Problem . . . . . . . . . . . 196 13.1.2 The Solution . . . . . . . . . . . 197 13.1.3 Free Protocols Foundation Endorse- ment of Operation WhiteBerry . . 199 13.2 Mobile Messaging Requirements . . . . . 200 13.3 The BlackBerry Solution . . . . . . . . . 202 13.3.1 How BlackBerry Works . . . . . 202 13.3.2 BlackBerry: Mobile Messaging Confirmation . . . . . . . . . . . 205 13.3.3 BlackBerry: A Closed Solution . 206 13.3.4 BlackBerry: Not All Things to All People . . . . . . . . . . . . 208 13.3.5 Strategic Myopia: More Closed Solutions . . . . . . . . . . . . . 209 13.4 The WhiteBerry Solution . . . . . . . . . 210 13.4.1 Technological Components of White- Berry . . . . . . . . . . . . . . . 2* *11 13.4.2 The Unifying Component: A Set of Open Protocols . . . . . . . . 212 13.4.3 The Key to WhiteBerry: The LEAP Protocols . . . . . . . . . . . . . 213 13.4.4 How WhiteBerry Works . . . . . 214 13.4.5 Putting Everything Together for the End User . . . . . . . . . . . 217 13.4.6 Technical Challenges & Responses 219 13.4.7 WhiteBerry versus BlackBerry . . 221 CONTENTS ix 13.5 Initial Development Framework . . . . . 223 13.5.1 Open-Source Software Implemen- tations . . . . . . . . . . . . . . . * *223 13.5.2 The MailMeAnywhere Develop- ment Forum . . . . . . . . . . . . 224 13.5.3 Initial Subscriber Services . . . . 225 13.5.4 Initial WhiteBerry Implementation 225 13.6 Mobile Messaging Security . . . . . . . . 227 13.6.1 BlackBerry Security . . . . . . . 227 13.6.2 WhiteBerry Security . . . . . . . 228 13.7 The Business Case for WhiteBerry . . . . 229 13.7.1 Immediate Opportunity: Installed Hardware Base . . . . . . . . . . 230 13.7.2 Precedents for Success . . . . . . 231 13.7.3 Shifting Opportunities: Winners & Losers . . . . . . . . . . . . . 232 13.7.4 Business Conservativism . . . . . 233 13.8 A Framework for Participation . . . . . . 234 13.8.1 Device Integration . . . . . . . . 235 13.8.2 Modem Integration . . . . . . . . 238 13.8.3 Network Services Integration . . 240 13.8.4 Systems and Solutions Integration 243 13.8.5 How to Participate . . . . . . . . 244 13.9 Beyond Operation WhiteBerry . . . . . . 246 13.10 Summary . . . . . . . . . . . . . . . . . 248 III Making LEAP Widespread 251 14 Strategy for Making LEAP Widespread 253 14.1 Introduction . . . . . . . . . . . . . . . . 253 14.2 The Power of Free Software . . . . . . . 254 14.2.1 Irrelevance of the Supply Chain Model . . . . . . . . . . . . . . . 255 14.2.2 Bypassing the Telecommunications Gatekeepers . . . . . . . . . . . . 257 14.3 How LEAP Will Become Widespread . . 257 14.4 NEDA's Free Software Base . . . . . . . 258 14.5 Neda's Free Software Licensing Strategy . 261 x CONTENTS 15 EMSD on Windows CE 263 15.1 Summary . . . . . . . . . . . . . . . . . 263 15.2 About This Document . . . . . . . . . . . 264 15.3 Background . . . . . . . . . . . . . . . . 264 15.3.1 Components involved . . . . . . . 264 15.4 CDPD, EMSD and Windows CE: High Level Architecture . . . . . . . . . . . . 267 15.4.1 EMSD and WinCE Messaging . . 267 15.4.2 WinCE and CDPD Modem inte- gration . . . . . . . . . . . . . . 2* *68 15.4.3 EMSD Message Transfer Service and Back End Mailbox Issues . . 269 15.5 Windows CE Inbox integration with EMSD270 15.6 End User Experience . . . . . . . . . . . 270 15.6.1 Assumptions . . . . . . . . . . . 270 15.6.2 Acquisition . . . . . . . . . . . . 270 15.6.3 Installation . . . . . . . . . . . . 270 15.7 Conclusions . . . . . . . . . . . . . . . . 271 16 EMSD on Palm OS 273 16.1 Introduction . . . . . . . . . . . . . . . . 273 16.1.1 Palm OS Integration Strategy . . 274 16.2 Palm OS Mail User Agents . . . . . . . . 275 16.2.1 Separate Mail User Interface and Mail Transport Service . . . . . . 275 16.2.2 Integrated Mail User Interface and Mail Transport Service . . . . . . 276 16.3 Invitation To Participate . . . . . . . . . . 278 17 Trying out LEAP 279 18 WhiteBerry and Bluetooth 281 18.1 Introduction . . . . . . . . . . . . . . . . 281 18.1.1 Bluetooth vs. fBluetoothg . . . . 282 18.1.2 Industry Characteristics and Trends283 18.2 What is WhiteBerry? . . . . . . . . . . . 285 18.3 The WhiteBerry/fBluetoothg Messaging Solution . . . . . . . . . . . . . . . . . . 2* *86 CONTENTS xi 18.3.1 Basic WhiteBerry/fBluetoothg Im- plementation Architecture . . . . 287 18.3.2 A Word About SMS . . . . . . . 290 18.4 Mail Notification . . . . . . . . . . . . . 290 18.5 Mail Notification in the WhiteBerry/fBluetoothg Model . . . . . . . . . . . . . . . . . . . 2* *92 18.6 Development Framework and Resources . 294 18.6.1 Development Support from Neda Communications, Inc. . . . . . . 295 18.6.2 Invitation to Cell Phone Manu- facturers . . . . . . . . . . . . . . 295 18.6.3 Open-Source Software Licensing 296 19 Use of EMSD for Mail Notification 297 19.1 Introduction . . . . . . . . . . . . . . . . 297 19.1.1 Intended Audience . . . . . . . . 297 19.2 The EMSD Protocol . . . . . . . . . . . 298 19.3 Mail Notification . . . . . . . . . . . . . 298 19.3.1 Mail Notification Implementation Model . . . . . . . . . . . . . . . 299 19.3.2 Mail Notification in Mobile En- vironments . . . . . . . . . . . . 301 19.4 Development Framework and Resources . 303 19.4.1 Open-Source Software Availability 304 20 Lessons From History: Comparitive Case Stud- ies 305 20.1 Introduction . . . . . . . . . . . . . . . . 305 20.2 Characteristics of Successful Protocols . . 306 20.3 Case Study I: The World Wide Web . . . 308 20.3.1 Prerequisites . . . . . . . . . . . 308 20.3.2 Open Protocol Specifications . . . 309 20.3.3 Open Standards Organization . . 309 20.3.4 Widespread Client Software . . . 309 20.3.5 Widespread Server Software . . . 310 20.3.6 Open-Source Software . . . . . . 310 20.3.7 Service Providers . . . . . . . . . 311 20.4 Case Study II: Pretty Good Privacy . . . . 311 xii CONTENTS IV The Mobile Messaging Industry 313 21 The Mobile Messaging Industry 315 21.1 Introduction . . . . . . . . . . . . . . . . 315 21.2 The Next Big Thing: Mobile Messaging . 315 21.2.1 The Mobile Messaging End-User 316 21.3 Comparison to Paging . . . . . . . . . . . 317 21.4 Timeliness of Mobile Messaging . . . . . 317 21.5 Market Forecasts . . . . . . . . . . . . . 318 21.6 Current Status of the Mobile Messaging Industry . . . . . . . . . . . . . . . . . . * *321 21.7 Differences among Mobile Messaging Providers321 21.8 The Fundamental Obstacle: Lack of Inter- Operability . . . . . . . . . . . . . . . . 322 21.9 The Key Enabling Requirement: A Stan- dard Protocol . . . . . . . . . . . . . . . 323 21.10 Protocol Requirements . . . . . . . . . . 323 V APPENDIX 327 A General Information 329 A.1 Device Options for the Mobile Professional329 A.1.1 Device Options for Cell Phones and PDAs: Integrated vs. Specialist329 A.1.2 Device Options for Mobile Mes- saging . . . . . . . . . . . . . . . 3* *31 A.1.3 Mobile Messaging via PDA: One Major Disadvantage . . . . . . . 333 A.1.4 Summary: Cell Phone/PDA Inte- gration a Viable Option . . . . . . 333 B RFC-2188 335 B.1 INTRODUCTION . . . . . . . . . . . . 337 B.1.1 Relationship To Existing Remote Operation Services . . . . . . . . 337 B.1.2 Overview of ESROS . . . . . . . 338 B.1.3 The Remote Operation Model . . 338 B.2 ESRO SERVICE DEFINITIONS . . . . . 339 B.2.1 Acknowledged Result Service Mode342 CONTENTS xiii B.2.2 Non-acknowledged Result . . . . 343 B.2.3 Serialized Use of ESRO Services 344 B.2.4 ESROS-INVOKE Service . . . . 344 B.2.5 ESROS-RESULT Service . . . . 347 B.2.6 ESROS-ERROR Service . . . . . 349 B.2.7 ESROS-FAILURE Service . . . . 352 B.3 ESRO SERVICE NOTATION . . . . . . 353 B.3.1 ES-OPERATION Notation . . . . 353 B.3.2 Mapping of ESROS Notation . . 354 B.4 REMOTE OPERATIONS PROTOCOL . 355 B.4.1 Overview of the Protocol . . . . . 355 B.4.2 Protocol Procedures . . . . . . . 357 B.4.3 Connectionless PDU Transfer For Small PDUs . . . . . . . . . . . . 358 B.4.4 Structure and Encoding of ESROS PDUs . . . . . . . . . . . . . . . 374 B.4.5 Concatenation and Separation . . 382 B.4.6 ES Remote Operations Protocol Parameters . . . . . . . . . . . . 385 B.5 ACKNOWLEDGMENTS . . . . . . . . 386 B.6 SECURITY CONSIDERATIONS . . . . 386 B.7 AUTHORS' ADDRESSES . . . . . . . . 386 C RFC-2524 389 C.1 PRELIMINARIES . . . . . . . . . . . 392 C.1.1 Internet Mail Submission and De- livery . . . . . . . . . . . . . . . * *392 C.1.2 Relationship Of EMSD To Other Mail Protocols . . . . . . . . . . 393 C.1.3 EMSD Requirements and Goals . 394 C.1.4 Anticipated Uses Of EMSD . . . 395 C.1.5 Definitions of Terms Used in this Specification . . . . . . . . . . . 396 C.1.6 Conventions Used In This Speci- fication . . . . . . . . . . . . . . 3* *97 C.1.7 About This Specification . . . . . 397 C.2 EFFICIENT MAIL SUBMISSION AND DELIVERY OVERVIEW . . . . . . . . . 397 xiv CONTENTS C.3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL . . . . . . . . . 400 C.3.1 Use Of Lower Layers . . . . . . . 401 C.3.2 EMSD-UA Invoked Operations . 402 C.3.3 EMSD-SA Invoked Operations . . 410 C.3.4 EMSD Common Information Ob- jects . . . . . . . . . . . . . . . . * * 417 C.3.5 Submission and Delivery Proce- dures . . . . . . . . . . . . . . . 4* *24 C.4 DUPLICATE OPERATION DETECTION SUPPORT . . . . . . . . . . . . . . . . . 426 C.4.1 Duplicate Operation Detection Sup- port Overview . . . . . . . . . . 426 C.5 EMSD PROCEDURE FOR OPERATIONS429 C.5.1 MTS Behavior . . . . . . . . . . 430 C.5.2 UA Behavior . . . . . . . . . . . 436 C.6 EMSD FORMAT STANDARDS . . . . . 440 C.6.1 Format Standard Overview . . . . 440 C.6.2 Interpersonal Messages . . . . . . 441 C.7 ACKNOWLEDGMENTS . . . . . . . . 448 C.8 SECURITY CONSIDERATIONS . . . . 448 C.9 AUTHOR'S ADDRESS . . . . . . . . . 448 .1 EMSD-P ASN.1 MODULE . . . . . . . . 449 .2 EMSD-IPM ASN.1 MODULE . . . . . . 459 .3 RATIONALE FOR KEY DESIGN DE- CISIONS . . . . . . . . . . . . . . . . . 463 .3.1 Deviation From The SMTP Model 463 .3.2 Use of ESRO Instead of TCP . . . 464 .3.3 Use Of Remote Procedure Call (RPC) Model . . . . . . . . . . . . . . . 465 .3.4 Use Of ASN.1 . . . . . . . . . . 465 .4 FURTHER DEVELOPMENT . . . . . . 465 A Glossary of Terms 467 Index 485 List of Figures 2.1 LEAP Protocol Organization . . . . . . . 23 2.2 Protocol Efficiency Comparison . . . . . 26 2.3 Open Mobile Messaging . . . . . . . . . 28 2.4 The End-User's Experience . . . . . . . . 29 5.1 Anatomy of a Vertical Wireless Application 85 6.1 LEAP Protocol Stack . . . . . . . . . . . 90 6.2 Efficient Mail Submission and Delivery Protocol . . . . . . . . . . . . . . . . . . * * 91 6.3 EMSD World and Global Messaging World 95 6.4 Messaging Communication Stack and EMSD 98 7.1 Experimental Setup for Submission . . . 105 7.2 Experimental Setup for Delivery . . . . . 110 7.3 Packets Per Delivery . . . . . . . . . . . 116 11.1 Wireless Internet Hype vs. Reality . . . . 171 12.1 Mobile Web Browsing: Past, Present and Future . . . . . . . . . . . . . . . . . . . * *183 12.2 WAP Architecture . . . . . . . . . . . . . 187 13.1 The BlackBerry Solution . . . . . . . . . 204 13.2 The WhiteBerry Solution . . . . . . . . . 215 13.3 WhiteBerry Components . . . . . . . . . 218 14.1 Traditional Supply Chain Model . . . . . 256 14.2 Neda Software Architecture . . . . . . . 259 15.1 Components of WCE Mail Transport Ser- vice Provider with EMSD . . . . . . . . . 268 xv xvi LIST OF FIGURES 16.1 Example Of Separate Mail Transfer Ser- vice for Palm OS . . . . . . . . . . . . . 276 16.2 Example Of Combined Mail Transfer Ser- vice for Palm OS . . . . . . . . . . . . . 277 18.1 The WhiteBerry/fBluetoothg Solution . . 287 18.2 Basic Implementation Architecture . . . . 288 18.3 General Mail Notification Model . . . . . 291 18.4 Mail Notification in the WhiteBerry/fBluetoothg Model . . . . . . . . . . . . . . . . . . . 2* *93 19.1 Mail Notification Model . . . . . . . . . 300 21.1 Wireless Mobile Data Subscribers . . . . 319 21.2 Global Wireless Internet Revenues . . . . 320 21.3 Existing Mobile Messaging Systems . . . 323 21.4 Open Mobile Messaging . . . . . . . . . 325 B.1 ES Remote Operation Model . . . . . . . 339 B.2 Time sequence diagram for ESRO services 340 B.3 Time sequence diagram for ESROS-INVOKE service . . . . . . . . . . . . . . . . . . . * * 345 B.4 Time sequence diagram for ESROS-RESULT service . . . . . . . . . . . . . . . . . . . * * 348 B.5 Time sequence diagram for ESROS-ERROR service . . . . . . . . . . . . . . . . . . . * * 350 B.6 Time sequence diagram for ESROS-FAILURE service . . . . . . . . . . . . . . . . . . . * * 352 B.7 ES Remote Operation Notation . . . . . . 354 C.1 Messaging Protocols vs. Supported Func- tions . . . . . . . . . . . . . . . . . . . .* * 393 C.2 Efficient Mail Submission and Delivery Protocol . . . . . . . . . . . . . . . . . . 3* *99 List of Tables 2.1 WAP versus LEAP . . . . . . . . . . . . 33 6.1 Comparison of EMSD to Other Protocols 96 6.2 Messaging Protocol Functionality . . . . 99 7.1 Messaging Protocols . . . . . . . . . . . 104 7.2 Comparison of Submission Traffic over- head for EMSD and SMTP . . . . . . . . 115 7.3 Comparison of Delivery Traffic Overhead for EMSD, SMTP, IMAP and POP . . . 115 11.1 WAP versus LEAP . . . . . . . . . . . . 169 13.1 BlackBerry vs. WhiteBerry . . . . . . . . 222 13.2 A WhiteBerry Case Study Implementa- tion: Lisa Simpson . . . . . . . . . . . . 226 15.1 Messaging Protocols vs. Supported Func- tions . . . . . . . . . . . . . . . . . . . .* * 266 20.1 Protocol Success Stories . . . . . . . . . 307 20.2 Web Industry vs. Mobile Messaging In- dustry . . . . . . . . . . . . . . . . . . . * * 308 21.1 Mobile Messaging End-Users . . . . . . . 316 21.2 Mobile Messaging vs. Traditional Paging 317 B.1 ESRO Services . . . . . . . . . . . . . . 340 B.2 ESRO service primitives and associated parameters . . . . . . . . . . . . . . . . . 341 B.3 Success and Failure in Acknowledged Re- sult Mode . . . . . . . . . . . . . . . . . 342 xvii xviii LIST OF TABLES B.4 Success and Failure in Non-acknowledged Result Mode . . . . . . . . . . . . . . . 343 B.5 ESROS-INVOKE service primitives and associated parameters . . . . . . . . . . 345 B.6 ESROS-RESULT service primitives and associated parameters . . . . . . . . . . 348 B.7 ESROS-ERROR service primitives and as- sociated parameters . . . . . . . . . . . . 350 B.8 ESROS-FAILURE service primitives and associated parameters . . . . . . . . . . 352 B.9 Encoding of Failure-value . . . . . . . . 353 B.10 ESROS Finite State Machine . . . . . . . 359 B.11 ESROS State Transition Diagram-Connectionless Transmission, 3-Way HS. P = Protocol, T = Timer, U = User, I = Internal. . . . . . 361 B.12 ESROS State Transition Diagram-Connectionless Transmission, 3-Way HS: Performer. P = Protocol, T = Timer, U = User, I = Inter- nal. . . . . . . . . . . . . . . . . . . . * *. 364 B.13 ESROS State Transition Diagram-Connectionless Transmission, 2-Way HS: Invoker p = Pro- tocol, T = Timer, U = User, I = Internal. . . . . . . . . . . . . . . . . . . . . .* * . 367 B.14 ESROS State Transition Diagram-Connectionless Transmission, 2-Way HS: Performer. P = Protocol, T = Timer, U = User, I = Inter- nal. . . . . . . . . . . . . . . . . . . . * *. 369 B.15 PDU Coding . . . . . . . . . . . . . . . 374 B.16 ESRO-INVOKE-PDU format. ESRO-INVOKE- PDU Type Code = 0. Note: Invoker SAP = Performer SAP - 1. . . . . . . . . . . . 375 B.17 Parameter Encoding Type for ESRO-INVOKE- PDU . . . . . . . . . . . . . . . . . . . * *375 B.18 ESRO-RESULT-PDU format . . . . . . . 376 B.19 Parameter Encoding Type for ESRO-RESULT- PDU . . . . . . . . . . . . . . . . . . . * *376 B.20 ESRO-ERROR-PDU format . . . . . . . 377 B.21 Parameter Encoding Type for ESRO-ERROR- PDU . . . . . . . . . . . . . . . . . . . * *377 B.22 Fields of ESRO-ACK-PDU . . . . . . . . 378 B.23 Encoding of ESRO-ACK-PDU Type . . . 378 B.24 ESRO-FAILURE-PDU format . . . . . . 378 LIST OF TABLES xix B.25 Encoding of failure value . . . . . . . . . 379 B.26 ESRO-INVOKE-SEGMENTED-PDU for- mat . . . . . . . . . . . . . . . . . . . .* * 380 B.27 Parameter Encoding Type for ESRO-INVOKE- SEGMENTED-PDU . . . . . . . . . . . 380 B.28 ESRO-RESULT-SEGMENTED-PDU for- mat . . . . . . . . . . . . . . . . . . . .* * 381 B.29 Parameter Encoding Type for ESRO-RESULT- SEGMENTED-PDU . . . . . . . . . . . 381 B.30 ESRO-ERROR-SEGMENTED-PDU . . . 382 B.31 Parameter Encoding Type for ESRO-SEGMENTED- ERROR-PDU . . . . . . . . . . . . . . . 383 B.32 ESRO-CONCATENATED-PDU format . 384 C.1 EMSD-P Operations Summary . . . . . . 425 Chapter 1 Executive Summary Until now, the Internet has been largely based upon sim- ple protocols. However, the era of simple protocols is now over. The new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality places an entirely new set of requirements on the underlying communica- tions protocols: they must now provide the power effi- ciency demanded by hand-held wireless devices, together with the bandwidth efficiency demanded by wide area wireless networks. It is now time for a new generation of protocols to be implemented, designed to address the need for perfor- mance, rather than simplicity. The industry-wide adoption of this new generation of powerful and efficient protocols will have enormous con- sequences. Protocols addressing the correct requirements will become the lynchpin of a huge new industry. The stakes are enormous, and ferocious competition is to be expected within all segments of the industry. All manner of wild claims and misrepresentations are also to be ex- pected. At the time of writing, the main claimant to the protocol throne is the Wireless Applications Protocol, or WAP. However, WAP will eventually prove to be entirely inadequate to the role being claimed for it. We have designed a set of protocols, the Lightweight & Efficient Application Protocols, or LEAP, which we believe is destined to displace WAP and become the de facto industry standard. These protocols, published as Internet RFC 2524 and RFC 2188, are designed to ad- dress all the technical requirements of the industry, and are oriented towards providing the greatest benefit to the industry and the consumer. This manifesto is about our vision of the future of 1 2 CHAPTER 1. EXECUTIVE SUMMARY the Mobile and Wireless Applications Industry. In the remainder of the manifesto we present the details of our vision, and we justify our claims. We justify our asser- tion that the industry needs a new generation of proto- cols, we explain why our protocols fulfil this need, and we describe how and why these protocols will achieve dominance. The protocols are free, open and in place. Open- source software implementations of the protocols are avail- able for all major platforms. The combination of free protocols and open-source software ensures acceptance of the protocols in the Internet mainstream. There can be no stopping this. 1.1 Technological Scope Most of our discussion throughout this Manifesto is framed in terms of a particular technology, namely, Mobile Mes- saging. It is important to bear in mind, however, that Mobile Messaging is just one aspect of a broader tech- nology: Mobile Consumer Data Communications. Mo- bile Consumer Data Communications refers to the gen- eral ability of an end-user to send and receive digital data at a hand-held device via a wireless network. This tech- nology includes Mobile Messaging as a special case, but also includes other wireless data transfer capabilities such as general Internet access, web browsing, etc. Much of the discussion set forth in this Manifesto ap- plies with equal force to all mobile data communications applications, not just that of messaging. However, it is currently well understood that the dominant application for mobile data communications is, in fact, Mobile Mes- saging, not web browsing or other Internet applications. Therefore throughout this Manifesto we will focus our attention on the messaging application. Though our discussion will be framed in terms of Mo- bile Messaging, the reader should bear in mind that the same principles apply to all forms of mobile data com- munications. Also, whenever we speak of the Mobile Messaging industry, we are referring to the totality of what is re- quired to accomplish effective mobile messaging capa- bilities for the end user. We are not referring to the implementation of mo- bile messaging on any particular device, such as a mobile phone, PDA, palmtop PC, laptop PC, or two-way pager. Similarly, we are not restricting our focus to any specific 1.2. EFFICIENCY IS THE KEY REQUIREMENT 3 technologies or standards, nor are we restricting our focus to a specific market or set of subscriber services. Rather, we are referring to the entire set of technolo- gies and constituencies which are required to enable Mo- bile Messaging. This includes: mobile handheld devices and their manufacturers, wireless modems and their man- ufacturers, wireless data networks and their operators, ISPs and other service providers, and the set of protocols and software implementations required to allow interplay and cooperation among these various consituencies. Our purpose in writing this Manifesto is very ambi- tious: we wish to describe our vision of all that is required to build the entire Mobile Messaging industry. 1.2 Efficiency is the Key Requirement Engineering is the art of making intelligent trade-offs be- tween conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power efficiency, and band- width efficiency. The 1980s and 1990s were the decades of simple pro- tocols - protocols such as the very aptly named Simple Mail Transfer Protocol (SMTP), and Simple Network Man- agement Protocol (SNMP). A great deal of the success of these and other Internet protocols can be attributed to their simplicity. The first generation of network engineers and net- work operators were only able to view network commu- nications in relatively simple terms. It was appropriate to cater to that simplicity with simple protocols. A key reason for the success of these early protocols is the lack of technical sophistication on the part of first-generation network engineers and operators. Simple protocols are easier to make widespread than "good" protocols (meaning those which have better ca- pabilities and performance), for the basic reason that net- work engineers and operators are able to adopt and im- plement simple protocols much more easily than "good" protocols. However, things have changed. Network communica- tions has now expanded dramatically and forcefully into the wireless and mobile data communications arena, and wireless applications demand efficiency. The move to wide-area wireless has significantly shifted the location 4 CHAPTER 1. EXECUTIVE SUMMARY of the ideal engineering balance between simplicity and performance - moving it away from simplicity, and to- wards performance. We therefore need a new generation of high-performance, efficient protocols, to cater to the demands of wireless applications. The point is sometimes made that the need for efficiency in the wireless arena is a temporary one - that advances in wireless engineering technology in the form of third generation (3G) systems will eliminate ex- isting bandwidth limitations, obviating the need for ef- ficient protocols. As long as the capacity of wireless networks remains finite, however, the need for efficiency will persist. Efficient usage is an inherent requirement for any finite resource, therefore the requirement for efficient bandwidth usage and battery longevity is permanent. 1.3 Conventional Origins of Proto- cols Where will the required protocols come from? Tradition- ally, industry-wide protocols have their origins in one of two sources: 1. The major players in the industry itself. In the case of wireless communications, this means the major telecommunications and wireless network compa- nies. 2. Professional protocol and standards producing as- sociations. In the case of wireless communications, this means the IETF, ITU, ISO, ANSI, TIA and others. Unfortunately, neither of these groups has produced a set of protocols which meets the industry's needs. The first group above, represented by a set of telephone com- panies, has generated the WAP specification. However, as we will argue in detail later, this specification is grossy unfit for its claimed purpose. Among other things it is poorly designed, not the product of open peer review, and crippled with Intellectual Property Right (IPR) re- strictions. It is essentially a business construct, not an engineering one. In the long run WAP cannot possibly survive as a viable solution. In the short run it can only have a destructive effect on the wireless industry. The second group above, most notably represented by IETF, has likewise failed to produce an acceptable stan- dard. IETF represents the tradition of simple protocols, 1.4. EXPECT THE UNEXPECTED 5 a tradition which wireless communications has made ob- solete. Unfortunately, IETF remains rooted in this tradi- tion, and has not adapted to the new realities of wireless communications. Until it does so, IETF will remain inef- fective as a protocols and standards body. In the area of efficient protocols, IETF is simply bankrupt. 1.4 Expect the Unexpected Fortunately, there are other sources of innovation. One of these is the radical new development that comes out of nowhere, taking everybody by surprise. Typically this originates in the actions of a small group of independent experts, with a deep understanding of the technology and industry, and who are passionate about and committed to its health and vigor. Note that the World Wide Web itself originated in nei- ther of the traditional sources, but instead came from an entirely different and unexpected direction: a group of physicists at the CERN laboratory in Switzerland. As an- other example, Pretty Good Privacy (PGP), now the de facto standard for electronic data encryption, also came from neither traditional source. It was essentially the cre- ation of a single man: Phil Zimmermann. Armed with a vision and a belief in its value, Zimmermann single- handedly made PGP the dominant consumer encryption application - displacing the IETF alternatives in the pro- cess. The solution to the current wireless application dilemma is also likely to come from an unexpected source - and we believe that we are that source. In the world of the Internet, we have learned to expect the unexpected. 1.5 Our Solution We have developed a set of protocols which we believe address all aspects of the industry's needs. Beyond their purely technical requirements, a fundamental requirement of all industry-building protocols is that they be com- pletely open and free from patents and other IPR restric- tions - either because no patents actually exist, or be- cause reasonably non-restrictive licenses are granted by the patent holder. In the rest of this document, this is what we mean when we speak of "patent-free" protocols. The presence of patented components within a pro- tocol is extremely undesirable, since this undermines the ultimate purpose of the protocol: its unrestricted adoption 6 CHAPTER 1. EXECUTIVE SUMMARY and usage. The process that we have followed in devel- oping our protocols has been such as to ensure that they are entirely open and, as far as this can be guaranteed, patent-free. A significant part of this process consists of our full committment to the processes and procedures of the Free Protocols Foundation (FPF). The FPF is an organizational framework for the devel- opment and maintenance of free protocols. It allows de- velopers to declare publicly that the protocols they have developed are intended to be patent-free, and that it is their intention to keep them patent-free into perpetuity. We have made this declaration through the Free Proto- cols Foundation with regard to our own protocols. Note that this is in sharp contrast to the WAP proto- cols, which include severe IPR restrictions. This creates an unfair market advantage in favor of the initial WAP de- signers. Our intention is to create a protocol which does not favor any one industry player over another, and places competition where it belongs: on the merits of each com- pany's individual products and services. We have created the general framework for a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. We refer to this gen- eral framework as the Lightweight & Efficient Applica- tion Protocols (LEAP). The need for efficient protocols extends across all as- pects of wireless data communications, including e-mail, web browsing, and other applications. The LEAP archi- tecture accommodates all of these applications. Our ini- tial implementation, however, is focussed on the Mobile Messaging application, since we believe that this is the dominant application for wide-area wireless networks. All efficient applications have the requirement for an efficient transport mechanism. For this reason, the ini- tial focus of our protocol development effort has been on creating a general efficient transport mechanism. The re- sulting protocol is referred to as Efficient Short Remote Operations (ESRO). ESRO is a reliable, connectionless transport mechanism, forming the foundation for the de- velopment of efficient protocols when TCP is too much and UDP is too little. Our Efficient Mail Submission and Delivery (EMSD) protocol is built on top of ESRO, and is designed to ad- dress the Mobile Messaging application. Both of these protocols have been published as Inter- net RFCs: ESRO as RFC 2188, and EMSD as RFC 2524. RFC publication ensures that the protocols are freely, eas- ily and permanently accessible to anyone who wishes to 1.6. A BRIEF HISTORY OF LEAP 7 use them. Note that this also is in stark contrast to WAP, which is self-published by the members-only WAP Forum. Fur- thermore, the WAP Forum reserves the right to make uni- lateral changes to its protocols; each of the WAP proto- cols carries on its cover page the disclaimer, "subject to change without notice." Publication of a protocol as an Internet RFC ensures that the protocol will remain stable and permanently avail- able to anyone who wishes to use it, and for this reason is the mainstream Internet publishing method. The declin- ing of the WAP Forum to publish their specifications as Internet RFCs suggests either that the forum wishes to re- tain an inappropriate degree of control over the specifica- tions, or that the specifications do not meet the minimum technical standards required for RFC publication. 1.6 A Brief History of LEAP LEAP originated in 1994 as part of the research and de- velopment initiatives of McCaw Cellular's wireless data group (now AT&T Wireless Services). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS net- work also. By 1996 McCaw Cellular was fully committed to pag- ing, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless message transport and delivery system. Neda Communications, Inc., an independent consulting com- pany working under contract to McCaw Cellular, played a significant role in the development of the required sys- tem. Neda Communications had also been involved from the outset in the development of the CDPD specification. In 1997 however, soon after the purchase of McCaw Cellular by AT&T, the latter company abandoned narrow- band PCS paging altogether. Prior to this event, Neda Communications had secured from AT&T the necessary rights to continue independent development of the pro- tocols. Therefore, recognizing the eventual future need for these protocols, Neda then undertook to continue de- velopment of the protocols independently of AT&T. They were eventually completed by Neda, published as RFCs, and now form the cornerstone of the LEAP protocols. 8 CHAPTER 1. EXECUTIVE SUMMARY 1.7 Making Our Solution Widespread Our ultimate goal is to make these protocols widespread. Developing and publishing a set of protocols, however, is just the beginning. Protocols become accepted as stan- dards as a result of public review, modification by con- sensus, and ultimately by standing the test of usage in the industry at large. To provide a forum for these processes, we have cre- ated EMSD.org and ESRO.org. Each of these organiza- tions allows public review of the respective protocol, and provides a mechanism for correction and enhancement of the protocol as a result of collective experience. Any interested person can become a member of these organi- zations and participate in the further development of the protocols. The only requirement for membership is that participants must adhere to the principles and procedures of the Free Protocols Foundation, ensuring that the pro- tocols remain permanently patent-free. Note that this also is in sharp contrast to WAP. Partici- pation in WAP, far from being open and public, requires a $27,000 membership fee (as of February 2000), and takes place entirely behind closed doors. In order for the protocols to become widely accepted, they must be implemented in the form of software solu- tions that are readily available for deployment by end- users. We have therefore created open-source software implementations of the protocols for most common plat- forms. Protocol engines are available in the form of portable code which has been ported to a variety of platforms. On the device side, software is available for Windows CE, Palm OS, EPOC, and others. On the message center side, software is available for NT, Solaris, and Linux. As noted above, our initial emphasis is on the Mo- bile Messaging application. Protocol engines are only a single component of a larger picture; in order to provide complete solutions to the user it is necessary to integrate these protocols into other existing pieces of software. To that end we have created MailMeAnywhere.org, where fully-integrated solutions in open-source format are made available to the user. We will initially "prime the pump" by providing free subscriber services through ByName.net and ByNumber.net. This will provide initial support for adoption of the proto- cols by end-user devices. Usage of the protocols among a sufficient number of user devices will then provide the motivation for usage among the message center systems. 1.8. COMPLETE AND READY 9 1.8 Complete and Ready All the components that are needed to accomplish these goals are complete, in place, and ready to go. These com- ponents are: The Protocols. The protocols are well-designed, meet all the technical requirements of the industry, and are published as RFCs - the mainstream Internet pub- lishing procedure. The complete text of RFC 2188 and RFC 2524 is available at: http://www.rfc-editor.org Open Maintenance Organizations. The protocols are main- tained at EMSD.org and ESRO.org, allowing open and non-exclusionary participation in the mainte- nance of the protocols. For complete details see: http://www.esro.org and http://www.emsd.org Freedom from Patents. The protocols are patent-free to the best of our knowledge, and are guaranteed to stay that way. This ensures permanent, unrestricted access to the protocols. For more information see: http://www.FreeProtocols.org Open-Source Software Implementations. These are be- ing made available for a wide variety of of plat- forms and end-user devices, including: pagers and cell-phones; hand-held PCs (Windows CE, Palm PC) and Palm Pilot; Windows 98, Windows 95, and Windows NT; Pine (UNIX, Windows, DOS). For complete details see: http://www.MailMeAnywhere.org Free Subscriber Services. These are provided to support initial deployment of the protocols in end-user de- vices. For complete details see: http://www.ByName.net and http://www.ByNumber.net Collectively, the above components represent a com- plete recipe for the success of the LEAP protocols. All the pieces of the puzzle are complete, and there are no missing pieces. 1.9 How to Participate As noted above, the LEAP protocols are entirely open, and any interested person or organization may participate 10 CHAPTER 1. EXECUTIVE SUMMARY in their development. To participate in the development of the LEAP protocols in general, visit the LEAP Forum website at http://www.leapforum.org/. To participate in the development of specific members of the LEAP family of protocols, visit the ESRO.org website at http://www.esro.org/, or the EMSD.org website at http://www.emsd.org/. All of the above websites host mailing lists for com- mentary and general information exchange regarding the protocols. In particular, ESRO.org and EMSD.org host Working Group mailing lists for active development of their respective protocols. In addition, we invite participation in the develop- ment of The LEAP Manifesto itself. We expect that as the LEAP family of protocols grows and becomes imple- mented on additional platforms, additional articles will be included in the Manifesto. Any person or organiza- tion may submit information or articles that they feel are appropriate for inclusion in the Manifesto; any such ma- terial will be given due consideration by the Manifesto editor. In addition, we would welcome the translation of key Manifesto articles into foreign languages. One such trans- lation has already taken place; the Manifesto article The WAP Trap is now available in French under the title Le WAP a la Trappe. Other key articles that would be greatly desirable in foreign language translations include LEAP: One Alternative to WAP, and Operation WhiteBerry. Per- sons interested in writing foreign language translations are asked to contact the Manifesto editor at info@leapforum.org. We also invite general commentary and criticism of the Manifesto. Please let us know of any errors, omis- sions or ambiguities you may find in the Manifesto. Any input or commentary should be submitted to the Mani- festo editor at info@leapforum.org. 1.10 Who We Are Throughout the Manifesto, we frequently refer to our- selves in the first person, and we also refer to several or- ganizations and domains that are in some way related to the LEAP protocols. The question may be asked, who exactly are "we"? Who are the authors of the Mani- festo, and what is their relationship to the organizations involved in the development of LEAP? Who owns LEAP? In this section we provide the answers to these questions. Mohsen Banan. Mohsen Banan is the principal editor of The LEAP Manifesto; he is also the author of 1.10. WHO WE ARE 11 many of its component articles. Several other au- thors also wrote and/or contributed material to cer- tain component articles; these are acknowledged in the appropriate articles. First-person references throughout the Manifesto refer to the principal ed- itor, Mr. Banan. Mr. Banan is also the president of Neda Commu- nications, Inc. He is also the president and a board member of the Free Protocols Foundation. Neda Communications, Inc. Neda Communications, Inc. is a private, for-profit company located in Bellevue, WA. Neda provides consulting services and devel- ops products and services relating to wireless data communications. Neda has independently led the development of the LEAP protocol specifications since 1997. Neda has also developed a comprehensive set of software implementations of the LEAP protocols, which it intends to subject to the GNU Public License and make freely available. The LEAP Protocols. The design and development of the LEAP protocols was primarily carried out by several engineers working at Neda Communications, Inc. The development effort was led and coordi- nated by Mohsen Banan. RFC-2188 was published jointly by Neda and AT&T personnel. RFC 2524 was published individually by Mohsen Banan. As the primary author of both RFCs, patent-free dec- larations for both protocols were made by Mohsen Banan and on behalf of Neda. No one owns the LEAP protocols. The protocol specifications reside entirely in the public domain. The LEAP Forum. The LEAP Forum is a clearing house for information and pointers relating to the LEAP protocols. The LEAP Forum is not a standards or- ganization, it is not a legal entity of any kind, and it is not a membership organization. The LEAP Forum maintains a mailing list for the free inter- change of information and commentary regarding the LEAP protocols. Any interested person or or- ganization may subscribe to the mailing list. The LEAP Forum website and mailing list are presently hosted by Neda equipment and network resources, and managed by Neda personnel. For more information, visit the LEAP Forum web- site at http://www.leapforum.org/. ESRO.org and EMSD.org. ESRO.org and EMSD.org are open organizations for the development and main- 12 CHAPTER 1. EXECUTIVE SUMMARY tenance of the ESRO and EMSD protocols respec- tively. Neither organization is a standards organi- zation, nor a legal entity of any kind, nor a mem- bership organization. They are simply forums to allow information exchange and cooperative effort relating to the LEAP protocols and technology. Both organizations maintain several mailing lists, to which any interested person or organization may subscribe. The ESRO and EMSD websites and mailing lists are presently hosted by Neda equip- ment and network resources, and managed by Neda personnel. In particular, each organization hosts a Working Group mailing list for active development of the corresponding protocol. Mohsen Banan is the cur- rent chairperson of both Working Groups, with re- sponsibility for coordinating the Working Group development effort. For complete information, visit the appropriate web- site at either http://www.esro.org/ or http://www.emsd.org/. Free Protocols Foundation. The Free Protocols Foun- dation is a non-profit organization whose mission is to prevent the inclusion of patented components within protocols. The FPF has established a set of policies and procedures for protocol development that is designed to ensure that the resulting proto- col is patent-free. The LEAP protocols conform fully to these policies and procedures. Free Pro- tocols Foundation board members include Mohsen Banan and Richard Stallman. For more information see the Free Protocols Foun- dation website at http://www.FreeProtocols.org. 1.11 About The LEAP Manifesto The purpose of The LEAP Manifesto is to provide a com- plete description of the LEAP protocols and their intended role in the development of the Mobile Messaging indus- try. The Manifesto includes: - An overview of the Mobile Messaging industry, and a description of the essential factors that are required for its long term success and growth. - A technical description of the LEAP protocols them- selves. 1.11. ABOUT THE LEAP MANIFESTO 13 - A description of the process used to develop the LEAP protocols, and how and why this differs from the conventional development process. - Technical descriptions of key aspects of the LEAP protocols, including their efficiency, and their im- plementation on Windows CE devices and Palm OS devices. - An analysis of several closed Mobile Messaging solutions (e.g. WAP), and a description of LEAP's superiority to these closed solutions. - A description of our strategy for encouraging widespread usage of the LEAP protocols, including the distri- bution of open-source software implementations of the protocols, and the availability of free subscriber services. 1.11.1 Manifesto Organization The LEAP Manifesto is organized as a series of largely independent articles. Each of these articles stands on its own, and can be read and understood independently of the others. Together, these articles provide a complete picture of the Mobile Messaging industry and the role of the LEAP protocols. Since each article is intended to be self-contained, some material is duplicated in more than one article. The LEAP Manifesto consists of the following arti- cles: - Executive Summary. An overview summary of the entire LEAP Manifesto. The Executive Sum- mary provides a brief description of all the major elements of the manifesto. First Published: 2000/8/4 Last Updated: 2000/12/5 Article formats: [HTML] [PDF] [PS] [Text Only] - Part I: The LEAP Protocols - Overview of the LEAP Protocols. A general overview description of the LEAP protocols. First Published: August 4, 2000 Last Updated: August 8, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - The LEAP Protocol Development Model. A description of the processes used to develop the LEAP protocols, and how and why these differ from conventional development processes. 14 CHAPTER 1. EXECUTIVE SUMMARY This article also includes a criticism of the IETF protocol development processes. First Published: August 4, 2000 Last Updated: June 16, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Free Protocols Foundation Policies and Pro- cedures A description of the Free Protocols Foundations processses to ensure the devel- opment and maintenance of patent-free pro- tocols. First Published: March 29, 2000 Last Updated: June 26, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - ESRO: A Foundation for the Development of Efficient Protocols. A technical descrip- tion of ESRO, the transport mechanism com- ponent of LEAP. First Published: August 4, 2000 Last Updated: August 9, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - EMSD: The LEAP E-Mail Component. A technical description of EMSD, the e-mail com- ponent of LEAP. First Published: August 4, 2000 Last Updated: July 14, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Efficiency of EMSD. A technical paper ana- lyzing the efficiency characteristics of EMSD and comparing its efficiency to other e-mail protocols. First Published: October 23, 1996 Last Updated: August 16, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - A Brief History of LEAP. A summary of the major events in the evolution of the LEAP protocols. First Published: August 4, 2000 Last Updated: September 20, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - The Future of LEAP. A description of the planned future development of LEAP, includ- ing descriptions of several LEAP-based prod- ucts and services which are currently under 1.11. ABOUT THE LEAP MANIFESTO 15 development. First Published: August 4, 2000 Last Updated: June 14, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Part II: LEAPing Over Closed Solutions - The WAP Trap. A detailed criticism of a set of specifications called the Wireless Applica- tion Protocol, or WAP. This article demon- strates that WAP is entirely unfit to play the role of a Mobile Messaging industry standard. First Published: April 3, 2000 Last Updated: May 26, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - LEAP: One Alternative to WAP. A point- by-point comparison of the LEAP protocols to the WAP specifications. This article demon- strates that LEAP has all the desirable charac- teristics of an industry standard protocol that WAP lacks. First Published: August 4, 2000 Last Updated: December 6, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - WAP Scraps. A discussion of what can be salvaged from what remains of WAP. First Published: August 28, 2001 Last Updated: August 28, 2001 Article formats: - WAP Scraps. A description of what to do with what is left of WAP First Published: 2001/8/13 Last Updated: 2001/8/13 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Operation Whiteberry. A description of how equivalent functionality to the closed Black- Berry mobile messaging solution can be im- plemented based on a completely open model, using existing open-source software implemen- tations of LEAP, and existing off-the-shelf hard- ware components. First Published: February 27, 2001 Last Updated: August 2, 2001 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Part III: Making LEAP Widespread 16 CHAPTER 1. EXECUTIVE SUMMARY - Strategy for Making LEAP Widespread. A description of our strategy for encouraging widespread usage of the LEAP protocols, in- cluding the distribution of open-source soft- ware implementations of the protocols, and the availability of free subscriber services. First Published: August 4, 2000 Last Updated: August 8, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - EMSD on Windows CE. A technical paper describing the architecture and implementa- tion of EMSD on Windows CE devices. First Published: March 3, 1997 Last Updated: August 16, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - LEAP on Palm OS. A technical paper de- scribing the architecture and implementation of LEAP on Palm OS devices. First Published: TBD Last Updated: TBD Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Trying out LEAP. A step-by-step, hands-on demonstration of how the LEAP protocols can be used to turn any Windows CE device into a fully functional Mobile Messaging device. First Published: June 12, 1998 Last Updated: June 12, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - WhiteBerry and Bluetooth. A description of how WhiteBerry and Bluetooth can be used in combination to bring new and enhanced messaging capabilities to the mobile profes- sional. First Published: July 27, 2001 Last Updated: July 31, 2001 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Use of EMSD for Mail Notification. A de- scription of how EMSD can be used to pro- vide a general Mail Notification service. First Published: TBD Last Updated: TBD Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Lessons From History: Comparative Case Studies. An analysis of the factors which 1.11. ABOUT THE LEAP MANIFESTO 17 lead to the success or failure of protocols, in- cluding discussions of several historical case studies. First Published: August 4, 2000 Last Updated: July 7, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] - Part IV: The Mobile Messaging Industry - The Mobile Messaging Industry. An overview of the Mobile Messaging industry, and a de- scription of the essential factors that are re- quired for its long term success and growth. First Published: August 4, 2000 Last Updated: August 10, 2000 Article formats: [ONE-HTML] [SPLIT-HTML] [PDF] [PS] [Text Only] 1.11.2 Draft Articles The LEAP Manifesto is a work in progress, and various additional articles are planned for future inclusion in the Manifesto. Some of these future articles already exist in draft form, and are available for review in the Draft Documents section of the LEAP Forum website at http://www.leapforum.org/draft- leapManifesto/. As these and other articles are completed, they will be incorporated into the Manifesto. 1.11.3 Getting the Manifesto The LEAP Manifesto and all of its component articles are available in multiple formats, including HTML, PDF, PostScript, and plain text. You can view or download the Manifesto in any of these formats from the LEAP Forum website at http://www.LeapForum.org/leap/index.html. The LEAP Manifesto is also available at the Free Protocols Foundation website at http://www.FreeProtocols.org/leap/index.html. 18 CHAPTER 1. EXECUTIVE SUMMARY Part I The LEAP Protocols 19 Chapter 2 Overview of the LEAP Protocols 2.1 Introduction The key component of the Manifesto is a set of mobile messaging protocols called the Lightweight & Efficient Application Protocols, or LEAP. LEAP is a set of high- performance, efficient protocols which are ideal for mo- bile and wireless applications. This article provides a brief overview of the LEAP protocols; complete details are provided elsewhere in The LEAP Manifesto [65 ]. 2.2 The Need for Efficiency Engineering is the art of making intelligent trade-offs be- tween conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power efficiency, and band- width efficiency. The 1980s and 1990s were the decades of simple pro- tocols - protocols such as the very aptly named Simple Mail Transfer Protocol (SMTP), and Simple Network Man- agement Protocol (SNMP). A great deal of the success of these and other Internet protocols can be attributed to their simplicity. The first generation of network engineers and net- work operators were only able to view network commu- nications in relatively simple terms. It was appropriate to cater to that simplicity with simple protocols. A key 21 22CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS reason for the success of these early protocols is the lack of technical sophistication on the part of first-generation network engineers and operators. Simple protocols are easier to make widespread than "good" protocols (meaning those which have better ca- pabilities and performance), for the basic reason that net- work engineers and operators are able to adopt and im- plement simple protocols much more easily than "good" protocols. However, things have changed. Network communi- cations has now expanded into the wireless and mobile data communications arena, and wireless applications de- mand efficiency. The move to wide-area wireless has significantly shifted the location of the ideal engineering balance between simplicity and performance - moving it away from simplicity, and towards performance. Wireless networks are constrained by bandwidth lim- itations, and the hand-held devices they serve are con- strained by limitations such as display size, battery ca- pacity, and memory capacity. These constraints place an extremely high premium on the efficiency of data trans- fer. Existing Internet protocols do not provide the required efficiency. We therefore need a new generation of high- performance, efficient protocols, to cater to the demands of wireless applications. The point is sometimes made that the need for efficiency in the wireless arena is a tem- porary one - that advances in wireless engineering tech- nology in the form of third generation (3G) systems will eliminate existing bandwidth limitations, obviating the need for efficient protocols. As long as the capacity of wireless networks remains finite, however, the need for efficiency will persist. Efficient usage is an inherent re- quirement for any finite resource, therefore the require- ment for efficient bandwidth usage and battery longevity will remain. 2.3 Technical Overview of LEAP The LEAP protocols are intended to be an enabling cata- lyst for the growth of the wireless-IP based Mobile Mes- saging industry, and have been designed with this goal in mind from the outset. They have been designed as a genuine enabling technology which will bring enormous benefits to the industry and the consumer. They are a sound engineering construction based on true openness and patent-freedom. 2.3. TECHNICAL OVERVIEW OF LEAP 23 The LEAP protocols a general-purpose solution to the problem of efficient message transfer, and their use is not limited to any particular device type or network. In particular, LEAP is compatible with all wireless-IP net- works. Examples of wireless networks which provide na- tive support for LEAP are CDPD, GSM, packet CDMA, and PCS. The basic organization of the LEAP protocols is shown in Figure 2.1. Figure 2.1: LEAP Protocol Organization 2.3.1 The ESRO Layer: Efficient Transport Services As shown in Figure 2.1, the LEAP protocols are layered. The lower layer is called Efficient Short Remote Opera- tions, or ESRO. The ESRO layer provides reliable con- nectionless transport services which can be used for a va- riety of applications. For example, in addition to mobile messaging services, ESRO can also be used as a trans- port service for credit card verification applications and efficient micro browsers. For more information on ESRO see the article ESRO: A Foundation for the Development of Efficient Protocols within The LEAP Manifesto, or visit the ESRO website at http://www.esro.org/. 24CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS 2.3.2 The EMSD Layer: Efficient E-Mail One of the efficient application layers built on top of ESRO is called Efficient Mail Submission & Delivery, or EMSD. EMSD is the component of LEAP that addresses the Mo- bile Messaging application. EMSD is a specialized native Internet messaging pro- tocol. It defines a similar set of services to the existing SMTP protocols. It defines a complete set of rules for message submission (end-user device to server) and mes- sage delivery (server to end-user device). EMSD meets or exceeds the level of functionality, reliability and security provided by the existing SMTP protocols. Though its use is not limited to wireless networks, EMSD has been designed specifically to address the re- quirements of wireless networks, such as CDPD, Wireless- IP, Mobile-IP. In particular, EMSD has been designed with a very strong and clear emphasis on efficiency. EMSD is highly optimized for the submission and delivery of short (typically 4 kilobytes or less) Internet e-mail messages, and is therefore extremely well suited to the wireless environment. EMSD improves on exist- ing messaging protocols by optimizing the exchange be- tween the server and the end-user device, both in terms of the number of bytes transferred and the number of trans- missions. Because of the required timeliness of the mes- sages, mailbox access protocols like POP and IMAP are not used. EMSD is the only truly open messaging proto- col that is specifically designed for the wireless network environment. EMSD is a natural extension of the existing Inter- net e-mail environment, and accommodates the two-way paging model of usage, in which time-critical messages are "pushed" to the recipient. Any network or network operator which faces signifi- cant bandwidth and capacity limitations can benefit from the use of EMSD. Any user of a network who must bear high costs for measured network usage can benefit from the use of EMSD. The initial use of EMSD is expected to be primarily to provide Mobile Messaging services over IP-based wire- less networks. However, EMSD can also function as an adjunct to Mail Access Protocols for "Mail Notification Services." For more information on EMSD see the article EMSD: The LEAP E-Mail Component within The LEAP Mani- festo, or visit the EMSD website at http://www.emsd.org/. 2.4. EFFICIENCY CHARACTERISTICS OF LEAP 25 2.3.3 The EHTD Layer: Efficient Web Brows- ing The Efficient Hyper Text Delivery (EHTD) layer is a hy- pertext transfer protocol which is optimized for the effi- cient transfer of short markup pages. EHTD is the com- ponent of the LEAP protocols which facilitates web brows- ing. Along with EMSD, EHTD also benefits from the reliable efficient services of ESRO. A multiplicity of effi- cient markup languages can be used in conjunction with EHTD. Development of the EHTD protocol is currently in progress. 2.3.4 Other Efficient LEAP Applications Various other efficient application protocols are either un- der development, or anticipated for future development. One of these is the Efficient Dictionary protocol, or E- DICT, which will enable efficient access to dictionaries and other look-up data structures. A starting point for the E-DICT protocol is currently being created. In devel- oping E-DICT, we intend to build on the existing work already done in the context of the DICT protocol. We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementations of ESRO-based instant messaging, chat, white pages, and others. 2.4 Efficiency Characteristics of LEAP All LEAP protocols are designed with efficiency in mind. In this section we describe the efficiency characteristics of EMSD, the LEAP e-mail protocol. Other LEAP pro- tocols deliver similar efficiency benefits. Most existing Internet e-mail protocols are designed with simplicity, and continuity with SMTP traditions, as two of the primary design requirements. These require- ments are in conflict with efficiency of data transfer, and for this reason most existing Internet e-mail protocols are not efficient. EMSD, on the other hand, has been designed with efficiency as its primary requirement. For this reason, EMSD is a great deal more efficient than existing Internet e-mail protocols. A detailed efficiency study of the LEAP protocols is provided in the article entitled Efficiency of EMSD [57 ] 26CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS within The LEAP Manifesto. That article presents var- ious efficiency studies which compare the efficiency of EMSD to other e-mail protocols such as SMTP, POP and IMAP, and which demonstrate the efficiency advantages of EMSD. In this section we provide a brief summary of EMSD's efficiency characteristics. A comparison of the efficiency of the EMSD protocol to other messaging protocols is provided in Figure 7.3, which shows the delivery traf- fic overhead for EMSD and three other e-mail protocols: SMTP, IMAP and POP. Figure 2.2: Protocol Efficiency Comparison As the figure shows, EMSD is much more efficient than SMTP, POP and IMAP. For submission and deliv- ery of short e-mail messages, EMSD is up to five times more efficient than the ubiquitous SMTP e-mail messag- ing protocols, both in terms of the number of packets transmitted, and in terms of number of bytes transmitted. Even with pipelining and other possible optimizations of SMTP, EMSD remains up to three times more efficient than SMTP, both in terms of the number of packets trans- mitted, and in terms of number of bytes transmitted. By minimizing the network traffic required to send 2.5. LEAP: A BASIS FOR CONVERGENCE 27 and receive messages, EMSD meets the needs of the mo- bile communicator. The extreme efficiency of the EMSD protocol translates into bandwidth efficiency, which in turn translates into: - Efficient use of carrier bandwidth, and therefore in- creased capacity for network operators - Longer battery life for mobile phones, PDAs and other wireless Internet devices - Cheaper network usage costs for the end-user - Reduced latency for the end-user - Improved support for marginal coverage areas 2.5 LEAP: A Basis for Convergence An illustration of how LEAP works is shown in Figure 21.4. As the figure shows, LEAP provides complete open- ness of interoperability among Mobile Messaging devices, message centers, and wireless networks. LEAP will thus have the effect of unifying the en- tire Mobile Messaging industry under a set of open Inter- net Protocol ("IP") standards and protocols so that, in the manner of the World Wide Web, all of the Mobile Mes- saging networks will effectively operate as one. In order to achieve this convergence, it is not suffi- cient for the Mobile Messaging industry merely to adopt a set of common protocols. Many would claim that WAP is in fact just such a set of common protocols. However, a further essential attribute of the required protocols is that they must be a truly integral, "end-to-end" part of the Internet, as opposed to "gateways" which accommodate unnecessary gatekeepers and middlemen. LEAP is based on the concept of the Internet end-to- end model, in which direct communication between the client and the server assumes that the role of the network service provider is merely that of a pipe - i.e. a passive communication conduit. The Internet end-to-end model assumes that both ends are under the control and choice of the user, and that the servers are widespread, from a variety of providers, and under no specific administra- tion or control. The Internet end-to-end model is in sharp contrast to the traditional phone company and telecom- munications approach, which inserts gateways between the two ends, and creates control and exploitation oppor- tunities for the telecommunication operators. 28CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS Figure 2.3: Open Mobile Messaging Bearing in mind that the natural convergence of all wireless networks to IP at Layer 3 is well under way and rapidly progressing, the key remaining requirements are: efficiency, lightweightness, miniaturization, and confor- mance to the Internet end-to-end model. LEAP fulfils all of these requirements. By serving as the necessary missing link, LEAP will become the ultimate basis for convergence. The mobile e-mail component of LEAP is EMSD. In the spirit of the Internet end-to-end model, the EMSD protocol will facilitate the convergence of the IP-based two-way paging industry, and Internet e-mail, in a natural and transparent manner. 2.6 The End-User's Experience The entire LEAP family of protocols bring efficiency and functionality benefits to the user of miniaturized mobile 2.6. THE END-USER'S EXPERIENCE 29 devices. In this section we describe the user's experience of an EMSD-enabled device. Mobile users may not always have the benefit of a wired connection, because of their frequent mobility. They may have a permanent computing system elsewhere, at which they can review large messages at their leisure (for example, messages containing Word documents, Excel spreadsheets, images, etc.). While on the move, however, they need to be kept apprised of important information that requires their immediate attention. Such information cannot wait for them to find the time to set up a laptop and dial in to check for messages. They must be able to ac- cept messages immediately, at any time, and on a device that they can carry anywhere. The experience of the end-user in using LEAP-based Mobile Messaging technology is illustrated in Figure 13.2. Figure 2.4: The End-User's Experience The user equips him/herself with an EMSD device. The EMSD device could be a dedicated two-way pager, or a hand-held device (such as a PalmPC) with a wire- 30CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS less (for example CDPD) modem. While the device can be turned off, the modem will remain on at all times to accept incoming messages. Anyone with access to the Internet can now send a message to this user. The EMSD Service Provider ac- cepts the message from the Internet e-mail system via standard Internet protocols, then delivers the message to the user's device via EMSD protocols. Since the modem is always on, the message can be accepted at any time, and the user can be notified immediately (in any of the ways commonly used for pager notification) that a mes- sage has arrived. The user will then activate the EMSD device and read the message. To send a message the user enters the message, then submits it to the EMSD Service Provider via the EMSD protocols. The Service Provider then acts like a standard Internet Service Provider and sends the message to its destination. The end-user device may have a limited display area and a limited keyboard. This is very much the case for today's cell phones, for example. If so, both the end- user and his/her correspondents may wish to make use of canned messages to facilitate their communication. These canned messages may be defined by the system or end- user device, or they may defined by the message origina- tor as embedded multiple-choice responses. Figure 13.2 illustrates how the Mobile Messaging needs of a typical user (we'll call him Joe) are provided by the LEAP technology. This figure includes all the required technological components, and shows how they interop- erate to satisfy Joe's needs. The figure includes three ma- jor components: 1. Joe requires some form of handheld mobile device, such as a cell phone or a PDA. This component is shown on the left side of the figure. The device must include the appropriate LEAP device software, allowing it to use the LEAP protocols to commu- nicate with LEAP-enabled Message Centers, either directly over the Internet, or via a Subscriber Ser- vice system. 2. Joe requires a set of Subscriber Services to support his Mobile Messaging capability. This component is shown in the center of the figure. 3. Joe may also wish to have LEAP-based Mobile Mes- saging capability on a Personal Desktop system at home, or on a Corporate Intranet system at his of- fice. These components are shown on the right side 2.7. THE LEAP DEVELOPMENT PROCESS 31 of the figure. If Joe receives a generic (i.e. non-LEAP) e-mail mes- sage over the Internet, then this will be fielded by his Sub- scriber Service provider, then forwarded to Joe's mobile device using the LEAP protocols. Meanwhile, e-mails for Joe may be received in ei- ther his home or office mailbox systems. Joe may con- figure either of these systems to forward certain e-mails to his mobile device on a selective basis. If so, the qual- ifying e-mails will be forwarded to him directly over the Internet, using the LEAP protocols. The Subscriber Ser- vices system need not be involved in the transmission of these forwarded e-mails, since they are being sent from one LEAP-enabled system to another. In summary, the end-user experience described above represents a superset of the capabilities of the RIM Black- Berry [tm] system. The market success of BlackBerry clearly demonstrates the large user demand for this kind of service. By providing the same functionality of Black- Berry in a completely open fashion, the benefits to the consumer will be that much greater. For further discus- sion, see the article Operation WhiteBerry in The LEAP Manifesto. 2.7 The LEAP Development Process The LEAP protocols are intended to be open in the fullest sense of the word; they are intended to be freely and per- manently available, subject to public review and revision, and without usage restrictions of any kind. Therefore the processes and procedures used throughout the develop- ment and maintenance of the LEAP protocols have been such as to endow them with these characteristics, and to ensure their integrity as public protocols. A detailed description of the LEAP development pro- cess is provided in the article entitled The LEAP Protocol Development Model within The LEAP Manifesto. In the following sections we provide a brief summary of the ma- jor development principles. 2.7.1 Patent-Freedom The development and maintenance of the LEAP proto- cols conforms fully to the policies and procedures of the Free Protocols Foundation. In particular, Neda has de- clared to the Free Protocols Foundation that the LEAP 32CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS protocols are patent-free to the best of its knowledge, and that it intends to keep them patent-free permanently. For more information see http://www.FreeProtocols.org. 2.7.2 RFC Publication Both protocols have been published as Internet RFCs; ESRO in September 1997 as RFC-2188 [91 ], and EMSD in March 1999 as RFC-2524 [5 ]. RFC publication is the mainstream Internet publishing procedure, ensuring that the protocols are freely, easily and permanently accessi- ble to anyone who wishes to use them. 2.7.3 Open Maintenance Organizations To provide an open forum for the continued development and maintenance of the LEAP protocols, Neda has estab- lished a public organization for each protocol. The ESRO and EMSD protocols are maintained, re- spectively, by ESRO.org at http://www.esro.org/, and by EMSD.org at http://www.emsd.org/. Each of these organizations allows public review of the respective protocol, and provides mechanisms for en- hancement of the protocol as a result of collective expe- rience. Any interested person may participate in the further development of the protocols. Participation in the devel- opment process is entirely open and non-exclusive; there are no membership fees. 2.8 LEAPing over WAP A set of specifications called the Wireless Application Protocol, or WAP, exists already, and purports to do the same things that LEAP does. However, the WAP speci- fications are entirely unfit for their claimed purpose, and are doomed to technological and political failure. A de- tailed criticism of WAP and justification of these state- ments is provided in an article called The WAP Trap [66 ] within The LEAP Manifesto. LEAP is an alternative to WAP, that does in fact what WAP does only in fiction. For a point-by-point compari- son of LEAP to WAP, see the article entitled LEAP: One Alternative to WAP [64 ] within The LEAP Manifesto. Those characteristics of WAP that make it wholly un- fit to be the industry standard are summarized in Table _ _ ___ ___ ____ _____ _____ ______ _______ _______ _______ _______ ________ ________ ________ _________ _________ __________ ___________ ___________ ____________ ____________ _____________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ___________________ 2.9.__A_BRIEF_HISTORY_OF_LEAP_____________ 33 _________________ ____________________ ______________________ WAP ______ * * LEAP _____ ___________ _______Subject_to_known_patent_restrictions________ Pat_____e* *nt-free _____ _______Self-published_by_the_WAP_Forum___________ Pub_____l* *ished as Internet RFCs _____ _______Revisions_subject_to_change_without_notice_______ All_____r* *evisions permanently fixed _____ _______Maintained_by_the_WAP_Forum_____ Mai_____n* *tained by open working groups _____ ________ Re-invention of existing protocols Efficienc* *y-optimizing extensions to existing _______ _________________ protoco__* *_______ls _________ ______ Tailored to mobile phone user interface char- User inte* *rface independent ______ ___________acteristics______ __* *_______ _________ _______Inherent_security_vulnerability____ Imp_____o* *ses no security assumptions _____ _______Inconsistent_protocol_number_assignment_ Con_____s* *istent protocol number assignment _____ _______Poor_technical_design_ Goo_____d* * technical design _____ _______Initial_focus: web browsing Ini_____t* *ial focus: messaging _____ ______ Treats wireless as a special case Tre_____a* *ts wireless as an extension of Internet _____ Table 2.1: WAP versus LEAP 11.1, along with the corresponding characteristics of the LEAP protocols. 2.9 A Brief History of LEAP LEAP originated in 1994 as part of the research and de- velopment initiatives of McCaw Cellular's wireless data group (now AT&T Wireless Services). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS net- work also. By 1996 McCaw Cellular was fully committed to pag- ing, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless message transport and delivery system. Neda Communications, Inc., an independent consulting com- pany working under contract to McCaw Cellular, played a significant role in the development of the required sys- tem. Neda Communications had also been involved from the outset in the development of the CDPD specification. In 1997 however, soon after the purchase of McCaw Cellular by AT&T Wireless, the latter company aban- doned the wireless messaging project. Prior to this event, Neda had secured from AT&T the necessary rights to continue independent development of the protocols. There- fore, recognizing the eventual future need for these pro- tocols, Neda then undertook to continue development of them independently of AT&T. They were eventually com- pleted by Neda, published as RFCs, and now form the 34CHAPTER 2. OVERVIEW OF THE LEAP PROTOCOLS basis of the LEAP protocols. Prior to abandoning wireless messaging, AT&T Wire- less Services invested several million dollars in related development work. In creating LEAP, therefore, Neda was able to build upon a large abandoned investment by AT&T Wireless. Chapter 3 The LEAP Protocol Development Model 3.1 Introduction Protocols come in all shapes and sizes, and from a variety of sources. Some are proprietary, intended for use exclu- sively by their developer. Others may be "open" in some sense, indicating that they are intended for more general, public usage. In this context, the word "open" can mean any one of several different things. It may mean nothing more than that the protocol has been published by its de- veloper. The protocol may still be very tightly controlled: revision of the protocol may remain the exclusive right of the developer, the protocol may be protected by patent or copyright restrictions, and use of the protocol may re- quire a licensing agreement. This is a very narrow, and to our mind misleading, use of the word "open." At the other extreme, the protocol may be open to a very high degree of public accessibility: it can be pub- lished by an open mechanism such as RFC publication, undergo revision by means of public working groups, and be entirely free of usage restrictions. A protocol satis- fying all these criteria can be said to be "open" in the broadest sense. Protocols are often referred to as "open" to imply that they are open in a broad sense, whereas in fact they are open only in the narrowest sense. To a large extent, the character of a protocol is defined by the processes used to develop it. This article is about a particular set of protocols called called LEAP, or the Lightweight & Efficient Application Protocols. LEAP is a set of high-performance, efficient protocols intended for mobile and wireless applications. 35 36CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL The LEAP protocols are intended to be open in the absolutely broadest sense of the word; they are intended to be freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. The processes used to develop the LEAP protocols have been such as to ensure that they have these intended characteristics. In this article we describe the LEAP development pro- cess. In the next section we provide a general description of the various phases of development that a protocol may go through. Then in subsequent sections we describe the specific processes used for the LEAP protocols at each phase of development. In this article we also discuss the enormous economic influences that protocols can exert, and we point out the potential for corruption that inevitably accompanies this. We describe our general philosophy regarding protocol development, and we present what we consider to be the key principles which must be upheld in order to maintain protocol integrity in the face of corrupting influences. Fi- nally, we provide justification for some of the protocol development choices we have made which others may consider to be unconventional or controversial. 3.2 Protocol Phases of Development Over its lifetime, a protocol typically goes through a num- ber of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases: 1. Initial Development. A protocol may be initially developed in a variety of ways, e.g. by a standards organization, a private business, or the academic community. 2. Global Parameter Assignment. If necessary, global parameters must be assigned to the protocol, for example by the IANA. 3. Publication. If the protocol is intended for public usage, as opposed to exclusive in-house usage, then it must be made publicly available, for example by being published as an Internet RFC. 4. Patent-Freedom. If the developers of a protocol intend it to be patent-free rather than proprietary, then they must take appropriate steps to work to- wards a patent-free result. 3.2. PROTOCOL PHASES OF DEVELOPMENT 37 5. Industry Usage. The ultimate test of a protocol is whether or not it becomes widely accepted and implemented in the industry at large. This is an aspect of protocol evolution which is not under the direct control of its developer. 6. Maintenance and Enhancement. Protocols fre- quently undergo revision and enhancement as a re- sult of experience and/or changing industry require- ments. Depending on the intended character of the protocol, this may take place by closed and propri- etary processes, or by open and public ones. 7. Endorsement by a Standards Body. Once a pro- tocol has become accepted as an industry standard, it may receive the formal sanction of a standards body. Depending on its purpose, nature, and history, a pro- tocol may undergo some, all, or none of these phases. Also, a protocol may iterate through phases (3) to (7) multiple times, as it undergoes maturation via repeated revision and re-publication. In general, the developers of a protocol define and control the policy and processes to be applied to the pro- tocol at every phase of development except (5) and (7). The developers have no direct control of (5) at all, and only minimal influence over (7). The processes used at each phase of development de- termine the character of the resulting protocol. In the fol- lowing sections of this article we will describe the pro- cesses applied to the LEAP protocols at each phase of development except (5). 3.2.1 Initial Protocol Development The conception and early development of a protocol can take place in a variety of ways. A traditional source of In- ternet protocols is the IETF/IESG. Other sources of pro- tocols are private businesses, the academic community, or even a single individual. In the case of LEAP, initial development of the pro- tocols was carried out by Neda Communications, Inc., a private business. We believe that there is a tendency among established standards bodies to regard their own, officially sanctioned protocols as authoritative, while any other protocol is of questionable worth or validity. However, the history of protocol development does not support this view. Small 38CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL groups of individuals have created protocols with far-reaching consequences (e.g. the World Wide Web), just as es- tablished standards bodies have created protocols which failed to achieved industry acceptance. For this reason we do not regard any one source of protocols as necessarily superior to any other. 3.2.2 Global Parameter Assignment It may be necessary to assign global parameters to a pro- tocol. In the case of LEAP, the necessary UDP port assign- ments for ESRO and EMSD have been made through the IANA. 3.2.3 Protocol Publication If a protocol is intended to be an open protocol, as op- posed to an in-house or proprietary one, then it must be made publicly available. This can be accomplished in various ways; the protocol can be self-published by the developer, or it can be published through an independent agency such as the Internet RFC Editor. In common with other Internet protocols, the LEAP protocols have been published in the form of Internet RFCs [91 ], [5 ]. RFC publication provides a number of signifi- cant advantages: - World-Wide Access. RFC publication ensures world- wide access to the published protocol. There are numerous Web and FTP sites world-wide that carry the complete series of RFC documents - if a par- ticular site is busy or unavailable, a person seeking an RFC can simply go to another. - Unrestricted Access. A user may download an RFC publication completely freely, without incur- ring any legal restrictions whatsoever. All that is required to acquire the full text of an RFC is its number or title. There are no copying or other dis- tribution restrictions attached to RFCs. - Permanence. RFC publication is permanent. Even if the creator of a protocol should go out of busi- ness or otherwise become defunct, the RFC itself will remain in existence. - Stability. Once published, an RFC is fixed - it can- not undergo change. If a new revision of the stan- 3.2. PROTOCOL PHASES OF DEVELOPMENT 39 dard must be issued, this is handled by issuing the revision under a new RFC number. - Quality Assurance. The RFC Editor maintains publication quality control, and will decline to pub- lish a document which, in the Editor's opinion, falls below the required technical and/or editorial RFC standards. For these reasons, RFC publication is the traditional, mainstream publication mechanism for Internet protocols, and virtually all Internet-related protocols are published this way. RFC publication of the LEAP protocols ensures that they are freely, easily and permanently accessible to anyone who wishes to use them. 3.2.4 Patent-Freedom If a protocol is intended to be open rather than propri- etary, then the protocol developers may take steps to work towards a patent-free result. In the case of a public protocol, the presence of patented components within the protocol is very undesirable. A public protocol provides a well-defined interoperability specification for an industry, so that businesses and other organizations can create products and services indepen- dently, which can then be relied upon to function and in- teroperate correctly. The protocol is a positive, enabling force for the entire industry. In order for the protocol to play this role, anyone who wishes to implement and use it must be able to do so freely. The presence of patented components within the protocol places restrictions on its usage, and there- fore undermines this purpose. Furthermore, the presence of the patent brings an enormously unfair market advan- tage to the patent holder. By exercising his patent rights, the patent holder can gain financial benefit from compet- ing companies who wish to use the protocol, or can stifle competition altogether by denying the competing com- pany the right to use the protocol at all. Software patents thus pose a significant danger to pro- tocols. In some cases patents become included in proto- cols by accident - that is, without deliberate intentional- ity on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a proto- col, in an attempt to gain market advantage via ownership of the protocol. In either case, the protocol can then be held hostage 40CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL by the patent-holder, to the great disadvantage of anyone else who may wish to use it. Patented protocols thus have the effect of inhibiting free and open competition, and are therefore highly detrimental to the industry and the consumer. The LEAP protocols are intended to be fully open and without usage restrictions of any kind. We have therefore exercised great diligence throughout their development to ensure their patent-freedom. The Free Protocols Foundation Various mechanisms exist for working towards a patent- free result. In developing the LEAP protocols, we have adopted a set of procedures defined for this purpose by the Free Protocols Foundation. The Free Protocols Foundation, or FPF, is an indepen- dent, non-profit organization whose mission is to prevent the inclusion of patented components within protocols. The FPF has established a set of policies and procedures for protocol development that is designed to ensure, inso- far as this is possible, that the resulting protocol is patent- free. In general, there may be both an Author and a Work- ing Group involved in the development of a protocol. The Author is the company, organization or other entity that has primary responsibility for the protocol. In some cases, the protocol may also undergo development at the hands of a Working Group - a set of independent in- dividuals or companies who work cooperatively on the protocol, usually via public mailing lists. The FPF de- fines procedures for both Authors and Working Groups, allowing both to participate in the development of a pro- tocol, while still maintaining the patent-free character of the protocol. For example, both an Author and a set of Working Groups are involved in the development of LEAP. As noted above, the LEAP protocols were initially developed by Neda Communications, Inc., and this company contin- ues to take primary responsibility for their maintenance. In addition, as described in Section 3.2.5, continued en- hancement and revision of the protocols takes place by means of various Working Groups. Both the Author and the Working Group may wish to make public declarations regarding the patent-freedom of the protocol. The Author may wish to make an initial declaration that the protocol is intended to be patent-free; and the Working Group may wish to make a declaration 3.2. PROTOCOL PHASES OF DEVELOPMENT 41 that it operates according to the FPF Working Group pro- cedures, thereby maintaining the patent-free nature of the protocol. In addition to defining protocol development proce- dures, the FPF also acts as an independent, public forum in which Authors and Working Groups may make these declarations. Such declarations which are submitted to the FPF are published on its website. For complete information on the Free Protocols Foun- dation and its procedures, see the FPF website at http://www.FreeProtocols.org. LEAP's Adherence to the FPF Procedures Development of the LEAP protocols conforms in all re- gards to the processes and procedures of the Free Pro- tocols Foundation. LEAP's compliance with these pro- cesses ensures, insofar as this is possible, that the LEAP protocols are, and will remain, patent-free. We have adopted the FPF processes because they are available for use by any protocol developer, without the requirement that the developer be part of a formal stan- dards organization. Various standards organizations in- clude processes within their protocol development pro- cedures which work towards patent-freedom. In general, however, these patent-free processes are created for the standards organization's internal use, and are not avail- able for a protocol which is not officially sanctioned by the organization. The FPF, on the other hand, is entirely egalitarian, providing the same level of support for patent-freedom to any protocol developer. To our knowledge, the FPF is unique in this regard. Author's Patent-Free Declaration Neda Communications, Inc., the original Author of the LEAP protocols, has made a declaration to the FPF that the LEAP protocols are intended to be patent-free. This declaration includes statements to the effect that: - To the best of the Author's knowledge, the protocol is not subject to any patent restrictions. - It is the Author's intention to maintain the protocol patent-free. - In the event that the Author becomes aware of any patent restrictions relating to the protocol, or if a 42CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL patent right assertion is made with respect to the protocol, the Author undertakes to make prompt disclosure of this fact to the FPF. The complete text of the declaration can be seen on the FPF website at http://www.FreeProtocols.org. 3.2.5 Maintenance and Enhancement Protocols are usually not static, but instead typically un- dergo continued revision and enhancement. Depending on the character of the protocol, this may take place by closed, in-house processes, or by open and public ones. Since LEAP is intended to be a fully open protocol, it is maintained by fully open processes. Open Maintenance Organizations The LEAP protocols are developed and maintained through a set of public organizations. At present there are three of these: - LeapForum.org. The LEAP Forum is a central clearing-house for information and pointers relat- ing to the LEAP protocols in general. For com- plete information, visit the LEAP Forum website at http://www.leapforum.org/. - ESRO.org. ESRO.org is an open organization for the development and maintenance of the ESRO pro- tocol. For complete information, visit the ESRO website at http://www.esro.org/. - EMSD.org. EMSD.org is an open organization for the development and maintenance of the EMSD protocol. For complete information, visit the EMSD website at http://www.emsd.org/. Additional maintenance organizations are expected to be created as the LEAP protocol family grows. None of these are standards organizations. They are simply forums to allow information exchange and coop- erative effort relating to the LEAP protocols and technol- ogy. Participation in these organizations takes place via various mailing lists which are hosted by each organiza- tion. Any interested company, organization or individual may participate by joining one or more of these mailing lists. Neither the organizations nor their mailing lists have 3.2. PROTOCOL PHASES OF DEVELOPMENT 43 any membership structure; nor does participation require any membership fees or other financial obligation. For more information, and to subscribe to one or more mailing lists, visit the How To Participate area at any of the above websites. Working Groups In particular, ESRO.org and EMSD.org each host a Work- ing Group mailing list. It is through the Working Group mailing lists that active development of the protocols takes place. Anyone may participate in the development of the ESRO and EMSD protocols by subscribing to the corre- sponding Working Group mailing list. To subscribe to the ESRO Development Working Group mailing list, visit http://www.esro.org/joinESROmailingList/esroSpec.html. To subscribe to the EMSD Development Working Group mailing list, visit http://www.emsd.org/joinEMSDmailingList/emsdSpec.html. This open development process ensures that commen- tary and participation is open to any industry constituency that may be affected by the LEAP protocols. Maintaining Patent-Freedom Since the LEAP protocols are intended to be patent-free, the Working Groups must function in a way which pre- serves their patent-freedom. All LEAP protocol Work- ing Groups therefore conform fully to the Free Protocols Foundation policies and procedures for Working Groups. These procedures ensure, insofar as possible, that a proto- col remains patent-free despite undergoing collective de- velopment by a public Working Group. For more infor- mation, refer to the FPF website at http://www.FreeProtocols.org. All Working Group contributors are required to ad- here to these procedures. The Working Group imposes adherence to these procedures by requiring that all con- tributors agree to them as a condition of participation. Both the ESRO Development Working Group and the EMSD Development Working Group have made declara- tions to the FPF that they conform fully to its patent-free policies and procedures. The text of these declarations can be seen on the FPF website. 44CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL 3.2.6 Endorsement by a Standards Body The ultimate arbiter of any particular protocol is the in- dustry itself, in which a multitude of individual decisions leads to the acceptance or rejection of the protocol. The acceptance of a protocol as a standard is therefore some- thing that occurs independently of formal endorsement by a standards body. Standards organizations such as the IETG/IESG cer- tainly have no monopoly on innovation, creativity, or com- petence. Any company, organization or individual is ca- pable of creating protocols that become successful, far- reaching industry standards, without the sponsorship or sanction of a standards body. For example HTTP, the protocol which forms the ba- sis of world-wide Internet communications, was devel- oped and achieved prominence entirely independently of any formal standards body. The same is true of Pretty Good Privacy (PGP), now a world-wide encryption stan- dard. These and many other protocols became industry standards despite lack of any official endorsement. For these reasons we believe that official endorsement of a protocol as a standard has little meaning, and that genuine legitimacy for a protocol derives from its indus- try usage. We therefore have no immediate plans to sub- ject the LEAP protocols to any formal standards track process. If and when they become widespread within the industry, we may at that time place them on standards track and seek their formal endorsement as a standard. 3.3 Economic Consequences of Pro- tocols In general, protocols are a positive, enabling force for an industry. Protocols define an agreed-upon expected be- haviour, allowing businesses to create products and ser- vices independently of one another, which can then be relied upon to interoperate correctly. It may happen that one or more rival protocols arise, which address more or less the same industry need. Un- der these circumstances the rival protocols will effectively compete with one another, just as products and services do. It is usually most beneficial to the industry for there to be a single commonly-accepted protocol, so it is often the case that one protocol eventually displaces all others, thereby becoming an industry "standard." In the early stages of formation of a new industry, this 3.3. ECONOMIC CONSEQUENCES OF PROTOCOLS45 competition among protocols is of great benefit to the in- dustry. As in the case of products and services, compe- tition is a mechanism for selection of the best. Free and open competition allows the success or failure of proto- cols to be determined on the basis of their merits, and their fitness to serve the overall interests of the industry. In an ideal world, the success of protocols would be determined exlusively on this basis. However, this is not an ideal world, and forces can arise which interfere with the free and fair competitive process. In particular, the adoption of a protocol by an industry can have enormous economic consequences. And where there is money, there is the potential for corruption. Businesses may attempt to exercise control over pro- tocols in various ways. During protocol development, they may seek to introduce patented components into the protocol, that they can subsequently exploit to their ad- vantage. They may seek to control the protocol publi- cation process, thereby allowing them to impose copy- right restrictions on the protocols, or even make unilat- eral, unannounced changes to the protocol specifications. They may develop and/or maintain the protocol by means of closed, exclusionary processes, which deny broad tech- nical review of the protocol, and allow its design to be dictated by minority business self-interests. 3.3.1 Principles for Maintaining Protocol In- tegrity We believe that there are three basic, fundamental prin- ciples for defending against these sorts of underhanded activities. These are: - Patent-freedom - RFC publication - Maintenance by open organizations Each of these provides a vital assurance of protocol integrity. Patent-freedom ensures that a patent-holder can- not subvert free-market competition among products and services based on the protocol. RFC publication ensures that the protocol is freely available to anyone who wishes to use it. And maintenance by open organizations ensures that development of the protocol takes place by demo- cratic, rather than oligarchic, processes. This trilogy of principles represent the most basic guar- antees of the integrity of a protocol. If any one of these 46CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL things is missing, then this means that some attempt is being made to control or limit access to the protocol. In the case of a public protocol, there is no valid reason for doing this. 3.4 Standards Organizations: Do They Mean Anything? In addition to its general, industry-wide economic bene- fits, the adoption of a protocol also brings a unique set of benefits to its developer. These benefits consist of name recognition, and first-mover advantages in terms of de- velopment and sales of services and products based on the protocol. There may also be other significant bene- fits, such as those resulting from ownership of software patents related to the protocol. These benefits can result in a huge financial windfall for the protocol developer. For this reason, the devel- oper has an enormous vested interest in the adoption of his protocol in preference to any others. And this may lead the developer to promote his protocol in ways which subvert the free and fair competitive process among pro- tocols. One of the ways a business may do this is by seeking to exert inappropriate influence or control over the activities of standards organizations. In particular, the developer may seek to have his protocol labelled as a "standard," while denying this label to other protocols. Alternatively, a business or group of businesses may form their own "standards organization" as an exclusive pro- motional vehicle for their own protocol. In either case the standards organization is in effect in the pocket of Big Business, and their discriminatory labelling of their own protocol as a "standard" represents another form of corruption. Though this serves the self-interest of the developer, it is likely to cause the industry to adopt the "wrong" protocol - i.e. not the one that best serves its overall needs. This is enormously detrimental to the in- dustry at large and the consumer. The incentives for businesses to indulge in these un- derhanded tactics is in direct proportion to the size of the industry and the financial stakes. And in the wireless data communications industry, the stakes are very high indeed. As a result of this, we are currently seeing an enor- mous amount of standards-related activity in the wire- less arena. Since 1998 a large number of self-proclaimed standards organizations relating to wireless data have been created, are claiming legitimacy, and are attempting to impose their own protocols on the industry. Among these 3.4. STANDARDS ORGANIZATIONS: DO THEY MEAN ANYTHING?47 recently-formed groups are: - Wireless Application Protocol (WAP) Forum - Mobile Internet Phone Services (MIPS) Forum - Global Mobile Commerce Forum (GMCF) - CDMA Development Group (CDG) - Universal Wireless Consortium (UWC) - GSM Alliance - Global TDMA Forum - Mobile Data Initiative - Portable Computer & Communications Association (PCCA) Each of these organizations is an independent entity, with its own claim of legitimacy, its own protocol pub- lication mechanism, and its own set of restrictions and limitations on participation. Beyond the realm of specific wireless subnetworks, there is no reasonable need for this large number of independent standards organizations. Many of these organizations are simply an instrument of Big Business. They are the result of a group of busi- nesses forming an industry association or forum, for the purpose of branding their own protocol as a "standard." At best, this labelling of some protocols but not oth- ers as "standards" is meaningless; it is a semantic shell game. And at worst, this labelling is an attempt by Big Business to market one set of protocols in competition with another. Marketing has its place in the promotion of a company's own products and services. But an industry protocol represents a public trust, and business marketing has no place in this arena. We believe that the ultimate criterion of the legiti- macy of a protocol is its acceptance and usage in the in- dustry at large. And the industry at large is entirely capa- ble of establishing its own winners and losers by means of free and fair competition among protocols. This arbitrary standards labelling serves only to corrupt this competitive process. Our philosophy regarding protocol development re- quires only that the developer make sure that he adheres to the basic trilogy of principles described above. Beyond that, free and fair competition will do the rest. By making it clear that these self-promoting consor- tia have no genuine legitimacy, we seek to reduce their influence and the harm they do to the industry. 48CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL 3.5 Our Independence of the IETF We are developing the LEAP protocols independently of the IETF, and we have not sought out their formal en- dorsement by the IETF. Our decision to work independently of the IETF is a result of our previous experiences with IETF. Based on our interactions with the IETF, we have concluded that the illegitimate influence that the IESG and the IAB exert over non-IETF protocol specifications is counterproduc- tive. We believe that the IESG and IAB are both prej- udiced against externally-generate protocols (a frame of mind sometimes referred to as Not Invented Here syn- drome), and that they engage in the active supression of competing protocols which originate outside their own domain. The IETF has become an autocratic organization that acts to suppress innovation rather than encourage it. In- deed, on its own mailing lists, the IETF acronym has been referred to as the "Innovation Extermination Task Force," and the IETF/IESG/IAB has been referred to as a "cult." We do not consider either of these characterizations as being in the least inappropriate. Our conclusion is that Big Business and political in- terests have now taken over the critical decision making processes within the IETF/IESG/IAB. We have come to this conclusion after many years of attempting to work within the system to bring the IETF back to it its original intended purpose. Our interactions with the IETF relating to several issues are publicly available: - The complete record of our communications with the IESG and RFC Editor relating to publication of RFC-2188 is available at http://www.esro.org/communicationRecord/index* *.html. - The complete record of our communications with the IESG relating to the IESG invitation to place RFC-2188 on standards track is available at http://www.esro.org/noStdT* *rack/main.html. - Our complaint regarding the delays in publication of RFC-2188 is available at http://www.esro.org/iesgNote/index.html. - The complete record of our communications with the IESG and RFC Editor relating to publication of RFC-2524 is available at http://www.emsd.org/communicationRecord/index* *.html. Based on the above records we have come to the con- clusion that the IESG is now characterized by irresponsi- bility, incompetence and arrogance. 3.5. OUR INDEPENDENCE OF THE IETF 49 3.5.1 Do We Need the IETF? We believe that a lesser IETF will be a better IETF. The IETF has been a source of new protocols in the past, and there is no reason why it cannot continue to create and develop new protocols in the future. But traditionally, the scope of IETF has gone far be- yond this; the IETF has also claimed responsibility for judging, labelling and ratifying protocols. We believe that these IETF functions are unnecessary and inappro- priate. All the functions that the IETF claims to provide can be accomplished by means of: - The Free Protocols Foundation - The RFC publication process - Maintenance by open Working Groups - Free and fair competition among protocols The first three items above are sufficient to ensure that a protocol is patent-free, is freely available, and is open to democratic and egalitarian development processes. And the fourth item above provides a more than ad- equate mechanism for determining which protocols be- come enduring industry standards, and which fall by the wayside. So what positive thing can the IETF offer that is not better provided elsewhere? The answer is: not much. We have no objection to the IETF existing as an en- tity, developing protocols, and making them available for use. What we demand is that other protocols have exactly the same opportunities as those of the IETF. These consist of the opportunity to be made public, and the opportunity to be judged by means of open competition, and on the basis of their merits. What we object to most strenuously, is the IETF/IESG/IAB arrogating to itself the power to quash protocols that it considers to be in competition to its own. This is not the job of the IETF/IESG/IAB; this is the job of fair compe- tition. We believe that the collective intelligence and exper- tise of the Internet technical community is adequate pro- tection against widespread adoption of "wrong" proto- cols, and we believe that the market and the consumer can collectively make the right eventual decisions. The actions of irresponsible entities such as IESG and IAB, claiming illegitimate authority to select winners and losers 50CHAPTER 3. THE LEAP PROTOCOL DEVELOPMENT MODEL at the time of initial publication of protocols, on the pre- text of protecting the network and the consumer, in fact does more harm than good. Chapter 4 Free Protocols Foundation Policies and Procedures 4.1 Introduction 4.1.1 The Patent Debate At the time of writing, there is an on-going debate within the software industry regarding software patents. Like many others within the industry, at the Free Protocols Foundation we regard the historical tradition of patents as being entirely inappropriate for software. We consider software patents to have the effect of in- hibiting free and open competition within the software industry, and to be extremely detrimental to the industry and the consumer. A complete discussion of the software patent issue is outside the scope of this document. For more information on this subject see [1 ] or [2 ]. 4.1.2 How Patents Affect Protocols Patents are applied to software, not to protocols. It is not possible to patent a protocol; in general only a process or an algorithm can be patented. However, a protocol may include a patented algorithm as an integral part of its specification. In this case, any software implementation of the protocol requires the use of patented software. That is, a patented process is an inherent part of the protocol. Even if a protocol does not explicitly decree the use of a specific patented software process, it may still be the 51 52CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES case that any practical implementation of the protocol re- quires the use of patented software components. The pro- tocol could in principle be implemented in a way which avoids the use of patented software; in practice, however, the result would be a significantly inferior implementa- tion, for example in terms of efficiency. In either case, the protocol effectively implies the use of patented software. We will refer to any such protocol as a patented protocol. That is, a patented protocol is any protocol whose practical implementation requires the use of patented software components. We will use the term patent-free protocol, or just free protocol, to refer to a protocol which is function- ally free from software patents. By "functionally free from software patents," we mean either that the proto- col is truly free from patents, or if the protocol does im- ply the use of patented software, that the patent-holder has granted non-restrictive rights to include the patented software components in implementations of the protocol. In either case, the result is that the protocol can be freely implemented and used by anyone, without encoun- tering significant restrictions. 4.1.3 Difficulties Relating to Software and Protocol Patents Because of the current state of affairs regarding software patents, it is no longer possible to be absolutely certain that any particular protocol is patent-free. Whether or not a new invention or technology violates any existing patents has traditionally been determined by means of a patent-search - a direct search and examination of all relevant pre-existing patents. In the case of a physical technology, this yields a more or less definitive answer as to whether or not the technology violates any existing patents. In the case of software, however, it is not possible to answer this question with the same degree of certainty. The basic reason for this lies in the very high degree of subtlety and complexity of modern software systems. A software system may contain hundreds or thousands of individual software constructs, any one of which may po- tentially violate an existing patent. Furthermore, it is very difficult to establish a taxonomy of existing soft- ware patents. A taxonomy is required to guide the patent- search process - the taxonomy defines which patents are "related" to the technology under search. Without a well- defined and meaningful taxonomy, it is not possible to 4.1. INTRODUCTION 53 define an appropriate scope of search. In other words, a software system may contain a small universe of software constructs. Meanwhile, the Patent and Trademark Office has established a small universe of software patents. Unfortunately, there is no way to establish with certainty, that none of the elements of one universe also reside in the other universe. To make matters worse, there can be room for dispute regarding whether or not a particular software construct violates a particular patent. The patent-holder may claim that it does, while the software developer claims that it does not. If the two parties are unable to come to agree- ment, the issue can only be resolved in the courts. Finally, because of the delay between a company fil- ing a patent application and the granting of the patent by the PTO, it is entirely possible for a company to conduct a software patent-search with negative results, only to dis- cover subsequently that a patent has been granted after- the-fact, which now places its software in violation. For all these reasons, it has now become essentially impossible to establish with certainty that a particular piece of software is, and will remain, truly patent-free. Like- wise, it has become impossible to establish with certainty that a particular protocol is, and will remain, patent-free. 4.1.4 Terminology Legal rights such as patents and copyright are sometimes referred to collectively as "Intellectual Property Rights." Although this is a very commonly used term, we will avoid using it in this document. Along with other authors, we object to the use of this term on the grounds that it blurs the distinction be- tween intellectual items and material ones. The law al- lows ownership rights to be asserted with regard to both types of item, and therefore both may be considered in some sense to be "property." However, we regard intel- lectual entities such as software and protocols to be fun- damentally different in nature to material items, and wor- thy of entirely different legal treatment relating to ques- tions of ownership. For more discussion about this point, see [3 ]. Where necessary, we will use explicit terms such as "patent," or "copyright," to refer to legal rights relating to intellectual constructs. 54CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES Definitions Throughout this document, we will use the following terms with the meanings indicated: - Truly Patent-Free Protocol. A protocol that can be implemented in the form of entirely patent-free software. A Truly Patent-Free Protocol contains no limitations whatsoever on its dissemination and use, and may be freely implemented by anyone, without restriction. - Functionally Patent-Free Protocol. A protocol for which there are either no known software patent restrictions, or where software patent restrictions are known to exist, non-restrictive usage rights have been obtained from the patent-holder. - Free Protocol Specification. A protocol that con- forms to the policies and procedures of the Free Protocols Foundation relating to patents, copyright, and confidentiality. These procedures are set forth in Section 4.6. - Declared Patent-Free Protocol. A protocol for which a declaration has been made, to the Free Pro- tocols Foundation, that it conforms to the proce- dures of Section 4.6. - Author of a Protocol. The individual, company or organization, or the set of individuals, companies or organizations, who are responsible for the cre- ation, development, maintenance, or enhancement of the protocol specification. - Working Group. An open-ended set of individu- als or organizations who collectively work towards the creation, development, maintenance, or enhance- ment of the protocol specification. - Free Protocol Development Working Group. A Working Group which has voluntarily elected to adhere to, and be bound by, the policies and proce- dures of the Free Protocols Foundation regarding patent-freedom. - Free Protocol Developer. A contributor to a Free Protocol Development Working Group. 4.1.5 About the Free Protocol Processes and Procedures This document establishes a set of policies and proce- dures for protocol development that is designed to en- 4.1. INTRODUCTION 55 sure, as far as this is possible, that the resulting protocol is functionally patent-free. The purpose of these proce- dures is to create a resulting protocol that is either free from patent restrictions, or for which non-restrictive us- age rights have been obtained from the patent-holder. These procedures are set forth in Section 4.6. The procedures of Section 4.6 are based on a similar set of procedures defined by the IESG (Internet Engineer- ing Steering Group). Specifically, the FPF procedures are an extension of Section 10, Intellectual Property Rights, of RFC 2026, The Internet Standards Process - Revision 3 [17 ]. That section defines the procedures to be followed by the IETF (Internet Engineering Task Force) relating to patent-freedom. However, the scope of RFC 2026 is largely limited to the needs of the IESG itself; in partic- ular, the patent-related procedures of Section 10 of RFC 2026 are limited to standards-track documents and other IETF-specific purposes. Thus, while these patent proce- dures may be entirely adequate for the needs of the IETF, they are not adequate to dealing with patent-freedom in a more general setting. The processes and procedures in Section 4.6 of this document are therefore an extension of the RFC 2026 procedures, designed to address the need for patent-freedom procedures in general. They are intended to be a set of general-purpose processes which can be adopted by any protocol development organization. 4.1.6 About this Document This document is available in several alternative formats at Free Protocols Foundation website (http://www.freeprotocols.org/freeProtocolProcess): - 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. 56CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES - Text Only: Provides the document in text-only for- mat. 4.2 The Protocol Development Pro- cess Protocols come in all shapes and sizes, and from a variety of sources. Some are proprietary, intended for use exclu- sively by their developer. Others may be "open" in some sense, indicating that they are intended for more general, public usage. In this context, the word "open" can mean any one of several different things. It may mean nothing more than that the protocol has been published by its de- veloper. The protocol may still be very tightly controlled: revision of the protocol may remain the exclusive right of the developer; the protocol may be protected by patent or copyright restrictions; and use of the protocol may re- quire a licensing agreement. This is a very narrow, and to our mind misleading, use of the word "open." At the other extreme, the protocol may be open to a very high degree of public accessibility: it can be pub- lished by an open mechanism such as RFC publication; undergo revision by means of public working groups; and be entirely free of usage restrictions. A protocol satis- fying all these criteria can be said to be "open" in the broadest sense. Protocols are often referred to as "open" to imply that they are open in a broad sense, whereas in fact they are open only in the narrowest sense. Also, protocols can have widely differing periods of industry tenure. Some protocols never achieve widespread acceptance and usage, or else have very short lifetimes before becoming obsolete or being eclipsed by compet- ing protocols. Other protocols become highly successful, and persist as long-term industry standards. 4.2.1 Phases of Development Over its lifetime, a protocol typically goes through a num- ber of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases: 1. Initial development. 2. Global parameter assignment. 3. Publication. 4. Patent-free declarations. 4.2. THE PROTOCOL DEVELOPMENT PROCESS 57 5. Industry usage. 6. Maintenance and enhancement. 7. Endorsement by a standards body. Depending on its purpose, nature, and history, a pro- tocol may undergo some, all, or none of these phases. Also, a protocol may iterate through phases 3 - 7 mul- tiple times, as it undergoes maturation via repeated re- vision and re-publication. As described later, the Free Protocols Foundation plays a role in only two of these phases. For completeness, however, in the following sec- tions we provide a brief description of each phase, along with commentary on the FPF's philosophy regarding the protocol development process. Initial Protocol Development The conception and early development of a protocol can take place in a variety of ways. A traditional source of In- ternet protocols is the IETF/IESG. Other sources of pro- tocols are private businesses, the academic community, or even a single individual. We believe that there is a tendency among established standards bodies to regard their own, officially sanctioned protocols as authoritative, while any other protocol is of questionable worth or validity. However, the history of protocol development does not support this view. Small groups of individuals have created protocols with far-reaching consequences (e.g. the World Wide Web), just as es- tablished standards bodies have created protocols which failed to achieved industry acceptance. At the Free Protocols Foundation, we do not regard any one source of protocols as necessarily superior to any other. We believe that any coordination of activities can generate useful protocols, and we are ready to provide the same support for patent-freedom regardless of the initial source of the protocol. Global Parameter Assignment If necessary, global parameters must be assigned to the protocol, e.g. by the IANA. The Free Protocols Founda- tion plays no role in this process. Protocol Publication If the protocol is intended to be an open protocol, as op- posed to an exclusively proprietary one, then it must be 58CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES made publicly available. This can be accomplished in various ways; the protocol can be self-published by the developer, or it can be published through an independent agency such as the Internet RFC Editor. Ideally, the protocol should be published in a way which allows permanent and unrestricted access to the protocol by anyone wishing to implement it. In the case of Internet protocols, this is usually accomplished by RFC publication. Patent-Free Declarations Depending on their intentions, the developers of a proto- col may take steps to work towards a patent-free result, and they may wish to make certain declarations to that effect. In general, there may be both an Author and a Work- ing Group involved in the development of a protocol. The Author is the person, company, or other entity that has primary responsibility for the protocol. In some cases, the protocol may also undergo development at the hands of a Working Group - a set of independent individuals or companies who work cooperatively on the protocol, usually via public mailing lists. Both the Author and the Working Group may wish to make declarations regarding the patent-freedom of the protocol. The Author may wish to make an initial dec- laration that the protocol is intended to be patent-free. As described later in this document, it is not possible to make an absolute guarantee that a protocol is, and will remain, completely patent-free. The best an Author can do is make a good-faith declaration that: - To the best of his knowledge the protocol is not sub- ject to any patent restrictions. - It is the Author's intention to maintain the protocol patent-free. - If any patent restrictions relating to the protocol be- come known to the Author, he will make prompt disclosure of this. Similarly, the Working Group may wish to make a declaration that: - The protocol has been developed in such a way as to ensure that no patented components have been intentionally introduced into the protocol. 4.2. THE PROTOCOL DEVELOPMENT PROCESS 59 - If any patent restrictions relating to the protocol be- come known to the Working Group, it will make prompt disclosure of this. One of the roles of the Free Protocols Foundation is to provide a public forum in which such declarations can be made. Any such declaration which is submitted to the FPF will be published on our website at http://www.FreeProtocols.org. Examples of previously submitted declarations may be seen at that location. Industry Usage The ultimate test of a protocol is whether or not it be- comes widely accepted and implemented in the industry. If a protocol is largely unused, or eclipsed by a competing protocol, then it is largely irrelevant. Maintenance and Enhancement Protocols are usually not static, but instead typically un- dergo revision and enhancement in response to experi- ence and/or changing industry requirements. Depending on the intentions of the Authors, this may take place by closed and proprietary processes, or by open and public ones. In the case of a truly open protocol, the develop- ment process should allow commentary and participation by all the constituencies that are affected by the protocol. In some cases, continued development and enhance- ment of the protocol is accomplished by means of a pub- lic Working Group. Also depending on the Authors' in- tentions, the Working Group may function in a way which preserves the patent-freedom of the protocol, and the Work- ing Group may wish to make a declaration to this effect. Two things are required in order to achieve these goals. First, the developers must establish and follow a set of Working Group operating procedures that will have the effect of preserving the patent-freedom of the protocol. Second, the developers must make a public declaration that the Working Group follows these procedures. A developer can achieve both of these things without the assistance of the Free Protocols Foundation. The de- velopment organization can establish its own set of Work- ing Group operating procedures, and can independently announce that the Working Group follows them. However, the Free Protocols Foundation provides a means of accomplishing these things which is external to, and independent of, the development organization itself. 60CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES It is for this purpose that the FPF primarily exists. First, the FPF defines a clear and unambiguous set of Working Group processes and procedures which ensure, as far as possible, that the resulting protocol will remain function- ally patent-free. Any development organization is free to adopt these procedures with regard to its own protocol. Second, the FPF provides an external forum in which the developer may declare publicly that its Working Group follows these procedures. The FPF Working Group procedures are designed to: - Ensure that no patented components can be inten- tionally introduced into the protocol as a result of the Working Group activities. - Provide remedies in the case of unintentional in- troduction of patented components into the proto- col. These remedies consist of prompt publication of the fact of the patented component, and an at- tempt to secure non-restrictive usage rights from the patent holder. Endorsement by a Standards Body The ultimate arbiter of protocols is the industry itself, in which a multitude of individual decisions leads to the ac- ceptance or rejection of any particular protocol. The ac- ceptance of a protocol as a standard is therefore some- thing that occurs independently of formal endorsement by a standards body. Nevertheless, once a protocol has become accepted as an industry standard, it is often the case that it receives the formal sanction of a standards body. 4.2.2 Role of the Free Protocols Founda- tion It is sometimes the case that many of the above phases of development take place under the direction of a single institution, or a group of tightly coupled institutions. For example, when developing protocols the IETF/IESG/IAB traditionally claims authority for all aspects of develop- ment except for (5), over which, of course, it has no direct control. At the Free Protocols Foundation, we consider it un- desirable to place control of multiple aspects of the de- velopment process in the hands of any single institution. First, this can include built-in conflicts of interest. For 4.2. THE PROTOCOL DEVELOPMENT PROCESS 61 example, if a standards body is responsible both for de- veloping protocols and publishing industry protocols, the body may be inclined to favor publication of its own pro- tocols in preference to competing protocols from other sources, or it may be inclined to place inappropriate com- mentary within competing protocols. The IETF/IESG has a history of doing both of these things. As another example, if the Maintenance and Enhance- ment responsibility is closely-held by a developing com- pany or group of companies, this process may be biased in favor of the companys' interests, rather than those of the industry at large. Furthermore, a large spread of responsibility within a single institution can lead to bureaucratization of its activ- ities; the energy of the organization can become directed towards maintaining its internal bureaucracy, rather than serving the needs of its consumers. In other words, the institution can become authority oriented, as opposed to responsibility oriented. The historical evolution of the IETF/IESG/IAB is a classic example of this. For these reasons, the Free Protocols Foundation is in favor of decoupling, as much as possible, the responsi- bility for the various aspects of development. A separa- tion of powers greatly lessens the potential for conflicts of interest. Furthermore, an organization with limited re- sponsibility can be discarded, reformed, or replaced more easily than one with very broad responsibility. Separation of powers thus provides a greater degree of choice, and therefore competition, within the protocol development process. The Free Protocols Foundation is therefore in favor of placing responsibility for the various phases and aspects of development in the hands of independent organizations with limited agendas. We favor delegating the Protocol Publication phase to a truly independent third-party en- tity, such as the Internet RFC Editor. We favor handling the Maintenance and Enhancement phase by means of a variety of truly open public working groups, not just the IETF. Both of these steps ensure unbiased processing of the protocol. In the same spirit, we favor placing responsibility for working towards patent-freedom in the hands of an in- dependent organization. It is primarily for this reason that the Free Protocols Foundation exists. The role of the Free Protocols Foundation is to place those aspects of the protocol development process which relate to patent- freedom in a common, central, public location. The var- ious other aspects of the development process have been described only to place the role of the FPF in its proper 62CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES context; the FPF plays no role in those aspects. In our model of the protocol development process, the scope of FPF activities is limited to two items exclu- sively: - (4) Patent-free declarations, and - (6) Maintenance and enhancement, and the Free Protocols Foundation has no agenda other than this. Note that the role played by the FPF regarding pro- tocol patents is somewhat analogous to the role played by the RFC Editor regarding protocol publication. RFC publication provides a means of publishing, via an inde- pendent agency, Internet protocols which have been pro- duced by a variety of sources. Similarly, the FPF represents a means of dealing with patent issues by an independent agency. Hitherto, this re- sponsibility has been taken by multiple standards bodies, each of which has been obliged to define its own pro- cesses and procedures relating to patents. By adopting the FPF procedures, a standards body or development or- ganization can make use of a set of general services es- tablished by an external agency. 4.2.3 Coordination of Activities As noted in the previous section, the FPF is in favor of distributing responsibility for the various aspects of pro- tocol development, rather than consolidating all these as- pects under the umbrella of a single organization, such as the IETF. The objection may be made, that this distribution of responsibility creates coordination difficulties. It can be argued that vertically-integrated organizations like the IETF play a valuable role in terms of coordination of activities, and that it is more difficult to coordinate the activities of multiple independent organizations. In particular, it can be said that the IETF assists in the logical and or- derly development of multiple protocols, by establishing a common architecture and structure for sets of related protocols. However, we believe that this objection is unfounded. It has been well demonstrated, for example by the de- velopment of Linux, that multiple independent entities can coordinate their development efforts extremely effec- tively. In any event, the advantages to be gained from a separation of powers certainly exceed the drawbacks. 4.3. THE FREE PROTOCOLS FOUNDATION 63 4.3 The Free Protocols Foundation 4.3.1 General Philosophy At the Free Protocols Foundation, we consider that patented protocols are very undesirable. A protocol is a general agreement within an industry that things will be done in a certain way. It represents an agreed-upon expected be- havior, providing common ground for cooperation among a variety of disparate entities: private businesses, aca- demic institutions, government, and individuals. The pro- tocol allows any of these entities to create products, ser- vices, applications, etc., and provides the necessary as- surances that these offerings will function and interop- erate in a well-defined way. The protocol is a positive, enabling force for the entire industry. In order for the protocol to play this role, anyone who wishes to implement and use it must be able to do so freely, and without restrictions. The presence of patented components within the protocol places restrictions on its usage, and therefore serves only to undermine this pur- pose. Furthermore, the presence of the patent brings an enormously unfair market advantage to the patent holder. By exercising his patent rights, the patent holder can gain financial benefit from competing companies who wish to use the protocol, or can stifle competition altogether by denying the competing company the right to use the pro- tocol at all. We have no objection to companies seeking market advantage by means which benefit the consumer and the industry. Such means include the creation of superior products and services, or the exercising of legitimate patents on physical processes. But we strenuously object to the seeking of market advantage by attempting to lay claim to the protocol itself. The presence of a patent within a protocol is at best absurd, pointless, and self-defeating. And at worst, it rep- resents an attempt by corrupt business interests to gain market advantage at the expense of the industry and the consumer. 4.3.2 Purpose, Activities and Scope The Free Protocols Foundation is a nonprofit corporation, incorporated in the State of Washington. The principal purpose of the Free Protocols Founda- tion is to act as an independent public forum for the sup- port of patent-free protocols. We do this by means of the 64CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES following major activities: - By providing an independent, external forum in which an Author may make an initial declaration that a protocol is intended to be patent-free. - By defining a set of patent-related Working Group procedures which, if followed, ensure that the re- sulting protocol will remain functionally patent-free. Any development organization is free to adopt these procedures with regard to its own protocols. - By providing an independent, external forum in which a Working Group may make a public declaration that it follows these procedures. - Whenever patent rights are asserted with respect to any protocol which has been declared patent-free to the FPF, by publishing a statement of the patent right assertion. - Whenever patent rights are known to exist with re- spect to a protocol which has been declared patent- free to the FPF, by assisting in obtaining from the patent-holder a non-restrictive license to implement the patented process as part of the protocol. The scope of activities of the Free Protocols Foun- dation is limited to those activities which provide sup- port for free protocols, and which oppose the mis-use of patented protocols. In particular, the Free Protocols Foundation does not develop protocols itself, nor does it participate in the de- velopment of the protocols of other organizations. The FPF does not evaluate or provide any commentary on the technical merits of protocols. Also, the FPF does not make any independent verifi- cation of whether or not a developer actually adheres to the processes and procedures of Section 4.6. The FPF does no more than record the fact that the development organization has made the declaration that it conforms to those procedures. 4.3.3 Other Activities In addition to its activities undertaken to support the de- velopment of patent-free protocols, the FPF may also take actions to oppose the creation and promotion of patented protocols. These actions may consist of any of the fol- lowing: 4.4. FREE PROTOCOL DEVELOPMENT WORKING GROUPS 65 - Acting as a clearing house for information and ar- ticles relating to protocol patent-freedom. - Supporting the creation and development of patent- free alternative protocols to existing patented pro- tocols. - Alerting legislators of the harmful effects of soft- ware and protocol patents, and lobbying for changes in the way software patents are granted. - Alerting the United States Patent and Trademark Office (PTO) of the harmful effects of software and protocol patents, and lobbying for changes in the way sofware patents are granted. - Supporting fights against invalid software patents in the courts. - Boycotting companies which misuse software and protocol patents. We encourage others to join us in resisting the grant- ing and abuse of software and protocol patents. 4.4 Free Protocol Development Work- ing Groups It is often the case that protocols are developed, or main- tained and enhanced, by means of public Working Groups. A Working Group may enter into participation at various stages in the protocol's development. In many cases, the creation and initial development of a protocol is done by a single Author or a small team of core developers. Once an initial basis for the proto- col is in place, a larger public Working Group is then formed, which takes over responsibility for maintenance and enhancement of the protocol. In this case, the Work- ing Group begins participating at stage (6), Maintenance and enhancement. In other cases, a Working Group may be formed in order to do the initial creation and development work it- self. In this case, the Working Group begins participating at the very beginning, at stage (1), Initial development. Working Groups typically communicate amongst them- selves by means of working group mailing lists, together with occasional physical meetings as necessary. Under these circumstances, it is possible for a large number of contributors to participate in the development of a proto- col. 66CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES The processes and procedures of Section 4.6 include provisions whereby patent-freedom can be maintained for a protocol despite its being developed by a public Work- ing Group. These provisions consist of a set of proce- dures that, if followed by the Working Group, will keep the protocol functionally patent-free. A key provision is that anyone who participates in the Working Group is re- quired to adhere to these procedures. That is, the Work- ing Group must impose adherence to its procedures on all Working Group contributors. Note that the FPF does not manage Working Group mailing lists itself, nor does it maintain a list of Work- ing Groups which have adopted the FPF's processes and procedures. Though the FPF does provide a mechanism whereby Working Groups may make a declaration that they conform to the FPF Working Group procedures, it does not provide a mechanism whereby individual con- tributors may make such a declaration. The role of the FPF regarding Working Groups is lim- ited to that of establishing a minimal set of policies and procedures that contributors may choose to adopt in or- der to maintain a patent-free protocol. This minimal set of policies relates only to patents, copyright and confi- dentiality. All other procedures are at the discretion of each individual Working Wroup. 4.5 Patent-Free Declarations 4.5.1 Author's Declaration Any Author may make an initial patent-free declaration to the Free Protocols Foundation relating to a protocol. This declaration should include statements to the effect that: - To the best of the Author's knowledge, the protocol is not subject to any patent restrictions. - It is the Author's intention to maintain the protocol patent-free. - In the event that the Author becomes aware of a patent right restriction relating to the protocol, or a patent right assertion is made with respect to the protocol, the Author will make prompt disclosure of this fact to the Free Protocols Foundation. Any such statement provided to the FPF will be pub- lished on the FPF website. Examples of statements pre- 4.6. PATENTS, COPYRIGHT AND CONFIDENTIALITY - POLICY STATEMENT 67 viously provided to the FPF can be found in the Author's Declarations section of the FPF website. 4.5.2 Working Group Declaration If a Working Group participates in the development and/or maintenance and enhancement of a protocol, it may make a declaration that its protocol maintenance and enhance- ment procedures conform to the FPF Processes and Pro- cedures regarding patent-freedom. A Working Group may do this by providing the Free Protocols Foundation with a statement that its protocol development process conforms to the processes and procedures set forth in Section 4.6. Any such statement provided to the FPF will be pub- lished on the FPF website, and the corresponding proto- col will be added to the list of those declared to conform to the FPF's patent-free policies and procedures. Examples of statements previously provided to the FPF can be found in the Free Protocols Working Group Declarations section of the FPF website. The list of declared- conforming protocols is available in the List of Free Pro- tocols Specifications and Their Declarations section of the FPF website. 4.6 Patents, Copyright and Confi- dentiality - Policy Statement In this section we define a set of policies and procedures which ensure that a protocol will remain functionally patent- free. Any Working Group is free to make use of these procedures as part of their development process. A key component of these procedures is that every member of the Working Group is required to abide by the proce- dures. 4.6.1 Policy Statement Principles Because of the difficulties relating to software patents de- scribed in Section 4.1.3, it is not possible to be absolutely certain that a protocol is truly patent-free. The scope of these policies and procedures is therefore limited to en- suring that a protocol is patent-free as far as is practically possible. The purpose of the procedures is to codify the following principles: - Author's Patent-Free Intent Declaration. When a developer makes a patent-free declaration to the 68CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES FPF, a key part of the declaration is that of intent. That is, the declarer is making the statement that to the best of the declarer's knowledge the protocol is patent-free, and that it is the declarer's intention to keep it so. - On-Going Patent-Free Contributions. By becom- ing a member of a Working Group, every contribu- tor to the on-going maintenance and enhancement of the protocol is required to adhere to principles and procedures which preserve patent-freedom of the protocol. - Working Group's Declaration When a Working Group makes a declaration to the FPF, the effect of this declaration is that the Working Group's activi- ties conform to a set of processes that ensure, as far as possible, that the resulting protocol specification is functionally patent-free. - Patent Assertion Disclosure If a patent assertion is made subsequent to the declaration, the declarer undertakes to make prompt announcement of this to the Free Protocols Foundation. The Free Pro- tocols Foundation maintains a record of all patent right assertions that have been made against any of its listed protocols. This record is available in the Notices of Claimed Rights section of the FPF web- site. - Obtaining Non-Restrictive Usage Rights. In the event that the developer becomes aware of a patent restriction relating to the protocol, the developer will attempt to obtain non-restrictive usage rights for the protocol. 4.6.2 General Policy In all matters of patent and confidentiality rights and pro- cedures, the intention of the FPF is to benefit the Internet community and the public at large, while respecting the legal rights of others. 4.6.3 Confidentiality Obligations No Free Protocol Developer shall make any contribution to the Free Protocol Working Group that is confidential. No contribution that is subject to any requirement of con- fidentiality or any restriction on its dissemination shall be included in any part of a Free Protocol Specification. 4.6. PATENTS, COPYRIGHT AND CONFIDENTIALITY - POLICY STATEMENT 69 4.6.4 Rights and Permissions of All Contri- butions By submission of a contribution, each person actually submitting the contribution is deemed to agree to the fol- lowing terms and conditions on his own behalf, on behalf of the organization (if any) he represents and on behalf of the owners of any proprietary rights in the contribution. Where a submission identifies contributors in addition to the contributor(s) who provide the actual submission, the actual submitter(s) represent that each other named con- tributor was made aware of and agreed to accept the same terms and conditions on his own behalf, on behalf of any organization he may represent and any known owner of any proprietary rights in the contribution. 1. Some works (e.g. works of the U.S. Government) are not subject to copyright. However, to the ex- tent that the submission is or may be subject to copyright, the contributor, the organization he rep- resents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited, per- petual, non-exclusive, royalty-free, world-wide right and license to the Free Protocols Foundation and the Free Protocol Working Group under any copy- rights in the contribution. This license includes the right to copy, publish and distribute the contribu- tion in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the origi- nal contribution. 2. The contributor acknowledges that the Free Proto- col Working Group and the Free Protocols Foun- dation have no duty to publish or otherwise use or disseminate any contribution. 3. The contributor grants permission to reference the name(s) and address(es) of the contributor(s) and of the organization(s) he represents (if any). 4. The contributor represents that the contribution prop- erly acknowledges major contributors. 5. The contributor, the organization (if any) he rep- resents, and the owners of any proprietary rights in the contribution agree that no information in the contribution is confidential and that the Free Pro- tocol Working Group and the FPF may freely dis- close any information in the contribution. 70CHAPTER 4. FREE PROTOCOLS FOUNDATION POLICIES AND PROCEDURES 6. The contributor represents that he has disclosed the existence of any proprietary or patent rights in the contribution that are reasonably and personally known to the contributor. The contributor does not repre- sent that he personally knows of all potentially per- tinent proprietary and patent, confidentiality and copyright rights owned or claimed by the organi- zation he represents (if any) or third parties. 7. The contributor represents that there are no limits to the contributor's ability to make the grants ac- knowledgments and agreements above that are rea- sonably and personally known to the contributor. 4.6.5 FPF Role Regarding Free Protocol Spec- ifications 1. Where any patents, patent applications, or other proprietary rights are known, or claimed, with re- spect to any Free Protocol Specification, and brought to the attention of the FPF, the FPF shall prepare a note, to be included in the next revision of the Free Protocol Specification, indicating the existence of such rights, or claimed rights. 2. The FPF encourages all interested parties to bring to its attention, at the earliest possible time, the ex- istence of any patent rights pertaining to Free Pro- tocol Specifications. 3. Where the FPF knows of rights, or claimed rights under (1), the FPF shall assist the Free Protocol Working Group in attempting to obtain from the claimant of such rights, a written assurance with re- spect to the relevant protocol specification(s), that any party will be able to obtain the right to imple- ment, use and distribute the technology or works when implementing, using or distributing technol- ogy based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. Chapter 5 ESRO: A Foundation for the Development of Efficient Protocols 5.1 Overview of ESRO All efficient applications have the requirement for an ef- ficient transport mechanism. For this reason, part of the initial focus of the LEAP protocol development effort has been on creating a general efficient transport mechanism. The resulting protocol is referred to as Efficient Short Remote Operations, or ESRO. ESRO is the efficient transport layer protocol for several LEAP applications. ESRO is a reliable connectionless transport mechanism, forming the foundation for the development of efficient protocols when TCP is too much and UDP is too little. The need for efficient protocols extends across all as- pects of wireless data communications, including e-mail, web browsing, and other applications. The LEAP archi- tecture accommodates many of these applications based on the use of ESRO. ESRO was published as RFC-2188 [91 ] in September of 1997. The ESRO protocol is publicly maintained and enhanced by ESRO.org at http://www.esro.org/. Patent free declarations have been made with respect to ESRO through the Free Protocols Foundation. 5.1.1 The Need for ESRO Considering that: - Many vertical applications in the wireless environ- 71 72CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS ment need a reliable, efficient and lightweight data transfer mechanism. - Existing Internet transport protocols (TCP/UDP) do not address these requirements adequately. - Today, most vertical applications either implement their own ad hoc reliability service on top of UDP, or else use non-standard middleware. - A reliable connectionless transport protocol based on open specifications is needed. - Remote Operations is superior to reliable connec- tionless transport as an application development paradigm. ESRO has been designed to address these specific needs. The need to address the requirements that the ESRO protocol addresses has been well recognized for quite a long time. As early as 1995 such requirements were be- ing discussed within the Internet research community. In particular, RFC-955 [14 ], entitled "Towards a Transport Service for Transaction Processing Applications," demon- strates recognition of the need for ESRO. A more re- cent document, RFC-2757 [67 ], entitled "Long Thin Net- works," again recognizes the demand for such a protocol. In the past, this unaddressed demand has given rise to a variety of product oriented proprietary solutions (as opposed to open protocols) which are often referred to as "Middleware Products." This has been particularly widespread in the wireless industry. Often these solutions are vendor specific and do not scale. 5.1.2 ESRO Requirements and Goals The requirements and goals driving the ESRO protocol and system design include the following: 1. Provide reliability in an efficient manner for a wide range of vertical applications (e.g. wireless). 2. Specify an Internet open protocol. 3. Minimize the number of transmissions. 4. Minimize the number of bytes transmitted. 5. Be fast; minimize latency. 6. Be power efficient, and show respect for the re- source limitations of mobile platforms, including memory, CPU, and battery power limitations. 7. Be lightweight; accommodate miniaturized devices. 5.2. OTHER RELATED PROTOCOLS 73 5.1.3 Terminology A description of ESRO includes references to a number of basic data communications concepts and ideas. Be- cause of the informal, ad hoc, and often inconsistent ter- minology used within the Internet technical community, many of these concepts are referred to by a variety of dif- ferent names throughout various documents and RFCs. Many of the RFCs mentioned below refer to ESRO-related concepts in an inconsistent manner. In contrast to this, the ESRO specification uses the well defined and precise terminology of the "Open Sys- tems Interconnection Reference Model" [76 ]. In this pa- per we will also adhere to the same precise terminology. An example of the use of imprecise terminology is the term "Transaction Processing." Various other proto- col specifications refer to the concept of "Remote Op- erations" as "Transaction Processing." In our terminol- ogy, however, Transaction Processing goes above and be- yond Remote Operations, and also includes the concepts of Commitment, Concurrency and Recovery, and chained (related) Remote Operations which may be built on top of ESRO. 5.2 Other Related Protocols The overall model of ESRO is similar to and consistent with many existing protocols. The distinguishing char- acteristic of ESRO is its efficiency. Also, the scope of ESRO is very narrow and well defined. The options and selections that it provides for are few and clear. A brief comparison of ESRO to other similar proto- cols is provided in the sections below. 5.2.1 RPC Remote Procedure Call (RPC) is specified in RFC-1831 [89 ] and RFC-1833 [88 ]. The RPC specifications define a remote procedure model that is essentially the same as ESRO. However, the nota- tion of RPC uses a syntax which is quite different from that of ESRO. RPC can rely on a connection-oriented or a connectionless transport mechanism. When using the connectionless mechanism, the retransmission and reli- ability issues are considered to be beyond the scope of the RPC specification. RPC is usually used in combi- nation with External Data Representation, XDR (RFC- 74CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS 1832) [90 ]. When using RPC over UDP, no meaningful reliable transport mechanism is defined. For this reason use of RPC over UDP has been limited to LANs. 5.2.2 ROSE Remote Operations Services Element (ROSE) is speci- fied in [20 ] and [21 ]. ROSE is a complete and heavy- weight traditional OSI application which assumes avail- ability of all of the underlying OSI layers. The ESRO protocols can accomplish short operations with much less overhead than ROSE. 5.2.3 WAP's WTP The Wireless Appliction Protocol (WAP) includes a layer which is similar to ESRO, called "Wireless Transaction Protocol" (WTP) [4 ]. The WTP specification was published after ESRO was published, and is similar in functionality to ESRO. In many ways WTP can be considered to be patterned af- ter ESRO; however, WTP is in fact a step backwards. The clear and simple Remote Operations model of ESRO is renamed as "Wireless Transactions" in an inap- propriate context. The notation specification conventions are not used, and the state machines are not as robust. More importantly, the WTP specifications are not sta- ble, have not been published as Internet RFCs, and have not been declared to be patent free. As early as 1995, those involved in the development of WTP were made aware of LSROS and ESRO. The only reason we know of for their re-specification of WTP, rather than re-use of ESRO, is the WAP Forum's desire for control. More details on the problems of the WAP Forum's approach are provided in the article The WAP Trap [66 ]. 5.2.4 T/TCP Transaction/TCP is specified in [15 ] and [16 ]. T/TCP is a backwards-compatible extension of TCP which pro- vides efficient transaction-oriented service in addition to virtual-circuit service. Use of T/TCP often involves replacing existing TCP 5.2. OTHER RELATED PROTOCOLS 75 implementations. This non-evolutionary aspect of T/TCP is one of the reasons why T/TCP has not been widely adopted. Various lessons can be learned from why T/TCP has not been widely adopted. 5.2.5 RDP Reliable Data Protocol (RDP) is specified in [41 ] and [40 ]. RDP can be considered to be a specialized TCP, spec- ified for particular circumstances in which some of TCP's facilities are needed. One of the reasons why RDP has not been heavily used is because the set of specialized circumstances that it addresses do not justify the cost of implementing it. RDP allows for many options and selections, which makes its use difficult. Various lessons can be learned from why RDP has not been widely adopted. 5.2.6 VMTP Versatile Message Transaction Protocol (VMTP) is spec- ified in [23 ]. VMTP can be considered to be a specialized transport protocol, targeted for what it calls the transaction model of communications. One of the reasons why VMTP has not been heavily used is because it tries to address too broad of a software engineering-centric model. VMTP allows for many op- tions and selections, which makes its use difficult. Various lessons can be learned from why VMTP has not been widely adopted. 5.2.7 TCP Transmission Control Protocol (TCP) is specified in [78 ] and [16 ]. TCP is mature, well understood and stable. Congen- stion control and flow control mechanisms for TCP have been developed over the years, and incorporated into TCP implementations. The simplest and shortest TCP interaction involves 5 PDU exchanges. For applications wishing to accomplish 76CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS short and occasional communications in less than 5 PDU exchanges, ESRO is more efficient that TCP. 5.2.8 UDP UDP (User Datagram Protocol) is specified in [77 ]. UDP is a very simple and thin layer on top of IP, which does not provide reliability or sequence ordering. Applications requiring a reliable connectionless transport need to build on top of UDP. ESRO provide an efficient and reliable transport service on top of UDP. 5.2.9 UDP Plus Ad Hoc Re-Transmissions Various protocols have added their own specific re-transmission policies on top of UDP to make it more reliable. Examples of such efforts include the Domain Name System (DNS) [55 ] [56 ], Network Time Protocol (NTP) [54 ], and NNTP for Usenet News Reading. These efforts have all resulted in incomplete and lim- ited solutions. The problems with such approaches were understood as early as 1985 [14 ]. 5.3 The ESRO Protocol The ESRO specification describes the service model, the notation and the protocol for Efficient Short Remote Op- erations (ESRO). The ESRO service is similar to and is consistent with other Remote Operation and Remote Pro- cedure Call services. The emphasis of the ESRO ser- vice definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g. CDPD) usage in mind. The ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with min- imum overhead. ESRO supports segmentation and re- assembly, concatenation and separation, as well as multi- plexing for service users (applications). ESRO allows for trade-offs between efficiency and re- liability by specifying both 2-way handshake and 3-way handshake based protocols. The ESRO specifications also define a notation and the services provided by an application-service element to support interactive applications in a distributed sys- tems environment. A Remote Operation is invoked by 5.3. THE ESRO PROTOCOL 77 one entity; the other entity attempts to perform the Re- mote Operation and then reports the outcome of the at- tempt. Encoding mechanisms for presentation of the param- eters of remote operations are outside the scope of ESRO. However, identification (tagging) of the encoding mech- anism in use (e.g. XDR, BER, PER) is supported by ESRO. A variety of applications can use the ESRO protocol. Some early applications which use ESRO include: effi- cient short message submission and delivery, credit card authorization, and white pages lookup. 5.3.1 Efficiency Characteristics of ESRO The key requirement driving the design of ESRO is effi- ciency. Reliable transfer of a short message using TCP involves 5 transmissions at a minimum. Reliable trans- fer of a short message using ESRO involves only 3 or 2 transmissions. For many applications in which optimization of effi- cency is desired, it is likely that elimination of the extra 2 transmissions which are inherent to TCP, justifies devia- tion from it and use of ESRO instead. The efficiency premium realized by the use of ESRO rather than TCP can be very significant. For example, EMSD (a mail submission and delivery protocol that uses ESRO) can be upto 5 times more efficient than SMTP, while maintaining precisely the same level of reliabil- ity and security. The paper entitled "Efficiency Study of EMSD vs. SMTP/POP3/IMAP" [57 ] quantifies the effi- ciency of ESRO in comparison to traditional TCP based applications. 5.3.2 Why We Adopted the Remote Opera- tions Model ESRO is a reliable connectionless transport mechanism. A reasonable question is: Why did we design ESRO's service interface to be based on the Remote Operations model? Many Internet protocols are "text-based" on top of TCP. And the "here is some text" followed by "here is some more text" followed by "here is some text in re- sponse" has become the tradition of simple Internet pro- tocols. Protocols designed on the basis of this "text-based" approach have a good track record of acceptance through- 78CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS out the Internet, primarily because they are simple to un- derstand and simple to implement. When efficiency matters, however, the traditional text exchange model can be better expressed by the client re- questing a particular operation from the server, and the server responding with the results of that operation, thereby eliminating the traditional "text-based" chit-chat. With such an approach, the design of the protocol becomes a natural fit for the remote operations model. For short interactions, a reliable connectionless trans- port mechanism and the Remote Operations model are simply the same thing. The formalism of Remote Opera- tions is an asset that ESRO exploits. ESRO provides a service which supports interaction of applications based on a remote operation model. A Remote Operation is invoked by one entity; the other en- tity attempts to perform the Remote Operation and then reports the outcome of the attempt. The ESRO protocol is designed to be able to support a large variety of appli- cations. 5.3.3 RFC Publication of the ESRO Proto- col The ESRO protocol is completely open. It has been pub- lished as RFC-2188. For information on how to obtain the ESRO protocol, visit the "Base Protocol Specifications" section of http://www.esro.org/. 5.3.4 Maintenance of the ESRO Protocol via ESRO.org ESRO.org is a public organization which enables and fa- cilitates the development, maintenance and enhancement of protocols and related technologies which address the efficiency requirements of generic Internet applications. Anyone interested in participating in the development of the ESRO protocol can join ESRO.org by visiting the "Joining the ESRO.org and Related Mailing Lists" sec- tion of http://www.esro.org/. Patent-free declarations have been made with respect to ESRO and RFC-2188 through the Free Protocols Foun- dation. 5.4. USE OF ESRO 79 5.4 Use of ESRO The ESRO protocol is designed to be able to support many applications, such as mobile messaging, directory ser- vices, micro-browsers, dictionary lookup (white and yel- low pages), data sensors monitoring, telemetry, dispatch, and credit card authorization applications. In this section we discuss various considerations that protocol developers and application designers should make when designing applications which use ESRO. We then build on this by providing various examples. 5.4.1 Common ESRO Application Design Con- siderations When designing applications which use ESRO services, a number of common issues often need to be considered. These include: - Presentation - Syntax and Encoding - Operation Reliability - Idempotency - Duplication Detection - Failure Detection and Re-Tries - Segmentation/Re-Assembly - Congestion and Flow Control - Security Considerations: Authentication, Confiden- tiality, Authorization We discuss each of these in some detail below. Presentation - Syntax and Encoding Using the remote operations model, Argument, Result and Error parameters are communicated between the in- voker and the performer. The application designer must choose and specify the particular syntax and encoding to be used. Encoding mechanisms for presentation of the param- eters of remote operations are outside the scope of ESRO. However, identification (tagging) of the encoding mech- anism in use is supported by ESRO. The choice of encoding mechanism by the develop- ers often revolves around the efficiency requirements, the 80CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS complexity of the application to be designed, the avail- ability of tools (e.g. XML, XDR, ASN parser and com- pilers) and the familiarity of the developer with the tools. ESRO can accomodate any syntax and encoding, in- cluding: plain text, XML, ASN.1 (BER, PER etc.) and XDR. The ESRO specification introduces one notation in ASN.1 for representation of Operations. This in no way ties the use of ESRO to ASN.1. Any syntax and encoding can be used, and use of any notation for representation of Operations is not mandatory. Operation Reliability Different applications may need various levels of failure detection for various operations. Any one of the follow- ing three methods may be needed to accomplish the de- sired reliability and semantics of various aspects of appli- cations: - 2-Way Handshake - 3-Way Handshake - 3-Way Handshake with Verify An example of the usage of all three of the above methods is provided by EMSD [5 ]. Idempotency - Duplication Detection Some operations are idempotent in nature, that is, they can be performed more than once without causing harm. However, other operations are non-idempotent, and should therefore be performed only once. In the case of non- idempotent operations, the performer should be able to detect duplicate operations, and perform each non-idempotent operation only once. Examples of non-idempotent operations are Submis- sion and Delivery of messages, which should not be per- formed more than once. Examples of idempotent oper- ations are enquiries of date and time, which can be per- formed more than once without harm. ESRO Services do not detect duplicate invocation of operations. As a result, the application should detect du- plication when the same operation instance is invoked more than once. 5.4. USE OF ESRO 81 An example of how this can be accomplished in a co- herent manner can be found in Section 4 of RFC-2524, entitled "Duplicate Operation Detection Support" [5 ]. Failure Detection and Re-Tries Based on ESRO's notification of Failures, the application must take necessary measures to re-try the operation. Depending on the nature of the application, use of a general spooler which supports persistence may be rea- sonable. Segmentation/Re-Assembly ESRO provides Segmentation and Re-Assembly, as well as Concatenation and Separation, inside the protocol. How- ever, an application may choose to provide segmentation and re-assembly above ESRO services. The specific requirements of the application and the nature of the networks in use may justify such a design. Congestion Control and Flow Control The ESRO protocol includes flow control, and allows for various re-transmission timers policies to be implemented. Such policies may include exponential back-off and adap- tive retransmission algorithms. These allow for the use of self-adjusting timers to determine and dynamically set timers to effectively adjust data traffic in the event the link is slower than usual due to congestion or other network or system conditions. However, specification of retransmission timers poli- cies was deliberately not included in the ESRO protocol. Often ESRO will be used on the edges of the Internet, where the characteristics of network behavior between the Invoker and the Performer are deterministic and sta- ble. In such environments, a custom re-transmission timers policies is more effective than a generic one. For exam- ple, timer profiles specific to CDPD or GSM wide area networks which assume the servers are at the edges of the Internet can be tailored to optimize performance. In practice, early usages of ESRO are likely to be in such environments. Congestion Control was also deliberately not included in the ESRO protocol, and is intended to sit on top of ESRO. This is for two reasons. First, indications of congestion in the IP protocol suite 82CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS violate layering principles, and use of such indications would have made the congestion control mechanism lim- ited to IP. Use of ESRO over non-IP packet networks (such as GSM) is highly desirable in the short term. Second, the indication and source congestion need not be limited to purely network resources, and indica- tions of congestion may come from a variety of sources. In practice, ESRO based congestion control is primarily server driven. Design of ESRO applications should in- clude Congestion Control mechanisms. An example of how Congestion Control on top of ESRO may be designed can be found in SubmissionCon- trol and DeliveryControl sections of RFC-2524, [5 ]. Such control facilities and design makes use of ESRO and EMSD well suited for the End-To-End Internet usage model. Security Different applications may need various levels of security facilities. It is the requirements and scope of the individ- ual application that drives the nature of security facilities that are appropriate to use. In many cases, the key required security facilities are Authentication, Confidentiality and Authorization. The trade-offs between complexity, efficiency and reliability are best made on a case-by-case basis. In the specific case of Efficient Mail Submission & Delivery (EMSD) [5 ], the existing mainstream Internet security mechanism of Pretty Good Privacy (PGP) can be used to provide end-to-end security facilities. As an underlying general facility, ESRO itself does not provide any generalized security facilities. At some point in time, it makes good sense to create a common security framework for LEAP which is consistent with the broader Internet security framework. We will start incorporating common security features when they become widespread in the broader Internet. When Network Layer Security, Transport Layer Security, PKI, etc. are widespread, they will be incorporated as common facilities within LEAP. 5.5 Example Applications A variety of applications can make use of the ESRO pro- tocol. In this section we mention and provide references to a number of ESRO based applications. Based on the 5.5. EXAMPLE APPLICATIONS 83 broadness of their usage and intended audience, we cate- gorize them as either "Horizontal Applications" or "Ver- tical Applications." 5.5.1 Horizontal Applications Various efficient horizontal applications have been devel- oped or are being developed using ESRO. These include: - EMSD: Mobile and Wireless Messaging, Modern Two-Way Paging - EHTD: Efficient Micro-Browsing - E-DICT: Efficient Dictionary Lookup A brief description of each is provided below. 5.5.2 EMSD: Efficient E-Mail One of the efficient application layers built on top of ESRO is called Efficient Mail Submission & Delivery, or EMSD. EMSD is the component of LEAP that addresses the Mo- bile Messaging application. EMSD is highly optimized for the submission and de- livery of short (typically 4 kilobytes or less) Internet e- mail messages, and is therefore extremely well suited to the wireless environment. EMSD improves on existing messaging protocols by optimizing the exchange between the server and the end-user device, both in terms of the number of bytes transferred, and in terms of the number of transmissions. For more information on EMSD see the article EMSD: The LEAP E-Mail Component within The LEAP Manifesto, or visit the EMSD website at http://www.emsd.org/. 5.5.3 EHTD: Efficient Web Browsing The Efficient Hyper Text Delivery (EHTD) layer is a hy- pertext transfer protocol which is optimized for the effi- cient transfer of short markup pages. EHTD is the com- ponent of LEAP which facilitates web browsing. Along with EMSD, EHTD also benefits from the reliable effi- cient services of ESRO. A multiplicity of efficient markup languages can be used in conjunction with EHTD. Devel- opment of the EHTD protocol is currently in progress. 84CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS 5.5.4 Other Efficient Horizontal Applications Various other efficient application protocols are either un- der development, or anticipated for future development. One of these is the Efficient Dictionary protocol, or E- DICT, which will enable efficient access to dictionaries and other lookup data structures. A starting point for the E-DICT protocol is currently being created. In develop- ing E-DICT, we intend to build on the existing work al- ready done in the context of the DICT protocol. We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementations of ESRO-based instant messaging, chat, white pages, and others. 5.5.5 Vertical Applications Various efficient vertical applications have been devel- oped or are being developed using ESRO. These appli- cations include: - Wireless credit card verification - Wireless automated teller machine (ATM) - Dispatch applications - Telemetry - Wireless T.V. ratings - Vehicle tracking (GPS applications etc.) There are a set of common architectural characteris- tics to most of these vertical applications. These common characteristics are illustrated in Figure 5.1. In this figure, the box labeled "Thin Reliability Layer" represents the position of ESRO. The combination of ESRO as the efficient transport mechanism, the systems modeling represented in Figure 5.1, and the methods described in Section 5.4.1 can greatly facilitate and expedite development of efficient vertical applications. 5.6 Existing Implementations of ESRO A Reference Implementation of ESRO in the form of free software in open-source format is being made available at http://www.MailMeAnywhere.org/. 5.6. EXISTING IMPLEMENTATIONS OF ESRO 85 Figure 5.1: Anatomy of a Vertical Wireless Application We expect to have the ESRO protocol engine software components subject to the GNU General Public License available at this location by September 2000. On the device side, software will be made available for most generic platforms, including PalmOS, EPOC, WindowsCE, Windows9X, and Windows-NT. On the server side, software will be available on Solaris, Linux and NT. In addition to open-source format, the ESRO Refer- ence Implementation will also be made available for the above mentioned platforms as a ready-to-use Toolkit. For a current list of ESRO free and commercial soft- ware products, visit the "Products and Services" section of http://www.esro.org. 86CHAPTER 5. ESRO: A FOUNDATION FOR THE DEVELOPMENT OF EFFICIENT PROTOCOLS 5.6.1 ESROS Application Programming In- terface The "ESRO API Specification" [58 ] defines the ESRO Application Programming Interface (API). This specifi- cation maps ESRO service primitives into C language function calls. This document is available at http://www.esro.org/documents/API.html. Chapter 6 EMSD: The LEAP E-Mail Component 6.1 Introduction This article provides a description of the Efficient Mail Submission & Delivery protocol, or EMSD. EMSD is the e-mail component of the LEAP family of protocols. The entire family of LEAP protocols has been de- signed with efficiency as a primary requirement, and each component protocol brings efficiency and functionality benefits to the users of miniaturized mobile devices. In particular, EMSD brings these efficiency benefits to the e-mail, or Mobile Messaging, application. Mobile Messaging is just one of several applications for which there is a high efficiency premium in the mobile and wireless arena. Other applications which demand efficiency in the mobile environment are such things as web browsing, dictionary look-up, etc. From an industry- building perspective, however, e-mail is the most criti- cally important of all wireless and mobile data commu- nications applications. Mobile Messaging provides the user with a unique communications facility: the immedi- ate delivery of important and time-critical information to the mobile recipient, wherever and whenever he/she hap- pens to be. This is a capability which is not provided by phone, Fax, or any other tool in the modern user's array of communications options. In fact, this capability represents the principal value of wide-area wireless networks to the end user, and this is why e-mail remains the dominant application for wide- area wireless networks. Furthermore, miniature hand- held mobile devices are extremely well-suited to the e- 87 88CHAPTER 6. EMSD: THE LEAP E-MAIL COMPONENT mail application. The same is not true for other applica- tions, such as web browsing. For all these reasons, e-mail is the key industry-building application, and this is why EMSD represents the right starting point for the LEAP family of protocols. 6.1.1 Terminology Throughout this article, we will make use of the follow- ing terms and definitions: - MTS. Mail Transfer System. - Mail Submission. Mail submission refers to the process of putting mail into the Mail Transfer Sys- tem (MTS). - Mail Delivery. Mail delivery refers to the process of the MTS putting mail into a user's final mailbox. - SMTP. Simple Mail Transfer Protocol. - MUA. Mail User Agent. - EMSD-P. EMSD Protocol. - EMSD-FS. EMSD Format Standard. - EMSD-UA. EMSD User Agent. - EMSD-SA. EMSD Server Agent. 6.2 Existing Internet Mail Submis- sion and Delivery Mail transmission in the Internet did not arise as a result of well-planned engineering processes; rather, it grew and evolved in a more organic way. At present, most mail submission and delivery through- out the Internet is done by means of the Simple Mail Transfer Protocol, or SMTP. SMTP was originally de- fined as a message transfer protocol - that is, a means to route (if necessary) and deliver mail by putting finished (i.e. complete) messages in a mailbox. Originally, users connected to servers from terminals, and all processing occurred on the server. Today, a split-MUA (Mail User Agent) model is common, in which MUA functionality occurs both on the user's own system, and the server. In the split-MUA model, the process of getting a mes- sage to the user is accomplished by access to a mailbox on 6.3. OVERVIEW OF EMSD 89 the server, using protocols such as POP and IMAP. Also, in the split-MUA model, the user's access to his/her mes- sage is based on a "Message Pull" paradigm, in which the user is required to explicitly poll his/her mailbox to re- trieve mail. Message delivery based on a "Message Push" paradigm, in which mail is delivered directly to the user without polling, is presently not supported. Despite its original definition as a message transfer protocol, in the split-MUA model, SMTP is often used for message submission. The widespread use of SMTP for submission has become a reality, regardless of whether this is a good or a bad thing. 6.3 Overview of EMSD EMSD is a messaging protocol that is highly optimized for the submission and delivery of short Internet e-mail messages. The EMSD protocol addresses all the short- comings in the existing Internet mail system described in the previous section. EMSD properly supports the Mes- sage Push mode of operation, and it provides an alterna- tive mechanism to SMTP for message submission. And most important of all, it does this with a major emphasis on efficiency. 6.3.1 Protocol Layering As shown in Figure 6.1, the LEAP protocols are layered. The lower layer, called Efficient Short Remote Opera- tions (ESRO), provides efficient reliable connectionless transport services which can be used by a variety of ap- plications. For example, in addition to Mobile Messaging services, ESRO can also be used as a transport service for credit card verification applications and efficient micro browsers. EMSD is built on top of ESRO. The reliability re- quirements for message submission and message deliv- ery in EMSD are the same as for existing e-mail proto- cols. The EMSD protocol provides reliable connection- less mail submission and delivery services. 6.3.2 EMSD Protocol Components EMSD consists of two independent components: the EMSD Format Standard, and the EMSD Protocol. These two components provide the following functions: 90CHAPTER 6. EMSD: THE LEAP E-MAIL COMPONENT Figure 6.1: LEAP Protocol Stack 1. EMSD Format Standard (EMSD-FS) EMSD-FS is a non-textual form of compact encod- ing of Internet e-mail (RFC-822) messages, which facilitates efficient message transfer. EMSD-FS is used in conjunction with the EMSD-P (described below), but is not in any way a general replace- ment for RFC-822. EMSD-FS defines a method of representation of short interpersonal messages. It defines the "Content" encoding (Header + Body). Although EMSD-FS contains end-to-end informa- tion, its scope is purely point-to-point. EMSD-FS relies on EMSD-P for the transfer of the content to its recipients. 2. EMSD Protocol (EMSD-P) EMSD-P is responsible for wrapping a limited size EMSD-FS message in a point-to-point envelope, and submitting or delivering it. EMSD-P performs the envelope encoding. EMSD-P relies on the ser- vices of Efficient Short Remote Operations (ESRO) as specified in RFC-2188 [91 ] for transporting the point-to-point envelope. Some of the services pro- vided by EMSD-P include: message originator au- thentication, and optional message segmentation and re-assembly. EMSD-P is expressed in terms of ab- stract services using the ESRO notation. 6.3. OVERVIEW OF EMSD 91 Together, the EMSD Protocol and Format Standard define the protocols used to transfer messages between an EMSD Server Agent (EMSD-SA), for example a Mes- sage Center, and an EMSD User Agent (EMSD-UA), for example a Two-Way Pager. Figure 6.2 illustrates how EMSD defines the com- munication between a specific EMSD-UA and a specific EMSD-SA. The Message Transfer System may include a number of EMSD-SAs, and each EMSD-SA may have any number of EMSD-UAs with which it communicates. Figure 6.2: Efficient Mail Submission and Delivery Pro- tocol It is important to note that EMSD-P and EMSD-FS are not end-to-end, but instead focus on the point-to-point transfer of messages. The two points being referred to are the EMSD-SA and EMSD-UA. EMSD-P functions as an element of the Internet mail environment, providing end- to-end services (i.e. EMSD-User to any other Messaging Originator or Recipient). The EMSD services use the Efficient Short Remote Operations (ESRO) services. They also use the Duplicate Operation Detection Support Functions. These functions guarantee that an operation is performed no more than once. 92CHAPTER 6. EMSD: THE LEAP E-MAIL COMPONENT 6.3.3 Efficient Short Remote Operations (ESRO) The EMSD protocol specifications define the protocols between the EMSD Device and the EMSD Server. EMSD is built on top of, and requires the services of, ESRO (Ef- ficient Short Remote Operations). This EMSD require- ment was the major motivation for the development of ESRO; however, ESRO has been developed to be inde- pendent of EMSD. ESRO defines a notation and the services provided by an application-service element to support interactive applications in a distributed systems environment. The scope of ESRO services is not limited to EMSD. ESRO is designed to be able to support other applications, such as finger/limited directory service. The ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with min- imum overhead. ESRO supports segmentation and re- assembly, concatenation and separation, as well as multi- plexing for service users (i.e. applications). The ESRO service is similar to and is consistent with other Remote Procedure Call services. The major empha- sis of the ESRO service definition and the ESRO proto- col is on efficiency. ESRO has been designed specifically with wireless network (e.g. CDPD) usage in mind. The service model, the notation, and the protocol for ESRO are fully specified in RFC-2188 [91 ]. The EMSD Protocol uses ESRO to accomplish reliable connection- less mail submission and delivery. For more information on ESRO, see the article enti- tled ESRO: A Foundation for the Development of Efficient Protocols within The LEAP Manifesto, or visit the ESRO website at http://www.esro.org/. 6.3.4 Anticipated Uses of EMSD Any network or network operator which faces significant bandwidth and capacity limitations can benefit from the use of EMSD. Any user of a network who must bear high costs for measured network usage can benefit from the use of EMSD. The initial use of EMSD is expected to be primarily to provide Mobile Messaging services over IP-based wire- less networks. However, EMSD can also function as an adjunct to Mail Access Protocols for "Mail Notification Services." 6.4. EMSD DESIGN GOALS AND REQUIREMENTS93 Mail submission and delivery take place at the edges of the network. It is likely that multiple mail submis- sion and delivery protocols will be developed, each ad- dressing the specific requirements of a particular user's environment. Such diversity on the edges of the network is beneficial, and with the right protocols, this diversity does not adversely affect the integrity of the mail transfer system. EMSD is the basis for the mail submission and delivery protocol to be used when the user's environment demands efficiency. 6.4 EMSD Design Goals and Require- ments The EMSD protocols have been designed to accomplish three high-level goals: 1. Define the new "world" of Efficient Mail Submis- sion & Delivery 2. Define a remote operations service that can handle messaging and other standard networking applica- tions 3. Make EMSD an extension of the existing Internet- working world Based on these goals, EMSD has been designed to satisfy the following design requirements: 1. Support the submission of short mail messages with the same (or better) level of functionality as the ex- isting Internet mail protocols. 2. Support the delivery of short mail messages with the same (or better) level of functionality as the ex- isting Internet mail protocols. 3. Function as an extension of the existing mainstream Internet mail. 4. Minimize the number of transmissions. 5. Minimize the number of bytes transmitted. 6. Be quick: minimize the latency of message sub- mission and delivery. 7. Provide the same level of reliability (or better) as the existing e-mail protocols. 94CHAPTER 6. EMSD: THE LEAP E-MAIL COMPONENT 8. Accommodate varying sizes of messages: the size of a message may determine how the system deals with the message, but the system must accommo- date it. 9. Be power efficient and show respect for mobile plat- form resources, including memory and CPU levels, as well as battery power longevity. In other words, be client-light and server-heavy. 10. Be highly extensible. Different users will demand different options, so the solution cannot require ev- ery feature to be a part of every message. Likewise, usage will emerge that is not currently recognized as a requirement. The solution must be extensible enough to handle new, emerging requirements. 11. Be secure. Provide the same level of security (or better) as the existing e-mail protocols. Content confidentiality, originator/recipient authentication, and message integrity must be available options to users. 12. Be easy to implement: re-use existing technology as much as possible. The EMSD protocols make extensive use of existing technology, including: - RFC-822 - ASN.1 - Basic Encoding Rules - Internet mail By using these established technologies, the design of EMSD avoids the expense and other problems associated with "re-inventing the wheel." The above technologies have been thoroughly tested, and have proven to be re- liable solutions for the problems they address (e.g. mes- sage format, reliable message delivery, encoding and com- pacting). The EMSD specifications cater to users who enjoy the advantages of this new technology, but at the same time want to be connected to the rest of the existing Internet e-mail world. Figure 6.3 shows how the Global and EMSD worlds complement one another. The Internet e-mail community is shown in the lower half of the figure. This world is connected to the EMSD Internet e-mail system. 6.5. RATIONALE FOR KEY DESIGN DECISIONS 95 Figure 6.3: EMSD World and Global Messaging World 6.5 Rationale for Key Design Deci- sions This section summarizes the rationale for the key design decisions that were made while developing the EMSD protocols. 6.5.1 Deviation from the SMTP Model SMTP is the main mail transport mechanism used through- out the Internet. It is widely deployed and well under- stood by many engineers who specialize in Internet e- mail. For these reasons, protocols based on or derived from SMTP or more likely to become widely deployed throughout the Internet. However, SMTP is highly inefficient for the transfer of short messages. SMTP is inefficient both in terms of the number of transmissions, and in terms of the num- ber of bytes transmitted. Even when fully optimized with PIPELINING, SMTP remains significantly inefficient. _ _ __ __ __ __ __ __ __ __ __ __ __ __ 96CHAPTER_6.__EMSD: THE LEAP E-MAIL COMPONENT ___ __ ___ The submission of a short message using SMTP re- quires_15_transmissions._ The submission of a short mes- sage_with_SMTP_and PIPELINING requires 9 transmis- sions.___The submission of a short message with EMSD (EMSD-P_and_ESRO)_requires_only 3 transmissions (in a typical_case).__ ____ ____ The key design requirement of EMSD is efficiency. Because__of__the_ 3 fold (at least) gain in efficiency, this justifies_the_deviation_from_the_SMTP model. ___ _____ Efficiency_Comparison_of_SMTP_and EMSD ___ ___ Table__6.1__shows_ the number of N-PDUs exchanged for the_transfer_of_a_short Internet e-mail when using SMTP, SMTP_with_PIPELINING,_QMTP,_and_EMSD._The names used_for_identifying_the PDUs are informal names. ___ _____ _______ SM_____TP _____SMTP + Pipelining _____ QMTP , QMQP * *_____ EMSD _____ _______Client: _____SYN _____SYN _____SYN * * _____Submit.Req _____ _______Server: _____SYN ok _____SYN ok _____SYN * * _____ Submit.Resp _____ ______ Client: _____HELLO _____HELLO _____ message * * _____ ack _____ _______Server: _____ok P_____IPELINING _____ accept close * * _____ _____ ______ Client: _____MAIL _____MAIL RCPT DATA _____ close * * _____ _____ _______Server: _____ok o_____k _____ * * _____ _____ _______Client: _____RCPT _____message QUIT _____ * * _____ _____ ______ Server: _____ok a_____ccept ok close _____ * * _____ _____ _______Client: _____DATA _____close _____ * * _____ _____ ______ Server: _____ok _____ _____ * * _____ _____ _______Client: _____message _____ _____ * * _____ _____ ______ Server: _____accept _____ _____ * * _____ _____ _______Client: _____QUIT _____ _____ * * _____ _____ _______Server: _____ok close _____ _____ * * _____ _____ ______ Client: _____close _____ _____ * * _____ _____ Table 6.1: Comparison of EMSD to Other Protocols 6.5.2 Use of ESRO Instead of TCP In order to provide the same level of reliability that the existing e-mail protocols provide for short messages, it is clear that a reliable underlying service is needed. UDP [80 ], by itself, is clearly not adequate. Use of TCP however, involves three phases: 1. Connection Establishment 2. Data Transfer 6.5. RATIONALE FOR KEY DESIGN DECISIONS 97 3. Disconnect The reliable transfer of a short message using TCP involves a minimum of five transmissions, as is the case with QMTP. Again, the key design requirement of EMSD is ef- ficiency. Therefore deviation from TCP is justified, be- cause this eliminates the two extra transmissions that are an inherent characteristic of TCP. The ESRO protocol, as specified in RFC-2188 [91 ], provides reliable connectionless remote operation services on top of UDP [80 ] with minimum overhead. ESRO sup- ports segmentation and reassembly, concatenation and sep- aration. The reliable transfer of a short message using ESRO involves 3 transmissions, as is the case with EMSD-P. 6.5.3 Use of the Remote Procedure Call (RPC) Model Many Internet protocols are "text-based." On the other hand, few Internet protocols are RPC-based. Protocols designed on the basis of the "text-based" approach have a better track record of acceptance throughout the Internet. However, considering that message submission and delivery in EMSD involves no more than two data ex- changes, the text-based model becomes the same as an operation. Furthermore, the RPC model is the natural way of using ESRO. 6.5.4 Use of ASN.1 In order to minimize the number of bytes transfered, effi- cient encoding mechanisms are needed. Among today's encoding mechanisms, ASN.1 has the unique feature of separating the abstract syntax from the encoding rules. By selecting ASN.1 as the notation used for expressing EMSD's information objects, EMSD has the flexibility of using the most efficient encoding rules, such as Packed Encoding Rules (PER), when they are available. Efficient encoding can always be better performed when the syntax of the information is known. In general, en- coding and compression techniques which use the knowl- edge of the syntax of the information produce better re- sults than those compression techniques that work on ar- bitrary text. 98CHAPTER 6. EMSD: THE LEAP E-MAIL COMPONENT 6.6 Relationship of EMSD to Other Mail Protocols EMSD is designed to be a companion to existing Inter- net mail protocols. It is designed to fit within the many protocols already in use for messaging, as well as those already in use for networking. Figure 6.4 shows how EMSD fits in with the other major messaging protocols. The RFCs referenced in the figure are current at the time of this writing, but could be updated or made obsolete at any time. Figure 6.4: Messaging Communication Stack and EMSD The various Internet mail protocols provide different sets of capabilities for mail processing. Table 6.2 summa- rizes the capabilities of SMTP, IMAP, POP and EMSD in the following areas of functionality: - Mail Submission - Mail Delivery _ _ ___ ___ ____ _____ _____ ______ _______ _______ ________ ________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ ___________ 6.7.__OBTAINING_THE_EMSD_PROTOCOLS________ 99 ___________ _____________ _______Protocol_Function__________SMTP_______ IMAP _____ POP _____ EMSD * *_____ ______ _______Submission______ _____ XX _____ _____ _____XXX* * _____ _______Delivery______ _____XXX _____ _____ _____XXX* * _____ _______Relay_(Routing)___ _____ XXX _____ _____ _____ * * _____ _______Retrieval___ _____ _____XXX _____XXX _____ XX * * _____ _______Mailbox_Access _____ _____XXX _____ X _____ * * _____ ______ Mailbox Sync. _____ _____XXX _____ _____ * * _____ Table 6.2: Messaging Protocol Functionality - Mail Routing (Relay) - Mail Retrieval - Mailbox Access - Mailbox Synchronization The number of X's in each cell of the table denotes the extent to which a particular function is supported by a particular protocol. Table 6.2 clearly demonstrates that combinations of these protocols can be used to complement one other in providing rich functionality to the user. For example, a user interested in highly mobile messaging functionality can use EMSD for the submission and delivery of time- critical and important messages, and use IMAP for com- prehensive access to his/her mail-box. 6.7 Obtaining the EMSD Protocols For complete instructions on how to obtain the EMSD protocols, visit the "Base Protocol Specifications" section of http://www.emsd.org/. 100CHAPTER 6. EMSD: THE LEAP E-MAIL COMPONENT Chapter 7 Efficiency of EMSD Preface This article was originally published in October 1996. It is being included in the Manifesto, essentially unchanged from its original form. 7.1 Introduction We provide here an overview of both SMTP and EMSD, to compare and contrast their features and to lay the ground- work for analysis of the experimental results in Sections ?? and ?? . SMTP According to RFC 821[79 ], the objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. The SMTP design is based on the following model of communication: As the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver- SMTP, which may be either the ultimate destination or an intermediate. Following this, the sender-SMTP sends a MAIL com- mand indicating the sender of the mail. If the receiver- SMTP can accept mail it responds with an OK reply. The sender-SMTP then sends a RCPT command identifying a recipient of the mail. If the receiver-SMTP can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The sender-SMTP and receiver-SMTP may negotiate several recipients. When 101 102 CHAPTER 7. EFFICIENCY OF EMSD the recipients have been negotiated, the sender-SMTP sends the mail data, terminating with a special sequence. If the receiver-SMTP successfully processes the mail data it re- sponds with an OK reply. Note that the dialog is pur- posely lock-step, one-at-a-time. SMTP provides two mechanisms for the transmission of mail: directly from the sending user's host to the re- ceiving user's host when the two host are connected to the same transport service, or via one or more relay SMTP- servers when the source and destination hosts are not con- nected to the same transport service. The mail commands and replies have a rigid syntax. Replies also have a nu- meric code. Thus it can be seen that for the exchange of any one message with SMTP, a number of transactions must be completed. EMSD attempts to improve efficiency by cut- ting down on this number and simplifying the process for the case of short messages. 7.1.1 Efficient Mail Submission & Delivery The EMSD specifications define the protocols between an EMSD Device and an EMSD Server. EMSD requires ESROS (Efficient Short - Remote Operation Services) [91 ]. The EMSD-P&FS consist of two independent com- ponents: Efficient Mail Submission & Delivery Protocol (EMSD-P) and EMSD Format Standards (EMSD-FS). EMSD-FS is responsible for defining the format of a limited size interpersonal message. It defines the "Con- tent" encoding (Header + Body) and the end-to-end enve- lope. It relies on EMSD-P for the transfer of the content to its recipients. EMSD-P is responsible for wrapping a limited size message in a point-to-point envelope and submitting or delivering it. EMSD-P performs the envelope encoding and relies on the services of ESROS for transporting the envelope. Some of the services of EMSD-P include mes- sage originator authentication and optional message seg- mentation and re-assembly. The Efficient Mail Submis- sion & Delivery Protocols are designed with three high level goals: - Define the new "world" of Efficient Mail Submis- sion & Delivery - Define a remote operations service that can handle messaging and other standard networking applica- tions 7.2. STUDY OVERVIEW 103 - Make Efficient Mail Submission & Delivery an ex- tension of the existing internetworking world These goals will prevent, whenever possible, the ex- pense and associated problems of "re-inventing the wheel." The EMSD Protocols make heavy use of existing technol- ogy: - RFC-822 - ASN.1 - Basic Encoding Rules - X.400 and Internet e-mail These technologies have been thoroughly tested and have proven to be reliable solutions for the problems they address (e.g. message format, reliable message delivery, encoding and compacting). The EMSD Specifications al- low for users who enjoy the advantages of this new tech- nology and at the same time want be connected to the rest of the existing messaging world. 7.2 Study Overview We have chosen to compare the efficiency of using EMSD to the efficiency obtained by other submission and deliv- ery protocols in this study. While it is debatable whether EMSD can be placed at the same level as the test proto- cols, we nonetheless feel that a study such as this is quite useful and provides a common denominator to discuss various aspects of EMSD performance. The experiments cover both submission (from a mo- bile unit) and delivery (to a mobile unit). Under sub- mission we looked at comparing EMSD and SMTP. The delivery experiments tested EMSD vs. SMTP, POP, and IMAP. In all cases a single uniform test message was re- layed between two devices (a recipient or sender, and a mail server) and the data traffic recorded. Although you cannot compare EMSD directly to any one messaging protocol, because each protocol is designed to perform a specific function, you can compare the results obtained by each messaging solution. The following table illus- trates the functions supported by each protocol. Note that EMSD is the most like SMTP. _ _ _ ___ ___ ____ ____ _____ ______ ______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ 104__________ CHAPTER 7. EFFICIENCY OF EMSD _________ __________ _______Protocol_______Submission________Delivery_______ Relay _____ Retrieval * * _____ Mailbox _____ Mailbox _____ _____________ _____ _____ _____ _____ * * _____Access _____ Sync _____ ____ _______SMTP___ _____ X _____ X _____ X _____ X * * _____ _____ _____ _______IMAP___ _____ _____ _____ _____ X * * _____ X _____ X _____ _______POP_ _____ _____ _____ _____ X * * _____ _____ _____ ______ EMSD _____ X _____ X _____ _____ X * * _____ _____ _____ Table 7.1: Messaging Protocols 7.3 Submission Please refer to Figure 7.1 below, which shows the setup for the following two submission experiments in detail. The experimental setup involves: At Site One: - A "sender": Toshiba Laptop running Windows 3.1 and Chameleon Winsock TCP/IP stack from Net- Manage - A "receiver": Sun Sparc running Solaris 2.4 - A "mail server": Sun Sparc running Solaris 2.4 - A sniffer that monitors packet movement at the junc- ture of the above three devices, recording two-way traffic At Site Two: - A Message Test Center: Sun Sparc running Solaris 2.4. The two setups are linked to each other over a number of routers across the Internet. In both cases below, we are interested exclusively in analyzing the recorded data between the sender laptop and the Unix mail server (in the case of SMTP submis- sion), or the EMSD Message Test Center (in the case of EMSD submission). Thus the "receiver" shown below, although necessary to submit the message, does not enter into our study picture directly. 7.3.1 SMTP Submission from PC to Unix Message Submission Process Message was submitted from the Laptop to the Unix mail server. To submit a message from the laptop, Netscape's 7.3. SUBMISSION 105 Figure 7.1: Experimental Setup for Submission Mail User Agent on Windows 3.1 was utilized. From the file menu on Netscape, "New Mail Message" was selected, popping up a mail window. The message was typed in, a recipient (the "receiver" in Figure 7.1) was specified, and "Send" was then clicked. The sniffer recorded the exchange of data between the sender and the mail server that was implement- ing sendmail. Protocol Trace The following is the protocol trace recorded by the snif- fer. After TCP synchronization and acknowledgment, a virtual circuit is established between the sender's Netscape Mail User Agent and sendmail on the mail server, and data is exchanged after specifying the sender and recipi- ent addresses. IP_PDU MailServer UA DATA TCP * * IP -------------------------------------------------------------------- 1 TCP .<------- TCP SYN -------- . 0 24 44 2 TCP . ------- TCP SYN ack ---->. 0 24 44 3 TCP .<------- Push ACK ------- . 0 20 40 * * (128) 4 SMTP . ----220 server ready --->. 116 136 156 5 TCP .<------- Push ACK ------- . 0 20 40 * * (196) 6 SMTP .<------- HELO --- . 36 56 76 7 SMTP . ----250 server Hello --->. 111 131 151 8 TCP .<------- Push ACK ------- . 0 20 40 * * (267) 106 CHAPTER 7. EFFICIENCY OF EMSD 9 SMTP .<--MAIL FROM: --- . 32 52 72 10 SMTP . ----250 ... Sender ok--->. 39 59 79 11 TCP .<------- Push ACK ------- . 0 20 40 * * (191) 12 SMTP .<--RCPT TO:-------- . 33 53 73 13 SMTP .<----250...Recipient ok-- . 45 65 85 14 TCP .<------- Push ACK ------- . 0 20 40 * * (198) 15 SMTP .<------ "DATA" ---------- . 6 26 46 16 TCP . ------- ACK ------------>. 0 20 40 * * (86) 17 SMTP . ----354..end with "."--->. 50 70 90 18 TCP .<------- Push ACK ------- . 0 20 40 * * (130) 19 SMTP .<--Mail header+body ----- . 437 457 477 20 SMTP .<------ . --------------- . 5 25 45 21 TCP . ------- ACK ------------>. 0 20 40 * * (562) 22 SMTP . ------- 250 Ok --------->. 8 28 48 23 TCP .<------- Push ACK ------- . 0 20 40 24 TCP .<------- Push Reset ----- . 0 20 40 * * (128) ---------------------------------------------------------------------- Measurement Results Total IP Packet bytes: 1886 Message Length (header + body): 437 Total Overhead (TCP header + IP header): 1449 3.1.4 Message as Received Message-ID: <32249501.46FD@airdata.com> Date: Wed, 28 Aug 1996 11:50:41 -0700 From: Jia-bing Cheng Organization: AT&T Wireless Services X-Mailer: Mozilla 2.0 (Win16; U) MIME-Version: 1.0 To: j.cheng@pocketnet.net Subject: test3 X-URL: file:///c:/netscape/jbc.htm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 123456789012345678901234567890 12345678901234567890 1234567890 7.3.2 EMSD Submission from PC to Unix Message Submission Process The message was submitted from the laptop using Neda's EMSD Mail User Agent version 0.9 on Windows 3.1, to Neda's EMSD Message Test Center. EMSD-Pine version 7.3. SUBMISSION 107 3.91 was used to submit the message from the laptop. Af- ter invoking Pine, and typing "C", a new message was composed and then sent via . A direct connec- tion was then established between the EMSD Mail User Agent on the laptop and the EMSD Message Test Cen- ter, and the message was relayed. The sniffer recorded exchange of data between the sender and Neda's EMSD Message Test Center which was imple- menting ESROS. Protocol Trace The following is the protocol trace recorded by the snif- fer. As compared to the SMTP protocol trace in section 7.3.1, you can see the exchange is quite brief. IP_PDU MailServer UA DATA UDP IP --------------------------------------------------------------- 1 UDP .<--Invoke header+body --- . 206 214 234 2 UDP . -----Response ---------->. 15 23 43 3 UDP .<------- Ack ------------ . 2 10 30 --------------------------------------------------------------- Measurement Results Total IP Packet bytes: 307 Message Length (header + body): 206 Total Overhead (EMSD header + UDP header + IP header): 101 Total IP bytes in the case of EMSD submission as compared to SMTP submission is down by a factor of 6; the header count is down by a factor of 2.6; and total overhead is down by a factor of 14, representing major savings in data traffic. Message as Received The # text below is provided as comments and does not appear in the received message. P.!.0. ... 0..0z@."333. 333" # FROM: 010/@)Jia-bing-pn Cheng # RCPT: ......test4 * * # Subject: ....text/plain; charset=us-ascii * * # content-type 0C.A * * # 123456789012345678901234567890. * * # BODY: 12345679801234567890. 108 CHAPTER 7. EFFICIENCY OF EMSD 1234567890 7.4 Delivery Similar to the submission experiments above, we also conducted analogous delivery tests. The first experiment on SMTP delivery is essentially the complement of the SMTP submission experiment described above, and uses the same setup as in Figure 7.1. The second and third de- livery experiments are with POP and IMAP servers and are described in their corresponding sections below. The final experiment is on EMSD delivery and also uses the same setup as in Figure 7.1. We then compare the perfor- mance of EMSD delivery versus the other three delivery methods. 7.4.1 SMTP Delivery from Unix to Unix Please refer to Figure 7.1 above for this experiment. Message Delivery Process The message was delivered to the Unix receiver from the Unix mail server. Both were implementing sendmail and the message was delivered via standard SMTP. The snif- fer recorded the exchange of data between the recipient and the mail server, which was . Protocol Trace The following is the protocol trace recorded by the snif- fer. After TCP synchronization and acknowledgment, a virtual circuit is established between the recipient's Mail User Agent and sendmail on the mail server, and data is exchanged after specifying the sender and recipient ad- dresses. IP_PDU MailServer bluejeans DATA TCP IP -------------------------------------------------------------------- 1 TCP .<------- TCP SYN -------- . 0 20 40 2 TCP . ------- TCP SYN ack ---->. 0 20 40 3 TCP .<------- Push ACK ------- . 0 20 40 4 SMTP . ----220 server ready --->. 116 136 156 5 SMTP .<------- HELO --- . 16 36 56 6 SMTP . ----250 server Hello --->. 95 115 135 7 SMTP .<--MAIL FROM: --- . 29 49 69 7.4. DELIVERY 109 8 SMTP . ----250 ... Sender ok--->. 39 59 79 9 SMTP .<--RCPT TO:-------- . 44 64 84 10 SMTP .<----250...Recipient ok-- . 57 77 97 11 SMTP .<------ "DATA" ---------- . 6 26 46 12 TCP . ------- ACK ------------>. 0 20 40 13 SMTP . ----354..end with "."--->. 50 70 90 14 SMTP .<--Mail header+body ----- . 301 321 341 15 TCP . -------- ACK ----------->. 0 20 40 16 SMTP .<------ . --------------- . 5 25 45 17 TCP . ------- ACK ------------>. 0 20 40 18 SMTP . ------- 250 Ok --------->. 8 28 48 19 SMTP .<------- QUIT ----------- . 6 26 46 20 SMTP .--221 closing connection->. 46 66 86 21 TCP .<------- FIN ACK -------- . 0 20 40 22 TCP . -------- ACK ----------->. 0 20 40 23 TCP . ------- FIN ACK -------->. 0 20 40 24 TCP .<------- ACK ----------- . 0 20 40 Measurement Results Total IP Packet bytes: 1778 Message Length (header + body): 301 Total Overhead (TCP header + IP header): 1477 Message as Received Received: by bluejeans. (SMI-8.6/SMI-SVR4) <09>id PAA24890; Fri, 13 Sep 1996 15:34:53 -0700 Date: Fri, 13 Sep 1996 15:34:53 -0700 From: jcheng@bluejeans Message-Id: <199609132234.PAA24890@bluejeans.> To: dnakano@griffey.nwest.airdata.com Subject: test1 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 7.4.2 Message Delivery via POP Mailbox Please refer to Figure 7.2 below, which shows the setup for the following two delivery experiments in detail. The experimental setup at Neda Communications involves the following: - A POP Server: Sun Sparc running Solaris 2.4. 110 CHAPTER 7. EFFICIENCY OF EMSD - An IMAP Server: Sun Sparc running Solaris 2.4. - A "receiver": IBM Thinkpad Laptop running Mi- crosoft TCP/IP on Windows 95 - A sniffer that monitors packet movement at the junc- ture of the above three devices, recording two-way traffic Figure 7.2: Experimental Setup for Delivery Message Delivery Process The message was delivered to the laptop from the POP server. After invoking Microsoft's Internet Explorer 3.0 on the laptop and bringing up MS Internet Mail, the new message was automatically retrieved from the POP server. The sniffer recorded traffic data between the POP server and the recipient. Protocol Trace (arash) (vader) IP_PDU Mailbox Client DATA TCP IP --------------------------------------------------------------- 1 DNS *<-- DNS Query ----------- . * * (dns) 2 DNS * -- DNS Reponse---------->. 7.4. DELIVERY 111 3 TCP .<-- SYN req-------------- . 0 24 44 (c* *onn) 4 TCP . ---SYN ACK ------------->. 0 24 44 5 TCP .<-- ACK ----------------- . 0 20 40 6 TCP . ---POP3 server OK ------>. 117 137 157 (au* *th) 7 TCP .<-- ACK ----------------- . 0 20 40 8 TCP .<-- AUTH twinkie -------- . 14 34 54 9 TCP . ---unknown command ----->. 45 65 85 10 TCP .<-- USER test-1 --------- . 13 33 53 11 TCP . ---user acpt,password? ->. 41 61 81 12 TCP .<-- PASS ****** --------- . 13 33 53 13 TCP . ---+OK ----------------->. 0 20 40 14 TCP . ---+OK mbox open 1 msg-->. 30 50 70 (t* *rans) 15 TCP .<-- STAT ---------------- . 6 26 46 16 TCP . ---+OK 1 542------------>. 11 31 51 17 TCP .<-- UIDL 1 -------------- . 8 28 48 18 TCP . ---unknown command ----->. 43 63 83 19 TCP .<-- TOP 1 0 ------------- . 9 29 49 20 TCP . ---+OK Top of msg ------>. 503 523 543 (_h* *eader) 21 TCP .<-- LIST ---------------- . 6 26 46 22 TCP . ---+OK scan listing----->. 44 64 84 23 TCP .<-- RETR 1 -------------- . 8 28 48 24 TCP . ---+OK 542 msg body---->. 561 581 601 (_b* *ody) 25 TCP .<-- DELE 1 -------------- . 8 28 48 26 TCP . ---+OK msg deleted ----->. 21 41 61 27 TCP .<-- ACK ----------------- . 0 20 40 28 TCP .<-- QUIT ---------------- . 6 26 46 29 TCP . ---+OK ----------------->. 6 26 46 30 TCP . ---Sayonara ------------>. 14 34 54 31 TCP .<-- FIN ACK ------------- . 0 20 40 32 TCP . ---+OK sa--------------->. 6 26 46 33 TCP .<-- FIN ACK ------------- . 0 20 40 34 TCP . ---ACK ----------------->. 0 20 40 --------------------------------------------------------------- Measurement Results Total IP Packet bytes: 2731 Message Length (header+body): 561 Total Overhead: 2170 Message as Received +OK 542 octets.. Return-Path: .. Received: from vader.neda.com by arash.neda.com (5.0/SMI-SVR4)... id AA04601; Wed, 18 Sep 1996 16:35:39 +0800.. 112 CHAPTER 7. EFFICIENCY OF EMSD Date: Wed, 18 Sep 1996 16:35:11 -0700 ().. From: Murat Divringi .. To: test-1@arash.neda.com.. Subject: test6.. Message-Id: .. X-X-Sender: muratd@zahak.neda.com.. Mime-Version: 1.0.. Content-Type: TEXT/PLAIN; charset=US-ASCII.. Content-Length: 66.. Status: .. .. 012345678901234567890123456789 .. 01234567890123456789 .. 0123456789 .. .. 7.4.3 Message Delivery via IMAP Mailbox Please refer to Figure 7.2 above for the experimental setup. Message Delivery Process Message was delivered to the laptop from the IMAP server. After invoking PC-Pine, the new message was automati- cally retrieved from the IMAP server. The sniffer recorded traffic data between the IMAP server and the recipient. Protocol Trace (zahak) (198.62.92.35) IP_PDU Mailbox Client DATA TCP IP --------------------------------------------------------------- 1 DNS *<-- DNS Query ----------- . * * (dns) 2 DNS * -- DNS Reponse---------->. 3 TCP .<-- SYN req-------------- . 0 24 44 (c* *onn) 4 TCP . ---SYN ACK ------------->. 0 24 44 5 TCP .<-- ACK ----------------- . 0 20 40 6 TCP . ---IMAP2 server OK ----->. 78 98 118 (au* *th) 7 TCP .<-- ACK ----------------- . 0 20 40 8 TCP .<-- LOGIN test-1 **** --- . 28 48 68 9 TCP . ---ACK ----------------->. 0 20 40 10 TCP . ---LOGIN completed ----->. 27 47 67 11 TCP .<-- A001 SELECT INBOX --- . 21 41 61 12 TCP . ---ACK ----------------->. 0 20 40 13 TCP . ---A001 cmp 1 EXISTS --->. 110 130 150 14 TCP .<-- A002 NOOP ----------- . 13 33 53 7.4. DELIVERY 113 15 TCP . -- A002 NOOP cmp ------->. 26 46 66 16 TCP .<-- A003 FETCH 1:1 ALL -- . 22 42 62 17 TCP . -- A003 FETCH evlp cmp-->. 364 384 404 (()) 18 TCP .<-- A004 NOOP ----------- . 13 33 53 19 TCP . -- A004 NOOP cmp ------->. 26 46 66 20 TCP .<-- ACK ----------------- . 0 20 40 21 TCP .<-- A005 FETCH 1:1 FULL-- . 23 43 63 22 TCP . -- A005 FETCH 1:1 cmp--->. 431 451 471 (()) 23 TCP .<-- A006 FETCH 1 RFC822hdr. 30 50 70 24 TCP . -- A006 FETCH 1 cmp hdr->. 708 728 748 (_* *header) 25 TCP .<-- A007 FETCH 1 body-----. 24 44 64 26 TCP . -- A007 FETCH 1 cmp body>. 125 145 165 (_* *body) 27 TCP .<-- ACK ----------------- . 0 20 40 28 TCP .<-- A008 SEARCH DELETED --. 23 43 63 29 TCP . -- A008 SEARCH cmp ----->. 38 58 78 30 TCP .<-- A009 LOGOUT --------- . 15 35 55 31 TCP . ---ACK ----------------->. 0 20 40 32 TCP . -- A009 LOGOUT cmp ----->. 80 100 120 33 TCP .<-- FIN ACK ------------- . 0 20 40 34 TCP . ---ACK ----------------->. 0 20 40 35 TCP . -- FIN ACK ------------->. 0 20 40 36 TCP .<---ACK ----------------- . 0 20 40 Measurement Results Total IP Packet bytes: 3593 Message Length (header+body): 833 Total Overhead: 2760 Message as Received * 1 FETCH(RFC822.HEADER -646".. Received: from arash.neda.com (arash [198.62.92.10]) by zahak.neda.com (8.6.10/8.6.10) with SMTP id QAA16710 for ; Wed, 18 Sep 1996 16:42:24-0700.. Received: from vader.neda.com by arash.neda.com (5.0/SMI-SVR4)... id AA04617; Wed, 18 Sep1996 16:41:42 +0800.. Message-Id: <9609182341.AA04617@arash.neda.com>.. From: "test-1" .. To: .. Subject: test6.. Date: Wed,18 Sep 1996 16:41:13 -0700.. X-Msmail-Priority: Normal.. X-Priority: 3.. X-Mailer: Microsoft Internet Mail 4.70.1155.. Mime-Version: 1.0.. Content-Transfer-Encoding: 7bit.. Content-Type: text/plain; charset=ISO-8859-1.. 114 CHAPTER 7. EFFICIENCY OF EMSD Content-Length: 66....).. A00006 OK FETCH completed.. * 1 FETCH (BODY[1] -70".. 012345678901234567890123456789 .. 01234567890123456789 .. 0123456789.. .. ).. A00007 OK FETCH completed.. 7.4.4 EMSD Delivery from Unix to PC Please refer to Figure 7.2 above for this experiment. Message Delivery Process The message was delivered to the laptop, running Neda's EMSD Mail User Agent version 0.9 on Windows 3.1, from Neda's EMSD Message Test Center. The sniffer recorded exchange of data between the recipient and Neda's EMSD Message Test Center which was implementing ESROS. Protocol Trace IP_PDU UA MailServer DATA UDP * * IP --------------------------------------------------------------- 1 UDP .<--Invoke header+body --- . 299 307 327 2 UDP . -----Response ---------->. 2 10 30 3 UDP .<------- Ack ------------ . 2 10 30 --------------------------------------------------------------- Measurement Results Total IP Packet bytes: 387 Message Length (header+body): 299 Total Overhead: 88 Comparing EMSD delivery with SMTP delivery we see that total IP packets in the case of EMSD delivery is down by a factor of 4.6, and total overhead is down by a factor of 16.8. In the case of POP retrieval, total IP bytes in the case of EMSD delivery is down by a factor of 7, and total over- head is down by a factor of 24.7. Finally for IMAP delivery, total IP packets in the case of EMSD delivery is down by a factor of 9.3, and total _ _ ___ ___ ____ _____ _____ _____ _ ______ _ ______ ___ _______ ___ _______ ____ _______ ____________ ____________ ____________ _____________ _____________ ______________ ______________ ______________ ______________ ______________ __________________ 7.5.__RESULTS_SUMMARY___________________ 115 _______________ ___________________ _______________________ EM_____SD _____SMTP _____ _________ ____________Total_number_of_IP_packets_________ 3 _____24 ___* *__ ____________Total_IP_bytes______ _____307 _____1886 _____ ____________Total_MSG_length_______ _____ 206 _____437 _____ ____________(mail_hdr+_mail_body)_____ _____ _____ _____ ____________Total_overhead_ _____101 _____1449 _____ _______ _________ Table__7.2:__Comparison__of__Submission__Traffic__overhead_ for_EMSD_and_SMTP________ _________ _________ _____________ EM_____SD _____SMTP _____IMAP _* *____ POP _____ ___ _______Total_number_of_IP_packets _____ 3 _____24 _____36 * * 3_____4 _____ _______Total_IP_bytes _____387 _____1778 _____3593* * _____2731 _____ _______Total_MSG_length _____ 299 _____301 _____833 * * _____561 _____ _______(mail_hdr+ mail body) _____ _____ _____ * * _____ _____ ______ Total overhead _____88 _____1477 _____2760 * * _____2170 _____ Table 7.3: Comparison of Delivery Traffic Overhead for EMSD, SMTP, IMAP and POP overhead is down by a factor of 31.4. Message as Received and Decoded From jcheng@airdata.com Tue Oct 01 16:16:31 1996 Date: 14 Sep 96 05:48:55 GMT From: jcheng@airdata.com Subject: TEST Subject To: 333.333@ Message-ID: <199609132148.OAA24774@bluejeans.> Content-Length: 66 X-Homepage: Visit our home page at http://www.airdata.com/ id OAA24774; Fri, 13 Sep 1996 14:48:55 -0700 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 7.5 Results Summary The following paragraphs summarize the results obtained above. Results indicate that EMSD compares very favor- ably to other message transfer mechanisms. 116 CHAPTER 7. EFFICIENCY OF EMSD Figure 7.3: Packets Per Delivery 7.6 Conclusion Results of the experiments show the dramatic efficiency gain of EMSD over all the other protocols under test. However, it should be noted that EMSD was specifi- cally designed for efficient short messaging in the context of mobile wireless devices, and thus from inception was meant to be more efficient than protocols designed to han- dle a wider variety of messages. Deployment and use of EMSD similarly is geared towards messaging scenarios that are a subset of the current global messaging world, such as palmtop devices exchanging messages over an airlink. At the other extreme, in a traditional office en- vironment, concerns like efficient use of communications infrastructure and maximizing the battery life of the de- vices do not necessarily apply to tethered devices plugged to a standard wall outlet and a high speed (non-air) net- working infrastructure. Within its own domain, EMSD does its job efficiently and admirably and as is clear from the results of this study, is a highly competitive alternative to other mes- saging protocols. 7.7. ACKNOWLEDGMENTS 117 7.7 Acknowledgments This study was performed with the support and assistance of AT&T Wireless Services. 118 CHAPTER 7. EFFICIENCY OF EMSD Chapter 8 A Brief History of LEAP 8.1 Overview The origins of the LEAP protocols go back to 1994, when they originated as part of the research and development initiatives of McCaw Cellular's wireless data group (now AT&T Wireless Services). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS network also. By 1996 McCaw Cellular was fully committed to pag- ing, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless messaging system. Neda Communications, Inc., an independent consulting company working under con- tract to McCaw Cellular, played a key role in the develop- ment of the required system. Neda Communications had also been involved from the outset in the development of the CDPD specification. In 1997 however, soon after the purchase of McCaw Cellular by AT&T Wireless, the latter company aban- doned the wireless messaging project entirely. Prior to this event, Neda Communications had secured from AT&T the necessary rights to continue independent development of the protocols. Therefore, recognizing the eventual fu- ture need for these protocols, Neda then undertook to continue development of them independently of AT&T. They were eventually completed by Neda, published as RFCs, and now form the basis of the LEAP protocols. 119 120 CHAPTER 8. A BRIEF HISTORY OF LEAP 8.2 Time-Line History A time-line history of the significant events relating to LEAP is provided below. Note that the name LEAP is relatively new; this acronym was coined in early 2000. Prior to 1997, the research and development work which would eventually lead to the creation of LEAP was re- ferred to by the general name of Limited Size Messaging (LSM). Much of the LSM work was sponsored in various ways by McCaw Cellular, then later by AT&T Wireless Services (AWS). Two divisions of AWS are referred to in the time-line below. First, the Wireless Data Divi- sion (WDD) of AWS led much of the LSM-related de- velopment work. WDD was the division of AWS which had major responsibility for the CDPD (Cellular Digital Packet Data) network. Later, the Messaging Division of AWS also made use of the LSM technology in the context of their Narrow- band PCS (NPCS) network. In the context of Narrow- band PCS, LSM was referred to by the general name of pACT (personal Air Communications Technology). Summer 1994: The basic concept of providing wireless e-mail services over the CDPD network was first analyzed. January 1995: AWS began creating the LSM protocol specifications. This work was carried out as a joint effort between the Wireless Data Division, and the NPCS Group within the Messaging Division. January 1995: AWS began development of the reference implementation of the LSM protocols for both Mes- sage Centers and Devices. June 1995: WDD submitted the LSM specifications to the CDPD Forum. The WDD made various LSM- related direction statements, and produced several press releases. This resulted in significant press coverage of LSM. Early development of the WAP protocols had the benefit of seeing this public re- lease of LSM technology, and was based in part upon it. December 1995: Neda's reference implementation of LSM was completed and ready for demonstration and testing. December 1995: AWS sent out Requests For Proposal to potential large-scale Message Center suppliers. 8.2. TIME-LINE HISTORY 121 February 1996: Neda's LSM device implementation in- teroperated with Aldiscon's Message Center. March 1996: Sema Group UK was selected as the pro- duction Message Center supplier by AWS. April 1996: The pACT Vendor Forum was formed. The initial forum members included Ericsson, PCSI, Ald- iscon, AT&T, Casio, NEC, Novatel, Research in Motion, and Sema Group UK. July 1996: Neda completed interoperability tests against the PCSI pACT pager. August 1996: AWS issued the equivalent of a VAR agree- ment to Neda for development and distribution of the LSM software. September 1996: Neda supplied LSM technology (in the form of source code) to Sema Group UK, and as- sisted Sema in the development of Message Center products for AWS. November 1996: AWS changed the LSM strategy for pACT from two-way to "mostly one-way plus." December 1996: Neda's palmtop LSM became ready for general testing. January 1997: Sema Group UK delivered its first re- lease of the LSM Message Center product. January 1997: The Messaging Division of AWS licensed Neda's LSM product set. February 1997: Neda's LSM implementation interoper- ated with Sema Group UK's LSM implementation. February 1997: WDD terminated funding of LSM-related work, and focussed instead on early development of WAP. March 1997: On March 17, AWS terminated the two- way paging project entirely. The NPCS Group of the Messaging Division was abruptly shut down, all employees were reassigned, and all vendor work terminated. Later the same year, the two nation- wide Narrowband PCS licenses belonging to AWS were sold. April 1997: Neda began development of EMSD and the Enhanced Two-Way Paging (ETWP) products. September 1997: Efficient Short Remote Operations (ESRO) protocol was published as Internet RFC 2188. 122 CHAPTER 8. A BRIEF HISTORY OF LEAP June 1998: The Windows CE efficient e-mail implemen- tation was publicly released by Neda. August 1998: ETWP Subscriber Services and web ac- cess were made available. November 1998: Open maintenance organization EMSD.org was established to support public enhancement of the EMSD protocol. January 1999: Open maintenance organization ESRO.org was established to support public enhancement of the ESRO protocol. February 1999: Efficient Mail Submission & Delivery (EMSD) protocol was published as Internet RFC 2524 by Neda. March 2000: Neda made patent-free declarations to the Free Protocols Foundation with respect to RFC 2188 and RFC 2524. This brings us up to the present. Our plans for the future of LEAP are described in a separate article in this Manifesto, entitled The Future of LEAP. 8.3 Acronym Apology We live in the age of the acronym. Our language is now littered with more acronyms than at any other time in history, with more being added every day. We are in- undated, swamped, awash with acronyms. We even have an acronym (TLA) for referring to acronyms. The right acronym can make all the difference be- tween the success and the failure of a product or idea, and for this reason considerable effort sometimes goes into creating just the right acronym. In some cases the result is an acronym which is in good harmony with what it represents: PAWS (Progres- sive Animal Welfare Society); MADD (Mothers Against Drunk Driving). In other cases the acronym has good force and immediacy, but is not especially relevant to what it represents: NOW (National Organization of Women). On the other hand, the striving for a catchy acronym can lead to a labored and contrived construction: DARE (Drug Abuse Resistance Education). In some cases no thought at all is given to the aesthet- ics of the acronym, resulting in one which is both point- less and clumsy: AFTRA (American Federation of Tele- vision and Radio Artists); or even worse, one which car- 8.3. ACRONYM APOLOGY 123 ries an actively negative connotation: SAG (Screen Ac- tors' Guild). As can be imagined, the search for the right acronym for our protocols has given rise to a protracted and some- times emotional debate. Prior to 1997, while the pro- tocols were undergoing development at AT&T Wireless Services, they were referred to as LSM, standing for Lim- ited Size Messaging. When Neda began independent de- velopment of the protocols in 1997, the early, working name for the protocols was EAPS, standing for the Ef- ficient Application Protocol Suite. This of course, is a purely engineering construction, describing the basic na- ture and purpose of the protocols perfectly. However, the word EAPS makes those of us with more aesthetic sensi- bilities physically ill. The working name EAPS was eventually displaced by the name WHIP, standing for the Wireless High-Performance Internet Protocols. WHIP has a good strong personality, and is therefore more likely to remain in the mind of the hearer. An important component of our Manifesto strat- egy is capturing mindshare. In today's deafeningly noisy Internet environment, any assistance is welcome. The price to be paid for this, of course, is that WHIP is contrived and inaccurate. First, the use of the word "Wireless" is inappropriate. There is nothing about the protocols which restricts them to wireless applications. Certainly, they have been designed with the needs of wire- less applications in mind, but their major defining char- acteristic is their efficiency, which makes them appro- priate for use in many applications, wireless and other- wise. Also, the hyphenated phrase "High-Performance" has been deliberately chosen to provide the coveted "H." A more accurate word would be Efficient, but there is nothing remotely memorable about "WEIP." For these reasons, the name WHIP caused consider- able distress among the engineering segment of the de- velopment team. Nevertheless, despite its contrived na- ture, WHIP persisted as a very strong candidate. This is because WHIP provides a compelling and very hard-to- resist payoff: it allows us to say, with spectacular alliter- ative effect: WHIP will whip WAP! However, first and foremost we are engineers, not marketeers, and in the end the inherent inaccuracy of WHIP proved to be intolerable, and regretfully, we abandoned it. Our final choice is LEAP, standing for the Lightweight 124 CHAPTER 8. A BRIEF HISTORY OF LEAP and Efficient Application Protocols.1 This leaves both the engineers and the linguists equally dissatisfied. It has some personality, though not as much as WHIP. And it is reasonably accurate, though not as accurate as EAPS. But it is a choice we can all live with. WHIP is dead. Long live LEAP! _ _ _ _ _ _ _ _ _ _ _ _ _ 1 We are grateful to Warren Sly for proposing this name Chapter 9 The Future of LEAP 9.1 Where We Are Today At the time of writing in June 2000, the basic structure of the LEAP protocols is complete and in place. The key component protocols have been published as Internet RFCs, and public support organizations for the contin- ued development and maintenance of the protocols have been created. All aspects of the LEAP development and maintenance processes conform fully to the basic trilogy of principles that we espouse: patent-freedom, RFC pub- lication, and openness of maintenance. Our next major challenge will be to promote the usage of LEAP throughout the Mobile Messaging industry. We will facilitate and encourage the adoption of LEAP by the following mechanisms: - We will provide free, open-source software imple- mentations of the LEAP protocols for major de- vice platforms such as PalmPilot and Windows CE. This free software will be distributed through http://www.MailMeAnywhere.org. - We will provide free, open-source software imple- mentations of LEAP which are fully integerated with major Message Center platforms such as Send- mail and Qmail. This free software will also ini- tially be distributed through http://www.MailMeAnywhere.org. - We will provide free Subscriber Services. These free services will initially be provided through http://www.ByName.net. The underlying purpose of this is to eliminate all eco- nomic and legal hindrances which might otherwise in- hibit the adoption and usage of LEAP. We accomplish 125 126 CHAPTER 9. THE FUTURE OF LEAP this by means of the patent-freedom of the protocols them- selves, the availability of free, open-source software im- plementations the protocols, and the availability of free support services. The result of this is that the costs of implementing LEAP, other than the associated overhead costs, are zero. By means of this strategy, we intend to make LEAP widespread throughout every segment of the Mobile Mes- saging industry. Our eventual goal is for LEAP to be- come the natural choice for Mobile Messaging applica- tions. 9.2 Invitations to Participate This is an ambitious goal, and cannot be accomplished without the cooperation and participation of others within the industry. We invite others to participate in the follow- ing arenas: Invitations to Protocol Developers - Anyone who is interested in ESRO and EMSD is invited to participate in their development through ESRO.org and EMSD.org. - Additional protocols are needed to enable efficient web browsing. A starting point for this, called EHDP (Efficient Hypertext Delivery Protocol), is currently being created. In developing EHDP we intend to build on the work of WAP and the W3 Consortium, and re-use the ESRO technology. We invite others to join us in this development effort. - Additional protocols are needed to enable efficient access to dictionaries and other look-up data struc- tures. A starting point for this, called EDICT (Ef- ficient Dictionary protocol), is currently being cre- ated. In developing EDICT, we intend to build on the existing work already done in the context of the DICT protocol. We invite others to join us in this development effort. - We anticipate that additional protocols will be needed for a variety of future applications, not all of which can be foreseen at this time. These applications will include such things as efficient implementa- tions of ESRO-based instant messaging, chat, white pages, and others. Invitations to Software Developers 9.3. PREVIEW OF COMING ATTRACTIONS 127 - Based on the existing open-soure software imple- mentations for end-user devices, we invite others to enhance the PalmPilot and Windows CE imple- mentations, and to port LEAP to additional general- purpose device platforms. - We invite telephone manufacturers and wireless data modem manufacturers to include the LEAP proto- cols as an integral part of their next generation de- vices. - We invite Message Center software developers to enhance and better integrate the Message Center LEAP software. Invitations to Subscriber Services Providers We invite Subscriber Services providers such as AOL, Yahoo, MCI and AT&T to participate in the general concept of providing free services based on free protocols and open-source software, and to inte- grate LEAP into their suite of Subscriber Services. A model of this concept is provided by our own free service at www.ByName.net. Invitations to Systems Integrators Each of the LEAP protocols is a component which must be integrated into larger solutions. In particu- lar, we invite the developers of customer-premise Message Centers to incorporate LEAP into their existing products. 9.3 Preview of Coming Attractions Several LEAP-based products and services are currently under development. These include MailMeAnywhere, ByName and ByNumber. 9.3.1 MailMeAnywhere.org In order to make use of the LEAP protocols convenient and widespread, we are providing implementations of the protocols as free and open-source software. Binary for- mats of the software for a variety of platforms are avail- able. In order to provide complete solutions, the LEAP protocol components are integrated with various other free software components, forming consistent and coherent bundles. Since the initial LEAP components are oriented 128 CHAPTER 9. THE FUTURE OF LEAP towards interpersonal messaging, the initial software dis- tribution takes place through http://www.MailMeAnywhere.org. MailMeAnywhere is a distribution center for free and open-source software which relates to LEAP, or which fa- cilitates use of the LEAP protocols. Device implementa- tions are available for a large number of general-purpose device platforms. Message Center implementations have been integrated with Qmail and Sendmail. To learn more about MailMeAnywhere, see the web- site at http://www.MailMeAnywhere.org. 9.3.2 ByName.net and ByNumber.net In order to make use of LEAP protocols convenient and widespread, we are also providing an initial free sub- scriber service which integrates the LEAP protocols into a variety of other services. We are delivering these ser- vices through the ByName.net domain. ByName pro- vides a set of free services, based on free protocols which have been implemented as free software. The ByName services are highly personalized and are based on the user's identity - ByName is based on the user's name, while ByNumber is based on a numerical user ID. A conventional e-mail account typically provides the user with a single address, usually of the form "some- Name@someDomain.com." This provides the user with a single mailbox, to which all mail for that address is sent. This becomes inconvenient when the owner uses the account for multiple types of incoming e-mail. For exam- ple, the user may use the account for both personal and work-related mail, to subscribe to various mailing lists, and to participate in usenet groups. Over time the user may get onto a large number of mailing lists, resulting in an incoming e-mail stream spanning a very wide dynamic range of importance, from urgent personal e-mail, all the way down to meaningless spam. E-mail applications typically deal with this by pro- viding the user with tools to manage and prioritize mail. These consist of inbox sorters and filters to eliminate spam and prioritize incoming messages based on the originator or subject. The ByName.net service provides a better way. By- Name provides you with multiple mailboxes and addresses, each of which can be dedicated to a particular type of e- mail. Furthermore, these various addresses have a simple and uniform naming scheme, based on the one symbol that is most dear and personal to you: your own name. ByName includes your name in the domain part of the 9.3. PREVIEW OF COMING ATTRACTIONS 129 address, and appends various selectors in front of the @ sign. For example, a particular subscriber might have the following addresses and mailboxes: personal@homer.simpson.1.ByName.net office@homer.simpson.1.ByName.net urgent@homer.simpson.1.ByName.net public@homer.simpson.1.ByName.net mobile@homer.simpson.1.ByName.net pager@homer.simpson.1.ByName.net fax@homer.simpson.1.ByName.net emergency@homer.simpson.1.ByName.net This provides our anti-hero with a consistent set of e-mail boxes that he can use for different purposes - one address for personal mail, a different one for work-related mail, and so on. Homer now has control over the routing of his e-mail without having to use a mail sorter or filters. Your home page is also based on your name; Homer's is http://homer.simpson.1.ByName.net. To learn more about the ByName service and to apply for an account, see the website at http://www.ByName.net. The ByNumber.net service provides a complemen- tary service to ByName, based on numbers rather than letters. ByNumber enables devices with digit-only orig- ination capability (e.g. conventional telephone keypads) to send e-mail messages, and provides a unified way of sending messages to pagers, two-way pagers, faxes and e-mail accounts. To learn more about the ByNumber service, see the website at http://www.ByNumber.net. 130 CHAPTER 9. THE FUTURE OF LEAP Part II LEAPing Over Closed Solutions 131 Chapter 10 The WAP Trap 10.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. 10.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 133 134 CHAPTER 10. THE WAP TRAP 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 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. 10.1.2 Characteristics of Successful Proto- cols 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 10.1. INTRODUCTION 135 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 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 [65 ]. 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. 10.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 136 CHAPTER 10. THE WAP TRAP 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: - LEAP: One Alternative to WAP [64 ]. 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 [65 ]. This document provides a complete analysis of the industry, and a detailed description of the LEAP protocols. 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. 10.2. WAP - A PROCEDURAL FRAUD 137 - Text Only: Provides the document in text-only for- mat. 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. 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 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. 10.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. 138 CHAPTER 10. THE WAP TRAP 10.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. 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 10.2. WAP - A PROCEDURAL FRAUD 139 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. 10.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- 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. 140 CHAPTER 10. THE WAP TRAP - 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. 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 [86 ]. 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. 10.2. WAP - A PROCEDURAL FRAUD 141 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. 10.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: - 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 [17 ]. Section 10 of this 142 CHAPTER 10. THE WAP TRAP 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. 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 [63 ]. 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 10.2. WAP - A PROCEDURAL FRAUD 143 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 [25 ], "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. 144 CHAPTER 10. THE WAP TRAP 10.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 [86 ], 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-mail discussion thread on the IETF mailing list [50 ] makes this point quite plainly - this thread demonstrates clear consensus among professionals that the WAP speci- fications 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. 10.3.1 User Interface Assumptions A basic principle of data communications protocol de- sign is that communications considerations must be de- 10.3. WAP - A TECHNICAL FAILURE 145 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- ciples. In fact, this is a strategic design error. 10.3.2 Extreme Accommodation to Exist- ing 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. 146 CHAPTER 10. THE WAP TRAP 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 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. 10.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 10.3. WAP - A TECHNICAL FAILURE 147 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. Specif- ically, T/TCP [16 ] and ESRO [91 ], 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 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. 10.3.4 Vulnerable Wireless Transport Layer Security (WTLS) In his paper Attacks against the WAP WTLS Protocol [52 ], author Saarinen describes in detail a number of security 148 CHAPTER 10. THE WAP TRAP 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- ficulties. 10.3.5 Bungled Protocol Number Assign- ment As Khare discusses in greater detail [86 ], 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. 10.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 10.4. WAP - A BASIC MISCONCEPTION 149 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. 10.4.1 The Wrong Answer Initially: Mo- bile 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' [51 ] "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 150 CHAPTER 10. THE WAP TRAP 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. 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 10.4. WAP - A BASIC MISCONCEPTION 151 from its enduring day-to-day usefulness. 10.4.2 The Right Answer Initially: Mobile Messaging 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- 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. 10.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. 152 CHAPTER 10. THE WAP TRAP 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 [19 ] "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. 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 10.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. 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 10.4. WAP - A BASIC MISCONCEPTION 153 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 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. 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 [19 ]. Voice Interface Adequate The screen user interface limitations of a cell phone are so severe, in fact, that its data access capabilities are almost 154 CHAPTER 10. THE WAP TRAP 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- 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. 10.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- 10.6. PREVENTING THE HARM OF WAP 155 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? 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 [24 ], "Companies in the WAP Forum generally set- tle licensing and cross-licensing deals between themselves." 10.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. 156 CHAPTER 10. THE WAP TRAP - Adopt a viable alternative to WAP. 10.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 10.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. Work- ing to reform the WAP Forum, therefore, is not a useful approach. 10.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. 10.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 10.6. PREVENTING THE HARM OF WAP 157 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. 10.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. 10.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. 158 CHAPTER 10. THE WAP TRAP 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. 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. 10.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[91 ] 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 10.7. LEAP: ONE ALTERNATIVE TO WAP 159 RFC-2524 [5 ] 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/. 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 Section 10.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 [63 ]. 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 [64 ], 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 [65 ], 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. 160 CHAPTER 10. THE WAP TRAP Chapter 11 LEAP: One Alternative to WAP 11.1 Introduction Over the last few years, data communications has ex- panded dramatically and forcefully into the wireless envi- ronment. A major new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality has placed an en- tirely new set of requirements on the underlying commu- nications protocols: they must now provide the power efficiency demanded by hand-held wireless devices, to- gether with the bandwidth efficiency demanded by wide area wireless networks. Existing Internet protocols do not adequately meet these requirements. Therefore a new generation of effi- cient protocols is needed, to satisfy the demands of wire- less applications. At some point, the wireless data com- munications industry must agree on a single set of proto- cols that satisfies its requirements. 11.1.1 The WAP Trap In April 1998, a business association called the WAP Fo- rum published the Wireless Application Protocol, or WAP. WAP is a set of specifications for wireless data commu- nications using hand-held devices such as mobile phones and palmtop computers. The WAP specification provides the users of these devices with mobile data communica- tions capabilities such as web-browsing and e-mail. The WAP specification purports to be an open, license- free protocol that will unify and promote the growth of 161 162CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP the wireless industry. The WAP Forum claims that the WAP specification satisfies all the requirements neces- sary to become the industry standard, and is aggressively promoting it as such. In a previous article entitled The WAP Trap [66 ], how- ever, we have argued that WAP is utterly unfit for its claimed purpose. In that article we described the desir- able characteristics of enduring, industry-building proto- cols, and we demonstrated that the WAP protocols lack all of them. Among other things we showed that WAP is the result of a closed design process within a members-only club, that it remains tightly controlled by the WAP Forum, is crippled by patent restrictions, and is riddled with techni- cal design errors. Our conclusion was that the WAP specification is not a genuine engineering construct; it is a bogus marketing one. Its purpose is to create unfair market advantage and bring short-term financial gain to its developers, rather than to provide long-term benefit to the industry at large and the consumer. Far from being an enabling force in the wireless industry, WAP is a poorly-designed red herring created by narrow business self-interests. In the long run WAP cannot survive as a viable so- lution. In the short run, however, it can do considerable harm to the industry and the consumer. In The WAP Trap we went on to discuss the steps that can be taken to prevent this harm. A crucial step will be for the industry to adopt an alternative to WAP as soon as possible. We concluded the article by presenting one al- ternative: LEAP, the Lightweight & Efficient Application Protocols. 11.1.2 About this Document In the present article, we will carry on where the previous article left off. The scope of The WAP Trap was limited to a critique of WAP, without actively promoting any par- ticular alternative. The present article, on the other hand, is frankly partisan; our purpose here is to promote LEAP as an open alternative to WAP. The authors of this article are participants in Free Pro- tocols Foundation (FPF) activities, under whose auspices this article is being written. The mission of the FPF is to provide support for the development, maintenance, and promotion of patent-free protocols and software. It pro- vides a forum in which developers can declare publicly that the protocols and/or software they have developed 11.2. THE NEED FOR EFFICIENCY 163 are intended to be patent-free, and that it is their intention to keep them permanently patent-free. In addition, where the existence of patented compo- nents within protocols and/or software threatens their un- restricted usage and implementation, the FPF supports the promotion of patent-free alternative protocols and/or software. It is for this purpose that the current article is being written: to promote LEAP as a patent-free alterna- tive to WAP. In this article we will describe LEAP from both a technical and a procedural point of view. We will com- pare it to WAP, and will demonstrate that it has all the desired protocol characteristics that WAP lacks. Our con- clusion will be that LEAP is destined to play a key role in the growth of the Mobile Messaging industry. This article is one of several we have written that an- alyze the current status of the wireless data communi- cations industry, criticize WAP, and present our view of what is truly needed to promote the growth of the indus- try. Related articles are: - The WAP Trap [66 ]. Provides a critique of the WAP specification, and sets the stage for the current pa- per. Available at http://www.freeProtocols.org/wapTrap. - The LEAP Manifesto [65 ]. Provides a complete analysis of the industry, and a detailed description of the LEAP protocols. The LEAP Manifesto is available at http://www.LeapForum.org/LEAP/Manifesto/roadMap/index. html. 11.2 The Need for Efficiency Engineering is the art of making intelligent trade-offs be- tween conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power efficiency, and band- width efficiency. The 1980s and 1990s were the decades of simple pro- tocols - protocols such as the very aptly named Simple Mail Transfer Protocol (SMTP), and Simple Network Man- agement Protocol (SNMP). A great deal of the success of these and other Internet protocols can be attributed to their simplicity. 164CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP The first generation of network engineers and net- work operators were only able to view network commu- nications in relatively simple terms. It was appropriate to cater to that simplicity with simple protocols. A key reason for the success of these early protocols is the lack of technical sophistication on the part of first-generation network engineers and operators. Simple protocols are easier to make widespread than "good" protocols (meaning those which have better ca- pabilities and performance), for the basic reason that net- work engineers and operators are able to adopt and im- plement simple protocols much more easily than "good" protocols. However, things have changed. Network communi- cations has now expanded into the wireless and mobile data communications arena, and wireless applications de- mand efficiency. The move to wide-area wireless has significantly shifted the location of the ideal engineering balance between simplicity and performance - moving it away from simplicity, and towards performance. We therefore need a new generation of high-performance, efficient protocols, to cater to the demands of wireless applications. The point is sometimes made that the need for efficiency in the wireless arena is a temporary one - that advances in wireless engineering technology in the form of third generation (3G) systems will eliminate ex- isting bandwidth limitations, obviating the need for ef- ficient protocols. As long as the capacity of wireless networks remains finite, however, the need for efficiency will persist. Efficient usage is an inherent requirement for any finite resource, therefore the requirement for efficient bandwidth usage and battery longevity will remain. Thus far, professional protocol and standards produc- ing associations, most notably represented by the IETF, have failed to produce an acceptable specification. The IETF continues to represent the tradition of simple proto- cols, a tradition which wireless communications has now made obsolete. Unfortunately, the IETF remains rooted in this tradition, and has not adapted to the new reali- ties of wireless communications. Until it does so, the IETF will remain ineffective as a protocols and standards body. In the area of efficient protocols, the IETF is simply bankrupt. 11.3. LEAP: THE LIGHTWEIGHT & EFFICIENT APPLICATION PROTOCOLS 165 11.3 LEAP: The Lightweight & Ef- ficient Application Protocols It is now time for a new generation of protocols to be im- plemented, designed to address the need for performance, rather than simplicity. The Lightweight & Efficient Application Protocols, or LEAP, are designed precisely to address this need. LEAP is the general framework for a set of high-performance, efficient protocols which are ideal for mobile and wire- less applications. LEAP is designed to address the tech- nical requirements of the wireless data communications industry, and is oriented towards providing the greatest benefit to the industry and the consumer. The LEAP protocols are patent-free, and open-source implementations of the protocols are being made avail- able for a variety of devices and message-center plat- forms. The protocols are thus ready and available, and can be quickly distributed and implemented as a viable alternative to WAP. 11.3.1 A Brief History of LEAP LEAP originated in 1994 as part of the research and de- velopment initiatives of McCaw Cellular's wireless data group (now AT&T Wireless). The development work that would eventually lead to LEAP was initially undertaken in the context of the CDPD network; its scope was later expanded to include the Narrowband PCS network also. By 1996 McCaw Cellular was fully committed to pag- ing, had recently purchased two nationwide narrowband wireless PCS licenses, and wished to develop an efficient wireless message transport and delivery system. Neda Communications, Inc., an independent consulting com- pany working under contract to McCaw Cellular, played a significant role in the development of the required sys- tem. Neda Communications had also been involved from the outset in the development of the CDPD specification. In 1997 however, soon after the purchase of McCaw Cellular by AT&T, the company abandoned narrowband PCS paging altogether. Prior to this event, Neda Commu- nications had secured from AT&T the necessary rights to continue independent development of the protocols. Therefore, recognizing the eventual future need for these protocols, Neda then undertook to continue development of the protocols independently of AT&T. They were even- tually completed by Neda, published as RFCs, and now form the cornerstone of the LEAP protocols. 166CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP 11.3.2 Technical Overview of LEAP In this section we will provide a brief technical overview of the LEAP protocols. For a detailed description of LEAP, refer to The LEAP Manifesto [65 ], available at http://www.LeapForum.org/LEAP/Manifesto/roadMap/index. html. LEAP is a set of wireless application protocols that are optimized for delivering small messages over wireless networks. Wireless networks are constrained by band- width limitations, and the hand-held devices they serve are constrained by limitations such as display size, bat- tery capacity, and memory capacity. These constraints place a high premium on the efficiency of data transfer. The LEAP protocols are up to five time more effi- cient than the ubiquitous SMTP e-mail messaging pro- tocols. This increased efficiency translates into longer battery life for mobile phones, PDAs and other wireless Internet devices. Layering of LEAP The LEAP protocols are layered. The lower layer, called Efficient Short Remote Operations (ESRO), provides reli- able connectionless transport services which can be used for a variety of applications. For example, in addition to mobile messaging services, ESRO can be used as a transport service for credit card verification applications and efficient micro browsers. On top of ESRO is the layer called EMSD. EMSD is a messaging protocol that is highly optimized for the submission and delivery of short Internet e-mail messages. Various other LEAP protocol components are in the process of being designed and implemented. See The Fu- ture of LEAP article in The LEAP Manifesto for more de- tails. ESRO, Efficient Short Remote Operations All efficient applications have the requirement for an ef- ficient transport mechanism. For this reason, the initial focus of the protocol development effort has been on cre- ating a general efficient transport mechanism. The re- sulting protocol is referred to as Efficient Short Remote Operations, or ESRO. ESRO is a reliable connectionless transport mechanism, forming the foundation for the de- velopment of efficient protocols when TCP is too much and UDP is too little. 11.3. LEAP: THE LIGHTWEIGHT & EFFICIENT APPLICATION PROTOCOLS 167 ESRO was published in September 1997 as Internet RFC-2188 [91 ]. Additional information about ESRO is available at http://www.esro.org/ EMSD, Efficient Mail Submission and Delivery The Efficient Mail Submission and Delivery (EMSD) pro- tocol is built on top of ESRO, and is designed to address the Mobile Messaging application. EMSD provides for the submission and delivery of short (4 kilobytes or less) Internet e-mail messages. EMSD meets or exceeds the level of functionality, reliability and security provided by the existing SMTP protocols. EMSD is a great deal more efficient than existing Internet e-mail protocols. EMSD was published in March 1999 as Internet RFC- 2524 [5 ]. Additional information about EMSD is avail- able at http://www.emsd.org/ Initial Focus: Mobile Messaging The need for efficient protocols extends across all aspects of wireless data communications, including e-mail, web browsing, and other applications. The LEAP architecture accommodates all of these applications. The initial LEAP protocols, however, are designed to support the Mobile Messaging application, since this is the dominant applica- tion for wide-area wireless networks. Subsequent LEAP protocols are expected to address other applications as necessary. 11.3.3 Processes and Procedures We believe that a public protocol must conform to each of the following basic, fundamental principles: - Patent-freedom - RFC publication - Maintenance by open Working Groups Each of these provides a vital assurance of protocol integrity. Patent-freedom ensures that a patent-holder can- not subvert free-market competition among products and services based on the protocol. RFC publication ensures that the protocol is freely available to anyone who wishes to use it. And maintenance by open Working Groups ensures that development of the protocol takes place by democratic, rather than oligarchic, processes. 168CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP This trilogy of principles represent the most basic guar- antees of the integrity of a protocol. The LEAP protocols are intended to be open in the fullest sense of the word; they are intended to be freely and permanently available, subject to public review and revision, and without usage restrictions of any kind. There- fore the processes and procedures used throughout the de- velopment and maintenance of the LEAP protocols have been such as to endow them with these characteristics, and to ensure their integrity as public protocols. Complete details of the LEAP development process are provided in a separate article within The LEAP Man- ifesto entitled The LEAP Protocol Development Model. The major aspects of the development process are sum- marized in the following sections. Freedom from Patents As discussed in The WAP Trap, a highly desirable at- tribute of an industry standard protocol is that it be free from patents. The presence of patented components within a protocol undermines the ultimate purpose of the proto- col: its unrestricted adoption and usage. The development and maintenance of the LEAP pro- tocols conforms fully to the policies and procedures of the Free Protocols Foundation. In particular, Neda has declared to the Free Protocols Foundation that the LEAP protocols are patent-free to the best of its knowledge, and that it intends to keep them patent-free permanently. For more information see http://www.FreeProtocols.org. RFC Publication Both protocols have been published as Internet RFCs; ESRO in September 1997 as RFC-2188 [91 ], and EMSD in March 1999 as RFC-2524 [5 ]. RFC publication is the mainstream Internet publishing procedure, ensuring that the protocols are freely, easily and permanently accessi- ble to anyone who wishes to use them. Open Maintenance Organizations To provide an open forum for the continued development and maintenance of the LEAP protocols, Neda has estab- lished a public organization for each protocol. The ESRO and EMSD protocols are maintained, re- spectively, by ESRO.org at http://www.esro.org/, and by EMSD.org at http://www.emsd.org/. _ _ ___ ___ ____ _____ _____ ______ _______ _______ _______ _______ ________ ________ ________ _________ _________ __________ ___________ ___________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ________________ 11.4.___COMPARISON_OF_LEAP_TO_WAP__________ 169 ______________ _________________ ____________________ WAP ______ * * LEAP _____ _________ _______Subject_to_known_patent_restrictions_____ Pat_____e* *nt-free _____ _______Self-published_by_the_WAP_Forum________ Pub_____l* *ished as Internet RFCs _____ _______Revisions_subject_to_change_without_notice___ All_____r* *evisions permanently fixed _____ _______Maintained_by_the_WAP_Forum___ Mai_____n* *tained by open working groups _____ _____ Re-invention of existing protocols Efficienc* *y-optimizing extensions to existing _____ _______________ protoco__* *_______ls _________ ____ Tailored to mobile phone user interface char- User inte* *rface independent ____ ___________acteristics___ __* *_______ _________ _______Inherent_security_vulnerability_ Imp_____o* *ses no security assumptions _____ _______Inconsistent_protocol number assignment Con_____s* *istent protocol number assignment _____ ______ Initial focus: web browsing Ini_____t* *ial focus: messaging _____ Table 11.1: WAP versus LEAP Each of these organizations allows public review of the respective protocol, and provides mechanisms for en- hancement of the protocol as a result of collective expe- rience. Any interested person may participate in the further development of the protocols. Participation in the devel- opment process is entirely open and non-exclusive; there are no membership fees. The only requirement is that participants must adhere to the principles and procedures of the Free Protocols Foundation, thus ensuring that the protocols remain permanently patent-free. 11.4 Comparison of LEAP to WAP In The WAP Trap, we enumerated the characteristics of the WAP specifications that make them wholly unfit to play the role of an enabling industry protocol. These characteristics are summarized in Table 11.1, along with the corresponding characteristics of the LEAP protocols. 11.4.1 Patent Restrictions As noted in The WAP Trap, the WAP specifications in- clude patented components. Unlike WAP, the LEAP pro- tocols are entirely patent-free. 11.4.2 Openness of Publication As noted previously, the LEAP protocols are published as Internet RFCs, ensuring permanent, unrestricted avail- ability of the protocols. The WAP specifications, on the 170CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP other hand, are self-published by the WAP Forum, and therefore do not carry the same assurances of unrestricted availability. The availability and permanence of the WAP specifications is only as good as that of the WAP Forum itself. Furthermore, in order to download any particular WAP specification, a user must agree to a license agreement. By contrast, the LEAP protocols may be downloaded and distributed without any restrictions. In addition, the WAP Forum's publishing philosophy carries no guarantee of stability. As of February 2000, each WAP specification carries on its title page the dis- claimer, "This document is subject to change without no- tice." By virtue of the RFC publication process, on the other hand, individual revisions of the LEAP protocols are permanently fixed. 11.4.3 Openness of Maintenance LEAP's open maintenance processes are also in sharp contrast to WAP. Participation in the development of the WAP specifications requires payment of the $27,000 WAP Forum membership fee (as of February 2000), and takes place entirely behind closed doors. Unlike WAP, the LEAP protocols are maintained by public maintenance organi- zations in which anyone is free to participate. 11.4.4 Technical Deficiencies The WAP protocols also include numerous technical defi- ciencies. For example, WAP is a broad-scope re-invention of existing protocols. The LEAP protocols, by contrast, consist of a small number of independent protocols that complement existing Internet protocols. Other WAP defi- ciencies are listed in Table 11.1; for a detailed discussion, see The WAP Trap. 11.4.5 Initial Focus There are also significant conceptual differences between LEAP and WAP, of which we will mention two here. First, LEAP is primarily oriented towards the mobile mes- saging (i.e. e-mail) application, whereas WAP is primar- ily oriented towards mobile web browsing. We believe that this represents a serious misunderstanding of the mo- bile data communications industry on the part of the WAP Forum. Hand-held mobile devices are extremely well- suited to the e-mail application, whereas their severe user 11.4. COMPARISON OF LEAP TO WAP 171 Figure 11.1: Wireless Internet Hype vs. Reality interface limitations render them highly ill-suited to web browsing. Second, LEAP and WAP take very different approaches to the messaging application. The LEAP approach, em- bodied in the EMSD protocol, is a complete and efficient submission and delivery model. The WAP approach, on the other hand, is a mailbox access and selective message retrieval model. A consequence of this is that the WAP protocol has several unresolved issues relating to message delivery. For example, the WAP protocol does not support the "push" model of message delivery, in which time-critical mes- sages are actively delivered to the recipient. The LEAP protocol, by contrast, fully supports the "push" model. 11.4.6 Hype versus Reality Our view of the evolution of the wireless Internet industry is illustrated in Figure 11.1. The early history of this in- dustry is already known to us; in recent years the industry has undergone extremely rapid growth. And in the long 172CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP term, there is general consensus among analysts that the industry is destined for continued strong and sustained growth. So the early history is known, and the eventual his- tory we can predict with confidence. But what about the more immediate future? Our view is that, largely thanks to the WAP Forum, the industry has been significantly over-hyped, with the result that expectations now greatly exceed realities. Our prediction is that this period of soar- ing expectation will be followed by a period of general disillusionment and frustration, as these expectations are inevitably disappointed. Sooner or later the industry must adopt a more real- istic understanding of its technological and business chal- lenges. Part of this understanding will consist of the recog- nition that the wireless industry must adopt a single set of truly open protocols. Only then will the industry be able to undergo stable and sustained growth. WAP represents the era of hype and disillusionment. LEAP represents the era of realism and maturity. 11.5 Making LEAP Widespread Thus far our discussion has been entirely theoretical; we have demonstrated on paper that WAP is not viable, and that LEAP has all the characteristics necessary to be con- sidered a viable alternative. However this is all academic until the protocols are implemented as software and de- ployed in real world systems. In order for the LEAP protocols to become widely used, they must be implemented in the form of software solutions that are readily available for deployment by end- users. To this end, we have created software implementa- tions of the protocols for most common platforms. Proto- col engines have been implemented in the form of portable code which has been ported to a variety of platforms. On the device side, software has been implemented for pagers and cell-phones; for hand-held PCs and Palm Pi- lot (Palm OS, Windows CE, Palm PC); for Windows 98, Windows 95, and Windows NT; and for Pine (UNIX, Windows, DOS). On the message center side, software has been implemented for Solaris, Linux and NT. All of this software will be made publicly available in the form of free software in open-source format. At present, we have created the structures necessary to al- low ready access and downloading of the software in bi- nary form. Foundation libraries of LEAP protocol en- 11.6. OTHER ALTERNATIVES TO WAP 173 gines called the "Open C Platform (OCP)" are subject to the GNU Library General Public License and are avail- able as open-source software. The software is being made available at http://www.MailMeAnywhere.org/. We expect to have the ESRO protocol engine software components subject to the GNU General Public License available at this location by September 2000. We expect the availability of the entire suite of open-source software implementations described above to be completed by De- cember 2000. As noted above, the initial emphasis of LEAP is on the mobile messaging application. Protocol engines are only a single component of a bigger picture; in order to provide complete solutions to the user it is necessary to integrate these protocols into other existing pieces of soft- ware. Fully-integrated solutions which combine LEAP with other open-source and free software packages such as qmail, sendmail, fetchmail will also be made available. We invite those interested in using, enhancing, port- ing and integrating this software to join the relevant mail- ing lists at http://www.MailMeAnywhere.org/ We will also initially "prime the pump" by provid- ing free subscriber services through ByNumber.net and ByName.net. This will provide initial support for the im- plementation of the protocols in end-user devices. Usage of the protocols among a sufficient number of user de- vices will then provide the motivation for usage among the message center systems. 11.6 Other Alternatives to WAP In this article we have promoted LEAP as one alterna- tive to WAP. An obvious question is: Are there any other alternatives? A 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 specifi- cation which addresses the requirements for efficient Mo- bile Messaging can be expected from them in the near fu- ture. 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 174CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP these sources. There is general consensus within the in- dustry that an alternative protocol to WAP is required. Apart from LEAP, however, no such protocol has yet been publicly proposed. To the best of our knowledge, therefore, LEAP is the only viable open and patent-free alternative to WAP. 11.7 Summary All of the basic components that are needed to launch LEAP are complete, in place, and ready to go. These components are: The Protocols Themselves. The protocols are well-designed, meet all the technical requirements of the indus- try, and are published as RFC-2188 and RFC-2524. The complete text of the RFCs is available at http://www.rfc-editor.org. Freedom from Patents. The protocols have been declared to the Free Protocols Foundation as patent-free. For more information see http://www.FreeProtocols.org. Open Maintenance Organizations. The protocols are main- tained by open and public organizations at http://www.esro.org, http://www.emsd.org, and http://www.LeapForum.org. Open-Source Software Implementations. These are in the process of being made available for all major platforms and end-user devices. For details see http://www.MailMeAnywhere.org. Free Subscriber Services. Provided to support initial de- ployment of the protocols in end-user devices. For details see http://www.ByNumber.net and http://www.ByName.net. Together, these components represent a complete recipe for the success of LEAP. The protocols themselves are open and immediately available, and open-source imple- mentations of the protocols are in the process of being made available as free software. The combination of free protocols and open-source software is something which has enormous power. It is this combination of factors which has driven the over- whelming success of other industry standards such as Linux and the Web (HTTP/HTML). We believe that this same combination of factors will drive the acceptance of LEAP in the wireless data communications industry. 11.7. SUMMARY 175 Finally, we do not claim that LEAP is technically ideal - like all engineering solutions it includes compro- mises. What we do claim is that LEAP is a good solution, and that its processes have integrity. Where the LEAP protocols fall short of the industry needs, the open main- tenance processes will provide a mechanism by which they can evolve into a better solution. 11.7.1 The LEAP Manifesto Every aspect of LEAP is described in The LEAP Mani- festo [65 ], available at http://www.LeapForum.org/LEAP/Manifesto/roadMap/index. html. The LEAP Manifesto includes a technical descrip- tion of the LEAP protocols themselves, and a descrip- tion of all the components required to encourage their widespread usage. The LEAP Manifesto consists of the following articles: Executive Summary. An overview summary of the en- tire LEAP Manifesto. Overview of the LEAP Protocols. A general overview description of the LEAP protocols. The LEAP Protocol Development Model. A description of the processes used to develop the LEAP proto- cols, and how and why these processes differ from the conventional development process. This arti- cle also includes a criticism of the IETF protocol development processes. EMSD: The LEAP E-Mail Component. A technical de- scription of EMSD, the e-mail component of LEAP. ESRO: A Foundation for the Development of Efficient Protocols. A technical description of ESRO, the transport mech- anism component of LEAP. Efficiency of EMSD. A technical paper analyzing the ef- ficiency characteristics of EMSD and comparing its efficiency to other e-mail protocols. EMSD on Windows CE. A technical paper describing the architecture and implementation of EMSD on Windows CE devices. EMSD on Palm OS. A technical paper describing the ar- chitecture and implementation of EMSD on Palm OS devices. A Brief History of LEAP. A summary of the major events in the evolution of the LEAP protocols. 176CHAPTER 11. LEAP: ONE ALTERNATIVE TO WAP The Future of LEAP. A description of the planned fu- ture development of LEAP, including descriptions of several LEAP-based products and services which are currently under development. The WAP Trap. A detailed criticism of a set of speci- fications called the Wireless Application Protocol, or WAP. This article demonstrates that WAP is en- tirely inappropriate to play the role of a Mobile Messaging industry standard. LEAP: One Alternative to WAP. A point-by-point com- parison of the LEAP protocols to the WAP specifi- cations. This article compares and contrasts LEAP with WAP, and demonstrates that LEAP has all the desired characteristics of an industry-enabling pro- tocol that WAP lacks. Operation WhiteBerry. A description of how all the ca- pabilities of the closed RIM BlackBerry mobile mes- saging solution can be duplicated using existing software implementations of LEAP, and existing off-the-shelf hardware components. Strategy for Making LEAP Widespread. A description of our strategy for encouraging widespread usage of the LEAP protocols, including the distribution of open-source software implementations of the pro- tocols, and the availability of free subscriber ser- vices. Trying Out LEAP. A step-by-step, hands-on demonstra- tion of how the LEAP protocols can be used to turn any Windows CE device into a fully functional Mo- bile Messaging device. Lessons from History: Comparitive Case Studies. An analysis of the factors which lead to the success or failure of protocols, including discussions of sev- eral historical case studies. The Mobile Messaging Industry. An overview of the Mo- bile Messaging industry, and a description of the essential factors that are required for its long term success and growth. Chapter 12 WAP Scraps What can be salvaged from what remains of WAP? 12.1 Introduction We first published the article The WAP Trap: An Expose of the Wireless Application Protocol [66 ] in April 2000. At that time it was the most comprehensive condemnation of WAP written to date. In it we demonstrated that WAP is crippled by patents, the result of a closed design pro- cess, inappropriately controlled by the WAP Forum, and riddled with technical design errors. We exposed WAP for what it is: a fraudulent marketing construct. Our con- clusion was that WAP must be rejected and replaced with a set of truly open, patent-free, technically sound, main- stream Internet protocols. 12.1.1 Claiming the Day In April 2000 we were one of a relatively small number of voices sounding the WAP alarm. At that time WAP was massively over-hyped, and a major portion of the wireless industry had succumbed to the hype. To use a phrase right out of the WAP hype machine: WAP was hot. But in September 2001, 17 months after initial pub- lication of The WAP Trap, our analysis and predictions have been convincingly validated. The message in The WAP Trap resonated within the industry, and it has experienced widespread distribution and readership. Partly because of this, there is now a growing awareness of the fundamental fraudulence of WAP. 177 178 CHAPTER 12. WAP SCRAPS The engineering community was never seriously taken in by WAP in the first place, and our raising of the alarm has had the desired effect among the business and me- dia communities. Numerous articles have been published which support our position, including: - WapLash. Meg McGinity, Inter@ctive Week, July 31, 2000. [53 ] - WAP 2.0: Mature Enough for Flight? Keri Schreiner, IEEE Internet Computing, November/December 2000. [87 ] - WAP Usability: Deja Vu: 1994 All Over Again. Marc Ramsay and Jakob Nielsen, Nielsen Norman Group, December 2000. [81 ] The body of published articles includes several which quote us directly or otherwise build on our work. The above articles and others are available on the Free Proto- cols Foundation website at http://www.FreeProtocols.org/harmOfWap/main.html. We will continue to augment the Free Protocols Founda- tion library with additional relevant articles as they ap- pear. In addition, The WAP Trap has now been translated into French, under the title Le WAP a la Trappe. The translation of The WAP Trap into French represents an- other step forward in our campaign to expose WAP. Both English and French versions of the paper are available in HTML, PDF and PostScript formats on the Free Proto- cols Foundation website at http://www.FreeProtocols.org/wapTrap/index.html. Though the tide of favor has turned against it, the WAP hype machine continues to operate. And there re- main many within the industry who are still unaware of the problems with WAP. We will continue to counter the WAP hype by writing and distributing articles such as The WAP Trap and WAP Scraps. However, the primary purpose of this article is not just to say NO to WAP. This article focuses on what needs to be done after WAP. 12.1.2 Mobile Web Browsing: An Open In- dustry Model As we discussed in The WAP Trap, WAP has many short- comings. But one of the major issues from a consumer- acceptance point of view is that it represents the wrong starting-point wireless Internet application. Though wire- less web browsing certainly has its place, its end-user 12.1. INTRODUCTION 179 value proposition is entirely overshadowed by that of an- other wireless Internet application: Mobile Messaging. This statement is fully supported by the user experi- ences and market acceptance of these two applications. The extremely poor end-user experience of WAP-based web browsing is very well documented in the Nielsen Norman Group field study report WAP Usability: Deja Vu: 1994 All Over Again [81 ]. By contrast, the end-user value of Mobile Messaging is well evidenced by the mar- ket acceptance of BlackBerry and other messaging sys- tems, which are enjoying widespread popularity. BlackBerry and other Mobile Messaging solutions are experiencing this popularity despite the fact that they are all closed, proprietary systems. In order for the Mobile Messaging industry to reach its full potential, these closed systems must be replaced by an open industry model, based on truly open and free protocols. All the com- ponents required to enable this, including the necessary open protocols, are now in place; and the development of the open Mobile Messaging industry is now assured. For a detailed discussion of the open Mobile Messaging industry, see the Manifesto article Operation WhiteBerry [8 ]. As in the case of Mobile Messaging, an open industry model is essential in order for the Mobile Web Browsing industry to reach its full potential. With the open Mobile Messaging industry well on its way, it is now time to fo- cus attention on the development of the open Mobile Web Browsing industry. 12.1.3 About this Document This paper is a follow-on paper to The WAP Trap. Both papers are endorsed by and published by the Free Proto- cols Foundation (FPF). The FPF is an independent public forum dedicated to the support of patent-free protocols and software. The FPF regards protocol and software patents as being highly detrimental to the industry and the consumer, and part of the FPF mandate is to oppose ex- ceptionally harmful patents and patented protocols when they appear. One such patented protocol is WAP. The FPF is a U.S. non-profit organization, and is tax- exempt under Section 501(c)(3) of the Internal Revenue Service regulations. All monetary contributions made to the FPF are tax deductible in accordance with these reg- ulations. Any organization or individual wishing to sup- port the goals of the FPF is encouraged to participate by joining the FPF mailing list, or by making an appropriate 180 CHAPTER 12. WAP SCRAPS donation. For more information see the FPF website at http://www.freeprotocols.org. One of the ways in which the FPF opposes patented protocols is by supporting and endorsing patent-free al- ternative protocols. This paper describes how WAP can be avoided by use of patent-free alternatives, and is there- fore fully consistent with this mission. The purpose of this paper is to describe the development of the open Mo- bile Web Browsing industry. In particular, we will: - Show how recent developments allow Mobile Web Browsing to be implemented based on an open in- dustry model which avoids the WAP protocols en- tirely. - Describe a new set of efficient protocols that can significantly increase the efficiency of Mobile Web Browsing. - Show how the WAP protocols have now become entirely irrelevant, and discuss whether anything useful can be salvaged from them. - Invite others to participate in the development of the open Mobile Web Browsing industry. Acknowledgments We gratefully acknowledge the assistance of the follow- ing persons in the preparation and review of this docu- ment: Andrew Hammoude and Pinneke Tjandana. 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 article is being written. As participants in the FPF, we are fully committed to its patent-free principles. As noted above, part of the FPF mandate is to provide support for patent-free alternatives to patented protocols such as WAP. It is in the spirit of this mandate that this article is being written. 12.2. MOBILE WEB BROWSING: PAST, PRESENT AND FUTURE181 12.2 Mobile Web Browsing: Past, Present and Future 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 heav- ily 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 dis- played 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 ex- tracted and downloaded to the phone. 12.2.1 The Past: WAP There is nothing bogus about this problem - only about the way WAP has gone about solving it. A key architec- tural component of the WAP solution is the WAP Gate- way, which stands between the cell phone and the web- site, and which actively participates in the data extrac- tion/download process. The catastrophic problem with this is that it totally violates the Internet End-to-End prin- ciple - the gateway is now interposed as an active author- ity between the client and the website. Clearly, the WAP Gateway exists for business rea- sons, not engineering ones. Control of the gateway, to- gether 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 sec- ondary to this. In other words, the entire WAP construct is an attempt by the wireless network operators and phone manufactur- ers to hijack the Mobile Web Browsing industry. If there was ever an example of the business dog wagging the en- gineering 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 Qual- comm (itself a longtime WAP Forum member), in re- sponse to The WAP Trap. Material omitted from Mr. Karn's e-mail is indicated by ellipses; otherwise, he is 182 CHAPTER 12. WAP SCRAPS quoted verbatim: From: Phil Karn 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 aga* *in. :-) 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 com- pletely irrelevant: 1. The XHTML[31 ] protocol from W3C 2. The LEAP family of protocols from the LEAP Fo- rum 12.2.2 The Present: XHTML Figure 12.1 shows the protocol stacks for web browsing under three different implementations: the WAP architec- ture, an architecture based on XHTML, and an architec- ture based on XHTML and LEAP. XHTML is a markup language from the World Wide Web Consortium (W3C) that allows an appropriate sub- set of web page content to be provided to a requesting device, depending on the device's display capabilities. XHTML thus provides an immediate solution to the cen- tral problem of website access from a limited-capability device such as a cell phone. As shown in Figure 12.1(b), XHTML can be used in combination with HTTP [32 ] and TCP [78 ] to provide a complete web browsing solution which bypasses the WAP Gateway and avoids the WAP protocols entirely. 12.2. MOBILE WEB BROWSING: PAST, PRESENT AND FUTURE183 Figure 12.1: Mobile Web Browsing: Past, Present and Future Furthermore, XHTML is an open, Internet-mainstream protocol, and conforms fully to the Internet End-to-End principle. The model of Figure 12.1(b) therefore provides Mobile Web Browsing the right way - i.e. based on a truly open industry model. (Note: The model of Figure 12.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 12.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. 12.2.3 The Importance of Efficiency The implementation of Internet applications such as web browsing in the wireless arena places a very high pre- mium on the efficiency of data transfer. Wide area wire- less networks demand bandwidth efficiency; miniaturized devices demand power efficiency; and the end user de- mands reliability and minimum latency. The underlying wireless protocols must provide all the required efficien- 184 CHAPTER 12. WAP SCRAPS cies. The claim is sometimes made that the need for effi- ciency in the wireless arena is a temporary one - that ad- vances in wireless engineering technology (such as third generation (3G) systems and 802.11b[13 ]) will eliminate existing bandwidth limitations, obviating the need for ef- ficient protocols. And indeed some high-speed networks have been implemented which demonstrate the capabili- ties 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 fu- ture advances in network speed, efficiency will remain a desirable goal as long as the capacity of wide-area wire- less networks remains finite. For these reasons, efficiency will remain a crucial as- pect of wireless network usage for some time to come. 12.2.4 The Future: XHTML + LEAP Because of the very limited display capabilities of minia- ture handheld devices, Mobile Web Browsing of neces- sity involves the transfer of relatively small amounts of data. In other words, Mobile Web Browsing is an inher- ently limited data-size activity. As connection-oriented protocols, HTTP and TCP are most efficient for large data transfers; however they pro- vide 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 12.1(b), though open and WAP-free, is a highly inefficient imple- mentation. 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 pro- tocols 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 de- scription of the LEAP protocols see The LEAP Manifesto, 12.2. MOBILE WEB BROWSING: PAST, PRESENT AND FUTURE185 available on-line at http://www.LeapForum.org/leap/. In addition, open-source implementations of the LEAP protocols are freely available through the MailMeAny- where open-source software distribution center; for de- tails visit the MailMeAnywhere website at http://www.MailMeAnywhere.org. The initial focus of the LEAP protocols was on effi- cient Mobile Messaging, and the first two members of the LEAP family, EMSD (Efficient Mail Submission and De- livery; RFC-2524 [5 ]) and ESRO (Efficient Short Remote Operations; RFC-2188 [91 ]), were designed for this pur- pose. 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 chal- lenge: 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 com- plete 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 ap- plication. 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 Effi- ciency of EMSD [6 ]. That article analyses the efficiency of EMSD and ESRO specifically; however similar effi- ciency results can be expected in the case of EHTD and ESRO. In particular, ESRO and EHTD are highly effi- cient for the transfer of limited-size data, and are there- fore ideal for the Mobile Web Browsing application. Figure 12.1(c) shows how these protocols may be used in combination with XHTML and UDP [77 ] to provide a Mobile Web Browsing implementation that is completely open, WAP-free and efficient. Note that the implementations of Figure 12.1(b) and Figure 12.1(c) are not mutually exclusive, but rather may be considered to be complementary. The connectionless 186 CHAPTER 12. WAP SCRAPS protocol stack of Figure 12.1(c) is highly optimized for the short data transfers inherent to Mobile Web Browsing; whereas the connection-oriented stack of Figure 12.1(b) may be used for large data transfers whenever necessary. 12.2.5 Invitation to Participate ESRO is a complete, RFC-published protocol, for which open-source software implementations are ready and avail- able 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 web- site 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 vari- ous 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 techni- cal understanding of WAP, represent a particularly valu- able resource. Their participation is encouraged and wel- comed. 12.3 WAP: A Salvage Operation The WAP Forum has responded to the availability of XHTML by announcing WAP 2.0, which provides support for both XHTML and WML in the WAP protocol stack. This di- minishes, but does not eliminate, the presence of the WAP Gateway in the WAP model. In addition, the in-place WAP 1.x architecture can claim to provide significant ef- ficiency advantages over the connection-oriented stack of Figure 12.1(b). However, all the other problems with WAP, detailed exhaustively in The WAP Trap and elsewhere, remain. Given the availability of truly open, Internet-mainstream alternatives, there is little remaining role for either the WAP specifications or the WAP Forum. At this point, WAP has become a salvage operation. There are three aspects to this salvage: engineering, business, and psy- chological. 12.3. WAP: A SALVAGE OPERATION 187 12.3.1 Engineering Salvage: Scrapping WAP Layer by Layer Before throwing WAP out completely, it behooves us to examine the specifications to determine whether there is anything worthwhile that can be salvaged for incorpora- tion or usage in the open industry models. Figure 12.2: WAP Architecture The general WAP architecture is shown in Figure 12.2. This figure is taken directly from the WAP specifications, and all nomenclature, acronyms etc. throughout this sec- tion are those of the WAP model. Starting from the bot- tom of the figure: - WDP (Wireless Datagram Protocol). The pur- pose of WDP is to accommodate non-IP networks. However, the convergence of wireless networks on IP at Layer 3 is now a technological reality. Most modern networks already support native IP, and IP will eventually become standard on all wireless net- works. There is therefore no need for a protocol designed to accommodate non-IP networks. Since IP can be assumed to be present at Layer 188 CHAPTER 12. WAP SCRAPS 3, UDP is entirely adequate at Layer 4. There- fore WDP is not needed at all, and can be scrapped completely. - WCMP (Wireless Control Message Protocol). The purpose of WCMP is also to accommodate non-IP networks, which, as described above, is unneces- sary. Assuming IP at Layer 3, the functionality of WCMP is adequately provided by ICMP. Therefore WCMP is not needed at all, and can be scrapped completely. - WTLS (Wireless Transport Layer Security). The purpose of WTLS is to provide security function- ality. However, a number of major security prob- lems have been identified in WTLS, including vul- nerability to datagram truncation attack, message forgery attack, and a key-search shortcut for some exportable keys. For a detailed description of the WTLS security problems, see Saarinen's paper At- tacks against the WAP WTLS Protocol [52 ]. Nevertheless, there may remain some worthwhile elements in WTLS. If the WAP Forum were to bring WTLS into conformity with the Internet mainstream by making patent-free declarations for it, publish- ing it as an RFC, and subjecting it to open review and maintenance procedures, then it may be worth examining for salvageable components. - WTP (Wireless Transaction Protocol). WTP serves a genuine purpose; however, equivalent functional- ity to WTP is provided by ESRO. In addition ESRO predates WTP, is truly open and patent-free, is RFC published, and otherwise conforms to the Internet mainstream. Therefore WTP is not needed at all, and can be scrapped completely. - WSP (Wireless Session Protocol). WSP provides a binary form of HTTP. Therefore there may be components of WSP that can be used to facilitate the development of EHTD. - WML (Wireless Markup Language). In the WAP model, WML is part of a broader specification called WAE (Wireless Application Environment). The func- tionality of WML is entirely provided by XHTML, which therefore renders WML irrelevant. WML is no longer required at all, and can be scrapped com- pletely. Thus every component of the WAP protocol stack is either functionally unnecessary, made irrelevant by an open 12.3. WAP: A SALVAGE OPERATION 189 alternative, or misdesigned; with the possible exceptions of WSP and WTLS, which may have some salvage pur- pose. Our analysis of the WAP stack is supported by various other studies which come to conclusions consistent with the above. A good starting point is the article W* Effect Considered Harmful [86 ], in which author Rohit Khare presents a detailed analysis of WAP, and demonstrates its shortcomings and ultimate non-viability. 12.3.2 Business Salvage: Cutting Financial Losses A huge amount of money has been sunk into the WAP fiasco - a large number of wireless network operators placed their bets on WAP, and invested heavily. And the WAP infrastructure is now complete; all the pieces are built and in place. The problem is that it falls disastrously short of its expectations; and as a result few people need it, few want it, and few are using it [81 ]. Apart from empty hype and broken promises, the WAP Forum has little to show for its massive investment. Under circumstances like this, people may find it dif- ficult to halt the investment Juggernaut. WAP has a huge amount of mass and momentum - it has the mass of its enormous investment costs, and the momentum of its own hype machine. The WAP Forum members may make the mistake of believing that this investment is still worth something. They may make the mistake of believing their own hype. But WAP is doomed, and its investment costs are now sunk costs. The only thing for the investors to do now is pull the plug on WAP and cut their losses. Contin- ued investment in WAP represents the throwing of good money after bad, and will only result in greater bottom- line losses at the end of the day. The sooner WAP is rec- ognized as a costly failure, the better. 12.3.3 Psychological Salvage: Saving Face Just about everybody joined the WAP Forum. The WAP Forum membership list is indeed impressive, including virtually every major player in the wireless and telecom- munications industry. However, as we now know, this is not a meaningful endorsement of WAP. Rather, it is a testament to herd mentality and bet-hedging. The arrival of XHTML and LEAP on the scene means that WAP is finished, and the WAP Forum has no signifi- 190 CHAPTER 12. WAP SCRAPS cant role to play in the development of the wireless Inter- net industry. From this point on, the important work will no longer be taking place within closed forums such as WAP. Given all of this, it is clear that the WAP Forum has little reason for continued existence, other than as a lame- duck organization with responsibilities that do not extend beyond face-saving activities for its members. 12.4 In Pursuit of Integrity Much has happened in the 17 months since we first pub- lished The WAP Trap. The Internet bubble has burst catas- trophically, causing the Nasdaq Composite Index to col- lapse from its peak of 5130 in March 2000 to around 1700 today - a staggering 67% loss of market capitalization. And the WAP bubble has also burst. The fortunes of WAP are perhaps best represented by Openwave Sys- tems, Inc. (formerly Phone.com, Inc.), one of the prin- cipal inventors and architects of WAP. The stock price of this company reached a peak of $208 in March 2000; at the time of writing in September 2001 it is trading at around $15 - a loss of 93%. Other WAP-related compa- nies have experienced similar losses. Meanwhile, the consumer has yet to see anything close to the promised ease and convenience of cell phone Inter- net access; and we are not aware of even a single com- pany that has made significant profits from sales of WAP services. 12.4.1 The WAP Hype Machine Fraud WAP has been a colossal failure in financial terms. Its us- age has not and cannot recoup its investment costs. Nev- ertheless, WAP has created fortunes for a privileged few. The WAP business model is based on the traditional supply chain model, in which the financial and other needs of all potential gatekeepers are addressed throughout the supply chain. The creation of this supply chain has re- quired the construction of a major infrastructure. Though this supply chain model cannot and will not work as in- tended, its construction has presented enormous profit- making opportunities for those in the right position. These profits have derived from two major sources. The smaller of these consists of the profits associated with building the WAP infrastructure itself; in particular the huge development contracts that have been awarded, 12.4. IN PURSUIT OF INTEGRITY 191 together with sales of WAP gateways and other equip- ment. But it is the larger source that represents the truly spectacular opportunity. This opportunity has been based, not on building the WAP infrastructure, but on the fairy- tale promises and expectations that have been created along- side it. The enormous amount of hype surrounding WAP led to huge increases in stock prices and company valu- ations across the entire WAP industry - nowhere better represented than in the valuation of Phone.com itself. Various WAP promoters were also investors and stock- holders in key WAP companies. These investors/promoters participated actively and collectively in the hyping of WAP, drove valuations up to levels far beyond what was realis- tic or supportable, then sold their WAP-related stock to the public at vastly inflated prices. One could be for- given for wondering whether the activities of the WAP promoters were intentionally directed towards this happy outcome. As the disappointing reality of WAP inevitably became clear, virtually all these inflated stock prices col- lapsed to less than 10% of their WAP-bubble peak, mak- ing fortunes for the investors, while leaving the public holding the empty WAP bag. This type of activity is commonly referred to as a "pump-and-dump" scheme - an ugly phrase to refer to an ugly operation: the deliberate over-hyping of a stock with the intention of artificially inflating its price, then dump- ing it on an unsuspecting public. From the perspective of the unfortunate losers, the collective activities of the WAP insiders must be hard to distinguish from a pump- and-dump operation on a grand, industry-wide scale. The WAP bubble was part of the more general Inter- net bubble, which represented the aggregate effects of a multitude of contributary bubbles similar to WAP. The WAP bubble was thus both a consequence of, and a cause of, the Internet bubble. To the extent that WAP was a consequence, the WAP promoters may shirk their respon- sibility for the WAP bubble. But to the extent that WAP contributed, they must then accept responsibility for the broader Internet bubble. We have no objection to those who make fortunes on the basis of something real. Authentic entrepreneurs make fortunes by building companies which provide some- thing of value to the consumer, and which create enduring value for their stockholders. Such people fully deserve the wealth created by their ingenuity, commitment and hard work. Nor do we object to profitable stock trading in which 192 CHAPTER 12. WAP SCRAPS no misrepresentation takes place. The stock prices of many companies were swept up and down along with the general Internet bubble; but in most cases this took place without gratuitous hyping by insiders. Those who sold near the peak made money at the expense of those who bought; but those are the breaks in the high-tech industry, and these are the risks that investors must accept. But neither of these considerations applies to WAP. In the case of WAP little of value has been provided to the disappointed consumer, the value of company equity has been fleeting, and a minority of people have been greatly enriched at the expense of a duped majority. The WAP fortunes have been made by selling WAP-related stock at inflated prices, not by delivering WAP services to satis- fied customers. Furthermore, the WAP hype campaign continued, and still continues today, despite the fact that actual WAP us- age remains dismal, and no one has ever made signifi- cant profits on the basis of WAP services. Given these facts, we find it scarcely conceivable that the WAP insid- ers were unaware that WAP was being hyped far beyond its reality, that stock prices were being driven to levels far beyond their sustainable value, and that they would inevitably collapse. We are making no suggestion here that actual, prose- cutable criminal fraud took place. But there can still be breach of trust, even though no law may have been bro- ken. When we consider that the WAP model includes a gateway whose primary purpose is to generate revenue for its operator; when we consider that WAP is patented; that WAP is a shoddy engineering construction; that WAP is the pseudo-open creation of a pseudo-open forum, then we have to wonder if everything is entirely above board. In our judgement, the activities of the WAP investors/promoters amount to fraud in all but the letter of the law. Our readers may come to their own conclusions. 12.4.2 Protocol Integrity Underhanded practices are a fact of life in the business world. But when such practices involve the creation of a large-scale engineering construct, and when they are based on the exploitation of vital industry protocols, this degrades the integrity of the engineering profession. The engineering profession traditionally carries a re- sponsibility to protect the safety and welfare of the pub- lic. An industry protocol is an engineering construct, held in public trust by the engineering community. It is the 12.4. IN PURSUIT OF INTEGRITY 193 responsibility of the engineering community to defend this trust against exploitation by narrow business self- interests. There are three fundamental principles for maintain- ing the integrity of public protocols [9 ]. These are: - Patent-freedom - Unrestricted access, permanence and stability of the published specifications (e.g. RFC publication) - Maintenance by truly open organizations Each of these provides a vital assurance of protocol integrity. Patent-freedom ensures that a patent-holder can- not subvert free-market competition among products and services based on the protocol. RFC publication ensures that the protocol is freely available to anyone who wishes to use it. And maintenance by open organizations ensures that development of the protocol takes place by technical engineering consensus, rather than business self-interest. This trilogy of principles represents the most basic guarantees of the integrity of a protocol. If any one of these things is missing, then this means that some attempt is being made to control or limit access to the protocol. In the case of a public protocol, there is no valid reason for doing this. The creation of the WAP specifications has violated every one of these principles. The use of patents and other access-control mechanisms has been a traditional way of life in the highly business-oriented, oligarchic telecom- munications industry. But the Internet industry is not like that. Openness and freedom from authority lie at the heart of the Internet, and in no small measure account for its extraordinary vitality and success. Patents and other business-oriented control devices have no place in this industry. Though WAP may try to pass itself off as an "open Internet protocol," its roots in the telecommunica- tions industry are plainly evident. In The WAP Trap we challenged the WAP Forum ei- ther to provide valid reasons for their violation of the above principles, or to bring the WAP specifications into line with them. Seventeen months later, neither of these things has happened, and our challenge remains unan- swered. We now repeat our challenge. We challenge the WAP Forum to abandon their closed, members-only model of operation, make patent-free declarations regarding the WAP protocols, publish them as Internet RFCs, and subject 194 CHAPTER 12. WAP SCRAPS them to genuine public review and maintenance proce- dures. By taking these steps, the WAP Forum will allow the possibility of what remains of WAP being incorpo- rated into the mainstream Internet development model. 12.4.3 Engineering Integrity When first published in April 2000, The WAP Trap was well ahead of its time. At that time it represented a dis- tinctly minority viewpoint, and seemed radical and ex- treme to many. Today it seems much less so. The same may be true of this article. To the casual observer, the WAP Forum may appear to be a healthy organism, engaged in creating something important and worthwhile. WAP has not yet been fully discredited, and it may not for some time. Meanwhile, the naive or the in- experienced may find themselves impressed by the sheer scale of financial investment and engineering effort that has gone into WAP. Such observers may find themselves puzzled by, and skeptical of, our rhetoric. It may be hard to accept that something so big can be so fallacious; nev- ertheless, that is the fact. In this paper we are lobbying for a Mobile Web Brows- ing based on a truly open industry model. By definition, WAP in its present form can play no role in such a model. Not all the things we are lobbying for will take place, and the things that do may not take place as soon as we would like. The LEAP protocols we are proposing may become part of this model, or they may not. The WAP salvage op- eration we are suggesting may contribute to this model, or it may not. But the eventual outcome is clear. WAP is non-viable, and sooner or later the rest of the wireless industry will come to this realization. And at some point it will be replaced by a truly open solution. In the meantime, we urge those engineers who have an interest in the ethics of their profession to distance themselves from WAP, because it is specious. Given a choice between WAP and something else, we encourage the engineering men and women of the wireless industry to invest their precious talents in something that has both business and engineering integrity. Chapter 13 Operation Whiteberry 13.1 Introduction The wireless data communications medium of today is struggling to define itself. It is clear that this medium is enormously important; it is also enormously complex, with major technical, societal and business consequences that no one fully understands. Of the many questions that this new medium raises, two of the most basic are: (1) What is the most appro- priate starting-point application, and (2) What is the best way to implement this application? In other words, what wireless application is of the most immediate and com- pelling value, and what is the most appropriate model for delivering this application? We believe that the answers to these questions have now become clear. The right entry-point application is Mobile Messaging, and the right implementation model is an entirely open paradigm, based on open and free pro- tocols. Mobile Messaging is in complete harmony with the wireless medium, provides users with an incontrovertible value proposition, and has already achieved widespread market acceptance. And a completely open paradigm is the right model for all large-scale communications systems. An open in- dustry model provides the greatest benefit to the end user and the industry at large, by allowing free market entry and competition at any point within the Mobile Messag- ing solution domain. This in turn results in greatly in- creased business opportunities, more and better solutions 195 196 CHAPTER 13. OPERATION WHITEBERRY for the end user, and unrestricted industry growth. Unfortunately, these two key ideas are not well un- derstood within the wireless industry. Numerous wireless initiatives are under way, but in all cases these are misdi- rected either because they are pursuing the wrong appli- cation, or because they are pursuing the right application but based on the wrong model. As a result of this, the wireless industry of today is in a state of chaos. A large segment of the industry, most notably the WAP Forum, has mischaracterized the ma- jor entry-point application, and is pursuing wireless web browsing and other second-string applications. Meanwhile, another industry segment is investing in the right application, but based on the wrong model. Mo- bile Messaging is the right application, but this indus- try segment is characterized by the existence of various closed, proprietary solutions such as BlackBerry and Re- FLEX. The components of these competing systems do not interoperate, and they cannot build on each others as- sets. The result of this is the fragmentation of the Mobile Messaging market into a number of isolated islands of consumers, each committed to a particular solution and unable to take advantage of the assets of any other island. The remedy to all this exists, in the form of a set of protocols called the Lightweight & Efficient Applica- tion Protocols, or LEAP. LEAP is a set of high-performance, efficient protocols which are ideal for mobile and wire- less applications. In this article we describe how equiva- lent Mobile Messaging functionality to the existing closed systems can be provided, in the form of an entirely open solution based on the LEAP protocols. Our goal is to use the inherent power of truly open and free protocols to dis- place these closed solutions. We refer to the execution of this goal as Operation WhiteBerry. WhiteBerry provides true Mobile Messaging, based on a set of open protocols - and therefore represents the right application and the right model. All the pieces re- quired to implement WhiteBerry exist and are in place, and the openness of the WhiteBerry solution ensures that it will displace all existing closed solutions. 13.1.1 The Problem The wireless industry of today is characterized by sys- tems which are closed, restricted, and which violate the Internet End-to-End principle. Two of these are of partic- ular relevance: 13.1. INTRODUCTION 197 1. The Wireless Application Protocol, or WAP 2. The BlackBerry Mobile Messaging system WAP is discussed in detail in the article entitled The WAP Trap [66 ], while BlackBerry is discussed in the present article. Our analyses of the WAP and BlackBerry systems are very different. As we argue in The WAP Trap, WAP is a bogus marketing construct that can bring nothing but harm to the industry and the consumer. WAP claims to be an open specification, but in fact it is anything but - on the contrary, it is booby-trapped with patents. Furthermore, the basic premise of WAP (namely, that of providing Web browsing capability on a cell phone) is inherently limited and impractical, and is the wrong starting point applica- tion. Mobile Messaging systems such as BlackBerry, on the other hand, bring unquestionable value to the user, and these systems have experienced widespread usage as a result. Without exception, however, all existing Mobile Messaging system are closed, and the emerging competi- tive scenario is that of a struggle among these closed sys- tems. Thus, while part of the wireless industry now appears to understand the enormous importance of the Mobile Messaging application, it does not appear to understand the importance of the open model. 13.1.2 The Solution The solution to this closed-system battle is not another set of products and services. Rather, the solution is the industry-wide adoption of the right set of open protocols as the basis for interoperability and cooperation. Throughout this article, we will take the BlackBerry system from RIM as a particular example of a closed Mo- bile Messaging system. In common with other messaging systems, BlackBerry brings unquestionable value to the user. But despite its end user value, BlackBerry remains a closed, single-vendor system, based on a set of propri- etary protocols. The proprietary nature of the underlying protocols prevents competition on the basis of any of the constituent components of the BlackBerry system. And this is something which is true in general: closed systems diminish competitive opportunity. It is, of course, entirely possible for a closed system to encounter compe- tition in the form of another closed system. However, the 198 CHAPTER 13. OPERATION WHITEBERRY market entry barriers and competitive challenges are far greater for a competing system than for a competing sys- tem component - such as a wireless modem, for example. Therefore closed systems act to inhibit competition both at system level and component level. This inhibi- tion of competition is all to the good of the company that owns the closed system - which is the fundamental rai- son d'etre for all closed systems, of course. However, this same inhibition of competition acts greatly to the detri- ment of the industry at large and the consumer. In contrast to this emphasis on minority business self- interests, we are committed to the following principles: - We support patent-free protocols and technologies which benefit the consumer by promoting compe- tition and choice. - We are opposed to closed systems based on pro- prietary or restricted protocols, since these reduce competitive opportunities and limit users' freedom of choice. - We are advocates of open systems based on free protocols and open-source software, since these en- able competition and preserve users' freedom of choice. - We are committed to the Internet End-to-End model, in which the Internet serves merely as a passive communication pipe, allowing direct communica- tion between a client and server. These principles are emphasized throughout this arti- cle, and in general throughout The LEAP Manifesto [65 ]. In this article we describe how the equivalent func- tionality to BlackBerry can be implemented in the form of a completely open system, based on existing technolo- gies and protocols. We refer to this open equivalent to BlackBerry as the WhiteBerry solution. In contrast to BlackBerry, WhiteBerry is a multi-vendor solution, al- lowing market entry and competition at any point within the Mobile Messaging technology chain. The result is greatly increased business opportunities throughout the Mobile Messaging industry, increased competition, and better solutions for the end user. Though we are presenting WhiteBerry as an open al- ternative to BlackBerry, there is nothing unique about BlackBerry in this regard. WhiteBerry represents an open alternative to any closed Mobile Messaging system, in- cluding others besides BlackBerry such as Mail on the 13.1. INTRODUCTION 199 Run! from River Run Software Group, and ReFLEX from Motorola. We have chosen BlackBerry as the subject of this article because it is in widespread use, and at this point appears to be the market leader. However, the same principles of openness versus closedness apply equally to any closed Mobile Messaging system. The entire WhiteBerry solution that we describe in this article is complete and available today. The key com- ponent of WhiteBerry is a set of mobile messaging proto- cols. These are complete, fully satisfy all necessary tech- nical requirements, are truly open and patent-free, and have been published as RFCs. In addition, a compre- hensive framework for the development of WhiteBerry implementations has been established. This framework consists of free, open-source software implementations of the protocols, an open public forum for the develop- ment and distribution of integration tools, an initial set of free Subscriber Services, and an initial end-to-end White- Berry implementation. Anyone can use these tools and facilities to create a fully functional WhiteBerry Mobile Messaging implementation immediately. Furthermore, the WhiteBerry development framework is highly generalized, and goes beyond simply duplicat- ing the limited capabilities of the BlackBerry system - it also allows the development of a more general set of wireless applications, including Instant Messaging and others. A discussion of some of the future possibilities of the WhiteBerry model is provided in Section 13.9. We begin this article by discussing the general func- tional requirements for Mobile Messaging. We then de- scribe how these requirements are provided by a typical closed system, using BlackBerry as an example. Next we provide a detailed description of the WhiteBerry model, and show how it provides equivalent functionality to Black- Berry, based on an open model. We then describe the WhiteBerry development framework, and discuss the se- curity issues relating to Mobile Messaging. The solution we propose is not just an academic, en- gineering exercise; it also has a well-founded business dimension. As will become clear later, there is a great deal of money to be made in Operation WhiteBerry. 13.1.3 Free Protocols Foundation Endorse- ment of Operation WhiteBerry The Free Protocols Foundation (FPF) is a non-profit orga- nization dedicated to the support of patent-free protocols and software. The FPF views software patents as being 200 CHAPTER 13. OPERATION WHITEBERRY extremely harmful to the industry and the consumer, and part of the FPF mandate is to oppose such patents when they appear. For more information see the FPF website at http://www.freeprotocols.org/. Research In Motion (RIM), the manufacturer of the BlackBerry system, has recently been granted U.S. Patent # 6,219,694 on the basis of its BlackBerry technology, and is now suing a competing company (Glenayre Elec- tronics, Inc.) for infringement against this patent. There- fore not only does BlackBerry limit competitive opportu- nity by virtue of being a closed system, but now RIM has taken a giant step beyond that in terms of anti-competitive practices: it is attempting to eliminate all competition en- tirely. The FPF regards this patent as fundamentally invalid, and RIM's infringement claim as an egregious example of patent law abuse. For a detailed FPF position state- ment on this patent see the FPF paper Position Statement regarding the RIM Mobile E-Mail Patent Assertion [35 ], available on-line at http://www.FreeProtocols.org/rimBBPatent/main.html. The FPF is strenuously opposing this patent by means of a variety of actions; see the above position statment for details. One of the general strategies by which the FPF opposes patented software is by supporting the cre- ation and development of patent-free alternatives. Since Operation WhiteBerry describes an open, patent-free al- ternative to the closed and patented BlackBerry system, it is directly aligned with this strategy. Therefore, as part of its broad compaign to oppose the RIM patent, the Free Protocols Foundation endorses Operation WhiteBerry fully, and is pleased to re-publish this revision of the paper on its own website. Operation WhiteBerry was first published and remains available on the LEAP Forum website at http://www.LeapForum.org/operationWhiteberry/index.html. 13.2 Mobile Messaging Requirements The mobile user of today can choose from a variety of messaging technologies. At one extreme, the user may choose to carry a miniature paging device. At another extreme, he may choose to carry a laptop device which he can use to dial in to retrieve e-mail messages. Each of these technologies provides a particular set of capabilities and functionality to the mobile user. Modern e-mail systems provide a comprehensive rich- ness of message format, including To, From, CC and Sub- 13.2. MOBILE MESSAGING REQUIREMENTS 201 ject fields, and the ability to include attachments. Tradi- tional paging devices, by contrast, typically provide ex- treme simplicity of message format - in some cases no more than a 10-digit telephone number. On the other hand, paging devices provide the user with a very high degree of portability, which cannot be matched by a laptop or even most palmtop devices. Fur- thermore, paging systems deliver messages directly to the recipient, who is then unilaterally alerted to their pres- ence by the paging device. By contrast, e-mail systems usually do not provide this direct delivery capability, but instead require an explicit retrieval action on the part of the recipient. The mobile user of tomorrow will expect and demand the best that each of these technologies can offer. While on the move, mobile users need to have important or time- critical information delivered to them. This information may be more complex than a 10-digit telephone number. And it may be necessary to present this information to the user immediately, without requiring him to dial in for messages. Users must be able to accept messages at any time, at any place, and on a device that they can carry anywhere. In order to satisfy these requirements, a Mobile Mes- saging system must have the following characteristics: - Allow the full information content of modern e- mail. The limited message content of traditional paging devices will not be adequate. - Provide mobile messaging capability on an uncon- scious carry device - meaning that the device can readily be carried anywhere by the user, and with- out moment-to-moment awareness of its presence. A palmtop is the maximum size form factor that can be considered to satisfy this requirement. - Support the push mode of message delivery - mean- ing that messages are delivered directly to the re- cipient, without requiring an explicit poll or retrieval action. The required Mobile Messaging system must there- fore combine the message richness of typical e-mail, with the unconscious carry and push delivery characteristics of typical paging devices. We will refer to a messaging system that satisfies these criteria as a true Mobile Mes- saging system. Unconscious carry, and the push mode of delivery, are essential requirements of the mobile user. Showing up to 202 CHAPTER 13. OPERATION WHITEBERRY a romantic dinner carrying a laptop is idiotic. Showing up with a pager in your pocket is not (though answering it may be). And if much later your now-wife is soon to give birth, you certainly do not want to have to dial into your Message Center to discover that she has gone into labor. Information like this must be presented to you im- mediately, and wherever you happen to be. 13.3 The BlackBerry Solution To illustrate the shortcomings of closed messaging solu- tions, we will take the case of BlackBerry as a specific example. While the description and analysis throughout this section applies specifically to the BlackBerry system, similar principles apply to all closed messaging systems. BlackBerry is a Mobile Messaging solution from Re- search In Motion (RIM). It satisfies all the Mobile Mes- saging requirements specified above: it provides users with general e-mail capability; the end user devices sat- isfy the unconscious carry criterion; and it supports the push mode of operation - incoming e-mails are delivered directly to the handheld device, which then immediately advises the user of their arrival. BlackBerry can be used as a stand-alone Mobile Mes- saging system; alternatively, it can be integrated with a user's existing home or office e-mail account. In this case it appears to the user as a wireless extension of his existing desktop, corporate, or ISP-based e-mail service. The user can freely access and manage the wireless mail- box, while the system maintains synchronization with the land-based mailbox. In the following sections, we will describe the major characteristics of the BlackBerry system. For complete details, see the BlackBerry website at http://www.blackberry.net/. It is important to note that the BlackBerry messaging implementation represents nothing fundamentally novel. All the basic concepts, methods and processes represented in the implementation have been previously known and put into practice by others - RIM has merely packaged those concepts and brought them to the mass market. 13.3.1 How BlackBerry Works The overall operation of the BlackBerry system is shown in Figure 13.1. All BlackBerry-specific components are shown shaded in this figure. (Note: Figure 13.1 and the following description represent our understanding of the 13.3. THE BLACKBERRY SOLUTION 203 BlackBerry system at the time of writing in February 2001. Because the system is closed and technical information regarding its operation is unavailable, we cannot guaran- tee the accuracy of this description; nor is there any assur- ance that RIM will not change the operation of the sys- tem in the future. The following description is based on RIM's promotional information, supplemented with our own educated assumptions where necessary. For the lat- est and most reliable information, refer directly to RIM's own materials. Note also that our purpose in providing this descrip- tion is not to reverse engineer the BlackBerry system; rather, it is to illustrate the characteristics of closed Mo- bile Messaging systems in general. Minor inaccuracies in our description of BlackBerry are therefore not of any great importance.) The BlackBerry user is provided with a wireless hand- held device, shown on the left side of the figure. The user has a choice of either of two alternative device styles: a pager-style form factor, or a palm-style form factor. The device has an integral wireless modem, allowing com- munications over the BellSouth Intelligent Wireless Net- work.1 The device is equipped with RIM's software im- plementation of their proprietary wireless-oriented proto- col, allowing the device to communicate with the simi- larly equipped BlackBerry Message Center. The mobile device is supported by the proprietary, RIM-operated BlackBerry Message Center, shown in the center of Figure 13.1. Any e-mails addressed directly to the mobile device are fielded by this Message Center us- ing standard Internet protocols, then delivered to the mo- bile device using the proprietary RIM wireless protocols. The device modem remains on at all times to accept in- coming messages, and the device notifies the user imme- diately whenever a new message arrives. To send a message, the user composes the message then submits it to the BlackBerry Message Center via the RIM protocols. The Message Center then sends the mes- sage to its destination using standard Internet e-mail pro- tocols. _ More often, the user wishes his mobile messaging ca- pability_to_function as a wireless extension of an existing e-mail_account._ The user may choose to have the Black- Berry_system function as an extension of his Microsoft Outlook_desktop_mail application. In this case, the user installs_the BlackBerry Desktop Redirector software on his_PC._This situation is shown at the top of Figure 13.1. _ _ 1 Formerly known as the RAM network 204 CHAPTER 13. OPERATION WHITEBERRY Figure 13.1: The BlackBerry Solution 13.3. THE BLACKBERRY SOLUTION 205 The Desktop Redirector software integrates with the Microsoft Outlook mail application, and allows selected e-mails to be forwarded to the wireless device on the basis of user-defined e-mail filters. Properly qualified e-mails are forwarded to the BlackBerry Message Center using standard e-mail protocols, which then delivers them to the mobile device using the RIM protocols. When the user sends a message, the BlackBerry Mes- sage Center sends the message to its destination as usual, but in addition sends a notification to the BlackBerry Desk- top Redirector so as to maintain mailbox synchronization between the handheld device and the desktop mail ap- plication. Similar synchronization is maintained for any other action the user might take, such as message for- warding, deletion, etc. The mailbox synchronization pro- tocols required to accomplish this are also proprietary to RIM. For integration with corporate e-mail systems, RIM provides the BlackBerry Enterprise Server, which inte- grates with the Microsoft Exchange Message Center, as shown on the right of Figure 13.1. The BlackBerry En- terprise Server functions in much the same way as the Desktop Redirector, except that mail redirection and syn- chronization take place at the corporate Message Center, rather than the user's desktop mail application. As be- fore, qualifying e-mails are forwarded to the BlackBerry Message Center, then delivered to the mobile device. The BlackBerry system can also be integrated with certain third-party Service Providers; at the time of writ- ing there are four of these: OneMain, RCN, Rogers AT&T, and PageNet Canada. The nature of the business relation- ship between RIM and these companies is unknown to us; our guess is that in each case RIM licenses the Black- Berry Enterprise Server to the Service Provider, which then integrates it with its in-house Message Center sys- tem. Regardless of the actual business arrangement the end result is the same: the Service Provider is then able to offer the BlackBerry system to its customers as a wireless extension of their regular e-mail account. This situation is shown in the lower right of Figure 13.1. The functional logistics in this scenario are essentially no different from integration with corporate Message Centers. 13.3.2 BlackBerry: Mobile Messaging Con- firmation Mobile Messaging solutions such as BlackBerry have been well received by consumers. Users generally report a high level of customer satisfaction, and such systems have 206 CHAPTER 13. OPERATION WHITEBERRY experienced steadily increasing adoption and usage. The basic reason for this is that these systems provide a tremen- dous value proposition to the user: Mobile Messaging systems provide instant delivery of important or time-critical e-mail messages to mobile users, using an uncon- scious carry device. The mobile device is always on, and is guaranteed to get you the information you need, whenever, and wher- ever, you happen to be. The market acceptance of systems like BlackBerry unequivocally confirms that Mobile Messaging, with the requirements defined in Section 13.2, is the killer appli- cation in the wireless data communications arena. Un- conscious carry, push mode, and full e-mail functional- ity: these are the key characteristics that have established Mobile Messaging as a viable commercial concept. And these are the same characteristics that will define the Mo- bile Messaging industry of the future. 13.3.3 BlackBerry: A Closed Solution Despite its proven value proposition, BlackBerry remains a closed messaging solution. It is a proprietary package of integrated components and services, supplied by a sin- gle vendor. The key component of the BlackBerry system con- sists of the protocols used for final-leg communication between the BlackBerry Message Centers and the mobile devices. However these protocols belong exclusively to RIM. They are heavily protected by patents, are not pub- lished or otherwise made available to potentially compet- ing vendors, and are otherwise treated as trade secrets. For this reason, BlackBerry consists of precisely the components and services defined by RIM. Because of the closed nature of the protocols, it is not possible for any other vendor to provide any alternative component of the BlackBerry solution. This is all very much by choice on the part of RIM, of course, who are executing a business model based on the classical "sustainable advantage." An integrated package of components is required to bring Mobile Messaging capability to the end user. The various required components, and the way in which the BlackBerry system supplies these components, are sum- marized below: - Mobile device. Only the two RIM-manufactured 13.3. THE BLACKBERRY SOLUTION 207 BlackBerry devices are available. No other device, such as a Palm or Windows CE device, is currently supported. (Of course, RIM could readily provide support for these and other devices by licensing its software for use on third-party devices, and we would not be surprised if at some point they do ex- actly that. Even if they did, however, these would merely be additional device incarnations of the same BlackBerry system. The system would still remain closed, because the underlying protocols would re- main closed and proprietary to RIM.) - Wireless modem. Only the RIM modem which is integral with the device is supplied. No other modem is supported. - Wireless network. At the time of writing, the Black- Berry system is based exlusively on the BellSouth Intelligent Wireless Network (and its Canadian ex- tension, the Rogers AT&T Wireless Network). No other wireless network, such as GSM/GPRS or CDPD [33 ], [34 ], is supported. - Message Center service. Message Center service for final-leg communications to the mobile device is provided exclusively by the RIM-operated Black- Berry Message Center. No other Message Center service may be used for this purpose. - Protocols to tie these components together. Black- Berry is based on RIM's proprietary protocols. - Where necessary, integration with the user's Desk- top, Corporate, or ISP-based e-mail system. In the case of desktop integration, BlackBerry pro- vides support for the Microsoft Outlook mailbox application only; no other mailbox applications, such as Netscape Messenger, are supported. In the case of integration with corporate Message Center sys- tems, BlackBerry provides support for Microsoft Exchange only; no other Message Center systems, such as sendmail [26 ] or QMail [12 ], are supported. In the case of integration with third-party ISPs, RIM currently has licensing agreements with only four: OneMain, RCN, Rogers AT&T, and PageNet Canada; no others are presently supported. - Integration of all these components into a pack- aged solution for the end user. The BlackBerry system is integrated and packaged exclusively by RIM. BlackBerry is thus, from beginning to end, from A to Z, defined and controlled by RIM. 208 CHAPTER 13. OPERATION WHITEBERRY A further consequence of the closed nature of the RIM protocols is that they have received no external engineer- ing scrutiny or validation. They are known to function adequately in the environment and usage patterns defined by the BlackBerry solution, but no information is avail- able regarding their technical merits - for example, no data is available by which to judge the performance, reli- ability or scalability of these protocols. In addition, no detailed information is available re- garding the BlackBerry security implementation. Secu- rity issues are discussed in greater detail in Section 13.6. 13.3.4 BlackBerry: Not All Things to All People Most of the closed aspects of the BlackBerry system do not directly affect the experience of the end user. For example, the typical user neither knows nor cares that the system is limited to the BellSouth Intelligent Wire- less Network. However, the closed nature of system is immediately evident to the end user in the form of the BlackBerry de- vices. While most users are extremely satisfied with the Mobile Messaging functionality of their device, they may be less than completely satisfied with its other features. A device manufacturer may be able to do one thing very well, but it is extremely difficult to do everything well. BlackBerry provides Mobile Messaging function- ality very well. The BlackBerry devices also provide the other standard PDA applications: calendar, address book, memopad, task list etc.; however, the BlackBerry imple- mentation of these applications falls well short of others in the marketplace. For example, once users have experi- enced the superlative Graffiti text-entry interface of Palm devices, text entry on BlackBerry seems clumsy and frus- trating. Even apart from the merits of one device over another, there is the simple matter of taste and familiarity; people grow used to a particular device or application, and have a reluctance to change to something different. As a general-purpose PDA, BlackBerry is inferior in many ways to other devices, most notably the popular Palm family. For this reason users find themselves carry- ing around two devices: their preferred PDA, plus Black- Berry as a specialized paging/messaging device. The so- lution to this inconvenience is abundantly obvious to the puzzled end user, who asks, "Why must I carry both of these? Why does my preferred PDA not do what Black- 13.3. THE BLACKBERRY SOLUTION 209 Berry does?" It is not that users have any dissatisfaction with the messaging functionality of BlackBerry - it is just that they would prefer to have this same functionality on their favorite PDA. Clearly, what is required is for the Mobile Messaging capability of BlackBerry to be available on any mobile device - and WhiteBerry makes this possible. 13.3.5 Strategic Myopia: More Closed So- lutions Because the value proposition has now become so clear, various companies are eager to jump on the Mobile Mes- saging bandwagon, or have already done so. For those companies that already have existing relevant assets, this is not difficult to do. A good example is Palm, which has a tremendously powerful asset in the form of its installed base of approximately 11 million PDAs. These can be wireless enabled with a variety of existing modems, and can therefore readily form the basis for a Mobile Mes- saging solution. In addition to its very positive effect on their PDA sales, this would also provide Palm with imme- diate entry into the Subscriber Services business arena, a highly desirable and natural extension of their existing business model. Palm thus has every reason to launch a Mobile Mes- saging solution: they have a vital asset, it is easy to do, and the business advantages are enormous. Evidently none of this is lost on Palm, who recently announced their intention to market wireless-enabled versions of their PDAs in the second half of 2001 [85 ]. Also, the opportunity to capitalize on the shortcomings of the BlackBerry devices is not lost on Palm CEO Carl Yankowski, who says: "We can do everything that (Research In Mo- tion) does not" For reasons discussed in Section 13.7.4, there is a great temptation for businesses to implement closed and proprietary solutions. Thus far, every player to enter the Mobile Messaging arena has succumbed to this tempta- tion. Palm has not yet provided information on whether it will be implementing a closed or an open messaging solution, or what the underlying protocols will be. How- ever, we do not expect Palm to be any exception. Other companies have been faced with a similarly clear-cut imperative to enter the Mobile Messaging mar- 210 CHAPTER 13. OPERATION WHITEBERRY ket, and as a result there is now a multiplicity of mes- saging solutions available. In addition to BlackBerry, messaging solutions are currently being marketed by Gle- nayre, Skytel, Metrocall, Motorola and River Run. AOL has also recently joined the marketing fray with its Mo- bile Communicator product (though this is in fact the BlackBerry system re-marketed under AOL's name). However, all of these are closed solutions, and are therefore subject to precisely the same limitations, and ultimate non-viability, as BlackBerry. The companies who are developing and marketing these solutions are suffering from strategic myopia. The existence of a plethora of closed, non-interoperating Mo- bile Messaging solutions results in technological and mar- ket fragmentation, which clearly cannot persist in the long run. Sooner or later, the Mobile Messaging industry must and will adopt an open solution model. Any closed so- lution is doomed to eventual (and we believe speedy) ex- tinction. 13.4 The WhiteBerry Solution The basic concept of WhiteBerry is to bring the same true Mobile Messaging functionality to the user as does BlackBerry - but based on a set of open protocols, as op- posed to RIM's proprietary protocols. BlackBerry is a single-vendor solution, in which ev- ery system component is defined and supplied by RIM. By contrast, WhiteBerry is a multi-vendor solution, in which the same functionality is provided by a series of products and services, and the necessary cross-vendor in- teroperability is guaranteed by the openness and integrity of the underlying protocols. WhiteBerry is thus not merely a competing system to BlackBerry - it is radically different in nature. White- Berry is not owned by anyone, any more than the econ- omy is owned by anyone. Since the underlying protocols are completely open, WhiteBerry will expose every part of the generic Mobile Messaging value chain to market entry, cooperation, and competition. Mobile Messaging will be transformed from its incarnation of today, consist- ing of a melange of closed, non-interoperating systems, into a true industry. 13.4. THE WHITEBERRY SOLUTION 211 13.4.1 Technological Components of White- Berry All the technological components required to implement WhiteBerry already exist and are in place. These compo- nents are: - Mobile Devices & Platforms. A wide variety of mobile devices and platforms are available which satisfy the unconscious carry criterion, such as the Palm product line, Windows CE devices, and the already ubiquitious cellular telephone. Note that the BlackBerry end user devices are also part of the general pool of mobile devices, and if RIM wishes to participate in WhiteBerry on the basis of their mobile device technology, it can certainly do so. - Wireless Networks. A variety of networks are in place that can provide the necessary coverage foot- print, in-building penetration, and bandwidth. These include: GSM/GPRS, Metricom, Packet CDMA, and CDPD. (Note: Throughout this paper we will frequently make use of CDPD as a specific example of a Wire- less IP network. We do this not because we neces- sarily believe that CDPD has any greater relevance than other networks, but because as the largest na- tive IP public wireless network in the world to- day, it provides a ready and familiar example. The WhiteBerry solution is in no way limited or spe- cific to CDPD - WhiteBerry is compatible with any Wireless IP network.) - Wireless Modems. A variety of wireless modems are available for the above networks, and in minia- turized form factors appropriate for unconscious carry usage. These include the AirCard product line from Sierra Wireless, and the Minstrel prod- uct line from Novatel. - Message Center Systems. Several Message Cen- ter systems which provide generic back-end e-mail support are commercially available. The major ones are: sendmail, QMail, and Microsoft Exchange. - Subscriber Services. A large number of ISPs and other Subscriber Services companies are already in existence, which host Message Centers and pro- vide e-mail service to their subscribers. Any of these can provide the necessary services to support true Mobile Messaging capability under the White- Berry scenario. 212 CHAPTER 13. OPERATION WHITEBERRY Given that all these technological components are well established and readily available, the final component re- quired to bring WhiteBerry to life is the right set of open protocols to tie everything together. As we will see in the following sections, these are now available too. 13.4.2 The Unifying Component: A Set of Open Protocols The key to the open Mobile Messaging industry is the right set of protocols. Existing Internet e-mail protocols are not suitable for this purpose, because they are lacking in two major re- spects. First, they lack the necessary efficiency charac- teristics. Wireless networks are severely constrained by bandwidth limitations, and mobile devices are constrained by limitations such as display size, battery capacity, and memory capacity. These constraints place an extremely high premium on the efficiency of data transfer. Existing Internet protocols such as SMTP [79 ], IMAP [27 ] and POP [68 ] do not provide the required efficiency. Second, existing Internet e-mail protocols do not prop- erly support the push mode of delivery, which is an essen- tial aspect of true Mobile Messaging. For more detailed discussions of the shortcomings of existing protocols, see the Manifesto articles EMSD: The LEAP E-Mail Compo- nent [7 ], and Efficiency of EMSD [6 ]. The inadequacy of existing protocols has been well demonstrated by the business failure of Mobile Messag- ing services based on them. Several service providers (Omnisky and YadaYada among others) have offered mo- bile e-mail services based on existing land-based Internet protocols such as POP, IMAP and SMTP. But because of the inefficiency of these land-based protocols, and be- cause they do not support the push mode of delivery, these services are no match for true Mobile Messaging systems like BlackBerry. Therefore a new generation of high-performance, ef- ficient protocols is required to address the demands of the mobile and wireless environment. The necessary pro- tocols must satisfy the following key functional require- ments: - Support the submission and delivery of short (e.g. 4 kilobytes or less) Internet e-mail messages, with the same or better level of functionality as the ex- isting SMTP protocols. - Provide the same or better level of reliability and 13.4. THE WHITEBERRY SOLUTION 213 security as the existing SMTP protocols. - Support the push model of instant delivery to the recipient. - Provide the required efficiency characteristics. These include: minimization of the number of transmis- sions, minimization of the number of bytes trans- mitted, and minimization of the latency of message submission and delivery. - Make reasonable trade-offs between specification complexity, implementation complexity, extensibil- ity, scalability and efficiency. In addition to these technical requirements, the re- quired protocols must be truly open. They must satisfy the conventions and criteria of openness that have come to be expected by the Internet mainstream community, ensuring that there are no restrictions whatsoever on their availability and usage. Specifically, the protocols must satisfy the following criteria: - They must be functionally free of patents, licensing requirements, or any other form of usage restric- tion. - They must be published as stable specifications which are freely, easily, and permanently available to any- one who wishes to use them. The ideal availability mechanism is Internet RFC publication. - They must be open to public review and commen- tary; and participation in the maintenance, revision and enhancement of the protocols must be open and free to any interested party. The maintenance process must also preserve the patent-freedom of the protocols. 13.4.3 The Key to WhiteBerry: The LEAP Protocols All the above requirements are fully satisfied by a set of mobile messaging protocols called the Lightweight & Efficient Application Protocols, or LEAP. LEAP is a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. LEAP is a layered family of protocols, of which two are of particular relevance to Mobile Messaging. The first of these is the Efficient Short Remote Operations proto- col, or ESRO, published as RFC 2188 [91 ]. ESRO pro- vides reliable connectionless transport services which can 214 CHAPTER 13. OPERATION WHITEBERRY be used for a variety of applications, including but not limited to Mobile Messaging. 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/. Built on top of ESRO is the Efficient Mail Submis- sion & Delivery protocol, or EMSD, published as RFC 2524 [5 ]. EMSD is a specialized native Internet messag- ing protocol which meets or exceeds the level of func- tionality, reliability and security provided by the existing SMTP protocols. EMSD has been designed with a major emphasis on efficiency, and fully supports the push mode of message delivery. For complete details on EMSD see the Manifesto article EMSD: The LEAP E-Mail Compo- nent, or visit the EMSD website at http://www.emsd.org/. In addition to satisfying all the necessary functional and technical requirements, the LEAP protocols also fully satisfy the required openness characteristics. They are open in the broadest sense of the word: they are freely and permanently available, subject to public review and revi- sion, and without usage restrictions of any kind. For com- plete details, see the Manifesto article The LEAP Protocol Development Model [9 ]. In principle, the WhiteBerry solution could be based on any set of protocols that satisfies the necessary require- ments. Other than LEAP, however, we are aware of no set of protocol specifications that satisfies these require- ments. Though we have actively searched for alterna- tives, to the best of our knowledge no such alternative exists. As the basis for WhiteBerry, therefore, the LEAP protocols are both ideal and unique. 13.4.4 How WhiteBerry Works The way in which the WhiteBerry solution brings Mobile Messaging capability to the user is illustrated in Figure 13.2. All LEAP-specific components are shown shaded in this figure. This figure is somewhat similar to Figure 13.1, and the description of WhiteBerry in this section is similar to the description of BlackBerry in Section 13.3.1. However, there are also very significant differences be- tween the two systems. First, the user must be provided with some form of mobile handheld device, as shown on the left side of the figure. In the case of BlackBerry, this could only be one of the two form factors provided by RIM. In the case of WhiteBerry, this could be any unconscious carry de- vice, such as a PDA, a cell phone, or a dedicated two-way 13.4. THE WHITEBERRY SOLUTION 215 Figure 13.2: The WhiteBerry Solution 216 CHAPTER 13. OPERATION WHITEBERRY pager, from any device manufacturer who has chosen to adopt the WhiteBerry model by LEAP-enabling the de- vice. The mobile device must be equipped with a wire- less modem. In the case of BlackBerry, this is the in- tegral RIM modem for the BellSouth Intelligent Wire- less Network. In the case of WhiteBerry, this could be any suitably miniaturized modem, which supports any appropriate wireless network, such as GSM/GPRS, Met- ricom, Packet CDMA, or CDPD. Though the device may be turned off, the modem will normally remain on at all times to accept incoming messages. The device must also be equipped with LEAP device software, allowing it to communicate via the LEAP pro- tocols with LEAP-enabled Message Centers. Next, the user must be provided with a LEAP-enabled Message Center to support his Mobile Messaging capa- bility. In the case of BlackBerry, this role could only be played by the RIM-operated/licensed BlackBerry Mes- sage Center. In the case of WhiteBerry, however, there is considerably more versatility in how this service can be provided. Under one scenario, Message Center service can be provided by an independent Subscriber Services provider, as shown in the center of Figure 13.2. Under WhiteBerry, this role can be played by any Message Center operator - for example, by any one of the large number of existing ISP companies. All that is required for an ISP or other Message Center operator to become a provider of LEAP- based Mobile Messaging services, is for them to install the necessary LEAP Message Center software. Anyone with access to the Internet can now exchange e-mails with the mobile user. E-mails addressed to the mobile account are fielded by the Subscriber Service provider from the Internet e-mail system using standard Internet protocols, then delivered to the mobile device using the LEAP protocols. The device modem remains on at all times to accept incoming messages, and the device notifies the user im- mediately (in any of the ways commonly used for pager notification, e.g. beep, buzz or vibrate) whenever a new message arrives. The user can then activate the device and read the message. To send a message, the user enters the message then submits it to the LEAP service provider via the LEAP protocols. The service provider then sends the message to its destination using standard Internet e-mail protocols. Users typically wish their mobile messaging capabil- 13.4. THE WHITEBERRY SOLUTION 217 ity to function as a wireless extension of an existing land- based e-mail account. For example, the user may wish the mobile device to act as an extension of a home or office desktop mail application, as shown at the top of Figure 13.2. This functionality is provided by installing the appropriate mail forwarding software on the desktop system. This software integrates with the desktop mail application, and allows messages to be selectively for- warded to the mobile device on the basis of user-defined e-mail filters. Properly qualified e-mails are forwarded to the LEAP service provider using standard e-mail proto- cols, then delivered to the mobile device using the LEAP protocols. When the user submits a message from the mobile de- vice, the LEAP service provider sends the message to its destination as usual, and in addition it can send a notifi- cation to the desktop mail application, to maintain mail- box synchronization between the handheld device and the desktop system. Under a different scenario, there may be a need to bring Mobile Messaging capability to a corporate e-mail system, as shown at the bottom of Figure 13.2. This func- tionality is provided by installing the appropriate LEAP software in the corporate Message Center. This endows the corporate Message Center with the same LEAP-enabled functionality as the independent LEAP Subscriber Ser- vice provider, which is therefore not needed under this scenario. Like the desktop software, the LEAP Message Center software allows e-mails to be selectively forwarded to the mobile device. But since the corporate Message Center is fully LEAP-enabled, these can be delivered directly to the mobile device using the LEAP protocols. This aspect of WhiteBerry operation constrasts starkly with the BlackBerry system, in which all messages must pass through the BlackBerry Message Center - even those forwarded from a peer Subscriber Service provider. 13.4.5 Putting Everything Together for the End User As described above, the WhiteBerry solution requires co- ordinated integration among several components. Figure 13.3 shows how these components fit together to provide true Mobile Messaging capability to the end user. If a so- phisticated end user were to assemble these components himself, he would need to follow these steps: 218 CHAPTER 13. OPERATION WHITEBERRY Figure 13.3: WhiteBerry Components 1. Acquire a suitable PDA; e.g. a Palm or Windows CE device. 2. Decide on an appropriate wireless network; e.g. GSM/GPRS or CDPD. 3. Acquire a wireless modem for the selected network, in a form factor compatible with the selected PDA; then attach the modem to the PDA. E.g. in the case of the Palm family of devices, and the CDPD net- work, suitable modems are available from Sierra Wireless and Novatel. 4. Purchase a subscription to the selected network through an appropriate network Service Provider; e.g. AT&T or GTE. 5. Activate the modem for use with the selected sub- scription, by configuring the modem as directed by the Service Provider. 6. Download the appropriate WhiteBerry client soft- ware for the selected PDA; e.g. from MailMeAny- where.org. 7. Choose a WhiteBerry Message Center operator, e.g. ByName.net, and activate an e-mail account with that operator. 8. (If desired) link the mobile e-mail account to an existing home or corporate e-mail account by in- stalling and configuring a rule-based forwarder on the existing home or corporate desktop system; e.g. by use of the Microsoft Outlook autoforwarding fa- cilities, or by use of FetchMail and ProcMail. 13.4. THE WHITEBERRY SOLUTION 219 And that's it. The user now has fully equivalent func- tionality to BlackBerry - but using his preferred choices of PDA, wireless network, wireless modem, network Ser- vice Provider, and Message Center operator. The user can assemble his WhiteBerry system using the best and/or most cost-effective option available for each component. And if the user should happen to own a PDA/modem combination already, e.g. for wireless web browsing, then the user can provide himself with full Mobile Messaging capability at zero incremental hardware cost. In principle, there is nothing to prevent an individ- ual end user from doing all this for himself. In reality, of course, it is impractical for the typical user to do this on his own - which is why we have systems integrators. A systems integration company such as Omnisky or Ya- daYada can readily bundle together all the above compo- nents and present the end user with a complete, turnkey WhiteBerry solution. These two scenarios (total assembly from scratch by the end user, vs. total third-party integration) represent two integration extremes. There are many shapes and sizes of partial integration lying between these extremes. For example, steps 3, 5 and 6 can readily be combined into a single product/service offering (as Omnisky does already, in fact, by packaging together a CDPD modem, AT&T account, and account activation as a wireless-enabling add-on for the Palm family of devices). The open WhiteBerry paradigm allows a supplier to step into any conceivable market niche. 13.4.6 Technical Challenges & Responses There are several challenges that can be made to the White- Berry model on technical and/or cost grounds. For ex- ample, the arguments can be made that wireless modems are too expensive to allow deployment of a cost-effective solution; or that battery longevity is too short to allow widespread acceptance by users. However, these objections and others like them are ultimately without basis. In the case of the modem cost, and all other cost-related objections, the response is the same: modem and other hardware costs have been falling, and will continue to fall. There is nothing about any of the WhiteBerry hardware components to prevent them from eventually becoming available as inexpensive commodity items. And there is no technical challenge that does not have a clear and straighforward resolution. To take the case of 220 CHAPTER 13. OPERATION WHITEBERRY battery longevity, the responses are: (a) increased net- work cell density will reduce active device power con- sumption; (b) inactive device power consumption will be drastically reduced by implementation of network proto- cols for efficient device sleep mode, and also by close integration between the modem and the protocol soft- ware for sleep mode operation; and (c) inherent battery longevity will continue to undergo gradual improvement. Clearly, there are no show-stoppers here. For a con- clusive demonstration of this one need look no further than BlackBerry itself - if RIM can successfully bring a viable product to market, then so can others. And as the technical and cost considerations become even less rele- vant, things can only get easier. A Word About Networks In general, the desired characteristics of a network de- pend upon its intended usage. The ideal technical net- work requirements for paging, and for generalized wire- less data transmission, are sufficiently different that these two applications have traditionally been considered to re- quire different networks. Historically, paging networks (both one-way and two-way) have been considered un- suitable for generalized wireless data usage; while gen- eralized wireless data networks have been considered in- adequate for specialized paging and Mobile Messaging applications. Because of this historical viewpoint, there is a contin- uing perception that only a certain class of networks are technically suitable for Mobile Messaging. However, this perception is incorrect. The key functional criteria for suitability of a network for Mobile Messaging are: - Coverage. In general, the greater the coverage foot- print the better, but nationwide or global coverage is by no means essential. Depending on the re- quirements of the user, local or regional coverage may be more than sufficient. - In-building penetration. In general, the higher the degree of in-building penetration the better. But again, depending on the usage pattern of the user, a lesser degree of in-building penetration may be adequate. - Device miniaturization and battery lifetime. To- day's mobile professional expects an unconscious 13.4. THE WHITEBERRY SOLUTION 221 carry form factor, and at least two full days be- tween battery recharges. Among other things, the density of the network transceivers must be suffi- cient to meet both these requirements. A variety of networks satisfy this requirement. - Data throughput. In general, a very high data throughput capability is not an essential require- ment for Mobile Messaging. Because messaging is an inherently asynchronous activity, based on a store-and-forward paradigm, data latency is not a major issue. Messaging is entirely feasible on net- works with data rates as low as 2400 bits per sec- ond. Based on the above, it can be seen that a broad range of networks are entirely suitable for Mobile Messaging. The BlackBerry system is currently limited exclusively to the BellSouth Intelligent Wireless Network. This net- work scores high marks on all four criteria listed above, and is therefore well-suited to Mobile Messaging. But it is by no means the only network that is suitable for this. And the WhiteBerry model allows any suitable wireless data network to be used, including GSM/GPRS, Metricom, Packet CDMA, and CDPD - which collec- tively account for most of the wireless network market of today. With proper industry cooperation and integra- tion, a messaging solution based on any of these networks can compete directly with closed solutions such as Black- Berry, or those based on the closed ReFLEX protocol. 13.4.7 WhiteBerry versus BlackBerry The major differences between BlackBerry and White- Berry are summarized in Table 13.1. In the world of closed systems, competition with Black- Berry takes the form of other proprietary turnkey sys- tems, which provide similar functionality. The WhiteBerry model is fundamentally different from this: it is an open industry model. Since the mobile mes- saging solution is based on a set of open protocols, each component of the solution is exposed to free competition. Vendors and service providers can now compete in every aspect of the mobile messaging solution: handheld de- vices, wireless modems, networks, message centers, and the provision of Subscriber Services to the user. The result of this is not just a set of competing, closed, non-interoperating solutions. Rather it is a thriving indus- try, in which active and independent competition takes 222 CHAPTER 13. OPERATION WHITEBERRY Table 13.1: BlackBerry vs. WhiteBerry place within every component of the user's ultimate value proposition. WhiteBerry Patent Resistance As noted previously, RIM has recently been granted a U.S. patent on the basis of its BlackBerry technology, which potentially threatens other closed Mobile Messag- ing systems. The WhiteBerry solution, however, is radically dif- ferent from closed systems in terms of its vulnerability to patents. Unlike BlackBerry and other closed systems, WhiteBerry is not a single static messaging solution; rather, it is a highly mutable meta-solution. That is, any partic- ular WhiteBerry implementation is created by integrat- ing together an appropriate set of components, so as to achieve the particular functionality desired by the sys- tems integrator or the end user. The components that go into any given WhiteBerry implementation may be drawn from a large family of com- ponents which includes the EMSD protocol engines, Fetch- Mail, ProcMail, mail forwarders, and various others. Each of these components is independent, freely available, use- ful in its own right, and entirely unrelated to the RIM patent. 13.5. INITIAL DEVELOPMENT FRAMEWORK 223 Because of this inherently component-based nature, the WhiteBerry solution is exceedingly resistant to the RIM patent claim, and indeed to patent infringement claims in general. By making all the necessary components freely and publicly available, WhiteBerry provides systems in- tegrators and end users with a variety of methods and strategies to circumvent or nullify invalid patent asser- tions. 13.5 Initial Development Framework All the essential components required to implement White- Berry now exist. As discussed in Section 13.4.1, all the technological components (devices, modems, networks) are well established and readily available. The necessary open protocols are also ready and avail- able: the LEAP protocols are complete and have been published as Internet RFCs, and open support organiza- tions for their continued revision and enhancement are up and running at LeapForum.org, ESRO.org and EMSD.org. In addition, an initial framework for the development of WhiteBerry solutions has been established. This frame- work consists of: - Open-source software implementations of the LEAP protocols for various devices and Message Center platforms - An open public forum for the development and dis- tribution of LEAP-related integration tools and fa- cilities - An initial set of free Subscriber Services to support early deployment of the WhiteBerry solution in end user devices - An initial end-to-end WhiteBerry implementation Each component of this development framework is described in the following sections. 13.5.1 Open-Source Software Implementa- tions Open-source software implementations of the LEAP pro- tocols are available for all major device and Message Cen- ter platforms. Reference Protocol Engines have been implemented in the form of portable code, which has been ported to a 224 CHAPTER 13. OPERATION WHITEBERRY wide variety of platforms and end user devices. On the device side, software has been implemented for pagers and cell phones; for palm size devices (Windows CE, Palm PC, Palm OS, EPOC); for Windows 2000, Windows 98/95, and Windows NT; and for Pine (UNIX, Windows, DOS). On the Message Center side, software is available for Windows NT, Solaris, and Linux. All of this software is being made publicly available through the MailMeAnywhere open-source software dis- tribution center, in the form of free software, subject to the General Public License (GPL) [36 ]. For complete de- tails visit the MailMeAnywhere website at http://www.MailMeAnywhere.org. 13.5.2 The MailMeAnywhere Development Forum The protocol engines provide the basic message submis- sion and delivery capability for the mobile environment. But this capability must be augmented with a variety of other tools and capabilities in order to bring a complete, well-integrated solution to the end user. Among other things, the user must be provided with flexible tools for selecting which e-mail messages are for- warded to the mobile device, and which can remain in his fixed mailbox for later review. The end user solution must also include facilities to ensure proper synchroniza- tion and continuity between the mobile account and the fixed account. In addition, there is a need to provide Mobile Mes- saging solutions in a variety of contexts. A mobile user may have a fixed e-mail account in any of various shapes and sizes, such as a corporate account or an ISP-based account, and he may wish to control and administer his mobile capability in various ways, such as via his desk- top mail application, or via his corporate or ISP-based mail server. In order to accomplish this large heterogeneity of Mo- bile Messaging implementation, the integration and de- velopment community requires a variety of tools for ac- cessing and processing the user's fixed mailboxes. In par- ticular, comprehensive and close integration of the LEAP protocol engines will be required with mail routers, mail retrievers, mailbox synchronizers, inbox filters and rule- and directory-based fowarders. For this purpose, MailMeAnywhere includes an open public forum for the development and distribution of the necessary tools and capabilities. The MailMeAnywhere development forum is a public framework for the collec- 13.5. INITIAL DEVELOPMENT FRAMEWORK 225 tive development and enhancement of LEAP integration tools on a continuous, on-going basis. This open development model, based on open proto- cols and open-source software, ensures the availability of a rich and expanding suite of tools and accessories for integration of the WhiteBerry solution in various config- urations and across multiple platforms. This open, heterogeneous development model is in sharp contrast to BlackBerry's narrow focus on Microsoft Outlook and Exchange. 13.5.3 Initial Subscriber Services The open WhiteBerry paradigm must address a classical bootstrapping problem: a useful WhiteBerry solution re- quires implementation of the LEAP protocols in both de- vices and Message Centers, each of which cannot func- tion without the other. Therefore a framework element has also been estab- lished to assist in overcoming this problem: an initial set of LEAP-based Subscriber Services have been put in place to provide support for early deployment of the pro- tocols in end user devices. These initial Subscriber Ser- vices are of limited scale and capability; however they are more than sufficient to play this initial support role, and to demonstrate the viability of the WhiteBerry solution. These Subscriber Services are entirely free, and are available at ByName.net, ByNumber.net, and My.ByName.net. For complete details visit these websites at http://www.ByName.net, http://www.ByNumber.net, and http://My.ByName.net. 13.5.4 Initial WhiteBerry Implementation As a starting point for further implementations, we have also established an initial WhiteBerry implementation. This implementation is freely available as a development tool to anyone who would like to examine it, enhance it, or use it as the basis for additional implementations. For complete details, see the announcement entitled: Announcing Free Availability of Neda Communication Inc.'s Enhanced Two-Way Paging (ETWP) Products and Services For WindowsCE Hand-Held PCs over CDPD and Wireless IP Neda-ETWP-wce-gold-1.2 226 CHAPTER 13. OPERATION WHITEBERRY June 12, 1998 This announcement is available at http://www.neda.com/products/Neda-ETWP/gold-1.2/wce/announce/announce.html [43 ]. This announcement provides a complete step-by-step description of how to build a WhiteBerry solution us- ing existing and available off-the-shelf components and services. As a concrete case-study example, we present the experiences of a particular user - we'll call her Lisa Simpson. The steps Lisa followed and the choices she made in assembling her WhiteBerry system are summa- rized in Table 13.2. The numbered steps in this table cor- respond to the generic steps described in Section 13.4.5 and Figure 13.3. Table 13.2: A WhiteBerry Case Study Implementation: Lisa Simpson At the end of this process Lisa had her very own, fully functional, true Mobile Messaging solution - and you can, too. This base implementation, of course, is not the same thing as a comprehensive, market-ready messaging so- lution. However, it clearly demonstrates the viability of WhiteBerry as a complete, end-to-end messaging solu- tion. And the existence of this base implementation means 13.6. MOBILE MESSAGING SECURITY 227 that WhiteBerry is not just an idea - it is an actual work- ing system, which is up and running today. 13.6 Mobile Messaging Security We claim in this article that WhiteBerry meets or exceeds the entire functionality of BlackBerry. There is one pos- sible objection that could be made to this statement: that, as described, WhiteBerry does not match BlackBerry's claimed security functionality. 13.6.1 BlackBerry Security In their promotional literature, BlackBerry claims to pro- vide "end-to-end" security using Triple DES encryption technology. A casual reading of this would lead one to believe that BlackBerry provides full message encryption all the way from the sending mail application to the re- ceiving mail application - i.e. all the way from the point of origin to the point of delivery. In the Internet world, this is conventionally what "end-to-end" means. In fact, the BlackBerry system only provides encryp- tion between the BlackBerry handheld and the corporate e-mail account. This provides security only for messages originating in or being delivered to the in-house corporate e-mail system. In the case of generic e-mails, which may be transmitted to/from any point on the Internet, Black- Berry provides no security whatsoever beyond the point of relay at the corporate system. In other words, one of the ends being referred to in BlackBerry's claim of "end-to-end" security is not the ul- timate user mail application, but the corporate account. BlackBerry thus only provides security over part of the transmission route from sender to recipient. This is rather like going out to do battle wearing a suit of armor that only offers protection from the waist down - it is only slightly better than no armor at all. Therefore BlackBerry does not provide true End-to- End security, and RIM's use of this term is disingenuous and misleading. The claimed security is limited and su- perficial, providing only a degree of psychological reas- surance to the user - it is more of a security blanket than genuine security. Furthermore, since the BlackBerry system is closed, details of the actual security implementation are unknown, and have not been subjected to external review. RIM's description of its security method may be adequate for 228 CHAPTER 13. OPERATION WHITEBERRY marketing purposes, but this does not provide sufficient information for a formal engineering validation. In general, e-mail users can achieve true End-to-End security by means of the existing PGP [49 ] or Secure MIME (S/MIME) [29 ], [30 ] technologies. These are the two methods most commonly used for e-mail security to- day. However, if these technologies are to provide true End-to-End security, they must be implemented at both ends - i.e. at both the sending and receiving e-mail appli- cations. But since the BlackBerry devices are closed, it is not possible for a BlackBerry user to make use of these or any other independent security mechanisms. Therefore not only does the BlackBerry system not provide genuine End-to-End security, its closed nature also precludes implementation of genuine End-to-End se- curity by any other means. 13.6.2 WhiteBerry Security There is no doubt that security is of major importance in the e-mail domain. However, the basic Internet e-mail protocols (SMTP, POP and IMAP) were originally de- signed without adequate consideration for the security is- sues. Because of this, and because of certain flaws in the implementation of these protocols, the Internet e-mail structure of today includes serious security compromises. Nevertheless, the existence of the above security com- promises has not prevented the widespread adoption and usage of Internet e-mail. Today, much of the daily e-mail traffic still takes place without any formal security pro- tection. In the case of those messages which do require secure transmission, additional security mechanisms are typically applied. There is a perception that there is a greater need for security in the wireless world