Subject: RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03

From: Randall Gellens <[email-masked]>
Date: Fri, 11 Aug 2006 11:09:22 -0700

At 9:36 AM +0100 8/9/06, Ben Last wrote:

>  Gang Liang [mailto:[email-masked]] wrote on 09 August 2006
>  04:04:
>>Using MMS to push email or notifications is just an example. What I
>  want to
>>talk about is the feasibility and rationality of pushing an email via
>>outband notification. E.g. if the client is GPRS online and the email
>  is
>>very urgent, maybe it's more appropriate to push the email directly in
>  the
>>notification instead of pushing a wake-up notification that makes the
>  client
>>to create a connection with server to fetch the email.
>
>  I think, then, that one of the key factors is the amount of data you can
>  get into an outband notification.

There's also the security implications: with a simple notification 
that an event has occurred, the payload generally needs to be signed 
but not encrypted.  When actual data (such as subject, sender, or 
body of the mail) is included, it needs to be encrypted as well.

>   You can fit 140 bytes into an SMS, so
>  there's not much room for more than a notification that events have
>  occurred.  You can fit far more into an MMS (with all the cost
>  implications)

With MMS, generally a notification is sent to the client, with advice 
from the server as to if the client should immediately retrieve the 
message or defer it.  So to send notification of new mail over MMS 
would be convoluted, since:
	(1) new mail arrives at message store
	(2) notification sent as MMS to client
	(3) MMS arrives at server
	(4) MMS server sends notification to client
	(5) client brings up traffic channel and fetches MMS
	(6) MMS client hands MMS to mail client
	(7) mail client brings up traffic channel and fetches mail

Whew!

>  However, I think that the decisions on (a) when to retrieve mail and (b)
>  how much to retrieve are better made by the client.  For example, if the
>  client can tell that the email is low-priority, or that it is in an area
>  where network access is slow and expensive, it may choose to retrieve
>  messages only once per hour, and to retrieve only the headers.  Or, if
>  it detects that it is in range of a usable wi-fi connection, and thus
>  has high-speed and low-cost access, it might choose to retrieve the
>  header and message text of new emails.  In the mobile phone environment,
>  I think there are many factors, which vary with time and location and
>  that are detectable only by the client, which might affect the client's
>  decisions about how to respond to the information that new messages (or
>  changes to messages) are available.

I'd agree with this.  We should keep the client in control as much as possible.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Every word is like an unnecessary stain on silence and nothingness.
                                                         --Beckett

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

---

From: Jon Ingi <[email-masked]>
Date: Sat, 12 Aug 2006 08:12:29 +0000

>>  occurred.  You can fit far more into an MMS (with all the cost
SMS supports concatenation which allows the notification to be larger 
then 140 bytes.  This is required for MMS notifications which are sent 
over SMS and are usually are larger then 1 SMS, especially due to legacy 
issues with clients who did not support specific WSP tokens and 
therefore require string encoding of those tokens.  A MMS notification 
can contain the following (MMS version 1.3):

* transaction-id
* mms-version
* from address
* subject
* delivery-report flag
* storage flag
* message class
* priority
* message-size
* expiry value
* reply charging
* reply charging deadline
* reply charging size
* reply charging id
* distribution indicator
* element descriptor
* recommended retrieval mode
* recommended retrieval mode text
* application id
* reply application id
* aux application info
* content class
* drm content
* replace-id
* content-location

so as you can see a surprising amount of information is being squeezed 
in there over SMS  :-)  Most of this is optional and not used in any 
real deployment that I've seen.

>     (5) client brings up traffic channel and fetches MMS
and sends notification response to the MMS server which due to a design 
flaw in MMS forces the message store to be tightly coupled to MMS server 
configuration in the device.
>     (7) mail client brings up traffic channel and fetches mail

I agree with others on this list that MMS is a poor choice for a 
notification protocol.  In that case it would be more logical to use MMS 
as the access protocol and skip IMAP  :-)

wr,
Jon Ingi

---

From: "Ben Last" <[email-masked]>
Date: Mon, 14 Aug 2006 08:38:05 +0100

Randall Gellens [mailto:[email-masked]] wrote, at 11 August 2006
19:09:
>There's also the security implications: with a simple notification that
an event has
>occurred, the payload generally needs to be signed but not encrypted.
When actual data
>(such as subject, sender, or body of the mail) is included, it needs to
be encrypted as well.
Excellent point.

>With MMS, ... to send notification of new mail over MMS would be
>	(7) mail client brings up traffic channel and fetches mail
(My omission in the first sentence for brevity)

Actually, it's not as bad as that from the client point of view, at
least on Symbian (S60 or UIQ), and I'm pretty sure on Windows Mobile
too.  The PIMAP client is just advised of the arrival of an MMS.  Steps
4-6 are all dealt with by the base OS or messaging layers, which are
opaque to an IMAP client application.
Similarly, there are many MMS senders that will accept an MMS via HTTP,
making steps 2-4 a single operation from the point of view of the mail
server.  So it need not be more complex than sending an SMS from the
point of view of the P-IMAP systems (client and server).

But as mentioned earlier, there are (currently) significant cost issues
with use of MMS.  Something I also didn't mention earlier is transit
time: MMS messages seem to be subject to more and longer delays, at
least in and between the UK/EU operators, than SMS.  Since part of the
rationale for using OOB notifications seems to be immediacy.

Regards
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 13:07:28 +0300

>Windows Mobile too.  The PIMAP client is just advised of the 
>arrival of an MMS.  Steps
What is this PIMAP client You mentioned?
Thank You.

---

From: "Ben Last" <[email-masked]>
Date: Tue, 15 Aug 2006 11:27:01 +0100

>I wrote:
>>Windows Mobile too.  The PIMAP client is just advised of the arrival
of 
>>an MMS.  Steps

>What is this PIMAP client You mentioned?

I'm not quite sure what you're asking: if it's "what do you mean by
PIMAP", I mean "Push-IMAP", or "the variant of IMAP spoken by a
Lemonade-compliant IMAP server".
If you mean "what particular client do you mean", I mean, as an example,
the Push-IMAP client that we're currently building for S60 (Symbian)
phones, though the statement's applicable to any application, running on
a Symbian handset, that wants to be able to detect the arrival of an
MMS.

Regards
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 13:49:16 +0300

Hi Ben,
I meant the "PIMAP client".
So, I guess You mean a client based on the proprietary P-IMAP draft, right?
http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt
Because if You mean a LEMONADE-compliant client, then it cannot be based on P-IMAP (well, not right anyway now at least because there are too many differences).
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Ben Last [mailto:[email-masked]] 
>Sent: 15 August, 2006 13:27
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]; 
>[email-masked]; [email-masked]
>Subject: RE: [lemonade] some questions in 
>draft-ietf-lemonade-notifications-03
>
>>I wrote:
>I'm not quite sure what you're asking: if it's "what do you 
>mean by PIMAP", I mean "Push-IMAP", or "the variant of IMAP 
>spoken by a Lemonade-compliant IMAP server".
>If you mean "what particular client do you mean", I mean, as 
>an example, the Push-IMAP client that we're currently building 
>for S60 (Symbian) phones, though the statement's applicable to 
>any application, running on a Symbian handset, that wants to 
>be able to detect the arrival of an MMS.
>
>Regards
>Ben
>EMCC Software Ltd
>

---

From: "Ben Last" <[email-masked]>
Date: Tue, 15 Aug 2006 12:12:35 +0100

[email-masked] [mailto:[email-masked]] wrote at 15
August 2006 11:49:
>Because if You mean a LEMONADE-compliant client, then it cannot be
based on P-IMAP (well,
>not right anyway now at least because there are too many differences).

It makes no difference at all to the point I was making: whether it's a
client based on any particular draft of P-IMAP, or Lemonade compliant to
some level, the point is still true: a Symbian application doesn't need
to be concerned with the complexities of receiving an MMS or SMS; that's
all dealt with by the platform.

However, to address your point: the Workgroup status page
(http://tools.ietf.org/wg/lemonade/) references
http://tools.ietf.org/wg/lemonade/draft-maes-lemonade-p-imap-12.txt,
which is "a recommendation for interoperable intermediate
implementations awaiting draft-ietf-lemonade-profile-bis-xx.txt" and
"the P-IMAP specifications are expected to further converge towards the
profile".  Right now, a feasible way to implement a client is to
implement it so that it supports P-IMAP, which overlaps with many parts
of the Lemonade profiles.  The client can then track the implementation
of Lemonade compliance in commercial servers whilst also generating
revenue from the installed base of users of those existing P-IMAP
servers.

So yes, there are differences between Lemonade (as expressed in the
profile-bis-xx documents) and P-IMAP (as expressed in
draft-maes-lemonade-p-imap-xx), but there's more than enough overlap to
allow a client to progress towards supporting both.  After all, a good
general-use client will follow the capabilities of the server, and
XPIMAPvX is just a way for a server to declare that it supports a
particular set of capabilities; for example, XPIMAPv1r2 means that the
server supports PIMAP version 1.2, which includes XPROVISION,
XSETPIMAPPREF, XGETPIMAPPREF, XDELIVER, XZIP, XCONVERT, XVFOLDER,
XENCRYPTED and BINARY and implies support for LITERAL+.  We're working
on a good general-use client, whose first release will include support
for servers that speak P-IMAP.  As implementations of other
Lemonade-originated features appear in servers, support for those will
be added (actually, it's usually already in the client, but until it's
been tested with a real commercial implementation, it doesn't count).

Anyway; P-IMAP isn't really proprietary, since the full details are
available and anyone could implement it!

Regards
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Tue, 15 Aug 2006 15:39:30 +0300

Hi Ben,

>It makes no difference at all to the point I was making: 
>whether it's a client based on any particular draft of P-IMAP, 
>or Lemonade compliant to some level, the point is still true: 
>a Symbian application doesn't need to be concerned with the 
>complexities of receiving an MMS or SMS; that's all dealt with 
>by the platform.
True indeed - I did not wish to engage in discussions on the
notifications, I was merely curious what You mean by "PIMAP client".

>implementations awaiting 
>draft-ietf-lemonade-profile-bis-xx.txt" and "the P-IMAP 
>specifications are expected to further converge towards the 
>profile".  Right now, a feasible way to implement a client is 
>to implement it so that it supports P-IMAP, which overlaps 
>with many parts of the Lemonade profiles.  The client can then 
>track the implementation of Lemonade compliance in commercial 
>servers whilst also generating revenue from the installed base 
>of users of those existing P-IMAP servers.
>So yes, there are differences between Lemonade (as expressed 
>in the profile-bis-xx documents) and P-IMAP (as expressed in 
>draft-maes-lemonade-p-imap-xx), but there's more than enough 
>overlap to allow a client to progress towards supporting both. 
> After all, a good general-use client will follow the 
>capabilities of the server, and XPIMAPvX is just a way for a 
>server to declare that it supports a particular set of 
>capabilities; for example, XPIMAPv1r2 means that the server 
>supports PIMAP version 1.2, which includes XPROVISION, 
>XSETPIMAPPREF, XGETPIMAPPREF, XDELIVER, XZIP, XCONVERT, 
>XVFOLDER, XENCRYPTED and BINARY and implies support for 
>LITERAL+.  We're working on a good general-use client, whose 
>first release will include support for servers that speak 
>P-IMAP.  As implementations of other Lemonade-originated 
>features appear in servers, support for those will be added 
>(actually, it's usually already in the client, but until it's 
>Anyway; P-IMAP isn't really proprietary, since the full 
>details are available and anyone could implement it!

Yes, certainly. Anyone can upload drafts and recommendations. Even me
about trash mailbox and move commands :-) but the fact that it is stored
in the repository of an IETF working group does not make it a standard.
Becoming an RFC does.
Please do not get me wrong - I am not saying that P-IMAP is bad - I am
simply saying that it is not a standard.
I have already seen quite a few confused people both internally and
externally - they are talking about P-IMAP and implementing LEMONADE
(and vice versa) -, so my goal here was to clarify that You indeed are
talking about a P-IMAP-based client.

And then again I wonder (per Ned's email about what is in the scope of
the charter and what is not) if P-IMAP actually falls into the charter
since both LEMONADE and P-IMAP intends to solve the exact same problem
with different specs. My history is quite short in IETF, so please
forgive my ignorance but I have to ask: Is it a tradition in IETF to
provide two solutions for the same problem? The answers I got regarding
the move command/trash proposals did not back up this theory. Makes me
wonder... Could someone actually clarify the intention with P-IMAP?
Someone with a lot of experience in this WG, please? Is it going to:
become a standard, is it going to become a separate WG in IETF, etc -
and when exactly.
Thank You.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Aug 2006 18:28:22 -0700

At 3:39 PM +0300 8/15/06, <[email-masked]> wrote:

>  Is it going to: become a standard,

Drafts which have someone's name as the second element are individual 
contributions.  Drafts which have been accepted by a working group 
have "ietf" as the second element, and the working group name as the 
third element.  In our case, they start with "draft-ietf-lemonade-".

The authors of the P-IMAP draft are active participants in the group, 
and are the authors of several working group documents.

The process of the IETF is based on drafts.  People write drafts as 
individuals to make proposals, to critique proposals, to offer 
information.  Often, specific parts of these drafts make it in to 
working group drafts.  Working group drafts progress through 
revisions based on comments.

>  is it going to become a separate WG in IETF, etc -

I have not seen any suggestions to form a new working group for P-IMAP.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity.
          --Martin Luther King, Jr.

---

From: <[email-masked]>
Date: Wed, 16 Aug 2006 10:29:49 +0300

Thank You for the clarification Randall,
it confirms that my understanding about the way of working in IETF is correct.
However, I was looking for a different answer.
I see confused people every day who think that P-IMAP is actually the LEMONADE standard. This is the reason why I asked Ben for clarification. I would like to end this confusion - it is not good for anyone(*) I believe - and this is the exact reason why I asked about P-IMAP (will it become standard, will it be in LEMONADE or should it be separate WG, etc).
Does the WG have a solid opinion on this issue at all?
The LEMONADE standard is called LEMONADE Profile and not P-IMAP, right? Or, maybe both? I would really appreciate if someone could clarify this in a way that everyone agrees to.
Thank You.

(*) Including me. Personally, I got tired of explaining over and over again that P-IMAP is not the LEMONADE stardard, the LEMONADE standard is LEMONADE Profile.

>From: ext Randall Gellens [mailto:[email-masked]] 
>Sent: 16 August, 2006 04:28
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); 
>[email-masked]; [email-masked]; [email-masked]
>Subject: RE: [lemonade] LEMONADE vs. P-IMAP
>
>Drafts which have someone's name as the second element are 
>individual contributions.  Drafts which have been accepted by 
>a working group have "ietf" as the second element, and the 
>working group name as the third element.  In our case, they 
>start with "draft-ietf-lemonade-".
>
>The authors of the P-IMAP draft are active participants in the 
>group, and are the authors of several working group documents.
>
>The process of the IETF is based on drafts.  People write 
>drafts as individuals to make proposals, to critique 
>proposals, to offer information.  Often, specific parts of 
>these drafts make it in to working group drafts.  Working 
>group drafts progress through revisions based on comments.
>
>-------------- Randomly-selected tag: --------------- Nothing 
>in the world is more dangerous than sincere ignorance and 
>conscientious stupidity.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 17 Aug 2006 16:17:17 -0700

At 10:29 AM +0300 8/16/06, <[email-masked]> wrote:

>  I see confused people every day who think that P-IMAP is actually 
> the LEMONADE standard. This is the reason why I asked Ben for 
> clarification. I would like to end this confusion - it is not good 
> for anyone(*) I believe - and this is the exact reason why I asked 
> about P-IMAP (will it become standard, will it be in LEMONADE or 
> should it be separate WG, etc).
>  The LEMONADE standard is called LEMONADE Profile and not P-IMAP, 
> right? Or, maybe both? I would really appreciate if someone could 
> clarify this in a way that everyone agrees to.
>  Thank You.

The lemonade working group charter includes enhancing Internet mail 
submission and retrieval protocols.  These enhancements are published 
as standards-track RFCs after having been produced by the lemonade 
working group.  To simplify things, the group is also producing a 
document called "Lemonade Profile".  This profile document describes 
how lemonade clients take advantage of the specific extensions, and 
specifies a minimum set of extensions that are supported by 
lemonade-compliant implementations.  The profile document references 
each of the specific extension (or other) documents.  In this way, we 
can speak of "IETF lemonade" and mean what is included in or 
referenced by the profile document.

The first version of the profile document has been published as RFC 
4550.  An updated version is being currently developed.

The term "P-IMAP" has no official meaning within the lemonade working group.

The lemonade charter is at 
<http://www.ietf.org/html.charters/lemonade-charter.html>.

RFC 3440 is available at <http://www.ietf.org/rfc/rfc4550.txt>.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only

---

From: "Stephane H. Maes" <[email-masked]>
Date: Thu, 17 Aug 2006 16:27:53 -0700

It should have been clear to all and was clear stated for example in the latest published version that P-IMAP was our submission to the IETF and OMA process as well as an interim solution awaiting the standard.

P-IMAp is not the object of any separate standardization activity. IETF Lemonade and OMA MEM are where this is happening.

P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for backward compatibility purposes.

I hope it clarifies.

Stephane 

_____
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) or [email-masked] (Google)

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 4:17 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] LEMONADE vs. P-IMAP

At 10:29 AM +0300 8/16/06, <[email-masked]> wrote:

>  I see confused people every day who think that P-IMAP is actually the 
> LEMONADE standard. This is the reason why I asked Ben for 
> clarification. I would like to end this confusion - it is not good for 
> anyone(*) I believe - and this is the exact reason why I asked about 
> P-IMAP (will it become standard, will it be in LEMONADE or should it 
> be separate WG, etc).

The lemonade working group charter includes enhancing Internet mail submission and retrieval protocols.  These enhancements are published as standards-track RFCs after having been produced by the lemonade working group.  To simplify things, the group is also producing a document called "Lemonade Profile".  This profile document describes how lemonade clients take advantage of the specific extensions, and specifies a minimum set of extensions that are supported by lemonade-compliant implementations.  The profile document references each of the specific extension (or other) documents.  In this way, we can speak of "IETF lemonade" and mean what is included in or referenced by the profile document.

The first version of the profile document has been published as RFC 4550.  An updated version is being currently developed.

RFC 3440 is available at <http://www.ietf.org/rfc/rfc4550.txt>.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- Every word is like an unnecessary stain on silence and nothingness.
                                                         --Beckett

---

From: "Stephane H. Maes" <[email-masked]>
Date: Thu, 17 Aug 2006 16:27:53 -0700

I hope it clarifies.

Stephane 

_____
Stephane H. Maes, PhD,

---

From: "Stephane H. Maes" <[email-masked]>
Date: Sun, 20 Aug 2006 18:52:29 -0700

Are you saying something different? I think that's what I said...

Stephane 

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, August 20, 2006 6:49 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] LEMONADE vs. P-IMAP

OMA is standardizing on the Lemonade profile bis, not P-IMAP.  We leave
it to the IETF Lemonade WG to decide on what goes into that profile.    

-Dorothy

-----Original Message-----
From: ext Stephane H. Maes [mailto:[email-masked]]
Sent: Thursday, August 17, 2006 4:28 PM
To: Randall Gellens; Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] LEMONADE vs. P-IMAP

I hope it clarifies.

Stephane 

_____
Stephane H. Maes, PhD,

---

From: <[email-masked]>
Date: Sun, 20 Aug 2006 18:49:23 -0700

-Dorothy

-----Original Message-----
From: ext Stephane H. Maes [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 4:28 PM
To: Randall Gellens; Ordogh Zoltan (Nokia-TP-MSW/Tampere);

It should have been clear to all and was clear stated for example in the
latest published version that P-IMAP was our submission to the IETF and
OMA process as well as an interim solution awaiting the standard.

P-IMAp is not the object of any separate standardization activity. IETF
Lemonade and OMA MEM are where this is happening.

P-IMAP 13 is pointing to Lemonade profile bis and only to P-IMAp for
backward compatibility purposes.

I hope it clarifies.

Stephane 

_____
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)
or [email-masked] (Google)

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]]
Sent: Thursday, August 17, 2006 4:17 PM
To: [email-masked]; [email-masked];

The lemonade working group charter includes enhancing Internet mail
submission and retrieval protocols.  These enhancements are published as
standards-track RFCs after having been produced by the lemonade working
group.  To simplify things, the group is also producing a document
called "Lemonade Profile".  This profile document describes how lemonade
clients take advantage of the specific extensions, and specifies a
minimum set of extensions that are supported by lemonade-compliant
implementations.  The profile document references each of the specific
extension (or other) documents.  In this way, we can speak of "IETF
lemonade" and mean what is included in or referenced by the profile
document.

The term "P-IMAP" has no official meaning within the lemonade working
group.

RFC 3440 is available at <http://www.ietf.org/rfc/rfc4550.txt>.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- Every word is like
an unnecessary stain on silence and nothingness.
                                                         --Beckett

---

From: <[email-masked]>
Date: Tue, 22 Aug 2006 08:02:38 +0300

Hi Stephane,

>It should have been clear to all and was clear stated for 
>example in the latest published version that P-IMAP was our 
>submission to the IETF and OMA process as well as an interim 
>solution awaiting the standard.

Are You suggesting that there will be a third solution in OMA (beside
LEMONADE and DS -based MEM)?

>P-IMAp is not the object of any separate standardization 
>activity. IETF Lemonade and OMA MEM are where this is happening.

P-IMAP is separate in LEMONADE - so it is not LEMONADE as pointed out by
Randall - or is Randall's statement incorrect?
In OMA, MEM is based on LEMONADE and DS - but not P-IMAP (hence my
question above about a third MEM solution in OMA).

It seems to me that there is a confusion about it in LEMONADE as well.

---

From: <[email-masked]>
Date: Tue, 22 Aug 2006 08:06:31 +0300

Hi Dorothy,

>it to the IETF Lemonade WG to decide on what goes into that 

Yes, this is my understanding as well regarding OMA standardization
activities.
But Stephane in another email is saying that OMA MEM is based on P-IMAP.
The emails on this mailing list seem to confirm that there are some
misunderstandings that I believe should be clarified as soon as
possible.

---

From: "Stephane H. Maes" <[email-masked]>
Date: Mon, 21 Aug 2006 22:21:56 -0700

I frankly do not understand the discussion that is taking place.

We have propsoed P-IMAp as input to IETF and as a group at lemonade we work on lemonade profile an dprofile bis That is the output of the work and the resulting standard.

We have similarly brought the use cases, features, requiremenst and design point to OMA and the output is the OMA MEM enabler.

We are pushing for having a MEM realization based on Lemonade profile bis.

What is not understood in these steps. Why create FUD around P-IMAP, Lemonade profile or OMA MEM that is not needed nor called for?

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 21, 2006 10:03 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [lemonade] LEMONADE vs. P-IMAP

Hi Stephane,

>It should have been clear to all and was clear stated for example in 
>the latest published version that P-IMAP was our submission to the IETF 
>and OMA process as well as an interim solution awaiting the standard.

Are You suggesting that there will be a third solution in OMA (beside LEMONADE and DS -based MEM)?

>Lemonade and OMA MEM are where this is happening.

P-IMAP is separate in LEMONADE - so it is not LEMONADE as pointed out by Randall - or is Randall's statement incorrect?
In OMA, MEM is based on LEMONADE and DS - but not P-IMAP (hence my question above about a third MEM solution in OMA).

---

From: Ray Cromwell <[email-masked]>
Date: Tue, 22 Aug 2006 00:18:34 -0700

The situation isn't so complicated.  P-IMAP is just an input document, 
an informational reference, just like many of the other drafts submitted 
to Lemonade for discussion of ideas and techniques. For example, all the 
draft-smaes documents, the OMA materials on the Supplemental Page, stuff 
like clearidle, videomsg, etc. Some stuff gets pick up in discussion, 
refined, and makes it into draft-ietf-lemonade-* documents, and alot 
more expires and disappears.  Look at the Lemonade drafts archive and 
all of those dead non-Lemonade drafts. :)

-Ray

---

From: <[email-masked]>
Date: Tue, 22 Aug 2006 12:27:51 +0300

Hi Stephane,
Thank You for Your responses. Please read what I wrote below to confirm
that my understanding is correct.

>I frankly do not understand the discussion that is taking place.
I thought that this would be clear from the original mail I sent.
I see people referring to P-IMAP sometimes as if it was the LEMONADE
solution. This creates confusion. I would like to clarify this
confusion. Simple as that.

>We have propsoed P-IMAp as input to IETF and as a group at 
>lemonade we work on lemonade profile an dprofile bis That is 
>the output of the work and the resulting standard.
Understood, but the draft is not being discussed - it is a draft hanging
around - and according to Randall it is not the LEMONADE solution. Thus,
I think asking what is its purpose is a logical question.
So, what You are saying that it is not a standard but a form of input -
I can accept this - but the problem is some people refer to it as if it
was going to be a standard.

>We have similarly brought the use cases, features, 
>requiremenst and design point to OMA and the output is the OMA 
>MEM enabler.
To my knowledge OMA solution will be based on LEMONADE Profile. Hence my
question about having a third solution (based on P-IMAP) to be done in
OMA.

>We are pushing for having a MEM realization based on Lemonade 
Yes, this I understand. What is not clear is the intent with P-IMAP. But
from Your statement above I understand it is a form of contributing
input to the LEMONADE standard, and P-IMAP is not a standard.

>What is not understood in these steps. Why create FUD around 
>P-IMAP, Lemonade profile or OMA MEM that is not needed nor called for?
No, there is no such intent. My intent is the exact opposite:
clarification.