RE: [lemonade] About draft-gulbrandsen-imap-notify-02

[Randall Gellens <randy at qualcomm.com>]

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

>   >From: Randall Gellens [mailto:randy at qualcomm.com]
> > 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).

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
> > inband notifications, but only for the SELECTED mailbox.
>
>  Surely, for any mailbox for which NOTIFY requests have been made?

Yes, you are right.


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

>  Randall Gellens writes:
> >  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 ...
> >  ...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.
>
>  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.)



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade