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

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-01

Glenn Parsons <gparsons@nortelnetworks.com>
Eric Burger <eburger@snowshore.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Mailing Lists:
General Discussion: lemonade@ietf.org
To Subscribe: lemonade-request@ietf.org
In Body: in boby 'subscribe'
Archive: ftp://ftp.ietf.org/ietf-mail-archive/lemonade/
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 streaming 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 of 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 server.

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 guidelines 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 groups:

- 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X

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

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:
Jun 03  Submit LEMONADE requirements and architecture specification to the IESG
Jul 03  Submit server to server notification protocol to the IESG
Sep 03  Submit IMAP4 and message submission extensions for streaming multimedia to the IESG
Nov 03  Submit IMAP4 profile for mobile devices to the IESG
  • - draft-ietf-lemonade-submit-01.txt
  • - draft-ietf-lemonade-imap-channel-00.txt
  • - draft-ietf-lemonade-goals-01.txt
  • No Request For Comments

    Current Meeting Report

    Lemonade Minutes
    Nov 10 2003 - Monday - 1.00pm - 3.00pm
     + Agenda was described as the starting item by Glenn
     + Goals of lemonade by Glenn
       - Describes Uses cases and possible scenarios.
       - On context and motivation 
       - De-emphasize on the requirement aspect
     + MMS Mapping by Randall
       - Update to the existing draft would be "Mapping of delivery of msgs in 
    MMS world and eMail world"
       - The biggest change in the pending update is the addition of mapping 
    between delivery and disposition reports in the MMS and Email worlds.
     + IMAP Push/Pull started by Glenn
       - After the presentation, decision to be made on which approach to go.
     + Submit without download by Randell
       - Depending on who is the activie entity IMAP Push and Pull are 
    differentiated, ie., whether IMAP server or the Submit server
       - Various alternates mechanism by which IMAP PUSH can be done were 
          * Submit Intrinsically
            Submit through IMAP
            Notes :
            Queueing of messages
            Generate DSNs
            Like Sendmail functionality in IMAP    
          * Proxy method
            Redendency in operation
            Issues in athentication/Authorization
        - Various alternate mechanism by which IMAP PULL can be done were 
          * Submit server access IMAP for messages
          * Per-Mailbox access keys
          * URL includes time/role/user and signatures using mailbox 
        - IMAP COMPOSE
          Resolves many issues
          Independent of PUSH and PULL
        - URL AUTH
          Expiry time/User identity/Role identity were described.
      + URL Auth by Chris and Mark
        One of the pull method.
        Changes :
           Authid and Authrole are included
        Upcoming changes :
           Generate the secret key on demand.
           Hash function
           Default configuration
        There was a long discussion oon URL AUTH, 
        - When the secret should be generated. 
        - Who creates the Ticket, Client or Server. Ans : Client
        - Round trip in getting the tickets
        - To be decided : Secrets per mailbox or per user.
        - Specify both mechanism in the document.
      + Scalable mail environment by Chris:
         If the message store, outbound MTA and inbound MTA are 
    seperated, significant performance boost was observed during his 
        - Security concerns in URLAUTH were discussed :
          * TLS Protection
          * Should not store URL without protection.
        - Where the queue should be, is not specified.
        - Document should be free from assumptions
      + IMAP COMPOSE by Pete
        - Simplifies other uses.
      + Decision on Which way 2 go : PUSH Vs PULL
        Currently we dont have enough technical details to make a decision
        Before deciding, deployment cost should be considered. Make the 
    changes in one place or two places. Arugment was that in Pull method, both 
    IMAP and submit server should be touched.
        Concentrate on this (email)specific problem and work on a 
    solution. Dont try to get a generic solution righ now.
        Current specificatoin impact on Scalable mail were desribed.
       NOTE: There should be a revisions of COMPOSE, Push and Pull method 
    drafts by Dec 17. After which the decision on which method to follow will be 
      + IMAP4 Profile
      + S2S notification by Gev
        documents out-of-scope is descibed :
          Notification service.
      + What it does :
          User identifcation
          Server notification service
          Store and Forward
          Event ordering ( Queue / Time stamp ) 
          Dynamic structure ( Structure should be dynamic with respect to the 
    notification request )
          Should extensible enough to take care of end-end notification in 
        Discussions :
         - this draft is not listed on the work group items but it was sent to 
    mailing list
         - Requirements were not clear
           Explicit boundary should be defined
           Semantics required
           Event naming required
        Milestones :
        Jan04 : Goals, S2S, Streaming multimedia
        Apr04 : Forward without download documents 
        Jun04 : Profile for Mpbile devices
        Jul04 : Translation to other msg systmes.
       Milestones should be 


    MMS Mappings
    Server To Server Notification protocol requirements