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

From: Graham Klyne <[email-masked]>
Date: Tue, 07 Aug 2007 12:13:09 +0100

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.
 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.

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

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

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

ain; charset=ISO-8859-1
Subject: [Notifications] Statement of interest, and comments on scope

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.
 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.

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

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

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

---

From: Leif Johansson <[email-masked]>
Date: Wed, 08 Aug 2007 11:31:43 +0200

> http://imageweb.zoo.ox.ac.uk/wiki/index.php/DefiningImageAccess/Standard/WebEventDelivery.
Seems useful.
> notification framework that is as independent of any specific application as
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.
> -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html
Cheers Leif

---

From: Eric Burger <[email-masked]>
Date: Thu, 09 Aug 2007 03:10:16 +0900

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?

>> -- http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html

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.

---

From: Chris Newman <[email-masked]>
Date: Wed, 08 Aug 2007 13:14:48 -0700

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:

>> (http://www1.ietf.org/mail-archive/web/notifications/current/msg00051.html),
>> I note that the scope of activity is up for debate.
>>
>> 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:
>> 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.
>>
>> Dave Crocker suggests that the notification service should be very lean with
>> no understanding of what is being sent.
>> ]]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 08 Aug 2007 22:39:53 +0200

Chris Newman wrote:
> 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
>
>
I'm not surprised nor do I disagree. Would you support a charter
which explicitly specifies profiling existing implementation(s) of
(say) a publish subscribe metaphor?

If so you'd have to address the issue of the email client growing
a sip stack (or an xmpp stack).

    Cheers Leif

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 8 Aug 2007 14:12:09 -0700

> a sip stack (or an xmpp stack).

Not necessarily.  Email clients that already support IMAP can use  
IMAP IDLE; this might not be so useful for existing rich email  
clients but instead for POP clients, HTTP clients or helper  
applications.  Of course if the event subscription features are  
useful enough even an IMAP client with access to IDLE might use  SIP  
or XMPP.  Some email clients already have such stacks, possibly  
proprietary approximations or access to a related application with  
such a stack -- my email client can tell me when somebody I'm  
emailing, who is also in my buddy list, happens to be online,  
provided iChat is running.

Lisa

---

From: Aki Niemi <[email-masked]>
Date: Thu, 09 Aug 2007 10:10:34 +0300

> a sip stack (or an xmpp stack).

This goes a bit beyond what standards actually can address, but I think
it the field there are frameworks that basically provide these protocols
as a system service that other applications can use. As an example, the
Symbian SIP stack allows any applications to register themselves for
certain types of SIP communications, and the freedesktop.org's telepathy
framework [1] allows for something similar via DBUS, an IPC bus.

Plus there are many, many open source implementations of SIP and XMPP,
which means no need to implement from scratch (which would be the only
available approach to a brand new protocol).

So I don't think the IETF would need to address this issue a whole lot
more than, say, the issue of an email client having to grow a TLS stack.

Cheers,
Aki

[1] http://telepathy.freedesktop.org/wiki/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 9 Aug 2007 09:22:54 +0200

Yes. 

We have been paying marginal attention from the perspective of the OPS
area, as long as the scope of the work that is discussed stays within
the realm of mail, as defined in the BOF scope. If we want to discuss
about a more general applicability that is covering real-time
applications and has operational implications beyond mail services, the
discussions need to happen in a different context and involve a broader
community. 

And yes, duplication of functionality already present in other areas is
a concern. 

Dan

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]] 
> Sent: Wednesday, August 08, 2007 11:15 PM
> To: Leif Johansson; Graham Klyne
> Cc: [email-masked]
> Subject: Re: [Notifications] Statement of interest, and 
> comments on scope
> 
> 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
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Aug 2007 09:39:42 +0200

> [1] http://telepathy.freedesktop.org/wiki/
Actually both you and Lisa addressed the issue when you said
the IETF wouldn't have to :-) You both make the point that
desktop OSen tend to be structured differently today using
lots of infrastructure.

Thats a perfectly reasonable response to my question: its not a
problem since there are very few truly stand-alone applications
anymore.

    Cheers Leif

---

From: Graham Klyne <[email-masked]>
Date: Thu, 09 Aug 2007 09:53:11 +0100

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
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Aug 2007 16:21:02 +0200

> conveyed by such a framework.
+1 - it seems realistic although it is important that the wg is able to
put some meat on (a) so that it has implications for interoperability.
> I hope this helps to clarify my position.
At least for me it does.

    Cheers Leif

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 11:54:06 -0400

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

---

From: Chris Newman <[email-masked]>
Date: Fri, 10 Aug 2007 18:17:22 -0700

Graham Klyne wrote on 8/9/07 9:53 +0100:
> 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

I consider it unlikely an IETF WG could reach closure on an abstract model on 
this topic.  However, the point you're trying to make about modularity of 
design is an important one.  Mail store implementers usually don't want to be 
experts about notification systems and notification system implementers usually 
don't want to be experts about mail stores.  A good design is likely to take 
that into account.

                - Chris