Subject: [lemonade] Draft Liaison to OMA - revised

From: "Glenn Parsons" <[email-masked]>
Date: Wed, 1 Feb 2006 18:12:07 -0500

Folks,

Below is the revised Liaison that we will send.

Cheers,
Glenn.

===================

From: IETF LEMONADE Working Group
To: OMA MWG MEM Sub Working Group
Title: Regarding the LEMONADE Profile	
Response contact:  [email-masked]
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 (the IMAP extension to
request static content transformation).  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

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade