One document matched: draft-moran-simple-pres-filter-reqs-00.txt

                                        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]