Mobile Instant Messaging Systems - A Comparative Study
Transcription
Mobile Instant Messaging Systems - A Comparative Study
HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering Telecommunications Software and Multimedia Laboratory Peter Salin Mobile Instant Messaging Systems A Comparative Study and Implementation Master’s Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Technology. Espoo, September 21, 2004 Supervisor: Professor Antti Ylä-Jääski Instructor: Juhani Malka, M.Sc. HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF THE MASTER’S THESIS Author: Peter Salin Name of the thesis: Mobile Instant Messaging Systems A Comparative Study and Implementation Date: September 21, 2004 Number of pages: 75 + 5 Department: Department of Computer Professorship: T-110 Science and Engineering Supervisor: Prof. Antti Ylä-Jääski Instructor: Juhani Malka, M.Sc. Ever since their introduction less than a decade ago, modern instant messaging systems have experienced a massive growth in users. Meanwhile, text messaging has revolutionized the use of the mobile phone, bringing mobile messaging forward as a new source of revenue for service providers. Now service providers look to enrich mobile messaging by bringing the combination of presence awareness and real-time messaging, that is instant messaging, to the mobile environment. However, several restrictions are inflicted on mobile services due to the differences of mobile and wireline environments. The instant messaging standards destined for mobile networks must be able to adapt to these restrictions. IMPS (Instant Messaging and Presence Service) is an instant messaging system designed especially for mobile environments. Another instant messaging system, the SIP (Session Initiation Protocol) based SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) service, will be introduced in forthcoming third generation (3G) networks as part of the 3G multimedia services. This thesis evaluates the applicability of IMPS and SIMPLE in mobile networks and presents the strengths and weaknesses of the standards in comparison to each other. The architecture of IMPS was found to be quite simple while SIMPLE is based on a more complex structure utilizing several different protocols and data formats. Despite their differences, both architectures are very scalable. The comparison also found the security services of SIMPLE to be better than those of IMPS. However, SIMPLE has problems with proxy traversal while IMPS is able to traverse proxies without problems. The performance of SIMPLE was considered slightly better than IMPS’s when it comes to bandwidth usage and delays, although the performance of IMPS is more than adequate for mobile environments as well. The level of extensibility and interoperability is equally high for both IMPS and SIMPLE. In conclusion, IMPS is easy to deploy due to its simple architecture, while considerable effort and resources are required to deploy the more complex SIMPLE service. On the other hand, SIMPLE enables a range of other multimedia services to be launched based on the same framework. As SIMPLE offers stronger security services, it is a better alternative for transporting business-critical information. In contrast, IMPS enables the creation of a global instant messaging service spanning both mobile networks and the wireline Internet, while SIMPLE is unable to accomplish the same due to proxy traversal problems. All in all, both services conform well to the requirements of mobile networks. Keywords: mobile instant messaging, instant messaging, presence awareness, IMPS, SIMPLE ii TEKNISKA HÖGSKOLAN Författare: Titel: Datum: Avdelning: Övervakare: Handledare: SAMMANDRAG AV DIPLOMARBETE Peter Salin System för mobila direktmeddelanden En jämförande studie och implementation 21.09.2004 Antal sidor: 75 + 5 Avdelningen för datateknik Professur: T-110 Prof. Antti Ylä-Jääski DI Juhani Malka Moderna system för direktmeddelande har ända sedan introduktionen för mindre än tio år sedan erfarit en massiv ökning i antalet användare. Under tiden har textmeddelanden (SMS) revolutionerat sättet på vilket mobiltelefoner används, vilket har fört fram mobila meddelanden som en ny inkomstkälla för tjänstleverantörer. Nu strävar leverantörer av mobila tjänster till att berika utbudet av tjänster genom att lansera direktmeddelande i en mobil omgivning. Mobila och stationära omgivningar skiljer sig emellertid avsevärt ifrån varandra. Detta medför en hel del begränsningar, till vilka en standard för mobila direktmeddelanden måste klara av att anpassa sig. IMPS (Instant Messaging and Presence System) är ett system för direktmeddelande konstruerat speciellt för att användas i en mobil omgivning. Ett annat system för direktmeddelande, det SIP (Session Initiation Protocol) baserade SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions), kommer att lanseras som en multimediatjänst i kommande tredje generationens (3G) nätverk. Detta arbete undersöker hur väl IMPS och SIMPLE tillämpar sig för användning i mobila nätverk samt beskriver standardernas styrkor och svagheter i jämförelse med varandra. Arkitekturen hos IMPS visade sig vara relativt simpel, medan SIMPLE har en mera komplex struktur och använder sig flera olika protokoll och data format. Trots skillnaderna, är skalbarheten hos båda arkitekturerna utmärkt. Jämförelsen visade också att SIMPLE erbjuder bättre säkerhetstjänster än IMPS. Däremot har SIMPLE problem med proxyservrar medan IMPS-trafik kan genomkorsa proxyservrar utan problem. Prestationsförmågan hos SIMPLE betraktades vara något bättre än IMPS’ när det gäller förbrukning av bandbredd och fördröjningar, även om prestationen hos IMPS också visade sig vara mer än tillräcklig för mobila omgivningar. När det gäller flexibilitet och interoperabilitet ligger bägge standarder på lika hög nivå. Som slutsats: IMPS är enklare att ta i bruk tack vare dess simplare arkitektur medan en lansering av SIMPLE kräver större ansträngingar och resurser. Å andra sidan möjliggör ramverket på vilket SIMPLE är baserat lanseringen av en lång rad andra multimediatjänster. Eftersom SIMPLE erbjuder starkare säkerhetstjänster, är den bättre lämpad för transportering av business-kritisk information. I motsats möjliggör IMPS skapandet av en global tjänst för direktmeddelande innehållande både mobila nätverk och Internet, medan SIMPLE inte förmår detsamma p.g.a. problem med proxyservrar. Allt som allt anpassar sig bägge tjänster väl till mobila omgivningar. Nyckelord: mobilt direktmeddelande, direktmeddelande, närvaro, IMPS, SIMPLE iii Acknowledgements This Master’s thesis has been done for Celtius Ltd. I want to thank the management of Celtius Ltd. for giving me the opportunity to write this thesis for their company. I wish to thank my instructor Juhani Malka for his valuable input and guidance during the entire work process. I would also like to thank my supervisor, Professor Antti Ylä-Jääski, for his helpful comments and advice regarding the thesis. My gratitude also goes to all those who read and commented the final draft version of this thesis. Finally, I would like to thank my family for their support throughout my entire studies. Espoo, September 21, 2004 Peter Salin iv Contents Abbreviations viii 1 Introduction 1 1.1 Objectives and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Internet Instant Messaging 3 2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Concepts and Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 Differences from Other Communication Systems . . . . . . . . . . . 8 2.4 2.5 2.6 Proprietary Instant Messaging Systems . . . . . . . . . . . . . . . . . . . . . 10 2.4.1 ICQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 AOL Instant Messenger . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.3 Yahoo Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.4 MSN Messenger/Windows Messenger . . . . . . . . . . . . . . . . . 11 Standards and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.1 IMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.2 SIMPLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.3 XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.1 Server Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.7 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.8.1 Types of Security Threats . . . . . . . . . . . . . . . . . . . . . . . . 17 v 3 Mobile Instant Messaging 20 3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Differences in Comparison to Instant Messaging in Fixed Networks . . . . . 22 3.4 3.3.1 Device Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.2 Network Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.4 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Standards and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.1 xMS (SMS, EMS, MMS) . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.2 IMPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4 Comparison of IMPS and SIMPLE 32 4.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3 4.4 4.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.1 Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.2 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.3 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.4 Coverage Loss 4.3.5 Proxy Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.1 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.2 Attack Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.5 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.6 Extensibility 4.7 Current Status and Future Trends . . . . . . . . . . . . . . . . . . . . . . . 52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7.1 Industry Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.2 Service Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.3 Future Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 vi 5 Implementation of IMPS CSP Protocol 5.1 5.2 5.3 55 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1.1 Overall Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1.2 CSP Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . 57 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.2 CSP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.3 CSP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.2 Tools 5.3.3 Software Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.4 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.3.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6 Discussion and Conclusions 65 6.1 Comparison of IMPS and SIMPLE . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Implementation of IMPS CSP protocol . . . . . . . . . . . . . . . . . . . . . 66 6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.4 Significance of the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Bibliography 70 A Message Flow Examples 76 vii Abbreviations 3GPP Third Generation Partnership Project APEX Application Exchange CIR Connection Initiation Request CLP Command Line Protocol CPIM Common Profile for Instant Messaging CPP Common Profile for Presence CSP Client-Server Protocol DOM Document Object Model DTD Document Type Definition EMS Enhanced Messaging Service GIF Graphics Interchange Format GLMS Group and List Management Server GPRS General Packet Radio Service GSM Global System for Mobile communications HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol (Secure) IEC International Engineering Consortium IETF Internet Engineering Task Force IM Instant Messaging IMAP Internet Message Access Protocol IMPP Instant Messaging and Presence Protocol viii IMPS Instant Messaging and Presence Service IMS IP Multimedia Subsystem IP Internet Protocol IRC Internet Relay Chat JPEG Joint Photographic Experts Group MD5 Message Digest Algorithm #5 MIDI Musical Instrument Digital Interface MIME Multipurpose Internet Mail Extensions MMS Multimedia Messaging Service MPEG Moving Pictures Experts Group MSRP Message Session Relay Protocol OMA Open Mobile Alliance PIDF Presence Information Data Format POP Post Office Protocol PRIM Presence and Instant Messaging Protocol RFC Request For Comments RTT Round-Trip Time SAP Service Access Point SAX Simple API for XML SHA Secure Hash Algorithm SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions SIP Session Initiation Protocol SIPPING Session Initiation Protocol Project Investigation SMCNP Server Mobile Core Network Protocol SMIL Synchronized Multimedia Integration Language S/MIME Secure MIME SMS Short Message Service ix SSP Server-Server Protocol TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol UML Unified Modeling Language UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier VoIP Voice over IP WAP Wireless Application Protocol WBXML Wireless Binary XML WLAN Wireless Local Area Network WSP Wireless Session Protocol XCAP XML Configuration Access Protocol XML Extensible Markup Language XMPP Extensible Messaging and Presence Protocol x Chapter 1 Introduction Picture yourself in a situation where you realize that you have an hour of free time to spend. You decide to gather a group of friends to meet for a cup of coffee. Using your mobile phone you are able to see which of your friends currently are available and possibly even where they are located and what mood they are in. Quickly you have gathered a list of people, potentially willing to keep you company. Next you send an instant message to the whole group, inviting them to join you. As all responses are sent to the group, negotiating the time and place to meet is efficient and easy. Before you know it, you are all at the cafeteria having your cup of coffee. The above example illustrates one application of mobile instant messaging. As neither presence information nor group instant messaging are available in current mobile networks, the above situation would require numerous phone calls or text messages, consuming most of the time available. The combination of presence awareness and real-time messaging offered by instant messaging systems has proved to be the source of a killer application in the Internet, gathering hundreds of millions of users. Although originally considered a teenager toy, the benefits of instant messaging have been realized by both academic and corporate organizations in the last few years. Concurrently with the instant messaging revolution of the Internet, the introduction of text messaging has launched a similar phenomenon in mobile networks. Over time, mobile messaging has proved one of the most important sources of revenue for providers of mobile services and new messaging services, such as multimedia messaging and mobile email, have been introduced in recent years. Now, instant messaging is about to make the transition from the wireline Internet to mobile networks. This thesis studies the requirements placed upon instant messaging systems by mobile environments and evaluates the applicability of two instant messaging systems set for introduction in mobile networks in the future. 1 CHAPTER 1. INTRODUCTION 1.1 2 Objectives and Scope The objectives of this thesis are: To identify requirements and limitations related to mobile instant messaging To compare IMPS and SIMPLE emphasizing the requirements of mobility To design and implement the client and the server end of the IMPS CSP protocol In order to be able to evaluate the applicability of instant messaging systems to mobile environments, the restrictions of mobile networks that affect such a system must be identified. Earlier work in this area has been performed by Parvianen et al. [48], Vogiazou [68] and Leggio et al. [37]. IMPS (Instant Messaging and Presence Service) and SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) are two instant messaging systems, both more than likely to be deployed in mobile networks in forthcoming years. The main objective of this thesis is to uncover the strengths and weaknesses of these services and to evaluate how well they conform to the requirements of mobile environments. This kind of study has not been performed earlier, but Leggio et al. [37] have evaluated the performance of XMPP (Extensible Messaging and Presence Protocol) in mobile networks while Greene et al. [27], Mituoka et al. [40] and Parvianen et al. [48] have proposed their own instant messaging solutions for mobile environments. Finally, the design and implementation of the Client-Server Protocol (CSP) of IMPS is one goal of this thesis. The CSP protocol provides clients of the IMPS instant messaging service with access to the IMPS server and the functionality provided by the IMPS service. In essence, CSP enables a user to interact with all other users connected to the same IMPS service. The scope of this thesis is limited to exploring instant messaging standards in general; evaluating single products or implementations of the standards is not inside the scope of the thesis. 1.2 Structure Chapter 2 introduces the concept of instant messaging and presents the solutions currently used in Internet instant messaging. Chapter 3 describes the services used to enable mobile messaging and studies the restrictions that mobile environments inflict on mobile instant messaging services. Two mobile instant messaging candidates, IMPS and SIMPLE, are compared in Chapter 4. Chapter 5 presents the design and implementation of the CSP protocol of IMPS. Finally, Chapter 6 discusses the findings of the thesis and presents the conclusions that can be drawn from them. Chapter 2 Internet Instant Messaging Instant messaging services have enjoyed a constant growth ever since their introduction. Real-time messages and presence information are the pieces of technology that makes instant messaging different from previous communication services. However, the success of instant messaging is not based on technical differences only; also the methods and concepts used in instant messaging clients, such as popup windows and buddy lists, have contributed to the birth of a completely new type of communication. Although first considered a toy for teenagers, the value of instant messaging to enterprises, e.g. in form of cost savings and increase in efficiency, has been recognized in recent years. This chapter introduces the concept of instant messaging as well as the solutions available for enabling Internet instant messaging. Section 2.1 defines the term ’instant messaging’. Section 2.2 presents the history of instant messaging in the Internet. In Section 2.3, an overview of the concepts and model of instant messaging is given. Section 2.4 describes the proprietary solutions for instant messaging while Section 2.5 presents standardized solutions. The architectural choices used in instant messaging systems are explained in Section 2.6. Section 2.7 describes the interoperability problem of Internet instant messaging. Finally, in Section 2.8 the security features of Internet instant messaging systems are discussed. 2.1 Definition Several different interpretations of the term ’instant messaging’ exist. This section clarifies the meaning of the term within this thesis. IEC (International Engineering Consortium) provides the following definition: ”Instant messaging (IM) is an Internet protocol (IP)–based application that provides convenient communication between people using a variety of different device types” [18]. Campbell et al. [14] defines instant messaging as ”the exchange of content between a set 3 CHAPTER 2. INTERNET INSTANT MESSAGING 4 of participants in near real time”. Webopedia.com [69] states that instant messaging is ”a type of communications service that enables you to create a kind of private chat room with another individual in order to communicate in real time over the Internet, analogous to a telephone conversation but using text-based, not voice-based, communication. Typically, the instant messaging system alerts you whenever somebody on your private list is online”. According to another online IT-specific encyclopedia, Whatis.com [70], instant messaging is ”the ability to easily see whether a chosen friend or co-worker is connected to the Internet and, if they are, to exchange messages with them”. Finally, Kohda et al. [35] refers to instant messaging as ”buddy list applications, which consist of two orthogonal services, presence and short messaging”. The IEC definition is rather vague and applies to almost all types of messaging. Campbell et al. recognizes the fact that instant messages are delivered to the recipient in real time. The remaining definitions all include presence as a part of instant messaging, thus exposing the dual nature of the term. Instant messaging is often perceived as a service consisting of both presence and sending of instant messages. However, the term instant messaging is frequently used also when referring to the sending of instant messages. In this thesis the former definition will mainly be used. If the term ”instant messaging” is referring to the sending of instant messages it will be made clear by context. Definition 1 Instant messaging is a type of communication service providing users with two elements; presence information and real-time messaging. As it is an essential part of instant messaging it is necessary to provide a definition for presence as well. Webopedia.com [69] defines presence as ”the ability to detect whether other users are online and whether they are available”. Day et al. [19] provides the following definition: ”Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. ”online” or ”offline”) of other users”. For the purposes of this thesis, the latter definition is suitable. It should be stressed that presence information is not restricted to online status only, other attributes such as mood, location and language might just as well be included. Also note that instant messaging is merely one application of presence; other technologies, e.g. VoIP (Voice over IP), provide presence services as well. Definition 2 Presence is a means for finding, retrieving, and subscribing to changes in the presence information of other users. CHAPTER 2. INTERNET INSTANT MESSAGING 2.2 5 History The Unix ’talk’ tool, released in the mid 1980’s, was one of the first applications to provide real-time messaging. ’Talk’ did not provide presence information, but combined with e.g. the Unix ’finger’ command, the elements of instant messaging were in place. ’Zephyr’, a notification service released for Unix in 1987, combined real-time messaging and online status information, but it was originally intended for sending short notifications to users and not for session-like communication. In 1988, Internet Relay Chat (IRC) was introduced. IRC provides both real-time messaging and online status information; therefore it can be classified as instant messaging. Private messaging between two users is the most frequently used type of communication for instant messaging applications. IRC differs from this as it is designed and mainly used for group chat, i.e. users join together at a channel (or chat room) where the ongoing discussion is seen by all joined users. Instant messaging as we know it today was born in 1996, when Mirabilis, a small Israeli start-up company, launched ICQ (I Seek You). ICQ included features such as buddy lists, presence subscriptions/notifications and, of course, sending of instant messages. Whereas all the previously mentioned solutions were text-based, the ICQ client came with graphical user interface making it very easy to use. The freely distributed ICQ rapidly gained popularity, reaching 850 000 registered users in within six months of its release. As the amount of users connected to the Internet kept soaring, so did the popularity of ICQ. Although ICQ was free, the major players in the Internet business recognized the value of such a vast user base. In May 1997 AOL (America Online) released their instant messaging software, the AOL Instant Messenger. One year later, in June 1998, AOL acquired the majority of instant messaging users when it bought Mirabilis and ICQ. Microsoft and Yahoo were not going to let AOL go unchallenged as they released their own solutions, MSN Messenger and Yahoo Messenger. All of these new applications became very popular, having a considerable amount of registered users. Unfortunately there was a slight problem; all solutions were based on proprietary protocols, meaning that a user of one IM system could not exchange messages with a user of another IM system. The problem was addressed by the Internet Engineering Task Force (IETF), which in 1999 formed the Instant Messaging and Presence Protocol (IMPP) working group. The group was to specify requirements and framework for instant messaging, and eventually produce a standard instant messaging protocol. The IMPP working group had severe difficulties in deciding on an instant messaging protocol. Therefore it was decided to let the market decide and three new work groups were formed, each creating their own protocol: Application Exchange (APEX, formerly IMXP), Presence and Instant Messaging Protocol (PRIM) and SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). The IMPP working group would define a CHAPTER 2. INTERNET INSTANT MESSAGING 6 model and common formats for instant messaging, thus ensuring interoperability between the protocols. SIMPLE proved to be the strongest of the three candidates; PRIM was discontinued quite early and APEX, although a finalized standard, has generated only limited interest. In 2002, a new challenger joined the race as IETF approved a working group for the Extensible Messaging and Presence Protocol (XMPP). Since then SIMPLE and XMPP have been battling it out, along with IMPS (Instant Messaging and Presence Services), a solution mainly targeted at mobile environments but perfectly applicable elsewhere as well (see Section 3.4.2). Figure 2.1 displays the growth of users of instant messaging along with the timeline of instant messaging. Figure 2.1: The history and user growth of instant messaging. Source: IDC 2.3 2.3.1 Overview Concepts and Model RFC (Request For Comment) 2778 [20], produced by the IETF IMPP working group, defines a common vocabulary and presents an abstract model for instant messaging. This model is used as such by all current solutions, both proprietary and open standards. CHAPTER 2. INTERNET INSTANT MESSAGING 7 Presence Service Figure 2.2 displays an overview of a presence service. A presence service has two distinct types of clients: ’presentities’ and ’watchers’. Presentities provide presence information to the presence service, while watchers request presence information about presentities from the presence service. Naturally, the same application can act both as a presentity and as a watcher. Figure 2.2: Overview of a presence service The watchers are classified as well; there are ’subscribers’, ’fetchers’ and ’pollers’ (see Figure 2.3). A subscriber is a watcher that has subscribed to the presence information of a presentity. The presence service keeps track of the subscriptions and sends a notification to the subscriber whenever the presence information of the subscribed presentity changes. A fetcher requests the presence service for presence information about a presentity. The presence service does not send notifications to fetchers, presence information is only sent upon the request of the fetcher. A poller is a special kind of a fetcher that polls the presence service for presence information about a presentity on a regular basis. Figure 2.3: Different kinds of watchers Instant Message Service Equally to the presence service, the instant message service also has two kinds of clients: ’senders’ and ’instant inboxes’ (see Figure 2.4). Senders are the source of instant messages CHAPTER 2. INTERNET INSTANT MESSAGING 8 to be delivered by the instant message service. An instant inbox is a container for instant messages that are to be read by the owner of the inbox. The instant message service accepts instant messages from senders and attempts to deliver them to the instant inboxes, to which they are addressed. Typically, the instant inbox resides in the client application, although it is not required by the IMPP definition. Figure 2.4: Overview of an instant message service 2.3.2 Differences from Other Communication Systems Model Presence, as such, is clearly not part of any major established communication systems of today, but also the method for delivering messages differs considerably from the methods currently used. Most of the currently used messaging systems are based on a paradigm called ’store-andforward’. When sending a message over a network using this paradigm, each message transfer agent stores and forwards the message to the next agent. In case the next agent cannot be reached, delivery can be reattempted later on. The store of the message transfer agent closest to the user agent of the recipient usually serves as an inbox to the user agent. The user agent fetches the messages from the inbox when it is online. Even though it is possible for messages to arrive real-time, ’store-and-forward’ is viewed as non-real-time delivery system since all delivered messages do not arrive in real-time. Examples of messaging systems using ’store-and-forward’ include traditional email, SMS (Short Message Service) and MMS (Multimedia Messaging Service). For instant messaging systems, intermediate elements along the path from the sender to the recipient merely relay the instant message to the next element without storing it. If the recipient cannot be reached, e.g. when the user is not online, then the instant message is normally discarded. Some instant messaging systems provide storage for messages sent to offline users, but this is a distinct service and not part of instant messaging as such. Sending instant messages from peer to peer is also possible using a few instant messaging CHAPTER 2. INTERNET INSTANT MESSAGING 9 systems (e.g. ICQ and SIMPLE). These systems provide the sender with the address of the recipient, using which the instant messages can be sent directly to the recipient without any server intervention. Usage Voice calls and email are by far the two most popular communication systems of today [8]. Table 2.1 shows some usage related properties of instant messaging compared with the corresponding properties of voice calls and email. Instant messaging can be seen as some kind of combination of features from voice calls and email. Like voice calls instant messaging provides real-time communication but at a price comparable to email. Of course, instant messaging is not free; deploying an instant messaging solution in an enterprise requires noticeable investments. However, after deployment the cost of usage is significantly lower for instant messaging than for voice calls, especially for international communication. When it comes to archiving, email systems provide the most sophisticated solutions. Presence information is one of the greatest benefits for users of instant messaging. Surveys show that 40-60% of business related phone calls fail due to the callee being busy or absent [67]. Presence information practically eliminates this phenomena for instant messaging, assuming that users keep their presence information up-to-date. Table 2.1: Comparison of popular messaging systems Messaging System Real-time Cost Presence Archiving Voice call Yes High Partly, the call is either established or not No Email No Low No, the sender does not know whether the recipient is available or not. Yes Instant Messaging Yes Low Yes, the status of the recipient is known by the system at all times. Depends on the IM client. Must often be done explicitly by the user. Table 2.2 shows how initiating a business related line of communication using different messaging systems affects the productivity of parties involved. Voice calls often interrupt the work of the callee, and on the contrary, emailing is more prone to suspend caller’s work for a while. Instant messaging is more like voice calls in this aspect, but presence information provides a means to prevent unnecessary interruptions. Instant messaging can also reduce productivity if not deployed carefully within an organization. Gossiping and constant interruptions are some aspects that can decrease productivity. The productivity aspect of instant messaging is discussed in more detail in [44] and [64]. The comparisons of Tables 2.1 and 2.2 reveal that instant messaging have both strong and weak points in comparison with current communication systems. There clearly exists CHAPTER 2. INTERNET INSTANT MESSAGING 10 Table 2.2: The influence of messaging systems on productivity Messaging System Caller Callee Voice call Generally no decrease in productivity. If the callee is reached, a direct answer can be received. Often decreases productivity as the interrupted callee must drop its current work in order to answer the call. Email Decrease in productivity while waiting for a reply. Affects productivity only slightly since the callee can choose when to answer the email. Instant Messaging Typically no productivity reduction. The presence service allows the caller to select currently available callee. Reduces productivity upon message reception, but the callee can use the presence service to control the arrival of messages. a niche for instant messaging as it is more suitable for particular tasks than the current systems. However, instant messaging will not eliminate any of the current systems. Users will choose which system to use based on the type of communication. Instant messaging is suitable for quick real-time conversations, email is convenient for errands that do not require an immediate response and voice calls are often preferred for e.g. business negotiations as the risk of misunderstandings is reduced. 2.4 Proprietary Instant Messaging Systems The instant messaging market is currently dominated by three big companies, AOL, Yahoo and Microsoft. These companies all offer their own proprietary solutions based on private protocols that are not interoperable. From the viewpoint of instant messaging, there are no fundamental differences between the solutions. Instead, the solutions try to attract users by incorporating non-instant messaging features such as weather reports or online games. The rest of this section describes these instant messaging systems in brief. 2.4.1 ICQ ICQ (short for I Seek You), created in 1996 by a small Israeli start-up company called Mirabilis, is considered the ancestor of instant messaging systems. ICQ introduced concepts like buddy lists, presence subscriptions and block lists, which form the basis for every instant messaging system of today. Internet growth was exponential at the time and ICQ quickly gathered a large user base. When Mirabilis was bought for $287 by AOL in 1998, ICQ had already gathered 12 million users. Currently ICQ has 180 million registered users, of which approximately 68 millions are active users. The majority of the user base is located in Asia and Europe, while the amount of users in the U.S. is relatively small. Table 2.3 presents the amount of active users per instant messaging system. The numbers are based on a research performed by the Radicati Group in October 2003. CHAPTER 2. INTERNET INSTANT MESSAGING 11 Table 2.3: Active users per proprietary instant messaging system 2.4.2 Messaging System Active Users AIM 100 million ICQ 68 million MSN 66 million Yahoo 36 million AOL Instant Messenger In the early 1990’s America Online (AOL) had a significant amount of users subscribing to their online services, which included communication through electronic bulletin boards. In May 1997 AOL released the AOL Instant Messenger (AIM) to provide these users with the means to communicate with the outside world and vice versa. AIM quickly gained popularity especially in the U.S., home of AOL, and was starting to catch up with ICQ. The competition between ICQ and AIM came to an end in 1998, when AOL bought the company behind ICQ, cornering about 90% of the market. The amount of users has not decreased since then, but the introduction of several competing systems has reduced the market share. Presently, AIM is used by roughly 100 million people. 2.4.3 Yahoo Messenger Yahoo joined the instant messaging race in June 1999 with the release of the Yahoo Messenger. Starting with no user base, but with a brand well-known to many users of the Internet, Yahoo currently has a user base of around 36 million for their instant messaging services. 2.4.4 MSN Messenger/Windows Messenger Microsoft published their instant messaging solution, the MSN Messenger, in July 1999. Similarly to Yahoo, Microsoft started out with a non-existent user base but coupling the Messenger with e.g. Hotmail and Windows has enabled Microsoft to build a large user base rapidly. As of now Microsoft has two different instant messaging clients. In addition to the previously mentioned MSN Messenger, the Windows Messenger was released for Windows XP in 2001. In comparison to the MSN Messenger, the Windows Messenger is more business focused and includes support for e.g. SIMPLE and the Exchange IM Server. The two clients are interoperable as both use the same instant messaging network. All in all, Microsoft’s instant messaging system currently serves about 66 million users. CHAPTER 2. INTERNET INSTANT MESSAGING 2.5 12 Standards and Protocols Ever since it became evident that users of the proprietary solutions would not be able to communicate with each other, IETF has been striving to produce a standardized solution for instant messaging. This section presents the results of the standardization efforts. 2.5.1 IMPP IETF originally chartered IMPP (Instant Messaging and Presence Protocol) in order to define protocols and data formats necessary to build an internet-scaled instant messaging system. The working group managed to produce a model for presence and instant messaging in RFC 2778 [20] and requirements for an instant messaging protocol in RFC 2779 [19]. However, as stated in Section 2.2, the working group failed to achieve a common consensus for an instant messaging protocol. This resulted in the launch of several new working groups specifying protocols based on IMPP. It was decided that although the IMPP working group was not to specify any instant messaging protocol, it would carry on with its work. It would focus on producing standards for enabling interoperability between instant messaging systems. The working group has since created RFCs containing: a common extensible instant message format (message/cpim) a common extensible presence information format (application/pidf+xml) a common profile for instant messaging (CPIM) a common profile for presence (CPP) CPIM [50] and CPP [51] specify semantics and data formats for common instant messaging and presence services. The goal of the profiles is to facilitate the creation of gateways between instant messaging systems for interoperability. CPIM uses the message/cpim MIME (Multipurpose Internet Mail Extension) type [7] as data format for instant messages while PIDF (Presence Information Data Format) [65] is used for formatting presence information in CPP. In order for an instant messaging system to be IMPP compliant, it must conform to the CPIM and CPP profiles and their data formats as well as meet the requirements of RFC 2778 and RFC 2779. 2.5.2 SIMPLE The IETF SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) working group was one of the three working groups formed in 2000 when the IMPP CHAPTER 2. INTERNET INSTANT MESSAGING 13 working group failed to agree on a common protocol for instant messaging. Of the three, the SIMPLE solution is the only one still going strong; the other two have more or less failed. As the name indicates, SIMPLE is based on SIP (Session Initiation Protocol) [60]. The primary work of the SIMPLE working group is to generate an IMPP-compliant proposed standard SIP extension for instant messaging. SIMPLE defines the presence protocol as an instantiation of the general event notification framework for SIP [56]. For sending instant messaging SIMPLE provides two modes: a pager mode [14] and a session mode [13]. When using the pager mode instant messages are sent as SIP messages. In session mode SIP is used to initiate a session, in which the instant messages then are sent. Detailed information concerning the technical details of the SIMPLE specifications can be found in Chapter 4. The progress of the SIMPLE working group has been quite slow, mostly due to the complexity of the SIP protocol. Overall, the SIMPLE specifications currently consist of close to 20 Internet Drafts. Only a few Requests for Comments has been produced so far, including pager mode messaging specified in RFC 3428. Despite the slow-moving standardization process, the SIMPLE standard has gained support from several major companies including Microsoft, IBM and Yahoo. 2.5.3 XMPP The Extensible Messaging and Presence Protocol (XMPP) is beyond doubt the strongest challenger to the SIMPLE standard in the Internet. Like SIMPLE, XMPP is also administered by an IETF working group, i.e. the XMPP working group. XMPP has been formed from the basis of the Jabber protocol. The Jabber protocol is the result of a project started by Jeremie Miller in 1998 [16]. The goal of the project was to produce an interoperable and open instant messaging protocol, an alternative to the proprietary solutions. The first public release of the protocol took place in May 2000. In June 2000 project members sent an Internet Draft of the Jabber protocol to the IMPP working group (see Section 2.5.1) as an instant messaging protocol proposal. However, the organization of the Jabber project was not mature enough at the time and the Internet Draft was left to expire. In 2001 the Jabber Software Foundation was formed to organize the projects and commercial bodies involved in the Jabber community. Following the reorganization, a new Internet Draft was submitted to the IETF in February 2002, eventually leading to the birth of the XMPP working group in October 2002. XMPP is in essence the core of the XML (Extensible Markup Language) based Jabber protocol. XMPP has been made IMPP compliant by the working group. The Jabber Software Foundation will continue to work on the parts of the Jabber protocol that are not part of XMPP or IMPP, exploring features such as: multi-user chat, calendaring and CHAPTER 2. INTERNET INSTANT MESSAGING 14 whiteboarding. Compared to SIMPLE, the XMPP solution is more mature. Recently, three of four Internet Drafts have been approved as Proposed Standards and the protocol has already been widely deployed with tens of thousands of active servers and millions of users. Although it has not acquired the support of as many major companies as SIMPLE, XMPP is also embraced by big enterprises, including Hewlett-Packard and Intel. An in-depth comparison of SIMPLE and XMPP from the viewpoint of XMPP can be found in [17]. 2.6 Architecture Although virtually all currently available instant messaging systems are based on different protocols, architecturally the solutions are quite similar. Nevertheless, two greater architectural aspects can be distinguished, namely the distribution of servers and the mechanism for message exchange. 2.6.1 Server Distribution Essentially two models can be found for how servers are organized in current instant messaging systems: the centralized model and the distributed model. In the centralized model, all information is gathered at one place handled by either one server or a cluster of servers. All traffic resulting from registration and lookup tasks, such as logging in, subscribing to presence, fetching presence and receiving notifications, is routed through the centralized server. In the distributed model the information is stored by a network of servers, all managing the information related to their own domain. When users request their home server for information available in other domains, the server forwards the request to the server of that domain. Table 2.4: Advantages and disadvantages of the server distribution models Characteristic Centralized model Distributed model Administration/Maintenance Easy Moderate Scalability Limited Good Attack vulnerability High Moderate Performance Limited Good Table 2.4 provides a light comparison of the two models. For a single authority, the centralized model is easier to administer and maintain than the distributed model. Hence, all the proprietary instant messaging systems are based on the centralized model (see Table 2.5). CHAPTER 2. INTERNET INSTANT MESSAGING 15 On the other hand, the centralized model has several obvious disadvantages. When the group of users accessing the system expands, more and more traffic is directed at the server (or cluster of servers) causing severe congestion. All proprietary IM systems have quite recently experienced outages relating to this as the amount of users logging on has been soaring. The single point of access is also a security issue as it makes the system vulnerable to denial-of-service attacks. The distributed model is more scalable with less traffic directed at a single server. In addition, an attack on a server does not usually affect the whole system, but as Lundgren et al. points out in [39], many of the current distributed systems can suffer from single points of failure if not built carefully. Also, since most communication takes place between users in the same region, a home server in a distributed system is able to deliver information faster than a centralized server. 2.6.2 Message Exchange When it comes to exchanging messages between counterparts, the instant messaging systems can be divided into two camps. One sends all messages, including instant messages, via a dedicated server to the recipient, while the other transmits instant messages peerto-peer. For peer-to-peer messaging, only instant messages are sent from peer to peer, all login and presence information must still be sent to the server (see Figure 2.5). Figure 2.5: Peer-to-peer instant messaging Again, both mechanisms come with both gains and losses. Sending instant messages via a server places an extra burden on the server, adding further delay to the delivery under congestion. On the other hand, sending messages via a server protects the identity of the users, as the IP (Internet Protocol) address of a user is not disclosed to other users. Group chat is also easier to implement when messages pass through a server. With peer-to-peer messaging the IP addresses of the involved parties are disclosed, but a more efficient data transfer is achieved. Some instant messaging systems send text based instant messages via a server, but sends content requiring more bandwidth (e.g. video and CHAPTER 2. INTERNET INSTANT MESSAGING 16 files) peer-to-peer in order to reduce server load. Table 2.5 lists the server distribution model and message exchange mechanism for the existing instant messaging systems. A more detailed evaluation of peer-to-peer networking and server distribution has been performed by Quintana et al. in [55] Table 2.5: Architectural differences between instant messaging systems 2.7 Messaging System Registration/Lookup Message exchange AIM Centralized Via server ICQ Centralized Peer to peer IRC Distributed Via server/Peer to peer IMPS Distributed Via server MSN Centralized Via server SIMPLE Distributed Peer to peer XMPP Distributed Via server Yahoo Centralized Via server Interoperability Interoperability is a serious problem in today’s world of instant messaging. As mentioned in earlier chapters, the proprietary solutions are not able to cooperate, creating ’islands’ of users unable to communicate with each other. The problem can be seen by comparing Table 2.3 on page 11 with Figure 2.1 on page 6; the sum of users of four different instant messaging systems is already greater than the sum of all users. This is, of course, due to users being forced to run several different clients concurrently in order to reach all their contacts. The fear of losing their large user bases makes the companies behind the proprietary solutions reluctant to open up their systems. The interoperability problem has initiated attempts to create clients able to communicate with all major proprietary protocols. As the proprietary protocols are not publicly documented, these solutions are purely based on reverse-engineering. The messengers from Trillian and Odigo are probably the most advanced in this area. The multi-network clients do only hide the interoperability problem they do not solve it, e.g. users are still required to have accounts in all IM systems they want to access. In addition, the corporations owning the proprietary solutions keep changing their protocols in order to cut off multi-network clients. Most of the up-and-coming open standard instant messaging protocols are IMPP compliant. This makes it relatively straight-forward to create gateways enabling users of one instant messaging system to interact directly with users of another system. CHAPTER 2. INTERNET INSTANT MESSAGING 2.8 17 Security The competition for users caused the companies behind the proprietary instant messaging solutions to give security a low priority, putting most emphasis on the feature richness for their products. Because of this, notable security flaws can still be found in all proprietary solutions. The forthcoming standardized solutions have incorporated stronger security mechanism into their design. This makes the standardized instant messaging systems strong contenders in the enterprise instant messaging market. 2.8.1 Types of Security Threats Several types of security threats for instant messaging can be identified. The main threats are briefly discussed below, more comprehensive studies of instant messaging security threats can be found in [29], [38], [42] and [64]. Worms A worm is a program that tries to propagate itself across a network, using the resources available on one machine to attack others. Furthermore, a worm might try to cause damage on the attacked machine before propagation. Most worms are programs spread through email. The content of the email tries trick users into running the worm, in which case the worm searches the contacts of the user and forwards itself to these. Anti-virus products monitoring email traffic are quite effective against worms and can reduce the rate of propagation considerably. Although, worms can propagate just as well through instant messages than through email, support for monitoring instant messaging has not been available until just recently. Trojan Horses A Trojan horse is a program masquerading as a benign application, tricking the user into executing it. Upon execution the Trojan horse usually opens a backdoor, through which an attacker can access the system. The Trojan horse might also collect user information, such as logins and passwords, and send them over the Internet to the attacker. Traditionally, firewalls provide protection against Trojan horses, since the firewall can be configured to block all traffic but traffic from well-known services. When it comes to instant messaging the Trojan horses can operate via the instant messaging client, making it hard to detect using traditional firewalls. Most Trojan horses exploiting instant messaging utilize the file sharing capabilities in order to infiltrate the system. CHAPTER 2. INTERNET INSTANT MESSAGING 18 Buffer Overflow Attacks Buffer overflow attacks exploit design flaws that allow an attacker to send overly long input streams to an application, causing the application to overflow its memory and execute code provided by the attacker instead. Buffer overflow vulnerabilities have been found in all four of the major proprietary instant messaging solutions. Nguyen provides a list of attacks exploiting known buffer overflow vulnerabilities of the instant messaging systems in [42]. Man-in-the-Middle Attacks A man-in-the-middle attack, allows an adversary to listen to and insert messages into an ongoing session, impersonating one of the users. Alternatively, the adversary can attempt to hijack the connection, disconnecting one of the parties and continuing the session impersonating the disconnected user. The intention of a man-in-the-middle attack is usually to obtain user passwords and other secret information, either by eavesdropping the connections or by asking the user directly, disguised as a trusted friend. A man-in-the-middle attack against a proprietary instant messaging system is fairly easy to carry out as most systems offer virtually no protection against it. Data is usually sent both unencrypted and unauthenticated, making reading and producing messages easy for an adversary. The standard solutions provide better protection against man-in-the-middle attacks. Replay Attacks A replay attack is an attack in which the adversary records a session between two parties and later replays the recorded data impersonating one party of the earlier communication. Systems with a weak login mechanism are vulnerable to this attack since the adversary can login as another user merely by replaying a previously recorded session. Denial-of-Service Attacks A denial-of-service (DoS) attack aims to overload the system or service which it is directed at, effectively making it impossible to use the service. Flooding the target with messages is the most usual type of denial-of-service attack, but known vulnerabilities of the target system that allow the adversary to cause the system to consume a large amount of CPU or to halt the system can also be used in a DoS attack. For attacking large systems, a distributed DoS attack involving numerous computers is often used. Especially instant messaging systems based on architectures with centralized servers (see Section 2.6.1) are vulnerable to this kind of attack. Although the usual reason for a DoS CHAPTER 2. INTERNET INSTANT MESSAGING 19 attack is to cause annoyance, it can also be used for example when hijacking a session in order to block one party of the session. Chapter 3 Mobile Instant Messaging Similar to instant messaging in the Internet, mobile messaging also took off in the last decade of the 20th century. Mobile services might seem no different from Internet services from a user’s point of view, but the mobile environment imposes several requirements that a mobile service must fulfill before it can be successfully launched. This chapter presents the concept of mobile messaging and identifies the restrictions of mobile environments that a mobile instant messaging service must be able to handle. The chapter consists of the following parts: Section 3.1 defines the term ’mobile instant messaging’. Section 3.2 briefly presents the history of mobile messaging. The differences between mobile and fixed environments from a mobile instant messaging point of view are described in Section 3.3. Finally, Section 3.4 describes the standards related to mobile instant messaging. 3.1 Definition As the word ’mobile’ has several distinct interpretations depending on the context, attempting to provide an unambiguous definition of ’mobile instant messaging’ is in place. MobileIN.com [41] provides a proper definition stating that ”Mobile Instant Messaging (MIM) is the ability to engage in IM from a mobile handset via various bearer technologies, which may include SMS, WAP or GPRS”. Although implied by the examples of bearers in the previous definition, it should be stressed that only devices connected through wireless bearers can participate in mobile instant messaging. In the scope of this thesis, a device must be able to be both mobile and connected to a network simultaneously in order to engage in mobile instant messaging. A device connected to a wireline network that first is disconnected, then moved and finally reconnected does not fit this requirement. Furthermore, a handset is required to participate in mobile instant messaging. Therefore, 20 CHAPTER 3. MOBILE INSTANT MESSAGING 21 using instant messaging from a laptop connected through a wireless connection is not considered mobile instant messaging in the scope of this thesis, as the laptop does not have the limitations of a typical handset. Definition 3 Mobile instant messaging is the ability to engage in instant messaging from a mobile handset via various wireless bearer technologies. Finally, it should be noted that it is possible for an instant messaging system providing mobile instant messaging to users with mobile handsets to provide instant messaging to users with fixed connections as well. In fact, this is usually the preferred behavior. 3.2 History As wireless networks only have existed for a few decades, the history of mobile messaging is short and the history of mobile instant messaging even shorter. Mobile messaging took off in the late 1990’s when SMS messaging was made available to GSM (Global System for Mobile communications) subscribers. In the following years, SMS usage kept rising rapidly as can be seen from Figure 3.1. Figure 3.1: Worldwide monthly SMS traffic. Source: EMC Research The success of SMS got the operators of mobile networks to realize the value of mobile messaging; considerable revenues can be gained using only a fraction of the available bandwidth. Therefore, new messaging services similar to SMS but with richer features, such as EMS (Enhanced Messaging Service) and MMS, have been designed and deployed lately. The most successful messaging system of the Internet, email, has also been brought to mobile clients in a number of different ways. In the beginning, email in mobile clients was CHAPTER 3. MOBILE INSTANT MESSAGING 22 handled through SMS messages. Later, mobile email was made available through WAP (Wireless Application Protocol) and recently mobile devices with email clients managing email using well-known mail protocols such as IMAP (Internet Message Access Protocol) or POP (Post Office Protocol) on top of GPRS (General Packet Radio Service) have been made available. Instant messaging solutions for mobile devices have been available since 2002, when AOL and Yahoo started providing access to their instant messaging network using an SMS interface. However, these services are not available worldwide, only users of wireless carriers that have made an agreement with AOL or Yahoo can use them. The SMS-based instant messaging services are not very convenient to use as they require the user to remember several commands and phone numbers. The recent introduction of mobile devices that allow both installation of third party software and packet switched data transfer has enabled companies to develop their own mobile client software for their proprietary protocols. For example, AOL has released an instant messaging client for mobile devices running the Symbian operating system. Work for a non-proprietary mobile instant messaging solution commenced in 2001 when Ericsson, Nokia and Motorola teamed up to form the Wireless Village initiative (now known as IMPS), a joint project established to create universal specifications for mobile instant messaging. The first release of the specifications was made available in 2002 but it was not until in the fourth quarter of 2003 that the first mobile device with support for the technology was published. The IP Multimedia Subsystem (IMS) defined for enabling multimedia communication services for 3G networks uses SIP for establishing multimedia sessions. The upcoming 3GPP (Third Generation Partnership Project) Release 6 specifications include instant messaging using SIMPLE, bringing SIMPLE forth as a contender to IMPS in the mobile instant messaging world as soon as IMS is widely deployed. 3.3 Differences in Comparison to Instant Messaging in Fixed Networks Transitioning from developing Internet services targeted at fixed networks to developing mobile services is not a trivial task. The mobile environment introduces several constraints on a mobile service that do not exist in traditional, fixed environments. Not only does the technology used for establishing wireless networks place limitations on a mobile service, but also mobile terminals and the behavior of users differ significantly between fixed and mobile environments. This section presents the characteristics of mobile environments that deviate from the corresponding ones of wireline environments. Even though only aspects affecting mobile instant messaging services are considered here, most of them apply to mobile services in general. CHAPTER 3. MOBILE INSTANT MESSAGING 3.3.1 23 Device Limitations Due to the requirement of portability, mobile devices have several differences in comparison to stationary computers, which should be considered when designing a mobile service. These differences are presented briefly below; in-depth studies are available in [15], [23] and [52]. Display Size As mobile devices are pocket-sized for portability, it follows that displays must be relatively small to fit the devices. Due to the small display size, special emphasis must be put on user interface design for mobile applications. In addition, there are no standard display resolutions for mobile devices. There exist high-level languages allowing the target device to render the user interface using its native style, thus trading look-and-feel design for portability. However, in practice distinct versions of the user interface must often be created for different display types. Input Device Size constraints of portable devices make many traditional input devices such as keyboards and mice impossible to use with mobile devices. Instead, mobile devices come equipped with limited keyboards, navigator buttons, touch screens or pointing devices. When it comes to instant messaging, the greatest problem arising from these alternative input devices is the difficulty of typing. Typing using any of the aforementioned methods is notably slower than typing using a regular keyboard. In recent years some progress has been made in this area; for example the T9 text input system has been introduced. Memory Memory is another aspect differing in size from wireline environments to mobile environments. Both physical memory and permanent storage memory are limited on mobile devices. These memory limitations cannot be ignored when designing a mobile service. Due to memory constraints some handsets might e.g. be unable to receive large bulks of data, forcing designers to utilize alternative methods such as sending data in smaller chunks. Luckily, rapid progress has been made in this area. In the last few years the magnitude of memory sizes has shifted from KB to MB. Several solutions for storing data permanently fitting into a very small space, such as CompactFlash, MultiMediaCard, Secure Digital Card and SmartMedia Card, have been put into market and are used in numerous new mobile devices. CHAPTER 3. MOBILE INSTANT MESSAGING 24 Processing Power In addition to memory limitations, mobile devices are limited also when it comes to processing power. When designing a mobile instant messaging service the restrictions of mobile device processors need to be considered especially when deciding what data formats to use. Data formats are of importance because of the processing power that is required to en/decode them for network transmission. Codecs for some formats are very efficient while others require heavy computing. In addition, some formats require more processing power to encode than to decode and vice versa. In general, codecs demanding more processing power often result in a better data compression rate and since data size is another important aspect of mobile computing, this trade-off between processing power and data size must also be taken into account when choosing data formats. Battery Practically all mobile devices are powered by batteries. As most batteries are rechargeable, saving batteries is often quite nonessential. Furthermore, software engineers implementing a mobile service have more influence on battery usage than the designers of the service. A designer of a mobile service can slightly affect the usage of power by optimizing the use of the processor and data communications. Data communication hardware consumes power especially when sending or receiving data, optimizing the amount of sent data can help reducing power consumption. For techniques reducing the need for processing power, see the previous subsection. Media Formats The operating systems of mobile handsets come equipped with a limited range of natively supported media formats. When specifying a mobile service, support for a particular media type cannot be assumed. Preferably a mobile instant messaging service should provide the means for parties of a communication to find out the mutually supported formats or at least notify the sender of a message when the recipient does not support a particular media format. 3.3.2 Network Limitations The characteristics of wireless network links differ considerably from those of links in conventional wireline networks. These differences affect the behavior of network data traffic in various ways that need to be considered when designing a mobile service. As the transport protocols currently in use were originally designed for wireline networks some of them do not adapt well to wireless environments. The aspects most relevant to protocol performance are presented below. When deciding which transport protocols to use for a CHAPTER 3. MOBILE INSTANT MESSAGING 25 mobile service, each protocol needs to be evaluated against these characteristics in order to find the most suitable for the particular case. Bandwidth Although new generation wireless networks will provide users with bandwidth that is closer to the one provided to subscribers of fixed networks, bandwidth is still a factor that cannot be ignored when planning mobile services. E.g. the data rate of 2.5G systems, which is presently the most widespread wireless technology, is 10-20 kbps uplink and 10-40 kbps downlink while the corresponding rates of the up-and-coming 3G systems are 64 kbps resp. 384 kbps [30]. In addition to the reduced bandwidth, bandwidth variations are also more frequent in wireless networks. Handovers and the fact that voice usually has precedence over data in wireless networks are two causes for bandwidth fluctuation. Even though most instant messages contain only text and are small in size, bandwidth limitations cannot be completely neglected as many instant message services allow any kind of content to be sent. Another reason for optimizing the bandwidth usage is operator charging schemes (see Section 3.3.4). Delay The delays in wireless networks can be several magnitudes greater than in conventional wireline ones; delays exceeding one second are not unusual in wireless environments, whereas delays in fixed networks often are measured in milliseconds. Most of the latency in wireless networks is caused by transmission delays in the radio access network and by the extensive processing done at the physical layer [30]. Another characteristic of wireless networks is high delay jitter, i.e. variations to the round trip time. Typical causes for increased delay jitter are [28]: Temporal loss of coverage, e.g. in tunnels or elevators Handovers Blocking by higher-priority traffic such as voice calls Delays and delay jitter especially affect the performance of protocols providing reliable delivery, such as TCP (Transmission Control Protocol). Several mechanisms for improving TCP performance in wireless environments have been developed. The Timestamps Option [33] aims to make TCP adapt better to delays and delay jitter. As instant messaging is a real-time service, minimizing the time it takes for a message the reach the recipient is essential. For example, initiating a connection with a connectionoriented protocol is very time-consuming when long delays are experienced. Therefore, keeping the connection active between messages improves performance considerably. CHAPTER 3. MOBILE INSTANT MESSAGING 26 Packet Losses Another characteristic specific to wireless networks is a high packet loss rate. As opposed to the wireline networks where packet losses usually are caused by congestion, packet losses in wireless networks are mainly caused by bit errors, i.e. packets are corrupted while traversing the network. Common reasons for these bit errors are [49]: Weak signal power Co-channel interference (several sources with equal signal power) External noise sources between transmitter and receiver Due to the high probability of packet corruption, many wireless technologies apply linklayer error correction techniques in order to reduce end-to-end packet losses. In particular the TCP protocol, which is built around the assumption that packet losses are caused by congestion, suffers a decrease in performance in wireless environments. A number of papers studying and proposing improvements to TCP, including [21], [30], [33] and [36], are available. Unreliable transport protocols, such as UDP (User Datagram Protocol), obviously suffer from more packets being lost but deliver packets without a decrease in performance. Designers of mobile services must consider this trade-off between performance and reliability. Proxies NAT (Network Address Translation) gateways and firewalls are common in fixed networks, but in wireless networks the majority of the clients are connected to the Internet through a proxy. Especially peer-to-peer applications like instant messaging do not interact well with NAT gateways [47]. Problems arising from the use of NAT gateways in mobile networks include: Incoming connections to clients are not possible, the client must initiate the connec- tion The IP address to which the recipient should reply changes when packets traverse the gateway, therefore applications that store addresses in the data portion of messages are unlikely to work with proxies Applications cannot send reply data to dedicated ports, the ports dynamically allo- cated by the proxy must be used Proxies might drop idle connections that are still active in order to free up resources In order to be usable in mobile networks an instant messaging service must provide mechanisms for allowing messaging through various types of proxies. CHAPTER 3. MOBILE INSTANT MESSAGING 3.3.3 27 Mobility The fact that users can be on the move while using a mobile service also introduces a few aspects different from fixed environments. These differences are presented below. Roaming Roaming is the ability to move freely while maintaining an active connection to a wireless network. There are two types of roaming: contractual roaming and handover roaming. Contractual roaming is the ability to use services outside of the network of the home service provider and still only pay the home service provider. When it comes to designing mobile services contractual roaming is not a factor. Handover roaming is a factor that mobile services should consider. Handover roaming itself comes in two flavors, horizontal handovers and vertical handovers. Horizontal handovers are the ability to move from one access point to another within the same technology. As stated in Section 3.3.2 horizontal handovers have an impact for instance on network delay and on delay jitter. Vertical roaming enables moving between to different types of technologies, e.g. from UMTS (Universal Mobile Telecommunications Network) to GPRS or from UMTS to WLAN (Wireless Local Area Network). Vertical roaming might alter the behavior of a network connection completely as the characteristics of the underlying technology are changed. Coverage Another aspect of wireless networks that is not available in wireline networks is network coverage. Naturally, coverage is lost when the mobile device is moved outside of the area covered by the network, but temporary coverage loss is also possible when moving in the network. Temporal coverage loss usually occurs in closed locations like e.g. tunnels or elevators. In addition to decreases in performance discussed in Section 3.3.2 coverage loss often cause disconnections. A mobile service should be able to cope with users being disconnected unexpectedly, minimizing the damage inflicted by sudden disconnections. Services preserving user state and letting users continue a previous session upon login is one example of reducing the impact of unexpected disconnections. CHAPTER 3. MOBILE INSTANT MESSAGING 3.3.4 28 Other Switching Equipment Due to the quite extensive range of limitations of mobile devices and mobile networks listed in the previous sections, users will prefer to use conventional devices and fixed networks whenever possible. Most users will most likely use a service from their mobile device while on the move, but then switch to the computer when at home or in the office. A mobile instant messaging service should be able to manage the frequently changing device capabilities of users constantly changing equipment and perhaps even support simultaneous sessions from a single user with multiple devices. Charging Finally, the success of a mobile service often depends on its cost; if the service is too expensive it will not be able to compete against other similar services, e.g. mobile instant messaging cannot compete against short messaging services if it costs much more even though it comes with more advanced features. As many operators are likely to charge by the amount of data transferred, optimizing the amount of data sent by the service not only increases the performance of the service, but also makes it cheaper to use. 3.4 Standards and Protocols This section provides an overview of the standards related to mobile instant messaging. Although the xMS services cannot be classified as instant messaging, their usage is very similar to instant messaging as described in Section 3.4.1. Section 3.4.2 introduces IMPS, currently the only instant messaging system designed specifically for mobile environments. 3.4.1 xMS (SMS, EMS, MMS) Technically none of the xMS messaging services can be seen as instant messaging due to the lack of presence information. Nevertheless, the usage of these services resembles the use of instant messaging services very much. Since users carry their mobile devices with them, their presence rate is much higher than at a fixed computer. As the probability for receiving a quick reply to a message is considerably higher, the content of xMS messages is often similar to the content in instant messages, i.e. xMS is often used for short questions to which an immediate answer is expected. The following subsections give a brief overview of the xMS messaging services. CHAPTER 3. MOBILE INSTANT MESSAGING 29 Short Message Service (SMS) SMS (Short Message Service) was originally designed and used for service messages, making it possible for operators to send service notifications to subscribers. This explains the low capacity (140 data octets) and limited functionality (text only) of SMS. The first SMS message was sent already in 1992, but it took until the end of the 1990’s until the mass use of the SMS service begun. At first all messages were mobile terminated, operators using SMS messages to notify users of waiting voicemail. The launch of support for mobile originated SMS messages, allowed end users to take an active role and send SMS messages to each other. This new functionality allowed the creation of interactive services using the SMS technology. Subscribers adopted this new form of mobile interaction quickly and as shown in Figure 3.1, the popularity of the SMS service has been growing swiftly ever since. Locationwise SMS is far more popular in Europe and Asia than in North America, where competing transmission technologies [43] and the Receiving Party Pays (RPP) system [66], [71] have been slowing down the rollout of SMS. Enhanced Messaging Service (EMS) EMS (Enhanced Messaging Service) was the first standardized messaging solution to offer richer messaging content than SMS. The EMS standard was born in the beginning of year 2000 when 3GPP, the same standardization body that defined SMS, started working on it. Of the terminal manufacturers, Alcatel, Ericsson, Siemens and Motorola have been fostering the standard and included EMS support in their terminals. The first EMS compliant mobile devices became available to customers in mid 2001. EMS is completely based on SMS technology allowing up to 255 SMS messages to be chained together as one EMS message increasing the amount of data that can be transported in one message from 140 bytes to about 38KB. EMS supports various contents including formatted text, animation, polyphonic sounds and color pictures. EMS also allows combinations of different media types in one message as long as the maximum message size is not exceeded. A major advantage of EMS being based on existing SMS technology is that operators do not need to invest in new infrastructure in order to offer EMS messaging. EMS messaging is completely transparent to SMS service centers. Practically the only requirement for EMS messaging is that both the sender and the recipient of an EMS message carry mobile devices that are EMS compliant. EMS is often seen as an intermediary step between SMS and MMS. For example, Baskerville predicts a market share of only 3% for EMS in 2006 while MMS is projected a share of over 30 %. The supporting forces behind EMS recognize the fact the MMS is a more ideal CHAPTER 3. MOBILE INSTANT MESSAGING 30 messaging service for 3G networks than EMS, however they see EMS as a cost-effective technology that eases the transition to MMS. Figure 3.2: Global message revenue market share projection for 2006. Source: Baskerville Multimedia Messaging Service (MMS) Following EMS, MMS (Multimedia Messaging Service) is the next evolutionary step of mobile messaging. MMS supports messages with theoretically unlimited size and a by far richer range of multimedia content than EMS. MMS supports many standard multimedia formats like JPEG, GIF, MPEG and MIDI, which can be combined in one message using a presentation language (e.g. SMIL). The MMS specifications are defined by both 3GPP and OMA (Open Mobile Alliance) in an effort to achieve worldwide interoperability. As opposed to EMS, which is based on SMS technology, MMS is a completely new technology. MMS makes use of existing protocols (e.g. WAP, SMTP, HTTP (Hypertext Transfer Protocol)) and message formats (SMIL, MIME) as far as possible, but requires operators to invest in new network elements. Table 3.1 summarizes the main differences between SMS, EMS and MMS. Although many network operators already offer MMS services to subscribers and most new mobile devices contain support for MMS, the volume of sent messages has so far been relatively small. Subscribers are still reluctant to use the service as they cannot be sure that the counterpart has an MMS compliant handset. Assuming the cost of sending MMS messages is kept reasonable, it is probable that MMS will acquire a significant amount of the messaging market (see Figure 3.2) as soon as the penetration level of MMS compliant handsets is high enough for mass use. CHAPTER 3. MOBILE INSTANT MESSAGING 31 Table 3.1: Comparison of mobile messaging services [11] Feature SMS EMS MMS Media supported Text only Formatted text, simple media formats, e.g. pictures, animations, sounds Multiple rich media formats, e.g. video, audio, text Delivery mechanism Signaling channel Signaling channel Data channel Store-and-Forward Yes Yes Yes Confirmation of message delivery Yes Yes Yes Protocols SMS specific, SMPP SMS specific WAP and general Internet e.g. MIME, HTTP, SMTP Platform SMS Center SMS Center MMS Server, MMS Relay, MMS Message Store, MMS User Agent, MMS User Databases 3.4.2 e.g. IMPS IMPS (Instant Messaging and Presence Service) is a set of specifications striving to ensure interoperability in mobile instant messaging. The initiative was started in 2001 by three leading telecommunication companies, namely Ericsson, Motorola and Nokia. The initiative was originally known as the Wireless Village but has since then been consolidated into the Open Mobile Alliance (OMA), which is an industry forum for developing market driven, interoperable mobile service enablers. In order to minimize interoperability issues, the initiative is open to participation from industry supporters interested in providing input regarding ongoing specification work. The aim of IMPS is not only to provide exchange of messages and presence information in mobile networks, but also to facilitate the creation of gateways to other instant messaging services. For a detailed evaluation of IMPS as a whole compared to SIMPLE, see Chapter 4. The first approved version of the IMPS specification was released in February 2002 and it was followed up by version 1.1 in November 2002. Version 1.2 has been available as a candidate enabler since February 2003 and will be approved by the end of 2004. Currently the initiative is working on version 1.3 and a candidate enabler is planned towards the end of 2004. Although the specification work has been quite rapid, IMPS has been quite slow to market. It was not until the final quarter of 2003 that the first IMPS compliant mobile devices were released and only a few operators are currently offering instant messaging based on IMPS to subscribers. Like MMS, the IMPS service is expected to take off as soon as the penetration of IMPS capable handsets is high enough. Chapter 4 Comparison of IMPS and SIMPLE This chapter contains a comparison of two open instant messaging standards applicable in mobile environments, namely IMPS and SIMPLE. IMPS is specifically defined for use in mobile environments and SIMPLE will soon be incorporated into 3G networks as part of the SIP-based IMS (IP Multimedia Subsystem). Therefore, these two services are without doubt the top contenders in the mobile instant messaging race. As IMPS services have not yet been deployed by operators and IMS is not yet available in commercial wireless networks, measuring the performance of the services using tests was not possible. Hence, the comparison between the two services had to be performed on a theoretical basis. Specifications, articles and technical reports related to the area were utilized. In addition, test results from sub-areas, e.g. studies evaluating the performance of transport protocols in wireless networks, were considered in the comparison. The aim of the comparison was to investigate which of the two standards suits the demands of mobile instant messaging the best. Therefore, the features differing between mobile and fixed environments listed in Section 3.3 were emphasized in the comparison. However, some features crucial to both environments, such as security, were also studied. The comparison was performed between version 1.2 of IMPS and the current (August 2004) specifications of SIMPLE. IMPS version 1.2 is currently a stable candidate enabler to which no further changes are expected. The final release is planned towards the end of 2004. Most SIMPLE specifications are still ongoing work available as Internet Drafts. Nevertheless, the specifications containing the main functionality are in a stable state. Thus, although neither service is complete it is possible to carry out a fairly thorough comparison between them. This chapter is organized as follows: Section 4.1 compares the functionality provided by the services. Section 4.2 presents and evaluates the architectures and protocols of the services. The performance and security is investigated in Sections 4.3 and 4.4. The next two sections, Section 4.5 and Section 4.6, study the interoperability and extensibility of the services. Finally, Section 4.7 presents the current status and anticipates the future 32 CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 33 trends of the two services. 4.1 Functionality This section provides an overview of IMPS and SIMPLE functionality. The functionality is considered from the user’s point of view. Succeeding sections study the technology behind the functionality in detail. Table 4.1 displays the support for main instant messaging functionality in IMPS and SIMPLE. As can be seen there are few differences between the two services. All major features are available in both services. Table 4.1: IMPS and SIMPLE functionality Function IMPS SIMPLE Login and logout Yes Yes Service and capability negotiation Yes No, services and capabilities are not negotiated with a server. It is up to client to reject unsupported requests and content types. User search Yes No Invitations Yes Yes Contact lists Yes Yes Presence subscriptions Yes Yes Presence notifications Yes Yes Update presence Yes Yes Presence authorization Yes Yes Watcher list Yes Yes Watcher notifications No Yes Sending and receiving instant messages Yes Yes Delivery reports Yes Yes Message blocking Yes No, must be implemented in the client Message composition indication No Yes Group Messaging Yes Yes, but specified by the SIPPING WG General functions Presence Instant Messaging In IMPS all traffic is directed via an IMPS server before reaching its destination (see Section 2.6.2). The IMPS service enables clients to inform the IMPS server about supported services, client capabilities etc. This makes it possible for IMPS servers to reject traffic not supported by the client. Since SIMPLE sends instant messages peer-to-peer, CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 34 a similar mechanism cannot be implemented. This explains the differences in service negotiation, capability negotiation and message blocking functionality of the two services. SIMPLE provides the means for clients to reject single messages but mechanisms for deciding which messages to reject, are not part of the specifications. SIMPLE clients can however implement e.g. message blocking in non-standard ways. IMPS offers functionality for finding out the IMPS address of a user through a search. For example, if the real name of the user is known, the IMPS address can be discovered using the search functionality. SIMPLE does not provide this kind of functionality; the address of the user must be resolved using other means before a line of communication can be initiated. The presence service features provided by the services are similar, except for the lack of watcher notifications in IMPS. Using watcher notifications a user can find out whenever another user subscribes to or unsubscribe from the presence information of the user. IMPS offers the functionality for retrieving a list of current watchers, but real-time notifications about changes made to the list are only sent in SIMPLE. Message compositions indications can be used to notify a user as soon as the other party starts composing a reply to a message. This feature is available in several proprietary instant messaging systems. SIMPLE offers support for message composition indications, while IMPS does not. Group messaging is a feature analogous to chatting, allowing users to join groups and participate in discussions within the group. IMPS includes support for group messaging. The SIMPLE working group does not directly offer group messaging. Instead, the SIPPING (Session Initiation Protocol Project Investigation) working group defines a more general service called conferencing, providing group functionality for any type of media session. Therefore group messaging can be accomplished by combining conferencing with SIMPLE messaging sessions. As conferencing is included in the IMS, group messaging will be available in networks supporting the IMS architecture. 4.2 Technology This section describes and compares the architectures and protocols utilized by the two compared services, IMPS and SIMPLE. 4.2.1 Architecture IMPS The architecture of the IMPS service is depicted in Figure 4.1. IMPS is based on a clientserver architecture, all traffic sent from a client passes through the server (see Section CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 35 2.6.2); peer-to-peer messaging is not supported. Figure 4.1: IMPS architecture [6] IMPS Server The IMPS server holds five important elements; the Service Access Point (SAP) and four service elements. The SAP serves as the interface through which the outside environment can communicate with the IMPS server. The interface provides IMPS clients, the mobile core network, proprietary gateways and other IMPS servers with access to the functionality of the SAP and the service elements. The functionality of the SAP includes: Authentication and authorization Service discovery and service agreement User profile management Service relay The functionality specific to instant messaging can be divided into four logical groups. Each service element comprises the functionality of one such group. Table 4.2 lists the service elements and their main functionality. All IMPS servers are required to provide SAP functionality but service elements can be scattered among several servers; a server is not required to implement all of them. This CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 36 Table 4.2: IMPS service elements Service element Main functionality Presence Presence management Presence subscriptions Presence authorization Contact list management Instant Messaging Instant message delivery Access control Group Group usage Group management Group access control Content Content sharing facilitates the creation of distributed IMPS services, where servers relay requests to the server containing a particular service element using the Server-Server Protocol (SSP). IMPS Clients The IMPS system defines two types of clients, Embedded Clients and CLI (Command Line Interface) Clients. The Embedded Client can be embedded into several different environments, e.g. mobile terminals, fixed PC-clients and automated applications. The Client-Server Protocol (CSP) allows these clients to be fully interoperable despite their differences. CLI Clients use the text message based Command Line Protocol (CLP) to communicate with IMPS servers. CLP consists of commands typed by the user and sent as SMS messages to the IMPS server, which sends an SMS message in reply for the user to read and interpret. Consequently, CLI Clients need no software except for the ability to send and receive SMS messages. CLI Clients provide only a subset of the functionality provided by Embedded Clients. SIMPLE Figure 4.2 shows the architecture of SIMPLE. As mentioned previously, the SIMPLE specifications are not yet finalized and therefore changes to the architecture, such as addition or removal of reference points, are possible. The reference points and their associated communication protocols are summarized in Table 4.3 and further elaborated on in the following subsections. As can be seen from the table, protocols providing direct interaction between the server elements are still to be defined. Some of these undefined reference points are not necessarily needed as server elements can communicate with each other utilizing reference points used by clients. In this case a server element acts as a client in order to use the services provided by another server. For example, a GLMS (Group and List Management Server) can subscribe to presence information provided by a presence server. Furthermore, several server elements can be co-located into one physical element, in which case an element has direct access to CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 37 Figure 4.2: SIMPLE architecture the information of the other co-located elements. Table 4.3: SIMPLE reference points Reference Point Functions Protocol IM-1, IM-2, IM-3 Session signaling between IM elements using the SIP/IP Core SIP IM-4 Peer-to-peer messaging MSRP IM-5, IM-6 Messaging through IM Servers MSRP IM-7 Communication between a Presence Server and an IM Server Undefined PRS-1, PRS-2 Communication between a Presence Client and a Presence Server SIP PRS-3 Presence information and authorization management XCAP GM-1, GM-2 Communication between a Group Management Client and GLMS SIP GM-3 Management of groups and lists at the GLMS XCAP GM-4 Communication between a GLMS and a Presence Server Undefined GM-5 Communication between a GLMS and an IM Server Undefined It should be noted that Figure 4.2 is somewhat simplified as the server elements themselves can consist of several smaller elements that are not required to exist at the same location either (for an example, see Figure 4.3). However no means for communication between the sub-elements of the server elements have been defined. In practice, it follows that the sub-elements usually will be co-located in the same physical entity, similar to the servers of Figure 4.2. IM Server SIMPLE provides two modes for sending instant messages: pager mode and session mode. CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 38 In pager mode instant messages are sent over SIP using the MESSAGE method extension [14]. When using session mode messaging, a session is established using SIP, after which the Message Session Relay Protocol (MSRP) [13] is used for exchanging instant messages within the session. Both modes are able to function without any actual server functionality. In this case the IM Server element of Figure 4.2 simply consists of a regular SIP proxy. When using pager mode, IM Server elements only route the message to the recipient over IM-1, IM-2 and IM-3. For session mode messaging, the session is initiated using IM-1, IM-2 and IM-3, while the actual message session is established over IM-4 using MSRP. MSRP sessions can also be directed through MSRP relay elements [34] using reference points IM-5 and IM-6. Currently this is the only case where the IM Server could include extra functionality. For example, a store-and-forward mechanism enabling offline messaging could be implemented. Presence Server By definition a SIMPLE presence server is a physical entity either acting as a presence agent or forwarding incoming subscriptions to entities that may act as presence agents [58]. A presence agent is a SIP user agent which manages presence subscriptions and sends notifications to watchers whenever the presence information of the subscribed presentity is updated. In order to manage presence subscriptions and notifications the presence agent needs access to both presence information and presence authorization rules, both defined as separate entities. As the methods to be used for communicating between these entities are undefined, most implementations will co-locate all in one physical element, generally called the Presence Server, as shown in Figure 4.3. Figure 4.3: SIMPLE Presence Server Figure 4.3 also illustrates another aspect typical to SIMPLE; on several occasions multiple CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 39 methods for performing the same function exist. For example, presence information can be updated either using the SIP PUBLISH method over PRS-1 and PRS-2 or using the XML Configuration Access Protocol (XCAP) [59] over PRS-3. GLMS The Group and List Management Server (GLMS) is responsible for the management of contact lists, group lists and group access lists. The GLMS allows users to create groups and to define the users which are allowed access to the created groups. The XCAP protocol (over GM-3) is generally used to manage the content on the GLMS. The GLMS might act as a server for ongoing group messaging sessions as well, but group messaging sessions can also be hosted by other entities, such as dedicated application servers or the hosts that created the groups. 4.2.2 Protocols This section presents protocols specific to the IMPS and SIMPLE services. Well-known protocols such as TCP, UDP or HTTP are not presented although used by the services. Only protocols enabling the actual functionality of the services are presented. IMPS The IMPS architecture and the protocols used for transporting data between the elements of the architecture are presented in Figure 4.2. This section presents CSP and SSP, the protocols most essential to the IMPS service. Of the other protocols, CLP is quite inconvenient to operate and contains only a subset of the functionality of CSP. The Server Mobile Core Network Protocol (SMCNP) for enabling features such as charging has not been defined by OMA at all. Client-Server Protocol (CSP) The Client-Server Protocol (CSP) provides IMPS clients with access to the IMPS server and its functionality. The functions provided by the server are used through CSP transactions. A CSP transaction consists of the messages needed to carry out a function, ordinarily one request and its response. Most CSP transactions are only available within a CSP session. A CSP session is established when the user logs in to the system and terminated upon user logout or if the server decides to disconnect the user. CSP sessions are transport independent, i.e. they remain valid even when the transport connection is broken, a phenomenon typical to mobile networks as described in Section 3.3.3. In order to achieve the flexibility needed for CSP to be used in clients varying from mobile terminals to fixed PC-clients, several different transport bindings have been defined. Logically a CSP transport binding is divided into two channels: a mandatory data channel in which all CSP messages are exchanged and a conditional CIR (Connection Initiation CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 40 Request) channel used to activate the data channel whenever it is not active (Figure 4.4). This communication model enables a server to communicate with clients behind proxies, which is a usual situation in mobile networks (see Section 3.3.2) Figure 4.4: IMPS communication model The protocol bindings defined for the data channel are WSP (Wireless Session Protocol), HTTP, HTTPS and SMS, while the bindings for the CIR channel are WAP push over SMS, WAP push over UDP, SMS, UDP, TCP and HTTP. CSP data is carried over the network using the XML message format according to the DTDs (Document Type Definition) specified in [2] and [4]. See Appendix A for examples of CSP messages. In order to optimize messages for size, CSP also supports the WBXML (Wireless Binary XML) format [1]. Server-Server Protocol (SSP) The Server-Server Protocol (SSP) [3] connects IMPS servers with each other. SSP enables IMPS clients to use IMPS functionality distributed across the network, possibly provided by different service providers. In addition, SSP enables other instant messaging networks to communicate with the IMPS network through proprietary gateways. SSP is transferred using either HTTP or HTTPS over the TCP transport protocol. As HTTP is an asymmetrical protocol two physical TCP connections are required in order to provide two-way communication. SSP uses persistent TCP connections for improved performance. Equally to the CSP protocol, SSP is also conveyed between network elements in the XML format. WBXML is not supported by SSP since servers ordinarily communicate with each other via wireline connections with high bandwidth. SIMPLE Session Initiation Protocol (SIP) The Session Initiating Protocol (SIP) is a signaling protocol used for creating, modifying and terminating sessions with one or more participants [60]. SIP allows for any kind of session to be initiated, including IP telephony calls, multimedia conferences and instant messaging sessions. Sessions created using SIP are peer-to-peer, i.e. the SIP framework is only used for managing sessions, not for session traffic. This typically results in a SIP trapezoid shown in Figure 4.5. User agents are SIP entities able send SIP requests acting as clients (UAC) and respond CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 41 Figure 4.5: The SIP trapezoid to incoming requests as servers (UAS). All servers and clients of the SIMPLE architecture (Figure 4.2) act as user agents. SIP proxies accept SIP requests from user agents or other SIP proxies and route them closer to the recipient. In addition to proxies and user agents, registrars are also important elements in SIP networks. Registrars accept registrations of address information from other SIP entities. The registrars store the information in location services which are then used by SIP proxies when routing messages. Finally, redirect servers can be utilized to redirect incoming requests to other destinations, e.g. a user could set the SIP phone at work to redirect all calls to the SIP phone at home. SIP is very similar to the HTTP protocol [22], utilizing the same request/response transaction model where each transaction consists of a request invoking a particular method and the responses to the request. The majority of the message and header field syntax is also derived directly from HTTP. SIP allows extensions to the protocol to be made in the form of new methods and header fields. Three extensions of the SIP protocol have a central role in SIMPLE, namely the event notification extension [56], the pager mode instant messaging extension [14] and the UPDATE method extension [57]. The event notification extension enables SIP nodes to be notified when a particular event occurs. The instant messaging extension adds support for sending instant messages in SIP messages without creating a session. Finally, the UPDATE method extension provides the means for updating presence information. In addition, group messaging software may use the REFER method extension [62]. Table 4.4 lists the main SIP methods and their use in SIMPLE. Message Session Relay Protocol (MSRP) The Message Session Relay Protocol (MSRP) [13] is an instant message transport protocol defined by the SIMPLE working group. As opposed to pager mode instant message exchange which uses the SIP MESSAGE method, MSRP is a session-based protocol. MSRP sessions can be setup using any signaling protocol capable of initiating sessions. In SIMPLE the SIP protocol is naturally used. CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 42 Table 4.4: SIMPLE usage of SIP methods SIP method SIMPLE function REGISTER Login/logout, enables the user to be reached by other users INVITE Initiating instant messaging and group messaging sessions REFER Alternative method for inviting users into ongoing group messaging sessions BYE Terminating sessions SUBSCRIBE Subscribing to the presence information of other users, watcher information, group change information etc. NOTIFY Notifies subscribers of particular events, e.g. changes to presence information UPDATE Updating presence information MESSAGE Sending of pager mode instant messages Like SIP, MSRP is also a text based protocol similar to the HTTP protocol. MSRP is a fairly simple protocol, only two request methods are needed: the SEND method and the REPORT method. The SEND method is obviously used for sending instant messages. MSRP does not limit instant messages to contain only text; any content type can be used. The REPORT method can be used for receiving delivery reports for sent instant messages. As MSRP is based on HTTP, it allows for extending the protocol by adding new methods and header fields. The ’Relay Extensions for MSRP’ specification [34] does exactly that, adding support for using relay intermediaries to MSRP, which originally is a peer-to-peer protocol. XML Configuration Access Protocol (XCAP) The XML Configuration Access Protocol (XCAP) [59] allows clients to retrieve, modify and delete XML data stored on a server. Although defined by the SIMPLE working group, XCAP is a general-purpose protocol which area of usage is not restricted to SIMPLE. However, XCAP is particularly suitable for the needs of SIMPLE as all data permanently stored in SIMPLE server elements, such as presence information, watcher information and presence authority rules, is defined in the XML format. XCAP provides the means for mapping XML documents and document elements directly to HTTP URIs (Uniform Resource Identifier). This enables XCAP to manipulate XML documents stored on a server using normal HTTP primitives. The HTTP GET method is used for retrieving XML documents or parts of them, the PUT method is used for creating or modifying documents and the DELETE method can be utilized for deletion of XML documents. The XCAP specification in [59] defines a framework for manipulation of XML data. In addition, each application storing data on XCAP servers comes with application-specific conventions, e.g. XML schemas and bootstrap URIs, which need to be defined. Therefore each application using XCAP is required to specify application-specific requirements in an CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 43 ’XCAP Application Usage’ document. For example, an application usage for manipulating presence information using XCAP is defined in [32]. 4.2.3 Summary As a whole, the architecture of IMPS is more mature than the SIMPLE architecture. The IMPS architecture is relatively simple; complete instant messaging functionality can be delivered using only two protocols, CSP and SSP, defining the client-client and the server-server interfaces clearly and unambiguously. The SIMPLE architecture is without doubt more complex; numerous reference points are defined for accessing the service. The functionality has been divided into several small elements of which each has been defined independently from the others in order to provide a flexible system. However, although the client-server interfaces of the elements are quite clearly defined, communication between server elements is mostly undefined. Also, on several occasions the SIMPLE service provides several alternatives for performing the same function. While this on one hand improves flexibility, it might on the other hand increase complexity as server solutions are forced to provide all alternatives in order to be functional against all kinds of clients. Again, it should be stressed that the SIMPLE specifications are ongoing work; changes to the current solution are possible. The protocols on which the network communication of IMPS and SIMPLE relies are very similar; both services rely on HTTP-like protocols based on the request/response model. In addition, all data except for the content of instant messages is transferred in the XML format for both IMPS and SIMPLE. The characteristics of the protocol and data formats when it comes to performance, security etc. are evaluated in subsequent sections. 4.3 Performance This section evaluates the performance of IMPS and SIMPLE compared to each other. Several aspects such as bandwidth usage, delays, processing, coverage loss, proxy traversal and scalability were studied. As mentioned earlier, the performance comparison is based purely on theoretical facts, no real tests could be performed due to the lack of deployed implementations of the services. 4.3.1 Bandwidth Usage As instant messages usually only contain short strings of text, it might seem unimportant to optimize them for size. However, in addition to the actual data, instant messages carry addressing information, session identifiers etc. increasing the size of the message substantially. Moreover, although 3G networks offer a broad bandwidth, only a fraction CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 44 of it will be allocated for SIP signaling. Also, it will take long until complete 3G coverage is reached and until then low-bandwidth technology, such as GPRS, will be widely used. Message Size Protocol messages consist of two parts: protocol data and payload data. In order to optimize the total size of a message, both parts need to be optimized. IMPS messages have a relatively small protocol part; most information is generally carried as payload data. SIMPLE messages carry more information in the protocol part of the message and only the actual instant message or presence information is carried in the payload part. For optimizing the size of the protocol part IMPS includes a WSP (Wireless Session Protocol) transport binding. In essence, WSP is a tokenized version of HTTP resulting in smaller sized messages. For compressing the payload data, IMPS provides support for the WBXML format. WBXML tokenizes the XML elements of the CSP protocol. As the XML elements of the CSP protocol have lengthy names, the WBXML format reduces the size of the payload data significantly. On average the size of a compressed CSP message is about 25% of the uncompressed message. SIMPLE SIP messages can be compressed using the SigComp solution [54] as described in [12]. SigComp compresses both the protocol and the payload part of SIP messages. A performance evaluation performed by Nordberg et al. in [46] indicates that the message size can be reduced to approximately 25-50% of the uncompressed size for SIP messages sent in 3G networks. By comparing the message sizes of instant messages for both services (see Appendix A for message examples) it can be noted that sending uncompressed IMPS instant messages consumes over three times more data than pager mode SIP instant messages. Setting up a SIMPLE session mode and sending one message requires a little more data than one IMPS message. Nevertheless, after session mode has been set up, all subsequent SIMPLE instant messages are over five times smaller than corresponding IMPS messages. Conclusively, despite IMPS providing a somewhat higher compression rate, SIMPLE messages are still considerably smaller than IMPS messages. Finally, the message size can also be affected by reducing the size of presence notifications received from the presence server. The size of notifications can be decreased using partial notifications, i.e. the server sends only the changed part of the presence information in the notification. Both IMPS and SIMPLE includes support partial notifications. Filtering Rules The bandwidth usage can also be limited using filtering rules. Clients can use filtering rules to narrow the amount of events resulting in notifications. Filtering rules can also be used to CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 45 block instant messages from certain users, thus limiting the amount of data received. IMPS supports filtering rules for both presence information and instant messaging. SIMPLE only supports filtering rules for presence information; instant messages cannot be blocked before arriving at the client due to the peer-to-peer property of SIMPLE. Signaling IMPS needs no signaling in order to send an instant message to another user. SIMPLE needs to setup a session using SIP when using session mode instant messaging, thus introducing data overhead in comparison to IMPS. Furthermore, SIMPLE presence subscriptions are not permanent, clients must refresh subscriptions periodically. The length of the period depends on the policy of the presence server. In comparison, IMPS presence subscriptions are guaranteed to last for the length of an IMPS session. However, IMPS clients might need to renew subscriptions whenever they login to the system, creating overhead comparable to SIMPLE presence refreshments. 4.3.2 Delays Delays and delay jitter are not as important factors in instant messaging as in other realtime services. E.g. when sending voice or video, keeping delays and delay jitter to a minimum is critical to the quality of the communication. Nevertheless, instant messaging is a real-time service and if delays grow too high, the user experience deteriorates. Delay jitter is not a factor in instant messaging since messages are not sent in an uninterrupted stream. There are two types of delays affecting user experience: the session setup delay and the message exchange delay. These are studied in more detail below. Session Setup The session setup delay is the amount of time needed for initiating the sending of an instant message. The delay caused from establishing a data channel to the radio access network can be neglected here as both services perform the same procedure. In IMPS, clients create a session with the IMPS server upon logging in to the system, but sessions are not initiated with recipients of instant messages. Hence there is no session setup delay associated with the IMPS service. SIMPLE pager mode messaging generates no session setup delay either. SIMPLE session mode messaging requires a session to be set up using SIP before the first instant message can be sent. A minimum of three SIP messages or 2 round-trip times (RTTs) are needed to complete the setup of a SIMPLE instant messaging session. CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 46 Message Exchange The message exchange delay is simply the amount of time elapsed between sending an instant message and its arrival at the recipient. The following aspects of the services affect the message exchange delay: System architecture Transport protocol Persistent connections Message size In IMPS all data communication with the IMPS server is client-initiated, i.e. the server can only send data to the client in a reply to a request initiated by a client. The IMPS server utilizes the CIR channel (Figure 4.4) to trigger requests from clients when needed. This inflicts an additional RTT to occur between the receiver and the IMPS server for each message. This is illustrated in Figure 4.6. Figure 4.6: IMPS message exchange IMPS recommends but does not require persistent connections to be used between clients and servers. Since IMPS is based on HTTP, using persistent connections offer significant performance gains due to the reduced number of connection initiations. SIMPLE message exchange using session mode is efficient since messages are sent peer-topeer. The protocol for session mode messaging, MSRP, uses the TCP protocol for transport and recommends reusing open connections, thus improving performance in wireless environments. The efficiency of pager mode messaging also depends on the use of persistent connections; if connections between SIMPLE clients and SIP proxies can be reused, then messages can be delivered efficiently. In addition to TCP, SIP also supports using UDP for transportation in which case the bit error rate of the network dictates the performance of pager mode messaging. However, since pager mode messages are sent in the low-bandwidth signaling channel, session mode messages will usually have a lower message exchange delay. 4.3.3 Processing As described in Section 3.3.1, the processing and memory constraints of mobile devices should be taken into account by mobile services. Both IMPS and SIMPLE offer basic CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 47 functionality for restricting the size of a single message in order to prevent clients from running out of memory. IMPS clients can specify the maximum message size it is able to process in one chunk during the login procedure. In SIMPLE the MSRP protocol allows sending large messages in smaller chunks when using session based messaging. For pager mode, instant messages are restricted to 1300 bytes by the specification. 4.3.4 Coverage Loss Both the IMPS and the SIMPLE service are able to cope with sudden disconnections caused by the loss of radio network coverage. Clients of neither service need to re-login to the system upon a disconnection, only the transport layer connections need to be reestablished. For session based messaging, SIMPLE clients need to store some information in order to be able to re-initiate the transport connection upon sudden disconnections, otherwise a new session must be negotiated. 4.3.5 Proxy Traversal Mobile networks are usually connected to the Internet via NAT proxies. Therefore, the ability to communicate through proxies is an important feature of mobile instant messaging services as it enables a global service, available from both mobile and wireline clients. IMPS makes use of the CIR channel presented in 4.2.2 in order to traverse proxies. As all client-server communication is client-initiated and the server can trigger client requests using the CIR channel, IMPS clients can use the IMPS service through proxies without problems. The cost of this arrangement is some additional delay to message exchange as described in Section 4.3.2. Implementations of SIP as specified in [60] have severe problems with NAT traversal. The problem stems from SIP proxies sending replies to ports defined in the SIP requests. RFC 3581 [61] defines a header extension to the SIP protocol solving the problem for TCP. However, the problem persists for UDP connections and all server-initiated requests. Several solutions to the problem have been proposed, including [9] and [63], but it will take long until a standard solution is available in every SIP proxy. SIMPLE services function perfectly inside mobile networks, e.g. using IMS in 3G networks, but due to the NAT problems it is currently not possible to create fully functional SIMPLE services spanning both mobile and wireline networks. 4.3.6 Scalability By scalability, the system performance when used by a substantial amount of simultaneous users is meant. Scalability is important as these services are expected to acquire millions CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 48 of users over time. The architectures of the two compared services provide excellent scalability. Neither service requires any centralized network elements, enabling data to be distributed among several servers. By building a network of distributed servers, both services can serve a vast amount of simultaneous clients. 4.3.7 Summary Generally, SIMPLE performs better than IMPS when it comes to optimizing bandwidth usage and delays. IMPS causes no session setup delays, but session mode messaging enables shorter message exchange delays and smaller messages for SIMPLE. On the other hand, the mechanisms causing delays in message exchange for IMPS also enable IMPS messages to traverse NAT proxies without problems. In contrast to IMPS, SIMPLE currently has severe problems with NAT traversal. The architectures of both services enable good scalability supporting customer bases of large scale. The ability to recover from disconnections due to coverage loss is also good for both IMPS and SIMPLE. 4.4 Security This section describes the security services provided by the compared instant messaging systems and evaluates how well the systems are protected against the security threats listed in Section 2.8. 4.4.1 Security Services Authentication IMPS requires user authentication before access to server functionality can be provided. For user authentication, either a two-way or a four-way access control mechanism can be used. Using the two-way mechanism, the user sends both the user identifier and the password in plain text to the server, which either grants or denies access. The four-way mechanism is a digest authentication based on a challenge sent by the server. The four-way mechanism supports the following digest schemes: SHA (Secure Hash Algorithm), MD4 (Message Digest Algorithm #4), MD5 and MD6. Server authentication is provided only when the HTTPS transport binding is used. No mechanisms have been defined explicitly for end-to-end authentication of instant messages. However, as any MIME type is allowed for content of instant messages, end-to-end authentication can be accomplished using e.g. S/MIME (Secure MIME) signatures. SIMPLE does not enforce clients or servers to be authenticated. However, SIP proxies are CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 49 required to support authentication mechanisms and to use them whenever requested. SIP proxies can authenticate clients using a scheme based on the HTTP authentication scheme [26] while clients can utilize TLS (Transport Layer Security) for server authentication. For end-to-end authentication, e.g. in session mode messaging, S/MIME signatures can be applied. Authorization Both IMPS and SIMPLE allow clients to specify authorization rules for their own presence information. In addition, IMPS lets clients specify access rules for instant messages as well, enabling the server to block messages from unauthorized users. In IMPS the services to be used are negotiated during the login procedure. Although the main purpose of the service negotiation is to ensure that clients do not request services not supported by the server, it can also be utilized to implement service authorization. In SIMPLE services are not negotiated, therefore service authorization can only be provided using proprietary solutions. Accountability Neither IMPS nor SIMPLE require service elements to create audit trails or logs of transactions. Nevertheless, although not enforced by specifications, most server implementations traditionally come equipped with some level of accountability features. Confidentiality For protecting the confidentiality of protocol messages IMPS clients can utilize the HTTPS transport binding, assuring that message content is only interpretable by the local IMPS server. Strangely, IMPS does not enforce end-to-end confidentiality, i.e. even though a client sends a message over HTTPS to the server, secure delivery from the server onwards is not guaranteed. In SIMPLE, TLS can be used to ensure that only trusted elements can read messages. Using the SIPS addressing scheme described in [60], a SIMPLE client can demand secure connections to be used along the whole path between the client and the recipient of a message. For providing end-to-end confidentiality for messaging sessions, encryption using S/MIME can be utilized if supported by both parties. Integrity Message integrity can be ensured in IMPS only when using the HTTPS transport binding and even then the integrity is only guaranteed between the client and the server. In CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 50 SIMPLE the SIPS addressing scheme can be used to cause TLS to be used between intermediaries, thus providing message integrity. SIMPLE also supports the use of S/MIME signatures for end-to-end integrity. 4.4.2 Attack Vulnerability This subsection evaluates how well IMPS and SIMPLE are able to withstand some of the security threats listed in Section 2.8. Man-in-the-Middle Attacks When using two-way authentication in IMPS, an adversary listening to network traffic can easily learn the password of the user as it is sent in plain text. When using fourway authentication passwords are harder to grab, but as the session identifier assigned to the created session is sent in plain text in each message, hijacking an ongoing session is simple. In essence, the HTTPS transport binding is the only mechanism providing adequate protection against man-in-the-middle attacks. Even when HTTPS is used it only guarantees secure delivery up to the server, an adversary can snatch and modify instant messages between the server and the final recipient instead. SIMPLE specifications do not force server elements to perform authentication of incoming traffic. Since neglecting authentication allows an adversary to impersonate any other user, providing authentication is in practice mandatory for SIMPLE systems. In order to prevent adversaries to read message content, the SIPS addressing format should be used. For end-to-end security the messages can be both encrypted and signed using S/MIME. When all these techniques are in use, SIMPLE provides relatively strong protection against man-in-the-middle attacks. Replay Attacks As TSL includes mechanisms for preventing replay attacks, IMPS users are decently protected against replay attacks while using the HTTPS transport. For other transports, messages can be replayed as long as the session from which the original message was captured is still active. Also, two-way authentication can be successfully replayed while four-way authentication cannot. Like IMPS messages, SIMPLE messages are sufficiently protected against replay attacks when transported over TSL connections. In order to prevent replay attacks SIMPLE requires all signed presence notifications to contain timestamps. Similarly, pager mode instant messaging obligates the usage of the SIP Date-header to defend against replay attacks. CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 51 Denial-of-Service Attacks Instant messaging systems are especially vulnerable to denial-of-service attacks due to the amplification properties of the presence service; an update of presence information can result in numerous notifications being sent out. Although it is never possible to mitigate denial-of-service attacks completely, authenticating incoming requests is one of the most effective means for reducing the probability of such an attack. As mentioned earlier, IMPS requires user authentication and SIMPLE provides mechanisms for authenticating both client and server requests. 4.4.3 Summary When using only the minimum required security services, the level of protection provided by both IMPS and SIMPLE is too weak to be used in business-oriented environments or public networks. Fortunately, both services include support for stronger security mechanisms as well. Overall, SIMPLE comes equipped with stronger security mechanisms than IMPS but the complexity of the SIMPLE architecture can make it difficult to apply strong security throughout the whole network. However, the IMS specifications define a security model to be deployed throughout 3G networks assuring strong security for SIMPLE within mobile networks. From the SIMPLE point of view, IMS security services are a combination of SIMPLE security and 3GPP security. For further information about the IMS security model and 3GPP security, see [53] and [45]. IMPS provides only two security mechanisms, authentication and the HTTPS transport binding. A server provider can provide a secure service within a closed network by enforcing the use of both these mechanisms. However, users of the service have no means to request end-to-end security for messages. Consequently, the service is vulnerable to security breaches in networks without common security policies, such as a global IMPS service in the Internet. 4.5 Interoperability The IETF IMPP working group produces standards aiming to provide interoperability between instant messaging systems. IMPP and the requirements it places on instant messaging systems for interoperability were described in Section 2.5.1. SIMPLE does conform to the IMPP specifications in full, facilitating the creation of interoperability gateways between SIMPLE and other IMPP compliant instant messaging systems. IMPS conforms to all other IMPP requirements except for the PIDF presence format [65]. CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 52 The lack of PIDF support does not prevent gateways from being created, but the gateways needs to translate the IMPS presence format to the PIDF format and vice versa. This means that presence information cannot be preserved end-to-end, which has implications especially on security since signed or encrypted presence information cannot pass through gateways. The OMA Presence & Availability Working Group is currently working on adding PIDF support to the presence architecture meaning that IMPS is likely to be fully IMPPcompliant in the future. Furthermore, the OMA Messaging Working Group is in the process of defining gateway functionality for connecting IMPS and SIMPLE networks together. 4.6 Extensibility As instant messaging is still a young service, it is subject to changes as instant messaging matures over the years. Consequently, extensibility is an important characteristic in the comparison of IMPS and SIMPLE. IMPS protocols are largely based on the XML format. New transactions and extensions to existing transactions can easily be added to the protocols using XML Namespaces [10]. In addition, all IMPS protocols are version-numbered; a new protocol version can be released when major changes to existing functionality are needed. In IMPS, protocol versions are usually not backwards compatible, but XML extensions are. SIMPLE also utilizes the XML format, enabling existing data formats to be extended easily. For example, SIMPLE defines several extensions to the XML based PIDF presence format. However, in contrast to IMPS which protocols are completely defined in XML, much of the SIMPLE functionality is provided by HTTP-like protocols such as SIP and MSRP. Both SIP and MSRP can be extended with new methods and header fields. In fact, as described in Section 4.2.2 SIMPLE is based upon SIP extensions. SIMPLE protocols, such as MSRP and XCAP, are not versioned which places limits on the amount of changes that can be made to the protocols. Finally, when it comes to layer independency IMPS does not depend on underlying protocols, making it possible to change the transport binding without affecting IMPS functionality. SIMPLE on the other hand is tightly coupled with SIP, meaning that all changes to the SIP protocol might have an impact on SIMPLE as well. 4.7 Current Status and Future Trends This section presents the current status and future trends of the compared services. CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 4.7.1 53 Industry Support The main founders of IMPS (known as Wireless Village at the time), Ericsson, Motorola and Nokia are the main forces behind the service. Each of these companies has mobile terminals with IMPS support on the market today. In addition, around 20 companies are currently offering IMPS client and server software. No free IMPS solutions have emerged up to date. As mentioned in Section 2.5.2, SIP and SIMPLE are supported by several major information technology players, such as Microsoft, IBM and Yahoo. There are numerous commercial and free SIP implementations available, a quite comprehensive list can be found in [31]. Of all SIP implementations around 15 include SIMPLE functionality as well. However, since the SIMPLE specifications are ongoing work, only a few implementations include newer features such as session mode messaging and XCAP. 4.7.2 Service Maturity Of the two compared services, IMPS is without doubt the more mature. IMPS is ready to be taken into use immediately; several terminals already include IMPS client software and IMPS server software is available on the market as well. However, there is a notable shortage of deployed IMPS services. Few network operators provide IMPS services and although mobile IMPS clients are able to function with public IMPS servers as well, currently only one public server, Yamigo [72], is known. As mentioned earlier, parts of the SIMPLE specifications are still ongoing work, e.g. major changes were made to the MSRP protocol enabling session mode instant messaging as late as July 2004. The current deadline for the SIMPLE working group is set at September 2004, but work is expected to continue during 2005 as well. 4.7.3 Future Trends Although IMPS is ready for deployment, network operators have initially been slow to introduce mobile instant messaging, evidently in the fear of losing SMS revenues. However, due to the superior functionality provided by mobile instant messaging, a few operators deploying instant messaging services will probably force the rest to follow in order to retain their customer bases. As more mobile handsets featuring support for IMPS becomes available, the IMPS service will start gaining momentum. Since the deployment of IMS, which enables SIMPLE to be used in mobile networks, is still a few years away IMPS is expected to attain an early lead in the mobile instant messaging race. The introduction of IMS into mobile networks makes SIP and consequently SIMPLE hot topics in the wireless world. As instant messaging based on SIMPLE is part of IMS, CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 54 deploying IMS automatically makes the SIMPLE service available to mobile users. As both standards are interoperable and OMA currently is defining a gateway for connecting IMPS and SIMPLE together, it is probable that both services will co-exist in the future as opposed to one of the services fading away completely. Chapter 5 Implementation of IMPS CSP Protocol As part of this thesis, one protocol of the IMPS service, namely the CSP protocol (Client Server Protocol) was implemented. The CSP protocol enables communication between an IMPS client and an IMPS server (see Figure 4.1 in Section 4.2). For an overview of the CSP protocol, see Section 4.2.2. Both the client and the server part of the protocol were implemented. For the client, the implementation consists of an application programming interface (API) on which e.g. a client equipped with a user interface can be built. The server is a fully functional implementation. The reason for choosing to implement the CSP protocol of the IMPS service is quite obvious. A CSP compatible IMPS server can provide a fully functional IMPS service to all CSP compatible clients subscribed to that particular server. Of course, the SSP (Server Server Protocol) is needed to allow communication between users of separate servers, but a functional service cannot be based on SSP only. The CLP (Command Line Protocol) protocol is based on text messages and supports only a subset of the features supported by CSP. CLP will primarily be used in mobile devices not supporting packet-switched data transfer; the majority of new mobile devices supporting IMPS will base their clients on the CSP protocol. In the time frame of this thesis only one protocol could be implemented and as the CSP protocol forms the basis of the IMPS service it was chosen. The next logical step after producing a fully functional CSP implementation would be to implement the SSP protocol, which not only provides inter-domain communication but also enables distributing services across multiple servers and connecting other instant messaging networks with IMPS through gateways. This section is organized as follows: Section 5.1 presents the requirements of the software. The design of the software is depicted in Section 5.2. The solutions used in the implementation and the problems arising during the implementation phase are described in Section 55 CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 56 5.3. 5.1 Requirements Version 1.2 of the CSP protocol was chosen for the implementation. Although not yet finalized, no further changes are expected to version 1.2 before its final release before the end of 2004. This section presents the requirements set upon the implementation in general, as well as the requirements imposed by the protocol specifications. 5.1.1 Overall Requirements To ensure that the implementation would be both easy to use for end-users and simple to maintain and expand for software developers, a list of high-level requirements was produced: Extensibility – Easy addition of unimplemented CSP functionality – Easy addition of additional transport bindings – Easy addition of new protocol versions Clear, maintainable structure Multi-platform support (Windows, Linux, Solaris, ...) High performance As not all features of the CSP protocol were to be implemented (see Section 5.1.2), the ability to add missing features to the solution later on was considered important. Since new protocol versions are under constant development, the solution should also be extensible enough to allow integration of these into the software. The structure of the software should not only provide extensibility, a clear structure easy to comprehend for developers new to the solution was also required. Another requirement was not to restrict the solution to any particular environment, but rather to make sure that the solution is applicable in a broad range of different environments with no or only minor changes. Finally, as the client library was to perform well in environments with limited resources and a scalable server solution was desired as well, the performance aspect of the system could not be overlooked. However, the clarity of the design was given a higher priority, thus no performance optimizations decreasing the comprehensiveness of the system were to be made. CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 5.1.2 57 CSP Protocol Requirements The CSP Static Conformance Requirement document [5] lists the features of the CSP protocol version 1.2, specifying which features are mandatory to implement and which are optional. As described in Section 4.2.1, the functionality of the CSP protocol can be divided into five larger groups (see Table 5.1). Of these groups only the SAP is mandatory to implement. However, creating a service consisting of only the SAP functionality would not be meaningful since this merely provides users with the ability to login and logout of the service. Therefore more functionality was needed in order to build a usable system. However, the time frame of the project also placed constraints on the amount of functionality that could be included. Table 5.1: Implemented CSP requirements Functionality Requirement Implemented Implemented sub-elements Service Access Point Mandatory Yes Mandatory Instant Messaging Service Element Optional Yes Mandatory Presence Service Element Optional Yes Mandatory + contact list management and updating presence information Group Service Element Optional No Content Service Element Optional Yes Mandatory As the two primary elements of instant messaging are presence information and message exchange, both the instant messaging service element and the presence service element were to be implemented. The shared content service does not require much effort to implement; therefore it was chosen for implementation as well. As required, all mandatory elements of the selected service elements were to be implemented. In addition, contact list management and the ability to update presence information, which are optional features of the presence service element were also chosen for implementation as these were considered to be essential parts of a presence service. 5.2 Design The CSP protocol was described in Section 4.2.2. This section presents the design of the CSP protocol implementation. The tools utilized in the design are described in Section 5.2.1. Sections 5.2.2 and 5.2.3 describe the design of the IMPS client and the IMPS server, respectively. CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 5.2.1 58 Tools Unified Modeling Language (UML) The Unified Modeling Language (UML) is a notational language for specifying, visualizing and documenting models of software. UML is especially suitable for designing objectoriented software. UML was utilized extensively during the design, the entire design of the system being documented using UML. Several of the standard diagram types specified within UML were used, in particular use-case diagrams, package diagrams, class diagrams and sequence diagrams [24]. Microsoft Visio Microsoft Visio is a tool for creating business and technical diagrams. The tool includes support for a wide variety of different diagram types, e.g. organizational charts, flow charts, database models and software program planning. For software program planning Visio supports several UML diagram types, which made it a suitable tool for creating the design diagrams of the CSP implementation. 5.2.2 CSP Client The design of the CSP client library is clarified by the UML class diagram of Figure 5.1. Figure 5.1: Architecture of the CSP client library CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 59 The ImpsClient and CspReceiver classes form the application programming interface (API) that is visible to the end-user of the library. The ImpsClient class provides methods for configuring and initializing the client. Client-initiated messages are also sent using the ImpsClient class. The CspReceiver class contains callback methods that are invoked when the client receives server-initiated CSP messages. CspReceiver contains stubs for the callback methods; for non-default behavior these methods shall be overridden by applications using the library. The subsections below provide more detailed descriptions of how CSP messages are sent and received using the CSP client library. When it comes to the internals of the library, the TransportHandler class is the main controller, directing messages to their correct destination class. By having classes implement the CIRTransport or the Transport interface, support for additional transport bindings for CIR and data channels can easily be added to the client, thus fulfilling the requirement listed in Section 5.1.1. Sending CSP Requests Messages are sent using the sendMessage method of ImpsClient: CspMessage *sendMessage(const CspMessage &request) The method takes the CSP request to be sent as an input parameter and returns the resulting CSP response message as a return value. The CspMessage class is the base class for CSP messages, containing features shared by all CSP messages. All CSP messages are subclasses of CspMessage as shown in Figure 5.2. Figure 5.2: CSP message tree CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 60 Receiving CSP Requests The library invokes the callback methods of CspReceiver upon reception of messages initiated by the IMPS server. These callback methods will be handed the incoming message as the first parameter, while the second parameter contains a response message to be filled by the method. void handleMessageNotification (const MessageNotification &req, StatusMessage &res) For example, the implementation of the handleMessageNotification -method above would examine the received message notification and produce a status message to be sent back to the IMPS server. 5.2.3 CSP Server The architecture of the server is depicted in Figure 5.3, the UML packages representing the logical components of the system. Figure 5.3: Server architecture Table 5.2 below describes the primary tasks of each logical component in brief. CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 61 Table 5.2: System component tasks Component Function Transport Handles all data sent or received via the network interface over the supported transport bindings. XML Parser Parses raw XML data filling the data into abstract data types derived from the CSPMessage class (see Figure 5.2). CSP Server Controller Links the different components of the system together. Also performs regular tasks, such as cleaning up expired sessions etc. Validator Validates aspects that are common to all messages, e.g. verifies that the session identifier of the message is valid. Transaction Handler Creates and executes Transaction objects performing the actions needed to fulfill each CSP request. APIs Provides access to the data of the server. For example, all presence subscriptions of a particular user can be fetched using the Presence API. Data Storage Contains the mechanisms needed for storing the permanent data of the system. Transactions All logic for fulfilling CSP requests is contained in Transaction objects. Transaction objects are instances of classes implementing the Transaction interface shown in Figure 5.4. The Transaction interface enables the Transaction Handler to create and execute a certain CSP transaction based on the type of CSP request. A Transaction object examines the received CSP request, carries out the procedures needed to fulfill the request and creates a CSP response message to be sent back in reply. Figure 5.4: The Transaction interface Some CSP transactions endure for several message exchanges between the client and the server. In this case Transaction objects are stored on the server while waiting for further messages from the client. Then the Transaction Handler retrieves and resumes execution of the previously created Transaction object. In order to clarify the operation of the server, the UML sequence diagram in Figure 5.5 shows the flow of control during its primary task, responding to incoming requests. CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 62 Figure 5.5: Flow of control for incoming messages Adding New Functionality According to the requirements of Section 5.1.1, addition of new transactions to the server was made as simple as possible. The process is described below: 1. Creation of abstract data types (CSPMessage) for the messages of the new transaction 2. Addition of support for the new messages to the XML parser 3. Creation of a Transaction class for performing the logic related to the transaction 4. Registering the new Transaction with the Transaction Handler In essence, creating a few classes derived from existing base classes and registering these with the server is all that is needed; no changes to the main flow of the server are needed at all. Similarly, many aspects are hidden behind common interfaces allowing for easy addition and changing of system parts. For example, new transport bindings can be added and the data storage component can be changed without affecting the rest of the system at all. 5.3 Implementation This section describes the solutions used and the problems encountered during the implementation of the CSP protocol. First, the tools and libraries utilized in the implementation are presented. Then problems arising in during the implementation phase are discussed. Finally, improvements that could be done in the future are identified. CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 5.3.1 63 Programming Language Both the server and the client library were written in the C++ programming language. An alternative object-oriented language would have been the Java programming language. As C++ code generally is more efficient and takes less space than Java code, it was considered more suitable than Java especially for mobile devices, which are one possible environment of the CSP client. Furthermore, since there would be quite an amount of shared code between the client library and the server it was sensible to implement both using the same programming language. 5.3.2 Tools Microsoft Visual Studio 6.0 The program code and binaries of the CSP protocol implementations were produced using the Microsoft Visual Studio 6.0 application development suite. However, no Windowsspecific features were utilized in order to make the code compilable for as many platforms as possible according to the requirements of Section 5.1.1. 5.3.3 Software Libraries Xerces XML Parser Version 2.5.0 of the Xerces C++ XML parser was used the produce the XML parsing module of the system. The Xerces library provides for both parsing and validation of XML structures. As Document Type Definitions (DTD) for the CSP protocol were provided in the specifications ([2], [4]), Xerces was able to validate incoming XML messages based on the DTDs, thus reducing the amount of code needed to be written. The Xerces API provides access to XML data using both SAX (Simple API for XML) and DOM (Document Object Model). Since SAX surpasses DOM when it comes to speed and memory consumption [25], it was seen as the best choice considering that the client library might be executed in environments with limited resources. Celtius HTTP API Celtius HTTP API for C++ is a powerful HTTP library for use in both client and server applications. As the library conforms to Wireless Profiled HTTP specifications it is perfectly applicable in both wireless and wireline environments. In order to implement the HTTP transport binding of the CSP protocol, the CSP client library utilizes the HTTP client that is part of the Celtius HTTP API while the CSP server relies on the HTTP server support included in the same library. CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 5.3.4 64 Problems During the creation process of the CSP protocol no severe problems that would have suspended the flow of work were encountered. As version 1.2 is the third release of the CSP protocol, most principal elements have been thoroughly reviewed and the protocol is rather stable as a whole. Still, there are some ambiguities in the specifications especially when handling special cases. For example, management of presence subscriptions in cases where users subscribe or unsubscribe to contact lists is not clearly described in the specifications. Also, reconnecting to a previous session is not defined in an unambiguous fashion. The implementation resolves these uncertainties by applying the solution that appears most reasonable. This does however not guarantee complete interoperability. Another minor problem was the lack of other implementations against which the implementation could have been tested. IMPS clients are currently available in a few mobile devices, but these clients are still based on previous versions of the CSP protocol. Furthermore, network operators are still to deploy IMPS services and Internet IMPS servers supporting version 1.2 of the CSP protocol are not available either. The main advantage of testing the software against other implementations of the same protocol would have been the ability to resolve the kind of ambiguities mentioned in the previous paragraph. 5.3.5 Future Work Although the created CSP implementation fulfills most of the mandatory protocol requirements, much of the optional functionality, such as access control, invitations and user search, is not available. Also, the group messaging service element was not implemented due to the limited time frame of the project. In order to create a richer implementation, these features could be added in the future. Other possible improvements for the future include the addition of support for new transport bindings as well as incorporating support for other versions of the CSP protocol into the implementation. Finally, an implementation of the IMPS Server-Server Protocol (SSP) would combined with the CSP implementation provide a complete IMPS service. Chapter 6 Discussion and Conclusions Section 3.3 presented a number of characteristics of mobile environments that deviate from the corresponding characteristics of wireline environments. Two instant messaging systems, IMPS and SIMPLE, were compared in Chapter 4, the comparison emphasizing the characteristics of mobile environments. Furthermore, the design and implementation of the IMPS CSP protocol was introduced in Chapter 5. Thus, all the objectives listed in Section 1.1 were fulfilled. The remainder of this chapter summarizes the results of the comparison and the implementation work in Sections 6.1 and 6.2. Conclusions from the results are drawn in Section 6.3. Finally, the significance of the results and future work to be done are considered in Sections 6.4 and 6.5. 6.1 Comparison of IMPS and SIMPLE As IMPS is specifically defined for usage in mobile environments and the IP Multimedia Subsystem (IMS) brings SIMPLE to forthcoming 3G networks, these two services are the top alternatives for mobile instant messaging. IMPS is a more mature service than SIMPLE. IMPS version 1.2 is nearly finalized and version 1.3 is already being defined. SIMPLE has not yet reached standard status and parts of the service are still ongoing work. However, the main elements of SIMPLE are ready and the service should be adopted as an IETF standard in 2005. The functionality of both services is very similar from a user’s point of view, but the techniques used to provide the functionality differ considerably between the services. IMPS is based on a rather simple architecture where all client communication passes through servers. SIMPLE on the other hand is a fairly complex solution which relies on SIP for much of its functionality but other protocols such as XCAP and MSRP are also utilized. The fact that SIMPLE provides two completely different messaging modes, pager mode 65 CHAPTER 6. DISCUSSION AND CONCLUSIONS 66 and session mode, only adds to the complexity. Despite their differences, both architectures allow for excellent scalability as functionality and users can be distributed among a multitude of servers. Both services utilize techniques for optimizing the performance in mobile environments. Overall, SIMPLE is slightly more efficient than IMPS when it comes to bandwidth usage and delays. Performance-wise, the most notable flaw in SIMPLE is the inability to traverse proxies. This affects the applicability of the service since a global service cannot be created. IMPS is able to handle proxy traversal without problems. SIMPLE includes mechanisms for providing the service with relatively strong security. Due to the complexity of the SIMPLE architecture, applying an even level of security throughout a network requires a great deal of cooperation between network administrators. IMPS provides sufficient security only between the client and its local server, end-to-end security can not be requested by clients and is therefore not guaranteed in all networks. Since the IMPS protocols are completely based on XML and function on top of several different transport bindings, IMPS qualifies as an extensible and flexible solution. SIMPLE also utilizes the XML format, but the tight coupling with the SIP protocol reduces flexibility to an extent. Finally, both services are built based on the requirements formulated by the IMPP working group, thus enabling good interoperability with other instant messaging systems. However, IMPS does not support the PIDF presence format, whereas SIMPLE is fully compliant with IMPP. 6.2 Implementation of IMPS CSP protocol The implementation of the CSP protocol of the IMPS service was successfully completed according to the plan and the requirements set upon the implementation were fulfilled. Minor problems were caused by ambiguities in the specifications. In addition, the lack of other similar implementations complicated interoperability testing slightly. 6.3 Conclusions Tables 6.1 and 6.2 list the main advantages and disadvantages of the compared services. The rest of this section presents the conclusions drawn from the results of the comparison. CHAPTER 6. DISCUSSION AND CONCLUSIONS 67 Table 6.1: Advantages and disadvantages of IMPS Advantages Disadvantages Simple architecture Security Scalability Lack of charging protocol Extensibility Proxy traversal Table 6.2: Advantages and disadvantages of SIMPLE Advantages Disadvantages Scalability Complex architecture Interoperability Tightly coupled with SIP Security Proxy traversal Efficiency IMPS is a simple solution that is easy to deploy The simple architecture of IMPS makes it possible for service providers to take the service into use without great efforts. In the simplest case, the service provider only needs to deploy one IMPS server. By updating the server with addresses of other servers, communication between users of different service providers or distributed services can be enabled. As a range of different bearers can be used to access the IMPS service, most service providers already have the infrastructure needed to deploy the service. IMPS lacks charging functionality; if service providers intend to charge per sent message, then a proprietary solution must be utilized. SIMPLE is a complex solution that requires effort to deploy As opposed to IMPS, the architecture of SIMPLE consists of several distinct elements communicating using numerous different protocols and data formats. This alone makes deploying SIMPLE far from effortless. In addition, a functioning SIP network is needed as a prerequisite for building a SIMPLE service. The SIP-based IMS standard brings multimedia services, including SIMPLE, to 3G networks. IMS also includes charging functionality which enables service providers to choose from different charging schemes for instant messaging. Although deploying IMS and SIMPLE requires resources from service providers, the amount of new services enabled by IMS should pay back the effort over time. CHAPTER 6. DISCUSSION AND CONCLUSIONS 68 SIMPLE provides the performance and security needed for business-oriented services The combination of SIP and peer-to-peer messaging provides SIMPLE with good performance considering the demands related to mobile instant messaging services. Both bandwidth usage and messaging delay can be optimized for usage in mobile environments. Additionally, security issues have not been neglected in the design of SIMPLE. All protocols used in SIMPLE come equipped with security mechanisms strong enough to eliminate most security threats. All in all, the level of performance and security is high enough for using SIMPLE for business-oriented services. IMPS lacks in security Although the performance of IMPS in mobile environments is up to par with the requirements for mobile environments, IMPS fails to meet some expectations when it comes to security. A service provider can create a secure service in a closed network by having all servers accept only secure connections. However, in larger networks with no common security policy, end-to-end security cannot be guaranteed. In such networks, a mechanism allowing clients to request that a message should be rejected in case it cannot be delivered securely would be needed. Unfortunately, IMPS lacks this kind of mechanism. IMPS can be used to implement a global service spanning both wireline and wireless networks IMPS includes mechanisms allowing servers to communicate with clients even if the two are separated by a proxy. Although the solution for proxy traversal adds some extra delay to server initiated messages, the advantage of the solution easily outweighs the disadvantages. While most mobile clients and many fixed PC clients are connected to the Internet through proxies, the proxy traversal ability of IMPS makes communication between them possible. This enables creating a global service on the Internet, to which users can connect using both mobile and fixed clients. SIMPLE has problems traversing proxies SIMPLE has severe problems traversing proxies. The difficulties are caused both by the SIP protocol and by peer-to-peer sessions. Several independent solutions to the problem have been proposed, all adding to the complexity of the service. So far no solutions for solving the problem completely and efficiently have been standardized. SIMPLE functions well inside mobile networks or intranets, but connecting mobile network users with Internet users is currently not possible. CHAPTER 6. DISCUSSION AND CONCLUSIONS 69 Both IMPS and SIMPLE are applicable in mobile environments All in all, the comparison confirmed that IMPS and SIMPLE conform to the requirements set forth by mobile environments. Both IMPS and SIMPLE feature numerous optimizations for improving the suitability of the services in mobile environments. Of course, both services have their strengths and weaknesses, against which own requirements should be compared before selecting a mobile instant messaging solution. 6.4 Significance of the Results This thesis strives to bring new information to the domain of mobile services by studying the limitations placed on mobile services and by evaluating the applicability of two mobile instant messaging services with these limitations in mind. Although one service could not be declared superior to the other, this thesis provides an overview of the advantages and disadvantages of both services and an assessment of the applicability of the services in mobile networks. 6.5 Future Work As the functionality of the next version of IMPS is already being defined and many parts of the SIMPLE specifications are not finalized, updates and improvements will be made to both the compared services in the future. These changes can affect the validity of the results of the comparison. Therefore, the comparison should be kept up to date as the services evolve. As the comparison was carried out on a theoretical basis, performing tests in real mobile networks would also be of interest in the future. Furthermore, the implementation of the IMPS CSP protocol could be broadened to include more functionality, such as access control and group messaging. Bibliography [1] Open Mobile Alliance. Client-Server Protocol Binary Definition and Example, Version 1.2, February 2003. Available at: http://member.openmobilealliance. org/ftp/public documents/MWG/IM/Permanent documents/OMA-IMPS-WV-CSP WBXML-V1 2-20030221-C.zip [referred to 30.8.2004]. [2] Open Mobile Alliance. February 2003. Presence Attribute DTD and Examples, Version 1.2, Available at: http://member.openmobilealliance.org/ftp/ public documents/mwg/IM/Permanent documents/OMA-IMPS-WV-CSP PA DTD-V1 2-20030221-C.zip [referred to 30.8.2004]. [3] Open Mobile Alliance. Server-Server Protocol Semantics Document, Candidate Version 1.2, February 2003. Available at: http://member.openmobilealliance.org/ ftp/public documents/MWG/IM/Permanent documents/OMA-IMPS-WV-SSP-V1 2-20030221-C.zip [referred to 30.8.2004]. [4] Open Mobile Alliance. Client-Server Protocol DTD and Examples, Candidate Version 1.2, March 2004. Available at: http://member.openmobilealliance.org/ ftp/public documents/mwg/IM/Permanent documents/OMA-IMPS-WV-CSP DTD-V1 2-20040317-C.zip [referred to 30.8.2004]. [5] Open Mobile quirement, Alliance. Client-Server Candidate Version 1.2, Protocol March 2004. Static Conformance Available at: Re- http: //member.openmobilealliance.org/ftp/public documents/mwg/IM/ Permanent documents/OMA-IMPS-WV-SSP SCR-V1 2-20040427-C.zip [referred to 30.8.2004]. [6] Open Mobile Alliance. System Architecture Model, Candidate Version 1.2, May 2004. [7] D. Atkins and G. Klyne. Common Presence and Instant Messaging (CPIM): Message Format (RFC 3862). The Internet Society, August 2004. [8] AT&T. Getting The Most From Your Favourite Gizmo ... The Telephone, May 2004. Available at: http://www.att.com/news/item/0,1847,13059,00.html [referred to 30.8.2004]. 70 BIBLIOGRAPHY 71 [9] G. Bajko, B. Bertenyi, and K. Kiss. Multimedia Sessions Between 3G Wireless and Internet Users. In IEEE International Conference on Communications, 2001, pages 435–439, June 2001. [10] T. Bray, D. Hollander, A. Layman, and R. Tobin. Namespaces in XML 1.1. World Wide Web Consortium, February 2004. Available at: http://www.w3.org/TR/ xml-names11/. [11] S. Buckingham. Data on MMS. Mobile Lifestreams, November 2001. [12] G. Camarillo. Compressing the Session Initiation Protocol (SIP) (RFC 3486). The Internet Society, February 2003. [13] B. Campbell, Protocol. R. Mahy, and C. Jennings. The Message Session Relay Internet draft, Internet Engineering Task Force, August 2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/ draft-ietf-simple-message-sessions-08.txt [referred to 30.8.2004]. [14] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, and D. Gurle. Session Initiation Protocol (SIP) Extension for Instant Messaging (RFC 3428). The Internet Society, December 2002. [15] I. Chlamtac and J. Redi. Mobile Computing: Challenges and Potential. In Encyclopedia of Computer Science, 4th Edition. International Thomson Publishing, 1998. Available at: http://www.jasonredi.com/papers/mobile computing summary distrib.pdf [referred to 30.8.2004]. [16] The Jabber Community. Brief chronology of activity related to Jabber and XMPP in the IETF standards process. Available at: http://www.jabber.org/ietf/history. php [referred to 30.8.2004]. [17] The Jabber Community. The Instant Messaging Standards Race: Comparing XMPP/Jabber and SIP/SIMPLE, May 2003. [18] International Engineering Consortium. Instant Messaging. Available at: http:// www.iec.org/online/tutorials/instant msg/ [referred to 30.8.2004]. [19] M. Day, S. Aggarwal, G. Mohr, and J. Vincent. Instant Messaging / Presence Protocol Requirements (RFC 2779). The Internet Society, February 2000. [20] M. Day, J. Rosenberg, and H. Sugano. A Model for Presence and Instant Messaging (RFC 2778). The Internet Society, February 2000. [21] H. Elaarag. Improving TCP Performance over Mobile Networks. ACM Computing Surveys, 34(3):357–374, September 2002. ACM Press. BIBLIOGRAPHY 72 [22] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, Masinter L., P. Leach, and T. BernersLee. Hypertext Transfer Protocol – HTTP/1.1 (RFC 2616). The Internet Society, June 1999. [23] G.H. Forman and J. Zahorjan. The Challenges of Mobile Computing. Computer, 27(4):38–47, 1994. [24] M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Longman Publishing Co., Inc., 2003. [25] S. Franklin. XML Parsers: DOM and SAX Put to the Test, February 2001. Available at: http://www.devx.com/xml/Article/16922/0/page/1 [referred to 30.8.2004]. [26] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart. HTTP Authentication: Basic and Digest Access Authentication (RFC 2617). The Internet Society, June 1999. [27] D. Greene and D. O’Mahony. Instant Messaging & Presence Management in Mobile Ad-Hoc Networks. In Second IEEE Annual Conference on Pervasive Computing and Communications Workshops, pages 55–59, March 2004. [28] A. Gurtov. Making TCP Robust Against Delay Spikes. Technical Report Series of Publications C, No C-2001-53, University of Helsinki, Department of Computer Science, November 2001. [29] N. Hindocha. Threats to Instant Messaging. Technical report, Symantec Security Response, October 2002. Available at: http://www.symantec.com/avcenter/ reference/threats.to.instant.messaging.pdf [referred to 30.8.2004]. [30] H. Inamura (Editor), G. Montenegro (Editor), R. Ludwig, A. Gurtov, and S. Khafizov. TCP Over Second (2.5G) and Third (3G) Generation Wireless networks (RFC 3481). The Internet Society, February 2003. [31] iptel.org. SIP Products. Available at: http://www.iptel.org/info/products/ [referred to 30.8.2004]. [32] M. Isomäki and E. Leppänen. An Extensible Markup Language (XML) Con- figuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents. Internet draft, Internet Engineering Task Force, June 2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/ draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt [referred to 30.8.2004]. [33] V. Jacobson, R. Braden, and D. Borman. TCP Extension for High Performance (RFC 1323). The Internet Society, May 1992. BIBLIOGRAPHY 73 [34] C. Jennings and R. Mahy. lay Protocol (MSRP). Relay Extensions for Message Sessions Re- Internet draft, Internet Engineering Task Force, July 2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/ draft-ietf-simple-msrp-relays-01.txt [referred to 30.8.2004]. [35] Y. Kohda, H. Sugano, and S. Okuyama. IMPP: A New Instant Messaging Standard and Its Impact on Internet Business. Fujitsu Scientific & Technical Journal: Information Technologies in the Internet Era, 36(2):147–153, December 2000. Available at: http://magazine.fujitsu.com/us/vol36-2/paper06.pdf [referred to 30.8.2004]. [36] T.V. Lakshman and U. Madhow. The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss. IEEE/ACM Transactions on Networking, 5(3):336–350, June 1997. ACM Press. [37] S. Leggio, T. Kulve, O. Riva, and M. Kojo. An Analysis of Instant Messaging and E-mail Access Protocol Behaviour in Wireless Environments. Technical report, University of Helsinki, Department of Computer Science, March 2004. [38] T. Louis. AIM Still Not Secure. Planet IT, February 2001. Available at: http: //www.tnl.net/who/bibliography/aimsecurity/ [referred to 30.8.2004]. [39] H. Lundgren, R. Gold, E. Nordström, and M. Wiggberg. A Distributed Instant Messaging Architecture based on the Pastry Peer-To-Peer Routing Substrate. Technical report, Uppsala University of Sweden, 2003. Available at: http://winternet.sics. se/workshops/sncnw2003/proceedings/18T-sncnw.pdf [referred to 30.8.2004]. [40] M. Mitsuoka, S. Watanabe, J. Kakuta, and S. Okuyama. Instant Messaging with Mobile Phones to Support Awareness. In Symposium on Applications and the Internet, pages 223–230, January 2001. [41] MobileIN.com. Mobile Instant Messaging. Available at: http://www.mobilein.com/ MIM.htm [referred to 30.8.2004]. [42] P. Nguyen. Instant Messaging technology for the business market: Do the advantages outweigh the risks? Technical report, SANS Institute, November 2003. Available at: http://www.giac.org/practical/GSEC/Phuong Nguyen GSEC.pdf [referred to 30.8.2004]. [43] P. Nicholls. Short Message Service Long on Possibilities. Available at: http://www. klixxx.com/archive/smssolution.shtml [referred to 30.8.2004]. [44] J. Nielsen. IM, Not IP (Information Pollution). ACM Queue, 1(8):75–76, November 2003. [45] V. Niemi and K. Nyberg. UMTS Security. John Wiley & Sons, December 2003. BIBLIOGRAPHY 74 [46] M. Nordberg, H. Hannu, J. Christoffersson, and L. Zaccomer. Improving SigComp performance through Extended Operations. In Vehicular Technology Conference, 2003, pages 3425–3428, October 2003. [47] V. Pai and P. Rana. A Transparent Framework for Enabling Incoming TCP Connections to Host Behind a NAT Gateway. In Computer Communications and Networks, 2003, pages 572–575, October 2003. [48] R. Parvianen and P. Parnes. Mobile Instant Messaging. In 10th International Conference on Telecommunications, pages 425–430, 2003. [49] C.E. Perkins. Mobile networking in the Internet. Mobile Networks and Applications, 3(4):319–334, 1999. ACM Press. [50] J. Peterson. Common Profile for Instant Messaging (CPIM) (RFC 3860). The Internet Society, August 2004. [51] J. Peterson. Common Profile for Presence (CPP) (RFC 3859). The Internet Society, August 2004. [52] E. Pitoura and B. Bhargava. Dealing With Mobility: Issues and Research Challenges. Technical report, Department of Computer Science, Purdue University, US, November 1993. [53] M. Poikselkä, G. Mayer, H. Kharatabil, and A. Niemi. The IMS: IP Multimedia Concepts and Services in the Mobile Domain. John Wiley & Sons, June 2004. [54] R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, and J. Rosenberg. Signaling Compression (SigComp) (RFC 3320). The Internet Society, January 2003. [55] A. Quintana, J. Ramsinghani, and T. Walls. Peer-to-Peer Computing: The Search for Viable Business Models. Technical report, Kellogg Tech Ventures, 2001. Available at: http://www.ranjaygulati.com/new/research/PEER-TO.pdf [referred to 30.8.2004]. [56] A. B. Roach. Session Initiation Protocol (SIP) - Specific Event Notification (RFC 3265). The Internet Society, June 2002. [57] J. Rosenberg. The Session Initiation Protocol (SIP) UPDATE Method (RFC 3311). The Internet Society, September 2002. [58] J. Rosenberg. A Presence Event Package for the Session Initiation Protocol (SIP) (RFC 3856). The Internet Society, August 2004. [59] J. Rosenberg. The Extensible Markup Language (XML) Configuration Ac- cess Protocol (XCAP). Internet draft, Internet Engineering Task Force, July 2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/ draft-ietf-simple-xcap-03.txt [referred to 30.8.2004]. BIBLIOGRAPHY 75 [60] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol (RFC 3261). The Internet Society, June 2002. [61] J. Rosenberg and M. Schulzrinne. An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing (RFC 3581. The Internet Society, August 2003. [62] R. Sparks. The Session Initiation Protocol (SIP) Refer Method (RFC 3515). The Internet Society, April 2003. [63] B. Sterman and D. Schwartz. NAT Traversal in SIP, 2001. Available at: http://corp.deltathree.com/technology/nattraversalinsip.pdf [referred to 30.8.2004]. [64] J. Stone and S. Merrion. Instant Messaging or Instant Headache? ACM Queue, 2(2):72–80, April 2004. [65] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, and J. Peterson. Presence Information Data Format (PIDF) (RFC 3863). The Internet Society, August 2004. [66] E. Sutherland. Wireless telecommunications: value and mobility. Technical report, Indian Institute of Technology, 2002. [67] techiwarehouse.com. Instant Messaging. Available at: http://www. techiwarehouse.com/Articles/2003-05-12.html [referred to 30.8.2004], May 2003. [68] Y. Vogiazou. Wireless Presence and Instant Messaging. Technical report, Knowledge Media Institute, November 2002. [69] Webopedia.com. Online Encyclopedia dedicated to computer technology. Available at: http://www.webopedia.com. [70] Whatis.com. Available at: http://www.whatis.com. [71] R.L. Wickham (Editor-in Chief). SMS: Europe’s Smash Hit. Wireless Review, Available at: http://wirelessreview.com/ar/wireless sms europes smash/ [referred to 30.8.2004], March 2001. [72] Yamigo.com. It’s a Wireless Village. Available at: http://www.yamigo.com/. Appendix A Message Flow Examples SIMPLE Session Mode Messaging Alice → atlanta.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 179 v=0 o=alice 2890844557 2890844559 IN IP4 pc33.example.com s= c=IN IP4 pc33.atlanta.com 76 APPENDIX A. MESSAGE FLOW EXAMPLES t=0 0 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://pc33.atlanta.com:7777/iau39;tcp atlanta.com proxy → Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 atlanta.com proxy → Alice SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 182 v=0 o=bob 2890844612 2890844616 IN IP4 bobpc.biloxi.com s= c=IN IP4 bobpc.biloxi.com t=0 0 m=message 9 msrp * a=accept-types:text/plain a=path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp Alice → Bob ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 Alice → Bob MSRP d93kswow SEND To-Path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp From-Path:msrp://pc33.atlanta.com:7777/iau39;tcp Message-ID: 12339sdqwer Content-Type:text/plain Hi, I’m Alice! -------d93kswow$ 77 APPENDIX A. MESSAGE FLOW EXAMPLES Bob → Alice MSRP d93kswow 200 OK To-Path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp From-Path:msrp://pc33.atalanta.com:7777/iau39;tcp -------d93kswow$ Bob → Alice BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Alice → Bob SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Pager Mode Messaging Alice → atlanta.com proxy MESSAGE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:alice@atlanta.com;tag=49583 To: sip:bob@biloxi.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 14 Hi, I’m Alice! 78 APPENDIX A. MESSAGE FLOW EXAMPLES atlanta.com proxy → Alice SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 From: sip:alice@atlanta.com;;tag=49394 To: sip:bob@biloxi.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0 IMPS Messaging Alice → IMPS server POST /wv/ HTTP/1.1 Host: imps.atlanta.com Content-Length: 949 Content-Type: application/vnd.wv.csp.xml <WV-CSP-Message xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.2"> <Session> <SessionDescriptor> <SessionType>Inband</SessionType> <SessionID>pc33.atlanta.com#48815atlanta.com</SessionID> </SessionDescriptor> <Transaction> <TransactionDescriptor> <TransactionMode>Request</TransactionMode> <TransactionID>IMApp01#12345@NOK5110</TransactionID> </TransactionDescriptor> <TransactionContent xmlns="http://www.openmobilealliance.org/DTD/WV-TRC1.2"> <SendMessage-Request> <DeliveryReport>F</DeliveryReport> <MessageInfo> <ContentType>text/plain</ContentType> <ContentEncoding>None</ContentEncoding> <ContentSize>58</ContentSize> <Recipient> <User> <UserID>wv:bob@biloxi.com</UserID> </User> </Recipient> <Sender> 79 APPENDIX A. MESSAGE FLOW EXAMPLES <User> <UserID>wv:alice@atlanta.com</UserID> </User> </Sender> <Validity>600</Validity> </MessageInfo> <ContentData>Hi, I’m Alice!</ContentData> </SendMessage-Request> </TransactionContent> </Transaction> </Session> </WV-CSP-Message> IMPS server → Alice HTTP/1.1 200 OK Date: Sat, 21 Aug 2004 07:40:27 GMT Content-Length: 702 Content-Type: application/vnd.wv.csp.xml <WV-CSP-Message xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.2"> <Session> <SessionDescriptor> <SessionType>Inband</SessionType> <SessionID>pc33.atlanta.com#48815@atlanta.com</SessionID> </SessionDescriptor> <Transaction> <TransactionDescriptor> <TransactionMode>Response</TransactionMode> <TransactionID>IMApp01#12345@NOK5110</TransactionID> </TransactionDescriptor> <TransactionContent xmlns="http://www.openmobilealliance.org/DTD/WV-TRC1.2"> <SendMessage-Response> <Result> <Code>200</Code> <Description>Successfully completed.</Description> </Result> <MessageID>0x0000f132</MessageID> </SendMessage-Response> </TransactionContent> </Transaction> <Poll>F</Poll> </Session> </WV-CSP-Message> 80