From notifications-bounces@ietf.org Wed Aug 01 08:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDJH-00034c-1F; Wed, 01 Aug 2007 08:28:15 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IFRxR-0002l3-Dj for notifications-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 05:54:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFRxN-0002jp-Ox for notifications@ietf.org; Mon, 30 Jul 2007 05:54:29 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFRxN-0006ug-1p for notifications@ietf.org; Mon, 30 Jul 2007 05:54:29 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLZ00CFTKTOJG@szxga04-in.huawei.com> for notifications@ietf.org; Mon, 30 Jul 2007 17:53:48 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLZ0050NKTN9O@szxga04-in.huawei.com> for notifications@ietf.org; Mon, 30 Jul 2007 17:53:48 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLZ00DXCKTJZ8@szxml03-in.huawei.com> for notifications@ietf.org; Mon, 30 Jul 2007 17:53:47 +0800 (CST) Date: Mon, 30 Jul 2007 17:53:43 +0800 From: Qian Sun To: notifications@ietf.org Message-id: <022301c7d28f$840e3b70$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfSj4M847eZ3mzCQ+uxz3IHkw9JFg== X-Spam-Score: 2.9 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-Mailman-Approved-At: Wed, 01 Aug 2007 08:28:14 -0400 Subject: [Notifications] subscribe X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org subscribe _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 01 12:53:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHS4-0002bO-Jo; Wed, 01 Aug 2007 12:53:36 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IGHS3-0002b9-FE for notifications-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 12:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHRz-0002aw-Qx for notifications@ietf.org; Wed, 01 Aug 2007 12:53:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGHRy-0003f0-GY for notifications@ietf.org; Wed, 01 Aug 2007 12:53:31 -0400 Received: from [192.168.0.3] (adsl-68-122-42-242.dsl.pltn13.pacbell.net [68.122.42.242]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l71GrFkP024050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Aug 2007 09:53:16 -0700 Message-ID: <46B0BA23.8030000@dcrocker.net> Date: Wed, 01 Aug 2007 09:51:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: notifications@ietf.org Subject: Re: [Notifications] Use cases References: <46AF3932.5030505@att.com> In-Reply-To: <46AF3932.5030505@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Tony Hansen wrote: > As Randy reminded me at the meeting :-), after we get a bunch of > potential use cases, each of them needs to be passed through a filter of > "should this be better done by a good sieve implementation that includes > the notification extension". +1 > But brainstorm first and keep the ideas flowing, *before* running them > through the filter. +10 -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 07 08:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINq9-0003Hq-SN; Tue, 07 Aug 2007 08:07:09 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIN3D-0007i8-H1 for notifications-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 07:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIN38-0007di-Py for notifications@ietf.org; Tue, 07 Aug 2007 07:16:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIN37-0004Zh-Ad for notifications@ietf.org; Tue, 07 Aug 2007 07:16:30 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l77BGFpL002013 for ; Tue, 7 Aug 2007 04:16:16 -0700 Message-ID: <46B8544C.8090809@ninebynine.org> Date: Tue, 07 Aug 2007 12:15:24 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF-notifications X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 07 Aug 2007 08:07:08 -0400 Subject: [Notifications] Request for information: status of GENA? X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Is anyone on this list able to comment on the current state of GENA (http://en.wikipedia.org/wiki/GENA)? There was an Internet draft back in 1999, and work subsequently seemed to move to the uPnP forum (http://www.upnp.org/) with Microsoft taking a keen interest (http://support.microsoft.com/kb/323713). But the specification link on the MS web site (http://msdn2.microsoft.com/en-us/library/Aa505982.aspx) is broken. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 07 08:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINq9-0003Hv-Vi; Tue, 07 Aug 2007 08:07:09 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIN3G-0007qv-Lt for notifications-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 07:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIN38-0007dd-Pj for notifications@ietf.org; Tue, 07 Aug 2007 07:16:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIN37-0004Zi-Ab for notifications@ietf.org; Tue, 07 Aug 2007 07:16:30 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l77BGCS2002000 for ; Tue, 7 Aug 2007 04:16:13 -0700 Message-ID: <46B853C5.1040807@ninebynine.org> Date: Tue, 07 Aug 2007 12:13:09 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: notifications@ietf.org X-Enigmail-Version: 0.95.3 Content-Type: text/plFrom notifications-bounces@ietf.org Tue Aug 07 08:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINq9-0003Hq-SN; Tue, 07 Aug 2007 08:07:09 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIN3D-0007i8-H1 for notifications-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 07:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIN38-0007di-Py for notifications@ietf.org; Tue, 07 Aug 2007 07:16:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIN37-0004Zh-Ad for notifications@ietf.org; Tue, 07 Aug 2007 07:16:30 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l77BGFpL002013 for ; Tue, 7 Aug 2007 04:16:16 -0700 Message-ID: <46B8544C.8090809@ninebynine.org> Date: Tue, 07 Aug 2007 12:15:24 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF-notifications X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 07 Aug 2007 08:07:08 -0400 Subject: [Notifications] Request for information: status of GENA? X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Is anyone on this list able to comment on the current state of GENA (http://en.wikipedia.org/wiki/GENA)? There was an Internet draft back in 1999, and work subsequently seemed to move to the uPnP forum (http://www.upnp.org/) with Microsoft taking a keen interest (http://support.microsoft.com/kb/323713). But the specification link on the MS web site (http://msdn2.microsoft.com/en-us/library/Aa505982.aspx) is broken. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 07 08:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINq9-0003Hv-Vi; Tue, 07 Aug 2007 08:07:09 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIN3G-0007qv-Lt for notifications-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 07:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIN38-0007dd-Pj for notifications@ietf.org; Tue, 07 Aug 2007 07:16:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIN37-0004Zi-Ab for notifications@ietf.org; Tue, 07 Aug 2007 07:16:30 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l77BGCS2002000 for ; Tue, 7 Aug 2007 04:16:13 -0700 Message-ID: <46B853C5.1040807@ninebynine.org> Date: Tue, 07 Aug 2007 12:13:09 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: notifications@ietf.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Tue, 07 Aug 2007 08:07:08 -0400 Subject: [Notifications] Statement of interest, and comments on scope X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Hello all, Reviewing the BOF draft minutes (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html), I note that the scope of activity is up for debate. I've had a background interest in asynchronous event or notification delivery for some time. Along with others, I've noticed this seems to be a topic that keeps on popping up in different circumstances. My own current interest has nothing to do with email, and more to do with web-based devices (e.g. http://www.ietf.org/rfc/rfc2324.txt, or ). It is my perception that a simple, publish-subscribe message distribution framework would be useful for a large number of applications. I've been putting together a page of notes that, among other things, lists a number of these applications that I've come across over the past 2-3 years or so: http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/WebEventDelivery. And there are several protocol specifications and implementations that might (and probably will) be used - XMPP, SIP and other implementers of CPP come to mind. I'd like to see a really simple notification architecture that can be adapted to all of these areas. To be clear, I absolutely DO NOT think the proposed activity can actually tackle all of these. Rather, I'd like to see an underlying event distribution architecture stripped back to a minimum that can be adapted to suit all of these. In this context, email-related notifications provides an important use-case for driving requirements, but I'd personally like to see an underlying notification framework that is as independent of any specific application as reasonably achievable. In that spirit, I'd like to second this comment from the meeting: [[ Dave Crocker suggests that the notification service should be very lean with no understanding of what is being sent. ]] -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications ain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Tue, 07 Aug 2007 08:07:08 -0400 Subject: [Notifications] Statement of interest, and comments on scope X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Hello all, Reviewing the BOF draft minutes (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html), I note that the scope of activity is up for debate. I've had a background interest in asynchronous event or notification delivery for some time. Along with others, I've noticed this seems to be a topic that keeps on popping up in different circumstances. My own current interest has nothing to do with email, and more to do with web-based devices (e.g. http://www.ietf.org/rfc/rfc2324.txt, or ). It is my perception that a simple, publish-subscribe message distribution framework would be useful for a large number of applications. I've been putting together a page of notes that, among other things, lists a number of these applications that I've come across over the past 2-3 years or so: http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/WebEventDelivery. And there are several protocol specifications and implementations that might (and probably will) be used - XMPP, SIP and other implementers of CPP come to mind. I'd like to see a really simple notification architecture that can be adapted to all of these areas. To be clear, I absolutely DO NOT think the proposed activity can actually tackle all of these. Rather, I'd like to see an underlying event distribution architecture stripped back to a minimum that can be adapted to suit all of these. In this context, email-related notifications provides an important use-case for driving requirements, but I'd personally like to see an underlying notification framework that is as independent of any specific application as reasonably achievable. In that spirit, I'd like to second this comment from the meeting: [[ Dave Crocker suggests that the notification service should be very lean with no understanding of what is being sent. ]] -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 08 05:31:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIht9-0003L8-Cr; Wed, 08 Aug 2007 05:31:35 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIht8-0003L3-4t for notifications-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 05:31:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIht4-0003Kq-6G for notifications@ietf.org; Wed, 08 Aug 2007 05:31:30 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIht3-0001jc-1s for notifications@ietf.org; Wed, 08 Aug 2007 05:31:29 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 81C163BEDA; Wed, 8 Aug 2007 11:31:27 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10529-01-47; Wed, 8 Aug 2007 11:31:27 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id C54B03BE3A; Wed, 8 Aug 2007 11:31:24 +0200 (CEST) Message-ID: <46B98D7F.6090403@it.su.se> Date: Wed, 08 Aug 2007 11:31:43 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Graham Klyne Subject: Re: [Notifications] Statement of interest, and comments on scope References: <46B853C5.1040807@ninebynine.org> In-Reply-To: <46B853C5.1040807@ninebynine.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.284 tagged_above=-99 required=7 tests=[AWL=0.028, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Graham Klyne wrote: > Hello all, > > Reviewing the BOF draft minutes > (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html), I > note that the scope of activity is up for debate. > > I've had a background interest in asynchronous event or notification delivery > for some time. Along with others, I've noticed this seems to be a topic that > keeps on popping up in different circumstances. My own current interest has > nothing to do with email, and more to do with web-based devices (e.g. > http://www.ietf.org/rfc/rfc2324.txt, or ). > > It is my perception that a simple, publish-subscribe message distribution > framework would be useful for a large number of applications. I've been putting > together a page of notes that, among other things, lists a number of these > applications that I've come across over the past 2-3 years or so: > http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/WebEventDelivery. > Seems useful. > And there are several protocol specifications and implementations that might > (and probably will) be used - XMPP, SIP and other implementers of CPP come to > mind. I'd like to see a really simple notification architecture that can be > adapted to all of these areas. > > To be clear, I absolutely DO NOT think the proposed activity can actually tackle > all of these. Rather, I'd like to see an underlying event distribution > architecture stripped back to a minimum that can be adapted to suit all of > these. In this context, email-related notifications provides an important > use-case for driving requirements, but I'd personally like to see an underlying > notification framework that is as independent of any specific application as > reasonably achievable. > I think you are absolutely right that a general notifications- framework would be useful. The problem (purely non-technical) as I see it is that notifications or publish-subscribe is a concern which has been done so many times that it is inconceivable that a new IETF-stamped protocol has any chance of being adopted even by current IETF "products" (eg SIP) since they already have working solutions. On the other hand both Subscribe/Notifyand XEP-0060 would get the job done but both are somewhat burdened by relatively large application stacks. Put another way: is it realistic to require light-weight apps to grow a full SIP-stack to be able to receive notifications? Would it be ok even for todays email clients? Another historical parallel to draw is the IETF work on IM which happened when IM was already a fact of life, the IETF having lived in a fog of indecision based on the nature of "instant" for too long. When we finally got around to IM the work was limited to figuring out commonality (RFC3860). It would (imho) be a waste of time to do something similar for notifications. Here is an illustrative story of these problems. At Chicago I talked to a guy who works for the .se registry and needs a way for a dnssec toolchain (think of it as a black box for signing zones) to notify the dns masters that a new set of zones exists. His natural instinct is to extend the existing DNS notify mechanism (which can be viewed as a single-purpose publish-subscribe for information about zones). Here is the problem: how do you sell that guy on the idea that its better to build on SIP, XMPP (or something else) ? Having said all of that I still think it is good to follow Dave's suggestion about generality but we need to have realistic expectations. > In that spirit, I'd like to second this comment from the meeting: > [[ > Dave Crocker suggests that the notification service should be very lean with no > understanding of what is being sent. > ]] > -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html > > #g > Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 08 14:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIpzG-0005hY-4c; Wed, 08 Aug 2007 14:10:26 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIpzF-0005hT-FA for notifications-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 14:10:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIpzF-0005hL-3T for notifications@ietf.org; Wed, 08 Aug 2007 14:10:25 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIpzE-0006yS-Bq for notifications@ietf.org; Wed, 08 Aug 2007 14:10:25 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l78IAM6q025937 for ; Wed, 8 Aug 2007 11:10:22 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l78I9dd5025729 for ; Wed, 8 Aug 2007 11:09:41 -0700 Received: from 172.24.29.206 ([172.24.29.206]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Aug 2007 18:10:19 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 09 Aug 2007 03:10:16 +0900 Subject: Re: [Notifications] Statement of interest, and comments on scope From: Eric Burger To: Message-ID: Thread-Topic: [Notifications] Statement of interest, and comments on scope Thread-Index: AcfZ518gne/hMEXaEdyMOgAWy4mm/w== In-Reply-To: <46B98D7F.6090403@it.su.se> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Let us call it what it is: I think we are well on the path to creating another BEEP. Great in theory. Great to have one thing use it. Too bad never really got used. How much effort do we want to put into this? Remember, the SHORTEST cycle in the IETF is 3 years. Will this task be more or less relevant in that time frame? On 8/8/07 6:31 PM, "Leif Johansson" wrote: > Graham Klyne wrote: >> Hello all, >> >> Reviewing the BOF draft minutes >> (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html), >> I >> note that the scope of activity is up for debate. >> >> I've had a background interest in asynchronous event or notification delivery >> for some time. Along with others, I've noticed this seems to be a topic that >> keeps on popping up in different circumstances. My own current interest has >> nothing to do with email, and more to do with web-based devices (e.g. >> http://www.ietf.org/rfc/rfc2324.txt, or ). >> >> It is my perception that a simple, publish-subscribe message distribution >> framework would be useful for a large number of applications. I've been >> putting >> together a page of notes that, among other things, lists a number of these >> applications that I've come across over the past 2-3 years or so: >> http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/WebE >> ventDelivery. >> > Seems useful. >> And there are several protocol specifications and implementations that might >> (and probably will) be used - XMPP, SIP and other implementers of CPP come to >> mind. I'd like to see a really simple notification architecture that can be >> adapted to all of these areas. >> >> To be clear, I absolutely DO NOT think the proposed activity can actually >> tackle >> all of these. Rather, I'd like to see an underlying event distribution >> architecture stripped back to a minimum that can be adapted to suit all of >> these. In this context, email-related notifications provides an important >> use-case for driving requirements, but I'd personally like to see an >> underlying >> notification framework that is as independent of any specific application as >> reasonably achievable. >> > I think you are absolutely right that a general notifications- > framework would be useful. The problem (purely non-technical) > as I see it is that notifications or publish-subscribe is a concern > which has been done so many times that it is inconceivable > that a new IETF-stamped protocol has any chance of being > adopted even by current IETF "products" (eg SIP) since they > already have working solutions. > > On the other hand both Subscribe/Notifyand XEP-0060 would > get the job done but both are somewhat burdened by relatively > large application stacks. Put another way: is it realistic to require > light-weight apps to grow a full SIP-stack to be able to receive > notifications? Would it be ok even for todays email clients? > > Another historical parallel to draw is the IETF work on IM > which happened when IM was already a fact of life, the IETF > having lived in a fog of indecision based on the nature of > "instant" for too long. When we finally got around to IM the > work was limited to figuring out commonality (RFC3860). > > It would (imho) be a waste of time to do something similar for > notifications. > > Here is an illustrative story of these problems. > > At Chicago I talked to a guy who works for the .se registry and > needs a way for a dnssec toolchain (think of it as a black box > for signing zones) to notify the dns masters that a new set of > zones exists. His natural instinct is to extend the existing DNS > notify mechanism (which can be viewed as a single-purpose > publish-subscribe for information about zones). > > Here is the problem: how do you sell that guy on the idea that > its better to build on SIP, XMPP (or something else) ? > > Having said all of that I still think it is good to follow Dave's > suggestion about generality but we need to have realistic > expectations. >> In that spirit, I'd like to second this comment from the meeting: >> [[ >> Dave Crocker suggests that the notification service should be very lean with >> no >> understanding of what is being sent. >> ]] >> -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html >> >> #g >> > Cheers Leif > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications 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. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 08 16:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIrva-0007tA-2m; Wed, 08 Aug 2007 16:14:46 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIrvZ-0007qN-5J for notifications-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 16:14:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIrvY-0007oZ-Pl for notifications@ietf.org; Wed, 08 Aug 2007 16:14:44 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIrvW-0001eG-Rc for notifications@ietf.org; Wed, 08 Aug 2007 16:14:44 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l78KEggI021776 for ; Wed, 8 Aug 2007 20:14:42 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMH00H011GFXP00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for notifications@ietf.org; Wed, 08 Aug 2007 14:14:42 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMH00K6P1KEZH10@mail-amer.sun.com>; Wed, 08 Aug 2007 14:14:41 -0600 (MDT) Date: Wed, 08 Aug 2007 13:14:48 -0700 From: Chris Newman Subject: Re: [Notifications] Statement of interest, and comments on scope In-reply-to: <46B98D7F.6090403@it.su.se> To: Leif Johansson , Graham Klyne Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Speaking as sponsoring area director, I would not support a proposed charter that included work on functionality already present in SIP and/or XMPP. I suspect other area directors would also have problems with such a charter. - Chris Newman Leif Johansson wrote on 8/8/07 11:31 +0200: > Graham Klyne wrote: >> Hello all, >> >> Reviewing the BOF draft minutes >> (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html), >> I note that the scope of activity is up for debate. >> >> I've had a background interest in asynchronous event or notification delivery >> for some time. Along with others, I've noticed this seems to be a topic that >> keeps on popping up in different circumstances. My own current interest has >> nothing to do with email, and more to do with web-based devices (e.g. >> http://www.ietf.org/rfc/rfc2324.txt, or ). >> >> It is my perception that a simple, publish-subscribe message distribution >> framework would be useful for a large number of applications. I've been >> putting together a page of notes that, among other things, lists a number of >> these applications that I've come across over the past 2-3 years or so: >> http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/Web >> EventDelivery. >> > Seems useful. >> And there are several protocol specifications and implementations that might >> (and probably will) be used - XMPP, SIP and other implementers of CPP come to >> mind. I'd like to see a really simple notification architecture that can be >> adapted to all of these areas. >> >> To be clear, I absolutely DO NOT think the proposed activity can actually >> tackle all of these. Rather, I'd like to see an underlying event >> distribution architecture stripped back to a minimum that can be adapted to >> suit all of these. In this context, email-related notifications provides an >> important use-case for driving requirements, but I'd personally like to see >> an underlying notification framework that is as independent of any specific >> application as reasonably achievable. >> > I think you are absolutely right that a general notifications- > framework would be useful. The problem (purely non-technical) > as I see it is that notifications or publish-subscribe is a concern > which has been done so many times that it is inconceivable > that a new IETF-stamped protocol has any chance of being > adopted even by current IETF "products" (eg SIP) since they > already have working solutions. > > On the other hand both Subscribe/Notifyand XEP-0060 would > get the job done but both are somewhat burdened by relatively > large application stacks. Put another way: is it realistic to require > light-weight apps to grow a full SIP-stack to be able to receive > notifications? Would it be ok even for todays email clients? > > Another historical parallel to draw is the IETF work on IM > which happened when IM was already a fact of life, the IETF > having lived in a fog of indecision based on the nature of > "instant" for too long. When we finally got around to IM the > work was limited to figuring out commonality (RFC3860). > > It would (imho) be a waste of time to do something similar for > notifications. > > Here is an illustrative story of these problems. > > At Chicago I talked to a guy who works for the .se registry and > needs a way for a dnssec toolchain (think of it as a black box > for signing zones) to notify the dns masters that a new set of > zones exists. His natural instinct is to extend the existing DNS > notify mechanism (which can be viewed as a single-purpose > publish-subscribe for information about zones). > > Here is the problem: how do you sell that guy on the idea that > its better to build on SIP, XMPP (or something else) ? > > Having said all of that I still think it is good to follow Dave's > suggestion about generality but we need to have realistic > expectations. >> In that spirit, I'd like to second this comment from the meeting: >> [[ >> Dave Crocker suggests that the notification service should be very lean with >> no understanding of what is being sent. >> ]] >> -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html >> >> #g >> > Cheers Leif > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications > _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 08 16:39:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIsJf-0002UV-Px; Wed, 08 Aug 2007 16:39:39 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIsJe-0002U5-3S for notifications-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 16:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIsJc-0002Tq-Nn for notifications@ietf.org; Wed, 08 Aug 2007 16:39:37 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIsJb-000247-9p for notifications@ietf.org; Wed, 08 Aug 2007 16:39:36 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 5A58C3BF51; Wed, 8 Aug 2007 22:39:34 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18430-01-59; Wed, 8 Aug 2007 22:39:34 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id ED7123BE22; Wed, 8 Aug 2007 22:39:33 +0200 (CEST) Message-ID: <46BA2A19.5090606@it.su.se> Date: Wed, 08 Aug 2007 22:39:53 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Chris Newman Subject: Re: [Notifications] Statement of interest, and comments on scope References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.286 tagged_above=-99 required=7 tests=[AWL=0.026, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Graham Klyne , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Chris Newman wrote: > Speaking as sponsoring area director, I would not support a proposed > charter that included work on functionality already present in SIP > and/or XMPP. I suspect other area directors would also have problems > with such a charter. > > - Chris Newman > > I'm not surprised nor do I disagree. Would you support a charter which explicitly specifies profiling existing implementation(s) of (say) a publish subscribe metaphor? If so you'd have to address the issue of the email client growing a sip stack (or an xmpp stack). Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 08 17:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIspH-00067P-Sr; Wed, 08 Aug 2007 17:12:19 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IIspG-00067K-8O for notifications-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 17:12:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIspF-00067C-Ti for notifications@ietf.org; Wed, 08 Aug 2007 17:12:17 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIspF-0002cH-IQ for notifications@ietf.org; Wed, 08 Aug 2007 17:12:17 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C75CC1421FD; Wed, 8 Aug 2007 14:12:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-uMdwL5c4+O; Wed, 8 Aug 2007 14:12:12 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1764F142201; Wed, 8 Aug 2007 14:12:10 -0700 (PDT) In-Reply-To: <46BA2A19.5090606@it.su.se> References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> <46BA2A19.5090606@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3126C5F0-2CF3-4913-AFC2-D99E687210C3@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Notifications] Statement of interest, and comments on scope Date: Wed, 8 Aug 2007 14:12:09 -0700 To: Leif Johansson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Graham Klyne , Chris Newman , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Aug 8, 2007, at 1:39 PM, Leif Johansson wrote: > Chris Newman wrote: >> Speaking as sponsoring area director, I would not support a proposed >> charter that included work on functionality already present in SIP >> and/or XMPP. I suspect other area directors would also have problems >> with such a charter. >> >> - Chris Newman >> >> > I'm not surprised nor do I disagree. Would you support a charter > which explicitly specifies profiling existing implementation(s) of > (say) a publish subscribe metaphor? > > If so you'd have to address the issue of the email client growing > a sip stack (or an xmpp stack). Not necessarily. Email clients that already support IMAP can use IMAP IDLE; this might not be so useful for existing rich email clients but instead for POP clients, HTTP clients or helper applications. Of course if the event subscription features are useful enough even an IMAP client with access to IDLE might use SIP or XMPP. Some email clients already have such stacks, possibly proprietary approximations or access to a related application with such a stack -- my email client can tell me when somebody I'm emailing, who is also in my buddy list, happens to be online, provided iChat is running. Lisa _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Thu Aug 09 03:10:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2AZ-0008Fx-RQ; Thu, 09 Aug 2007 03:10:55 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ2AY-0008Fl-MP for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 03:10:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2AU-0008Ac-5y for notifications@ietf.org; Thu, 09 Aug 2007 03:10:50 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ2AT-0003Xa-Kq for notifications@ietf.org; Thu, 09 Aug 2007 03:10:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l797AN9U006803; Thu, 9 Aug 2007 10:10:42 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 10:10:38 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 10:10:38 +0300 Received: from [172.21.41.122] (esdhcp041122.research.nokia.com [172.21.41.122]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l797AY0b013243; Thu, 9 Aug 2007 10:10:35 +0300 Message-ID: <46BABDEA.7030602@nokia.com> Date: Thu, 09 Aug 2007 10:10:34 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Leif Johansson Subject: Re: [Notifications] Statement of interest, and comments on scope References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> <46BA2A19.5090606@it.su.se> In-Reply-To: <46BA2A19.5090606@it.su.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2007 07:10:38.0475 (UTC) FILETIME=[637F65B0:01C7DA54] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Graham Klyne , Chris Newman , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org ext Leif Johansson wrote: > If so you'd have to address the issue of the email client growing > a sip stack (or an xmpp stack). This goes a bit beyond what standards actually can address, but I think it the field there are frameworks that basically provide these protocols as a system service that other applications can use. As an example, the Symbian SIP stack allows any applications to register themselves for certain types of SIP communications, and the freedesktop.org's telepathy framework [1] allows for something similar via DBUS, an IPC bus. Plus there are many, many open source implementations of SIP and XMPP, which means no need to implement from scratch (which would be the only available approach to a brand new protocol). So I don't think the IETF would need to address this issue a whole lot more than, say, the issue of an email client having to grow a TLS stack. Cheers, Aki [1] http://telepathy.freedesktop.org/wiki/ _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Thu Aug 09 03:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2Mr-0001D0-Ud; Thu, 09 Aug 2007 03:23:37 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ2Mq-0001Cr-M9 for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 03:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2Mq-0001Ci-BE for notifications@ietf.org; Thu, 09 Aug 2007 03:23:36 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ2Mq-000375-0s for notifications@ietf.org; Thu, 09 Aug 2007 03:23:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 09 Aug 2007 03:23:35 -0400 X-IronPort-AV: i="4.19,239,1183348800"; d="scan'208"; a="51630389:sNHT8022426" 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] Statement of interest, and comments on scope Date: Thu, 9 Aug 2007 09:22:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Statement of interest, and comments on scope Thread-Index: AcfZ+Nm4ty6IrxpYRNe5JnWqrkmEfgAXGz8A References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> From: "Romascanu, Dan (Dan)" To: "Chris Newman" , "Leif Johansson" , "Graham Klyne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Yes.=20 We have been paying marginal attention from the perspective of the OPS area, as long as the scope of the work that is discussed stays within the realm of mail, as defined in the BOF scope. If we want to discuss about a more general applicability that is covering real-time applications and has operational implications beyond mail services, the discussions need to happen in a different context and involve a broader community.=20 And yes, duplication of functionality already present in other areas is a concern.=20 Dan =20 =20 > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM]=20 > Sent: Wednesday, August 08, 2007 11:15 PM > To: Leif Johansson; Graham Klyne > Cc: notifications@ietf.org > Subject: Re: [Notifications] Statement of interest, and=20 > comments on scope >=20 > Speaking as sponsoring area director, I would not support a=20 > proposed charter that included work on functionality already=20 > present in SIP and/or XMPP. I suspect other area directors=20 > would also have problems with such a charter. >=20 > - Chris Newman >=20 _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Thu Aug 09 03:39:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2cF-0005AV-8W; Thu, 09 Aug 2007 03:39:31 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ2cD-0005A2-77 for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 03:39:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2cC-00059t-Mu for notifications@ietf.org; Thu, 09 Aug 2007 03:39:28 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ2cB-0003Q7-4Q for notifications@ietf.org; Thu, 09 Aug 2007 03:39:28 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id D03E03BF16; Thu, 9 Aug 2007 09:39:23 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15582-01-84; Thu, 9 Aug 2007 09:39:23 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 1042B3BF02; Thu, 9 Aug 2007 09:39:23 +0200 (CEST) Message-ID: <46BAC4BE.4060806@it.su.se> Date: Thu, 09 Aug 2007 09:39:42 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Notifications] Statement of interest, and comments on scope References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> <46BA2A19.5090606@it.su.se> <46BABDEA.7030602@nokia.com> In-Reply-To: <46BABDEA.7030602@nokia.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.286 tagged_above=-99 required=7 tests=[AWL=0.026, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Graham Klyne , Chris Newman , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Aki Niemi wrote: > ext Leif Johansson wrote: > >> If so you'd have to address the issue of the email client growing >> a sip stack (or an xmpp stack). >> > > This goes a bit beyond what standards actually can address, but I think > it the field there are frameworks that basically provide these protocols > as a system service that other applications can use. As an example, the > Symbian SIP stack allows any applications to register themselves for > certain types of SIP communications, and the freedesktop.org's telepathy > framework [1] allows for something similar via DBUS, an IPC bus. > > Plus there are many, many open source implementations of SIP and XMPP, > which means no need to implement from scratch (which would be the only > available approach to a brand new protocol). > > So I don't think the IETF would need to address this issue a whole lot > more than, say, the issue of an email client having to grow a TLS stack. > > Cheers, > Aki > > [1] http://telepathy.freedesktop.org/wiki/ > Actually both you and Lisa addressed the issue when you said the IETF wouldn't have to :-) You both make the point that desktop OSen tend to be structured differently today using lots of infrastructure. Thats a perfectly reasonable response to my question: its not a problem since there are very few truly stand-alone applications anymore. Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Thu Aug 09 04:57:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3pd-0008HC-19; Thu, 09 Aug 2007 04:57:25 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ3pb-0008Gx-Pg for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 04:57:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3pb-0008Gp-A6 for notifications@ietf.org; Thu, 09 Aug 2007 04:57:23 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ3pa-0005xB-Fi for notifications@ietf.org; Thu, 09 Aug 2007 04:57:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l798vCOT005941 for ; Thu, 9 Aug 2007 11:57:20 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 11:57:15 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 11:57:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Notifications] Reliability Date: Thu, 9 Aug 2007 11:56:44 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Reliability Thread-Index: AcfaYzXihpsbDxx4RmeflLMsErg8ig== From: To: X-OriginalArrivalTime: 09 Aug 2007 08:57:15.0903 (UTC) FILETIME=[48A970F0:01C7DA63] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0051658512==" Errors-To: notifications-bounces@ietf.org This is a multi-part message in MIME format. --===============0051658512== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DA63.48472912" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA63.48472912 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 ------_=_NextPart_001_01C7DA63.48472912 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Notifications] Reliability

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=E1n = =D6rd=F6gh
E-mail: zoltan = dot ordogh at nokia dot com
Phone: = +358 50 386 = 0566


------_=_NextPart_001_01C7DA63.48472912-- --===============0051658512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications --===============0051658512==-- From notifications-bounces@ietf.org Thu Aug 09 04:58:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3qF-0001hl-CQ; Thu, 09 Aug 2007 04:58:03 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ3qD-0001hg-DA for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 04:58:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ3qD-0001hY-1h for notifications@ietf.org; Thu, 09 Aug 2007 04:58:01 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ3qC-0005xt-7S for notifications@ietf.org; Thu, 09 Aug 2007 04:58:00 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l798vbk4026763; Thu, 9 Aug 2007 01:57:47 -0700 Message-ID: <46BAD5F7.8040501@ninebynine.org> Date: Thu, 09 Aug 2007 09:53:11 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Leif Johansson Subject: Re: [Notifications] Statement of interest, and comments on scope References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> In-Reply-To: <46B98D7F.6090403@it.su.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Leif, (as I write, I've also seen comments from Chris and Lisa...) I agree with almost all you say here. I'm definitely not suggesting there should be work on a new universal protocol. I half agree with what you say about CPIM/CPP - I was involved in some of that work, and I feel the result inevitably contained some awkward compromises. All of which begs the question, what would I like to see, if not a new protocol? I think some move toward convergence on a minimal model that can form the basis of common APIs so that application code and underlying pub-sub protocol frameworks can be switched about. This in turn begs a question of whether this is appropriate work for the IETF to consider, since it's not strictly about on-the-wire interoperability. I don't know the answer, but I don't see any other body that stands much chance of having any useful impact in this area. So what does my request amount to in practical terms? Given that the proto-WG is aiming to produce specifications for email event notifications that can work with existing notification protocols, I'd like to see that teased apart into two layers: (a) an abstract notification model, presumably based on pub-sub, that can be layered over existing (and new) protocols and is not of itself specific to email (even though it does not take account of wider requirements), and (b) an email-specific part that addresses how email notifications can be conveyed by such a framework. Apart from some head scratching about where to draw the line, and some additional documentation effort, I don't think this represents a big leap over what's already on the table, and it could at least represent a step towards some kind of convergent approach to notifications, even if it doesn't solve all problems, because the notification model part may present a "higher point of departure" for non-email applications to build upon. (Aside: even without consideration of other applications, I think this approach could produce a cleaner overall solution by driving some consideration of what really needs to be incorporated in the underlying notification mechanism and what can be built upon it.) I hope this helps to clarify my position. #g -- Leif Johansson wrote: > Graham Klyne wrote: >> Hello all, >> >> Reviewing the BOF draft minutes >> (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html), I >> note that the scope of activity is up for debate. >> >> I've had a background interest in asynchronous event or notification delivery >> for some time. Along with others, I've noticed this seems to be a topic that >> keeps on popping up in different circumstances. My own current interest has >> nothing to do with email, and more to do with web-based devices (e.g. >> http://www.ietf.org/rfc/rfc2324.txt, or ). >> >> It is my perception that a simple, publish-subscribe message distribution >> framework would be useful for a large number of applications. I've been putting >> together a page of notes that, among other things, lists a number of these >> applications that I've come across over the past 2-3 years or so: >> http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/WebEventDelivery. >> > Seems useful. >> And there are several protocol specifications and implementations that might >> (and probably will) be used - XMPP, SIP and other implementers of CPP come to >> mind. I'd like to see a really simple notification architecture that can be >> adapted to all of these areas. >> >> To be clear, I absolutely DO NOT think the proposed activity can actually tackle >> all of these. Rather, I'd like to see an underlying event distribution >> architecture stripped back to a minimum that can be adapted to suit all of >> these. In this context, email-related notifications provides an important >> use-case for driving requirements, but I'd personally like to see an underlying >> notification framework that is as independent of any specific application as >> reasonably achievable. >> > I think you are absolutely right that a general notifications- > framework would be useful. The problem (purely non-technical) > as I see it is that notifications or publish-subscribe is a concern > which has been done so many times that it is inconceivable > that a new IETF-stamped protocol has any chance of being > adopted even by current IETF "products" (eg SIP) since they > already have working solutions. > > On the other hand both Subscribe/Notifyand XEP-0060 would > get the job done but both are somewhat burdened by relatively > large application stacks. Put another way: is it realistic to require > light-weight apps to grow a full SIP-stack to be able to receive > notifications? Would it be ok even for todays email clients? > > Another historical parallel to draw is the IETF work on IM > which happened when IM was already a fact of life, the IETF > having lived in a fog of indecision based on the nature of > "instant" for too long. When we finally got around to IM the > work was limited to figuring out commonality (RFC3860). > > It would (imho) be a waste of time to do something similar for > notifications. > > Here is an illustrative story of these problems. > > At Chicago I talked to a guy who works for the .se registry and > needs a way for a dnssec toolchain (think of it as a black box > for signing zones) to notify the dns masters that a new set of > zones exists. His natural instinct is to extend the existing DNS > notify mechanism (which can be viewed as a single-purpose > publish-subscribe for information about zones). > > Here is the problem: how do you sell that guy on the idea that > its better to build on SIP, XMPP (or something else) ? > > Having said all of that I still think it is good to follow Dave's > suggestion about generality but we need to have realistic > expectations. >> In that spirit, I'd like to second this comment from the meeting: >> [[ >> Dave Crocker suggests that the notification service should be very lean with no >> understanding of what is being sent. >> ]] >> -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html >> >> #g >> > Cheers Leif > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications > -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Thu Aug 09 05:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4BJ-000216-DL; Thu, 09 Aug 2007 05:19:49 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ4BI-000210-C8 for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 05:19:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4BH-00020s-Bi for notifications@ietf.org; Thu, 09 Aug 2007 05:19:47 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ4BH-0006OI-1R for notifications@ietf.org; Thu, 09 Aug 2007 05:19:47 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id B64AE3BF3B; Thu, 9 Aug 2007 11:19:45 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22438-01-90; Thu, 9 Aug 2007 11:19:45 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 5495D3BEDA; Thu, 9 Aug 2007 11:19:45 +0200 (CEST) Message-ID: <46BADC44.2060706@it.su.se> Date: Thu, 09 Aug 2007 11:20:04 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Zoltan.Ordogh@nokia.com Subject: Re: [Notifications] Reliability References: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.279 tagged_above=-99 required=7 tests=[AWL=0.033, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org 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. Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Thu Aug 09 10:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8sc-0008H6-12; Thu, 09 Aug 2007 10:20:50 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJ8sa-0008H0-RV for notifications-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 10:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8sa-0008Gs-HU for notifications@ietf.org; Thu, 09 Aug 2007 10:20:48 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ8sY-0002rU-U2 for notifications@ietf.org; Thu, 09 Aug 2007 10:20:48 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id C7C683BF12; Thu, 9 Aug 2007 16:20:43 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14702-01-21; Thu, 9 Aug 2007 16:20:43 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 664663BEA8; Thu, 9 Aug 2007 16:20:43 +0200 (CEST) Message-ID: <46BB22CE.5090007@it.su.se> Date: Thu, 09 Aug 2007 16:21:02 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Graham Klyne Subject: Re: [Notifications] Statement of interest, and comments on scope References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> <46BAD5F7.8040501@ninebynine.org> In-Reply-To: <46BAD5F7.8040501@ninebynine.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.28 tagged_above=-99 required=7 tests=[AWL=0.032, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org > > So what does my request amount to in practical terms? Given that the proto-WG > is aiming to produce specifications for email event notifications that can work > with existing notification protocols, I'd like to see that teased apart into two > layers: > (a) an abstract notification model, presumably based on pub-sub, that can be > layered over existing (and new) protocols and is not of itself specific to email > (even though it does not take account of wider requirements), and > (b) an email-specific part that addresses how email notifications can be > conveyed by such a framework. > > +1 - it seems realistic although it is important that the wg is able to put some meat on (a) so that it has implications for interoperability. > I hope this helps to clarify my position. > > At least for me it does. Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Aug 10 07:56:24 2007 Return-path: 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: To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org >-----Original Message----- >From: ext Leif Johansson [mailto:leifj@it.su.se]=20 >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=20 >> did not actually go trhough with it. >> If this notification is not going to be reliable, what's the use for=20 >> it? I mean: >> You have a new mail, but You don't get a notification - what the use=20 >> of the whole framework then? >> Any thoughts on this? >> Thank You. >> >Well if you typically get email regularly and the purpose of=20 >the notification mechanism is to notify you that you _may_=20 >have new mail then it won't matter much (imho) if you loose a=20 >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 From notifications-bounces@ietf.org Fri Aug 10 11:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWoY-0006h0-7E; Fri, 10 Aug 2007 11:54:14 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJWoX-0006el-9R for notifications-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 11:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJWoW-0006cC-U7 for notifications@ietf.org; Fri, 10 Aug 2007 11:54:12 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJWoU-0000Sk-QH for notifications@ietf.org; Fri, 10 Aug 2007 11:54:12 -0400 Received: from [10.241.249.1] (nr1-66-42-173-121.fuse.net [66.42.173.121]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l7AFs44V009545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Aug 2007 11:54:06 -0400 (EDT) In-Reply-To: <46BAD5F7.8040501@ninebynine.org> References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> <46BAD5F7.8040501@ninebynine.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Notifications] Statement of interest, and comments on scope Date: Fri, 10 Aug 2007 11:54:06 -0400 To: Graham Klyne X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org I think we need to answer two questions: (1) Should we recommend that new event notification problems that arise use one of the existing protocols (or possibly allow several), such as SIP and XMPP? Currently, there is some concern about applicability, which may lead to inadvertent efforts to duplicate work. If we agree on this general notion, then new events only need to specify an (XML) event format and possibly a set of rules similar to the event package descriptions in SIP, not a wire protocol. Converting existing applications to use these pub/sub mechanisms is likely to be harder and, in my opinion, lower priority. I'd be happy if we stopped re-inventing event notification for each new application protocol. (2) Are there additional generic tools needed for pub/sub systems? For example, the SIMPLE infrastructure consists of privacy rules, filtering rules, subscriber management ("watcher"), configuration updates (XCAP) and we had discussed composition rules. Many of these components are probably useful beyond presence and beyond SIP, but we haven't really had this discussion. Henning On Aug 9, 2007, at 4:53 AM, Graham Klyne wrote: > Leif, > > (as I write, I've also seen comments from Chris and Lisa...) > > I agree with almost all you say here. I'm definitely not > suggesting there > should be work on a new universal protocol. > > I half agree with what you say about CPIM/CPP - I was involved in > some of that > work, and I feel the result inevitably contained some awkward > compromises. > > All of which begs the question, what would I like to see, if not a > new protocol? > > I think some move toward convergence on a minimal model that can > form the basis > of common APIs so that application code and underlying pub-sub > protocol > frameworks can be switched about. This in turn begs a question of > whether this > is appropriate work for the IETF to consider, since it's not > strictly about > on-the-wire interoperability. I don't know the answer, but I don't > see any > other body that stands much chance of having any useful impact in > this area. > > So what does my request amount to in practical terms? Given that > the proto-WG > is aiming to produce specifications for email event notifications > that can work > with existing notification protocols, I'd like to see that teased > apart into two > layers: > (a) an abstract notification model, presumably based on pub-sub, > that can be > layered over existing (and new) protocols and is not of itself > specific to email > (even though it does not take account of wider requirements), and > (b) an email-specific part that addresses how email notifications > can be > conveyed by such a framework. > > Apart from some head scratching about where to draw the line, and some > additional documentation effort, I don't think this represents a > big leap over > what's already on the table, and it could at least represent a step > towards some > kind of convergent approach to notifications, even if it doesn't > solve all > problems, because the notification model part may present a "higher > point of > departure" for non-email applications to build upon. > > (Aside: even without consideration of other applications, I think > this approach > could produce a cleaner overall solution by driving some > consideration of what > really needs to be incorporated in the underlying notification > mechanism and > what can be built upon it.) > > I hope this helps to clarify my position. > > #g > -- > > Leif Johansson wrote: >> Graham Klyne wrote: >>> Hello all, >>> >>> Reviewing the BOF draft minutes >>> (http://www1.ietf.org/mail-archive/web/notifications/current/ >>> msg00051.html), I >>> note that the scope of activity is up for debate. >>> >>> I've had a background interest in asynchronous event or >>> notification delivery >>> for some time. Along with others, I've noticed this seems to be >>> a topic that >>> keeps on popping up in different circumstances. My own current >>> interest has >>> nothing to do with email, and more to do with web-based devices >>> (e.g. >>> http://www.ietf.org/rfc/rfc2324.txt, or ). >>> >>> It is my perception that a simple, publish-subscribe message >>> distribution >>> framework would be useful for a large number of applications. >>> I've been putting >>> together a page of notes that, among other things, lists a number >>> of these >>> applications that I've come across over the past 2-3 years or so: >>> http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/ >>> Standard/WebEventDelivery. >>> >> Seems useful. >>> And there are several protocol specifications and >>> implementations that might >>> (and probably will) be used - XMPP, SIP and other implementers of >>> CPP come to >>> mind. I'd like to see a really simple notification architecture >>> that can be >>> adapted to all of these areas. >>> >>> To be clear, I absolutely DO NOT think the proposed activity can >>> actually tackle >>> all of these. Rather, I'd like to see an underlying event >>> distribution >>> architecture stripped back to a minimum that can be adapted to >>> suit all of >>> these. In this context, email-related notifications provides an >>> important >>> use-case for driving requirements, but I'd personally like to see >>> an underlying >>> notification framework that is as independent of any specific >>> application as >>> reasonably achievable. >>> >> I think you are absolutely right that a general notifications- >> framework would be useful. The problem (purely non-technical) >> as I see it is that notifications or publish-subscribe is a concern >> which has been done so many times that it is inconceivable >> that a new IETF-stamped protocol has any chance of being >> adopted even by current IETF "products" (eg SIP) since they >> already have working solutions. >> >> On the other hand both Subscribe/Notifyand XEP-0060 would >> get the job done but both are somewhat burdened by relatively >> large application stacks. Put another way: is it realistic to require >> light-weight apps to grow a full SIP-stack to be able to receive >> notifications? Would it be ok even for todays email clients? >> >> Another historical parallel to draw is the IETF work on IM >> which happened when IM was already a fact of life, the IETF >> having lived in a fog of indecision based on the nature of >> "instant" for too long. When we finally got around to IM the >> work was limited to figuring out commonality (RFC3860). >> >> It would (imho) be a waste of time to do something similar for >> notifications. >> >> Here is an illustrative story of these problems. >> >> At Chicago I talked to a guy who works for the .se registry and >> needs a way for a dnssec toolchain (think of it as a black box >> for signing zones) to notify the dns masters that a new set of >> zones exists. His natural instinct is to extend the existing DNS >> notify mechanism (which can be viewed as a single-purpose >> publish-subscribe for information about zones). >> >> Here is the problem: how do you sell that guy on the idea that >> its better to build on SIP, XMPP (or something else) ? >> >> Having said all of that I still think it is good to follow Dave's >> suggestion about generality but we need to have realistic >> expectations. >>> In that spirit, I'd like to second this comment from the meeting: >>> [[ >>> Dave Crocker suggests that the notification service should be >>> very lean with no >>> understanding of what is being sent. >>> ]] >>> -- http://www1.ietf.org/mail-archive/web/notifications/current/ >>> msg00051.html >>> >>> #g >>> >> Cheers Leif >> >> >> >> _______________________________________________ >> Notifications mailing list >> Notifications@ietf.org >> https://www1.ietf.org/mailman/listinfo/notifications >> > > -- > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Aug 10 15:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJa2U-000831-QT; Fri, 10 Aug 2007 15:20:50 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJa2U-00082s-5P for notifications-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 15:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJa2T-00082k-SD for notifications@ietf.org; Fri, 10 Aug 2007 15:20:49 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJa2S-0005JY-ET for notifications@ietf.org; Fri, 10 Aug 2007 15:20:49 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C1582142203; Fri, 10 Aug 2007 12:20:47 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCELSaPte6rz; Fri, 10 Aug 2007 12:20:45 -0700 (PDT) Received: from [192.168.1.101] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 43811142201; Fri, 10 Aug 2007 12:20:45 -0700 (PDT) In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157E7A870@esebe199.NOE.Nokia.com> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> <46BADC44.2060706@it.su.se> <4C38DC11F6B4FF4FAEA73E30DB5AA157E7A870@esebe199.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <504BEDBB-5B4F-461F-ABE1-990B452B912A@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Notifications] Reliability Date: Fri, 10 Aug 2007 12:20:43 -0700 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Aug 10, 2007, at 4:55 AM, wrote: > > 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)... > > ... > 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. > 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 _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Aug 10 15:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaEU-0004pv-43; Fri, 10 Aug 2007 15:33:14 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJaET-0004l5-FR for notifications-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 15:33:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaET-0004id-49 for notifications@ietf.org; Fri, 10 Aug 2007 15:33:13 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJaES-0003z3-P5 for notifications@ietf.org; Fri, 10 Aug 2007 15:33:13 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 61DC03BF66; Fri, 10 Aug 2007 21:33:11 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22305-01-2; Fri, 10 Aug 2007 21:33:11 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id EF92F3BE76; Fri, 10 Aug 2007 21:33:10 +0200 (CEST) Message-ID: <46BCBD8B.1020206@it.su.se> Date: Fri, 10 Aug 2007 21:33:31 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Notifications] Reliability References: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> <46BADC44.2060706@it.su.se> <4C38DC11F6B4FF4FAEA73E30DB5AA157E7A870@esebe199.NOE.Nokia.com> <504BEDBB-5B4F-461F-ABE1-990B452B912A@osafoundation.org> In-Reply-To: <504BEDBB-5B4F-461F-ABE1-990B452B912A@osafoundation.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.283 tagged_above=-99 required=7 tests=[AWL=0.029, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org > > 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 stanzas but there is for . Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Aug 10 15:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaF0-0005WT-Fo; Fri, 10 Aug 2007 15:33:46 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJaEy-0005WB-RV for notifications-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 15:33:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaEy-0005Vv-Gv for notifications@ietf.org; Fri, 10 Aug 2007 15:33:44 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJaEy-00040G-4m for notifications@ietf.org; Fri, 10 Aug 2007 15:33:44 -0400 Received: from [10.241.249.1] (nr1-66-42-173-121.fuse.net [66.42.173.121]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l7AJXgSA026320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Aug 2007 15:33:42 -0400 (EDT) In-Reply-To: <504BEDBB-5B4F-461F-ABE1-990B452B912A@osafoundation.org> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157E3F135@esebe199.NOE.Nokia.com> <46BADC44.2060706@it.su.se> <4C38DC11F6B4FF4FAEA73E30DB5AA157E7A870@esebe199.NOE.Nokia.com> <504BEDBB-5B4F-461F-ABE1-990B452B912A@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42AEADF2-B9A8-444D-8B58-540E2940BB19@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Notifications] Reliability Date: Fri, 10 Aug 2007 15:33:42 -0400 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org > 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 > 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 > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Aug 10 21:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJfbW-0006bi-SC; Fri, 10 Aug 2007 21:17:22 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IJfbV-0006bd-BV for notifications-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 21:17:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJfbU-0006bT-Dd for notifications@ietf.org; Fri, 10 Aug 2007 21:17:20 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJfbO-0002ha-5s for notifications@ietf.org; Fri, 10 Aug 2007 21:17:20 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7B1HDPl003938 for ; Sat, 11 Aug 2007 01:17:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JML006013YZ5K00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for notifications@ietf.org; Fri, 10 Aug 2007 19:17:13 -0600 (MDT) Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JML00M8Z4WM2L50@mail-amer.sun.com>; Fri, 10 Aug 2007 19:17:13 -0600 (MDT) Date: Fri, 10 Aug 2007 18:17:22 -0700 From: Chris Newman Subject: Re: [Notifications] Statement of interest, and comments on scope In-reply-to: <46BAD5F7.8040501@ninebynine.org> To: Graham Klyne , Leif Johansson Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <46B853C5.1040807@ninebynine.org> <46B98D7F.6090403@it.su.se> <46BAD5F7.8040501@ninebynine.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Graham Klyne wrote on 8/9/07 9:53 +0100: > (a) an abstract notification model, presumably based on pub-sub, that can be > layered over existing (and new) protocols and is not of itself specific to > email (even though it does not take account of wider requirements), and > (b) an email-specific part that addresses how email notifications can be > conveyed by such a framework. I consider it unlikely an IETF WG could reach closure on an abstract model on this topic. However, the point you're trying to make about modularity of design is an important one. Mail store implementers usually don't want to be experts about notification systems and notification system implementers usually don't want to be experts about mail stores. A good design is likely to take that into account. - Chris _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Aug 13 18:39:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKiZR-00045r-1j; Mon, 13 Aug 2007 18:39:33 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IKiZQ-00045l-61 for notifications-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 18:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKiZP-00045d-Sb for notifications@ietf.org; Mon, 13 Aug 2007 18:39:31 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKiZO-000883-Kb for notifications@ietf.org; Mon, 13 Aug 2007 18:39:31 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 15:39:30 -0700 X-IronPort-AV: i="4.19,256,1183359600"; d="scan'208"; a="199412365:sNHT47928483" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7DMdUwL030194; Mon, 13 Aug 2007 15:39:30 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l7DMdSF5027251; Mon, 13 Aug 2007 22:39:28 GMT In-Reply-To: <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8377A826-8354-4784-B96F-A297AAAAB6AC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Notifications] Use cases Date: Mon, 13 Aug 2007 15:38:11 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1915; t=1187044770; x=1187908770; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Notifications]=20Use=20cases |Sender:=20; bh=sMleAHPINjChdfclxRCjDhCWtwjiOE/95hpknX0ZLds=; b=tp05Ta5HJTKybCO4skdTQKu9GKedI+93JWX0cYEm2Aq1Jt6z0nEerPWG0mZLlzpu93LdQ3Iz JXNLIfWiXbcUXuMR3FzZ7UKECy7i5vsqN25bswigS1UXl9lUKsAyAjM4; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Rohan Mahy , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org It seems like this use case was pretty much outside the email notifications scope we were trying to do for first version. Is this is the you have have to have it , or the could wait till later category? On Jul 30, 2007, at 10:19 AM, Rohan Mahy wrote: > Scenario: > A widget on my cell phone that correlates all package tracking emails > from Federal Express. It is interested in the Subject and To header > of all emails sent From tracker.fedex.com. When it gets a new > notification, it parses the tracking number from the Subject and does > an HTTP fetch to get the current status of the package. It can then > beep or chime or prompt you to send an email or a phone call or SMS > when various things happen (package picked up, package delivered, > package delayed, package cleared customs). > > This model would apply nicely to other widgets for package tracking, > flight status, sales order notifications, and stock trade > confirmations. > > Problem: > The cell phone does not want to poll for new messages (for example > using IMAP) because this would negatively affect battery life. Better > to use an existing open TCP connection already used by SIP or XMPP to > receive these async notifications. > > Also, the phone is only interested in a filtered view of > notifications. There are ways of doing this today in email, but just > forwarding all your email to an IM gateway using a static filter isn't > sufficient. If the phone has multiple widgets, these filters my need > to be somewhat dynamic. > > Market: > Widgets like this are popping up left and right, but they use HTTP > polling. The market would like these apps and decent battery > consumption too. > > thanks, > -rohan > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 14 06:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtEt-0004pC-4K; Tue, 14 Aug 2007 06:03:03 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IKtEr-0004iI-RM for notifications-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 06:03:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtEn-0004aq-E0 for notifications@ietf.org; Tue, 14 Aug 2007 06:02:57 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKtEn-0004iP-1M for notifications@ietf.org; Tue, 14 Aug 2007 06:02:57 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id B22243BE32; Tue, 14 Aug 2007 12:02:55 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21326-01-22; Tue, 14 Aug 2007 12:02:55 +0200 (CEST) Received: from [193.11.30.35] (dhcp-wavelan-vo-35.publik.su.se [193.11.30.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id D479A3BE24; Tue, 14 Aug 2007 12:02:54 +0200 (CEST) Message-ID: <46C17DC7.6070209@it.su.se> Date: Tue, 14 Aug 2007 12:02:47 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Notifications] Use cases References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> <8377A826-8354-4784-B96F-A297AAAAB6AC@cisco.com> In-Reply-To: <8377A826-8354-4784-B96F-A297AAAAB6AC@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.021 tagged_above=-99 required=7 tests=[AWL=0.291, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Rohan Mahy , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Cullen Jennings wrote: > > It seems like this use case was pretty much outside the email > notifications scope we were trying to do for first version. Is this is > the you have have to have it , or the could wait till later category? > > On Jul 30, 2007, at 10:19 AM, Rohan Mahy wrote: > > Why? It sounds to me like a (relatively) straightforward combination of sieve and some notification mechanism running over the existing IM/Presence framework on the phone. Imo it nicely illustrates the need for multiple transports and why existing implementations of pubsub will be a natural point of integration. Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 14 13:14:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzye-0002Xz-Gk; Tue, 14 Aug 2007 13:14:44 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IKzyd-0002Xt-7n for notifications-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 13:14:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzyc-0002Xk-TE for notifications@ietf.org; Tue, 14 Aug 2007 13:14:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKzyc-0004JP-Hv for notifications@ietf.org; Tue, 14 Aug 2007 13:14:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 10:14:42 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="199926737:sNHT43305057" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EHEfbV015322; Tue, 14 Aug 2007 10:14:41 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7EHEaiG014217; Tue, 14 Aug 2007 17:14:36 GMT In-Reply-To: <46C17DC7.6070209@it.su.se> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> <8377A826-8354-4784-B96F-A297AAAAB6AC@cisco.com> <46C17DC7.6070209@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8906B4EA-89A4-4C03-9A73-873F742696AF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Notifications] Use cases Date: Tue, 14 Aug 2007 10:13:20 -0700 To: Leif Johansson X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=909; t=1187111682; x=1187975682; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Notifications]=20Use=20cases |Sender:=20; bh=FBYVS6panTwJRrgt8M1IZl+Jgx/eMucHaov4qj2kNNU=; b=bcoRewMzUF4HQ9tYq/bteC5fuykiIPYU7z89WMj2AsoG4AYfeipbMFWvr3ji0MCTdKr4BXgW zh2RhATv56W7N11TS9gbXNx+oqzMVd5n+ruUebISmRpuxnQXgu1j799R; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Rohan Mahy , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Aug 14, 2007, at 3:02 AM, Leif Johansson wrote: > Cullen Jennings wrote: >> >> It seems like this use case was pretty much outside the email >> notifications scope we were trying to do for first version. Is >> this is >> the you have have to have it , or the could wait till later category? >> >> On Jul 30, 2007, at 10:19 AM, Rohan Mahy wrote: >> >> > Why? It sounds to me like a (relatively) straightforward > combination of sieve and some notification mechanism > running over the existing IM/Presence framework on > the phone. > > Imo it nicely illustrates the need for multiple transports > and why existing implementations of pubsub will be a > natural point of integration. > > Cheers Leif Ok - fair enough. However, if we start dealing with use case outside of mail stores, I probably have over 100. I just failed to see how this one involved a mail store. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 14 17:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3gt-00015K-U0; Tue, 14 Aug 2007 17:12:39 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IL3gs-00015C-Jd for notifications-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 17:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3gs-000154-7t for notifications@ietf.org; Tue, 14 Aug 2007 17:12:38 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL3gm-0006Oi-Pi for notifications@ietf.org; Tue, 14 Aug 2007 17:12:38 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id DCE1D3BF09; Tue, 14 Aug 2007 23:12:29 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03123-01-52; Tue, 14 Aug 2007 23:12:29 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 755183BE24; Tue, 14 Aug 2007 23:12:23 +0200 (CEST) Message-ID: <46C21AC1.4060003@it.su.se> Date: Tue, 14 Aug 2007 23:12:33 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Notifications] Use cases References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> <8377A826-8354-4784-B96F-A297AAAAB6AC@cisco.com> <46C17DC7.6070209@it.su.se> <8906B4EA-89A4-4C03-9A73-873F742696AF@cisco.com> In-Reply-To: <8906B4EA-89A4-4C03-9A73-873F742696AF@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.275 tagged_above=-99 required=7 tests=[AWL=0.037, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Rohan Mahy , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Cullen Jennings wrote: > > On Aug 14, 2007, at 3:02 AM, Leif Johansson wrote: > >> Cullen Jennings wrote: >>> >>> It seems like this use case was pretty much outside the email >>> notifications scope we were trying to do for first version. Is this is >>> the you have have to have it , or the could wait till later category? >>> >>> On Jul 30, 2007, at 10:19 AM, Rohan Mahy wrote: >>> >>> >> Why? It sounds to me like a (relatively) straightforward >> combination of sieve and some notification mechanism >> running over the existing IM/Presence framework on >> the phone. >> >> Imo it nicely illustrates the need for multiple transports >> and why existing implementations of pubsub will be a >> natural point of integration. >> >> Cheers Leif > > Ok - fair enough. However, if we start dealing with use case outside > of mail stores, I probably have over 100. I just failed to see how > this one involved a mail store. Isn't the the mailstore typically where sieve runs? Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 14 20:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL78t-0004kg-4M; Tue, 14 Aug 2007 20:53:47 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IL78r-0004fi-Ss for notifications-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 20:53:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL78r-0004eT-Hk for notifications@ietf.org; Tue, 14 Aug 2007 20:53:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL78r-0000nw-6m for notifications@ietf.org; Tue, 14 Aug 2007 20:53:45 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2007 17:53:45 -0700 X-IronPort-AV: i="4.19,262,1183359600"; d="scan'208"; a="513571723:sNHT48721092" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7F0riCm017279; Tue, 14 Aug 2007 17:53:44 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7F0rciG014932; Wed, 15 Aug 2007 00:53:38 GMT In-Reply-To: <46C21AC1.4060003@it.su.se> References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> <8377A826-8354-4784-B96F-A297AAAAB6AC@cisco.com> <46C17DC7.6070209@it.su.se> <8906B4EA-89A4-4C03-9A73-873F742696AF@cisco.com> <46C21AC1.4060003@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AA8838A-2743-4385-A2EF-9121B18A306E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Notifications] Use cases Date: Tue, 14 Aug 2007 17:52:20 -0700 To: Leif Johansson X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1154; t=1187139224; x=1188003224; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Notifications]=20Use=20cases |Sender:=20; bh=lVJ0RQv0hewxJPnLJFpHlxFIyvt0kkvCEbIiumxlK1k=; b=mZF7qOFH7J783zMrD5gDFvbZMGOZ36wEKRr3oso0FdwbScao5sv9zq2iNUsUg99LrW6amkmJ xwoCy1c60lkyVyhjVaymTxEtLd3Cn/UPGZzaP7rowKi5PyUJo0JVWtjZ; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Rohan Mahy , notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Aug 14, 2007, at 2:12 PM, Leif Johansson wrote: > Cullen Jennings wrote: >> >> On Aug 14, 2007, at 3:02 AM, Leif Johansson wrote: >> >>> Cullen Jennings wrote: >>>> >>>> It seems like this use case was pretty much outside the email >>>> notifications scope we were trying to do for first version. Is >>>> this is >>>> the you have have to have it , or the could wait till later >>>> category? >>>> >>>> On Jul 30, 2007, at 10:19 AM, Rohan Mahy wrote: >>>> >>>> >>> Why? It sounds to me like a (relatively) straightforward >>> combination of sieve and some notification mechanism >>> running over the existing IM/Presence framework on >>> the phone. >>> >>> Imo it nicely illustrates the need for multiple transports >>> and why existing implementations of pubsub will be a >>> natural point of integration. >>> >>> Cheers Leif >> >> Ok - fair enough. However, if we start dealing with use case outside >> of mail stores, I probably have over 100. I just failed to see how >> this one involved a mail store. > Isn't the the mailstore typically where sieve runs? yes - you are right > > Cheers Leif _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Aug 22 23:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO3Uv-0001qR-S9; Wed, 22 Aug 2007 23:36:41 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IO3Uv-0001qJ-3u for notifications-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 23:36:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO3Uu-0001q4-Q1 for notifications@ietf.org; Wed, 22 Aug 2007 23:36:40 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO3Ut-0002Ih-U1 for notifications@ietf.org; Wed, 22 Aug 2007 23:36:40 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN700JFOJBWJ2@szxga04-in.huawei.com> for notifications@ietf.org; Thu, 23 Aug 2007 11:35:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN7007OLJBW1U@szxga04-in.huawei.com> for notifications@ietf.org; Thu, 23 Aug 2007 11:35:56 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN7002FTJBS11@szxml03-in.huawei.com> for notifications@ietf.org; Thu, 23 Aug 2007 11:35:56 +0800 (CST) Date: Thu, 23 Aug 2007 11:35:52 +0800 From: Qian Sun To: notifications@ietf.org Message-id: <004f01c7e536$b4931040$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcflNrQ9WeOsDg6DSXKPwEtHqJeJuQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Notifications] Use case--reply mail notification X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Hi, all Scenario: Bob is sending a email to Alice. Bob wants to get a instant notification via SMS something if Alice replies, since he is eager to know the reply of Alice. He is not interested in other emails. When Bob's mailbox in the email server recieves a new email, and find out it is a reply from Alice for that mail, a notification of SMS,like "You have got a reply mail from Alice", will be sent to Bob's cellphone. Problem: For the email sending part, I prefer to realize this requirement by using a SMTP extension, e.g. define a new parameter for MAIL command, which includes the SMS URI or IM URI. (To Webmail, we need not to do any standard.) For the notification part, pager mode message may be better; SUB/NOT event mechanism is not necessary. For example, SIP MESSAGE could be a good choice, if the users only want to get few notifications. Market: It might be an attractive feature to enhance the existing email service. Opinion? Cheers, Qian _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Sat Aug 25 07:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOtQK-0003Cn-IQ; Sat, 25 Aug 2007 07:03:24 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IOtQJ-00037h-3R for notifications-confirm+ok@megatron.ietf.org; Sat, 25 Aug 2007 07:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOtQI-00037Y-QC for notifications@ietf.org; Sat, 25 Aug 2007 07:03:22 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOtQG-0000Y1-78 for notifications@ietf.org; Sat, 25 Aug 2007 07:03:22 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7PB3A3C022523; Sat, 25 Aug 2007 04:03:10 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7PB37H6007042; Sat, 25 Aug 2007 04:03:09 -0700 Received: from 10.43.242.9 ([10.43.242.9]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sat, 25 Aug 2007 11:03:08 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 24 Aug 2007 21:03:13 -0400 Subject: Re: [Notifications] Use case--reply mail notification From: Eric Burger To: Qian Sun , Message-ID: Thread-Topic: [Notifications] Use case--reply mail notification Thread-Index: AcflNrQ9WeOsDg6DSXKPwEtHqJeJuQBfQG8O In-Reply-To: <004f01c7e536$b4931040$7c6c460a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.9 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Why not use MDN and a sieve filter? Sounds like major surgery to do what people do every day with today's tools. On 8/22/07 11:35 PM, "Qian Sun" wrote: > Hi, all > > Scenario: Bob is sending a email to Alice. Bob wants to get a instant > notification via SMS something if Alice replies, since he is eager to know the > reply of Alice. He is not interested in other emails. When Bob's mailbox in > the email server recieves a new email, and find out it is a reply from Alice > for that mail, a notification of SMS,like "You have got a reply mail from > Alice", will be sent to Bob's cellphone. > > Problem: For the email sending part, I prefer to realize this requirement by > using a SMTP extension, e.g. define a new parameter for MAIL command, which > includes the SMS URI or IM URI. (To Webmail, we need not to do any standard.) > For the notification part, pager mode message may be better; SUB/NOT event > mechanism is not necessary. For example, SIP MESSAGE could be a good choice, > if the users only want to get few notifications. > > Market: It might be an attractive feature to enhance the existing email > service. > > Opinion? > > Cheers, > Qian > > > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications 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. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Aug 27 07:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdB7-0000jA-3c; Mon, 27 Aug 2007 07:54:45 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IPdB5-0000bv-Dk for notifications-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 07:54:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdB0-0000aH-5k for notifications@ietf.org; Mon, 27 Aug 2007 07:54:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPdAz-0001k0-4y for notifications@ietf.org; Mon, 27 Aug 2007 07:54:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNF001MBL1YCQ@szxga02-in.huawei.com> for notifications@ietf.org; Mon, 27 Aug 2007 19:53:58 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNF0020DL1X35@szxga02-in.huawei.com> for notifications@ietf.org; Mon, 27 Aug 2007 19:53:58 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNF00JFIL1TYY@szxml03-in.huawei.com> for notifications@ietf.org; Mon, 27 Aug 2007 19:53:57 +0800 (CST) Date: Mon, 27 Aug 2007 19:53:53 +0800 From: Qian Sun Subject: RE: [Notifications] Use case--reply mail notification In-reply-to: To: 'Eric Burger' Message-id: <000901c7e8a0$f0ffb610$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcflNrQ9WeOsDg6DSXKPwEtHqJeJuQBfQG8OAHqk6pA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Hello, Eric Any document defines a "reply" disposition type? And some people might prohibit MDN. Do you want to set a sieve script like this? if header :contains "In-Reply-To" "143243@example.com" { notify :message "You got reply mail" "sms: +10231223"; If not, could you explain your solution in more details? Cheers, Qian -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Saturday, August 25, 2007 9:03 AM To: Qian Sun; notifications@ietf.org Subject: Re: [Notifications] Use case--reply mail notification Why not use MDN and a sieve filter? Sounds like major surgery to do what people do every day with today's tools. On 8/22/07 11:35 PM, "Qian Sun" wrote: > Hi, all > > Scenario: Bob is sending a email to Alice. Bob wants to get a instant > notification via SMS something if Alice replies, since he is eager to know the > reply of Alice. He is not interested in other emails. When Bob's mailbox in > the email server recieves a new email, and find out it is a reply from Alice > for that mail, a notification of SMS,like "You have got a reply mail from > Alice", will be sent to Bob's cellphone. > > Problem: For the email sending part, I prefer to realize this requirement by > using a SMTP extension, e.g. define a new parameter for MAIL command, which > includes the SMS URI or IM URI. (To Webmail, we need not to do any standard.) > For the notification part, pager mode message may be better; SUB/NOT event > mechanism is not necessary. For example, SIP MESSAGE could be a good choice, > if the users only want to get few notifications. > > Market: It might be an attractive feature to enhance the existing email > service. > > Opinion? > > Cheers, > Qian > > > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications 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. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 28 14:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5MQ-0006Eh-OR; Tue, 28 Aug 2007 14:00:18 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IQ5MQ-0006B4-5k for notifications-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 14:00:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5MP-00068h-Ox for notifications@ietf.org; Tue, 28 Aug 2007 14:00:17 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ5MP-0000c1-4E for notifications@ietf.org; Tue, 28 Aug 2007 14:00:17 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7SHxxBH004767; Tue, 28 Aug 2007 10:59:59 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7SHxvDZ007387; Tue, 28 Aug 2007 10:59:58 -0700 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: 7bit Subject: RE: [Notifications] Use case--reply mail notification Date: Tue, 28 Aug 2007 10:59:50 -0700 Message-ID: In-Reply-To: <000901c7e8a0$f0ffb610$7c6c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Use case--reply mail notification Thread-Index: AcflNrQ9WeOsDg6DSXKPwEtHqJeJuQBfQG8OAHqk6pAAP7JPoA== References: <000901c7e8a0$f0ffb610$7c6c460a@china.huawei.com> From: "Eric Burger" To: "Qian Sun" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org In the "do it today", the execution step runs an external shell script, but yes, this is the basic flow. Remember, that to protect the privacy interests of the recipient, just as they can prohibit MDN, they can prohibit "automatic SMS notification." -----Original Message----- From: Qian Sun [mailto:sunqian@huawei.com] Sent: Monday, August 27, 2007 7:54 AM To: Eric Burger Cc: notifications@ietf.org Subject: RE: [Notifications] Use case--reply mail notification Hello, Eric Any document defines a "reply" disposition type? And some people might prohibit MDN. Do you want to set a sieve script like this? if header :contains "In-Reply-To" "143243@example.com" { notify :message "You got reply mail" "sms: +10231223"; If not, could you explain your solution in more details? Cheers, Qian -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Saturday, August 25, 2007 9:03 AM To: Qian Sun; notifications@ietf.org Subject: Re: [Notifications] Use case--reply mail notification Why not use MDN and a sieve filter? Sounds like major surgery to do what people do every day with today's tools. On 8/22/07 11:35 PM, "Qian Sun" wrote: > Hi, all > > Scenario: Bob is sending a email to Alice. Bob wants to get a instant > notification via SMS something if Alice replies, since he is eager to > know the reply of Alice. He is not interested in other emails. When > Bob's mailbox in the email server recieves a new email, and find out > it is a reply from Alice for that mail, a notification of SMS,like > "You have got a reply mail from Alice", will be sent to Bob's cellphone. > > Problem: For the email sending part, I prefer to realize this > requirement by using a SMTP extension, e.g. define a new parameter for > MAIL command, which includes the SMS URI or IM URI. (To Webmail, we > need not to do any standard.) For the notification part, pager mode > message may be better; SUB/NOT event mechanism is not necessary. For > example, SIP MESSAGE could be a good choice, if the users only want to get few notifications. > > Market: It might be an attractive feature to enhance the existing > email service. > > Opinion? > > Cheers, > Qian > > > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications 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. 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. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Aug 28 23:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEQJ-0003IN-GJ; Tue, 28 Aug 2007 23:40:55 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IQEQI-0003II-VH for notifications-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 23:40:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEQI-0003I9-Jj for notifications@ietf.org; Tue, 28 Aug 2007 23:40:54 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQEQH-0002El-Ev for notifications@ietf.org; Tue, 28 Aug 2007 23:40:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNI005F2NIVDI@szxga02-in.huawei.com> for notifications@ietf.org; Wed, 29 Aug 2007 11:40:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNI00GUINIUUQ@szxga02-in.huawei.com> for notifications@ietf.org; Wed, 29 Aug 2007 11:40:07 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNI0040FNIPS3@szxml04-in.huawei.com> for notifications@ietf.org; Wed, 29 Aug 2007 11:40:06 +0800 (CST) Date: Wed, 29 Aug 2007 11:40:01 +0800 From: Qian Sun Subject: RE: [Notifications] Use case--reply mail notification In-reply-to: To: 'Eric Burger' Message-id: <000001c7e9ee$47d5a320$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcflNrQ9WeOsDg6DSXKPwEtHqJeJuQBfQG8OAHqk6pAAP7JPoAATXg6Q X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Hello Eric I don't think so. A recipient can not prohibit things in sender's mail server. And the sender's mail server has no reason to prohibit the sender to know what stuff is in the sender's mailbox. In detail: When a reply email arrives at sender's mail server, the server may check if the in-reply-to or references header field of this reply email contains the recorded message-id value of original email. If YES, then the sender's server can send an automatic SMS notification to the sender. The recipient can prohibit MDN in his email client, but how can the recipient prohibit this "automatic SMS notification"? Cheers, Qian -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Wednesday, August 29, 2007 2:00 AM To: Qian Sun Cc: notifications@ietf.org Subject: RE: [Notifications] Use case--reply mail notification In the "do it today", the execution step runs an external shell script, but yes, this is the basic flow. Remember, that to protect the privacy interests of the recipient, just as they can prohibit MDN, they can prohibit "automatic SMS notification." -----Original Message----- From: Qian Sun [mailto:sunqian@huawei.com] Sent: Monday, August 27, 2007 7:54 AM To: Eric Burger Cc: notifications@ietf.org Subject: RE: [Notifications] Use case--reply mail notification Hello, Eric Any document defines a "reply" disposition type? And some people might prohibit MDN. Do you want to set a sieve script like this? if header :contains "In-Reply-To" "143243@example.com" { notify :message "You got reply mail" "sms: +10231223"; If not, could you explain your solution in more details? Cheers, Qian -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Saturday, August 25, 2007 9:03 AM To: Qian Sun; notifications@ietf.org Subject: Re: [Notifications] Use case--reply mail notification Why not use MDN and a sieve filter? Sounds like major surgery to do what people do every day with today's tools. On 8/22/07 11:35 PM, "Qian Sun" wrote: > Hi, all > > Scenario: Bob is sending a email to Alice. Bob wants to get a instant > notification via SMS something if Alice replies, since he is eager to > know the reply of Alice. He is not interested in other emails. When > Bob's mailbox in the email server recieves a new email, and find out > it is a reply from Alice for that mail, a notification of SMS,like > "You have got a reply mail from Alice", will be sent to Bob's cellphone. > > Problem: For the email sending part, I prefer to realize this > requirement by using a SMTP extension, e.g. define a new parameter for > MAIL command, which includes the SMS URI or IM URI. (To Webmail, we > need not to do any standard.) For the notification part, pager mode > message may be better; SUB/NOT event mechanism is not necessary. For > example, SIP MESSAGE could be a good choice, if the users only want to get few notifications. > > Market: It might be an attractive feature to enhance the existing > email service. > > Opinion? > > Cheers, > Qian > > > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications 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. 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. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications