ietf-nntp Notification list - A unified effort

[Matt Jensen]

We're announcing the Notification mailing list to discuss ways to
unify Internet notification efforts.

This message is being blind-cc'd to mailing lists and individuals who
have discussed a need for a near-real-time notification service. We want to
quickly know when, for example...

* A friend comes online. (RVP/Buddy List group)

* A document has finished printing. (Internet Printing Protocol group)

* Someone releases their hold on a document I'm waiting to edit.
(WebDAV group)

There are also other uses for quick notification (pushing news,
linking distributed systems, remote monitoring, etc.) which do not
currently have mailing lists or working groups of their own.

It is becoming clear to many people that there is a growing need for a
UNIFIED EFFORT to provide a single notification protocol/service that
all of these groups could use, rather than have each group create
overlapping solutions.

A new mailing list has been set up for this discussion at
notification at makelist.com. To subscribe, send an empty message to
notification-subscribe at makelist.com . An archive is available at
http://www.findmail.com/list/notification/ .


This mailing list is for:

1. Discussing requirements of a single notification system which would
work for different groups. 2. Defining an open protocol which meets
those requirements.

We hope you will join this list, even if (or especially if) you are
not sure this unified approach is right for your notification needs.
If you discuss notification in other lists, we would appreciate you
cc'ing the Notification list, too. Below we discuss the rationale for
this effort. 


The benefits of a such a single service include:

* Avoids duplication of effort. Invent the wheel only once. 

* Avoids extra administrative burden. Issues of bandwidth, servers,
accounts, passwords, and integration are handled only once, by the
notification server. The alternative is that every other service
(buddy lists, printers...) duplicates those demands by doing their own
notification.

* Speeds standards design. If your working group can hand off the
notification issue, you can finish the rest of your design faster.

* Provides inter-group leverage. Without a single standard, it's
difficult for messages in these different contexts to be integrated.
For example, you might want a document to be printed as soon as a user
finishes editing it. Or a security sensor alert could be sent to your
Instant Message software, and also logged in a database somewhere
else.

The possible drawbacks are:

* A separate notification effort might provide fewer features than a
group needs, or burden them with unneeded features.

* It might slow a group down to have to wait for the results of the
notification group.

We believe these are valid concerns, but we also believe at this point
that:

1. The dangers of feature mismatch are not significant right now. The
different applications seem to require very similar sets of
requirements. As for overspecifying, note that with a separate
notification approach, you could end up with LESS work because you
wouldn't have to implement notifications in your system; you could use
someone else's compliant notification service through an API.

2. We think the notification problem can be solved faster with a
specialized effort. Some of us who have been focused on the issue for
a long time have worked through problems that others are only starting
to discover.

3. In the near future, people are going to demand more integration
between these groups.  It would be easier to have everyone use the
same tools early on than to stitch everyone together after wide
deployment of different tools.

Thanks for your time. 

-Matt Jensen
 BLIP Project Director
 mattj at blip.org

[Full disclosure: Our volunteer group, BLIP.org, has been developing
an open protocol for notification over the last year. You can check
out what we have so far at www.blip.org.]