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 <email@example.com>
>From: "Matt Jensen" <firstname.lastname@example.org>
>Date: Sat, 23 May 1998 14:18:56 +0000
>Subject: Notification mailing list - A unified effort
>X-mailer: Pegasus Mail for Windows (v2.42a)
>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.
>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
>A new mailing list has been set up for this discussion at
>email@example.com. To subscribe, send an empty message to
>firstname.lastname@example.org . An archive is available at
>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
>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
>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
>* 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
>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
>We believe these are valid concerns, but we also believe at this point
>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
>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.
> BLIP Project Director
>[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