Subject: [lemonade] Draft Liaison to OMA

From: "Glenn Parsons" <[email-masked]>
Date: Wed, 25 Jan 2006 16:31:07 -0500

Folks,

As agreed, we will be sending a liaison to OMA MEM in time for their Feb
meeting.

As a result, please provide comment on the proposed liaison to OMA by
Jan 30th.  We will send it on Jan 31st if there is no objection.

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 allow this to be documented in the IETF and to
further affirm its status as a WG view.

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 interface ME-2 as
well as the notifications aspects of ME-3 in the OMA MEM AD.  The OMA TS
can normatively reference the LEMONADE profile.

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.  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 managed SIEVE to manage the filters.
Additional methods (such as XDMS) could be used as well.
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?
5.  We are aware of the limitations for mutual authentication on mobile
devices.  TLS is not required, and this could be handled by SASL
mechanisms which are already on mobile phones.
6.  Message recall is possible within the submit (i.e., administrative)
domain.  We indicated that we could design protocol for this based on
MSGTRK.  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 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
later 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

---

From: "Stephane H. Maes" <[email-masked]>
Date: Wed, 25 Jan 2006 21:06:31 -0700 (MST)

Glenn,
 
Here are my suggestions.
 
BTW deadline for submission is technicallythis coming Sunday...
 
Thanks
 
Stephane

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 how with see this can be achieved with IETF protocols (in particular Lemonade Profile) in an Internet Draft (see draft-ietf-lemonade-oma-mem-realization-00.txt).  The purpose of the WG Internet Draft is to allow this to be documented in the IETF, to provide a working document to ensure that our work address all the OMA MEM required features within our scope and to further affirm its status as a WG view.

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), as an overall protocol.  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. Additional documents may be published with additional best practices etc 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.  However we are concerned for practical implementations with the large number of optional parameters.  We would prefer a shorter finite mandatory set (that is extensible via IETF extensibility mechanisms (IANA)).  What advice can you offer on a shorter set?

3.  We will be providing managed SIEVE as a protocol to manage the filters.  Additional methods (such as XDMS) could be used as well by OMA if so 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. TLS may be used but TLS is not required, and this could just be handled by SASL mechanisms which are already on mobile phones.

6.  Message recall is possible within the submit (i.e., administrative) domain.  We indicated that we could design protocol for this based on MSGTRK.  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 later 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 (http://www.ietf.org/html.charters/lemonade-charter.html) with more detail tracked on the supplemental site.

    · Mar 20-24 – IETF 65 plenary – Dallas, TX
    · Jul 10-14 – IETF 66 plenary - TBD

__________________________________________________

_______________________________________________lemonade mailing [email-masked] (mailto:[email-masked])https://www1.ietf.org/mailman/listinfo/lemonade (https://www1.ietf.org/mailman/listinfo/lemonade) 

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked] (mailto:[email-masked])
IM: shmaes (AIM/Y!/Skype) or [email-masked] (mailto:[email-masked]) (MSN Messenger)

__________________________________________________

>From Glenn Parsons <[email-masked]>
Sent Wed 1/25/2006 1:31 PM
To [email-masked]
Subject [lemonade] Draft Liaison to OMA

Folks,

As agreed, we will be sending a liaison to OMA MEM in time for their Feb meeting.

As a result, please provide comment on the proposed liaison to OMA by Jan 30th.  We will send it on Jan 31st if there is no objection.

Cheers,

Glenn.

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 allow this to be documented in the IETF and to further affirm its status as a WG view.

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 interface ME-2 as well as the notifications aspects of ME-3 in the OMA MEM AD.  The OMA TS can normatively reference the LEMONADE profile.

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.  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 managed SIEVE to manage the filters.  Additional methods (such as XDMS) could be used as well.

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?

5.  We are aware of the limitations for mutual authentication on mobile devices.  TLS is not required, and this could be handled by SASL mechanisms which are already on mobile phones.

6.  Message recall is possible within the submit (i.e., administrative) domain.  We indicated that we could design protocol for this based on MSGTRK.  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 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 later 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 (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] (mailto:[email-masked])
https://www1.ietf.org/mailman/listinfo/lemonade (https://www1.ietf.org/mailman/listinfo/lemonade)

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Jan 2006 13:01:13 +0000

Looks good to me, some extra corrections below:

> The LEMONADE working group (WG) would like to thank the OMA Mobile 
> Email Sub Working Group for your latest liaison.
>
> how with see this can be achieved with IETF protocols (in particular 
> Lemonade Profile) in an Internet Draft (see 
> draft-ietf-lemonade-oma-mem-realization-00.txt).  The purpose of the 
> WG Internet Draft is to allow this to be documented in the IETF, to 
> provide a working document to ensure that our work address
>
addresses?

> all the OMA MEM required features within our scope and to further 
> affirm its status as a WG view.
>
> extensions to IMAP and ESMTP to support mobile email.  This set will 
> be succinctly described in the LEMONADE profile 
> (draft-ietf-lemonade-profile-bis), as an overall protocol.  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. 
> Additional documents may be published with additional best practices 
> etc that may be useful to OMA MEM.
>
> 2.  OMA STI is currently being used in CONVERT.
>
I think CONVERT should be explained here.

>   However we are concerned for practical implementations with the 
> large number of optional parameters.  We would prefer a shorter finite 
> mandatory set (that is extensible via IETF extensibility mechanisms 
> (IANA)).  What advice can you offer on a shorter set?
>
> 3.  We will be providing managed SIEVE
>
Manage SIEVE Protocol (no "d" at the end of Manage)

> as a protocol to manage the filters.  Additional methods (such as 
> XDMS) could be used as well by OMA if so 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. TLS may be used but TLS is not required, and this could just 
> be handled by SASL mechanisms which are already on mobile phones.
>
I am not sure about "SASL mechanisms which are already on mobile 
phones". I think saying "SASL mechanisms which are optimized for mobile 
phone use" is better.

To be more precise the last sentence should read:
  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.
>
Should there be a reference to RFC 3888 in order to explain what MSGTRK is?

>   However, in the general end-to-end Internet Mail case it is 
> reliably work. We encourage OMA MEM WG to consider that reality and 
> verify that recall is still a desired target mechanisms for OMA MEM
>
> be found at http://www.ietf.org/html.charters/lemonade-charter.html 
> with more detail tracked on the supplemental site.
>
>     * Mar 20-24 – IETF 65 plenary – Dallas, TX
>     * Jul 10-14 – IETF 66 plenary - TBD 
>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 27 Jan 2006 13:25:43 +0000

On Fri Jan 27 13:01:13 2006, Alexey Melnikov wrote:
>> response. TLS may be used but TLS is not required, and this could 
>> just be handled by SASL mechanisms which are already on mobile 
>> phones.
>> 
> phones". I think saying "SASL mechanisms which are optimized for 
> mobile phone use" is better.
> 
> 
Indeed, I'm not actually sure if the deployed base of phones capable 
of IMAP actually support anything but pre-SASL plaintext LOGIN. 
Certainly I've not seen a phone supporting DIGEST-MD5, which is the 
most common mutual auth SASL mechanism. (That's a particularly good 
mechanism to use on phones, since it's simple to implement without 
integrity or crypto, and has a fast re-auth mode which can complete 
in one round-trip with the right extensions).

The other mutual auth mechanisms tend to require some form of 
infrastructure in place.

> 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.
> 
> 
Equally, the vast majority of existing phones actually appear to 
support TLS 1.0. Of course, use of TLS might be blocked by other 
reasons, such as local law, so stating TLS isn't required is fair.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Mark Crispin <[email-masked]>
Date: Fri, 27 Jan 2006 09:22:00 -0800 (PST)

On Fri, 27 Jan 2006, Dave Cridland wrote:
> DIGEST-MD5, which is the most common mutual auth SASL 
> mechanism.

Are you sure about that?  I would have thought that GSSAPI was more 
commonly used, even if it isn't installed on as many sites; and after that 
CRAM-MD5 was more common than DIGEST-MD5.

I'm referring strictly to IMAP, not to any other protocol that uses SASL.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 27 Jan 2006 17:34:59 +0000

On Fri Jan 27 17:22:00 2006, Mark Crispin wrote:
>> DIGEST-MD5, which is the most common mutual auth SASL mechanism.
> 
> commonly used, even if it isn't installed on as many sites; and 
> after that CRAM-MD5 was more common than DIGEST-MD5.
> 

You're probably right about GSSAPI vs DIGEST-MD5, I expressed my 
opinion as if it were a fact, which is silly of me. CRAM-MD5 doesn't 
count here, although it's certainly better deployed than DIGEST-MD5, 
because it doesn't do mutual authentication.

DIGEST-MD5 is, however, the only mutual auth SASL mechanism I feel is 
likely to be deployed on a mobile phone for the typical situation.

Dave.

---

From: [email-masked]
Date: Tue, 31 Jan 2006 15:30:33 +0200

"Additional documents may be published with additional best practices etc that may be useful to OMA MEM."
What does this mean? There will be a "profile 3" if OMA MEM does not find bis sufficient? Please clarify.
"But a complete set of remote management functionality will be made available by the LEMONADE work as part of the LEMONADE profile."
What is the purpose of this sentence? OMA MEM expects nothing less. Suggest removal.

Best regards: Zoltán Ördögh 
E-mail: [email-masked]
Phone: +358 50 386 0566 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephane H. Maes
Sent: 26 January, 2006 06:07
To: Glenn Parsons; [email-masked]
Subject: RE: [lemonade] Draft Liaison to OMA

Glenn,
 
Here are my suggestions.

Thanks
 
Stephane

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.

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

________________________________

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

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!/Skype) or [email-masked] (MSN Messenger)

________________________________

Folks, 

Cheers, 
Glenn. 

3.  We will be providing managed SIEVE to manage the filters.  Additional methods (such as XDMS) could be used as well. 
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?

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

________________________________

---

From: [email-masked]
Date: Tue, 31 Jan 2006 15:30:34 +0200

"The purpose of the WG Internet Draft is to allow this to be documented in the IETF and to further affirm its status as a WG view."
What does it mean? Will it become an RFC later on? Could You please clarify/reword this sentence?

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Glenn Parsons
Sent: 25 January, 2006 23:31
To: [email-masked]
Subject: [lemonade] Draft Liaison to OMA

Folks, 

Cheers, 
Glenn.

---

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 31 Jan 2006 14:33:53 +0000 GMT

Remember the deoloyment best practice for example.

Stephane
_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle
Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!) or [email-masked] (MSN Messenger)

-----Original Message-----
From: [email-masked]
Date: Tue, 31 Jan 2006 15:30:33 
To:<[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [lemonade] Draft Liaison to OMA

Glenn,
 
Here are my suggestions.

Thanks
 
Stephane

 

_____
Stephane H. Maes, PhD,

Folks, 

Cheers, 
Glenn.

---

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 31 Jan 2006 14:49:25 +0000 GMT

Zoltan, 

It seems correct to me:
1) its the LEMONADE WG view as agreed hence a ietf deaft
2) this way its is documented, visible and stored somewhere as a working document hence a draft.

This does not imply bor discuss its long term status hence again beung a draft. I personally believe that it makes a lot of sense to have it become RFC (fizing the concrens raised by OMA of course) when work and relationship between specs stabilize.

Stephane
_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked]
Date: Tue, 31 Jan 2006 15:30:34 
To:<[email-masked]>, <[email-masked]>
Subject: RE: [lemonade] Draft Liaison to OMA

Folks, 

Cheers, 
Glenn.