Liaison statement
Regarding the LEMONADE Profile

From: IETF LEMONADE Working Group
To: OMA MWG MEM Sub Working Group
Title:
Response contact:  lemonade@ietf.org
Purpose:  For Action
Deadline:  March 13, 2006

The LEMONADE working group (WG) would like to thank the OMA Mobile Email Sub
Working Group for your latest liaison.

Our previous liaison indicated that we have proposed a realization of the OMA
MEM architecture using IETF protocols and that we documented this in an
Internet Draft (see draft-ietf-lemonade-oma-mem-realization-00.txt).  The
purpose of the WG Internet Draft is to provide a working document in the IETF
to ensure that our work addresses the OMA MEM required features within our
scope and to further affirm its status as a WG view.  As is the case with some
other WG documents in the LEMONADE WG, there is currently no intent to progress
this draft to an RFC.

Further, there is no intent to publish the OMA MEM RD, AD or TS in IETF.

As we have indicated before, the LEMONADE WG is working on a set of extensions
to IMAP and ESMTP to support mobile email.  This set will be succinctly
described in the LEMONADE profile (draft-ietf-lemonade-profile-bis).  This will
cover the protocol exchanged on interface ME-2 (ME-2a and ME-2b) as well as the
notifications aspects of ME-3, referring to the interfaces described in the OMA
MEM AD.  The OMA TS can normatively reference the LEMONADE profile for these
interface aspects and for the MEM protocol.  In addition, we are also
considering a best practices document on deployment considerations that may be
useful to OMA MEM.

We appreciate your response to the questions that we had asked in our previous
liaison.  We have a number of follow-on comments/questions:

1.  We will support signed notifications but will add the ability to turn it
off.

2.  OMA STI is currently being used in CONVERT (draft-ietf-lemonade-convert). 
However we are concerned with the large number of optional parameters.  We
would prefer a shorter finite mandatory set (that is extensible).  What advice
can you offer on a shorter set?

3.  We will be providing ‘Manage SIEVE Protocol’ to manage the filters. 
Additional methods (such as XDMS) could be used as well by OMA if desired.  But
a complete set of remote management functionality will be made available by the
LEMONADE work as part of the LEMONADE profile.

4.  We are evaluating where in our protocols delays may play a role.  We note
that there may be a tradeoff in mobile phones on battery life vs delay.   What
delay aspects are of concern to the OMA – is it roundtrip, network or service
level? Clearly our design will aim at  minimizing delays that are within our
control. We would like to make  sure we understand the aspect of particular
interest to OMA MEM.

5.  We are aware of the limitations for mutual authentication on mobile
devices.  We apologize for the confusion in our previous response.  Mutual
authentication is a feature provided by SASL (RFC 2222) framework, or SASL +
TLS. However the use of TLS is not required, and this could just be handled by
SASL mechanisms which are optimized for mobile phone use.

6.  Message recall is possible within the submit (i.e., administrative) domain.
 We indicated that we could design protocol for this based on MSGTRK (RFC
3888).  However, in the general end-to-end Internet Mail case it is practically
impossible to design a message recall solution that will reliably work. We
encourage OMA MEM WG to consider that  reality and verify that recall is still
a desired target mechanisms for OMA MEM

We would like to draw your attention to the fact that LEMONADE has wrapped up
the first phase of its work.  We are currently working on finalizing the
content of Profile bis.  Additional input on details required to meet OMA
requirements have been reviewed, and most have become WG documents.  The
timeline would likely result in conclusion in early 2006.

Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found
at http://www.ietf.org/html.charters/lemonade-charter.html with more detail
tracked on the supplemental site.

Finally, as information, the next meetings of the IETF LEMONADE WG are:
-       Mar 20-24 – IETF 65 plenary – Dallas, TX
-       Jul 10-14 – IETF 66 plenary - TBD