Subject: Re: [Notifications] Use cases

From: "Eric Burger" <[email-masked]>
Date: Tue, 31 Jul 2007 03:41:49 -0700

First scenario: is that not what sieve does today?

Second scenario: once you assume a long-lived TCP connection, the IMAP connection is free. I would also offer the IMAP NOTIFY message can be an order of magnitude smaller than a fully-routed SIP message, which would save bandwidth.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

-----Original Message-----
From: Rohan Mahy <[email-masked]>
To: [email-masked] <[email-masked]>
CC: Rohan Mahy <[email-masked]>
Sent: Mon Jul 30 10:19:57 2007
Subject: Re: [Notifications] Use cases

Scenario:
A widget on my cell phone that correlates all package tracking emails
from Federal Express.  It is interested in the Subject and To header
of all emails sent From tracker.fedex.com. When it gets a new
notification, it parses the tracking number from the Subject and does
an HTTP fetch to get the current status of the package. It can then
beep or chime or prompt you to send an email or a phone call or SMS
when various things happen (package picked up, package delivered,
package delayed, package cleared customs).

This model would apply nicely to other widgets for package tracking,
flight status, sales order notifications, and stock trade
confirmations.

Problem:
The cell phone does not want to poll for new messages (for example
using IMAP) because this would negatively affect battery life.  Better
to use an existing open TCP connection already used by SIP or XMPP to
receive these async notifications.

Also, the phone is only interested in a filtered view of
notifications.  There are ways of doing this today in email, but just
forwarding all your email to an IM gateway using a static filter isn't
sufficient.   If the phone has multiple widgets, these filters my need
to be somewhat dynamic.

Market:
Widgets like this are popping up left and right, but they use HTTP
polling.  The market would like these apps and decent battery
consumption too.

thanks,
-rohan

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

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

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

---

From: Tony Hansen <[email-masked]>
Date: Tue, 31 Jul 2007 09:29:22 -0400

As Randy reminded me at the meeting :-), after we get a bunch of
potential use cases, each of them needs to be passed through a filter of
"should this be better done by a good sieve implementation that includes
the notification extension".

But brainstorm first and keep the ideas flowing, *before* running them
through the filter.

	Tony Hansen
	[email-masked]

Eric Burger wrote:
> Second scenario: once you assume a long-lived TCP connection, the
> IMAP connection is free. I would also offer the IMAP NOTIFY message
> can be an order of magnitude smaller than a fully-routed SIP message,
> which would save bandwidth.