It's good that the need has been identified, but the protocol
(http://www.blip.org/protocol.htm) looks a bit crude - not even a mention
of the word "multicast".
>Comments: Authenticated sender is <mattj%blip.org@pop3.blip.org>
>From: "Matt Jensen" <mattj@blip.org>
>To: notification@makelist.com
>Date: Sat, 23 May 1998 14:18:56 +0000
>Subject: Notification mailing list - A unified effort
>X-mailer: Pegasus Mail for Windows (v2.42a)
>Sender: owner-ietf-calendar@imc.org
>
>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 quick 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@makelist.com. To subscribe, send an empty message to
>notification-subscribe@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.
>
>We want to hear your opinions on these matters. Thanks for your time.
>
>-Matt Jensen
> BLIP Project Director
> mattj@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.]
>
>
-- Mark Baker. CTO, Beduin Communications Corp Ottawa, Ontario, CANADA http://www.beduin.com