Event Notification Services (NOTIFY) Working Group -------------------------------------------------- Status ------ Charter revision level 0.1, 25 August 1998 Needs a limiting of scope - contact adam at xent dot com Chair(s): --------- ? Applications Area Directors: ------------------------------ Keith Moore Patrik Faltstrom Applications Area Advisor: -------------------------- Patrik Faltstrom (?) Mailing Lists: -------------- General Discussion: notification@makelist.com List Owner: notification-owner@makelist.com To subscribe, send an empty message to notification-subscribe@makelist.com To unsubscribe, send a message to notification-unsubscribe@makelist.com Archived messages at: http://www.findmail.com/list/notification/ Description of Working Group: ----------------------------- This working group will define a protocol to enable distributed event notification tools to be broadly interoperable. Event notifications are useful in many domains, including Web authoring, instant messaging, buddy lists, workflow, and Internet printing. While efforts are well underway to develop a standard protocol for instant messaging and personal presence, requirements for notification services in other domains suggest the need for development of an interoperable protocol for the registration, initiation, and transport of Internet event notifications. This working group will strive to develop a better understanding among the different communities of interest, elicit scenarios of use for an event notification service, refine requirements for an event notification service, and enumerate the application domains that will benefit from an event notification service. Our goal is to specify a protocol for Internet-scale event notification services. In particular, there is a large class of applications that already detects event occurrences by monitoring Web resources: link maintenance, price quotes, package-tracking, and so on. It seems desirable now to allow any application that used to poll an event source to now subscribe to {Some Set of Methods} X {Some Collection of Resources} and be notified immediately whenever information of interest is generated. For example, when used with the WebDAV extensions, notifications can communicate resource deletions, link modifications, and property changes. A cleanly designed interface permits the layering of advanced capabilities such as intermediated (relayed) delivery, notification management, and event-coalescing functions such as aggregating and filtering. Requirements for event notifications encompass the following capabilities, which will be considered by this working group: In Scope: --------- * Various notification delivery latencies * Source- and sink-initiated notifications * End-to-end and intermediated notifications * Delivery constraints: guarantees, transport choices, retry policies for disconnected clients and servers * Notification management: subscription and unsubscription to resources, event coalescing, asynchronous callbacks, queue management, per-notification security, access control including role-based access, group membership operations It is the intent of this working group to avoid the inclusion of the following functionality, unless it proves impossible to create a useful set of event notification capabilities without it: Out Of Scope: ------------- * Creation of new authentication schemes * Description of message transformation functions * Definition of schema-specific notifications Deliverables: ------------- The final output of this working group is expected to be three documents: 1. A scenarios document, which gives a series of short descriptions of how event notification functionality can be used, typically from an end-user perspective. An example strawman is R. Khare and A. Rifkin, "Scenarios for an Internet-Scale Event Notification Service," available at http://www.ics.uci.edu/~rohit/notify/draft-khare-notify-scenarios-01.txt 2. A requirements document, which describes the high-level functional requirements for event notifications, including rationale. An example strawman is S. Reddy, "Requirements for Event Notification Protocol," available at http://www.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt 3. A protocol specification (which for example describes new HTTP methods, headers, request bodies, and response bodies, to implement the event notification requirements). An example strawman is J. Cohen and S. Aggarwal, "General Event Notification Architecture (GENA) Base," available at http://www.ietf.org/internet-drafts/draft-cohen-gena-p-base-01.txt Goals and Milestones: --------------------- Sep 98 - (Scenarios) Revise scenarios document. Submit as Internet Draft. Sep 98 - (Requirements) Revise requirements document. Submit as Internet Draft. Nov 98 - (Specification) Create ISENS protocol specification. Submit as Internet Draft. Dec 98 - (Meeting, Scenarios, Requirements, Specification) Meet at the Orlando IETF and hold working group meeting to review the scenarios, requirements, and protocol specification documents. Mar 99 - (Meeting, Scenarios, Requirements, Specification) Meet at the IETF and hold working group meeting to review revised scenarios, requirements, and protocol specification documents. Apr 99 - (Scenarios) Create final scenarios document. Submit as Informational RFC. Apr 99 - (Requirements) Create final version of ISENS requirements document. Submit as Informational RFC. Jul 99 - (Meeting, Specification) Meet at the Oslo IETF and hold working group meeting to review a revised protocol specification document. Nov 99 - (Meeting, Specification) Meet at the Washington DC IETF and hold working group meeting to review a revised protocol specification document. Dec 99 - (Specification) Complete revisions to ISENS protocol specification. Submit as RFC.