INTERET-DRAFT T. Moran Document: draft-moran-simple-pres-filter-reqs-00.txt S. Addagatla Expires: July 2003 Nokia January 2003 Requirements for Presence specific 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 Target URI.................................................3 3.4 Event Notification Triggering..............................3 3.4.1 Rate Limited..........................................3 3.4.2 Element Value Tests...................................4 3.4.3 Logical Expressions...................................4 3.5 Notification Content Limiting..............................4 Moran, Addagatla Expires - April 2003 [Page 1]
INTERNET-DRAFT Presence Event Filtering Requirements January 2003 3.5.1 Element value Test....................................4 3.5.2 Logical Expressions...................................4 3.6 Extensible.................................................4 4 Requirements for uploading rules (Operational Rules)............4 4.1 Filter uploading...........................................4 4.2 SUBSCRIBE method...........................................5 4.2.1 Retention of filter settings..........................5 4.2.2 Changing filter settings..............................5 4.3 Server does not support filters............................5 4.4 Server does not support filter settings....................5 4.5 Server can no longer support filter settings...............5 5 Security Requirements...........................................5 6 Example Applications for Notification Filtering.................5 7 Acknowledgements................................................6 8 References......................................................6 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 such as user presence [2] and watcher information [3]. 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 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 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. Sections 3 and Error! Reference source not found. 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. Moran, Addagatla Expires - July 2003 [Page 2]
INTERNET-DRAFT Presence Event Filtering Requirements January 2003 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. It MUST be possible for the client to define different rules for different purposes using a common filtering mechanism. 3.2 Package Identification It MUST be possible for the client to specify the package the rules apply to. 3.3 Target URI It MUST be possible to indicate the target presentity or presentity list to which a certain filter criteria is applied. It MUST be possible to support filtering also in presence list subscriptions. Is MUST be possible to specify different filter criteria for an individual presentities than the other presence list members in a presence list subscription case. 3.4 Event Notification Triggering This chapter presents requirements for specifying the desired conditions for when notifications are to be sent to the client. These conditions would override the default trigger conditions of the server/service as defined in the package when they are withing the server's local policy constraints. 3.4.1 Rate Limited Moran, Addagatla Expires - July 2003 [Page 3]
INTERNET-DRAFT Presence Event Filtering Requirements January 2003 It MUST be possible to specify the maximum rate notifications are 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, and reaching a certain value of an element. 3.4.3 Logical Expressions It MUST be possible to construct expressions that combine multiple tests. 3.5 Notification Content Limiting This chapter presents requirements for specifying the content to be sent in the notifications. It MUST be possible for the client to specify the elements (e.g. only certain XML elements) to be delivered in the notification. 3.5.1 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. The existence of an element SHOULD be considered as a criterion. 3.5.2 Logical Expressions It MUST be possible to construct expressions that combine multiple tests. 3.6 Extensible The filtering solutions MUST support any extensions to the default presence information format as the PIDF [4] allows extensions to presence attributes. 4 Operational Requirements This chapter defines operation requirements of the client and server. 4.1 Filter uploading Moran, Addagatla Expires - July 2003 [Page 4]
INTERNET-DRAFT Presence Event Filtering Requirements January 2003 It MUST be possible for the client to upload the rules to the server (notifier) and know the status - accepted or rejected. 4.2 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. E.g. it should be possible for the rules to be (permanently) stored in the server, as in a presence list case. 4.2.1 Retention of filter settings The server MUST retain the uploaded filter setting for the duration of the subscription. 4.2.2 Changing filter settings It MUST be possible to change the filter settings during a subscription. It MUST be possible for the client to reset the filter settings to the service (server) defined default. 4.3 Server does not support filters If the server does not support filters (the content type) then it MUST indicate so in a response. 4.4 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 or in the NOTIFY. The server MAY indicate the general reason the request is not supported or understood, e.g. by returning a specific reason value for the event. 4.5 Server can no longer support filter settings The server MUST be able to terminate the subscription if the active filter is no longer applicable due to a policy in the Presence Server. 5 Security Requirements TBD 6 Example Applications for Notification Filtering Moran, Addagatla Expires - July 2003 [Page 5]
INTERNET-DRAFT Presence Event Filtering Requirements January 2003 * A watcher wishes to get to know presentity's availability and willingness for messaging (e.g. IM and MMS). * A watcher is interested in getting information about the communication means and contact addresses the presentity is currently available for communication. * 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 minutes 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. * A Subscriber only wants to be notified when the presentityÆs location is Dallas or Fort Worth. 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. * 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 Kalliokulju, Mikko L÷nnfors, Hisham Khartabil 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., "A Presence Event package for the Session Initiation Protocol (SIP)", Internet Draft, December 2002, Work in progress [3] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", Internet Draft, December 2002, Work in progress Moran, Addagatla Expires - July 2003 [Page 6]
INTERNET-DRAFT Presence Event Filtering Requirements January 2003 [4] H. Sugano, S. Fujimoto, et al, "CPIM presence information data format", Internet Draft, May 2002. 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-01. txt, October 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 Tel: 972.374.1369 Sreenivas Addagatla Nokia Inc. 6000 Connection Drive Irving, Texas 75039 Tel: Moran, Addagatla Expires - July 2003 [Page 7]