Skip to main content

Note: Unified Notification Protocol Considerations, July 2003
statement-iab-2003-07-10-iab-notification-00

Document Type IAB Statement
Title Note: Unified Notification Protocol Considerations, July 2003
Published 2003-07-10
Metadata last updated 2023-08-09
State Active
Send notices to (None)
statement-iab-2003-07-10-iab-notification-00

Note: Unified Notification Protocol Considerations

This note was formulated in response to an informal IESG request to look at the architectural issues surrounding a unified notification protocol. The following materials were used as reference:

  • draft-dusseault-s2s-event-reqs-00.txt (notification requirements)
  • meeting notes for the LEMONADE WG from IETF 56.
  • draft-shapira-snap-05.txt (protocol design for SNAP which has some aspects of a generic notification protocol)
  • the LEMONADE WG charter
  • Recent email on the Lemonade list
  • A few presentations from the 1998 UCI workshop on Internet-wide notification
  • The Web pages for KnowHow, a company founded by Rohit Khare which has a proprietary Internet-wide notification system.

Thanks to Lisa Dusseault for providing these references.

Note that this opinion does not represent IAB concensus, it is just the opinion of the author after having reviewed the references.

After the reviewing the material, it seemed that the same kinds of functionality are being asked from a generic notification protocol as are asked of desktop application integration mechanisms, like OLAY/COM on Windows or like Tooltalk was on Solaris, but at the level of messaging across the Internet. The desire is that various distributed applications with different application specific mechanisms should be able to interoperate without having an n x n problem of having each application interact with each other application. The cannonical example, which is in a presentation by Lisa Dusseault to LEMONADE from IETF 56, is sending a notification from one application, like XMPP Instant Messaging, and having it delivered on whatever device the recipient happened to be using at the time, like SMS on a cell phone.

The usual problem with application intergration mechanisms on the desktop is how to get the various applications to actually use the mechanism. For Windows, this is relatively easy, since most application developers see major value-added in their applications being able to play nicely with Microsoft Office. For Tooltalk, unfortunatly, Solaris developers didn’t see the 10x improvement, and so it was not used outside of Sun’s internally maintained applications and a few flagship applications like Framemaker. If the generic notification mechanism requires application developers and other notification protocol designers to make a major effort to utilize it, including modifying their applications or protocols in some way, the protocol could become “just another notification mechanism” rather than a unifying device, because most application developers and other protocol designers could ignore it.

So the first architectural consideration is how do clients of a particular protocol (and the word “client” is used here here to mean “any entity using the protocol”, they may peers or they may be client/server) actually utilize the generic notification protocol? Is there some code change required in the client or can a legacy client interoperate without change?

If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems to be that the notifying client uses the generic protocol, SNAP in this case, to a functional entity (server? module on the receiving client?) called the “Notification Service” that processes the generic notification into an application specific notification and sends that notification to the client. From this figure it looks as if the notifying client would require modification but the receiving client wouldn’t.

Another characteristic of application integration mechansims is that they typically focus on very simple operations, the semantics of which are shared between different applications. Examples are “here’s a rectangle, display yourself in it” or “put this styled text object into the clipboard”, and applications agree on what styled text means. More complicated semantics are hard to share because each application has its own particular twist on the meaning of a particular sequence of operations on a collection of objects. The result is a “least common denominator” collection of integration mechanisms, primarily focussed on display integration and, to a lesser extent, cut and paste integration.

In the context of a generic notification protocol, this raises several possible issues. One is addressing, which is identified draft-dusseault- s2s-event-reqs-00.txt, but in a sense this is the easiest to resolve, by using existing and perhaps newly defined URIs. A more complex problem is matching the semantics of what preconditions constitute the trigger for an event across different application notification mechanisms. This is of course necessary for translating notifications between the different event notification mechanisms and the generic mechanism, but, more problematically, it is also required for a subscription service whereby subscriptions can be made to filter events using the generic notification mechanism and the subscriptions can be translated to different application specific mechanisms. Any language for expressing generic subscriptions is unlikely to support expressing the fine points in the different application notification semantics. Note that SNAP does not seem to support a subscription service so perhaps this isn’t an issue for SNAP.

Another architectural issue, which was discussed earlier this year on the LEMONADE list w.r.t. some other topics, is gatewaying. The cannonical example above (message sent using XMPP and arriving via SMS on a cell phone) is actually a gateway example, because it would require translation between an IP-based messaging mechanism (XMPP) to a PSTN based mechanism (SMS). The problem with using a unified notification mechanism for this purpose is that if there are other functions common between the two, it is likely that a gateway will be built anyway. In fact, one of the work items for LEMONADE is to investigate such gateways. The value of a generic notification mechanism therefore needs to be assessed in the light of this.

These are the primary architectural issues, but there are a few others that need consideration in any major system development effort. End to end security is one, draft-dusseault-s2s-event-reqs-00.txt talks about this quite extensively, so it won’t be repeated here. The major issue is how to ensure that the end to end security properties are maintained in the face of movement of the notification through the generic intermediary protocol. Another issue is scalability. Peer to peer v.s. server based mechanisms have implications for how scalable the notification mechanism would be, and this needs consideration. Extensibility needs careful consideration. What is required to integrate a new application? Ideally, with time, application developers will stop “rolling their own” notification service and simply use the generic service, but this ideal may be extremely hard to achieve, and may depend to a large extent on market acceptance.

Finally, there are some considerations that aren’t architectural but may impact the ultimate success of a generic notification protocol, in the sense that the protocol becomes widely deployed and used. The author’s experience is that IETF has not had particular success in introducing mechanisms that unify or supplant existing proprietary mechanisms unless strong vendor and service provider by-in is there. Two examples are instant messaging and service discovery. With instant messaging, it seems that a standarized, unified instant messaging protocol has been delayed by the lack of committment from major service providers. With service discovery, weak commitment from vendors has resulted in the continued introduction of vendor specific service discovery solutions even after an IETF standard is in place. The situation with service discovery (with which the author is most familiar) resulted from a lack of major vendor committment during the end phases of the standarization process. Applying these lessions to a generic notification protocol, having important players with proprietary notification protocols on board and committed until the conclusion of the design process will be crucial. Major committment is needed from various application notification protocols before a generic mechanism could succeed. Given the amount of time and effort required in any IETF standardization work, assessing these with an objective eye is critical, otherwise, regardless of how technically well designed the protocol is, deployment success may be lacking. Having an elegently design solution that nobody deploys is an outcome that might be wise to avoid.

James Kempf

July 2003