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

Whitepapers

LEMONADE Profile: The Key Standard for Mobile Messaging

8th June 2006

Purpose

LEMONADE is the Internet Engineering Task Force (IETF) technology being standardized for support of Mobile Email. The LEMONADE Profile was published as an Internet Standard (RFC 4550) in June 2006. This paper explains what the LEMONADE Profile is about and why it will be the central specification for open standards mobile messaging.

How Internet Standards Work

Internet Standards are based around documents confusingly called RFCs (Request For Comments). RFCs are numbered, and most of them have a short title which is used by aficionados to refer to them concisely. The title is important, because when an RFC is updated, the new version will be issued with a new number, but the title will remain the same. The two most important Email standards for mobile messaging are:

• SMTP:"Simple Mail Transfer Protocol" (RFC 2821).
• IMAP:"IMAP4, Internet Message Access Protocol Version 4 rev 1" (RFC 3501).

This style will be used to refer to RFCs throughout this white paper.

An IETF goal for Internet standardization is to avoid optional features – if you implement a standard, you should do all of it. A consequence of this is that functionality that goes beyond the core is generally specified in a new RFC, so that new features appear in new RFCs rather than in updates to existing ones.

The LEMONADE Working Group

The LEMONADE (License to Enhanced Mobile Oriented And Diverse Endpoints) working group was set up to extend the core Internet messaging standards mentioned above to support mobile devices and communications over "bandwidth and latency challenged networks". LEMONADE has active participation from a wide range of companies, including: Cantata; Cingular, Comverse, Isode, Lucent, Nokia, Nortel, Oracle, Qualcomm, Sprint and Sun.

Although the core IMAP and SMTP standards can work well for mobile messaging, a number of improvements are possible. These have resulted in a number of new RFCs as output of the work of the LEMONADE working group to meet its technical objectives.

The LEMONADE Profile

Internet messaging standardization, including LEMONADE, has produced a plethora of RFCs related to SMTP and IMAP. To achieve a given goal, you need to select which set of RFCs are applicable, which is often not an easy task. It also makes procurement complex, as there is no single reference that can be used to clearly specify what is needed.

To address this, the LEMONADE WG has specified the "LEMONADE Profile", which will also be published as an RFC. The Profile is essentially a set of RFCs, with some overall technical description. The LEMONADE Profile is therefore a single and simple specification of the set of Internet Standards needed to support mobile messaging.

The LEMONADE Profile was approved for publication in February 2006 and published as an Internet Standard in June 2006.

User Benefits

From the user’s perspective the most obvious benefit of LEMONADE is speed resulting from efficient use of available bandwidth. This allows for a better user experience and also, in situations where charges are applied on the basis of bandwidth usage, reduced costs.

In some areas, such as forwarding a message without downloading it to the handset, LEMONADE allows for the efficient provision of functionality that would otherwise be prohibitively expensive.

The Component Standards

The rest of this document gives a brief summary of the RFCs that comprise the LEMONADE Profile, giving a short and high level summary of each one. Those interested in more technical detail should review the Profile and the documents that it references.

IMAP Support in the SMTP Server

SMTP is a protocol for message submission (and transfer). IMAP is a protocol for access to stored message. Some functionality for mobile messaging requires the ability for messages being submitted to incorporate stored messages, in order to optimize network usage. In particular:

• Forward without download, where a received message is sent onwards, without download to the client.
• Incorporating documents (attachments) from stored messages in a new message.
• Managing and sending draft messages stored on the server.

This is achieved by having the SMTP server access the IMAP server, so that data does not have to go through the client. A number of the RFCs listed below are in support of this functionality.

IMAP Component Standards

The following IMAP related RFCs are included in the LEMONADE Profile:

RFC	Explanation
NAMESPACE. "IMAP4 Namespace" (RFC 2342)	This helps a client determine information on mailbox configuration, and reduces the need for manual client configuration.
CONDSTORE. "IMAP Extension for Conditional STORE operation or quick flag changes resynchronization" (RFC 4551)	When an IMAP client disconnects and subsequently reconnects, it needs to determine if any changes have been made to the any mailbox. CONDSTORE provides additional information with each message, to make this process much more efficient and reduce network traffic.
URLAUTH. "Internet Message Access Protocol (IMAP) – URLAUTH Extension" (RFC 4467)	URLAUTH enables the client to request a special token from the IMAP server granting temporary access to all or part of a stored message. The client can then pass this token to the SMTP server, which will use it to access the IMAP server in support of forward without download and related services.
CATENATE. "Internet Message Access Protocol (IMAP) CATENATE Extension" (RFC 4469)	CATENATE allows an IMAP client to build messages on the server using parts of existing messages along with new data.
UIDPLUS. "UIDPLUS" (RFC 2359)	Extends IMAP with some additional commands which reduces overall network traffic.
LITERAL+. "IMAP4 non-synchronizing literals" (RFC 2088)	A protocol enhancement to reduce number of round trip times that will improve performance, particularly on high latency links.
IDLE. "IMAP4 IDLE command" (RFC 2177)	The IMAP IDLE command provides a very efficient mechanism for an IMAP client to be immediately alerted to new messages. IDLE is used to provide what is commonly called "push email".
"$Forwarded IMAP Keyword". "LEMONADE Profile" (RFC 4550)	This technical specification is included in the profile, and enables clients to mark messages as forwarded (on the server).

 

SMTP Component Standards

The following SMTP related RFCs are included in the LEMONADE Profile:

RFC	Explanation
SUBMIT. "Message Submission for Mail" (RFC 4409)	SMTP is used for message submission and message transfer, and the SMTP specification covers functionality that is common to both. This standard specifies specific SMTP behavior when SMTP is used for submission.
PIPELINING. "SMTP Extension for Command Pipelining" (RFC 2197)	SMTP operates with many commands and responses. PIPELINING enables a client to send commands before getting the previous response, which improves performance on high latency connections and reduces the number of packets.
DSN. "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications" (RFC 3461)	Allows an SMTP client to control requirements for Delivery Status Notifications (Delivery Reports).
SIZE. "SMTP Service Extension for Message Size Declaration" (RFC 1870)	Allows an SMTP server to inform the client of the maximum message size it will accept.
ENHANCEDSTATUSCODES. "SMTP Extension for Returning Enhanced Error Codes" (RFC 2034)	This provides a mechanism for improved error reporting.
STARTTLS. “SMTP Service Extension for Secure SMTP over TLS” (RFC 3207)	This provides data confidentiality using Transport Layer Security (TLS). Note that TLS support is included in the core IMAP standard.
BURL. "Message Submission BURL Extension" (RFC 4468)	BURL is used to include an IMAP URL as defined in URLAUTH with message submission, so that the SMTP server can get data from an IMAP server to fill in this element of the message. This is to support forward without download and related services.
CHUNKING. "SMTP Service Extensions for Transmission of Large and Binary Messages" (RFC 3030)	The CHUNKING capability of RFC 3030 breaks message submission into blocks. This allows use of BURL to insert data into an arbitrary part of a submitted message.
BINARYMIME. "SMTP Service Extensions for Transmission of Large and Binary Messages" (RFC 3030)	The BINARYMIME part of RFC 3030 allows general binary data to be transferred, and thus optimize bandwidth
8BITMIME. "SMTP Service Extension for 8bit MIME Transport" (RFC 1652)	This alternative to BINARYMIME optimizes bandwidth for non-ASCII text messages only.
SMTP AUTH. "SMTP Service Extension for Authentication" (RFC 2554)	This allows message submission to be authenticated. Note that the equivalent service is part of the core IMAP standard.

 

Why LEMONADE Matters

The LEMONADE Profile (It is likely that "LEMONADE" and "LEMONADE Profile" will become synonymous) brings together a collection of open standards which can provide high functionality efficient mobile email. It will enable mobile operators to clearly and simply specify a level of functionality for mobile email provision. It will enable email service providers to offer efficient mobile email access to existing and new customers.

With bandwidth charges forming a large proportion of the cost element of mobile email, lemonade’s focus on optimising bandwidth usage is important for the provision of mobile email not only to handsets but also to other mobile devices commonly used to access email on the move (such as laptops and PDAs equipped with a compatible client). The device independent nature of open standards is particularly important to organisations wishing to provide mobile email access to users through existing devices rather than via the purchase of often expensive additional or replacement mobile units.

Users and potential users of mobile email services gain flexibility and scalability. For small and medium sized business the cost of expanding access to mobile email or adding mobile email access as a capability using proprietary solutions is often cost prohibitive.