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

[Henning Schulzrinne <[e-mail]>]

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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/notifications
>>
>
> -- 
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>
>
>
> _______________________________________________
> Notifications mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/notifications



_______________________________________________
Notifications mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/notifications