2.7.2 Interim Meeting - Enhancements to Internet email to support diverse service environments (lemonade)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-10-03

Chair(s):

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

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

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

Done  Submit LEMONADE goals and use-cases specification to the IESG
Done  Submit server to server notification requirements to the IESG
Done  Submit translation to other messaging systems to the IESG
Apr 2005  Submit IMAP/SUBMIT extensions for forward without download to IESG
Apr 2005  Submit IMAP4 profile for mobile devices to the IESG
Jun 2005  Submit IMAP4 extensions for streaming multimedia to the IESG
Aug 2005  Submit server to server notification protocol to the IESG

Internet-Drafts:

  • draft-ietf-lemonade-goals-05.txt
  • draft-ietf-lemonade-catenate-05.txt
  • draft-ietf-lemonade-urlauth-08.txt
  • draft-ietf-lemonade-profile-05.txt
  • draft-ietf-lemonade-reconnect-04.txt
  • draft-ietf-lemonade-mms-mapping-06.txt
  • draft-ietf-lemonade-futuredelivery-03.txt
  • draft-ietf-lemonade-notify-s2s-00.txt
  • draft-ietf-lemonade-burl-04.txt
  • draft-ietf-lemonade-rfc2192bis-00.txt
  • draft-ietf-lemonade-convert-00.txt

    No Request For Comments

    Interim Meeting Report

    LEMONADE London - Sept 28-30 
    ======================== 
    
    OMA requirements (RD) 
     - summary including feedback on previous LEMONADE concerns 
    
    OMA architecture (AD) 
     - discussion of the model including which parts might 'belong' to OMA
    vs IETF 
     - initial LEMONADE view (including 'magic box') presented 
     - OMA interested in detailed IETF proposal on how LEMONADE will realize
    architecture.  Official liaison expected.  This will be published as a
    WG I-D.
    
    MMS mapping 
     - WG reviewers volunteered to review comments, new draft if necessary 
    
    Reconnect 
     - New revision needed to address issues 
     - Vendor implementations are needed on this 
     - There is dependency on CONDSTORE, EXPUNGED , and comparators 
    
    Future Delivery 
     - new draft due to resolve last issues 
    
    Trio 
     - CATENATE & BURL issues resolved (chairs to confirm) 
     - URLAUTH needs another spin to resolve 
    
    'The LEMONADE profile' 
     - finalize list for first release 
     - Reconnect, post address out 
     - CHUNKING, CONDSTORE, LITERAL+, TLS in 
     - WGLC when draft available mid Oct 
    
    Notifications / filtering 
     - IAB note reviewed, we are within charter to cover OMA requirements 
     - SIEVE is basis 
     - Greg & Stephane will propose draft 
    
    Content Transformation 
     - streaming proposal will be made by Eric or Lyndon (based on figure B
    at 61.5) 
     - static proposal based on LCONVERT by Stephane 
    
    Compose 
     - discussion tabled, as it is not needed if SMTP had http binding... 
    
    Compression 
     - agreed to define min codec for TLS, but will decide later 
    
    HTTP binding 
     - proposal to make optional for IMAP & SMTP 
     - perhaps BCP or Informational 
     - use of IMAP/SMTP ports must be promoted by profile 
    
    New drafts: 
     - Goal to finish first phase before Vancouver 
     - 00 due by Oct 17 
     - rest due by Oct 24 
    
    Vancouver: 
     - we will have two slots and perhaps additional BOFs 
    

    Slides

    Agenda
    Overview of Mobile Email RD
    Business Model Study in Mobile E-mail
    SIEVE
    Lemonade Model
    Lemonade Mobile and New Drafts Towards Phase 2 of Lemonade