INTERNET-DRAFT Rohit Khare, UC Irvine <draft-khare-notification-00.txt> Adam Rifkin, Caltech Expires May 1999 November 17, 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 obsoleted 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.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Please send comments to the notifications mailing list at <notification@makelist.com>, archived at http://www.findmail.com/list/notification/. Background information and proposed charter(s) are at http://www.ics.uci.edu/pub/ietf/notify/. 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, old and new. [NOTE: this edition is largely unchanged from an August 13th, 1998 draft presented at the Chicago NOTIFY BOF.] 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 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 was scheduled for the Chicago IETF meeting. At that meeting, there was broad interest in chartering some work in this area, but no detailed advocacy for a particular charter. Two strawmen were presented, a generic notification platform (NOTIFY) and a narrowly Web-oriented page delivery service (PAGER). At the same time, some called for event notification even more reliable than HTTP, with retries for nomadic computing support. This document also takes pains to defend the "control hypothesis": that existing Internet messaging (email, news) is sufficient for many notifications. On the other hand, Presence vendors and other groups have been progressing towards a common HTTP-based platform for that particular kind of notification. To the degree that such efforts are split into base + presence parts (as with, say, GENA and RVP), the horizontal service *will* be used for more diverse applications. This certainly bends the definition of HTTP, perhaps too far (see "On the use of HTTP as a Substrate for Other Protocols", <draft-iesg-using-http-00.txt>). A forum for HTTP developers' reviews and input would be useful, to filter potential security, bandwidth, and manageability challenges. In summary, there has been a lull since the Chicago meeting. The authors believe there is a problem worth solving in here, but perhaps not yet. 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 than 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]. However, multicast [Deering, 1989] does not permit acknowledgement scalably when it is required to be reliable, 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 Initiator: 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. We believe that Yet Another Web Notifications (YAWN) working group endeavor could prove fruitful in designing a protocol for "Web events." A cleanly designed HTTP interface should allow the layering of 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 using 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 SIN Simple Internet Notifications (SIN) is a lightweight, application neutral protocol framework for sending event notifications [Nerenberg, 1998]. SIN's communications are line commands sent between clients and servers in persistent connections; in the SIN model, object identity and event semantics defined by profiles on a per-application basis. There are plans underway to define a SIN application profile for IMAP newmail notifications, and an associated IMAP4 capability extension. 5.2.3 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.4 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.5 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.6 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.7 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.8 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 Steve Deering, "Host Extensions for IP Multicasting", RFC 1112, August 1989, available at ftp://ftp.isi.edu/in-notes/rfc1112.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 Lyndon Nerenberg, Simple Internet Notifications (SIN), Internet Draft (Work in Progress), August 1998, available at http://www.ietf.org/internet-drafts/draft-nerenberg-sin-00.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, Roy Fielding, and Lisa Lippert. Last, but not least, we would like to thank Jim Whitehead for his editorial input and leadership of the NOTIFY BOF meeting at the Chicago IETF. 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.