[lemonade] RE: Lemonade Kicker Design Team Proposal

["Glenn Parsons" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, July 25, 2007 6:55 PM
To: Alexey Melnikov; Chris Newman; Dave Cridland; Randall Gellens;
Parsons, Glenn (CAR:1A14); Eric Burger
Cc: [e-mail]
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:

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade