Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)

ned.freed@mrochek.com Wed, 29 January 2003 21:20 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00203; Wed, 29 Jan 2003 16:20:11 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18dzej-0000ce-00 for ietf-list@ran.ietf.org; Wed, 29 Jan 2003 16:22:01 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18dzdr-0000at-00 for ietf@ran.ietf.org; Wed, 29 Jan 2003 16:21:07 -0500
Received: from mauve.mrochek.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00057; Wed, 29 Jan 2003 16:13:02 -0500 (EST)
From: ned.freed@mrochek.com
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KRSZYL6PGG002DEU@mauve.mrochek.com>; Wed, 29 Jan 2003 13:16:32 -0800 (PST)
Date: Wed, 29 Jan 2003 13:06:39 -0800
Subject: Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)
In-reply-to: "Your message dated Wed, 29 Jan 2003 14:40:31 -0600" <p06000111ba5de5b9c58d@[216.43.25.67]>
To: Pete Resnick <presnick@qualcomm.com>
Cc: John C Klensin <john-ietf@jck.com>, "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Message-id: <01KRT49TEUKI002DEU@mauve.mrochek.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_UVevbSQno9NfSOlfUmv3MA)"
References: <200301282312.SAA11118@ietf.org> <169878963.1043847608@p3.JCK.COM> <p0600010dba5dd6b34009@[216.43.25.67]> <175052472.1043852782@p3.JCK.COM> <p06000111ba5de5b9c58d@[216.43.25.67]>
Sender: owner-ietf@ietf.org
Precedence: bulk

> I agree. And unfortunately, I think this is due to a serious problem
> about which I'm quite distressed:

> The proposed charter contained in the announcement is *not* the
> proposed charter worked out on the LEMONADE BOF mailing list. Not
> even close. The one on the list went through several revisions to
> include specific language in the work items about profiling of
> existing protocols, and that language has been removed in what was
> posted here. The one on the list was tailored specifically to avoid
> having the working group add to existing protocols (with IMAP as only
> one example) unless absolutely necessary, but rather to profile
> existing protocols if that solved the problem. The present charter
> gives the incorrect impression that the desire of the group is simply
> to add extensions, specifically to IMAP.

Well, as it happens the charter that was posted to ietf-announce wasn't
the one the IESG approved either. It is one from quite a few versions
back.

I've attached the current charter below.

> First, a process point: If these significant changes were made by the
> IESG to what was submitted, these should have been brought back to
> the list for approval.

I regard this as being up to the chair of the group. The charter that
wasn't posted was iterated on by both the chairs and the IESG.

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

Proposed Charter
================

Lemonade is tasked to provide a set of enhancements and profiles of Internet
email submission, transport, and retrieval protocols to facilitate operation in
environments which use Internet-based technologies but which have link
characteristics, device characteristics, or service environments that are
significantly different from those common on the Internet.  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, IMAPEXT and other 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 will be produced on LEMONADE requirements.

     1.  Enhance the existing IMAP4 message retrieval protocol to satisfy the
         requirements for streaming playback of multimedia content. 
         
     2.  Enhance the exsiting IMAP4 message retrieval protocol to facilitate
         its use with devices that have limited capabilities such as mobile
         endpoints. The existing standards-track CONNEG framework will be used
         if content negotiation capabilities are needed.

     3.  Create a message notification protocol for the specific purpose of
         servers reporting message status information to other servers.

     4.  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 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-P <http://3gpp2.org/Public_html/P/index.cfm>
  - 3GPP2 TSG-N <http://3gpp2.org/Public_html/N/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.


Milestones  (document completion)
==========

Feb 2003 - LEMONADE Requirements

May 2003 - Server to server notification protocol

Jul 2003 - IMAP4 extensions for VM playback

Sep 2003 - IMAP4 extensions for mobile devices

Jan 2004 - Translation to and from other messaging systems


Drafts to be used as input for working group
deliverables (grouped per milestone)
====================================

   LEMONADE requirements

     - draft-vaudreuil-um-issues-00.txt
     - draft-burger-um-reqts-00.txt
     - draft-wong-umcli-00.txt

   Server to server notification protocol

     - draft-shapira-snap-04.txt

   IMAP4 extensions for VM playback

     - draft-burger-imap-chanuse-00.txt
     - draft-nerenberg-imap-channel-01.txt

   IMAP4 extensions for mobile devices

     - draft-neystadt-imap-status-counters-00.txt
     - draft-shveidel-mediasize-00.txt

   Translation to and from other messaging systems

     - draft-vaudreuil-futuredelivery-00.txt