It is NOT yet in the Internet-Drafts diirectory. This version will be
submitted on August 23 when the I-D desk reopens; and a revised -02 will be
submitted soon after, based on comments from Chicago and this mailing list.
This draft and the NOTIFY bof agenda are available from:
http://www.ics.uci.edu/~rohit/notify
... but don't bookmark that yet, since we will set up a /pub/ietf/notify tree
soon.
Rohit Khare
(Adam Rifkin)
-----
NOTIFY BOF Rohit Khare, UC Irvine
INTERNET-DRAFT Adam Rifkin, Caltech
<draft-khare-notify-scenarios-01.txt>
Expires February 1999 August 13, 1998
Scenarios for an Internet-Scale Event Notification Service (ISENS)
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to
the notifications mailing list at
<notification@makelist.com>. Discussions of the working group are
archived at <http://www.findmail.com/list/notification/>.
Abstract
This document's goal is to organize the discussion of a potential
"Internet Scale Event Notification Service" (ISENS) working group effort
by defining a model of Event Notification Service (ENS), identifying
a taxonomy of design choices and their tradeoffs, sketching some usage
scenarios, and briefly evaluating a host of candidate solutions.
1. Recent History
1998 has seen a flurry of activity under the umbrella of "event
notifications":
* In March 1998, the Presence Information Protocol (PIPR) BOF in Los
Angeles, CA discussed requirements for Internet notifications of
individuals' online status [Calsyn and Dusseault, 1998; Day, 1998a].
* Also in March 1998, a draft of an Internet Printing Protocol (IPP)
notification requirements was issued [deBry, 1998].
* In May 1998, a Web-based Workflow workshop met in Costa Mesa, CA to
discuss using notifications for initiating, controlling and monitoring
work processes. This led to the development of the Simple Workflow
Access Protocol (SWAP) [Swenson, 1998].
* July 1998 saw the last call for the Session Invitation Protocol (SIP),
which uses notifications for distributing invitation information
[Handley, Schulzrinne, Schooler, and Rosenberg, 1998].
* Based on this interest, UC Irvine convened a Workshop on
Internet-Scale Event Notification (WISEN) in July 1998. WISEN gathered
people working on notification services and protocols, to discuss
requirements and scenarios.
Several new ENS protocols have been proposed, particularly (A) for event
distribution over HTTP; and (B) for events related to resources served
over HTTP. With this interest in mind, a NOTIFY birds-of-a-feather has
been scheduled for the Chicago IETF meeting. This draft represents the
authors' brief efforts to outline the area by proposing some common
definitions, scope, and scenarios.
2. Definitions
Perhaps unsurprisingly, a survey of over two hundred related papers and
systems failed to elicit a globally consistent definition of "event
notification services" [Rifkin and Khare, 1998].
Examples range from a simple network broadcast like Dynamic Host
Configuration Protocol (DHCP) address allocation [Droms, 1997] to
publish-and-subscribe information buses with complex internal
aggregation, filtering, and coalescing of notifications. A minimal
common ENS model manages the delivery of observed-event notifications
between a set of sources and sinks. We refer to this model to
distinguish (A) notification messaging and (B) notification management
mechanisms.
Once an event observation has been packaged into a bitstream, message
delivery can proceed using one of many existing Internet messaging
protocols: email, netnews, file transfer, chat, and so on. There is an
unaddressed mode, however: an application-layer analogue to datagrams.
Many candidiate solutions propose an "instant message" for one-way
(reliable) delivery. Email comes up short because it is not typically
implemented end-to-end; intermediate relays add latency. HTTP comes up
short because it requires client-initiation. While earlier generations
of "telemetry"-style event notifications used custom data streams,
current interests focus on intermittent events, demanding a
"connectionless" delivery scheme. Furthermore, mission-specific
notification framing (*) does not benefit from a common marshalling
format, typing scheme, or security model.
(*) "Framing" -- as in Application Level Framing (ALF) -- is the process
of distilling an application data unit (ADU) into a protocol data unit
(PDU) [Clark and Tennenhouse, 1990].
Where messaging systems merely take an enumerated list of destinations
and fire away, an ENS actively manages distribution. To route event
notifications between sources and sinks, ENS developers have used a
range of mechanisms to establish interest: mailing list subscriptions,
news group creation, multicast address allocation, content-based routing
and filtering, and chat spanning tree construction. Subscription
management can require much more maintaining a list of listeners at the
source, or a list of speakers at the sink; there are also intermediate
constructs such as topical or pattern-of-interest filters .
For the record, the General Event Notification Architecture (GENA) Base
[Aggarwal and Cohen, 1998], defines event notification as "a message
sent by a subscribed resource to its subscribers, implied and otherwise,
notifying them of an event on that resource." The WebDAV-based Event
Notification Protocol (ENP) [Reddy and Fisher, 1998] defines event
notifications as messages sent "when a resource property value changes
or event state changes." Both of these documents describe particular
solutions for event notification services such as subscriptions and
datagram messaging, which intertwine messaging and management
facilities. In particular, they do not explicitly include abstractions
such as message queues and routers that could separate those functions.
3. Scope
In this section, we present a taxonomy of ENS design decisions that
suggest the space of possible solutions. A particular ENS protocol will
(A) offer minimum and maximum latency bounds, on observation and
delivery; (B) offer end-to-end or intermediated delivery; (C) allow
source- or sink-initiated delivery; and (D) optionally enforce selected
delivery constraints. These terms allow us to refactor popular, if
vague, labels in the ENS debate such as push and pull, poll and
interrupt, synchronous and asynchronous, and real-time and virtual
synchrony. Furthermore, (E) notification management raises its own
issues, of access control, privacy, enumerability, and verification. The
scenarios in Section 4.1 will illustrate these design choices.
[Note that we do not claim all of these combinations are in scope;
rather, these should inform decisions about modes and ranges.]
3.1 Latency
The frequency of event occurrence is perhaps the primary constraint on
an application's choice of ENS. Designers need to characterize the
sampling latency bounding the delay from occurrence until observation;
this "observation interval" determines the minimum resolution of event
frequency. Furthermore, designers need to characterize the delivery
latency from observation until notification; this "delivery interval"
determines the maximum resolution of event frequency.
These parameters must be aligned between the service and the
requirements of the application. Both are typically the same order of
magnitude: it makes as little sense to simulate a dogfight over email as
to deliver the daily comic strip with a flood of instant messages.
At one end of the spectrum, Simple Network Management Protocol (SNMP)
trap messages provide immediate sampling and low latency delivery of
infrequent alarms [Case, Fedor, Schoffstall, and Davin, 1990]. At the
other end, Network News Transfer Protocol (NNTP) postings could take
hours to be uploaded to upstream servers and days to propagate across
the entire Internet [Kantor and Lapsley, 1986].
Comparing sampling latency to the frequency of event occurrence
determines how many events might be reported per notification message.
Sampling latency interacts closely with who initiates communication, the
notification source or sink (see Section 3.3). For sink-initiated
transfers, this appears as a "poll-interval," but source-initiated
transfers may also limit the notification rate. For example, rather than
sending a TCP segment for each keystroke in an interactive session, the
Nagle algorithm waits up to one network round-trip time for additional
keystrokes to reduce congestion [Nagle, 1984].
Achieving low sampling latencies -- less than delivery latency -- can
require source-initiation. Low event frequencies also rule out
sink-initiation as inefficient. Buffering can easily increase sampling
latency in either case, though, by reporting more events per
notification. Source-initiated mailing lists, for example, offer
"digest" modes that batch daily or weekly traffic. Conversely, event
logs can store notifications for sinks to poll later.
Delivery latency governs how long a notification might remain "in
transit." It could be explicitly specified in a message (an Expiry:
header), implicitly specified by an event distributor's configuration
(an email delivery status notification timeout), or entirely dependent
on system and network load as with Internet Relay Chat (IRC) [Oikarinen
and Reed, 1993]. Network transport performance puts a lower bound on
delivery latency -- a single IP packet can take up to 255 seconds or
hops to deliver, but more typically on the order of a second. Low
delivery latencies generally restrict designers to end-to-end
distribution rather than store-and-forward ENS (see Section 3.2).
Latency is not the only source of delay in event observation and
notification. Bandwidth definitely affects those rates, but remains
secondary at global scale and especially in the Internet for small
messages. Subscription management is another bottleneck, governing the
setup and teardown delays for expressing interest in event occurrences.
3.2 Intermediation
Event notifications can be exchanged directly between sources and sinks,
or through an intermediate relay (aka depot, router, queue, bus, or
broker). Whether or not to allow intermediation affects latency (see
Section 3.1), but does not determine it: IRC is still low-latency
compared with the mail or news network for conferencing. Intermediation
becomes essential for efficiency at very large scale.
Tracking all the sources and sinks in the network is the fundamental
job of an ENS. Lists of interested parties must be maintained at either
endpoint or an intermediary. In the former cases, either the source or
sink can clearly initiate "end-to-end" delivery (see Section 3.3); in
the latter case, we have "store-and-forward" delivery.
In essence, an intermediary maintains a rendezvous point. Sometimes it
takes the form of a group address, like a newsgroup identifier; in
others it is simply a layer of indirection. AOL Instant Messenger's
centralized Internet-wide presence database is an example of the latter;
WhoDP's federation of Switchboards (which point, in turn to actual
user's responders) is a more flexible example of the same [Mohr, 1998].
A "group address," incidentally, is not always a semantic or topical
index. The medium or distribution hierarchy may offer other kinds of
groups, such as "all receivers within radio range," "within three hops
on the multicast tree," or a "geographic" scope, as in NNTP.
However, developers should be very careful using transport as a group
address, as in the first two cases listed above. First, there is the
question of whether these group addresses will scale. Further, there is
a good chance that the hard problems of distribution get pushed to
another layer at which the developer may have no fine-grained control.
3.3 Initiation
One of the greatest sources of confusion in selecting an ENS is which
end initiates notification delivery. Either the source interrupts or the
sink polls -- but these terms are conflated with "push" (often
implemented by polling), "asynchronous" (assuming an interrupt can be
sent at any time), and "real time" (assuming that an interrupt is sent
with low sampling latency).
There is also a question of which party has enough information to
enumerate its counterparties. If an event source knows its listeners, it
can initiate delivery upon event observation (for example, an instant
message on print job completion); conversely, if an unknown set of
parties want to monitor a single resource, a client-polling policy may
be more appropriate (for example, listing a printer job queue).
Initiation is also conflated with connection establishment; in fact,
some protocols can open a TCP connection and then swap roles (for
example, the Simple Mail Transfer Protocol (SMTP) TURN command [Postel,
1982]). Some systems use depots to bridge both initiation modes within
a single application. For example, email notification typically proceeds
in two phases, SMTP delivery to a mailbox with POP/IMAP polling from
there to the client.
Interrupt-driven delivery is also often assumed not to require
acknowledgment, or that correspondingly, transports that do not require
acknowledgement can only be used for source-initiation. In fact, Domain
Name System (DNS) requests regular naming updates over UDP [Mockapetris,
1987], and one-way Zephyr messagegrams are sent over TCP [DellaFera et
al., 1988]. Multicast, however, does not permit acknowledgement
scalably, and is thus only suited for source-initiated announcements.
As mentioned in Section 3.1, the polling interval establishes sampling
latency, but ENS definitions vary whether to use a poll-interval as an
upper or lower bound (the minimum or maximum delay between polls,
respectively).
An efficient initiation decision depends on the relative number of
sources and sinks (the distribution topology of Section 3.2). Namely,
the smaller set should initiate. If one or both sets are arbitrarily
large, however, initiation selection depends whether there is a
simplifying assumption at hand. To post to N newsreaders, there exist
smaller, enumerable sets of news servers in the network, or perhaps a
single multicast channel -- so source-initiation remains viable. For N
people to become aware of one's presence, though, protocols like finger
[Zimmerman, 1991] must be sink-initiated since there are no blackboards
at which to rendezvous in that case (Section 3.2).
3.4 Delivery Constraints
Delivery constraints center around the question "Upon receiving (or
not receiving) a notficiation, what steps can/must the ENS take before
passing it up to the application?" The ENS is responsible for ensuring
certain guarantees before delivering a notification to the handler
above; for example, this affects the blocking or nonblocking behaviors
of the protocol when processing requests and replies.
The ENS itself can support a range of guarantees. At one end of the
spectrum, real time simulation protocols actively replace "missing"
notices with predicted dead-reckoned position updates; at the other end
of the spectrum, an ENS could offer no retry policy whatsoever for lost
notification messages. These options are further complicated by
scenarios with nomadic or intermittently-connected clients.
Intermediation and topology (see Section 3.2) can be consequences of the
choices for delivery constraints. Issues such as event notification
subscriptions -- for example, who actually maintains the subscription
lists -- should also be considered; with first-class connectors and
subscription-maintainers as components, the system is more resilient.
Over the Internet, the channels themselves are nonblocking (modulo the
practicalities of buffer size), so the protocol should only withhold
delivery to ensure transactional commit on exactly-once delivery;
reliable handoff (to stable storage); ordered delivery (blocking until
missing sequence numbers received); or reception of entire streaming
contents.
If a packet is lost (for example, after a timer expires), an ENS can
ignore the loss; substitute a speculative estimate (as is done with
distributed interactive simulations), or revert to a known state (as
WhoDP does).
In addition, we may also want to enforce security guarantees, such as
verifications that a notification is legitimate, ciphered and signed by
the right principal, and/or from a legitimate relay machine. We discuss
these issues further in Section 6.
In many ENS designs, several gremlins are swept under the "transport"
rug. Common traps include confusing transport with latency ("we can use
UDP for efficiency without worrying about reliability") and using
transport to do group membership ("multicast will by its very nature get
us an efficient, reliable broadcast to a sparse group"). Trying to
implement reliability atop UDP, one often reinvents TCP; multicast only
makes sense on a shared physical medium such as a dedicated local area
or wide area network. Retry policies should be based on a combination
of latency choice and transport choice.
We believe transport decisions should not alter the underlying semantics
of a system's behaviors -- that it is risky to define hastily an "HTTP
over UDP," say, without considering what it means to have responseless
HTTP semantics.
3.5 Notification Management
At some point, an ENS has to manage an actual set of source and sink
addresses. While previous generations used homogeneous lists of
mailboxes or logins or network addresses or process IDs, almost all
current proposals recommend using Uniform Resource Identifier (URI)
syntax [Berners-Lee, Fielding, and Masinter, 1998] for those entries,
allowing a range of different notification delivery mechanisms to be
used within a single ENS.
This decision carries the seeds of its own troubles, though. Allowing
"callbacks" by mail and news and direct connections and UDP is easy
enough within URI syntax, but these have distinctly different
characteristics in each of the four aspects discussed previously in this
Section. Application designers must be aware of these precise tradeoffs
in permitting each type of delivery -- a classic middleware challenge,
to be sure.
However, at Internet-scale, there are concerns other than those four
that affect a subscriber's choice of callback address. Accommodation can
be the best course, as one scenario in Section 4.1 indicates. Even a
real-time, reliable problem like stock trading should be available to
those with email-access alone, to reach the largest market.
Subscription and unsubscription are the two basic operations on this
set. The latency and granularity of these updates can also become an
issue for the ENS users, as with very short-lived subscriptions or very
high transaction volumes.
We recommend that the subscription list itself should be a "first-class"
object, editable and auditable remotely with proper authorization.
Systems that "store" this set as a side-effect of join/depart requests
raise manageability risks. There may also be a requirement for loopback
verification, that a particular address actually works and represents a
genuine request. It's a fact of life for Internet mailing lists [Neufeld
and Baer, 1998], and would seem to be for most of the scenarios proposed
for Web notifications as well.
Security, access control, group membership operations, and role-based
access to information are discussed further in Section 6.
4. Scenarios for Internet-Scale Event Notification
As cited in the call for a NOTIFY BOF, "Event notifications are useful
in many domains, including web authoring, instant messaging, buddy
lists, workflow, and Internet printing." Event-based integration is a
widely-applicable strategy to decouple distributed system components,
and as a result it motivates a wide range of event notification
services. In this section, we sketch the ENS design space within a
hypothetical scenario (a financial brokerage firm), then carve out the
areas with immediate developer interest, and finally make the case that
"Web Notifications" offer a focused strategy for a working group to
pursue.
4.1 Notification Services at Foonly Trading
[Note that these scenarios do NOT motivate a single, unified protocol;
they are merely intended to illustrate the concepts introduced in
Section 3.]
At Foonly Trading, brokers' workstations integrate data feeds from
around the world to inform trading decisions. They range in latency from
second-by-second stock tickers to annual reports; delivered directly and
with intermediate relay processing; pulled by clients or pushed by
analysts; and ranging from best-effort updates to guaranteed
transactions.
The stock ticker is one of the most basic information feeds: as each
trade clears on the Metropolis Stock Exchange (MSX), an event
notification is immediately assembled and sent out to member
organizations as quickly as possible.
Latency: observation = ~0 (triggered by trade execution);
delivery = IP packet (= 30-300 msec)
Initiator: source
Intermediation: none
Delivery Constraint: reliable connection
Foonly's website also offers a public stock ticker, but MSX rules
require a fifteen-minute delay for disclosure to nonmembers.
Latency: delivery = 15 minutes + HTTP connection
Initiator: Web server (for example, deliver to client applet)
Intermediation: Web server aggregates updates
Delivery Constraint: reliable connection
For their own clients, Foonly offers a personalized portfolio-tracker.
Foonly's ticker depot recalculates portfolio values every time one of
its constituent stocks changes trading price. The client must maintain a
subscription with current quantities of portfolio holdings to use this
feature.
Initiator: portfolio server
Intermediaton: portfolio server computes total value
Notificication Mgmt: client sub. request enumerates current holdings
There also exists a newswire, with articles indexed by industry,
company, and type of news. Traders and customers can subscribe to
newsgroups corresponding to these terms.
Initiator: customer's news client
Intermediation: news server offers articles under several groups
Notification Mgmt: news client stores groups, records last-seen
... or they can opt to have the day's news emailed to them in a single
digest delivered each evening.
Latency: observation = 1 day
delivery = minutes
Intiator: Foonly mail server
Intermediation: list robot gathers all relevant news
Notification Mgmt: list robot stores client's groups, last-seen
"Real-time" weather reports every minute from a bellwether Kansas farm
helps hone their estimates of grain futures prices.
Latency: observation = 1 minute (polling interval);
delivery = IP packet (= 30-300 msec)
Initiator: sink (Foonly brokers' server polls)
Intermediation: none
Delivery Constraint: unreliable datagrams
Foonly also wants to be sure to short all California stocks if the Big
One hits. Their network of seismometers is programmed to send a
satellite page to Metropolis as soon as a Richter 4+ event is detected.
Latency: observation = ~0 (immediate, if infrequent);
delivery = radio signal (fixed delay)
Initiator: source (autonomous seismometers)
Intermediation: none
Delivery Constraint: unreliable radio signal
Their competitors at BarNone think they can do better predicting an
earthquake rather than waiting for one.
Latency: observation = 50 msec (continuous telemetry);
delivery = radio signal (fixed delay)
Initiator: source (autonomous seismometers)
Intermediation: none
Delivery Constraint: unreliable radio signal
Aside from such routine feeds, brokers are also subscribed to their
client's trading orders. Suppose a customer emails in a stop-order,
which could take some time to execute. That customer may have to put up
with a few minutes delay, and then resubmit the order (because the
original got lost in a mail loop that would only be bounced back five
days later). Within that order is a "callback" address for Foonly to
reach them with the news of its execution.
That callback URI might be either A) mailto:, if the customer can bear a
few minutes' suspense; B) a return socket address, if the customer is
running a listener application; or C) a promise to query the Foonly
database every minute until the trade executes.
While each of these three options have very different guarantees on
observation and delivery latency, they are each plausible scenarios on
the public Internet and should be accomodated. A) is for a disconnected
or nomadic user with email access alone; B) is for a directly-connected
customer whose firewall (if any) permits connections; and C) is for a
client behind a firewall that only permits outgoing connections. (A
hybrid of B and C is to leave the connection open as long as possible
for Foonly to use the reverse path).
4.2 Imminent ENS Users
Web Distributed Authoring and Versioning (WebDAV) requires some way to
monitor the activities of collaborative authors [Goland, Whitehead,
Faizi, Carter, and Jensen, 1998]. At a whole-resource level, this
includes locked resource value update notifications (creating a
resource, changing a resource, deleting a resource, adding a collaborator,
removing a collaborator, updating a timeout expiry value) and property update
notifications, among user groups and cooperating servers at a wide range
of scales and latencies. Distributed authoring could also benefit from
sub-resource notifications, allowing editors to show the work of other
collaborators synchronously in real-time.
Distributed collaborating authors often use the telephone, or email,
or both for communication [Beck and Bellotti, 1993]. In many such
scenarios, Internet notifications augment other communications paths
by which human collaborators generate awareness of the actions of
their co-collaborators, as for example is done in the Basic Support
for Cooperative Work (BSCW) System [Bentley et al., 1997].
Internet Printing Protocol (IPP) also needs several capabilities: not
just device-initiated messaging, but also access control, filtering,
varying qualities of services, and the merging of event streams by
notification priority and grain [deBry, 1998]. There are different roles
for notifications that are human-readable and machine-readable, and
notification-queuing proxies can buffer and respond to multiple events.
The presence community could benefit from a notification protocol, even
if it is proceeding apace for now on its RendezVous Protocol (RVP)
[Calsyn, Dusseault, and Mohr, 1998]. RVP introduces a NOTIFY method for
responding to subscriptions and sending instant messages, and employs a
"Reply-to:" header to permit communication upon receipt of notifications.
The workflow/process community could use notifications to track ongoing
out-of-the-box invocations [Swenson, 1998]. SWAP needs notifications
for starting, monitoring, controlling, and receiving from a remote
asynchronous service, for use in passing data and invoking methods
across applications.
The Lightweight Directory Access Protocol v3 (LDAP) search operation
could employ a simple mechanism by which an LDAP client receives
notification of changes that occur in an LDAP server [Smith, Good,
Howes, and Weltman, 1998]. The current approach provides clients and
servers participating in Persistent Search with an active channel
through which entries that change (and additional information about the
changes that occur) can be communicated.
More speculatively, Web-Based Enterprise Management (WBEM), an analogue
to SNMP built on an HTTP/XML device interface as part of the PC99
specification), could also benefit from using notifications for tracking
and trapping networked information [Web-Based Enterprise Management
Initiative, 1998].
4.3 "Web Notifications" as a Working Group Strategy
Having set the scene of the possible design space for ISENS, and
probable users of ISENS, we must extract a plausible intersection of the
two to move forward. We believe the most persuasive common interest is
both A) in notification delivery in the form of HTTP messages and B) for
events affecting HTTP resources.
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.
The HTTP resource model has proven so sufficiently flexible -- large
messages and small, immediate and deferred, for humans or machines --
that it seems likely that many current applications can be "ported" to
this ENS base. News distribution, presence, conferencing, distributed
simulations, and tool integration could all proceed to some degree over
an "instant page" infrastructure.
A cleanly designed HTTP interface should be able to layer on advanced
capabilities such as intermediated (relayed) delivery and
event-coalescing functions such as aggregating and filtering. And, as we
later describe in Section 5.1.3, notification management could also
proceed over an extensible HTTP interface.
5. Candidate Protocols
To provide ISENS, developers could opt for creating conventions for use
with an existing protocol such as SMTP, NTTP, or HTTP; or, we could
develop an application-layer protocol specially designed to accommodate
the event notification design space described in Section 3.
5.1 Existing ISENS
Developers are already combining Internet-scale messaging with specific
notification-management technologies to build custom solutions.
5.1.1 SMTP + List Addresses
Email has some useful properties for event-notification messages: its
infrastructure is already configured for "datagram" delivery without
prior arrangement. Its admistratively-scoped relay network allows
traffic consolidation for "nearby" receivers (those under the same MX
relay). There is even some queue management, and although it is only
visible to administrators, it does allow some prioritization and
management.
Mailing list manager software automates the creation of such aliases.
These steps include: accepting subscriptions; verifying addresses
(loopback confirmation and ongoing bounce monitoring); and
unsubscription. It may optionally archive messages, or buffer messages
into periodic digests for some recipients. Of course, mailing list
managers are differentiated mainly by engineering concerns: bursting
large lists into smaller batches, security and robustness of
implementation, and human-robot user interfaces.
Another useful property of the mail network is its staged delivery. On
the connected Internet, messages are delivered immediately (that is,
server-initiated) to a mailbox, and then retrieved by the end-user
deferred (that is, client-initiated). News shares this property.
5.1.2 NNTP + Newsgroups
News has some useful properties for reaching very large groups: messages
floodfill throughout the network of interconnected news servers, subject
only to expiry and "geographic" limits. However, it works poorly for
sparse groups, since a copy reaches the whole public Internet, and for
low-latency groups, since the eventual delivery time is even more random
than email.
Newsgroup creation is a matter of administrative cooperation, too. Sites
must "subscribe" to the appropriate feed before any local users can. In
practice, this is tuned for very low-frequency group creation and
deletion.
One handy consequence, though, is cross-posting. Each article has one
identifier that can be cited from many group lists usings the
"Newsgroups:" header.
5.1.3 HTTP + Callbacks
On the surface, HTTP/1.1 [Fielding et al., 1997] seems an unlikely ENS.
It seems exclusively adapted to low-latency, sink-initiated, end-to-end,
reliable delivery on a one-to-one basis. There are two relevant features
that widen its range, however. First, its syntax already affords
relaying a request and response along a chain of proxy servers (and to
short-circuit it using a cached response). Second, it is possible (and
practical) to have both an HTTP client and server at any node on the
Internet.
At each step in the resolution of an HTTP resource, a request can be
directed to the origin server, or to a proxy for that resource [Khare
and Rifkin, 1998]. As currently defined, though, HTTP's semantics are
serialized and end-to-end (synchronous); even caching is merely an
approximation of reaching the origin server. An HTTP ENS would make it
possible to snip this constraint, allowing a client to make a request of
a resource at one server, and be notified of its reply from another a
day later.
As defined, HTTP/1.1 proxying already allows intermediation. Proxies can
aggregate and filter event streams. Caching properties like ETags and
expiry times can be used judiciously to "cross-post" event notices under
several topic addresses, and to keep recent notifications available for
subsequent sink requestors. Wide-area notifications might be
prepositioned by NNTP-like delivery to a network of Web proxies.
An HTTP server, upon observing an event, can also take advantage of HTTP
to deliver a notification to a list of listeners. By implementing HTTP
servers at "client" nodes, the event source can initate delivery as an
HTTP request (firewall permitting); that is the approach behind GENA's
NOTIFY method [Aggarwal and Cohen, 1998]. However, rather than cloak a
response within an HTTP request, it would be cleaner to initiate
delivery of an HTTP response message, but that would require a
reinterpretation of HTTP/1.1's flowchart.
In any case, it makes some sense to use HTTP-formatted messages for
communication in both directions. Other protocols cannot be so easily
implemented in both roles. E-mail, for example, really argues against
routing to a "Mail Transfer Agent (MTA) on every desk" and for a handful
of mail servers instead. Bidirectional HTTP traffic may also be the most
principled approach to firewall traversal, too.
Furthermore, a human- and machine-readable notification management
interface can be published over HTTP. Distribution lists can be
represented as HTTP resources, with subscription operations as HTTP
methods. Event types and channels can be advertised (and indexed) as
HTTP resources. Access controls on all of the above can be implemented
with existing HTTP headers.
Note: Some have proposed an unreliable transport for HTTP; see our
caveats for unreliable transport in Section 3.4. For some idempotent
requests leading to a 204 No Content reply, it might make sense to
define a responseless form of operation -- or to fill a cache, say, with
spontaneous (requestless) 200 responses. In those cases, we could
further define a UDP transport -- for sufficiently small messages whose
losses would be acceptable (in applications for which these losses do
not alter the runtime semantics).
5.2 New ISENS Candidates
Several new protocols offering event notification services have emerged
recently, many of them loosely or strictly based on HTTP (including some
based on WebDAV extensions).
5.2.1 BLIP
Basic Lightweight Information Protocol (BLIP) was designed to provide
application-level message services based on the publish-and-subscribe
model [Jensen, 1998]. MIME message notifications are delivered in
real-time streams, and application-level transaction services are
available. This protocol is not based on HTTP.
5.2.2 SGAP
Simple General Awareness Protocol (SGAP) provides notifications of
changes that users, groups, or resources of interest are available [Day,
1998b]. These changes are selectively exposed to a potentially large
pool of listeners, with relatively loose constraints on latency. This
protocol is not based on HTTP.
5.2.3 SIP
Session Invitation Protocol (SIP) is an application-layer control
protocol for creating, modifying, and terminating sessions with one or
more participants [Handley, Schulzrinne, Schooler, and Rosenberg, 1998].
Designed to be independent of the lower-layer transport protocol, SIP
allows the distribution of messages using multicast, a mesh of unicast
relations, or a combination of these. Loosely based on HTTP, SIP
supports user mobility by proxying and redirecting requests to the
user's current location.
5.2.4 RVP
RendezVous Protocol (RVP) was designed to accommodate notifications for
people subscribing to other peoples' status [Calsyn, Dusseault, and
Mohr, 1998]. MIME is used to specify the notification message format,
and RVP uses XML for ACLs and detailed kinds of notifications on an
object. RVP is loosely based on HTTP including some WebDAV extensions.
5.2.5 ENP
Event Notification Protocol provides a service that allows users to
register interest in resources or events for later notifications of
property and state value changes [Reddy and Fisher, 1998]. ENP is based
on the WebDAV extensions for HTTP, making no additional method
extensions and using a few request and response extension headers
specifically for notifications.
5.2.6 SWAP
Simple Workflow Access Protocol (SWAP) uses HTTP to transfer structured
work control and monitoring information [Swenson, 1998]. In providing a
notification service, rather than use existing HTTP methods, SWAP
overloads (slightly) the semantics of the WebDAV PROPFIND and PROPPATCH
methods. Although encoded in XML, the notification messages transferred
by SWAP are not intended for human consumption.
5.2.7 GENA Base
General Event Notification Architecture (GENA) Base specifies HTTP
extensions that allow the transmission of notifications between HTTP
resources [Aggarwal and Cohen, 1998]; these extensions are independent
of the WebDAV extensions. Notifications can be pushed or pulled, and a
resource can establish a subscription relationship with any other
resource to receive notifications of specific events. GENA Base has
hooks for intermediation, server or client initiation, and some delivery
constraints, but there is no support for explicit notification
management as described in Section 3.5.
6. Security Considerations
Access control lists alone cannot address the spectrum of security
concerns in ISENS. In addition to the "usual" trust management concerns
of messaging applications (authenticating counterparties, integrity, and
confidentiality) and subscription maintenance (subscriber verification
and access controls), some event-oriented applications raise unique
*privacy* concerns that any supporting protocol must accommodate.
As SGAP illustrates, the events to be distributed depend as much on the
recipient as the sender: your boss may know you are in, but your
colleagues may not [Day, 1998b]. From experience with mailing lists,
even the contents of the distribution list itself can be sensitive
information. Also, there exists a "birthday party notification problem"
of how to send a notification to a preset list excluding a subset of the
members on a one-time basis.
At an engineering level, firewall traversal is the most signficant
hurdle for this effort; persistent connections and client-initiated
connections can facilitate event-notification with the current state of
firewall deployment. However, session-oriented security checks must
adequately address the performance tradeoffs based on the number of
channels and the number of principals. Furthermore, the revocation
timing model also needs to be addressed.
7. References
Sonu Aggarwal and Josh Cohen, "General Event Notification Architecture
Base," Internet Draft (Work in Progress), July 1998, available at
http://www.ietf.org/internet-drafts/draft-cohen-gena-p-base-01.txt
Eevuk E. Beck and Victoria M. E. Bellotti, "Informed Opportunism as
Strategy: Supporting Collaboration in Distributed Collaborative Writing,"
European Computer-Supported Cooperative Work, 1993
R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J.
Trevor, and G. Woetzel, "Basic Support for Cooperative Work on the World
Wide Web," International Journal of Human-Computer Studies, Special
Issue on Innovative Applications of the World Wide Web, Volume 46,
Number 6, Pages 827-846, June 1997, available at
http://bscw.gmd.de/Papers/IJHCS/IJHCS.html
Tim Berners-Lee, Roy Fielding, and Larry Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax," Internet Draft (Work in Progress),
June 1998, available at
http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-04.txt
Martin Calsyn and Lisa Dusseault, "Presence Information Protocol
Requirements," Internet Draft (Work in Progress), March 1998, available
at http://www.ietf.org/internet-drafts/draft-dusseault-pipr-00.txt
Martin Calsyn, Lisa Dusseault, and Gordon Mohr, "RVP: A Presence
Notification Protocol," Internet Draft (Work in Progress), March 1998,
available at http://www.ietf.org/internet-drafts/draft-calsyn-rvp-01.txt
Jeffrey D. Case, Mark Fedor. Martin Lee Schoffstall, and James R. Davin,
"A Simple Network Management Protocol (SNMP)", RFC 1157, May 1990,
available at ftp://ftp.isi.edu/in-notes/rfc1157.txt
David D. Clark and David L. Tennenhouse, "Architectural Considerations
for a New Generation of Protocols," in Proceedings of the SIGCOMM '90
Symposium on Communications Architectures and Protocols, Philadelphia,
PA, Computer Communications Review, Volume 20, Number 4, Pages 200-208,
September 1990
David H. Crocker, "Standard for the Format of ARPA Internet Text
Messages," RFC 822, August 1982, available at
ftp://ftp.isi.edu/in-notes/rfc822.txt
Mark Day, "Requirements for Presence and Instant Messaging," Internet Draft
(Work in Progress), March 1998 (1998a), available at
http://www.ietf.org/internet-drafts/draft-day-rpim-00.txt
Mark Day, "Simple General Awareness Protocol (SGAP)," Internet Draft (Work
in Progress), March 1998 (1998b), available at
http://www.ietf.org/internet-drafts/draft-day-sgap-01.txt
Mark Day, John F. Patterson, and David Mitchell. "The Notification Service
Transfer Protocol," Computer Networks and ISDN Systems, Volume 29, Pages
905-915, 1997.
Roger K. deBry, "Requirements for IPP Notifications," Internet Draft (Work
in Progress), March 1998, available at
http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-01.txt
C.A. DellaFera, M.W. Eichin, R.S. French, D.C. Jedlinsky, J.T. Kohl, and
W.E. Somerfeld. "Zephyr Notification Service," USENIX Conference
Proceedings, Dallas, Texas, Winter 1988
Ralph Droms, "Dynamic Host Configuration Protocol (DHCP)," RFC 2131,
March 1997, available at ftp://ftp.isi.edu/in-notes/rfc2131.txt
Roy T. Fielding, Jim Gettys, Jeff Mogul, Henrik Frystyk, and Tim
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068, January
1997, available at ftp://ftp.isi.edu/in-notes/rfc2068.txt
Roy T. Fielding, E. James Whitehead, Jr., Kenneth M. Anderson, Gregory A.
Bolcer, Peyman Oreizy, and Richard N. Taylor, "Web-Based Development of
Complex Information Products," Communications of the ACM, Volume 41, Number
8, August 1998
Yaron Y. Goland, E. Jim Whitehead Jr., A. Faizi, S.R. Carter, and D. Jensen,
"Extensions for Distributed Authoring on the World Wide Web -- WEBDAV,"
Internet Draft (Work in Progress), April 1998, available at
http://www.ietf.org/internet-drafts/draft-ietf-webdav-protocol-08.txt
Mark Handley, Henning Schulzrinne, Eve Schooler, and Jonathan Rosenberg,
"SIP: Session Invitation Protocol," Internet Draft (Work in Progress),
July 1998, available at
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-07.txt
Matt Jensen, "Basic Lightweight Information Protocol (BLIP)," Draft 0.005,
July 1998, available at http://www.blip.org/protocol.htm
Brian Kantor and Phil Lapsley, "Network News Transfer Protocol," RFC 977,
February 1986, available at ftp://ftp.isi.edu/in-notes/rfc977.txt
Rohit Khare and Adam Rifkin, "Composing Active Proxies to Extend the
Web," OMG-DARPA-MCC Workshop on Compositional Software Architectures,
Monterey, CA, January 1998, available at
http://www.cs.caltech.edu/~adam/papers/csa98b.html
P. Mockapetris, "Domain Names - Implementation and Specification," RFC
1035, November 1987, available at ftp://ftp.isi.edu/in-notes/rfc1035.txt
Gordon Mohr, "WhoDP: Widely Hosted Object Data Protocol," Internet Draft
(Work in Progress), March 1998, available at
http://www.ietf.org/internet-drafts/draft-mohr-whodp-00.txt
John Nagle, "Congestion Control in IP/TCP Internetworks," RFC 896,
January 1984, available at ftp://ftp.isi.edu/in-notes/rfc896.txt
Grant Neufeld and Joshua Baer, "The Use of URLs as Meta-Syntax for Core
Mail List Commands and their Transport through Message Header Fields,"
RFC 2369, July 1998, available at ftp://ftp.isi.edu/in-notes/rfc2369.txt
Jarkko Oikarinen and Darren Reed, "Internet Relay Chat (IRC) Protocol,"
RFC 1459, May 1993, available at ftp://ftp.isi.edu/in-notes/rfc1459.txt
Jonathan B. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982,
available at ftp://ftp.isi.edu/in-notes/rfc821.txt
Surendra Reddy, "Requirements for Event Notification Protocol," Internet
Draft (Work in Progress), April 1998, available at
http://www.ietf.org/internet-drafts/draft-skreddy-enpreq-00.txt
Surendra Reddy and Mark L. Fisher, "Event Notification Protocol," Internet
Draft (Work in Progress), June 1998, available at
http://www.ietf.org/internet-drafts/draft-reddy-enp-protocol-00.txt
Adam Rifkin and Rohit Khare, "A Bibliography of Event Papers," August 1998,
available at http://www.cs.caltech.edu/~adam/isen/event-papers.html
Mark Smith, Gordon Good, Tim Howes, and Rob Weltman, "Persistent Search: A
Simple LDAP Change Notification Mechanism," Internet Draft (Work in
Progress), August 1998, available at
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-psearch-01.txt
Keith Swenson, "Simple Workflow Access Protocol (SWAP)," Internet Draft
(Work in Progress), August 1998, vailable at
http://www.ietf.org/internet-drafts/draft-swenson-swap-prot-00.txt
Web-Based Enterprise Management Initiative, "Web-Based Enterprise Management
(WBEM)," 1998, available at http://wbem.freerange.com/wbem/standards.htm
David Paul Zimmerman, "The Finger User Information Protocol," RFC 1288,
December 1991, available at ftp://ftp.isi.edu/in-notes/rfc1288.txt
8. Authors' Addresses
Rohit Khare
UC Irvine
Department of Information and Computer Science
ICS2-247
Irvine, CA 92697-3425
Email: rohit@uci.edu
Adam Rifkin
Computer Science 256-80
California Institute of Technology
Pasadena, CA 91125
Email: adam@cs.caltech.edu
The authors would like to acknowledge the entire WISEN community for
their informative feedback to our original talk (available at
<http://www.cs.caltech.edu/~adam/isen/> ). We would particularly like
to thank our colleagues Sonu Aggarwal, Greg Bolcer, Josh Cohen, Lisa
Dusseault, and Roy Fielding. Last, but not least, we would like to
thank Jim Whitehead for his editorial input and leadership of the BOF
meeting in Chicago.
9. Appendix: Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--Rohit Khare -- UC Irvine -- 4K Associates -- +1-(626) 806-7574 http://www.ics.uci.edu/~rohit -- http://xent.ics.uci.edu/~FoRK