Subject: [lemonade] Lemonade Kicker Design Team Proposal

From: Randall Gellens <[email-masked]>
Date: Wed, 25 Jul 2007 15:54:37 -0700

The lemonade "kicker" design team that was formed yesterday met 
today, formulated a proposal, and disbanded.  Here is the proposal 
for how to deal with Section 8 in profile-bis and mention minimal 
"kicker" notifications:

Introduction (Section 2) already says:

    It is intended that the Lemonade profile support realizations of the
    OMA's mobile email enabler (MEM) (see [MEM-req] and [MEM-arch]) using
    Internet Mail protocols defined by the IETF.

Move Section 8 (OMA) to new Informational document "IETF Lemonade as 
an OMA MEM enabler" or some such title.  Repeat the sentence above in 
its Introduction.

Make Section 5.4 into "Notifications" with introductory text (from 
notifications document section 6 first four paragraphs).  The 
existing 5.4 text becomes 5.4.1 "In-IMAP Notifications".  Add new 
section:

5.4.2.  Out-of-IMAP Notifications

Lemonade, and TCP, provide for long-lived idle connections between 
the client and mail store, allowing the server to push notifications 
within IMAP.  Some mobile networks support dormancy, which shuts down 
the radio traffic channel during idle periods to conserve handset and 
network resources, while maintaining IP and TCP state.  (See the 
deployments [deployments] document for more information.)

However, there are environments where the email client cannot remain 
active indefinitely, or where it is not advisable (or even always 
possible) for TCP connections to the server to remain up while idle 
for extended periods.  In these situations, a good user experience 
requires that when "interesting" events occur in the mail store, the 
client be informed so that it can connect and resynchronize.  At an 
absolute minimum, this requires that at least the arrival of new mail 
generate some sort of wake-up to the email client.  A number of 
vendors have implemented various solutions to this.  As examples of 
what has been done, for many years (long pre-dating cellular 
handsets) the technique described in RFC 4116 has been supported. 
Today, a number of email vendors include facilities to send SMS or 
other simple non-stream messages to clients on handsets when new mail 
arrives.  OMA has published a mechanism that uses WAP PUSH to send a 
basic message containing a URL [OMA-EMN].  The IETF is investigating 
ways to standardize enhanced functionality in this area.

A "push email" user experience can be achieved using any number of 
techniques, ranging from always-on TCP connectivity to the server and 
the NOTIFY extension described above, to OMA EMN, or even a 
non-standard trigger message over SMS.  In any technique, the client 
learns of the existence of new mail, and decides to fetch information 
about it, some part of it, or all of it, and then presents this to 
the user.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
To err is human, to moo bovine.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: "Glenn Parsons" <[email-masked]>
Date: Wed, 25 Jul 2007 19:00:40 -0400

In addition to the Profile-bis proposal, we also concluded on what to do
with the existing notifications document.  Essentially, the plan is to
retain it but also to move some of the material to either Profile-bis or
the new OMA document Randy noted.

So specifically the on draft-ietf-lemonade-notifications, the
disposition on the clauses is as follows:

Title:  LEMONADE Notifications Architecture 
3. Objectives -> OMA document 
4. Architecture -> retain 
5. Capabilities -> drop 
6. Events - paragraphs 1-4 -> Profile 5.4
		paragraph 5 -> Profile ...
		remainder -> retain
7. Filters -> Profile
8. Inband -> Profile 5.4.1
9. Outband - non-xemn -> Profile Appendix on notifications
		 xemn -> drop
10. Message store -> drop
11. Provision -> Profile or NOTIFY
12. Filters -> drop
13. Out of scope -> OMA document
14. S2S -> retain
15. security -> retain
16. references -> retain
17. future -> drop
18. ack -> retain?
AppA -> Profile Appendix on notifications 
AppB -> drop

Randy will remain the author of the Notifications document.

Eric and I will author the OMA document.

Cheers,
Glenn. 

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 6:55 PM
To: Alexey Melnikov; Chris Newman; Dave Cridland; Randall Gellens;
Parsons, Glenn (CAR:1A14); Eric Burger
Cc: [email-masked]
Subject: Lemonade Kicker Design Team Proposal

The lemonade "kicker" design team that was formed yesterday met today,
formulated a proposal, and disbanded.  Here is the proposal for how to
deal with Section 8 in profile-bis and mention minimal "kicker"
notifications:

    It is intended that the Lemonade profile support realizations of the
    OMA's mobile email enabler (MEM) (see [MEM-req] and [MEM-arch])
using
    Internet Mail protocols defined by the IETF.

Move Section 8 (OMA) to new Informational document "IETF Lemonade as an
OMA MEM enabler" or some such title.  Repeat the sentence above in its
Introduction.

Make Section 5.4 into "Notifications" with introductory text (from
notifications document section 6 first four paragraphs).  The existing
5.4 text becomes 5.4.1 "In-IMAP Notifications".  Add new
section:

Lemonade, and TCP, provide for long-lived idle connections between the
client and mail store, allowing the server to push notifications within
IMAP.  Some mobile networks support dormancy, which shuts down the radio
traffic channel during idle periods to conserve handset and network
resources, while maintaining IP and TCP state.  (See the deployments
[deployments] document for more information.)

However, there are environments where the email client cannot remain
active indefinitely, or where it is not advisable (or even always
possible) for TCP connections to the server to remain up while idle for
extended periods.  In these situations, a good user experience requires
that when "interesting" events occur in the mail store, the client be
informed so that it can connect and resynchronize.  At an absolute
minimum, this requires that at least the arrival of new mail generate
some sort of wake-up to the email client.  A number of vendors have
implemented various solutions to this.  As examples of what has been
done, for many years (long pre-dating cellular
handsets) the technique described in RFC 4116 has been supported. 
Today, a number of email vendors include facilities to send SMS or other
simple non-stream messages to clients on handsets when new mail arrives.
OMA has published a mechanism that uses WAP PUSH to send a basic message
containing a URL [OMA-EMN].  The IETF is investigating ways to
standardize enhanced functionality in this area.

A "push email" user experience can be achieved using any number of
techniques, ranging from always-on TCP connectivity to the server and
the NOTIFY extension described above, to OMA EMN, or even a non-standard
trigger message over SMS.  In any technique, the client learns of the
existence of new mail, and decides to fetch information about it, some
part of it, or all of it, and then presents this to the user.
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- To err is human,
to moo bovine.

---

From: "Ben Last" <[email-masked]>
Date: Thu, 26 Jul 2007 11:18:40 +0100

>Subject: [lemonade] Lemonade Kicker Design Team Proposal

>Today, a number of email vendors include facilities to send SMS or other simple non-stream messages to clients on handsets when new mail
>arrives.  OMA has published a mechanism that uses WAP PUSH to send a basic message containing a URL [OMA-EMN].  The IETF is investigating
>A "push email" user experience can be achieved using any number of techniques, ranging from always-on TCP connectivity to the server and
>the NOTIFY extension described above, to OMA EMN, or even a non-standard trigger message over SMS.  In any technique, the client learns
>of the existence of new mail, and decides to fetch information about it, some part of it, or all of it, and then presents this to the user.

An implementation note, for client-side, relevant to the above, on Symbian.

EMN handling (over SMS) functionality is part of the UIQ 3.2 platform, not Symbian as a whole.  It doesn't appear as though there is an S60 equivalent (Zoltan - can you clarify?)
There is currently nothing in the platform that can provide third-party applications with EMN notification.  It's all handled internally, and there is no way to register a third-party client as a handler for EMN notifications.

There appears to be a potential conflict if a third party client handles the same protocol as a built-in client (for example, a Lemonade client is an IMAP client, and so is the built-in Symbian IMAP client).  The "mailat" scheme is not well-suited to client implementation because the email address is not necessarily stored in a standard location that the platform can use to identify the correct client.

In summary: the use of EMN requires a significant level of platform support, since OMA messages are usually handled directly by the platform.  There appears to be an assumption that "the client" is one entity; this does not adequately cover the question of third-party clients installed on existing devices.

Regards
Ben

--
Ben Last
R&D Manager
EMCC Software

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Thu, 26 Jul 2007 11:29:51 +0100

OMA EMN is in S60, see http://www.nokia.com/A4297065

IMAP IDLE is in UIQ 3.1 as well. I have a Motorola Z8 in my hand.

Cheers,

/Paul.

-----Original Message-----
From: Ben Last [mailto:[email-masked]] 
Sent: 26 July 2007 11:19
To: [email-masked]
Subject: RE: [lemonade] Lemonade Kicker Design Team Proposal

non-standard trigger message over SMS.  In any technique, the client
learns of the existence of new mail, and decides to fetch information
about it, some part of it, or all of it, and then presents this to the
user.

An implementation note, for client-side, relevant to the above, on
Symbian.

EMN handling (over SMS) functionality is part of the UIQ 3.2 platform,
not Symbian as a whole.  It doesn't appear as though there is an S60
equivalent (Zoltan - can you clarify?) There is currently nothing in the
platform that can provide third-party applications with EMN
notification.  It's all handled internally, and there is no way to
register a third-party client as a handler for EMN notifications.

There appears to be a potential conflict if a third party client handles
the same protocol as a built-in client (for example, a Lemonade client
is an IMAP client, and so is the built-in Symbian IMAP client).  The
"mailat" scheme is not well-suited to client implementation because the
email address is not necessarily stored in a standard location that the
platform can use to identify the correct client.

In summary: the use of EMN requires a significant level of platform
support, since OMA messages are usually handled directly by the
platform.  There appears to be an assumption that "the client" is one
entity; this does not adequately cover the question of third-party
clients installed on existing devices.

Regards
Ben

--
Ben Last
R&D Manager
EMCC Software

---

From: "Ben Last" <[email-masked]>
Date: Thu, 26 Jul 2007 11:41:32 +0100

But is it available to third-party apps?  Or just the built-in ones?

IMAP IDLE is indeed in the Symbian IMAP client (common to UIQ & S60) and has been for a while.

Cheers
b

--
Ben Last
R&D Manager
EMCC Software

-----Original Message-----
From: Douglas Paul-APD028 [mailto:[email-masked]] 
Sent: 26 July 2007 11:30
To: Ben Last; [email-masked]
Subject: RE: [lemonade] Lemonade Kicker Design Team Proposal

Cheers,

/Paul.

---

From: "Douglas Paul-APD028" <[email-masked]>
Date: Thu, 26 Jul 2007 11:45:03 +0100

I'm not sure. But they can always intercept the data by intercepting the
SMS or the data on the incoming port right?

Paul. 

-----Original Message-----
From: Ben Last [mailto:[email-masked]] 
Sent: 26 July 2007 11:42
To: Douglas Paul-APD028; [email-masked]
Subject: RE: [lemonade] Lemonade Kicker Design Team Proposal

IMAP IDLE is indeed in the Symbian IMAP client (common to UIQ & S60) and
has been for a while.

Cheers
b

--
Ben Last
R&D Manager
EMCC Software

-----Original Message-----
From: Douglas Paul-APD028 [mailto:[email-masked]]
Sent: 26 July 2007 11:30
To: Ben Last; [email-masked]
Subject: RE: [lemonade] Lemonade Kicker Design Team Proposal

Cheers,

/Paul.

---

From: "Ben Last" <[email-masked]>
Date: Thu, 26 Jul 2007 12:36:59 +0100

Yes, but that'd interfere with the built-in OMA message handling.  Or possibly a third-party app couldn't intercept the SMS because there's already a built-in handler for it. 
cheers
b

--
Ben Last
R&D Manager
EMCC Software

-----Original Message-----
From: Douglas Paul-APD028 [mailto:[email-masked]] 
Sent: 26 July 2007 11:45
To: Ben Last; [email-masked]
Subject: RE: [lemonade] Lemonade Kicker Design Team Proposal

I'm not sure. But they can always intercept the data by intercepting the SMS or the data on the incoming port right?

Paul.

---

From: <[email-masked]>
Date: Thu, 26 Jul 2007 19:06:58 +0300

Hi Ben,

>>arrives.  OMA has published a mechanism that uses WAP PUSH to 
>send a basic message containing a URL [OMA-EMN].  The IETF is 
>investigating ways to standardize enhanced functionality in this area.
>non-standard trigger message over SMS.  In any technique, the 
>client learns of the existence of new mail, and decides to 
>fetch information about it, some part of it, or all of it, and 
>then presents this to the user.
>
>EMN handling (over SMS) functionality is part of the UIQ 3.2 
>platform, not Symbian as a whole.  It doesn't appear as though 
>there is an S60 equivalent (Zoltan - can you clarify?) There 
>is currently nothing in the platform that can provide 
>third-party applications with EMN notification.  It's all 
>handled internally, and there is no way to register a 
>third-party client as a handler for EMN notifications.

S60 does not provide any API for delivering OMA e-mail notifications to
applications. This is true for all publicly announced releases (1.0,
1.1, 1.2, 2.0, 2.1, 2.6, 2.8, 3.0, 3.1 and

---

From: Randall Gellens <[email-masked]>
Date: Thu, 26 Jul 2007 14:58:02 -0700

At 11:18 AM +0100 7/26/07, Ben Last wrote:

>  There appears to be a potential conflict if a third party client 
> handles the same protocol as a built-in client (for example, a 
> Lemonade client is an IMAP client, and so is the built-in Symbian 
> IMAP client).

This is just one example of why the text merely mentions EMN as an 
example of what has been deployed, instead of a normative "this is 
how to do this."
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
One should always be a little improbable.          --Oscar Wilde