Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

IETF and OMA Architectures for Mobile Email

Purpose

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.

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.

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.