Subject: RE: [lemonade] Text on server to client notifications (per Paris AI).

From: "Eric Burger" <[email-masked]>
Date: Fri, 16 Sep 2005 14:33:04 -0400

Agreed.  This is what was chartered and the original plan of record.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erev Ari
Sent: Thursday, September 15, 2005 3:59 AM
To: Mark Crispin; Stephane H. Maes
Cc: [email-masked]
Subject: RE: [lemonade] Text on server to client notifications (per
Paris AI).

On Thu, 15 Sep 2005, Mark Crispin wrote:
> 
> IMAP should NOT be extended to be a notification service.  There is 
> nothing in IMAP's scope that enables it to be a notification 
> service.  It 
> would be very strange to tell a POP3 or NNTP client that it 
> must support 
> IMAP in order to obtain notifications.
> 
> However, there is no reason why an IMAP server can not be a 
> client of a 
> notification service.  The effective result seen by an IMAP client 
> programmer would be the same.
> 
> Put another way: you will get strong pushback from IMAP 
> server vendors 
> against any proposal that requires IMAP to be a notification 
> service.  You 
> will not get such negative pushback on a separate 
> notification service 
> that (among other things) happens to be accessible via IMAP.
> 

I tend to agree with Mark. 

Actually, I even go further than that.... Which brings me to the
following question:

Do we really need the "Server to Client" notification protocol be
implemented *by the IMAP server* ???

I doubt it.
Wouldn't it be better to have the IMAP server just implement a simple
"Server to Server" protocol and have another entity ("the notification
server/service") implement all the rest (which is not a trivial task,
and is quite different from what IMAP servers usually do) ?

I think, that this is a very reasonable conclusion from Mark's comment.

And in fact, (surprise, surprise...) this is the "architecture" that was
presented more than 3 years ago to Lemonade - where the IMAP server just
uses a "Server-to-Server" protocol and another entity is doing all the
rest.

And this "rest" is not that obvious....

- Simple and complicated Filters (for example, event types which are not
specific to IMAP).
  (complicated filters are actually logic applied to filters such as "if
the result of this filter is X - do Y)

- Delayed/Scheduled notifications 
  (you do not necessarily want to be wakened in the middle of the night
just because a wrothless message arrived in your inbox).

- Logic for deativation rules.  
  (deactivation is used to "remove" flashing icons on your handset, and
may involve finding out what is the
  handset status (on, off, busy, reachable)

- Supports multiple transports 
  (also outside the "IETF transport protocols") - such as SMS, and
related non-IETF protocols which are very common in mobile ceullar
communications nowdays).

In today's mobile/ceullar world all these features are percieved by
Telecom service providers and users as basic requirements and are
functioning in real networks.

Do we want all this logic to be handled by the IMAP server? 
And if so - will part of these be (re)implemented by other messaging
(and non-messaging) servers? 
Are IMAP servers going to implement this?

On the other hand, the "server to server" architecture assumes a
functional separation:

Messaging (and other) servers send rather-simple triggers to the
notification server. 
(they usually do *NOT* support a complex filter mechanism).

The notification server/service is the one responsible for processing
the triggers, and deciding (based on filters, logic, etc.) which type of
notification should be sent, when, and on which channel.

This functioanl separation allows each server to develop in its own pace
and to concentrate on its own "problem".

>From a practical/maintenance point of view, I should also mention, that
combining messaging and notification in one server is a hard task to
accomplish and *maintain* over time successfully.
My real-life experience shows that although it is feasible, it has many
disadvantages compared to the "de-coupled" model.

Best regards,
Ari Erev
[email-masked]

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

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

---

From: [email-masked]
Date: Sun, 18 Sep 2005 22:06:35 -0500

Ok, this is excellent discussion and I see the points made.
An are of uncertainty is exactly we will be sending in the trigger.
>From the conversations I gather that everyone agrees that minimal data
carier triggers are the most sensible (and secure).  By this I mean the
trigger has almost no payload (like email header or body information).
But rather it's a trigger notification to the client that the server
contains changes that the client needs to sync with.

Several ideas need to be pollished in the usecases I have in my head
that have been highlited in the discussion.
1. Should the trigger contain data (like a UID)
2. If the client receives a trigger should it simply launch the IMAP
client and sync up with the server?
	a. Do we need to agregate in this case.
	b. How do we handle collisions?
	c. Should the notification server be aware that the client has
yet to sync?
3. If the user modifies the messages in a folder that alters the state
of the notification, should we send another notification to clear the
original notification (ugh).

Lots of stuff there.  Hm, need to think.

Corby Wilson

> From: ext Rob Siemborski [mailto:[email-masked]] 
> Sent: Sunday, September 18, 2005 15:49 PM
> To: Erev Ari
> Cc: Wilson Corby (Nokia-ES/Pittsburgh); 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [lemonade] Text on server to client 
> notifications (per Paris AI).
> 
> On 9/18/05, Erev Ari <[email-masked]> wrote:
> > On 9/17/05, [email-masked] <[email-masked]> wrote:
> > I agree with Rob.
> >
> > The work required by the mail server to send a notification 
> trigger to
> > the notification server, is relatively
> > small - if you compare it to the logic required to parse 
> notification
> > rules and decide which notification to send and how to format it...
> >
> > It also depends (of course) on the effective design of the 
> "server to
> > server" notification protocol. Since the practical design of this
> > protocol is not in place (if you do not consider the 
> 3-years old suggest
> > of "SNAP") we can not estimate how "heavy" it is.
> >
> > But, from practical experience, sending the triggers to a 
> notification
> > server is much lighter than the work to process and issue the
> > "notification to client".
> 
> Now that I understand what is being asked (that it isn't limited to
> just deliveries), I can see why Corby might be concerned -- if sending
> these notifications required, suddenly, that all users be available
> for examination all the time, this would be hugely expensive.
> 
> The good news, of course, is that if an event that would cause a
> notification to be sent is being generated, then the server already
> has all the data it needs about the user available to it.
> 
> -Rob
> 
> --
> Rob Siemborski        |     PGP:0x5CE32FCC    |     
> [email-masked]
> Software Engineer     |                       |            
> 650-623-6925
>