LEMONADE WG Internet Draft Alan K. Stebbens Milt Roselinsky Document: draft-stebrose-mmsarch-00.txt Openwave Systems Expires: September 2003 March 2003 Mobile Messaging Architectures and Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The increasing importance of messaging as a potential source of revenue for mobile networks has led operators to build or procure mobile messaging solutions. Some operators have built mobile messaging solutions using IETF standards (IMAP, SMTP, MIME). Another solution has been developed by consensus in the 3GPP and OMA groups, based on MIME, HTTP methods and WAP PUSH, which has been deployed by many operators. This document presents a taxonomy of messaging architecture components and models, providing a comparison of their feature sets. It also identifies the commonalities of these mobile messaging solutions and abstracts from these a set of mobile messaging requirements. The information is provided to inform and encourage future discussion of and improvements to Internet messaging in order to increase their applicability to mobile messaging systems. Stebbens & Roselinsky Expires - September 2003 [Page 1] Mobile Messaging Architectures & Requirements March 2003 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 2. Components and Models of Mobile Messaging......................3 2.1 Mobile Messaging Components................................3 2.2 Mobile Messaging Transaction Models........................3 2.3 Mobile Messaging Transactions..............................4 2.4 Submission.................................................4 2.5 Notification...............................................5 2.6 Retrieval..................................................6 3. Mobile Messaging Architectures.................................6 3.1 Short Message Service (SMS)................................7 3.2 Mobitex....................................................7 3.3 Extended Messaging Service (EMS)...........................8 3.4 Web/WAP-based Messaging....................................8 3.5 Mobile Messaging Based on IMAP4 and SMTP...................9 3.6 MMS Messaging.............................................10 4. Messaging Call Flows..........................................11 5. Analysis of Mobile Messaging Requirements.....................12 5.1 Mobile Messaging Requirements.............................12 6. Security Considerations.......................................13 7. References....................................................13 8. Acknowledgments...............................................15 9. Author's Addresses............................................15 1. Introduction Messaging has proven to be an important application, developed and extensively used for more than a decade over wire line networks. Over the last few years, messaging applications have also been deployed across wireless networks worldwide. Initially, the mobile messaging facilities were simple: text-based and person-to-person (or device-to-device). Correspondingly, the mechanisms used to transport the simple text-based messages were also simple. Subsequently, additional features have been added to the mobile messaging services, resulting in rich multimedia services with many Stebbens & Roselinsky Expires - September 2003 [Page 2] Mobile Messaging Architectures & Requirements March 2003 features. Photo messaging services, for example, first appeared in Japan in 2000 (based on IMAP4 [3]), then, in 2002, in Europe and in the Americas (based on OMA MMS [4]). These rich multimedia mobile messaging services have required richer messaging transport protocols which are capable of transporting and managing the varied multimedia objects, as well as providing the appropriate messaging semantics. IMAP4, with its rich messaging feature set, has been used as the message transport protocol in several mobile messaging architectures. OMA MMS has been developed by 3GPP([5],[6]) and OMA to provide for some of the mobile messaging service functions, and is widely supported by mobile vendors and their operator-customers. 2. Components and Models of Mobile Messaging From a survey of existing messaging architectures, there are is a common client server architecture with mobile clients and operator servers. This architecture is differentiated by whether the clients have push model or pull model transactions between them. 2.1 Mobile Messaging Components The client, also known as a "user agent", presents messages to and accepts messages from the user, and performs messaging functions on behalf of the user, sometimes automatically, sometimes with interrogation of the user. The server, also known as a "relay/server" or a "proxy-relay", generally resides in the operator's network and manages messages on behalf of some or all of the operator's subscribers. It accepts connections from clients, typically authenticated, performs requested functions, and, importantly, generates billing records appropriate to the requested function. The server also provides storage of the message for some length of time (depending on service definition). 2.2 Mobile Messaging Transaction Models As stated above, there are two basic transactional models. The "pull" model is where the component with the message data initiates the transaction. For example a client may initiate a connection to a server and issue requests to the server to discover and retrieve messages as appropriate. Conventional e-mail clients, web-mail clients, and WAP-based mobile clients use the "pull" model. The "push" model is where the component that wishes to operate on the data initiates the transaction. For example, it is common that the Stebbens & Roselinsky Expires - September 2003 [Page 3] Mobile Messaging Architectures & Requirements March 2003 arrival of a new message at the terminating server causes a notification to be sent ("pushed") to a messaging client. The push model has the advantage of being event or message driven. User interaction only occurs when message data is available. Unlike the pull model where the user must poll for new message data (or configure their client to poll for them). 2.3 Mobile Messaging Transactions The most common functions are: "submission", "notification", and "retrieval". There may be other functions, such as "delivery reports", "read-reply reports", "forwarding", "view mailbox", "store message", etc. Each of these transactions can be implemented in either a pull or push model. However, some transactions are more naturally suited to one model or another. The following Figure 1 is a simple depiction of the basic messaging model: (1) Message submission (2) Message notification (3) Message retrieval +-------+ +------+ +-------+ |Mobile |-------(1)------>| |-----------(2)-------->|Mobile | |Client | Submit msg | | Notification /|Client | +-------+ | | / +--+----+ | | / ^ | |<----------(3)-----+ / |Server| Retrieval request / | | / | | / | |-----------(4)-------+ | | Retrieval response | | +------+ Figure 1 - Basic Messaging Model 2.4 Submission The "submission" transaction is the transaction between a client and a server by which the user of the former can sends a new message to another user. Stebbens & Roselinsky Expires - September 2003 [Page 4] Mobile Messaging Architectures & Requirements March 2003 This transaction is most commonly implemented in the push model. The when the user has composed a message, the user directs the client to initiate a connection to the server and push the message up to the server. In a pull model implementation, the server would connect to the client from time to time and query for the presence of new messages to send. In practice, this is never done. 2.5 Notification The "notification" transaction is the transaction by with the server notifies the client that it has received messages intended for that client. This transaction is also most commonly implemented as a push transaction. In this model, the server will initiate a connection to the client and send data to the client indicating that new message data is available for the client. SMS [7], by virtue of already being widely available, has become the ubiquitous protocol that provides for a basic notification service. Given that SMS packets are limited in size, the prevalent use of SMS is to send a summary of multimedia messages, including a reference, in the notification message. The WAP Forum, now part of the Open Mobile Alliance (OMA), published a flexible "Push Architecture" (WAP Push [8], PAP [9]), with which services can have messages pushed to mobile devices, either over HTTP [10] or SMS. There is some talk of adapting the Push Proxy-Gateway [11] to use SIP NOTIFY for notification transport, but this, too, is still work-in-progress. Regardless of the actual transport method, the essential ingredient to all of them is that either the message itself (if it a short one) or a summary of and reference to the message must be sent to the client. In the case of a short message being sent via a notification, the client can then present it to the user. In the case of a long message, the client can either then present a summary of the message, or, by using the message reference, retrieve additional information about the message, or even the complete message, and present it appropriately to the user. The significant advantage of the push model notifications is that data is presented to the user without the user needing to be aware of network/transport latencies, and without tying up network resources for polling when there is no new data. All of the larger mobile messaging systems implement a push model for the notification transaction. Stebbens & Roselinsky Expires - September 2003 [Page 5] Mobile Messaging Architectures & Requirements March 2003 The "pull" model of PC-based or WAP-based mobile e-mail clients has not required a notification method per-se. When a new message arrives at the server, the client learns of it only when it next initiates a connection to the server and requests a list of messages (or, more optimally, a list of new message). Clients can be configured to automatically connect to the server and determine whether or not new messages are available, and notify the user as desired. This has been completely acceptable to the client community and so, there has been no protocol development in this area. There has been recent work to define "e-mail notification" methods SIP-MWI [12], EMN [13], SNAP [14], but these are still works-in- progress. 2.6 Retrieval The "retrieval" transaction is the transaction between a client and a server by which the client can obtain one or more messages from the server. In a push model implementation, the server will initiate a connection to the client and push the message data to the client. This is done in OMA [4] in "Immediate Mode." The advantage of this is that the user is not necessarily aware of transport or network latencies. The disadvantage is that the client may not be able to store the message due to size constraints. In a pull model implementation, the client will initiate a connection to the server and retrieve the message from the server. Often the client will first retrieve information about the message (e.g. IMAP4 BODYSTRUCTURE [3]), and allow the user to selectively download the message from the server to the client. The advantage of this method is that the user can control what data is actually sent to and stored by the client. In both implementations (push or pull) the server can be configured to keep a copy of the message data in server-managed storage. This is considered very valuable by many users. The server-managed message data is available for other operations without requiring upload from the client. For example, it can be referenced and forwarded as part of another message, or it may be viewed from another client, whether mobile or fixed. 3. Mobile Messaging Architectures Although many of the transport protocols and interfaces have been standardized, mobile operators compete with how they combine the standard protocols and interfaces into an innovative, comprehensive Stebbens & Roselinsky Expires - September 2003 [Page 6] Mobile Messaging Architectures & Requirements March 2003 messaging architecture that fulfills their service requirements. The following sections are a brief survey of several mobile messaging architectures, their features, and their problems. 3.1 Short Message Service (SMS) The Short Message Service (SMS) allows the exchange of short text- only messages on mobile telephone networks. SMS emerged in the early 1990s and by 2001 had become a very popular consumer-oriented messaging service, when users exchanged more than 100 billion messages. SMS was originally standardized as part of the GSM phase 1 ETSI technical specifications. Features: . short-messages of less than 140 octets . E.164-based[15] or "short code" addressing . Text only . Client presentation is easy (because text-only) . First over-the-air immediate messaging protocol . Additional functions (CANCEL, REPLACE) to support content- providers (VASPs) . Available on almost every handset: TDMA, CDMA, GSM, GPRS Problems: . Requires expensive SS7[16] network interface . Each SMS data packet requires SS7 signaling, which is also used for voice signaling . No network mailbox support . No standard Internet interworking (e-mail gateways exist but are ad-hoc or commercial products) . Requires specialized hardware systems called SMSCs . There are several "standard" interfaces for inter-SMSCs, creating the need for inter-SMSC switches 3.2 Mobitex Mobitex is a proprietary service, created by Ericsson, that is a packet-switched, narrowband PCS network, designed for wide-area wireless data communications. Mobitex networks offer a variety of paging solutions, the most advanced of which is called "interactive paging", a 2 way text messaging solution. Features: . Short-messages of less than 500 octets . Device addressing only . Text-only . Transport supports submit, delivery, & read reports Stebbens & Roselinsky Expires - September 2003 [Page 7] Mobile Messaging Architectures & Requirements March 2003 Problems: . Proprietary Ericsson network (based on X.25 [17]) . Device addressing only . No network mailbox support . Limited client availability . No standard Internet interworking interface 3.3 Extended Messaging Service (EMS) The Extended Messaging Service (EMS [18]) is an enhancement to the SMS service that enables the exchange of multimedia messages. EMS utilizes the same network infrastructure as SMS [7]. Features: . Long messages sent via concatenated SMS packets . E.164-based [15] or "short code" addressing . Text, bit-map images, and vector graphics Problems: . Requires expensive SS7 [16] network interface . Each EMS "packet" is one or more SMS data packets, each of which requires SS7 signaling that is also used for voice signaling . No network mailbox storage . No standard interworking with Internet e-mail systems . Client presentation of media less simple . No capability discovery or content negotiation between EMS devices (what happens if a bitmap image is sent to another address that does not support that image type?) . Requires specialized hardware systems called EMSCs (upgraded SMSCs) . EMSCs continue the need for SMSC/EMSC switches 3.4 Web/WAP-based Messaging Perhaps the first architecture realized for mobile messaging that allowed for the possibility of presenting a unified interface for multimedia messages was the WAP-based mobile e-mail service. Features: . Leverages ubiquitous HTTP [10] as transport . RFC2822 addressing [20] . Large and multimedia message support . Client capability discovery and content adaptation based on USERAGENT string [10] . Can support delivery and read reports (server-based) . Mailbox functions fully supported . Client requires only a WAP browser . Message transported via IP network, using Internet protocols Stebbens & Roselinsky Expires - September 2003 [Page 8] Mobile Messaging Architectures & Requirements March 2003 . Interoperates with Internet e-mail systems Problems: . No E.164 [7] or "short code" addressing, except possibly for only the mobile operator's network . Requires network connectivity for all operations, even message composition . User typically exposed to the network latencies (e.g., no "background" submission or retrieval) . Server-based message composition not integrated with client address book . No notifications of newly arrived messages - user or client must request new messages . Mobile radio access billing not necessarily integrated with message service billing It is interesting to note that one of the major complaints with mobile web mail services was network latencies, which is a consequence of the design of the relatively stateless, browser-based client, and not necessarily a consequence of using WSP and/or HTTP. 3.5 Mobile Messaging Based on IMAP4 and SMTP Several mobile operators have built a mobile messaging architecture based on IETF messaging protocols: SMTP [19], IMAP4 [3], and used SMS[7] for their notification protocol. Today, these operators have proven, successful, revenue-generating multimedia messaging services. Features: . RFC2822 [20] and E.164 [15] addressing, including "short codes" . Large and multimedia message support, MIME [21] encapsulation . Can support delivery reports (DSNs [22]) and read reports (MDNs [23]) . Messages submitted, retrieved, and forwarded via IP network, using Internet protocols . Wide interoperability with Internet e-mail systems. . Notifications via WAP Push or SMS . Complete mailbox support available now . Client and server developers have ready access to widely deployed protocol development kits, test tools, etc. . Billing can be based on either per-message or per-byte . Persistent storage model supported . Authentication can be network-based or application-based Problems: . IMAP4 too "chatty"; operators have made proprietary adaptations to avoid this. . Messages are base64 encoded, expanding the payload. . Notification methods not standardized. Stebbens & Roselinsky Expires - September 2003 [Page 9] Mobile Messaging Architectures & Requirements March 2003 . No client capability discovery or exchange . No content adaptation . No content protection mechanisms currently 3.6 MMS Messaging The 3GPP T2 and OMA MAG MMS groups developed the Multimedia Messaging Service (MMS) specifications independently ([5], [6]), based on new HTTP [10] methods and WAP Push ([24], [25]). The MMS Submission and Retrieval methods are fulfilled with HTTP methods. The MMS Notification is based on the WAP Push architecture, which can delivery push messages over HTTP or over SMS [7]. Features: . RFC2822 and E.164 addressing, including "short codes" . Large and multimedia message support, MIME encapsulation . Delivery reports and read reports supported . Client capability discovery (via UAPROF [26] or HTTP USERAGENT [10] strings) . Content adaptation supported . Delayed delivery feature supported . Forward without download . Tightly integrated billing, supporting both pre- and post-pay operations . Some mailbox functions supported now . Messages submitted, retrieved, and forwarded via IP network, using SMTP with MMS headers . Internet e-mail interworking . Well-specified content provider API that allows partnering relationships between content owners and messaging service providers. . Notifications via WAP Push or SMS . Message is compressed to save bandwidth . Well-specified IOT program within OMA IOP . Authentication is network-based Problems: . Delivery reports are not DSNs and do not interoperate with SMTP e-mail systems in a standard fashion . Read-reply reports are not MDNs and do not interoperate with SMTP e-mail systems in a standard fashion . Some mailbox functions not supported (server-based sorting, message folders) . Over-the-air transport protocols not widely deployed; lack of development kits and test tools . Content protection mechanisms are limited to a "forward lock" (OMA DRM is still a work-in-progress) Stebbens & Roselinsky Expires - September 2003 [Page 10] Mobile Messaging Architectures & Requirements March 2003 4. Messaging Call Flows In Figure 2 (below), the basic call flows for the IETF messaging and MMS technologies are depicted, similar to the basic messaging model from Figure 1: (1) Message submission (from the client) (2) Message notification (to the client) (3) Message retrieval request (from the client) (4) Message retrieval response (deliver msg to the client) +-------+ +------+ +-------+ |Mobile |-------(1)------>| |-----------(2)-------->|Mobile | |Client | Submit msg | | Notification /|Client | +-------+ (SMTP or) | | (SMS) / +--+----+ (IMAP APPEND) |SMTP/ | / ^ |IMAP4 |<----------(3)-----+ / |Server| Retrieval request / | | (IMAP) / | | / | |-----------(4)-------+ | | Retrieval response | | (IMAP) +------+ Figure 2 - Messaging Call Flow with SMTP, SMS, & IMAP +-------+ +------+ +-------+ |Mobile |-------(1)------>| |-----------(2)-------->|Mobile | |Client | Submit msg | | Notification /|Client | +-------+ (HTTP) | | (SMS) / +--+----+ | | / ^ | MMS |<----------(3)-----+ / |Server| Retrieval request / | | (HTTP) / | | / | |-----------(4)-------+ | | Retrieval response | | (HTTP) +------+ Figure 3 - MMS with specialized HTTP methods & SMS. Please note that the call flows for both are identical except for the actual transport protocols. Stebbens & Roselinsky Expires - September 2003 [Page 11] Mobile Messaging Architectures & Require