Event Notification Services (PAGER) Working Group
-------------------------------------------------
Charter revision level 0.1, 25 August 1998
Status:
-------
Speculative strawman proposal. Mailing list not created yet.
Chair(s):
---------
Rohit Khare <rohit@uci.edu>
(?)
Applications Area Directors:
------------------------------
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
--------------------------
Patrik Faltstrom <paf@swip.net> (?)
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.