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]