2.1.7 Enhancements to Internet email to support diverse service environments (lemonade)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional LEMONADE Web Page

Last Modified: 2005-01-25


Glenn Parsons <gparsons@nortel.com>
Eric Burger <eburger@brooktrout.com>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: lemonade@ietf.org
To Subscribe: lemonade-request@ietf.org
In Body: in boby 'subscribe'
Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html

Description of Working Group:

Lemonade is tasked to provide a set of enhancements and profiles of
Internet email submission, transport, and retrieval protocols to
facilitate operation on platforms with constrained resources, or
communications links with high latency or limited bandwidth. A primary
goal of this work is to ensure that those profiles and enhancements
continue to interoperate with the existing Internet email protocols in
use on the Internet, so that these environments and more traditional
Internet users have access to a seamless service.

Lemonade's work is at the crossroads of a body of work related to
Internet messaging, in particular work done by the VPIM, FAX, and
IMAPEXT IETF working groups. Given the potentially broad scope of
activities this group could engage in, the group will focus
specifically on the following work items:

0. An informational RFC or RFCs will be produced on LEMONADE
architecture and the issues it seeks to address.

1. Enhance the existing IMAP4 message retrieval and message submission
(RFC 2476) protocols to satisfy the requirements for handling
multimedia content. The existing standards-track CONNEG framework will
be used if content negotiation capabilities are needed. The group will
employ existing protocols (such as for streaming) with IMAP4 instead
duplicating such functionality within IMAP4.
2. Enhance the existing IMAP4 message retrieval and/or message
submission (RFC 2476) protocols to satisfy the requirements for
forwarding a message and/or its attachments without downloading
the message to the client and subsequently uploading the message to a

3. Refine the existing IMAP4 message retrieval protocol to facilitate 
its use with devices that have limited capabilities such as mobile   
endpoints. At most one backwards compatible profile of IMAP4 will be 
produced by this effort.

4. Define a format for message notifications for servers reporting   
message status information to other servers. Specify the method for 
delivery of those notifications.

5. Create a specification describing the use of Internet message     
services in environments where message delivery may take place using 
either Internet protocols or through an MMS server using WAP to
communicate with the receiving user agent.

Any protocols defined by this working group will include appopriate
security mechanisms, including authentication, privacy, and access
control. Mandatory-to-implement security mechanisms will be specified
as needed in order to guarantee secure protocol interoperability.

The transport area will be consulted to deal with any transport-related
issues that arise, especially in regards to items 1-4 above.

The IAB is currently working on the specification of general
and requirements for notification services. Once complete this work
will be used as input to item 4 above.

The working group is aware of several related activities in other

- 3GPP TSG T WG2 SWG3 Messaging <http://www.3gpp.org/TB/T/T2/T2.htm>
- W3C Mulitmodal interaction Activity <http://www.w3.org/2002/mmi/>
- Open Mobile Alliance <http://www.openmobilealliance.org/>
- 3GPP2 TSG-X <http://3gpp2.org/Public_html/X/index.cfm>

The goal is to coordinate efforts with at least these groups as

While there is obvious synergy, given the end-of-life of the VPIM and
FAX work groups and the similar membership, the working group does not
expect to coordinate with these other groups.

Goals and Milestones:

Oct 04  Submit LEMONADE goals and use-cases specification to the IESG
Oct 04  Submit server to server notification requirements to the IESG
Nov 04  Submit translation to other messaging systems to the IESG
Nov 04  Submit IMAP/SUBMIT extensions for forward without download to IESG
Jan 05  Submit IMAP4 extensions for streaming multimedia to the IESG
Feb 05  Submit IMAP4 profile for mobile devices to the IESG
Mar 05  Submit server to server notification protocol to the IESG


  • draft-ietf-lemonade-goals-05.txt
  • draft-ietf-lemonade-catenate-04.txt
  • draft-ietf-lemonade-urlauth-05.txt
  • draft-ietf-lemonade-profile-01.txt
  • draft-ietf-lemonade-reconnect-02.txt
  • draft-ietf-lemonade-mms-mapping-02.txt
  • draft-ietf-lemonade-futuredelivery-01.txt
  • draft-ietf-lemonade-notify-s2s-00.txt
  • draft-ietf-lemonade-burl-00.txt

    No Request For Comments

    Current Meeting Report

    Minutes by Eric Burger Compiled from Jabber Log

    Goals in RFC Editor Queue
    Server-to-Server Notifications Needs WG Chair Write-Up for IESG
    MMS Mapping Needs WG Chair Write-Up for IESG
    Future Delivery and BURL needs nits review
    Tool to help nits review: http://ietf.levkowetz.com/tools/idnits/idnits.pyht

    - url interpretation: basic concern is "what is the base url for relatively interpretation? does it change in selected state as opposed to authenticated state?"
    - if you are going to use an absolute url we have an issue of a server needing to know its own domain name and do you always want to include the username
    - an absolute url without a user seems to indicate an anonymous user
    - Philip Gunther: favor of changing base url in selected state
    - Chris Newman: the complexity is how to deal with ".." in a relative url?
    seems to be consensus for selected state changing base URL for relative urls, specifically, to "this mailbox"

    Are absolute URLs allowed? is the client required to use relative URLs where possible?
    - general agreement that we should force clients to use relative URLs and have a different extension for absolute URLs.
    - John Klensin that disallowing absolute URLs is weird. Why have URLs at all if we can only use relative URLs?
    - Chris Newman: we should require relative URLs but need to make clear that "/random/mailbox" refers to "random/mailbox"
    Consensus that absolute URLs are out for this extension
    ";AUTH=" is also not allowed
    Absolute URLs are syntactically allowed, but not supported by the CATENATE extension.
    Absolute URLs get a "NO" from the server.
    Same for AUTH.
    Needs new draft, new Chairs say enough has changed for new WGLC

    Alexey notes there are some ABNF issues with IMAP URL RFC, which he sent to Chris.,

    Greg V: are requirements on server only or client, too? Consensus is requirements are on server, but document needs to give hints to client for how to use server extension.
    Needs lots of work. Right now document is a tutorial. Needs to be a standards document.

    Security Issues
    EKR: Comfortable if we use same authentication method for reconnect as for initial IMAP connect. Using *only* a cookie opens up passive attack. Using cookie after authentication is OK.
    Alexey & Corby: This is how Quick Reconnect works today (using cookie after full authentication).
    Cyrus Daboo points out that this is needed for desktop clients, as well as mobile clients.
    Edwin Aoki asks about single use schemes (e.g., SecurId). EKR says that if that is the authentication method, that is the authentication method.

    Transcoding & Security
    Drawing on fact that there is a possibility for the server to hand the encrypted session key to the client, the client can decrypt the session key, and hand back the key to the server, we can (1) ANNOTATE clear key to message, (2) decrypt message using session key and CATENATE message to temporary/permanent storage, (3) hand session key over for each IMAP operation.
    One problem is key is part of encrypted blob. [BTW: Ned pointed out need for separate carriage of key back in early 90's.] EKR points out that key almost always lives in first 4KB of blob, so can hack extraction. Jim Shod states that API's exist for S/MIME to do separate session key extraction, session key decryption, and decryption of the message using the decrypted session key.
    Will form design team to address this issue.

    On the streaming issue, URLAUTH addresses the Streaming Server-IMAP Server association, so long as the Streaming Server is authenticated to the IMAP Server; can use the same mechanism a SUBMIT server authenticates with the IMAP server for forward-without-download. Normal IMAP authentication addresses the IMAP Server-IMAP Client association. Using a secure channel between the IMAP Client and Streaming Server should be OK (EKR), but Sam Hartman separately expressed concern that the association between the IMAP Client and the Streaming Server has to use the same method as the IMAP Client and IMAP Server. For example, if the IMAP login does not use certificates, then we should not require the use of certificates for the IMAP Client-Streaming Server link.

    Stan Turner volunteered to participate on e2e design team.

    EKR volunteered to help review specific documents.


    First Session
    Second Session