Functional Description of Event Notification Filtering
updated by
- rfc-6665 — SIP-Specific Event Notification
Extracted elements (30)
Filtering is expected to be particularly valuable for mobile wireless devices with high latency, low bandwidth, limited processing, small displays, and limited battery power, as it reduces the amount of information generated at the event notification source. However, implementers must be aware of the computational burden placed on the notifier.
It is RECOMMENDED that notifiers ignore (rather than reject) parts of a filter requesting unauthorized content, because subscribers may not know what they are authorized to see and will inadvertently request unauthorized items. Polite blocking (delivering bogus info and then filtering) is offered as an alternative.
Resource-specific filters take precedence over domain-specific or list-specific filters in a SUBSCRIBE. If an individual resource-specific filter is present alongside a domain filter, the resource-specific filter overrides the domain-specific filter.
When an RLS receives a filter addressed to a resource not under its administrative control, the filter is propagated to all fanned-out subscriptions to accommodate sub-lists in foreign administrative domains.
A notifier MUST ignore any filter using a 'domain' attribute for a domain it is not responsible for, and MUST NOT apply such a filter to any notification it sends.
A server MUST check that there are no filters addressed to the same resource or domain in a SUBSCRIBE request; if there are duplicates, it MUST reject the request with a '488' error response.
An RLS MUST check for duplicate filters addressed to the same resource or domain in a SUBSCRIBE; if found, it MUST reject the request with a '488' error response.
Each filter within a subscription MUST uniquely identify one resource or one domain; there can only be one filter applicable to a single resource or domain within a single SUBSCRIBE.
For a domain-addressed filter, the RLS MUST NOT apply filters to any notifications it sends; instead it MUST forward the filter with all fanned-out subscriptions to the notifiers.
If any of the <trigger> element criteria are satisfied, a NOTIFY SHOULD be generated.
If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'.
If the NOTIFY is the one sent immediately after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter <what> element; if applying the filter results in no content, the NOTIFY MUST be sent with empty contents.
If the Request-URI is a list URI, the filter URI MUST be the list URI, a sub-list URI, or a resource URI that results from RLS lookup on the Request-URI; otherwise the filter may be ignored or rejected.
SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml' in NOTIFY bodies.
The resultant XML document in a NOTIFY MUST be well formed and valid; all mandatory elements and attributes MUST be included regardless of filter expressions, so if filtering produces an invalid document, the notifier MUST add required elements from the original.
The subscriber MUST ensure that the XML document inserted as the SUBSCRIBE body is well formed and valid, and MUST NOT insert extension elements or attributes unless it has access to the extension schema.
Upon receiving a SUBSCRIBE with a filter, the notifier SHOULD retain the filter as long as the subscription persists.
A filter can be enabled or disabled using the 'enabled' attribute on the <filter> element. When disabled ('enabled'='false'), the filter is treated as absent; re-enabling causes the notifier to behave as if the filter was just placed.
A filter consists of optional <what> and <trigger> elements within a <filter> element. A <what>-only filter limits notification content; a <trigger>-only filter controls when notifications are sent; both together restrict both content and send conditions.
A filter is explicitly removed by using the 'remove="true"' attribute as defined in RFC 4661. A SUBSCRIBE refresh with no filter body maintains existing filters; they are persistent within a dialog.
Filtering rules are transported by inserting an XML document (per RFC 4661) in the body of a SUBSCRIBE request. The filter body uses MIME type 'application/simple-filter+xml' and may contain multiple <filter> elements, each optionally carrying a 'uri' or 'domain' attribute to identify the target resource.
Filters are identified by a filter ID. A filter is replaced by reissuing it with the same filter ID; changing the filter ID while keeping the resource URI is an error causing the server to assume two filters for the same resource.
The event-reason-value 'badfilter' is introduced to indicate subscription termination due to a filter that is not well formed and/or not accepted. It may be included in the subexp-params of a NOTIFY with subscription-state 'terminated'.
A filtered document at a subscriber may project false reality. For example, a subscriber notified only when status changes to 'open' (not back to 'closed') may believe the resource is 'open' indefinitely. Subscribers must understand what they asked for and be prepared to be out of sync with real resource state.
Filter processing (set operations and searches) enables a DoS attack via large numbers of messages with substantial filter content. Servers SHOULD limit the number of <what>, <changed>, <added>, and <removed> elements; a default limit of 40 is RECOMMENDED.
Messages containing filter bodies MUST be authenticated and authorized; Digest Authentication (RFC 3261) is recommended. The authorization decision is based on permissions granted by the notifier (resource) to the subscriber.
Propagating filters in SUBSCRIBE requests to foreign domains reveals sensitive information about a user's resource lists. An RLS MUST NOT forward a filter addressed to a resource under its administrative domain that is not on the resource list.
Requests can reveal sensitive UA capability information and SHOULD be encrypted using SIP S/MIME if that information is sensitive. All package-specific security measures MUST be followed.
Notifier filter lifecycle: filter is retained while subscription persists; if a '202' was sent because the filter could not be accepted at that time, the NOTIFY MAY terminate the subscription if the filter is ultimately found unacceptable, sending a NOTIFY with subscription-state 'terminated'.
Subscriber response handling: a '200' response means the subscription and filter are accepted; a '202' means the subscription is understood but filter acceptance is pending (MAY arrive in a subsequent NOTIFY); a '415' means the MIME type was not understood; a '488' means the filter content was not accepted.