Subject: Re: [lemonade] Notifications for multiple devices per user

From: Lisa Dusseault <[email-masked]>
Date: Tue, 4 Jul 2006 10:44:48 -0700

Sorry I'm behind on the list, catching up since my trip to Dublin.   
Responses inline...

On Jun 16, 2006, at 4:11 PM, Randall Gellens wrote:

> At 10:15 AM -0700 6/15/06, Lisa Dusseault wrote:
>
>>>  At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote:
>>>
>>>>   There's an alternative architecture for the same use case, and  
>>>> that's to let the notification server (SIP or XMPP, in  
>>>> particular) do fanout.  Then the IMAP server simply sends the  
>>>> notification to the user's notification address (plus some  
>>>> application field if specified) and the user decides which  
>>>> devices subscribe to those notifications.
>
>
>>  It's easier for the device to simply to subscribe, or no, to some  
>> address to which notifications are sent (not nonstop but whenever  
>> there's a receiver) according to a previously configured script or  
>> rule.
>
> I apologize if this was covered in a draft that I missed, but I'd  
> like to understand this better.
>
> So Sieve would be used to test messages, and generate notification  
> events as appropriate.  If you had, say, progressively more  
> restrictive filter criteria, the Sieve script would contain tests  
> for each set.
>
> The Sieve script could be written such that it did the most  
> restrictive (fewest notifications) tests first, in the equivalent  
> of a deep IF-THEN-ELSEIF, and therefore at most one notification  
> would be generated per message.  Or, the Sieve script could be  
> written such that it did all tests against all messages, and  
> therefore might generate multiple notifications per message.   
> Notifications generated by the Sieve script would be have an  
> identifier that looked like an IM address, and be published to  
> something that looked like an IM server.  In the case of  
> progressively more restrictive filter criteria, each would have its  
> own address.  For example, 'randy.urgent- 
> [email-masked]', 'randy.interesting- 
> [email-masked]', etc.
>
> Devices would subscribe to the notifications using the identifier.

Yes, this is the way I see it working best; good description.

>
> How does the Sieve script get created and updated?  Which device  
> does this, and how much knowledge does it need about the others?

I imagine the primary mail client would do this.  The other main  
alternative is a server interface (particularly in the short term,  
email servers can offer Web UIs).  The user would likely have the  
best UI available in the primary mail client with which to edit  
filters.  In fact, I can't imagine that my mobile device will have  
much of an interface at all to edit sieve filters.

There's definitely a use case for somebody who doesn't want to (or  
can't) install an IMAP client on their phone at all, but they do want  
to see the Subject lines of mails from their boss, or the subject/ 
from of mails that contain iMIP content.  However when leaving on  
vacation he might well want to turn this off, *from the phone.*    
Ideally the user wouldn't have to install any new code on the mobile  
device to accomplish this use case.

>
> How is the Sieve script or engine configured to send notifications  
> to the addresses?

The primary client or server WebUI would set up the script and  
provide a notification address.

>
> How do devices learn which notification identifier they need to  
> subscribe to?

This can involve some coordination, for example noting the address  
these are sent to in the email client, and switching to some other  
client, application or device to subscribe to the same address.

If the user chooses an address which delivers to an IM server (or  
more generally, a notification aggregation server),  their mobile  
devices might already be subscribed.  E.g. if I chose to send the  
subject lines of mails from Ekr to my main IM address, my phone is  
already subscribed to those messages whenever I launch the IM client.

>
> Note that I think these questions apply generally to any out of  
> band notification mechanism.

agreed.

Lisa

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

---

From: Randall Gellens <[email-masked]>
Date: Sat, 8 Jul 2006 12:31:37 -0700

>  Sorry I'm behind on the list, catching up since my trip to Dublin.

...And I'm catching up since my trip to an Internet-free zone in Australia.

>>>>>    There's an alternative architecture for the same use case, 
>>>>> and that's to let the notification server (SIP or XMPP, in 
>>>   It's easier for the device to simply to subscribe, or no, to 
>>> some address to which notifications are sent (not nonstop but 
>>> whenever there's a receiver) according to a previously configured 
>>> script or rule.
>>
>> progressively more restrictive filter criteria, each would have 
>> its own address.  For example, 
>> [email-masked]', 
>> [email-masked]', etc.
>>

Do we need to identify which approach should be used?

> much of an interface at all to edit sieve filters.

I can see the appeal of having the user set up notifications using a 
primary mail client or a web interface, but I'm concerned that this 
makes mobile email more difficult for average users; a new device 
won't simply work out of the box.

I can see several potential approaches to notifications, and I'm 
unsure which direction is better.  For example, there is some appeal 
in a client's ability to create notifications for itself, perhaps 
using a simple check-box UI ("be notified of [] all new messages [] 
new messages in inbox [] new high-priority messages [] new messages 
from ______").  On the other hand, there will always be some users 
who want more flexibility and won't mind going through extra steps to 
set it up.

> can't) install an IMAP client on their phone at all, but they do 
> want to see the Subject lines of mails from their boss, or the 
> subject/from of mails that contain iMIP content.  However when 
> leaving on vacation he might well want to turn this off, *from the 
> phone.*   
>  Ideally the user wouldn't have to install any new code on the 
> mobile device to accomplish this use case.

Maybe, but that seems to be different from the use case where 
notifications trigger a client fetch of the message, so that 
"interesting" messages just appear in the mail client.

Without a mail client on the device, notifications would be directed 
at the user, rather than at the client.  The user could of course 
then use a web browser on the device to read the new mail, but that 
seems beyond the scope of lemonade.

> already subscribed to those messages whenever I launch the IM 

This is troubling, since it means that clients can't do much on their 
own, and the significant amount of user coordination and 
configuration is needed.  Personally, I think that ease of setup will 
be critical in the success of mobile email (at least for the 
non-engineer).

It seems to me that we need a mechanism that either has clients 
create the notification filters themselves, or that allows clients to 
discover the notifications that have been created and their criteria. 
Otherwise we don't have an interoperable solution, but rather we 
force users to configure their environment and coordinate their 
devices.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Lottery: A tax on people who are bad at math.