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

[Chris Newman <[e-mail]>]

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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/notifications
>






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