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

From: "Erev Ari" <[email-masked]>
Date: Thu, 15 Sep 2005 10:58:49 +0300

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

---

From: "Stephane H. Maes" <[email-masked]>
Date: Thu, 15 Sep 2005 01:07:18 -0700

Is this based on the view that the task appears too complicated?

Yes you can do server to client notification by doing server to server where the target is a notification service. However, in such case the notification is orthogonal to the rest of the process. It is a particular case of what I had initially enumerate of approaches to look at.

I am uncertain of you would want to decide ahead of time to stick to limit your options to that or analyze what else might be possible before reaching such a decision.

Stephane

_____
Stephane H. Maes, PhD,
Director of Architecture - OCS & Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger)

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

I doubt it.

Best regards,
Ari Erev
[email-masked]