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

From: "Erev Ari" <[email-masked]>
Date: Sun, 18 Sep 2005 10:21:59 +0300

On 9/17/05, [email-masked] <[email-masked]> wrote:
> 
> If we let a notification server do all of the filtering, the number of
> messages that get sent ot the notification server from the mail server
> can number in the thousands per hour for a large enterprise.
> One of the reasons why email servers are so cost effective is 
> that they
> are idle storage most of the time.  Messages are delivered 
> into the mail
> server at a very low processing cost, but accessing the messsages with
> the MUA is much more expensive (client operations are involved,
> obviously).
> 

And:
On 9/18/05,  Rob Siemborski <[email-masked]> wrote:
> Am I missing something?  Wouldn't the load on the notification server
> be just the same as the load on the "mail server" from incoming
> messages?  (are "notifications" being delivered for something else
> that happens more frequently than incoming mail)?
> I agree with 

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".

On 9/18/05,  Rob Siemborski <[email-masked]> wrote:
> This basic approach I agree with.  Notification should be a job of the
> MDA, not the IMAP server.  In fact, you shouldn't even need some magic
> folder annotation to do this, just use the sieve notify extension (or
> something similar) combined with a sieve filter in the MDA.
> 
> Or maybe I'm missing why we are trying to tie this notification
> service to IMAP.  Are we looking to send notifications when someone
> issues an APPEND into a folder too?  Is this really such a frequent
> occurance that its a problem that users have?

I believe you do miss something here. The notifcation events are not
limited to "New Mail arrived" notifications.
There are notification that should be generated for "mailbox events" -
such as Login, Logout (for example, in order to deactivate the "envelope
icon" on your cell phone). Depending on the complexitiy of the
application, sometimes even "Message deletion" events should be
considered as triggers.

For our suggestion to the list of events that should be handled you may
want to take a look at the last SNAP draft (now obsolete) at:
www.watersprings.org/pub/id/draft-shapira-snap-05.txt 

This protocol proposals was rejected at the time, on various grounds -
mainly lack of security and extensibility.
However, I believe that some of its content - especially the FULL LIST
OF EVENTS that trigger notifications is still a good source of
information.

Regards,
Ari Erev
[email-masked]

Small worktrigernotificatio

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

---

From: Mark Crispin <[email-masked]>
Date: Sun, 18 Sep 2005 10:42:27 -0700 (PDT)

> rules and decide which notification to send and how to format it...

This is why, in my lightweight notification protocol, I punted entirely on 
that parsing and decision.

Rather, *every* event is spammed to the notification server.  The 
notification server merely checks (through a hash table) whether it has 
(a) client(s) for that event.  Events with no clients are tossed.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Rob Siemborski <[email-masked]>
Date: Sun, 18 Sep 2005 12:49:22 -0700

> "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

---

From: Chris Newman <[email-masked]>
Date: Wed, 21 Sep 2005 10:49:21 -0700

> www.watersprings.org/pub/id/draft-shapira-snap-05.txt

I just read this after pushing out the first draft of a document with the list 
of events to generate:

 <http://www.ietf.org/internet-drafts/draft-newman-lemonade-msgevent-00.txt>

However, the Internet draft you describe was published before the new 
boilerplate related to IPR was introduced.  Before I read your draft and fold 
in any events I missed, can you disclose any IPR on SNAP I might need to worry 
about?

                Thanks,
                - Chris