Use of EMSD for Mail Notification
Use of EMSD for Mail Notification
Mohsen Banan
http://mohsen.banan.1.byname.net/ContactMe
September 10, 2001
Copyright ©2001 Mohsen Banan
copies of this manual provided the copyright notice and
this permission notice are preserved on all copies.
A Component of The LEAP Manifesto
This article is one of a series of articles describing various aspects of the Mobile Messaging industry and the Lightweight &
Efficient Application Protocols (LEAP) protocols. For the complete collection of articles see The LEAP Manifesto [5], available
at
http://www.LeapForum.org/LEAP/Manifesto/roadMap/index.html. The LEAP Manifesto is also available at the Free
Protocols Foundation website at
http://www.FreeProtocols.org/LEAP/Manifesto/roadMap/index.html.
Contents
1.1 Intended Audience
2 The EMSD Protocol
3 Mail Notification
3.1 Mail Notification Implementation Model
3.2 Mail Notification in Mobile Environments
4 Development Framework and Resources
4.1 Open-Source Software Availability
List of Figures
1 Introduction
In this article we will make the case that there is a general need within the Mobile Messaging industry for a Mail Notification functionality, which would provide the user with immediate notification of the arrival of certain types of messages in the user’s back-end Message Center. We will then describe how the required Mail Notification functionality can be implemented, based entirely on existing open protocols and technologies.
As we describe in Section 4, the proposed Mail Notification model is supported by a comprehensive set of development tools and resources. In particular, free open-source software implementations of the underlying LEAP protocols are immediately available for a wide variety of Message Center and Mail User Agent platforms. All this software is readily available at the MailMeAnywhere open-source software distribution center at http://www.MailMeAnywhere.org.
The model we describe in this article is thus not merely theoretical, but can be implemented immediately and without difficulty using existing software components.
1.1 Intended Audience
This article is directed towards Internet protocol engineers – it describes the Mail Notification model in technical engineering terms.
For a description of an implementation of this model in a specific context, see the Manifesto article WhiteBerry and Bluetooth [?]. That article may be considered a sister article to this one – while this article is directed towards an engineering audience, WhiteBerry and Bluetooth is directed towards a business development audience.
2 The EMSD Protocol
The Mail Notification model is based on the the Efficient Mail Submission & Delivery protocol, or EMSD [1], [2]. EMSD is a member of a broader family of high-performance, efficient protocols called the Lightweight & Efficient Application Protocols, or LEAP. For more information about the LEAP protocols in general see the LEAP Forum website at http://www.LeapForum.org.
EMSD is a messaging protocol that has been designed with a major emphasis on efficiency. In addition, EMSD fully supports the push mode of delivery, in which messages are delivered directly to the Mail User Agent, without requiring an explicit retrieval action by the user.
In common with other LEAP protocols, EMSD is truly open, RFC published, and patent-free; and declarations regarding the patent-free nature of EMSD have been made to the Free Protocols Foundation. For complete details see the LEAP Manifesto article EMSD: The LEAP E-Mail Component [2], or visit the EMSD website at http://www.EMSD.org.
EMSD has been designed to complement the existing Internet protocol framework in a variety of ways. In addition to the Mail Notification model described in this paper, EMSD is also the basis of an open Mobile Messaging model. This model is described in detail in another Manifesto article entitled Operation WhiteBerry [3].
3 Mail Notification
A basic shortcoming of conventional e-mail protocols such as IMAP (Internet Message Access Protocol) [4] is that they do not support the push mode of message delivery. Instead, the user must initiate an explicit pull action to retrieve new messages from the Message Center.
As noted above, EMSD fully supports the push mode of delivery, and therefore properly addresses this shortcoming. Also as noted above, EMSD is a highly efficient messaging protocol. Specifically, it is optimized for the efficient delivery of “short” Internet e-mail messages – meaning text messages up to approximately 4 kbytes in length.
Though the great majority of daily e-mail messages fall within this category, there is no inherent upper limit to the size of e-mail messages. Any given e-mail can be extremely large, particulary if large attachment files are included with the message. The efficiency characteristics of EMSD do not extend to long messages; and in terms of efficiency, IMAP (because of TCP[6], sliding windows etc.) is more suitable for long messages than EMSD.
Thus we see that in the case of long messages, there is a functional lacuna in the existing e-mail protocol framework. EMSD can push the message to the recipient but cannot deliver it efficiently; while IMAP can deliver the message efficiently, but cannot push it to the recipient.
This deficiency is particularly problematic in the Mobile Messaging arena, which has inherent requirements for both urgent push-mode and efficient delivery. Immediate delivery of time-critical messages is an essential requirement of the mobile user; while the constraints of wireless networks and miniaturized mobile devices demand highly efficient transfer of data.
The ideal solution to this would be a protocol which is suitable for long messages and which also supports the push mode of delivery, but no such protocol exists at present. In its absence, the delivery of long messages can be greatly enhanced by means of a Mail Notification service, which would alert the user to the arrival of the message at the Message Center.
As we will see below, such a service can readily be implemented based on EMSD. Used in conjunction with a suitable message delivery protocol such as IMAP, this can greatly improve the timeliness of delivery of long messages.
3.1 Mail Notification Implementation Model
The Mail Notification implementation model is shown in Figure 1.
In the case of short messages, EMSD can do it all – it can push the message directly to the recipient, and can do so efficiently. Therefore whenever a short message arrives at the Message Center, it is simply delivered directly to the Mail User Agent via the EMSD protocol. The message is now immediately available to the user, and the Mail User Agent can alert the user to this in any of the usual ways – e.g. by means of a window pop-up, audible alert, or flashing icon.
It is in the case of long messages that a notification mechanism is required. If a long message arrives at the Message Center, then the EMSD protocol is used to send a Mail Notification to the Mail User Agent. This could take the form of a generic notification flag, simply reporting the arrival of a long message at the Message Center; alternatively the notification could take the form of a message digest for perusal by the user. In the former case the Message Center requires an appropriate Mail Notification Send function, and the Mail User Agent requires a complementary Mail Notification Receive function, as shown in Figure 1.
The Mail User Agent can respond to the notification in either of two basic ways:
- Receipt of the notification can trigger automatic retrieval of the message by the Mail User Agent.
- The Mail User Agent can merely alert the user to the availability of the long message at the Message Center; it is then the responsibility of the user to retrieve the message at his discretion, either sight unseen (in the case of a generic notification), or on the basis of the message digest.
In either case, retrieval of the long message takes place via IMAP, or other appropriate long-message protocol.
The first mode of operation is most appropriate for a desktop messaging environment, which can readily accept delivery of messages of arbitrary size, so that the user need not be involved in the delivery process. Note that in this mode of operation, the combination of Mail Notification via EMSD and message retrieval via IMAP is functionally equivalent to true push mode delivery for long messages.
In the case of a mobile messaging environment, automatic delivery of a long message to a limited-capability mobile device may not be appropriate; and in this case the second option may be more appropriate. This operational model could be described as a “push-assisted” mode of operation – i.e. the notification is pushed to the user, but the user must then pull the message itself.
Note that the implementation of Figure 1 is based entirely on readily available, open and free protocols; specifically EMSD, IMAP and TCP/IP. Layer 7 communications takes place via EMSD and IMAP; while communications at Layer 3 takes place via IP.
The integration requirements for the implementation of Figure 1 are particularly simple. Those components which require integration are shown shaded in the figure; all unshaded components are already commonly integrated in modern Message Centers and Mail User Agents.
This implementation thus requires only that the Message Center be equipped with the EMSD Server Agent protocol engine and a suitable Mail Notification Send function; and that the Mail User Agent be equipped with the EMSD User Agent protocol engine and a Mail Notification Receive function. The EMSD and IMAP protocol engines must also be properly integrated with the User Message Alert function of the Mail User Agent.
As described below, open-source and free software for both the EMSD and IMAP protocol engines is readily available.
3.2 Mail Notification in Mobile Environments
The Mail Notification model is particularly advantageous in the Mobile Messaging environment, where long messages cannot be handled in a wholly satisfactory way be either EMSD or IMAP.
The general model of Figure 1 translates fully into the mobile domain, in which the Mail User Agent takes the form of a miniature handheld device such as a cell phone or PDA. There are however, some additional considerations in the case of mobile devices.
The mobile device may be turned on or off as desired by the user. However the wireless modem component of the device will normally remain on at all times, so that the device can accept incoming messages at any time, and at any point within the network coverage area.
Whenever a short message arrives at the Message Center, it is delivered directly to the mobile device via the EMSD protocol. If the device is off, the push mode delivery causes it to wake up automatically, so that the message is now immediately available to the user. The device can then alert the user to this in any of the usual ways for mobile devices, i.e. by means of an audible (beep, buzz, ring) visual (flash) or tactile (vibration) indication.
Whenever a long message arrives at the Message Center, a notification of this is sent to the mobile device via the EMSD protocol. Again, if the device is off, the push mode delivery of the notification causes it to wake up and alert the user to the availability of the long message at the Message Center.
The user can then retrieve the message at his discretion, either sight unseen (in the case of a generic notification), or on the basis of the message digest. Retrieval of the long message takes place via IMAP or other appropriate protocol. Automatic retrieval of the long message will not normally be an appropriate mode of operation for miniaturized mobile devices.
The integration requirements for mobile devices are the similar to those of generic Mail User Agents, except that the Mail Notification Receive function may be considered to be optional, since this is not required if the notification takes the form of a message digest.
As in the case of generic Mail User Agents, IMAP is also becoming the norm on PDAs and other mobile devices. IMAP Client software is becoming increasingly widespread on devices, for example to support e-mail synchronization of the device with a desktop mailbox application.
In terms of integration, therefore, the mobile device requires only an EMSD User Agent protocol engine and (optionally) a Mail Notification Receive function. The EMSD and IMAP protocol engines must also be properly integrated with the device User Message Alert function.
4 Development Framework and Resources
Those who find the Mail Notification model interesting or compelling are invited to participate in its implementation and deployment.
The Mail Notification model is part of a more general industry effort which we call Operation WhiteBerry. A detailed
description of Operation WhiteBerry is provided in the Manifesto article Operation WhiteBerry [3]. This article is available on
the LEAP Forum website at
http://www.LeapForum.org/operationWhiteberry/index.html, and also on the Free Protocols Website at
http://www.freeprotocols.org/operationWhiteberry/index.html.
A comprehensive development framework exists to assist organizations and individuals who wish to participate in Operation WhiteBerry in general, or the Mail Notification model in particular. This framework provides a complete set of development resources, including:
- The MailMeAnywhere open-source software distribution center and development forum at
http://www.MailMeAnywhere.org. - The LEAP Forum at http://www.LeapForum.org
- The EMSD Organization at http://www.EMSD.org
Each of these forums hosts several mailing lists which facilitate various forms of participation. MailMeAnywhere hosts a public forum for the collective development and enhancement of LEAP protocol engines and integration tools, while EMSD.org is a development forum for the EMSD protocol.
LeapForum.org is oriented towards coordinating usage of the LEAP protocols from a business development perspective; it provides a means for organizations and individuals to announce their participation in Operation WhiteBerry, seek out partners, and coordinate cooperative effort.
The EMSD User Agent source code is readily available at http://www.MailMeAnywhere.org. Alternative versions of the IMAP Server Agent software are available in source form from both the University of Washington and Carnegie-Mellon University; both versions are also readily available at http://www.MailMeAnywhere.org.
4.1 Open-Source Software Availability
Both the EMSD and IMAP software is freely available in source code form. In particular, the EMSD software is available under the terms of the GNU General Public License (GPL). The GPL places no restrictions on use of the software for development and proof-of-concept purposes.
However the GPL places certain restrictions on commercial usage of the software, and such usage may be in violation of the GPL. Device manufacturers are advised that they may need to purchase professional license agreements in order to make use of the EMSD and IMAP protocol engines in commercial contexts.
References
[1] M. Banan. Neda’s Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3. RFC 2524 (Informational), February 1999.
[2] Mohsen Banan. EMSD: The LEAP E-mail Component. A component of LEAP Manifesto, LEAP Forum, January 2000. Online document is available at http://www.LEAPForum.org/leap.
[3] Mohsen Banan. Operation WhiteBerry. A component of LEAP Manifesto, LEAP Forum, January 2000. Online document is available at http://www.LEAPForum.org/operationWhiteberry/index.html.
[4] M. Crispin. Internet Message Access Protocol - Version 4rev1. RFC 2060 (Proposed Standard), December 1996. Obsoleted by RFC 3501.
[5] Mohsen Banan. Lightweight & Efficient Application Protocol (LEAP) Manifesto. Technical Report 108-101-01, LEAP Forum, Bellevue, WA, January 2000. Online document is available at http://www.leapforum.org/LEAP/Manifesto/completeManifesto.
[6] J. Postel. Transmission Control Protocol. RFC 793 (Standard), September 1981. Updated by RFCs 1122, 3168.