Transcript Internet Standards Based Mobile Messaging

Internet Standards Based
Mobile Messaging
[email protected]
[email protected]
March, 2003
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
Openwave Systems
Internet Standards Based Mobile Messaging
Mobile Message Flow
Mobile
Client
(1)
Submit msg
(2)
Notification
Server
(5)
Mobile
Alert User
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
Openwave Systems
Internet Standards Based Mobile Messaging
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
Openwave Systems
Internet Standards Based Mobile Messaging
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
Openwave Systems
Internet Standards Based Mobile Messaging
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
Openwave Systems
Internet Standards Based Mobile Messaging
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
1. 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
2. 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
Openwave Systems
Internet Standards Based Mobile Messaging
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)
•
•
Openwave Systems
Brevity (omission of unneeded response text)
DELIVER extension command (for submission & forwarding)
Internet Standards Based Mobile Messaging
Proposal for Internet Standards Based Mobile Messaging
Mobile
Client
(1)
Submit msg
(SMTP)
(2)
Notification
(???)
Mobile
Client
SMTP/
(3)
IMAP4 Retrieval request
Server
(IMAP)
(4)
Retrieval request
(IMAP)
Feature
Submission (1)
Notification (2)
Suggested Protocol
SMTP or IMAP APPEND “Outbox”
push delivery + URI
Retrieval (3) (4)
Forwarding
Addressing
Notification filters
Content adaptation
IMAP FETCH [BINARY] or IMAP Channel:http
SMTP or IMAP APPEND “Outbox” w/IMAP URL
RFC2822, E.164 & RFC2916
SIEVE RFC3028
IMAP Channel http:
Openwave Systems
Internet Standards Based Mobile Messaging
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
Openwave Systems
Internet Standards Based Mobile Messaging