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

[Eric Burger <[e-mail]>]

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