SIP                                                     Hisham Khartabil 
Internet Draft                                              Eva Leppanen 
Expires: 23 August 2003                                                  
                                                                   Nokia 
                                                                         
                                                        24 February 2003 
    
             Event Notification Filtering for Watcher Info 
                                     
               draft-khartabil-simple-winfo-filter-00.txt 
           
    
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 a 
   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. 
    
   This Internet Draft will expire on 23rd August 2003. 
    
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2003). All Rights Reserved. 
    
    
Abstract 
    
   Watcher information template-package for the SIP event framework 
   refers to the set of users subscribed to a particular resource 
   within a particular event package. The Watcher Information I-D does 
   not describe a mechanism of how filtering of watcher information can 
   be achieved. 
     
   This document defines a watcher info filter. It provides the 
   mechanism whereby a watcherinfo subscriber can specify the watcher 
   info event filtering rules, using XML, for the notifier and how that 
   notifier is to behave when receiving such filter. 
 
Khartabil, Leppanen.                                          [Page 1] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
    
Table of Contents 
    
    
   1.0 Terminology...................................................3 
   2.0 Introduction..................................................3 
   2.1 Motivation For Using XML......................................4 
   3.0 Watcherinfo Package Specific Filters..........................4 
   3.1 Package ID....................................................4 
   3.3 Transport mechanism...........................................4 
   3.4 Structure of XML-Encoded winfo Filter Criteria................4 
   3.4.1 The <ev-filter-set> Root Element............................5 
   3.4.2 The <ev-filter> Element.....................................5 
   3.4.3 The <what> Element..........................................5 
   5.0 Client and server operation...................................6 
   5.1 Client Operation..............................................6 
   5.1.1 SUBSCRIBE Bodies............................................6 
   5.1.2 Subscriber Generating SUBSCRIBE requests....................6 
   5.1.2.1 To-Header vs. Filter URI..................................6 
   5.1.2.2 Changing The Filter Criteria Within A Dialog..............7 
   5.1.2.3 Subscriber Interpreting SIP responses.....................7 
   5.1.3 Subscriber processing NOTIFY requests.......................7 
   5.2 Server Operation..............................................8 
   5.2.1 NOTIFY Bodies...............................................8 
   5.2.2 Notifier processing SUBSCRIBE Requests......................8 
   5.2.3 Notifier Generation of NOTIFY requests......................8 
   5.2.3.1 Generating NOTIFY Contents................................9 
   5.2.4 Handling of abnormal cases..................................9 
   6.0 IANA Considerations..........................................10 
   7.0 Examples.....................................................10 
   7.1 Presentity makes subscription to get all the information about 
       active watchers..............................................11 
   7.2 Presentity makes subscription to get information about defined, 
       new and unauthorized watchers................................12 
   7.3 Presentity requests history information of watchers..........13 
   8.0 XML Schema...................................................14 
   9.0 Security Considerations......................................15 
   10.0 Acknowledgements............................................16 
   11.0 References..................................................16 
   AuthorsÆ Addresses...............................................17 
   Full Copyright Statement.........................................17 
   Acknowledgement..................................................18 
    
 
Khartabil, Leppanen.                                          [Page 2] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
    
1.0 Terminology 
    
   In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" "MAY", 
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 
    
   The document uses the terms as defined in [2] and [3]. 
    
2.0 Introduction 
    
   Watcher information template-package for the SIP event framework 
   refers to the set of users subscribed to a particular resource 
   within a particular event package [2]. 
    
   SIP event notification is described in [4]. It defines a general 
   framework for sending subscriptions and receiving notifications in 
   SIP based systems.  It introduces the concept of event packages, 
   which are concrete applications of the general event framework to a 
   specific usage of events. 
    
   Filtering is a mechanism for controlling the content of event 
   notifications [5].  
    
   The filtering mechanism is expected to be particularly valuable to 
   users of mobile wireless access devices. The characteristics of the 
   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.  
    
   It is stated in [2] that Watcherinfo notifications are generated 
   every time there is any change in the state of the watcher 
   information. It also states that Watcherinfo notifications triggered 
   from a change in watcher state only contain information on the 
   watcher whose state has changed. The format of such information 
   defined in [3]. 
    
   This document presents a mechanism for the filtering of the 
   watcherinfo information. The document specifically describes how the 
   subscriber is able to both limit the content and indicate more 
   specifically the preferred content of the notifications using XML 
   and Xpath [14] technologies. It also describes how the notifier 
   functions when generating notifications by taking into account 
   filters, authorisation rules and default functionality of the 
   watcherinfo notification service. 
    
   The watcherinfo specific filtering solution presented here is 
   compatible with the watcherinfo event template-package [2]. 
    
   Requirements for the watcherinfo filter criteria can be found [5] 
   and [13]. 
 
Khartabil, Leppanen.                                          [Page 3] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
    
   Events Notification RFC [4] and the SIMPLE working group both 
   identify filtering work as potential work. 
    
2.1 Motivation For Using XML 
    
   When trying to select the schema and protocol for defining the 
   filter criteria, it can be found that there are several alternatives 
   available. The best practice is to modularise the problem and work 
   on smaller modules (the protocol and the filter information schema). 
   The selection of the schema for defining the filter criteria 
   requires a readable syntax with enough flexibility to define the 
   semantics. 
    
   Among the multiple possibilities (i.e. XML, Perl, TCL, etc), XML 
   provides a generic framework where a schema for the filter logic 
   including a namespace allowing the definition of the filter 
   criteria. Thus, an XML schema provides an extensible mechanism where 
   the logic required for the filtering functionality can be built. XML 
   provides extensibility based on "namespaces" associated with a 
   globally unique URI. 
    
   The XML also enables the use of Xpath [14] for referencing items in 
   an XML document (which in the case is watcher information in the 
   format of watcherinfo). 
   In addition, by using XML the need for reliance on the transport 
   protocol in order to interpret the filter criteria can be 
   eliminated.  
    
    
3.0 Watcherinfo Package Specific Filters 
    
   This section describes the technologies and information needed to 
   provide a filter specification relevant to watcherinfo filtering. 
    
    
3.1 Package ID  
    
   The package ID is æwinfoÆ. This ID is carried in the event-header of 
   the SUBSCRIBE as well as within the XML document carrying filter 
   criteria. 
    
    
3.3 Transport mechanism 
    
   Transportation of the filter criteria to the server is achieved by 
   inserting the filter XML document in the body of a SIP SUBSCRIBE 
   request. Alternatively, the document can be uploaded to the server 
   using a transport specific for data manipulation. 
    
3.4 Structure of XML-Encoded winfo Filter Criteria 
    
 
Khartabil, Leppanen.                                          [Page 4] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   Winfo Filter Criteria is an XML document [7] that MUST be well-
   formed and SHOULD be valid. Winfo Filter Criteria XML documents MUST 
   have the XML declaration and it SHOULD contain an encoding 
   declaration in the XML declaration e.g. "<?XML version='1.0' 
      encoding='UTF-8'?>". This specification makes use of XML 
   namespaces for identifying the XML schema of the Winfo Filter 
   Criteria documents and document fragments.  
    
   The namespace identifier for elements defined by this specification 
   is a URN [8]; using the namespace identifier 'ietf' defined by [9] 
   and extended by [10]. This urn is: 
    
   urn:ietf:params:xml:ns:simple-winfo-filter+xml. 
    
   This namespace declaration indicates the namespace on which the 
   filter criteria are based on. 
    
3.4.1 The <ev-filter-set> Root Element 
    
   The root element of the filter criteria is <ev-filter-set>. The <ev-
   filter-set> MAY have a 'pkgdef' attribute that defines the æwinfoÆ 
   as package for the filter criteria. 
    
   The <ev-filter-set> root element MUST contain the namespace 
   mentioned above. This element MUST contain one or more <ev-filter> 
   elements.    
    
3.4.2 The <ev-filter> Element 
    
   The <ev-filter> element is used to specify the content of an 
   individual filter.  
    
   <ev-filter> MUST have an 'id' attribute. The value of the 'id' 
   attribute MUST be unique within the <ev-filter-set> root element. 
   <ev-filter> MAY have an 'uri' attribute. The value of the 'uri' 
   attribute is the URI of a watcher-list resource. 
    
   The <ev-filter> element MUST contain a <what> element. 
    
    
3.4.3 The <what> Element 
    
   The <what> element is used to specify the content to be delivered to 
   the watcherinfo subscriber. It does not specify the exact content 
   but rules that are used to construct that information.  
    
   The <what> element MUST contain the 'report' attribute. The value of 
   the 'report' is either 'default'. The 'default' value means that the 
   whole content of selected watcher elements are delivered. 
    
   The æstateÆ attribute is optional and indicates whether the document 
   to be delivered to the watcherinfo subscriber contains the ôfullö 
   watcherinfo state, or whether it contains only information on those 
 
Khartabil, Leppanen.                                          [Page 5] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   watchers which have changed since the previous document (ôpartialö) 
   [2]. The delivered content depends on the XPath rules and the 
   selected state. If this attribute is not present, the default value 
   is a matter of local policy [2]. 
    
   OPEN ISSUE: the æreportÆ attribute may be later removed if it is 
   asserted that no other value (e.g. ôonly-selectedö) is needed. 
    
    
3.4.3.1 Defining the delivered content 
    
   It must be possible in the filter criteria to be able to select 
   watchers from which watcher information is delivered. The selection 
   is based on any XML elements and attributes of the default 
   watcherinfo format [3]. 
    
   The preferred watcher information is indicated using the 
   capabilities of XPath [14]. The XPath clause is stated in the value 
   of the <What> element.  
 
4.0 Client and server operation 
    
4.1 Client Operation 
    
4.1.1 SUBSCRIBE Bodies 
    
   SIP entities compliant with this specification MUST support content-
   type æapplication/simple-winfo-filter+xmlÆ. 
    
4.1.2 Subscriber Generating SUBSCRIBE requests 
    
   This section presents additional functionalities required from the 
   subscriber when filters are used in SUBSCRIBE requests bodies. 
   Normal operations as defined in [2] are then followed. 
    
   As defined in [2], a SUBSCRIBE for winfo MAY contain a body. This 
   body, as defined in this document, would serve the purpose of 
   filtering. Honouring of these filters is at the policy discretion of 
   the notifier. 
    
   No content in the body of a SUBSCRIBE indicates to the notifier that 
   no filter is being requested; so that the notifier is instructed to 
   send all NOTIFY requests using the notifierÆs default watcherinfo 
   subscription filtering policy as described in [2]. 
    
   If present, the body MUST be of MIME-Type æapplication/simple-winfo-
   filter+xmlÆ. 
    
    
4.1.2.1 To-Header vs. Filter URI 
    
 
Khartabil, Leppanen.                                          [Page 6] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   The Event package "winfo" in Event-header of the SUBSCRIBE request 
   specifies that the filter rules apply to the watcherinfo of a 
   watcher-list resource whose URI appears in the filter. 
    
   If no watcher-list resource URI is indicated by the filter, the 
   filter rules apply to the watcher-list of the resource identified in 
   the To-header. 
    
   If the resource URI indicated by the filter is not the same as the 
   one in the To-header, that filterÆs rules do not apply and are 
   ignored. The filter does not affect Watcherinfo documents sent to 
   the watcherinfo subscriber. 
    
    
4.1.2.2 Changing The Filter Criteria Within A Dialog 
 
   The client MAY reset or change the filter criteria by re-issuing a 
   new SUBSCRIBE request within the existing dialog. The SUBSCRIBE 
   provides the "replace" semantics. This means that all filters are 
   replaced. A SUBSCRIBE within the exiting dialogs that does not 
   contain a filter is assumed to be removing all filter criteria. 
    
   The filter MAY be incorporated within an existing subscription (an 
   active dialog) by the subscriber sending a re-SUBSCRIBE that 
   includes the filter in the body. 
    
    
4.1.2.3 Subscriber Interpreting SIP responses 
    
   The SUBSCRIBE request will be confirmed with a final response. 200-
   class responses indicate that the subscription has been accepted, 
   and that a NOTIFY will be sent immediately. A 200 response indicates 
   that the subscription has been accepted, the user is authorized and 
   that the filter is accepted.  A 202 response merely indicates that 
   the subscription has been understood, the content type has been 
   accepted, and that authorization may or may not have been granted. A 
   202 response also indicates that the filter has not been accepted 
   yet. The acceptation of the filter MAY arrive in a subsequent 
   NOTIFY. 
    
   Non-200 class final responses indicate that no subscription or 
   dialog has been created, and no subsequent NOTIFY message will be 
   sent.  All non-200 class responses have the same meanings and 
   handling as described in RFC 3261 [11] and RFC 3265[4]. 
   Specifically, a 415 response indicates that the server does not 
   understand the MIME-type æapplication/simple-pres-filter+xmlÆ. A 488 
   response indicates that the content (filter) is understood but some 
   aspects of it were either not understood or not accepted. 
    
    
4.1.3 Subscriber processing NOTIFY requests 
    
 
Khartabil, Leppanen.                                          [Page 7] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   If a 2xx response was returned for the SUBSCRIBE, the NOTIFY that 
   follows MAY contain a body that describes the state of the watcher 
   after the filter has been applied. 
    
   If the NOTIFY indicates that a subscription has been terminated [4], 
   the subscription is assumed to be terminated. Behaviour in such 
   events is also described in [4]. 
    
   If the subscription is indicated as active, NOTIFY requests are 
   handled as described in [2] and [4].  
    
4.2 Server Operation 
    
4.2.1 NOTIFY Bodies 
    
   SIP entities compliant with this specification MUST support content-
   type æapplication/simple-winfo-filter+xmlÆ. 
    
4.2.2 Notifier processing SUBSCRIBE Requests 
    
   This section presents addition functionalities required from the 
   notifier when filters are used in SUBSCRIBE requests bodies. Normal 
   operations as defined in [2] are then followed. 
    
   The notifier will examine the content-type header and will return a 
   415 response if it does not understand content-type 
   æapplication/simple-pres-filter+xmlÆ. 
    
   If the notifier accepts the content-type, it then starts parsing the 
   body. If the body is understood but some aspects of the contents 
   (filter) were not understood and accepted, then procedures described 
   in section 4.2.4 are followed. 
    
   A 200-class responses indicate that the subscription has been 
   accepted, and that a NOTIFY will be sent immediately. A 200 response 
   indicates that the subscription has been accepted, the user is 
   authorized and that the filter is accepted.  A 202 response merely 
   indicates that the subscription has been understood, and that 
   authorization may or may not have been granted. A 202 response also 
   indicates that the filter has not been accepted yet. The acceptation 
   of the filter MAY arrive in a subsequent NOTIFY. 
    
   The filter MAY be incorporated within an existing subscription (an 
   active dialog) by the notifier receiving a re-SUBSCRIBE that 
   includes the filter in the body. 
    
    
4.2.3 Notifier Generation of NOTIFY requests 
    
   Upon receiving the SUBSCRIBE with the filtering rules, the notifier 
   SHOULD retain the filter as long as the subscription persists. The 
   filter SHOULD be used as long as the subscription is active.  
    
 
Khartabil, Leppanen.                                          [Page 8] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   If the response sent to the SUBSCRIBE was a 202, and the 202 was 
   chosen because the filter could not be accepted in time, the NOTIFY 
   MAY be used to terminate the subscription if the filter was not 
   found acceptable. See Section 4.2.4. 
    
   As described in [2], the NOTIFY message MAY contain a body that 
   describes the state of the watchers. This body MUST be in one of the 
   formats listed in the Accept header of the SUBSCRIBE, or the 
   presence specific default æapplication/watcherinfo+xmlÆ if the 
   Accept header is omitted. 
    
4.2.3.1 Generating NOTIFY Contents 
    
   The input to the filter is a watcherinfo document [3] derived 
   according to the normal functionality defined in [2]. 
    
   Before applying the Xpath expression to the watcherinfo document, 
   the æstateÆ attribute is considered. If the value is ôpartialö, the 
   information of watchers, whose state has not changed since the last 
   document, is removed before any further processing. If the value is 
   ôfullö, all watchersÆ information is included in the next processing 
   step. 
    
   If the æstateÆ attribute is omitted from the filter, the notifierÆs 
   local policies are applied to determine the watchers whose 
   information is filtered. 
    
   The content is then filtered according to the XPath expression. The 
   XPath expression indicates the delivered watcher elements. 
    
   The 'report' attribute indicates the delivered content. The value 
   ôdefaultö of the 'report' attribute means that all the values and 
   attributes of the selected watcher elements are delivered. In 
   addition to the selected watcher elements, the namespace definitions 
   are also conveyed. 
    
    
4.2.4 Handling of abnormal cases 
    
   In case of an invalid filter definition û the filter XML document is 
   not aligned with the filter XML schema, the notifier rejects the 
   SUBSCRIBE request with a 488. A warning header in the response may 
   give a better indication why the filters are not accepted. 
    
   If the subscription was accepted with a 202 response and the filter 
   is being evaluated after that, a NOTIFY with a subscription-state of 
   terminated is sent. An event-reason-value of ôbadfilterö MAY be 
   included. 
    
   The above paragraph uses the extension to the event-reason-value of 
   subexp-params as defined in [6]. 
    
 
Khartabil, Leppanen.                                          [Page 9] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   In case of an erroneous XPath clause in the filter definition the 
   notifier either ignores the filter definition or terminates the 
   subscription. 
    
   In case of indication of empty content by the XPath clause the 
   presence agent functions according to the normal procedure for the 
   content filtering described in this document. 
    
5.0 IANA Considerations 
    
   A new content type "application/simple-winfo-filter+xml" is defined 
   to represent an XML MIME for the filter criteria of Presence. 
    
   This specification follows the guidelines of RFC3023 [12]. 
    
   OPEN ISSUE: IANA registration template must be added later. 
    
    
6.0 Examples  
    
   The examples in this section use the ôpresenceö event package with 
   the ôwinfoö template-package. 
    
   Watcher information to a Presentity: 
    
   <?xml version="1.0"?> 
     <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" 
   version="0" state="full"> 
     <watcher-list resource="sip:presentity@domain.com" 
                   package="presence"> 
         <watcher status="active" 
            id="sr8fdsj" 
            duration-subscribed="509" 
            expiration="20" 
            event="approved">sip:watcherA@example.com"</watcher> 
         <watcher status="pending" 
            id="sr8fdsj" 
            duration-subscribed="501" 
            expiration="100" 
            event="subscribe">sip:watcherB@example.com"</watcher> 
         <watcher status="terminated" 
            id="sr8fdsj" 
            duration-subscribed="500" 
            expiration="0" 
            event="rejected">sip:watcherC@example.com"</watcher> 
         <watcher status="active" 
            id="sr8fdsj" 
            duration-subscribed="20" 
            expiration="30" 
            event="approved">sip:watcherD@domain.com"</watcher> 
     </watcherinfo> 
    
    
 
Khartabil, Leppanen.                                         [Page 10] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
6.1 Presentity makes subscription to get all the information about 
active watchers 
    
   SUBSCRIBE request from the presentity including the filter: 
    
   SUBSCRIBE sip:presentity@domain.com 
   Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 
   To: <sip:presentity@domain.com> 
   From: <sip:presentity@domain.com>;tag:12341111 
   Call-ID: 121212@10.0.0.1 
   Cseq: 1 SUBSCRIBE 
   Expires: 3600 
   Event: Presence.winfo 
   Contact: <sip:presentity@dom.com> 
   Content-Type: application/simple-winfo-filter+xml 
   Content-Length: à 
    
   <?xml version="1.0" encoding="UTF-8"?> 
     <ev-filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter" 
   pkgdef=öwinfoö> 
         <ev-filter id = "active" uri=ösip:presentity@domain.comö> 
           <what report="default" state="partial"> 
              //*[(.                 .                 /@package="presence" and                                       /                                       /@status="active")]/ancestor-or-self:                                                                 :* 
          </what> 
        </ev-filter> 
     </ev-filter-set> 
    
    
   Notification to the subscriber: 
    
   NOTIFY sip:presentity@dom.com SIP/2.0 
   Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 
   To: sip:presentity@domain.com;tag:12341111 
   From: sip:presentity@domain.com;tag:232321 
   Call-ID: 121212@10.0.0.1 
   Cseq: 1 NOTIFY 
   Contact: sip:presentity@server.domain.com 
   Event: Presence.winfo 
    
   Content-Type: application/watcherinfo+xml 
   Content-Length: à 
    
   <?xml version="1.0"?> 
     <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" 
   version="0" state="full"> 
     <watcher-list resource="sip:presentity@domain.com" 
                   package="presence"> 
         <watcher status="active" 
            id="sr8fdsj" 
            duration-subscribed="509" 
            expiration="20" 
            event="approved">sip:watcherA@example.com"</watcher> 
         <watcher status="active" 
 
Khartabil, Leppanen.                                         [Page 11] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
            id="sr8fdsj" 
            duration-subscribed="20" 
            expiration="30" 
            event="approved">sip:watcherD@domain.com"</watcher> 
     </watcherinfo> 
    
6.2 Presentity makes subscription to get information about defined, new 
and unauthorized watchers 
    
   SUBSCRIBE request from the presentity including the filter: 
    
   SUBSCRIBE sip:presentity@domain.com 
   Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 
   To: <sip:presentity@domain.com> 
   From: <sip:presentity@domain.com>;tag:12341111 
   Call-ID: 121212@10.0.0.1 
   Cseq: 1 SUBSCRIBE 
   Expires: 3600 
   Event: Presence.winfo 
   Contact: <sip:presentity@dom.com> 
   Content-Type: application/simple-winfo-filter+xml 
   Content-Length: à 
    
   <?xml version="1.0" encoding="UTF-8"?> 
     <ev-filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter" 
   pkgdef=öwinfoö> 
         <ev-filter id = "filter_X" uri=ösip:presentity@domain.comö> 
           <what report="default" state="partial"> 
              //*[(.                 .                 /@package="presence" and ((@status="terminated" and 
   @event="rejected") or @event="subscribe" or contains(.,"domain.com"))]/ancestor-or-self:                                                                     :                                                                     * 
          </what> 
        </ev-filter> 
     </ev-filter-set> 
    
   Notification to the subscriber: 
    
   NOTIFY sip:presentity@dom.com SIP/2.0 
   Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 
   To: sip:presentity@domain.com;tag:12341111 
   From: sip:presentity@domain.com;tag:232321 
   Call-ID: 121212@10.0.0.1 
   Cseq: 1 NOTIFY 
   Contact: sip:presentity@server.domain.com 
   Event: Presence.winfo 
    
   Content-Type: application/watcherinfo+xml 
   Content-Length: à 
    
   <?xml version="1.0"?> 
     <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" 
   version="0" state="full"> 
     <watcher-list resource="sip:presentity@domain.com" 
                   package="presence"> 
 
Khartabil, Leppanen.                                         [Page 12] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
         <watcher status="pending" 
            id="sr8fdsj" 
            duration-subscribed="501" 
            expiration="100" 
            event="subscribe">sip:watcherB@example.com"</watcher> 
         <watcher status="terminated" 
            id="sr8fdsj" 
            duration-subscribed="500" 
            expiration="0" 
            event="rejected">sip:watcherC@example.com"</watcher> 
         <watcher status="active" 
            id="sr8fdsj" 
            duration-subscribed="20" 
            expiration="30" 
            event="approved">sip:watcherD@domain.com"</watcher> 
     </watcherinfo> 
    
6.3 Presentity requests history information of watchers  
    
   SUBSCRIBE request from the presentity including the filter: 
    
   SUBSCRIBE sip:presentity@domain.com 
   Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk 
   To: <sip:presentity@domain.com>;tag:12341111 
   From: <sip:presentity@domain.com> 
   Call-ID: 121212@10.0.0.1 
   Cseq: 1 SUBSCRIBE 
   Expires: 0 
   Event: Presence.winfo 
   Contact: <sip:presentity@dom.com> 
   Content-Type: application/simple-winfo-filter+xml 
   Content-Length: à 
    
   <?xml version="1.0" encoding="UTF-8"?> 
     <ev-filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter" 
   pkgdef=öwinfoö> 
         <ev-filter id = "history" uri=ösip:presentity@domain.comö> 
           <what report="default" state="full"> 
              //*[(.                 .                 /@package="presence" and (@duration-subscribed>500)]/ancestor-or-
   self:      :* 
          </what> 
        </ev-filter> 
     </ev-filter-set> 
    
   Notification to the subscriber: 
    
   NOTIFY sip:presentity@dom.com SIP/2.0 
   Via: SIP/2.0/TCP presence.domain.com:5060;branch=xjfder 
   To: sip:presentity@domain.com;tag:12341111 
   From: sip:presentity@domain.com;tag:232321 
   Call-ID: 121212@10.0.0.1 
   Cseq: 1 NOTIFY 
   Contact: sip:presentity@server.domain.com 
 
Khartabil, Leppanen.                                         [Page 13] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   Event: Presence.winfo 
    
   Content-Type: application/watcherinfo+xml 
   Content-Length: à 
    
   <?xml version="1.0"?> 
     <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" 
   version="0" state="full"> 
     <watcher-list resource="sip:presentity@domain.com" 
                   package="presence"> 
         <watcher status="active" 
            id="sr8fdsj" 
            duration-subscribed="509" 
            expiration="20" 
            event="approved">sip:watcherA@example.com"</watcher> 
         <watcher status="pending" 
            id="sr8fdsj" 
            duration-subscribed="501" 
            expiration="100" 
            event="subscribe">sip:watcherB@example.com"</watcher> 
     </watcherinfo> 
    
7.0 XML Schema 
    
   The XML Schema for the watcher information filter.  
   ******************* 
    
   XML Schema Implementation (Normative) 
   <?xml version="1.0" encoding="UTF-8"?> 
    
   <!-- *********************************************************** --> 
    
   <xsd:schema targetNamespace="urn:ietf:params:xml:ns:simple-winfo-
   filter" 
   xmlns:xsd=http://www.w3.org/2001/XMLSchema/> 
   <xsd:import namespace="http://www.w3.org/XML/1998/namespace" 
     schemaLocation="http://www.w3.org/2001/xml.xsd"> <!ùlang --> 
    
   <xsd:annotation> 
     <xsd:documentation xml:lang="en"> 
       XML Schema Definition for SIP Event Filtering for Winfo. 
     </xsd:documentation> 
   </xsd:annotation> 
    
   <!-- *********************************************************** --> 
    
   <xsd:element name="ev-filter-set" type="EventFilterSetType"/> 
    
   <!-- 
   The "pkgdef" attribute is useful to identify the event package  
   --> 
    
   <xsd:complexType name="EventFilterSetType"> 
 
Khartabil, Leppanen.                                         [Page 14] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
     <xsd:sequence> 
       <xsd:element name="ev-filter" type="EventFilterType" 
                    minOccurs="1"    maxOccurs="unbounded"/> 
     </xsd:sequence>  
     <xsd:attribute name="pkgdef"    type="xsd:string" use="optional"/> 
   </xsd:complexType> 
    
   <!-- 
      An event filter corresponds to the SIP URI indicated by its "uri" 
   attribute. The URI defines the watcher-list resource. --> 
    
   <xsd:complexType name="EventFilterType">  
     <xsd:sequence>  
       <xsd:element name="what" type="WhatType" use="required"/> 
     </xsd:sequence>  
     <xsd:attribute name="id"  type="xsd:string" use="required"/> 
     <xsd:attribute name="uri" type="xsd:anyURI" use="optional"/> 
     <xsd:attribute name="state" type="StateType" use="optional"/> 
    
   </xsd:complexType> 
    
    
   <xsd:complexType name="WhatType"> 
     <xsd:simpleContent> 
       <xsd:extension base="xsd:string">  
      <xsd:attribute name="report" type="ReportType" use="required"/> 
       </xsd:extension base> 
     </simpleContent> 
   </xsd:complexType> 
    
   <xsd:simpleType name="ReportType"> 
     <xsd:restriction base="xsd:string"> 
       <xsd:enumeration value="default"/> 
     </xsd:restriction> 
   </xsd:simpleType> 
    
   <xsd:simpleType name="StateType"> 
     <xsd:restriction base="xsd:string"> 
       <xsd:enumeration value="partial"/> 
       <xsd:enumeration value="full"/> 
     </xsd:restriction> 
   </xsd:simpleType> 
 
 
   <!-- *********************************************************** --> 
    
   </xsd:schema> 
    
   <!-- * 
    
    
8.0 Security Considerations 
    
 
Khartabil, Leppanen.                                         [Page 15] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
   The presence of filters in the body in a SIP message has a 
   significant effect on the ways in which the request is handled at a 
   server. As a result, it is especially important that messages 
   containing this extension be authenticated and authorized. 
    
   Processing of requests and looking up filter criteria requires set 
   operations and searches, which can require some amount of 
   computation. This enables a DoS attack whereby a user can send 
   requests with substantial numbers messages with large contents, in 
   the hopes of overloading the server. To counter this, the server 
   SHOULD only allow filters with no more than about 20 rules. 
    
   Requests can reveal sensitive information about a UAÆs capabilities. 
   If this information is sensitive, it SHOULD be encrypted using SIP 
   S/MIME capabilities. 
    
   All watcherinfo related security measures discussed in [2] MUST be 
   followed. 
    
    
9.0 Acknowledgements 
     
   The authors would like to thank Jyrki Aarnos and Juha Kalliokulju 
   and Tim Moran for their valuable comments. 
     
    
10.0 References 
    
   [1] S. Bradner, "Key words for use in RFCs to indicate requirement 
      levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 
    
   [2] Rosenberg, J., "A Watcher Information Event Template-Package for 
   SIP", draft-ietf-simple-winfo-package-05.txt. Internet Draft, 
   January 2003, Work in progress. 
    
   [3] Rosenberg, J., "An XML Based Format for Watcher Information", 
   draft-ietf-impp-cpim-pidf-05.txt. Internet Draft, January 2003. Work 
   in progress. 
    
   [4] Roach, A., "SIP-Specific Event Notification", RFC 3265, Internet 
   Engineering Task Force, June 2002. 
    
   [5] Kiss, K. et al, " Requirements for Filtering of Watcher 
   Information", draft-kiss-simple-winfo-filter-reqs-00.txt. Internet 
   Draft, February 2003, Work in progress. 
    
   [6] Khartabil, H. et al, ôEvent Notification Filtering for 
   Presence", draft-khartabil-simple-presence-filter-00.txt. Internet 
   Draft, January 2003. Work in progress. 
    
   [7] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The 
   XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml-
   19980210. 
 
Khartabil, Leppanen.                                         [Page 16] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
    
   [8] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task 
   Force, May 1997. 
    
   [9] R. Moats, "A URN namespace for IETF documents," RFC 2648, 
   Internet Engineering Task Force, Aug. 1999. 
    
   [10] M. Mealling, "The IETF XML registry", draft-mealling-iana-
   xmlns-registry-04.txt. Internet Draft. November 2001.  Work in 
   progress. 
    
   [11] J. Rosenberg, et al. ôSIP: Session Initiation Protocolö. RFC 
   3261, Internet Engineering Task Force, June 2002. 
    
   [12] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 
   3023, Internet Engineering Task Force, Jan. 2001. 
    
   [13] K.Kiss, ôRequirements for Presence Service based on 3GPP 
   specifications and wireless environment characheristicsö draft-kiss-
   simple-presence-wireless-reqs-01.txt. Internet Draft, October 2002. 
   Work in progress. 
    
   [14] W. W. W. C. (W3C), "XML Path Language (Xpath)". W3C 
   Recommendation. <link - http://www.w3.org/TR/xpath > 
    
    
AuthorsÆ Addresses 
    
   Hisham Khartabil 
   Nokia 
       
   P.O. Box 321 
   FIN-00045 
   NOKIA GROUP 
   FINLAND 
    
   Email: hisham.khartabil@nokia.com 
   Tel: + 358 7180 76161 
    
    
   Eva Leppanen 
   Nokia 
    
   P.O Box 785 
   FIN-33101 Tampere 
   FINLAND 
    
   Tel: +358 7180 77066  
   Email: eva-maria.leppanen@nokia.com 
    
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2003).  All Rights Reserved. 
 
Khartabil, Leppanen.                                         [Page 17] 

Internet Draft          Watcher Info Filtering           February 2003 
 
 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Khartabil, Leppanen.                                         [Page 18]