IETF Logo Mail Archive

RE: [Notifications] Reliability

<Zoltan.Ordogh@nokia.com> Fri, 10 August 2007 11:56 UTC

Return-path: <notifications-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJT6N-0001Yb-SI; Fri, 10 Aug 2007 07:56:23 -0400
Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJT6M-0001YW-PP for notifications-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 07:56:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJT6M-0001YO-Fz for notifications@ietf.org; Fri, 10 Aug 2007 07:56:22 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJT6K-0003Pw-WD for notifications@ietf.org; Fri, 10 Aug 2007 07:56:22 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7ABu8pG007358; Fri, 10 Aug 2007 14:56:15 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 14:56:05 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 14:56:05 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Notifications] Reliability
Date: Fri, 10 Aug 2007 14:55:29 +0300
Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157E7A870@esebe199.NOE.Nokia.com>
In-Reply-To: <46BADC44.2060706@it.su.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Notifications] Reliability
Thread-Index: AcfaZm7TCt7JGqNSQKSmZBYWXiEa5AA3NSvw
References: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> <46BADC44.2060706@it.su.se>
From: Zoltan.Ordogh@nokia.com
To: leifj@it.su.se
X-OriginalArrivalTime: 10 Aug 2007 11:56:05.0124 (UTC) FILETIME=[6E306440:01C7DB45]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: notifications@ietf.org
X-BeenThere: notifications@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Message Notifications interest group discussion list <notifications.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/notifications>, <mailto:notifications-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/notifications>
List-Post: <mailto:notifications@ietf.org>
List-Help: <mailto:notifications-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/notifications>, <mailto:notifications-request@ietf.org?subject=subscribe>
Errors-To: notifications-bounces@ietf.org

>-----Original Message-----
>From: ext Leif Johansson [mailto:leifj@it.su.se] 
>Sent: 09 August, 2007 12:20
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
>Cc: notifications@ietf.org
>Subject: Re: [Notifications] Reliability
>
>Zoltan.Ordogh@nokia.com wrote:
>>
>> 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.
>>
>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.

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.


_______________________________________________
Notifications mailing list
Notifications@ietf.org
https://www1.ietf.org/mailman/listinfo/notifications

v2.23.0 | Report a Bug | By Email