"Lemonade Notifications Architecture", Randall Gellens, Stephane Maes, 8-Jul-08. ( bytes)

This document discusses how to provide notification and filtering mechanisms to mail stores to meet Lemonade goals. This document also discusses the use of server to server notifications, and how server to server notifications fit into an architecture which provides server to client notifications. Gellens [page 1] Expires January 2009 Internet Draft Lemonade Notifications Architecture July 2008

"The Lemonade Profile", Dave Cridland, Alexey Melnikov, Stephane Maes, 30-Sep-08. ( bytes)

This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon several extensions to IMAP and Mail Submission protocols.

"Internet Message Store Events", Randall Gellens, Chris Newman, 2-Nov-08. ( bytes)

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. This document describes events and event parameters which are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP.

"Streaming Internet Messaging Attachments", Neil Cook, 26-Sep-08. ( bytes)

This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022).

"IMAP4 extension for named searches (filters)", Alexey Melnikov, Curtis King, 22-Sep-08. ( bytes)

The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criteria as a parameter.

"The IMAP NOTIFY Extension", Arnt Gulbrandsen, Alexey Melnikov, Curtis King, 19-Aug-08. ( bytes)

This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. [[Add Updates: RFC-CONTEXT to the headers]]

"LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail", Eric Burger, Glenn Parsons, 3-Nov-08. ( bytes)

This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) work group in the IETF. This document also describes how the LEMONADE architecture meets the OMA's requirements for their Mobile Email (MEM) service.

"Extended URLFETCH for binary and converted parts", Dave Cridland, 4-Sep-08. ( bytes)

The URLFETCH command defined as part of URLAUTH provides a mechanism for third-parties to gain access to data held within messages in a user's private store, however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications.

"IMAP4 Extensions for Quick Mailbox Resynchronization", Alexey Melnikov, Dave Cridland, Corby Wilson, 19-Oct-08. ( bytes)

This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged).

Return to Internet-Draft directory.

Return to IETF home page.