Subject: Re: [lemonade] About draft-gulbrandsen-imap-notify-02

From: Eric Burger <[email-masked]>
Date: Fri, 09 Feb 2007 08:08:38 -0600

Do we need to say anything other than, "The server does what the filter says
to do"?

On 1/23/07 4:42 AM, "Lingyan Wu" <[email-masked]> wrote:

> Hi All,
>  
> In notify-02, there are some new text just like "It does not notify the client
> about any events on other mailboxes".
>  
> I accept, it's a waste of both server resources and network traffic to send
> events for all accessible mailboxes.
>  
> How about to only send very important and urgent events in unselected mailbox
> (e.g. the events that can pass outband-notification filters) through
> unsolicited STATUS response including the event--STATUS(EVENT)?
> Then we can get such a result:
> If client is not connected, the server can send such urgent events through
> outband notifications.
> If client is connected, the server can send such urgent events in unselected
> mailboxes through STATUS(EVENT)(For events in selected mailbox, it's not
> necessary to say).
> While client is connected only inband notifications shall take place (it means
> the server don't send out-band notifications while connection, right?), so
> while connection the client can not get urgent events directly in unselected
> mailboxes without the extended STATUS responses.
>  
> Maybe you will say, the server can notify client that some events happen in an
> unselected mailbox through STATUS(HIGHESTMODSEQ). Yes, it can tell the client
> events which happend before connection only through one STATUS(HIGHESTMODSEQ)
> responses but for the urgent events which happen after connection
> STATUS(EVENT) is more appropriate than STATUS(HIGHESTMODSEQ).
>  
> Any guidance?
>  
> Best Regards,
> Lingyan
> 
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade

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

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

---

From: Lingyan Wu <[email-masked]>
Date: Sat, 10 Feb 2007 10:11:21 +0800

Hi Eric,

What I said is also that "the server does what the filter says to do".

I will mention Type A, Type B and Type C which are defined in 
"draft-ietf-lemonade-notifications-03".

While the client is not connected, the server sends events of Type C 
through outband notifications.
While the client is connected, the server can send events of Type B and Type 
C in selected mailbox and send events of Type C in unselected mailboxes 
through STATUS(EVENT).

BTW. What I think is based upon the precondition that "while client is 
connected only inband notifications shall take place".

Best Regards,
Lingyan

---

From: Randall Gellens <[email-masked]>
Date: Wed, 21 Feb 2007 15:21:26 -0800

At 10:11 AM +0800 2/10/07, Lingyan Wu wrote:

>  BTW. What I think is based upon the precondition that "while client 
> is connected only inband notifications shall take place".

This requires that the notification engine can determine if the user 
(not any particular client of the user) is logged in.  It also opens 
one timing hole during login when connected clients will get two 
notifications, one inband and the other outband.  This is probably 
not a problem, as the client should be able to handle this.  It also 
opens a second timing hole during disconnection when the client will 
not get any notifications.  It also opens the issue of client versus 
user: the server knows users, but it may be clients that care about 
specific notifications.

There was a discussion of these issues at a recent lemonade meeting 
(maybe DFW?) where there seemed to be some consensus that it is 
better for outband notifications to always be sent, regardless of 
connection state.  If the client happens to be connected, it can then 
easily resynchronize.  I think the extra cost is duplicate inband 
notifications, but only for the SELECTED mailbox.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities. -- Winston Churchill

---

From: "Ben Last" <[email-masked]>
Date: Thu, 22 Feb 2007 08:52:35 -0000

>From: Randall Gellens [mailto:[email-masked]] 
>There was a discussion of these issues at a recent lemonade meeting (maybe DFW?) where there seemed to be
>some consensus that it is better for outband notifications to always be sent, regardless of connection state.
Technically, that may well be true.  Economically, outband notifications may incur costs that are not present for (or exceed the costs of) inband notifications (I'm thinking again of SMS).

>If the client happens to be connected, it can then easily resynchronize.  I think the extra cost is duplicate
>inband notifications, but only for the SELECTED mailbox.
Surely, for any mailbox for which NOTIFY requests have been made?

Regards
ben

Ben Last
R & D Manager
EMCC Software Ltd

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 Feb 2007 11:00:35 +0100

Randall Gellens writes:
> not get any notifications.

No, that hole is there anyway if you look at the grand scheme of things. 
Suppose a notification is sent to a laptop client just as the client is 
reaching for the laptop lid, and is displayed on-screen as the lid is 
closing, already almost closed, too late for the user to notice. The 
client receives the event, the user not.

In any case, if I've understood the general attitude here correctly, we 
don't care too much about it: Stray lost notifications are okay as long 
as there aren't too many.

> It also opens the issue of client versus user: the server knows users, 
> but it may be clients that care about specific notifications.

Or it may be users. I've heard use-cases for both. The 
sieve/metadata/blah notification system towards which I think we're 
heading heading should support both. (Alexey will talk about this and 
give some examples in Prague.)

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Feb 2007 15:55:11 -0800

At 8:52 AM +0000 2/22/07, Ben Last wrote:

>> (maybe DFW?) where there seemed to be
>>some consensus that it is better for outband notifications to 
>> always be sent, regardless of connection state.
>
>  Technically, that may well be true.  Economically, outband 
> notifications may incur costs that are not present for (or exceed 
> the costs of) inband notifications (I'm thinking again of SMS).

Very true.  Costs as in user charges, as well as network costs, etc.

>   >If the client happens to be connected, it can then easily 
> resynchronize.  I think the extra cost is duplicate

Yes, you are right.

At 11:00 AM +0100 2/22/07, Arnt Gulbrandsen wrote:

>>   BTW. What I think is based upon the precondition that "while 
>> client  is connected ...
>>  ...snip...
>>  ... able to handle this.  It also opens a second timing hole 
>> during disconnection when the client will not get any 
>> notifications.
>
>  No, that hole is there anyway if you look at the grand scheme of 
> things. Suppose a notification is sent to a laptop client just as 
> the client is reaching for the laptop lid, and is displayed 
> on-screen as the lid is closing, already almost closed, too late 
> for the user to notice. The client receives the event, the user not.

In this case, I think the client has likely received the event.  I 
wasn't thinking so much of the user reading any sort of notice as I 
was about the client receiving and processing events (to decide if it 
should resynch then or later, and to know if it is out of synch in a 
mailbox).

>  In any case, if I've understood the general attitude here 
> correctly, we don't care too much about it: Stray lost 
> notifications are okay as long as there aren't too many.

Yes, we have (rightly, I think) concluded that we should focus on 
notifications that are non-critical (since notifications that are in 
themselves sufficient to resynch require reliability and increased 
protection against eavesdropping and alteration).

>
>>  It also opens the issue of client versus user: the server knows 
>> users, but it may be clients that care about specific 
>> notifications.
>
> heading heading should support both. (Alexey will talk about this 
> and give some examples in Prague.)

-------------- Randomly-selected tag: ---------------
The Law, in its majestic equality, forbids the rich, as well as the
poor, to sleep under the bridges, to beg in the streets, and to steal
bread.                                               --Anatole France

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade