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 organizati