Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
Creative Commons
Isode's whitepapers are licenced under a Creative
Commons Licence.
22nd May 2005
Why Open Standards for Mobile Messaging?
There is a clear requirement and growing demand for mobile messaging. Forrester Research estimates that the market for mobile messaging in Europe alone will grow by 92% over the next 5 years and the evidence provided by our own experiences (observing users of laptops, blackberries and other devices in airports, on trains and in many other places) supports the assumption that this is a market undergoing dramatic change.
However, in many cases the mobile messaging experience relies on proprietary protocols to connect the mobile user’s email device over a wireless link, the proprietary Blackberry devices being just one example.
Isode believes that an open standards approach is better, for two fundamental reasons:
- Device independence: The user is not constrained in the choice of device used to access the email service. This gives choice of mobile devices, and should also allow non-mobile devices to use the same service.
- Service independence: The owner of a specific device can move easily between different email service providers.
The practical benefits of these two reasons to the end user are increased flexibility and lower cost. The service provider benefits by being able to switch between open standards based solutions as their business model demands as well as the usual lower staff/skills costs associated with open standards solutions compared to their proprietary rivals.
To achieve these benefits, it is important that the open standards can deliver a mobile service that is as good as or better than the service that can be provided using proprietary protocols. This paper looks at these requirements, and shows how a technically robust and commercially viable service can be achieved with open standards.
| Evaluate Today |
|---|
Isode's M-Box is the core of Isode's Internet Messaging Solution, supporting the new IETF Open Standards for mobile messaging. You can evaluate M-Box today, click here for more details. |
Core Open Standards for Mobile Messaging
There is a core set of open standards, which can support mobile messaging. The two protocols central to this are:
- SMTP (Simple Message Transfer Protocol): This is the Internet Standard for moving messages, and is used by a mobile device to submit messages to a server.
- IMAP (Internet Message Access Protocol): This is an Internet Standard for an email client to access messages on a server. A key characteristic of IMAP is that the messages may remain on the server until the user explicitly deletes them, allowing multiple clients to access the same mailbox. This is important for mobile access, as it allows network access to be optimized and can support small devices such as mobile phones, which are not suitable for long term, message storage.
Both SMTP and IMAP run over the core TCP protocol used by most Internet applications. SMTP and IMAP are widely supported by mobile devices. SMTP is supported by most (open standards based) email service providers. IMAP is sometimes supported, but in many cases service providers offer only the simpler POP (Post Office Protocol).
POP is not a good choice for mobile devices as it was primarily designed to allow users to retrieve email when connected, and then handle those messages offline. Email clients using POP usually connect to retrieve all messages from the server (deleting from the server in the process) and store those messages on the accessing device. POP assumes bandwidth availability and storage capability not usual on mobile devices as well as assuming that messages will be accessed from only one client.
There are two key supporting standards, which are desirable to provide improved security:
- SASL (Simple Authentication and Security Layer) is used with both SMTP and IMAP to provide flexible client authentication.
- TLS (Transport Layer Security) is used with SMTP and IMAP to provide data confidentiality.
Why SMTP and IMAP are not enough
The SMTP and IMAP protocols provide a viable solution for mobile email. However, a typical open standards mobile client implementation is not as good as a Blackberry-type service for a combination of three reasons:
- User Interface Quality: Good email user interfaces need to address many issues, including device form factor and user interaction. For a device and interface to win in the market, it will need considerable attention and effort from the vendor. These issues are not considered here.
- Protocol Implementation: A key constraint in most mobile environments is relatively low connection bandwidth and relatively high connection latency. The underlying SMTP and IMAP protocols need to be used sensibly to optimize for this environment. In many products this is not done well, and in particular message retrieval does not take advantage of IMAP capabilities. This is covered in this paper.
Looking at the better open standards clients, such as Profimail, Chattermail, Polymer and Snappermail, it is quite clear that good GUIs with efficient protocol access are quite viable. There is a good standards framework for doing email today.
LEMONADE
If you examine the protocols in detail, there are desirable optimizations, which cannot be achieved using the current standard protocols. This paper discusses these optimizations, and how these may be achieved using anticipated new standards. These standards are believed to encompass all functionality provided by proprietary systems, and features that go beyond core capabilities.
The IETF (Internet Engineering Task Force) established the LEMONADE ("License to Enhanced Mobile Oriented And Diverse Endpoints") working group to address messaging standard extensions in support of:
- Smart phones
- Set-top boxes
- Other memory/processor limited devices
- Bandwidth/latency challenged networks
This group is working on a number of standards, some of which are complete and others are still work in progress. These extensions provide the necessary functions for optimized open standard mobile messaging.
The LEMONADE work is quite detailed and technical, so this paper does not attempt to review the work from a technology standpoint. Rather, the rest of this paper will look at user functionality, which is not currently well provided for.
Scenarios
When considering functionality from a user perspective, that functionality needs to be expressed in the context of real requirements. Mobile devices vary widely in terms of form factor, storage capabilities and bandwidth, the two scenarios we examine here are quite near the extremes of mobile email.
- Scenario P: A small form factor mobile phone, that is highly portable and would not be used as a primary email storage device. The GUI is likely to be significantly constrained and optimized for the small device form factor.
- Scenario L: A laptop, connected using low or medium bandwidth connectivity (e.g., GSM or GPRS). This may or may not be the primary email storage device, and is likely to use a normal desktop email client, such as Microsoft Outlook.
The following table looks at desirable features from a user perspective. The table indicates which scenarios the feature applies to, and what technology is used to support the feature. IMAP is used for standard IMAP functions which are gerally available in IMAP client and server products. 'Lemonade' refers to new IMAP work being developed, which is generally associated with the Lemaonde working group.
| Feature | Scenario(s) | Technology | Importance to User |
|---|---|---|---|
| Message listing without download | P,L | IMAP | Messages may be large, so it is important
for the user to be able to examine messages before deciding
to download. The client interface should help the user to use the network efficiently. |
| Access key information from message | P,L | IMAP | Internet messages have a structure that may
be accessed by IMAP. A common structure is a short text body
part and a then a larger body part (attachment). The text body
part will often be a summary of the larger body part, and so
to makes sense to download this body part to help the user make
a decision on whether or not to download the larger body part. |
| Background download | (P),L | Client implentation | If the user decides to download (or submit) a large message (or body part), it is desirable that this happens in background and does not block other local or network activity from the client. – This should not impact other requests made by the user (most email clients do not behave in this manner). |
| Forward without download | P,L | Lemonade | If a (large) message is received, it is useful to be able to forward the message to another account or person without having to download the message to the mobile device. |
| Search without download or list, server side message filtering | P,L | IMAP | Many clients only allow searching of local messages. Many clients automatically list messages when selecting a folder, which can be very slow for a large folder. By searching on the server, a specific message can be found efficiently. |
| Search Very Large Folders | P,L | Lemonade | The new IMAP ESEARCH Function provides optimizations to enable efficient searching of very large folders. |
| Optimize for high latency | P,L | SMTP/IMAP (Pipelining) | Internet protocols are command/response. Where a network has high latency, this can slow communications. Pipelining is where the client does not wait for an answer from one command before submitting the next one. This is good for high latency networks. |
| Basic Message Alert | P,L | IMAP | Basic message alerts can be provided by the IMAP IDLE command. |
| Advanced Message alert | P,L | Lemonade | Lemonade provides a mechanism for the user to be alerted when new messages arrive, without needing to poll the server (the CLEARIDLE mechanism) and for out of band alert mechanisms suitable for low volume mailboxes, which may use a choice of transports such as SMS and SIP. |
| Don't synchronise (unless you need to) | L | Client implementation | Some email clients perform complex server synchronization which can need significant network resource (Microsoft Outlook does this). This should be avoided in a mobile environment. |
| Fast startup and optimization for broken network connections | P,L | Lemonade | In many mobile situations (e.g., a train journey), the underlying connection will be broken and re-established. Standard IMAP has a quite resource intensive start-up. Lemonade provides quick reconnect mechanism to avoid this based on the IMAP CONDSTORE features that enable fast resynchronisation. This also improves startup performance for all connections. |
| Play voicemail on a phone | P | Lemonade | If a message is received with a voice or music attachment, it is generally inefficient to download this by email. A better approach is to have the message streamed to the client. |
| Attachment conversion and compression | (P), L | Lemonade | If a large attachment is received, it may be useful to download a smaller version (e.g., a JPEG photo with reduced resolution). |
Conclusion
With the demand for mobile access to messages of all types on the rise and the richness and complexity of messages on the increase there is clearly a need for service provider solutions that recognize the reality of limited storage and low bandwidth. Whilst bandwidth on and (especially) storage for mobile devices will continue to increase, it is probably true to say that the bandwidth we need today is always going to be available tomorrow.
IMAP and SMTP are the key standards to address the continuing problems being faced by an increasingly mobile population and workforce who are demanding efficient email access on the move. By adopting an Open Standards approach service providers are insuring against the possibility of finding themselves locked in to a proprietary cul-de-sac.
LEMONADE is a new set of standard, providing IMAP and SMTP optimizations
that will provide useful benefit to a second generation of open standards
based mobile clients.
