[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

                                        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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/