Event Notification Services (PAGER) Working Group ------------------------------------------------- Charter revision level 0.1, 25 August 1998 Status: ------- Speculative strawman proposal. Mailing list not created yet. Contact rohit@uci.edu Chair(s): --------- Rohit Khare (?) Applications Area Directors: ------------------------------ Keith Moore Patrik Faltstrom Applications Area Advisor: -------------------------- Patrik Faltstrom (?) Mailing List: ------------- General Discussion: ietf-pager@ics.uci.edu List Management: ietf-pager-request@ics.uci.edu Subscribe: Send message with subject "subscribe" Unsubscribe: Send message with subject "unsubscribe" Archived Messages: http://www.ics.uci.edu/pub/ietf/pager Description of Working Group: ----------------------------- A wide range of distributed applications, especially groupware, need a mechanism to express interest in events affecting an Internet resource and be notified upon their occurrence. A long list of existing solutions could surely be adapted to such use -- even "fast" email -- but PAGER posits that there is merit in a common infrastructure for an entire generation of Web-based applications: "instant pages," initiated by HTTP servers, per subscription to application-specific event queues. WebDAV and IPP are two immediate drivers for this effort: their users need event notifications generated by Web resources representing collaborative authoring and printing processes, respectively. Those alone, however, do not do justice to the range of applications PAGER might be called upon for. Distilling experience from hundreds of existing event-oriented systems [WISEN-SURVEY], the PAGER system should afford notification observation and delivery latencies ranging from milliseconds to weeks; event sources (interrupt-driven) and sinks (polling) to initiate notification; end-to-end delivery and via proxy relays; and permit application-specific delivery constraints (e.g. ordering, guaranteed delivery) as extensions. PAGER will achieve these goals with a three-layered solution. Event-based applications build on a particular event schema, a notification management interface, and a set of notification delivery mechanisms. In particular, PAGER will define a way for Web-based applications to (1) distribute "instant pages" to (2) subscribers of an event queue (3) that represent application-specific event notifications. (1) PAGER will adapt HTTP/1.1 for "push" delivery. An HTTP server should be able to defer response by initiating a connection back to the client later; or, by implementing an HTTP server interface at the client, invoke callback methods in return. In particular, a transaction-ID mechanism would afford out-of-order responses within an HTTP session; and UDP delivery of individual messages. (2) PAGER will define an "event queue" as a specialized HTTP resource (also known as a message bus or event channel). It will manage notification distribution with subscribe, unsubscribe, and enumeration operations. It controls latency, initiation, intermediation, and delivery constraints. Appropriate security and access controls will apply. (3) PAGER will address key event-based applications, defining DAV and IPP "event sources" as initial targets. Note that these are only "shakedown applications" -- future development of application-specific event semantics will be remanded to separate working groups. The intended result is that applications which integrate Web-based information sources today by polling alone will have new, easy-to-deploy, and manageable notification mechanisms to choose from instead. Out Of Scope: ------------- 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: * General Event-description languages or formats * General Event filtering/aggregation/transformation functions * New HTTP Authentication and Confidentiality mechanisms * Differential content update formats Deliverables: ------------- This Working Group will track its progress through five documents. The first two will lead to Informational RFCs; the latter three will be standards-track RFCs. (1) Scenarios. Outlines the history of the field, the design space, and an end-user perspective on different kinds of notifications. (2) Requirements. Represents WG consensus on what kinds of notifications, queuing, and delivery properties a PAGER solution must have. Also defines one or two "testbed" application areas PAGER will initially address. (3) HTTP Notification Delivery. Describes how to defer HTTP responses and allow "server"-initiated requests. Describes how to deliver HTTP messages over UDP and to multicast groups. (4) HTTP Event Queue Resource. Describes an HTTP resource that binds together a set of event sources and sinks, as well as the operations upon it (subscribe/unsubscribe/delegate) and access controls. An Event Queue resource also determines observation and delivery latency, which end initiates delivery, whether delivery is end-to-end or held at an intermediate proxy, and may have hooks to ensure other delivery constraints. The document discusses how these properties constrain the range of acceptable callback URI schemes. (5) HTTP Events. Describes a syntax and semantics for events an HTTP resource or collection might generate and patterns to express interest in selected event notifications. Must also suffice to describe events generated by WebDAV and IPP resources. Goals and Milestones: --------------------- Sep 98 - Update Scenarios document presented at the Chicago BOF and frame a new requirements document. Nov 98 - Document PAGER design decisions or choices for each of three components. Appoint an editorial team to synchronize and track subprojects. Dec 98 - (Meeting, Scenarios, Requirements, Specifications) Meet at the Orlando IETF and hold working group meeting to review the scenarios and requirements; and introduce three protocol specification drafts. Jan 99 - (Scenarios, Requirements) Submit scenarios as Informational and revised requirements as Internet-Draft. Mar 99 - (Meeting, Requirements, Specifications) At IETF-44, finalize requirements document and evaluate consensus on specification strategy. Apr 99 - (Requirements) Submit requirements as Informational. Jul 99 - (Meeting, Specification) Meet at the Oslo IETF and hold working group meeting to review three (working) protocol specification documents. 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 PAGER protocol specification. Submit as Proposed Standard RFC.