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
- [Notifications] Reliability Zoltan.Ordogh
- Re: [Notifications] Reliability Leif Johansson
- RE: [Notifications] Reliability Zoltan.Ordogh
- Re: [Notifications] Reliability Lisa Dusseault
- Re: [Notifications] Reliability Leif Johansson
- Re: [Notifications] Reliability Henning Schulzrinne