INTERET-DRAFT T. Moran Document: draft-moran-sipping-filter-reqs-00.txt S. Addagatla Expires: April 2003 Nokia October 2002 Requirements for 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 defines a set of structured requirements whereby an event subscriber (client) may specify when notifications are sent to it and what the contents should be. Table of Contents 1 Introduction....................................................2 2 Conventions used in this document...............................3 3 Requirements for Specification of Filters.......................3 3.1 Common syntax..............................................3 3.2 Package Identification.....................................3 3.3 Event Notification Triggering..............................3 3.3.1 Periodic..............................................3 3.4 Rate Limited...............................................3 3.4.1 Absolute Time.........................................3 3.4.2 Element Value Tests...................................4 3.4.3 Logical Expressions...................................4 Moran, Addagatla Expires - April 2003 [Page 1] INTERNET-DRAFT Event Filtering Architecture October 2002 3.5 Notification Content Limiting..............................4 3.5.1 All changed elements..................................4 3.5.2 Triggering elements...................................4 3.5.3 List of elements......................................4 3.5.4 Element value Test....................................4 3.5.5 Logical Expressions...................................4 3.6 Extensible.................................................5 4 Requirements for uploading rules (Operational Rules)............5 4.1 SUBSCRIBE method...........................................5 4.1.1 Retention of filter settings..........................5 4.1.2 Reset filter..........................................5 4.2 Server does not support filters............................5 4.3 Server does not support filter settings....................5 4.4 Server can no longer support filter settings...............5 4.5 Filter support status...........Error! Bookmark not defined. 5 Security Requirements...........................................6 6 Example Applications for Notification Filtering.................6 7 Acknowledgements................................................7 8 References......................................................7 9 Author's Addresses..............................................7 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], watcher information [3], and message waiting indications [4]. As the inherent complexity of event packages grows, both the frequency and size of event notifications are bound to increase. In general, the client needs some mechanisms for controlling the frequency and content of event notifications at the source. Evidence of this need is found in [6]. 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. Moran, Addagatla Expires - April 2003 [Page 2] INTERNET-DRAFT Event Filtering Architecture October 2002 Sections 3 and 4 of this draft propose a set of requirements whereby a client may specify when notifications are to be sent to it and what they are to contain. That is, a means to specify filtering rules to be executed by the server. Section 6 provides a few example applications of notification filtering. 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 [1]. 3 Requirements for Specification of Filters The following requirements relate to the creation of filters (rules). 3.1 Common syntax A common set of constructs MUST be defined for the creation of rules. There MUST be a common set of operations that follow a common syntax. This enables reuse among event packages. 3.2 Package Identification A means is REQUIRED whereby the client may specify the package the rules apply to. Support for version information is highly desirable. 3.3 Event Notification Triggering It MUST be possible for the client to specify the desired conditions for when notifications are to be sent to it. These conditions would override the default trigger conditions of the server/service as defined in the package. 3.3.1 Periodic It MUST be possible to specify that notifications be sent periodically. That is, they are sent at some amount of time relative to the last notification. 3.4 Rate Limited It MUST be possible to specify the maximum rate notifications are to be sent. 3.4.1 Absolute Time Moran, Addagatla Expires - April 2003 [Page 3] INTERNET-DRAFT Event Filtering Architecture October 2002 It SHOULD be possible to specify an absolute time for which a notification is to be sent. 3.4.2 Element Value Tests It MUST be possible to specify logical expressions based on the value of elements defined in the package for the purpose of when to send notifications. This includes expressions (tests) related to the change of an element's value. 3.4.3 Logical Expressions It MUST be possible to construct expressions that combine multiple tests and conditions such as the relative time since the last notification. 3.5 Notification Content Limiting It MUST be possible for the client to specify the elements to be delivered in the notification. 3.5.1 All changed elements It MUST be possible for the client to specify that only the elements whose value has changed be sent. The first notification will send all elements since no prior value has been sent, i.e. exists. 3.5.2 Triggering elements When a notification trigger has been set, it MUST be possible to specify that only those elements that triggered the sending of the notification be included. 3.5.3 List of elements The client MUST be able to specify a list of the element to be included in the notification. This includes the empty set. 3.5.4 Element value Test It MUST be possible to specify logical expressions based on the value of elements defined in the package for the purpose of determining what to send in the notification. 3.5.5 Logical Expressions It MUST be possible to construct expressions that combine multiple tests. Moran, Addagatla Expires - April 2003 [Page 4] INTERNET-DRAFT Event Filtering Architecture October 2002 3.6 Extensible It MUST be possible to extend the operations to meet the specific needs of packages/applications. 4 Requirements for uploading rules (Operational Rules) It MUST be possible for the client to upload the rules to the server (notifier)and know the status - accepted or rejected. 4.1 SUBSCRIBE method Placing filtering rules in the body of the subscription MUST be supported. Other means of delivering the filtering rules to the event server MAY be supported. 4.1.1 Retention of filter settings The server MUST retain the uploaded filter setting for the duration of the subscription. Thus, SUBSCRIBE requests sent to refresh the subscription are not required to include the filter settings. 4.1.2 Reset filter It MUST be possible for the client to reset the filter settings to the service (server) defined default. 4.2 Server does not support filters If the server does not understand the rules (e.g. content type) then it MUST explicitly indicate so in a response. 4.3 Server does not support filter settings If the server does not support or understand the filter settings, it MUST explicitly indicate so in a response. The server SHOULD indicate the reason the request is not supported or understood. For example, the filter may cause depletion of resources to a level where the functioning of the server is threatened. In such cases the notifier MUST return an appropriate error message, and SHOULD provide an interval after which the subscriber may retry the subscription with the same filter. 4.4 Server can no longer support filter settings Moran, Addagatla Expires - April 2003 [Page 5] INTERNET-DRAFT Event Filtering Architecture October 2002 The server MUST be capable of canceling an active filter and reverting back to the default rules as specified in the package. The circumstance may arise (e.g. due to loading) that the server can no longer support the level of filtering requested by the client. IN such a case the default rules need to be reinstated. 4.5 Filter support status It SHOULD be possible for the client to query the server for filtering support information. 5 Security Requirements TBD 6 Example Applications for Notification Filtering * A watcher wishes to get to know presentity's availability and willingness for messaging (e.g. IM and MMS). * The Economical Presence Service requires notification no more than every 15 minutes if the state of a buddy has changed. * The Premium Presence Service requires notification within 5 seconds if the state of a buddy has changed. * A Conference leader only wants to be notified when a certain number of attendees (defined as a quorum) have subscribed for (joined) the 9:00 a.m. group conference. * The soda machine monitoring system requests inventory of all machines at 10:00 a.m. and 3:00 pm. * A Subscriber only wants to be notified when the presentityÆs location is Dallas or FortWorth. The notification should include the vehicle license, driver name, and city. * A Basic location tracking service requires notification when the presentity's cell id changes. The notification should include the cell id. * An E911/Premium Location Service requires notification when the geo-location changes more than 25 meters. The geographical location and confidence factor are required. Moran, Addagatla Expires - April 2003 [Page 6] INTERNET-DRAFT Event Filtering Architecture October 2002 * A Push Data Service requires notification whenever the presentity's GPRS and/or GSM state (attached/detached) changes. The GPRS state, contact address, and home/roam status are required in the notification. * A presentity wishes to see who has subscribed to their presence. The presentity only wishes to see information for subscriber's who are co-workers. 7 Acknowledgements The authors would like to thank Eva-Maria Leppanen, Aki Niemi, Jose Costa-Requena, Juha Kaliokulju, and Pekka Pessi for their valuable input. 8 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] Rosenberg, J., et al, "A SIP Event Sub.Package for Watcher Information", Internet Draft, July 2001, Work in progress [4] Mahy, R., Slain, I., "SIP Event Package for Message Waiting Indication", 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] Kiss, K., Bajko, G., "Requirements for Presence Service based on 3GPP specifications and wireless environment characteristics", draft-kiss-simple-presence-wireless-reqs-00.txt, June 2002 [7] Ramsdell, B., "S/MIME Version 3.1 Message Specification", draft- ietf-smime-rfc2633bis-01.txt, June 30, 2002 9 Author's Addresses Tim Moran Nokia Inc. 6000 Connection Drive Irving, Texas 75039 Moran, Addagatla Expires - April 2003 [Page 7] INTERNET-DRAFT Event Filtering Architecture October 2002 Tel: 972.374.1369 Sreenivas Addagatla Nokia Inc. 6000 Connection Drive Irving, Texas 75039 Tel: Moran, Addagatla Expires - April 2003 [Page 8]