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

Last Modified: 2003-06-20

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

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

- 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:
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-00.txt
  • - draft-ietf-lemonade-imap-channel-00.txt
  • - draft-ietf-lemonade-goals-00.txt
  • No Request For Comments

    Current Meeting Report

    concluded.Meeting notes of LEMONADE group meeting by Chanh Phung
    Meeting in Room LM @ Vienna Center
    Chairs : Glenn Pearson
            Eric Burger
    Agenda bashing - 10 min 
    No issue
    LEMONADE Goals (ex Requirements) - 40 min 
      - draft-lemonade-goals-00.txt - Editor Kue Wong 
    should we have an architecture as well? 
    Charter was shown.
    Q: should it be IMAP4 ?
    A: Yes, it is explicitly written in the charter.
    One of the notes from the chair is to extend email to wireless handset.
    IMAP4 extensions for mobile devices - 30  
           - draft-lemonade-imap-submit-xx.txt - Editor Randall Gellens 
        - draft-shveidel-mediasize-02.txt 
       - draft-vaudreuil-futuredelivery-01.txt 
    -       Issue & architecture document.
    -       Draft from 4 earlier drafts, started from IETF 56. Has sections on 
    client-model, internet mail enhancement, detailed requirements for 
    telephone interface and wireless handheld.
    -       New material adds cellular perspective to text and multimedia 
    -       Push-notification delivery
    -       E.164 delivery
    -       Discussions about the enhancements to IMAP4
    -       Tighter spec of IMAP4 enhancements for limited capability 
    -       Tighter spec of requirements for notification format and 
    -       IMAP support for interworking with MMS
    -       More detailed architectural description or separate 
    architectural document
    Q. Should it be only mobile handheld or expand to TUI ?
    Randy. Did not see anything about user interface in the charter, only 
    networking, memory, bandwidth, latency related constraints.
    Glenn. The goal doc explains the environment, but do not get into what the 
    TUI should be. It specifies the use cases and the problems to solve. More as a 
    description of the requirement, not design doc.
    Randy. Are we
    Greg. There are things beyond network efficiency, but protocol related in 
    order to support TUI features.
    Glenn. Agree. Request review the goal document and comment on what should be 
    Randy. Are we committing to go to RFC with this goal document ? Good about a 
    guiding document, but not useful as an informational RFC.
    Glenn. Good point. Need to focus on use case. Decision to publish this 
    document should be later.
    Vote : not working on TUI.
    Glenn. Request to study and comment on this document to identify work 
    Q. Request feedbacks on contents.
    Glenn. Start a new thread on the mailing list for each content item.
    IMAP push/pull 
    (draft-ietf-lemonade-submit-00.txt)- Randy
    Forward without download: Allow IMAP client to include 
    previously-received message without downloading
    Push mechanism:
    1.      Annotated outbox/external agent: requires annotation support by the 
    2.      IMAP does submit intrinsically: add message submission to IMAP.
    -       Require IMAP the capability to queue message
    -       Generate DSN
    -       Forward to smart
    -       OK from IMAP does not mean message accepted
    -       Client polls message to learn status or get DSN
    -       Add complexity to IMAP for limited cases: non-SMTP submit (e.g. IM)
    -       Admin complexity
    3.      Proxy/submit server: few changes to IMAP
    -       Does not return OK until get ack from submit -> longer 
    -       Submit server has to authenticate to IMAP server -> new 
    authentication and authorization.
    -       #2. have a choice to deprecate message submission, or have two 
    parallel message submission.
    -       #2 vs. #3. different client 
    -       #3. submit server and IMAP server can be co-located.
    -       Suggest to add a design goal (elegance vs. efficiency)
    -       All 3 options define a new submission protocol, not only #2 and #3. 
    Good point.
    Pull mechanism: Pawn ticket. Per user mailbox secret.
    -       Randy. There are some interesting usage for the pawn ticket 
    -       Dave. Great summary of the draft. Composition should be tightly 
    with IMAP function and composition by reference is not a good idea. 
    Double login is not a big deal. Ticket mechanism is a risk.
    -       Glenn. Is trigger to submit assumed ? different mechanism would 
    have different assumption.
    -       Chris. Need two composition services: full composition, compose and 
    append. Both are already adopted.
    -       Chris. was a proponent of IMAP push model. Should not have 
    multiple ways to submit for IM, etc. Now a proposal of IMAP pull model.
    -       xxx. Need to focus on the split client-model decision.
    -       Lisa. Same problem is resolved in IM, using URI instead of attach 
    the whole thing. Please consider this model.
    -       Eric. The requirement is the object is there whenever needed, 
    regardless of pull/push/reference. A scenario to consider is when one 
    client delete, the other client forward, and the reference should be 
    managed accordingly.
    -       Eric. Should the protocol protects the user from wrongful use ?
    -       Dave. Let's take the ticket mechanism out of the scope of 
    immediate resolution.
    -       Randy. Assumption about trusted environment is probably not 
    -       Dave. Let's figure out what is useful for our users ??? Ticket 
    mechanism is a high risk item.
    -       Pete. Ease of implementation should be the most important.
    -       Pete. IMAP composition should be a separate issue. Push or pull 
    would be determined later.
    -       Vote. Support client compose and append.
    -       xxx. Design the system in a modular way to take on 
    authentication later.
    -       Glenn. Have two questions to vote.
    -       Eric. It is premature to vote now. Should wait until Pete's work 
    -       Vote. Should have only one RFC for the chosen option.
    -       Vote. Split between push and pull.
    Q. Should it be a working group doc ?
    Vote. Not a working group item.
    Ari. Willing to limit the scope to make it a working group doc. It is 
    ready, but needs reviews.
    Chris. Have substantial work load for the charter. Willing to give expert 
    review but not working group item.
    Q. Should it be a working group doc ?
    Vote. It is a working group doc.
    This work item should be part of IMAP push/pull.
    The document will continue as usual. The document will be absorbed to the 
    push/pull document whenever necessary.
    IMAP4 profile for mobile devices - 5 min 
       - volunteers will be solicited in Vienna 
    Translation to and from other messaging systems - 10 min 
    Vote: This is a working group doc.
    Mapping between email and MMS.
    MMS delivery and read report is text, not multipart.
    MMS specific features: sender addr hiding, reply charging.
    X-MMS-* headers
    Eric. How this work is shared with 3GPP and 3GPP2 ?
    Randy. This should be published as RFC, then reference by 3GPP2.
    Server-to-Server Notification Protocol - 5 min 
        - brief discussion of direction   
    IMAP4 extensions for streaming VM playback - 10 min 
       - draft-lemonade-imap-channel-xx.txt - Editor Eric Burger 
    Pete. Lyndon is the new editor of this document.
    Milestone bashing - 10 min 
    Deliverables: Discussed, updated and agreed.
    Milestones: Discussed, updated and 


    Goals for Internet Messaging to Support Diverse Service Environments