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

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-11-01

Chair(s):

Glenn Parsons <gparsons@nortelnetworks.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 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:

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

Internet-Drafts:

  • draft-ietf-lemonade-imap-channel-02.txt
  • draft-ietf-lemonade-goals-04.txt
  • draft-ietf-lemonade-catenate-02.txt
  • draft-ietf-lemonade-urlauth-03.txt
  • draft-ietf-lemonade-profile-00.txt
  • draft-ietf-lemonade-msg-context-00.txt
  • draft-ietf-lemonade-reconnect-02.txt
  • draft-ietf-lemonade-mms-mapping-01.txt
  • draft-ietf-lemonade-server-to-client-notifications-00.txt
  • draft-ietf-lemonade-futuredelivery-00.txt
  • draft-ietf-lemonade-notify-s2s-00.txt
  • draft-ietf-lemonade-burl-00.txt

    No Request For Comments

    Interim Meeting Report

    Lemonade Interim Meeting

    Agenda was bashed.

    Liaison statements
    - Lemonade received liaison response from T2. No further response needed
    - OMA liaison previously sent has not received response, Follow-up to be
    done
    - Additional OMA response notifying of working group last call for MMS
    mapping to be sent via Dean Willis

    Working Group Last Calls Completed
    - Glenn to write IESG summary to send to Ted (Server to Server
    Notifications Reqs)
    - MMS Mapping - After Randy makes some last-minute changes
    To be sent
    - Goals document needs WG Last Call for tomorrow.
    - Future Delivery - draft-ietf-lemonade-00 Needs WG Last Call tomorrow

    Pull document Review
    - BURL document ready for last call? - Private comments sent to Chris..need to be folded into new
    document.
    - WGLC to be sent, pick up final comments in that review
    - Alexey explicitly named to review document.
    - CATENATE
    - Not ready yet... - How to edit message drafts save on server? Apparent consensus not
    to optimize at this time.
    - Desire is to have appropriate examples in the catenate document. - Describe how to use and choice of simplicity in the profile
    document
    - URLAUTH
    - Some editorial messages from Randy to be incorporated before or
    after WGLC
    - Add some note text talking about revocation of tokens... if
    administrator wants to use
    stronger algorithm, Randy to contribute text.

    Target for pull documents is last call after revised drafts posted before
    the close of ID posting interval, with close of the WGLC at the Lemonade WG
    meeting in Washington.

    Channel
    - Current channel proposal is security challenged
    - GV restated model presented earlier in email as a starting place for
    discussion

    Open discussion resulted in the following new insights. The problem space
    was split into two

    A) Download of file types using existing IMAP connections. Add request
    for server-side transcoding to the IMAP protocol somehow.
    B) Use URLAUTH to retrieve content from a streaming server using RTSP.
    Negotiation is part of RTSP. Some hand waving/work require needed to determine how to use the
    URLAUTH in RTSP.

    Substantial discussion was conducted to determine if the problem space
    triggered any OPES considerations. The consensus was that this work met the
    requirements for explicit request and authorization of content stored in the
    subscribers own mailbox. Also, it was expected that the unmodified content
    would remain in the mailbox for access by alternate clients or later times
    when better connectivity is available. A statement to the effect that the
    server should never convert without a request from the client was seen as a
    good idea.

    WG also discussed the charter and convinced ourselves that charter item #1
    implied a requirement to provide a mechanism for transcoding requests.

    Requirements
    Client controls conversion
    No default conversion on server
    Message contents not changed on server after conversion
    Assumption is Conneg mechanism for IMAP download option. Streaming
    protocols have mechanism based on SDP?
    Go-fish content request mechanisms are bad... try to reduce trips.
    - maybe client requests ordered list of formats


    Discussion of IMAP compression

    Presentation made by Aranaud Meylan (available on VPIM web-site).
    Discussion, interpolation, and guessing suggested that compression may be a
    red-herring. Compression of IMAP commands and responses appears to save few
    if any packets and no round-trips. Most text-messages seem short enough
    that compression, while effective, does not save packets or round-trips, the
    main costs. Larger contents such as pictures, audio, and video are already
    highly compressed.
    Compression tests were most valuable at winning back the base-64 encoding of
    large attachments, to which the WG reached consensus that it would be better
    to require use binary Fetch.

    Various folks will work with Aranaud to better test these hypothesis with
    additional testing and/or modeling.
    Rough consensus also achieved that if compression is needed, StartTLS with a
    null cypher and compression seems to be the best approach. This also
    leverages use of TLS for encryption which is expected to become commonly
    available in handset OS's in the target timeframe.

    There are some low-handing fruits that may be exploited to minimize IMAP
    chattiness, but the working group decided not to complicate or delay
    Lemonade 1.0 profile to figure how to exploit these opportunities.

    Also some thought that if compression of specific media types such as
    text/plain is desired, the conversion could be requested from the server
    using the media conversion extensions.

    Encryption at a basic "must implement" level appears to be necessary for
    enterprise use.

    Discussion of notification and Restart

    The Lemonade profile will address the requirement for inband "instant"
    notification of arrival of new messages. The working group split the problem statement, agreeing that TCP
    should survive the underlying networking coming and going. In that case,
    IMAP IDLE provides a good mechanism for notification of new messages.
    However, given the widespread lack of support for good TCP behavior, the WG
    will acknowledge the need for out-of-band notification that may stimulate a
    sleeping client to efficiently reconnect and fetch messages.
    The group discussed a number of concepts but did not have any specific
    proposals to review. There was general interest in improving IMAP
    synchronization rather than an explicit session token. The interest is
    motivated by the desire to have fast starts when using server pools and
    connection after mid-to-long term disconnection.

    Marketing and PR

    The WG is enthusiastic, and after a review of charter milestones discussed
    the need to engage a marketing-oriented group for PR and promotion of the
    Lemonade profile. Greg Vaudreuil was invited to present the work of the
    Lemonade group to the TMIA, meeting in Vancouver in conjunction with the
    Lemonade WG meeting :-) . The TMIA may be a reasonable choice to sponsor or
    promote interoperability events and PR as and if necessary.


    ACTION ITEMS:

    Eric Burger will invent (with help) a lightweight mechanism for starting a
    RTSP session based on a URLAUTH. Due after November IETF meeting, but Eric
    is expected to do some thinking in time for the WG meeting.

    Lyndon Nerenberg will take a first stab, published in an ID before the
    November IETF, for a capabilities declaration and transcoding request
    mechanism within IMAP.
    Greg is supposed to capture the pictures of options A and B in ASCII art as
    part of these minutes.

    Randy to post a new version of the MMS mapping document addressing editorial
    comments received.

    Pete Resnik to post a new version of Catenate including some relevant
    examples

    Aranaud to iterate on the analysis of the benefits of compression.

    Corby and Alexey will continue their collaboration on restart.


    Respectfully submitted for WG review by Greg Vaudreuil



    Attendees
    - Stephan Maes stephan.maes@oracle.com
    - mark Crispin mrc@washington.edu
    - randy Gellens rg+ietf@qualcomm.com
    - Ted Hardie Hardie@qualcomm.com
    - Lyndon Nerenberg lyndon@orthanc.ca
    - corby wilson corby.wilson@nokia.com
    - Jerry Weingarten jerry.weingarten@comverse.com
    - Aranaud Meylan ameylan@qualcomm.com
    - Glenn Parsons gparsons@nortelnetworks.com
    - Eric Burger eburger@brooktrout.com
    - Jean Sini siniJ@symbol.com
    By Phone
    - Pete Resenick presnick@qualcomm

    Slides

    None received.