[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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 & Requirements  March 2003


5. Analysis of Mobile Messaging Requirements

   As identified in the preceding descriptions, modern mobile messaging
   systems have a number of requirements.  Some of these differ
   significantly from those seen in the desktop oriented email systems
   deployed in today's Internet.

   The mobile user marketplace is targeted at a large consumer audience
   and requires a simple, immediate and compelling messaging experience.

   Users of today's mobile messaging user agents desire a rich end user
   experience that features multimedia content pushed to the end user
   device.  The devices available today are constrained as to which
   media codecs are supported, limited screen size, limited or expensive
   network bandwidth.  The mobile devices are often roaming in and out
   of network coverage and the messaging system must take this into
   consideration.

   Mobile network providers often operate on a "pay for use" service
   model.  This brings in requirements for clearly delineated service
   transactions that can be reported to billing systems, and for
   positive end-to-end acknowledgement of delivery or non-delivery of
   messages.

5.1 Mobile Messaging Requirements

   The following are requirements of a successful mobile messaging
   offering:
     . Push based notifications.
     . Delivery model where messages "just show up" on the device (when
        appropriate), based on push based notification and end-user
        preference settings.  In other words, hide network latencies
        from the user, and reduce user interaction with profile-based
        automations.
     . RFC2822 and E.164 addressing, including "short codes"
     . Large message and multimedia message support, MIME encapsulation
     . Support for end-to-end delivery reports and read reports
     . Client capability discovery/exchange and content adaptation
     . User configurable filters for selective downloading and SPAM
        control
     . Message exchange with existing Internet email systems
     . Mailbox (persistent storage model) support
     . Network-based and/or application-based authentication
     . Bandwidth saving features such as binary transfers, data
        compression, forward without download and streamlined client-
        server message submission and retrieval





Stebbens & Roselinsky  Expires - September 2003              [Page 12]


            Mobile Messaging Architectures & Requirements  March 2003


6. Security Considerations

   This draft describes mobile messaging networks based on IMAP4, SMTP
   and HTTP.  Although all offer application-level authentication, many
   mobile operators have deployed mobile messaging services network-
   based authentication.  In other words, the sessions are implicitly
   authenticated by the mobile device network access parameters.


7. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  Crispin, M., "Internet Message Access Protocol - Version 4rev1",
      RFC 2060, University of Washington, December 1996.

   4  Open Mobile Alliance (OMA) "Multimedia Messaging Service;
      Architectural Overview Version 1.1", OMA, 2002

   5  3GPP TS 22.140 "Third Generation Partnership Project; Technical
      Specification Group Services and System Aspects; Service aspects;
      Functional description; Stage 1 Multimedia Messaging Service",
      3GPP, 2001

   6  3GPP TS 23.140 "Third Generation Partnership Project; Technical
      Specification Group Terminals; Multimedia Messaging Service (MMS);
      Functional description; Stage 2", 3GPP, 2001

   7  C.S0015-A: Short Message Service (SMS), December 1999, 3GPP2.

   8  Open Mobile Alliance (OMA) "Push Architectural Overview,
      WAP-250-PushArchOverview-20010703-a", OMA, 2001

   9  Open Mobile Alliance (OMA) "Push Architectural Overview
      Push Access Protocol Specification, WAP-247-PAP-20010429-a", OMA,
      2001

   10 Fielding, Gettys, Berners-Lee, et. al., "Hypertext Transfer
      Protocol - HTTP 1.1", RFC 2616, June 1999.

   11 Open Mobile Alliance (OMA) "Push Proxy Gateway Service
      Specification", WAP-249-PPGService-20010425.pdf, OMA, 2001



Stebbens & Roselinsky  Expires - September 2003              [Page 13]


            Mobile Messaging Architectures & Requirements  March 2003



   12 Mahy, R. "A Message Summary and Message Waiting Indication Event
      Package for the Session Initiation Protocol (SIP)", draft-ietf-
      sipping-mwi-01.txt

   13 Open Mobile Alliance (OMA) "E-mail Notification Version 1.0", OMA,
      2002

   14 Shapira, N. and Aloni, E. "Simple Notification and Alarm Protocol
      (SNAP)", Comverse Technology, 2002.

   15 ITU-T Recommendations Series E: "E.164: The international public
      telecommunication numbering plan"; ITU, May 1997.

   16 CCITT White Book, Volume VI, Fascicle VI.7, Recommendations Q.700-
      Q.716: Specifications of Signalling System No. 7.

      CCITT White Book Volume VI, Fascicle VI.8, Recommendations Q.721-
      Q.766: Specifications of Signalling System No.7.

      ITU White Book, ITU-T Recommendation Q.763: Specifications of
      Signalling System Number 7.

      GR-246-CORE, Issue 1, December 1994: Specifications of Signalling
      System Number 7.

   17 ITU-T Recommendation Series X: X.25: "Interface between Data
      Terminal Equipment (DTE) and Data Circuit-terminating Equipment
      (DCE) for terminals operating in the packet mode and connected to
      public data networks by dedicated circuit", ITU, Oct 1996.

   18 S.R0051-0 v1.0, "Enhanced Message Service (EMS) Stage 1
      Description", 3GPP2, July 2001.

   19 Klensin, J. "Simple Mail Transfer Protocol", RFC 2821, April 2001.

   20 Resnick, P. "Internet Message Format", RFC 2822, April 2001.

   21 Freed, N. and Borenstein, N. "Multipurpose Internet Mail
      Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

   22 Moore, K. "SMTP Service Extension for Delivery Status
      Notifications", RFC 1891, January 1996.

   23 R. Fajman, "An Extensible Message Format for Message Disposition
      Notifications", RFC 2298, March 1998.




Stebbens & Roselinsky  Expires - September 2003              [Page 14]


            Mobile Messaging Architectures & Requirements  March 2003



   24 Open Mobile Alliance (OMA) "Multimedia Messaging Service; Client
      Transactions Version 1.1", OMA-MMS-v1_1, OMA, 2002

   25 Open Mobile Alliance (OMA) "Multimedia Messaging Service;
      Encapsulation Protocol Version 1.1", OMA-MMS-v1_1, OMA, 2002

   26 Open Mobile Alliance (OMA) "User Agent Profile, Version 1.1", OMA-
      UAPROF-v1_1, OMA, December 2002.



8. Acknowledgments

   Benjamin Ellsworth,
   Openwave Systems, Inc.
   530 E. Montecito St., Santa Barbara, CA 93103
   Phone: 805-884-3153
   Email: benjamin.ellsworth@openwave.com


9. Author's Addresses


   Alan K. Stebbens
   Openwave Systems, Inc.
   530 E. Montecito St., Santa Barbara, CA 93103
   Phone: 805-884-3162
   Email: alan.stebbens@openwave.com

   Milt Roselinsky
   Openwave Systems, Inc.
   530 E. Montecito St., Santa Barbara, CA 93103
   Phone: 805-884-6207
   Email: milt.roselinsky@openwave.com
















Stebbens & Roselinsky  Expires - September 2003              [Page 15]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/