INTERET-DRAFT                                                 T. Moran 
Document: draft-moran-sipping-filter-arch-00.txt          S. Addagatla 
Expires: October 2002                                            Nokia 
                                                            April 2002 
                                                                       
    
    
                Architecture 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 an extendible architecture whereby an event 
   subscriber (client) may specify the rules for SIP event notification 
   from the notifier (server). Potential solutions meeting the 
   architecture specification are also provided in the annexes.  
        
   Requirements for event filtering were previously described in [1]. 
     
Table of Contents 
    
   1 Introduction....................................................2 
   2 Conventions used in this document...............................3 
   3 Defining Rules..................................................3 
      3.1 Pre-defined Attributes.....................................3 
         3.1.1 Current time..........................................3 
         3.1.2 Package-ID............................................4 
         3.1.3 Attribute-ID..........................................4 
         3.1.4 Error.................................................4 
      3.2 Package Defined Attributes.................................4 
 
 
Moran, Addagatla        Expires - October 2002                [Page 1] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
      3.3 Operators..................................................5 
         3.3.1 Mathematical Operators................................5 
         3.3.2 Comparison and Logical Operators (Triggers)...........5 
         3.3.3 Time-based Logical Operators (Triggers)...............5 
         3.3.4 Filter Operators......................................6 
      3.4 Application Defined Operators..............................6 
   4 Client Operation................................................6 
      4.1 Normal.....................................................6 
      4.2 Abnormal...................................................7 
   5 Server Operation................................................8 
      5.1 Normal.....................................................8 
      5.2 Abnormal...................................................8 
   6 Security Considerations.........................................8 
   7 IANA Considerations.............................................9 
   8 Acknowledgements................................................9 
   9 References......................................................9 
   10 Author's Addresses.............................................9 
 
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. 
     
   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. 
    
   This draft proposes a reusable and extendible architecture whereby an 
   event client (e.g. a presence client) may specify the rules for when 
   a notification should be sent to it and what the contents should 
   contain. Syntactical constructs are identified which include common 

 
 
Moran, Addagatla        Expires - October 2002                [Page 2] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
   attributes and operations as well as mechanisms for extending the set 
   of operations. Normal and abnormal operation of the subscriber, 
   notifier, and proxy are defined. Appendices provide example 
   applications for notification filtering as well as potential 
   implementations of the architecture.  
     
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 Defining Rules 
    
   The event client (e.g. a presence client) specifies rules in the form 
   of logical expressions wherein the server is informed of the 
   appropriate conditions for notification (triggers) as well as the 
   specific content to be delivered (filters). These rules consist of a 
   defined set of operations applied to pre-defined attributes (see 
   below) and/or attributes as defined in the event package. The 
   evaluation of the rules restricts the frequency and content of the 
   notifications. In other words, the rules specify the when and what 
   criteria for notification. 
    
   This section identifies the required attributes and operations for 
   specifying event notification rules. 
    
   Annex A provides example applications where client based filtering 
   could be used. 
 
3.1 Pre-defined Attributes 
     
   In addition to the package-defined attributes, a common set of 
   attributes is needed to trigger when a notification is sent and to 
   filter what is sent. This section defines those attributes needed to 
   define client-based rules for event notification and filtering. Also 
   included is the definition of a common error handling attribute. 
 
3.1.1 Current time 
    
   Sending notifications based on absolute time or changes to a specific 
   absolute time require the current time attribute. This attribute 
   represents the current time relative to a time zone. 
    
   Current time is specified as follows: 
    
     * Year (0-9999) 
     * Month (1-12) 
     * Day of month (1-31) 
 
 
Moran, Addagatla        Expires - October 2002                [Page 3] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
     * Hour (hr: 0-23) 
     * Minute (0-59) 
     * Second (0-23) 
     * Millisecond 
     * Time Zone (EST, PST, etc.) 
    
   Support of this attribute is optional. 
    
3.1.2 Package-ID 
    
   The Package-ID attribute establishes a reference to the source that 
   defines the application specific events (attributes). Server software 
   utilizes this attribute to identify the application space (scope) for 
   which the rules apply. This is especially useful for servers 
   supporting multiple applications. 
    
   Support of this attribute is required. 
    
3.1.3 Attribute-ID 
    
   This attribute acts as a pointer to a package specific attribute. It 
   enables the client to specify what package attribute(s)should be 
   evaluated before triggering the sending of a notification. The 
   contents of this attribute are: 
    
     * Package Attribute Name  
     * Package Attribute Value 
    
   Support of this attribute is optional. 
    
3.1.4 Error 
    
   In the event server does not understand the rule or cannot honor the 
   request, the error attribute contains the server response that 
   includes: 
     * Error Code,  
     * Error String 
     * Error Details 
     * Error Source 
    
   Support of this attribute is required for the Code, and String 
   parameters. All other parameters are optional. Error codes and 
   strings are relevant to the package or service and not defined here. 
    
    
3.2 Package Defined Attributes 
    
   A package-defined attribute is referenced in a rule using the pre-
   defined attribute, Attribute-ID. Any attribute of any package may be 
 
 
Moran, Addagatla        Expires - October 2002                [Page 4] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
   referenced in a rule. Prior to referencing an attribute of a package, 
   the package itself must be referenced as described in section 3.1.2 
    
3.3 Operators 
    
   The following identifies the operations/constructs used to trigger 
   notification and filter the notification content. The client is not 
   required to specify a trigger and may only specify a filter as 
   described in section 3.3.4. 
    
3.3.1 Mathematical Operators 
    
   These operators are used to manipulate attribute values relevant to 
   their type as understood in the defining package. 
    
     * Add - addition 
     * Sub û subtraction 
     * Mul - multiply 
     * Div - divide 
     * Mod - modulo 
 
3.3.2 Comparison and Logical Operators (Triggers) 
    
   These operators are used to compare attribute values relevant to 
   their type as understood in the defining package. 
 
   Lt û less than 
   Le û less than or equal to 
   Gt û greater than 
   Ge û greater than or equal to 
   Eq û equal to 
   Ne û not equal to 
   Not û Boolean not 
   And û Boolean and 
   Or û Boolean or 
    
   Has-changed û this operation yields TRUE whenever the indicated 
   attribute has changed.  
    
   Has-changed-by <delta> û this operation yields TRUE whenever the 
   indicated attribute has at least changed by the amount specified by 
   <delta>. 
    
   In <list> û this operation compares the value of the attribute to 
   members of list. The expression yields TRUE if a match is found, 
   otherwise FALSE. 
    
3.3.3 Time-based Logical Operators (Triggers) 
    
 
 
Moran, Addagatla        Expires - October 2002                [Page 5] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
   Every <period> <repeat-n> - this operation yields TRUE whenever 
   period amount of time has lapsed since the subscription was received 
   or since the last notification.  
    
   Period is specified in hours, minutes, and seconds.  
    
   If repeat-n is specified, notification is repeated up to that many 
   times unless the subscription is cancelled or the rule is replaced by 
   a subsequent rule. If it is not specified (absent), then a single 
   notification is generated. 
      
3.3.4 Filter Operators 
 
   Default û if no filter operator is specified or the explicit Default 
   operator is used, then notifications will include those package 
   attributes as defined by the package itself. This may include, for 
   example, all attributes or only those that have changed. 
    
   All û specifies that all package attribute values be reported when a 
   notification is sent. 
    
   All Changed û requires the server to report all attributes whose 
   value has changed since the subscription or last notification. 
    
   Triggering û indicates that the server is to report all attributes 
   whose value change caused the notification rule to trigger.  
    
   Only <list> - only those attributes identified in ôlistö are to be 
   sent in the notification. 
    
   None û the server sends a notification with no attributes. 
     
3.4 Application Defined Operators 
    
   Applications may extend the above base set of operators. However, the 
   base set of operations should be used whenever possible.  
    
4 Client Operation 
    
   The normal and abnormal operation of the client (subscriber) is 
   described below. The informative annex provides plausible 
   implementation options. 
    
4.1 Normal 
    
   The client creates a rule adhering to the above rule architecture. 
   Required in the rule is a reference to the event package (i.e. 
   inclusion of Package-ID) for which the rules apply and at least one 
   triggering or filtering rule. Multiple triggering rules may be 
 
 
Moran, Addagatla        Expires - October 2002                [Page 6] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
   specified using the logical operators. If no triggering rules are 
   specified, then the triggering rules as defined in the event package 
   are used. If no, filtering rules are specified, then the filtering 
   rules of the event package apply. If no rules are specified 
   (triggering or filtering), then the default rules of the event 
   package apply. 
    
   If the current_time attribute is specified in a rule, the time is 
   understood to be that at the server. Since the client may not know 
   the time zone at the server, the client includes the time zone 
   parameter to which the time applies. The server will adjust the 
   trigger relative to the difference between its own time zone and that 
   specified by the client. For example, if the time zone of the server 
   is EST and the client requests that notification be sent at 5:00 P.M. 
   CST, then the server will set the trigger for 4:00 P.M. EST. 
    
   The client (subscriber) may use multiple methods to establish the 
   notification and filtering rule(s) in the server (notifier). However, 
   whatever method is used, the rules for notification must be 
   established either before or during subscription. Otherwise, the 
   default notification rules of the package may override those desired 
   by the client. The normative text of this draft does not specify how 
   this is done. A few plausible options are provided in the informative 
   annexes. For example, Annex B describes how the rules may be 
   specified using XML. The XML (or other method) could be included as 
   content in the body of a SUBSCRIBE request. 
    
   A client may modify a rule by issuing a new set of rules to the 
   server (e.g. re-subscribe). All prior rules are removed. That is they 
   do not stick and must be restated if desired. 
    
   If the initial response from the server does not indicate an error as 
   described in section 3.1.4 or a transport error, then the client 
   considers the rule as activated in the server. For example, if the 
   client receives a 200 OK in response to a SUBSCRIBE request and there 
   is no body or there is no described ERROR in the body of the 
   response, then the client would consider the rule as active. 
    
4.2 Abnormal 
    
   The client considers the rule as inactive if there is a transport 
   error indicating the message was not accepted or was not confirmed 
   (when confirmation is required). 
    
   The client also considers the rule as inactive when the server 
   responds with an error as described above. 
    


 
 
Moran, Addagatla        Expires - October 2002                [Page 7] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
   The status of a rule (set of rules) as specified by the client, is 
   either active or inactive. No provision for partial activation is 
   specified or required. 
    
   Recovery mechanisms are beyond the scope of this draft. 
    
5 Server Operation 
    
   The normal and abnormal operation of the server (notifier) is 
   described below. The informative annex provides plausible 
   implementation options. 
    
5.1 Normal 
    
   When the server receives a rule specification it must associate the 
   rule with the subscription or service instance. The rule must also be 
   interpreted and a decision made as to whether the server will support 
   the request in full or reject it. If supported, the server responds 
   to the client as per the requirements of the transport (e.g. 200 OK). 
   If no response is required, no explicit response indicating 
   activation of the rule is needed. 
    
5.2 Abnormal 
    
   If a server does not or cannot support a rule, then it must 
   explicitly reject it. This is done by sending a response to the 
   client which indicates the failure to accept the rule and why. 
   Reasons may include errors in syntax, parameter values not supported, 
   filtering not supported, etc.  
    
   The more information provided by the server, the better able the 
   client is to correct the problem and reissue an acceptable request. 
   For example, if the rule specified an ôEveryö parameter value of 15 
   seconds, but the server only supported a granularity of minutes, then 
   an error indication such as ôEvery value < 1 minuteö would enable the 
   client to either use the server default rules or modify the request 
   to 1 minute. 
    
   The method for explicitly rejecting the rules is not within the scope 
   of this document. However, as an example, the sever might send a 200 
   OK in response to a SUBSCRIBE request. The body of the OK would 
   contain the error indication as described in section 3.1.4. 
 
6 Security Considerations 
    
   The security considerations of the Subscribe method itself and the 
   parent package (e.g. presence), apply here. Of special consideration 
   is the integrity of the Subscribe content, namely the rules 
   themselves. Tampering with the rules by an interceptor could result 
 
 
Moran, Addagatla        Expires - October 2002                [Page 8] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
   in undesirable results such as no notifications or too many. The 
   later is of special concern since it can contribute to a denial of 
   service for other subscribers. That is, a request to be notified 
   every minute if the status changes could be changed to notify every 
   second regardless of status changes. 
    
7 IANA Considerations 
    
   If XML is determined as the implementation mechanism, then a new 
   application type may be required, e.g. application/eventfilter+XML 
    
8 Acknowledgements 
     
   The authors would like to thank Eva-Maria Leppanen, Aki Niemi, and 
   Pekka Pessi for their valuable input. 
  
9 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] Moran, T., et. al., ôEvent Notification Filtersö, draft-moran-
      sipping-filter-00.txt, November, 2001 
    
   [7] XML 1.0: W3C Recommendation, ôhttp://www.w3.org/TR/2000/REC-xml-
      20001006ö 
    
   [8] SOAP version 1.2: W3C  Working drafts from 
      ôhttp://www.w3.org/2002/ws/ö 
    
10 Author's Addresses 
     
   Tim Moran 
   Nokia Inc. 
   6000 Connection Drive 
   Irving, Texas 75039 
   Tel:  
 
 
Moran, Addagatla        Expires - October 2002                [Page 9] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
     
   Sreenivas Addagatla 
   Nokia Inc. 
   6000 Connection Drive 
   Irving, Texas 75039 
   Tel: 
    
Annex A. Example Presence Filtering Applications 
    
     Location based services for applications such as fleet 
     management, driving directions, and tracking an E911 
     caller is one area wherein simple notification based on 
     state change may be inadequate. These types of services 
     will warrant notification based on changes such as the 
     presentities location or simply periodic. Specifying a 
     default rule in the event package is difficult (if not 
     impossible) since each of these applications has different 
     quality of service needs.  Too frequent (too costly) or 
     too few notifications may be sent. Too much or too little 
     information may be sent as required by the user and/or the 
     service.  
      
     Group messaging is yet another application wherein the 
     default rules may prove insufficient. A participant may 
     not wish to know every single user that has joined a large 
     conference. Instead, a periodic indication of how many may 
     suffice. Other participants may only want to know when the 
     primary participants have joined. Participants of a small 
     chat session may wish to know all users in the session the 
     moment they join.  
      
     The following are a few concrete examples where the 
     subscriber and/or service is best equipped to define the 
     rules for notification: 
      
     * A Conference leader only wants to be notified when a 
        certain number of attendees (defined as a quorum) have 
        subscribed (or registered) for the 9:00 a.m. group 
        conference. 
     * 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 presentities 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 

 
 
Moran, Addagatla        Expires - October 2002               [Page 10] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
        geographical location and confidence factor are 
        required. 
     * A Push Data Service requires notification whenever the 
        presentities GPRS state (attached/detached) changes. 
        The GPRS state, contact address, and home/roam status 
        are required in the notification.  
     * The Economical Wireless Presence Service requires 
        notification no more than every 15 minutes if the state 
        of a buddy has changed.  
     * The Premium Wireless Presence Service requires 
        notification within 5 seconds if the state of a buddy 
        has changed. 
      
Annex B. XML Implementation 
    
   A sample XML DTD for specifying filtering rules is given below: 
    
        <!ENTITY % id-attr  "id  CDATA #REQUIRED"> 
        <!ENTITY % uri-attr "uri CDATA #IMPLIED"> 
        <!ENTITY % val-attr "val CDATA #IMPLIED"> 
        <!ENTITY % op-attr  "id  (add | sub | mul | div | mod | 
                                  lt | le | gt | ge | eq | ne | and | or | not | 
                                  has-changed | has-changed-by | 
                                  in | 
                                  every) 
                                       #REQUIRED"> 
         
        <!ELEMENT ev-filter-set (ev-filter+)> 
        <!ATTLIST ev-filter-set %uri-attr;> 
        <!ATTLIST ev-filter-set pkgdef CDATA #REQUIRED> 
        <!-- pkgdef is the URI that can provide attribute definitions --> 
         
        <!ELEMENT ev-filter   (when?, what)> 
        <!ATTLIST ev-filter   %id-attr;> 
         
        <!ELEMENT when        (builtin-expr | user-defined-expr)> 
        <!ELEMENT what        ( (attr | builtin-expr | user-defined-expr)* )> 
        <!ATTLIST what report (default | all | all-changed | triggering | 
                               only-listed | none) #IMPLIED> 
         
        <!ELEMENT expr        (const | current-time | interval | attr | 
                               builtin-expr | user-defined-expr)> 
         
        <!ELEMENT const       EMPTY> 
        <!ATTLIST const       %id-attr;> 
         
        <!ELEMENT current-time EMPTY> 
        <!ATTLIST current-time yyyy CDATA #REQUIRED> 
        <!ATTLIST current-time mm   CDATA #REQUIRED> 
 
 
Moran, Addagatla        Expires - October 2002               [Page 11] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
        <!ATTLIST current-time dd   CDATA #REQUIRED> 
        <!ATTLIST current-time hr   CDATA #REQUIRED> 
        <!ATTLIST current-time min  CDATA #REQUIRED> 
        <!ATTLIST current-time sec  CDATA #REQUIRED> 
        <!ATTLIST current-time tz   CDATA #REQUIRED> 
         
        <!ELEMENT interval EMPTY> 
        <!ATTLIST interval seconds CDATA #REQUIRED> 
         
        <!ELEMENT attr        EMPTY> 
        <!ATTLIST attr        %id-attr;> 
        <!ATTLIST attr        %val-attr;> 
         
        <!ELEMENT builtin-expr  (expr+)> 
        <!ATTLIST builtin-expr  %op-attr;> 
         
        <!ELEMENT user-defined-expr (expr+)> 
        <!ATTLIST user-defined-expr %id-attr;> 
         
        <!-- DTD for Presence filtering response --> 
         
        <!ELEMENT notification (what+ | error)> 
        <!ATTLIST notification %uri-attr;> 
         
        <!ELEMENT error (current-time, error-string)> 
        <!ATTLIST error code (server-failure | invalid-filter) #REQUIRED> 
        <!ATTLIST error filter-id CDATA #IMPLIED> 
         
        <!ELEMENT error-string (#PCDATA)> 
    
   With this DTD, the following XML requests illustrate filtering: 
    
     * A Conference leader only wants to be notified when a 
        certain number of attendees (defined as a quorum) have 
        subscribed (or registered) for the 9:00 a.m. group 
        conference. 
        
                <ev-filter-set uri="sip://conference@example.com" 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                      <builtin-expr id="ge"> 
                        <expr><attr id="num-attendees"/></expr> 
                        <expr><attr id="min-quorum-limit"/></expr> 
                      </builtin-expr> 
                    </when> 
                 
 
 
Moran, Addagatla        Expires - October 2002               [Page 12] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
                    <what> 
                      <attr id="attendee-list"/> 
                    </what> 
                 
                  </ev-filter> 
                 
                </ev-filter-set> 
                 
     * 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. 
        
                <ev-filter-set uri="sip://presentity@example.com" 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                        <builtin-expr id="in"> 
                          <expr><attr id="location-city"/></expr> 
                          <expr><const id="Dallas"/></expr> 
                          <expr><const id="Fortworth"/></expr> 
                        </builtin-expr> 
                    </when> 
                     
                    <what> 
                      <attr id="location-city"/> 
                      <attr id="vehicle-license"/> 
                      <attr id="vehicle-driver"/> 
                    </what> 
                 
                  </ev-filter> 
                 
                </ev-filter-set> 
 
     * A Basic location tracking service requires notification 
        when the presentities cell id changes. The notification 
        should include the cell id. 
        
                <ev-filter-set uri="sip://presentity@example.com" 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                      <expr> 
                        <builtin-expr id="has-changed"> 
                          <expr><attr id="cell-id"/></expr> 
 
 
Moran, Addagatla        Expires - October 2002               [Page 13] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
                        </builtin-expr> 
                      </expr> 
                    </when> 
                     
                    <what> 
                      <expr><attr id="cell-id"/></expr> 
                    </what> 
                       
                  </ev-filter> 
                 
                </ev-filter-set> 
 
     * An E911/Premium Location Service requires notification 
        when the geo-location changes more than 25 meters. The 
        geographical location and confidence factor are 
        required. 
 
                <ev-filter-set uri="sip://presentity@example.com" 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                      <expr> 
                        <builtin-expr id="has-changed-by"> 
                          <expr><attr id="location-radius-
                meters"/></expr> 
                          <expr><const id="25"/></expr> 
                        </builtin-expr> 
                      </expr> 
                    </when> 
                     
                    <what> 
                      <expr><attr id="location-longitude"/></expr> 
                      <expr><attr id="location-latitude"/></expr> 
                      <expr><attr id="location-confidence-
                factor"/></expr> 
                    </what> 
                 
                  </ev-filter> 
                 
                </ev-filter-set> 
 
     * A Push Data Service requires notification whenever the 
        presentities GPRS state (attached/detached) changes. 
        The GPRS state, contact address, and home/roam status 
        are required in the notification.  
 
                <ev-filter-set uri="sip://presentity@example.com" 
 
 
Moran, Addagatla        Expires - October 2002               [Page 14] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                      <expr> 
                        <builtin-expr id="has-changed"> 
                          <expr><attr id="gprs-state"/></expr> 
                        </builtin-expr> 
                      </expr> 
                    </when> 
                     
                    <what> 
                      <expr><attr id="gprs-state"/></expr> 
                      <expr><attr id="roaming-status"/></expr> 
                      <expr><attr id="contact-address"/></expr> 
                    </what> 
                     
                  </ev-filter> 
                   
                </ev-filter-set> 
 
     * The Economical Wireless Presence Service requires 
        notification no more than every 15 minutes if the state 
        of a buddy has changed. 
 
                <ev-filter-set uri="sip://presentity@example.com" 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                      <expr> 
                        <builtin-expr id="and"> 
                          <expr> 
                            <builtin-expr id="every"> 
                              <expr><interval seconds="900"/></expr> 
                            </builtin-expr> 
                          </expr> 
                          <expr> 
                            <builtin-expr id="has-changed"> 
                              <expr><attr id="status"/></expr> 
                            </builtin-expr> 
                          </expr> 
                        </builtin-expr> 
                      </expr> 
                    </when> 
                 
                    <what> 
 
 
Moran, Addagatla        Expires - October 2002               [Page 15] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
                      <expr><attr id="status"/></expr> 
                    </what> 
                 
                  </ev-filter> 
                 
                </ev-filter-set> 
 
     * The Premium Wireless Presence Service requires 
        notification within 5 seconds if the state of a buddy 
        has changed. 
        
                <ev-filter-set uri="sip://presentity@example.com" 
                               pkgdef="http://example.com/attr.dtd"> 
                 
                  <ev-filter id="ef-1"> 
                 
                    <when> 
                      <expr> 
                        <builtin-expr id="and"> 
                          <expr> 
                            <builtin-expr id="every"> 
                              <expr><interval seconds="5"/></expr> 
                            </builtin-expr> 
                          </expr> 
                          <expr> 
                            <builtin-expr id="has-changed"> 
                              <expr><attr id="status"/></expr> 
                            </builtin-expr> 
                          </expr> 
                        </builtin-expr> 
                      </expr> 
                    </when> 
                 
                    <what> 
                      <expr><attr id="status"/></expr> 
                    </what> 
                 
                  </ev-filter> 
                 
                </ev-filter-set> 
    
Annex C. SOAP Implementation 
    
   SOAP [8] provides the definition of an XML document which can be used 
   for exchanging structured and typed information between peers. 
    
   A sample filter request (using similar XML constructs as described in 
   Annex B) in SOAP would look like: 
    
 
 
Moran, Addagatla        Expires - October 2002               [Page 16] 
INTERNET-DRAFT       Event Filtering Architetcure           April 2002 
 
 
        <?xml version="1.0"?> 
        <soap:Envelope 
              soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
                       xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
                       xmlns:xsd="http://www.w3.org/1999/XMLSchema" 
                       xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> 
         
          <soap:Header soap:mustUnderstand="true" 
                       xmlns:m="http://conference.example.com" 
                       actor="next"> 
            <m:builtin-expr id="ge"/> 
            <m:attr id="num-attendees"/> 
          </soap:Header> 
         
          <soap:Body> 
            <m:getAttendeeList xmlns:m="http://conference.example.com/attr.dtd"> 
              <m:builtin-expr id="ge" xsi:type="xsd:boolean"> 
                <m:attr id="num-attendees" xsi:type="xsd:int"/> 
                <m:attr id="min-quorum-limit" xsi:type="xsd:int"/> 
              </m:builtin-expr> 
            </m:getAttendeeList> 
          </soap:Body> 
         
        </soap:Envelope> 
                     
    























 
 
Moran, Addagatla        Expires - October 2002               [Page 17]