1 / 10

Internet Standards Based Mobile Messaging

Internet Standards Based Mobile Messaging. Alan.Stebbens@openwave.com Milt.Roselinsky@openwave.com March, 2003. Introduction. The Mobile Messaging experience differs from current Internet Email experience Mobile user expects “push model” of message delivery

cachet
Télécharger la présentation

Internet Standards Based Mobile Messaging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet Standards BasedMobile Messaging Alan.Stebbens@openwave.com Milt.Roselinsky@openwave.com March, 2003

  2. Introduction • The Mobile Messaging experience differs from current Internet Email experience • Mobile user expects “push model” of message delivery • Devices have limited (and varied) media rendering capabilities • Many mobile networks are bandwidth starved and “unreliable”. • Multiple solutions have appeared • New protocols are being invented • Interoperability is a challenge • Internet Email protocols should be enhanced • to support mobile messaging requirements • meet the needs of mobile users

  3. Mobile Message Flow (1) Submit msg (5) Alert User (2) Notification Mobile Client Server Mobile Client (3) Retrieval request (4) Retrieval request • Current mobile messaging practices analyzed in • draft-stebrose-lemonade-mmsarch-00.txt • Mobile messaging and desktop messaging experience have many • similarities and a number of key differences • Push model using active notification

  4. Mobile Messaging Requirements 1 • “Push” Delivery model • enabling messages to "just show up" on the device, • Flexible addressing • RFC2822, E.164, and "short codes" addressing • MIME-based encapsulation: • Large, multimedia message support • End-to-end Delivery Reports and Read Reports • Content adaptation: • Smart network model: • Client capabilities and profile discovery by the server • Automatic content adaptation upon retrieval • Smart client model: • Client-directed message content type retrieval • Client-directed content adaptation and retrieval • Device-independent presentation language • enable uniform presentation for both mobile and fixed-line clients

  5. Mobile Messaging Requirements 2 • Notifications filter • User configurable • Server-based filtering • SPAM control even more critical than for e-mail • Message exchange with existing Internet email systems • Mailbox support (network-based persistent storage) • Network-based and/or application-based authentication • Bandwidth saving features such as: • binary transfers • data compression • forward without download • streamlined client- server message submission and retrieval • pipelining to reduce transaction counts and RTT latencies

  6. What’s all the fuss about, can’t we already do this? • Not today – Internet messaging needs some enhancements and adjustments • Internet Mobile Messaging Requirements: • email + notification + content adaptation • gets us most of the way there • Solutions must comply with established Internet Protocol requirements: • end-to-end connectivity • broad applicability • reuse of existing protocols • device and network independence • smart endpoints • service-oriented network functions

  7. How Do We Fill the Gaps • Notification • Some proposals exist, none seem to completely fit the bill • Ideal solution should be applicable to all forms of messaging and content types • LEMONADE needs to work on notification solution • Content Adaptation • Alternatives • Smart client analyzes content and selectively requests adaptation and/or download. eg: IMAP “CHANNEL http:” performs content adaptation based on HTTP Accept and/or USERAGENT • Capabilities exchange and “automatic” network based adaptation • Presentation Languages • Use SMIL/XHTML/XML for both mobile and wireline clients • User Configurable Filters • Use SIEVE (RFC 3028) • Configuration of filters from clients is outside scope of LEMONADE

  8. How Do We Fill the Gaps (continued) • Payload compression • Use IMAP Binary to avoid base64 expansion • compression best handled at network layers • Forward Without Download • SMTP or IMAP APPEND “Outbox” with IMAP URL in MIME part: • Content-type: Message/External-body, • access-type=URL; URL=“IMAP: …” • Streamlined Submission and Retrieval • Proposal made in 3GPP2: • X.P0016-311 MMS MM1 using M-IMAP • Features: • Manage submissions & retrievals over one connection to one server • Basically IMAP with these enhancements: • Pipelining (avoiding unnecessary transactions and RTT latencies) • Brevity (omission of unneeded response text) • DELIVER extension command (for submission & forwarding)

  9. Proposal for Internet Standards Based Mobile Messaging (1) Submit msg (SMTP) (2) Notification (???) Mobile Client SMTP/ IMAP4 Server Mobile Client (3) Retrieval request (IMAP) (4) Retrieval request (IMAP)

  10. Conclusion Internet Messaging Protocols should be improved to fulfill mobile messaging requirements. Why? Avoid creating new messaging protocols and reuse existing enhanced messaging protocols with enhancements Simplify Internet email interworking and avoid messaging gateways Reinforce basic IP end-to-end application architecture Changes are required to “mobilize” Internet email Push based notification Content adaptation Forwarding (without downloading) Presentation language This presentation proposes potential solutions that LEMONADE should consider

More Related