Summary

The IETF (Internet Engineering Task Force) and OMA (Open Mobile Alliance) both have architectures to support mobile email. This white paper looks at the differences between these architectures, and considers technical and commercial implications of the differences. Particular consideration is given to the role of service providers.

Creative Commons License

The IETF Architecture

The IETF architecture for client access to electronic mail services is a simple one:

For normal email services, two protocols will be used:

  1. A message submission protocol, to allow the email client to submit (send) messages. This protocol is based on the Simple Message Transfer Protocol (SMTP).
  2. A protocol to access and retrieve messages. There are two protocols that may be used for this purpose.
    • Post Office Protocol (POP), which allows for simple message retrieval.
    • Internet Message Access Protocol (IMAP) which provides more sophisticated message retrieval, and the ability to access messages which remain on the server.

Internet mobile email uses the same architecture, and the standard email protocols can be used. The IETF is defining extensions to IMAP and SMTP, to optimize these protocols for mobile messaging. These extensions and the core protocols are known as "LEMONADE". Note that LEMONADE uses IMAP (and not POP), as this gives significant advantages for a mobile email client. LEMONADE is discussed in the Isode Whitepaper [Open Standards: The best approach to mobile messaging].

The OMA Architecture

The OMA has a more complex architecture. There is an entity known as the Mobile Email Enabler (MEE), which supports two protocols:

  1. "Server Email Protocols" by which the MEE accesses an end email service. The definition of these protocols is out of OMA scope.
  2. "Mobile Email Protocols" which are used by the Mobile Email Client to access the MEE. The OMA MEM (Mobile Email) group is seeking to specify mobile email protocol standards for the mobile industry.

OMA have defined a set of requirements for Mobile Email Protocols, and are considering two open standard approaches to realize these requirements:

  1. Use the LEMONADE protocols from the IETF, and set a profile of the LEMONADE specifications as an OMA standard. The IETF LEMONADE group is working with the OMA, and seeking to address the OMA requirements as a part of the LEMONADE specifications.
  2. Use the SyncML DS, data synchronization protocols. SyncML is a data synchronization standard, which is now managed by OMA. It is widely used in mobile telephones. A new version is planned, which is intended to address the OMA requirements.

The rest of this paper does not make any assumption on OMA decision to use one or both of these options. It shows the implications of both choices on options available to operators.

Isode's view on the choice is clear. LEMONADE is a technically appropriate solution, which will work well. SycncML DS is an excellent open standards approach for synchronizing address books and calendars between mobile devices and servers. While synchronization using SyncML DS can be used to submit and access email, it seems an awkward and potentially inefficient approach. It is difficult to see how it could effectively address the OMA requirements.

Comparison of IETF and OMA Architectures

The difference is simple: OMA uses an MEE and the IETF does not. It will become clear from the analysis below that there are many practical situations where an MEE is an operational necessity. The IETF tends to define "pure" architectures, and then defines protocols in the context of these architectures. Other applications of the protocols are generally considered to be out of scope. While the MEE may be "out of scope" for the IETF open standards architecture, it is a concept that has important operational value in many situations, and it is very sensible that the OMA have it as a part of their architecture.

Realization of the OMA Architecture

We now look at a number of protocol combinations that could be made in deploying an MEE. These choices will make clear the benefits of an MEE.

Mobile Email Protocols Server Email Protocols Notes
RIM "Blackberry" proprietary protocols Microsoft Exchange proprietary protocols This combination is widely deployed today in support of mobile email. Both protocols are proprietary.
LEMONADE Lotus Notes proprietary message protocols This combination shows that, assuming OMA adopt LEMONADE as the protocol of choice, that an MEE will be necessary to access proprietary email servers.
LEMONADE POP/SMTP Where LEMONADE is used for the mobile email protocol, an MEE can still add value to access Internet Standards conformant mail servers. With this combination, a LEMONADE device may not be able to access the email server directly (e.g., because the device does not support POP) or there would be a significant loss of efficiency without the MEE, as the server lacks LEMONADE optimizations. In this scenario, the MEE will add significant customer value, and will be important for supporting mobile customers using older mailbox services.
LEMONADE LEMONADE

This combination shows that in some situations, the MEE will be redundant, and it may be preferable to allow direct access from the mobile client to the email server without use of an MEE.

There are situations where use of an MEE for this combination can add value. For example, if the MEE is close to a slow high latency link to the mobile device, it will be able to optimize link performance more easily than the mail server which is directly connected to a high bandwidth service.

SyncML DS Any of the Above This combination shows that if SyncML DS is uses as the mobile access protocol, that an MEE will be needed to access most mail servers.

Service Provider Roles

Potential Roles of the Mobile Operators

In terms of providing a solution according to the OMA architecture, a mobile service provider has three potential roles.

  1. Providing the underlying network connectivity (typically IP over a wide choice of underlying services) between the mobile email device and the MEE. Providing this connectivity is fundamental to the business of a mobile operator, and this will always be provided.
  2. Operating the MEE. The mobile operator has two basic (non-exclusive) strategies:
    • Operate the MEE. This reflects a strategy of mobile email being a core value added service, which should be provided as a service by the operator to its customers.
    • Work with service provider partners to provide MEE services. This reflects a strategy that the core business of the operator is connectivity, and that it should enable choice and flexibility in value added services by working with a range of partners.

    Both approaches and strategies appear to be viable commercial options.

  3. Providing the end email services (mailbox and messaging services to the customer). The operator may also provide the end email service. This would make sense in several situations:
    • Where the mobile operator is also a general purpose Internet Service Provider, and offers mailbox services as a part of this offering. In this case, it make sense to integrate this as a part of the mobile offering.
    • To offer a complete mobile email service to customers, which would be of particular benefit to those who use mobile email as their exclusive email service.

    Where the MEE and email service are provided by the same organization, the IETF architecture, giving direct access from mobile email client to the email service simplifies the overall configuration, and may be preferable.

MEE Operator

The first and third roles above are well understood. This section considers the role of MEE operator, and which organizations may provide it. The MEE is providing an email level conversion between the email protocols supported on the mobile client and the email protocols supported on the server with the user's mailbox.

  1. Mobile operator. The mobile operator is in a natural position to provide an MEE. It can control the choice of protocols on the handset, and offer email access to a choice of mailbox services, enabling support of both consumers and corporate customers.
  2. Independent Service Provider. The MEE could also be operated by an independent service provider that may have a commercial arrangement with the mobile operator. From the viewpoint of the mobile operator, this service provider offers a value added service to its customers. Multiple service providers could be used, perhaps supporting different mobile email protocols.
  3. Enterprise or ISP. The mailbox provider could offer the MEE. In this model the MEE is being used as a value added service to the existing mailboxes, and the mobile operator is providing connectivity. There are two implementation models.
    • The enterprise using mailbox software that directly supports the mobile email protocols (IETF Model).
    • The enterprise deploying an MEE in front of its existing mailbox service.
  4. Email ASP or outsourcing organization. This is a variant on 3, where the MEE is operated by the same external organization that operates the mailbox service for the enterprise.

Benefits of Combining IETF and OMA Architectures

An important observation of the analysis of this paper is that both the IETF and OMA models can in some situations be useful and appropriate. It would seem sensible that both models evolve in tandem. Specific recommendations:

  1. The IETF should recognize in its model that an MEE can sit between the email servers and the client, as an extension to the core IETF model.
  2. The OMA should recognize that in some situations the mobile email client can communicate directly to the email server. This might be formulated as a configuration option, such that the MEE and mailbox service are the same entity.

Conclusions

This paper has explained the difference between the IETF and OMA models, and recommends that convergence would be useful.