Subject: [Notifications] Reliability

From: <[email-masked]>
Date: Thu, 9 Aug 2007 11:56:44 +0300

Hi all,
We have briefly touched the reliability issue during the BoF, but we did not actually go trhough with it.
If this notification is not going to be reliable, what's the use for it? I mean:
You have a new mail, but You don't get a notification - what the use of the whole framework then?
Any thoughts on this?
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

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

---

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Aug 2007 11:20:04 +0200

> of the whole framework then?
Well if you typically get email regularly and the purpose of the
notification mechanism is to notify you that you _may_ have
new mail then it won't matter much (imho) if you loose a
notify message now and again.

    Cheers Leif

---

From: <[email-masked]>
Date: Fri, 10 Aug 2007 14:55:29 +0300

>-----Original Message-----
>From: ext Leif Johansson [mailto:[email-masked]] 
>Sent: 09 August, 2007 12:20
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [Notifications] Reliability
>
>Well if you typically get email regularly and the purpose of 
>the notification mechanism is to notify you that you _may_ 
>have new mail then it won't matter much (imho) if you loose a 

Regarding email:
It may be ok from our point of view - but the end-user will notice that
He was not notified about some mails - and if it's not a free service,
he is going to complain (because he is missing events that were
important to him)...

People will get
1-5 emails a day - reliability is a must
5-10 emails a day - reliability is a should
10-50 - reliability is a may
>50 - these people do not need notification at all since most of the
time their clients will be online anyway.

Regarding future extensions:
I do think there might be a few future candidates for extensions to this
notification framework that will not tolerate the fact that this
protocol is unreliable. So, instead of simply defining an extension to
this notification framework, a completely new mechnism will be invented.

I do think that the notification mechanism has to be reliable. Otherwise
we did not achieve anything because people will try to re-invent the
wheel every time they need something that they can count on when
everything else fails.

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 10 Aug 2007 12:20:43 -0700

On Aug 10, 2007, at 4:55 AM, <[email-masked]>  
<[email-masked]> wrote:

> ...

Hi Zoltan,

Do you think the reliability requirements for mail-related events  
(not delivery, not access,  but events) are really significantly  
greater than the reliability requirements for SIP and instant  
messaging?   If I was in IM conversation with a colleague and one of  
their messages to me got dropped, that would seriously derail the  
conversation and I would not find that acceptable.  I've never  
noticed that happen, however.

One of the points I was making, which I think you agree with, is that  
if we're going to build on top of the deployed pub/sub  
infrastructure, the reliability of that system is what it is.  We can  
only make certain choices in our schemas to improve on that or break  
it, without changing the system functionality itself, which I believe  
we don't want to get into.  In the long run, if people want greater  
reliability than what we get by default, people will build new  
systems or strengthen the reliability of their existing systems.

thanks,
Lisa

---

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Aug 2007 21:33:31 +0200

>
> Hi Zoltan,
>
> Do you think the reliability requirements for mail-related events (not
> delivery, not access,  but events) are really significantly greater
> than the reliability requirements for SIP and instant messaging?   If
> I was in IM conversation with a colleague and one of their messages to
> me got dropped, that would seriously derail the conversation and I
> would not find that acceptable.  I've never noticed that happen, however.
>
Depending on your environment it happens all the time. In XMPP there is
no ack for <message/>
stanzas but there is for <iq/>.

    Cheers Leif

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 15:33:42 -0400

When discussing reliability, it would be helpful to be more specific  
as to what kinds of impairments are being discussed. For example, is  
this about the loss of a message due to packet loss or server failure  
or a service model that silently drops notifications if there is no  
receiver available (as opposed to a store-and-deliver-later model)?

I think we have a pretty good handle on the former, with both SIP and  
XMPP offering reasonable models that survive most short-term network  
failures or at least provide a failure indication if delivery is not  
possible.

Henning

> messaging?   If I was in IM conversation with a colleague and one  
> of their messages to me got dropped, that would seriously derail  
> the conversation and I would not find that acceptable.  I've never  
> One of the points I was making, which I think you agree with, is  
> that if we're going to build on top of the deployed pub/sub  
> infrastructure, the reliability of that system is what it is.  We  
> can only make certain choices in our schemas to improve on that or  
> break it, without changing the system functionality itself, which I  
> believe we don't want to get into.  In the long run, if people want  
> greater reliability than what we get by default, people will build  
> new systems or strengthen the reliability of their existing systems.
>
> thanks,
> Lisa
>
>