SIMPLE H. Khartabil Internet-Draft E. Leppanen Expires: August 3, 2004 M. Lonnfors J. Costa-Requena Nokia February 3, 2004 Functional Description of Event Notification Filtering draft-ietf-simple-event-filter-funct-00 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. This Internet-Draft will expire on August 3, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the Khartabil, et al. Expires August 3, 2004 [Page 1] Internet-Draft Functional Description of Filtering February 2004 notifier behaves when receiving such filtering rules and how a notification is constructed. The format of the filter is outside the scope of this document. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Client Operation . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Transport Mechanism . . . . . . . . . . . . . . . . . . . . 4 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Subscriber Generating SUBSCRIBE Requests . . . . . . . . . . 4 3.3.1 Structure of a Filter . . . . . . . . . . . . . . . . . . . 4 3.3.2 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . . 5 3.3.3 Changing Filters within a Dialog . . . . . . . . . . . . . . 5 3.3.4 Subscriber Interpreting SIP responses . . . . . . . . . . . 5 3.4 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 6 4. Resource List Server Behaviour . . . . . . . . . . . . . . . 6 4.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . . 6 5. Server Operation . . . . . . . . . . . . . . . . . . . . . . 7 5.1 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Notifier Processing SUBSCRIBE Requests . . . . . . . . . . . 7 5.2.1 Request-URI vs. Filter URI . . . . . . . . . . . . . . . . . 7 5.3 Notifier Generating NOTIFY Requests . . . . . . . . . . . . 8 5.3.1 Generation of NOTIFY Contents . . . . . . . . . . . . . . . 8 5.3.2 Handling of Notification Triggering Rules . . . . . . . . . 9 5.4 Handling Abnormal Cases . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Presence Specific Examples . . . . . . . . . . . . . . . . . 10 7.1.1 Subscriber Requests Messaging Related Information . . . . . 11 7.1.2 Subscriber Fetches Information about "Open" Communication Means . . . . . . . . . . . . . . . . . . . . 12 7.1.3 Subscriber Requests Notifications when Presentity's Status Changes . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Watcher Information Specific Examples . . . . . . . . . . . 16 7.2.1 Watcher Subscriber Makes Subscription to Get All the Information about Active Watchers . . . . . . . . . . . . . 17 7.2.2 Watcher Subscriber Requests Information of Watchers with Specific Subscription Duration Conditions . . . . . . . . . 18 7.2.3 Watcher Subscriber Requests Specific Watcher Info On Specific Triggers . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . 25 Khartabil, et al. Expires August 3, 2004 [Page 2] Internet-Draft Functional Description of Filtering February 2004 1. Conventions 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] and indicate requirement levels for compliant implementations. 2. Introduction SIP event notification is described in [5]. 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. Additionally, the subscriber may specify the rules for when a notification should be sent to it. Requirements for such mechanisms are defined in [10] and [11]. 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 [5] that the notifier may send a NOTIFY at any time, but typically it is sent when the state of the resource changes. It also states that the notifications would contain the complete and current state of the resource authorized for a certain subscriber to see. The format of such resource state information is package specific. In this memo, we assume that the NOTIFY for any package contains an XML document. There is a separate approach for the rate limiting of SIP event notifications, namely the throttling mechanism [12]. This throttling mechanism allows the subscriber to specify a maximum rate at which event notifications are generated by a single notifier. The solution for such requirements is out of scope for this document. This document presents a mechanism for filtering whereby a subscriber describes its preference of when notifications are to be sent to it and what they are to contain. It also describes how the notifier functions when generating notifications by taking into account filters and default functionality of the package/service. The XML format for defining the filter is described in [9]. Khartabil, et al. Expires August 3, 2004 [Page 3] Internet-Draft Functional Description of Filtering February 2004 3. Client Operation 3.1 Transport Mechanism Transportation of the filter to the server is achieved by inserting the XML document, as defined in [9], in the body of the SUBSCRIBE request. Alternatively, the XML document can be uploaded to the server using means outside the scope of this document. 3.2 SUBSCRIBE Bodies SIP entities compliant with this specification MUST support the content type 'application/simple-filter+xml'. 3.3 Subscriber Generating SUBSCRIBE Requests This section presents additional functionality required from the subscriber when filters are used in the bodies of the SUBSCRIBE requests. Normal operations of services, e.g., as defined in [4], [8] and [6] are otherwise followed. As defined in [5], the SUBSCRIBE message MAY contain a body. This body would serve the purpose of carrying filtering information. Honouring those filters is at the discretion of the notifier and might depend on local policies. 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 the NOTIFY requests using the notifier's own or service specific policy. Note that e.g. in the list case [6] the filter might have been uploaded to the server beforehand (by means outside the scope of this document). If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'. 3.3.1 Structure of a Filter Multiple filters MAY be included in one SUBSCRIBE. This is achieved by including multiple elements in the filter [9]. Each element may include a URI attribute. A SUBSCRIBE request destined to a list URI [6] MAY include multiple filters specific to individual resources. This is achieved by including multiple elements with different URIs of resources in each of those elements. This resource specific filter overrides any list specific filter, if any. The list specific filter may or may not include a URI. Khartabil, et al. Expires August 3, 2004 [Page 4] Internet-Draft Functional Description of Filtering February 2004 3.3.2 Request-URI vs. Filter URI The URI in the filter defines the target resource, e.g. in the Presence service case; it is the presentity's presence information to which the filter is applied. The subscriber MAY choose to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI. Similarly, the subscriber MAY define a filter URI. If the Request-URI is a list URI [6], the filter URI MUST be the list URI, a sub-list URI or resource who's URI is one of the URIs that result from a lookup, by an RLS, on the Request-URI. If not, the filter may be ignored or may be rejected. The URI in the filter may also carry a domain. In this case, the filter applies to resources in that domain. This can be used when a subscription is for a resource that is an event list with many resources from differing domains. 3.3.3 Changing Filters within a Dialog The client MAY reset or change the filter by re-issuing a new SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the exiting dialog that does not contain a filter is assumed to maintain existing filters. This means that filters are persistent and are only explicitly removed. A client requiring removal of a filter may do so by using the 'removed="true"' attribute as defined in [9]. In the case the URI in the filter is that of a list, a client may override the existing filter with a filter for an individual resource, that is part of the list subscribed to earlier, by issuing a new SUBSCRIBE within the existing dialog and including a filter specific for that individual resource. The new filter need not include the original filter since a filter is only removed in the manner indicated above. 3.3.4 Subscriber Interpreting SIP responses The SUBSCRIBE request will be confirmed with a final response. 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 and 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 acceptance of the filter MAY arrive in a subsequent NOTIFY. Khartabil, et al. Expires August 3, 2004 [Page 5] A 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 final responses have the same meanings and handling as described in [3] and [5]. Specifically, a "415" response indicates that the MIME type 'application/simple-filter+xml' is not understood by the notifier. A "488" response indicates that the content type (filter) is understood but some aspects of it were either not understood or not accepted. 3.4 Subscriber Processing of NOTIFY Requests If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that follows MAY contain a body that describes the present state of the resource after the filters have been applied. If the NOTIFY indicates that a subscription has been terminated [5], the subscription is assumed to be terminated. Behaviour in such events is also described in [5]. If the subscription is indicated as active, NOTIFY requests are handled as described in package specific documents and [5]. 4. Resource List Server Behaviour The Resource List Server is defined in [6]. This section describes how such entity behaves in the presence of a filter in a subscription to a list. 4.1 Request-URI vs. Filter URI If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI. If no URI is indicated by the filter, the filter applies to all the notifications that the RLS issues. If the URI indicated by the filter is a list URI, the filter applies to all the notifications that the RLS issues. If the URI indicated by the filter is for one resource who's URI is one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter for that particular resource is extracted and propagated in the SUBSCRIBE request sent to that resource. (It is possible to have more than one filter in a SUBSCRIBE body, and therefore a filter specific to a resource MUST be extracted and only that is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where "bob@otherdomain.com" is a resource belonging to that list, and the URI in a filter is "sip:bob@otherdomain.com", the filter specific for Bob are extracted and placed in the body of the SUBSCRIBE sent to Khartabil, et al. Expires August 3, 2004 [Page 6] Internet-Draft Functional Description of Filtering February 2004 "bob@otherdomain.com"). If the URI indicated by the filter is for one resource who's URI is NOT one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter is propagated to all the fanned out subscriptions. This is to accommodate the scenario where the subscriber knows that there are sub-lists in the event list that the original subscription was sent to, and the subscriber wishes to set a filter for a resource in that sub-list. The URI in the filter may carry a domain. In this case, the filter applies to resources in that domain. The RLS MUST NOT apply filters to any notifications it sends, but instead MUST forward the filter with all fanned out subscriptions to the notifiers. 5. Server Operation 5.1 NOTIFY Bodies SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml'. 5.2 Notifier Processing SUBSCRIBE Requests This section presents addition functionality required from the notifier when filters are used in the bodies of the SUBSCRIBE requests. Normal package specific functionality are otherwise followed. The notifier will examine the content type header and will return a 415 response if it does not understand the content type 'application/ simple-filter+xml'. A 200-class responses indicate that the subscription has been accepted, and the NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted, the user is authorized and the filter is accepted. A "202" response merely indicates that the subscription has been understood, but the authorization may or may not have been granted. A "202" response also indicates that the filters have not been accepted yet. The acceptance of the filters MAY arrive in a subsequent NOTIFY. Procedures described in section Section 5.4 are followed if an error is encountered. 5.2.1 Request-URI vs. Filter URI The subscriber may have chosen to leave the URI in the filter Khartabil, et al. Expires August 3, 2004 [Page 7] Internet-Draft Functional Description of Filtering February 2004 undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI. Similarly, the subscriber may have chosen to include a URI in the filter. In this case, the filter applies to all notifications send for this subscription. If the Request-URI and the URI in the filter mismatch, the filter may be ignored or may be rejected. The URI in the filter may carry a domain. In this case, the filter applies to resources in that domain. The notifier MUST NOT apply filters to any notifications it sends if the domain is not that of its own, and MUST ignore it. Notifiers belonging to domain MUST apply the filter to all notifications sent, unless policy dictates otherwise. 5.3 Notifier Generating NOTIFY Requests Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD retain the filter as long as the subscription persists. The filter MAY be incorporated within an existing subscription (in an active dialog) by sending a re-SUBSCRIBE that includes the filter in the body. If the response sent to the SUBSCRIBE was the 202 and the 202 was chosen because the filter could not be accepted that time, the NOTIFY MAY be used to terminate the subscription if the filter was found unacceptable. As described in [5], the NOTIFY message MAY contain a body that describes the state of the resource. This body is in one of the formats listed in the Accept header of the SUBSCRIBE, or the package specific default if the Accept header is omitted. 5.3.1 Generation of NOTIFY Contents If the NOTIFY being sent is the immediate one sent after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter. If applying the filter results in not sending a NOTIFY, the NOTIFY MUST be sent with empty contents. A notifier may also choose not to obey the filter in the first NOTIFY and instead send the configured value authorised for that subscriber set by the notifier using means outside the scope of this document). The input to the content filter is a package specific XML document, e.g. [2] and [7] derived according to the package specific specifications, ([4] and [8]). The content is filtered according to the expressions in the Khartabil, et al. Expires August 3, 2004 [Page 8] Internet-Draft Functional Description of Filtering February 2004 element of the filter. The expression indicates the delivered XML elements and/or attributes. Prefixes of the namespaces of the items of the XML document to be filtered must be expanded before applying the filter to the items. The expression directly states the XML elements and attributes to be delivered in the NOTIFY, along with their values. In addition to the selected contents also the namespaces of all the selected items are included in the NOTIFY. The XML elements and/or attributes indicated by the expression in the element must be items that the subscriber is authorised to see. If not, the notifier policy dictates the behaviour of the notifier (notifier can either ignore the filter, parts of the filter, or reject the filter completely). Implementers need to carefully consider such an implementation decision; the subscriber may not be aware of the authorised contents and therefore most likely will include a filter requesting unauthorised contents. It is therefore RECOMMENDED that notifiers just ignores the parts of the filter where it is requesting unauthorised info. I.e. The filter in the element where the unauthorised contents are requested is ignored. If polite blocking is used by the notifier, the notifier may choose to ignore the filter, by choosing to deliver notifications containing bogus information in the unauthorised elements or attributes. The resultant XML document MUST be well formed and valid according to the XML schema. This means that all mandatory elements and attributes along with their values MUST be included in the XML document regardless of the expression. In other words, if the results of applying a filter on an XML document is a non-valid XML document, the notifier MUST add elements and attributes, along with their values, from the original XML document into the newly formulated one in order for it to be a valid one. This situation can occur if the notifier did not closely examine the filter before accepting it 5.3.2 Handling of Notification Triggering Rules There can be several elements inside one element. If the criteria for any of the elements are satisfied, a NOTIFY SHOULD be generated. The items (XML elements and/or attributes) indicated by the expression in the element, element or element must be items that the subscriber is authorised to access. If not, the notifier policy dictates the behaviour of the notifier (notifier can either ignore the filter, parts of the filter, or reject the filter completely). Khartabil, et al. Expires August 3, 2004 [Page 9] Internet-Draft Functional Description of Filtering February 2004 5.4 Handling Abnormal Cases In case of an invalid filter definition where the XML document of the filter is not aligned with the XML schema of the filter format[9], the notifier rejects the SUBSCRIBE request with a "488" response. A warning header in the response may give better indication why the filters were not accepted. If the subscription was accepted with a "202" response but the invalid filter was discovered after that, a NOTIFY with a subscription-state of value 'terminated' is sent. An event-reason-value "badfilter", introduced here, of subexp-params [5] MAY be included. In case of an erroneous expression in the filter definition the notifier either ignores the filter definition or terminates the subscription. If a or element is empty, the notifier proceeds as if the element did not exist. 6. IANA Considerations A new event-reason-value "badfilter" is defined to represent the event where the filter is not well formed and/or not accepted. OPEN ISSUE: IANA registration template must be added later. [13] 7. Examples The following chapters include filtering examples for Presence and Watcher Information. The format of filter is according to [9]. 7.1 Presence Specific Examples This chapter describes three use cases where the presence information filtering solution is utilised [4]. In the first use case the watcher is interested in getting messaging specific information of a certain presentity. In the second use case the watcher is interested in getting information about the communication means and contact addresses the presentity is currently available for communication on. The third case shows how a presentity can request triggers to receive notifications Below is the Presentity's presence information in PIDF [2]. It includes two tuples: one for the instant messaging and another for the voice related information. Khartabil, et al. Expires August 3, 2004 [Page 10] Internet-Draft Functional Description of Filtering February 2004 closed im im:presentity@domain.com open voice tel:2224055555@domain.com 7.1.1 Subscriber Requests Messaging Related Information The subscriber initiates a subscription to the presentity's messaging (MMS, IM and SMS) related presence information. The subscription includes the content limiting filter. The filtered content is indicated with an expression. This expression selects the element and all the parent elements (this means the status, tuple and its root element), the element and the element. The filter is: elements that have values beginning with "MMS", "SMS" or "IM". In this case, the notification includes the contents of the tuple that has the value "IM" in its