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

Graham Klyne <GK@ninebynine.org> Thu, 09 August 2007 08:58 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 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 <GK@ninebynine.org>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Leif Johansson <leifj@it.su.se>
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 <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

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