Re: [Notifications] Statement of interest, and comments on scope

Leif Johansson <leifj@it.su.se> Wed, 08 August 2007 09:31 UTC

Return-path: <notifications-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 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 <leifj@it.su.se>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Graham Klyne <GK@ninebynine.org>
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 <notifications.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/notifications>, <mailto:notifications-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/notifications>
List-Post: <mailto:notifications@ietf.org>
List-Help: <mailto:notifications-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/notifications>, <mailto:notifications-request@ietf.org?subject=subscribe>
Errors-To: notifications-bounces@ietf.org

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