T. Moran INTERNET DRAFT S. Addagatla Document: draft-moran-sipping-filter-00.txt A.Niemi Expires: May 2002 P.Pessi Nokia November 2001 Event Notification Filters Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses filtering and throttling of SIP event notifications. It identifies some general requirements for such mechanisms and proposes some outlines for a possible solution. The goal is to start discussion on the subject and provide a starting point for further work. Table of Contents 1 Introduction.....................................................3 2 Conventions used in this document................................3 3 Background.......................................................3 4 Requirements.....................................................4 4.1 Notification Rate..............................................4 4.2 Notification Mode..............................................4 4.3 Conditional Notifications......................................4 4.4 Content Filtering..............................................4 4.5 Aggregation Method.............................................4 4.6 Structured Document Processing.................................4 4.7 Event-Specific Operation.......................................5 Moran et al Expires May 2002 1 INTERNET DRAFT Event Notification Filters November 2001 5 Overview of Operation............................................5 5.1 Transport of Filter Description Documents......................5 5.2 Filtering Notifications........................................5 6 Structure of filters.............................................5 6.1 XML Style Sheets...............................................5 6.2 Filter Description Language....................................6 6.3 Event Notification Engine......................................6 7 Acknowledgements.................................................6 A. References......................................................6 B. Author's Addresses..............................................6 C. Expiration Date.................................................7 Moran et al Expires May 2002 2 INTERNET DRAFT Event Notification Filters November 2001 1 Introduction SIP event notification is described in [1]. It defines a general framework for subscriptions and notifications for events in SIP systems. It defines the SIP extensions for events, and introduces the concept of event packages, which are concrete applications of the general event framework to a specific group of events. Some event packages have been defined so far, e.g., user presence [2], message waiting indications [3], and watcher information [4]. As the inherent complexity of event packages grows, both the frequency and size of event notifications are bound to increase. In general, some mechanisms are needed for controlling the frequency and content of event notifications. These mechanisms are expected to be particularly valuable to users of mobile wireless access devices. The characteristics of these devices typically include high latency, low bandwidth, low data processing capabilities, small display, and limited battery power. Such devices can benefit from the ability to filter the amount of information generated at the source of the event notification. However, it is expected that the control mechanisms for event notifications add value for all users irrespective of their network access characteristics. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. 3 Background In terms of congestion control, some restrictions to the frequency of event notifications are usually incorporated in the event package definitions. Event package policy may also require that notifications only contain a portion of the full state associated with en event, e.g., indicating only a watcher whose state has changed [4]. Also, the possibility of defining additional throttling mechanisms has been identified in [1]. These mechanisms are applicable to subscription sessions. However, subscribers can also control the rate of notifications explicitly. A SUBSCRIBE with zero expiry can be used to fetch current event state, without creating a subscription session. Repeating this periodically will result in polling of event status. Further control of event notifications by the client in terms of modifying, expanding, filtering, throttling, or setting thresholds for the class of events being requested is left to the specifications of individual event packages in [1]. Such Moran et al Expires May 2002 3 INTERNET DRAFT Event Notification Filters November 2001 functionality is expected to be carried in the bodies of the SUBSCRIBE messages. 4 Requirements This chapter lists some general requirements for filtering of event notifications. 4.1 Notification Rate An event filter specifies the desired rate of event notifications. The rate can be expressed as maximum rate (notifications may only be sent at given intervals), or with a simple token bucket. 4.2 Notification Mode An event filter specifies the desired notification mode. Either the complete state of the watched event can be sent in the notifications, or if the particular event package allows it, only the change, or delta state of the event is sent. When the event state is fetched, the filter may specify the state known by the fetcher, so that only the delta state of its currently known state can be sent. NOTE: subpackage(s) may be a better solution than specifying the notification mode in filters. Also, most event packages define in their default policies the notification mode. 4.3 Conditional Notifications An event filter specifies conditions to the contents of an event notification. The notifier sends notifications only if those conditions are true. The evaluation process of these conditions may apply different levels of logical operations on the event state. For example, attributes of a presence application can be evaluated, e.g., for equality, and only in case the attributes evaluate to true, a notification is invoked. 4.4 Content Filtering An event filter specifies in which parts of the event state the subscriber is interested. Only these parts of the event state are then sent in the notifications. 4.5 Aggregation Method An event filter specifies a method for combining several pieces of event state in a single notification. 4.6 Structured Document Processing Moran et al Expires May 2002 4 INTERNET DRAFT Event Notification Filters November 2001 An event filter processes the event state according to the structure of the event state document. Such structured documents may include XML, SIP messages, MIME multipart messages, or line-oriented text. 4.7 Event-Specific Operation Event packages may restrict functionality provided by the filters. Event package specification may also require that some optional filtering functionality is mandatory with that event. 5 Overview of Operation The event filter is a document describing the maximum notification rate, the notification mode, and the actions taken on the event state before sending it in the notification. 5.1 Transport of Filter Description Documents An event filter can be uploaded to the notifier in many ways. The subscriber can include the filter document as the body of a SUBSCRIBE message. A State User Agent can upload the filter to the State Agent using the same mechanisms (SETDATA, PUT, PUBLISH) as used when uploading the event state to the State Agent. 5.2 Filtering Notifications The event filter is applied to the event state document when an event is normally generated according to the event-specific rules. First, the notifier examines the rate specification. No event notification is sent if it would exceed the rate specified by the filter. Next the notifier adjusts the notification mode; the whole state or only the delta state is included in the notification. Next, filtering actions are applied. These consist of content selection, conditions, and notification actions. If the filter so directs the selected content is sent to the subscriber in a notification. 6 Structure of filters This chapter outlines some possibilities for further work on an event filtering solution. 6.1 XML Style Sheets Currently all event packages have defined an XML based event document structure. Content filtering, or transformation of XML documents could be accomplished with XML style sheets. The World Wide Web Consortium (W3C) [6] has developed the Extensible Stylesheet Language (XSL), which may have applications for event notification filtering. Moran et al Expires May 2002 5 INTERNET DRAFT Event Notification Filters November 2001 6.2 Filter Description Language Apart from the content filtering, other mechanisms may require that a new description language is created. A filter description language would incorporate content filtering, and have additional tools for controlling the notification rate, etc. of event notifications. Such a filter description language could also be XML based. 6.3 Event Notification Engine As the filtering of notifications may in fact contain complex logical operations, simple XML based description language may not be powerful enough. An actual programming language could be used instead. For example, Java Servlets or PHP scripts could be used for uploading logic to the State Agents. 7 Acknowledgements The authors would like to thank Markus Isomaki, Krisztian Kiss, and Mohan Sivanandan for their valuable input. A. References 1 Roach, A., "SIP-Specific Event Notification", Internet Draft, November 2001, Work in progress 2 Rosenberg, J., et al, "SIP Extensions for Presence", Internet Draft, September 2001, Work in progress 3 Mahy, R., Slain, I., "SIP Event Package for Message Waiting Indication", internet Draft, July 2001, Work in progress 4 Rosenberg, J., et al, "A SIP Event Sub.Package for Watcher Information", Internet Draft, July 2001, Work in progress 5 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 6 W3C, http://www.w3c.org B. Author's Addresses Tim Moran Nokia Inc. 6000 Connection Drive Irving, Texas 75039 USA Tel: +1 972 3741 369 Fax: +1 972 8944 064 Email: tim.moran@nokia.com Moran et al Expires May 2002 6 INTERNET DRAFT Event Notification Filters November 2001 Sreenivas Addagatla Nokia Inc. 6000 Connection Drive Irving, Texas 75039 USA Tel: +1 972 3741 917 Fax: +1 972 8944 064 Email: sreenivas.addagatla@nokia.com Aki Niemi Nokia Networks P.O. Box 301 FIN-00045 NOKIA GROUP Espoo, Finland Tel: +358 50 389 1644 Fax: +358 7180 30163 Email: aki.niemi@nokia.com Pekka Pessi Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Helsinki, Finland Tel: +358 71 8036 404 Fax: +358 71 8036 851 Email: pekka.pessi@nokia.com C. Expiration Date This document is filed as and expires in May 2002. Moran et al Expires May 2002 7