Notifications are a mechanism for making users or processes aware of events relating to an entity such as a document or set of documents. Notifications are sent as real-time or queued messages and may represent a discrete event or be a summary of events. Notifications deal with both syntatic and semantic events.
The group considered it important to implement notification support in a fashion that improved network scalibility. One consideration was that the user/process's local proxy needed to be able to manage the origination of notifications regarding events it might be aware of.
Notifications will support requirements ranging from management of the WWW infrastructure thru application specific requirements. To accomplish this, a number of attributes need to be associated with notifications. These must include structured values understood by the WWW as well as application unique attributes. The representation should be compact but extensible. System attributes should include characteristics such as expiration and the entity to which the notification applies.
Much of the groups time was spent discussing how notifications might address various problems. In this evaluation, we noticed a number of related missing infrastructure elements which we will also mention.
The issue here is that there is currently no proposed mechanism within the HTTP protocol which allows an owning server to invalidate cached replicas of objects. We believe owner to replicator (proxy cache) notification can substantially improve network behavior by improving data quality at the same time content provider motivation for short expiration cycles is reduced. This provision also allows the proxy to carry the burden of notification of users and processes known to the proxy.
We also noted that notifications were a logical mechanism by which a proxy would notify the owner of document usage. Again encouraging network providers to enable caching of their content.
I believe we had consensus that user discovery of new and/or changed content in the sense of general surfing was usually a second order problem in that the user would utilize a service which indexed the WWW and made the user aware of what is discovered via search requests or stored profiles which might generate a single notification as a result of many new items.
There was a class of usage we recognized where immediate or rapid awareness was important but this was in the context of existing entities whose change was significant. Therefore, it seemed like notification requirements would be registered as an interest in specific entities.
The fundamental consumer we envisioned for new/change (including deletion) notification were processes which perform content discovery on the WWW (e.g., build indices). By providing notifications, the need to interrogate servers and retrieve documents solely for the purpose of detecting change would be eliminated.
Critical to workflow management is awareness of responsibility for tasks and even failure of others to meet their responsibilities. While some workflow requirements can be met by having users poll periodically for new tasks, this approach does not satisfy time critical applications. This form of notification was envisioned as a combination of notifications based on WWW server recognized events and notifications generated directly by the application.
Notifications seem to run the gamut from must deliver to preserve the integrity of a process to awareness of an event which has no real bearing on any decisions the receiver would make. Often this distinction will vary by receiver much like the chime of a clock will panic an individual late for an important meeting while letting another individual know time is passing.
We felt a fundamental part of the implementation of notification support will be a notification server capable of queuing notifications on a reliable basis when the recipient is available. We envisioned that the candidate notification recipient would establish a connection with the notification server which would remain active as long as the recipient was able to receive notifications. The recipient process (user agent, HTTP proxy, etc.) would be responsible for delivery of notifications in a suitable fashion. We expected the delivery mechanism might range from immediate replacement of an invalid document to changing a border from green to red for a less critical document to providing the user with updates to their TODO list(s). Other notifications might be delivered to a subsidiary (e.g., helper) application.
We observed that many notifications did not require discrete delivery. For example, 27 new entries in a on-line conference need only appear to the user as a single notification, perhaps with an occurrence count. Such entries might be summarized by the conference server, the user agent, or both.
We postulated that not all service providers would be able or willing to fulfill change notification or indexing service requirements implied by our scenarios. We acknowledged that some service providers will never provide notification support, etc. Soft recovery from that situation will likely be that their content does not participate in change sensitive usage.
Other providers will contract with another server. To allow for this situation, we believe it will be necessary for a universal service to provide a mechanism for identification of notification and indexing services which support individual servers. We envision that these attributes might be provided during URN->URL resolution, etc. There might also be an HTTP server attribute query which would provide this sort of information.
We did not address the issue of user agent state changes or any other user agent originated notifications. Based on comment during the group presentation, I would note that there is some set of other notifications which need to originate with the client. For example, receipt acknowledgement. The group did not discuss this topic.
The ultimate conclusion was that we had barely scratched the surface of issues related to notifications. Notifications represent a mechanism for improving scalibility of the WWW by providing an alternative to polling for change in a fashion similar to the considerations a system designer encounters when balancing the use of interrupts vs. polling for state changes.
Furthermore, notifications are important to the successful deployment of many WWW based applications.
We observed that many solution examples exist for notification specific and the WWW problem set in general. I think we felt that research would be more exploration for existing solutions which can be adapted and less discovery of new technology. One area for investigation we identified was the distinction between semantic and syntatic notification. How does the WWW provide users with semanticly interesting awareness of change. We believe that interest is very much in the eyes of the beholder. For example, an editor might want to know about every change to content while a user of a document such as a product description might only care about specification or price changes, etc.
During our presentation, we identified two issues to be pursued by the W3C:
The more notification specific W3C issue is the follow-on BOF-like activity proposed during the wrap-up which is hoped to further study and refine understanding of notifications and ultimately result in protocols, standards, and other workproducts applicable to the WWW.
I have taken substantially more time to record these thoughts than our group had for the initial discussion. I have attempted to reflect the state of discussion and except for my reflection immediately above have not intentionally recorded my own follow-up reflections. We did not pursue any passive alternatives to notification other than a brief observation that there are situations where some form of polling can be much kinder to the network. My belief (not expressed to the group) is that many kinds of user notification can be best provided by having the user request via index/search facilities access to new/changed information. Even many event notifications can be best recorded and presented as dynamic/or quasi dynamic HTML pages specific to the user.