📄 rfc4660 functional description of event notification filtering.txt
字号:
Network Working Group H. Khartabil
Request for Comments: 4660 Telio
Category: Standards Track E. Leppanen
M. Lonnfors
J. Costa-Requena
Nokia
September 2006
Functional Description of Event Notification Filtering
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The SIP event notification framework describes the usage of the
Session Initiation Protocol (SIP) for subscriptions and notifications
of changes to the state of a resource. The document does not
describe a mechanism whereby filtering of event notification
information can be achieved.
This document describes the operations a subscriber performs in order
to put filtering rules associated with a subscription to event
notification information in place. The handling, by the subscriber,
of responses to subscriptions carrying filtering rules and the
handling of notifications with filtering rules applied to them are
also described. Furthermore, the document conveys how the notifier
behaves when receiving such filtering rules and how a notification is
constructed.
Khartabil, et al. Standards Track [Page 1]
RFC 4660 Functional Description of Filtering September 2006
Table of Contents
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Client Operation ................................................4
3.1. Transport Mechanism ........................................4
3.2. SUBSCRIBE Bodies ...........................................4
3.3. Subscriber Generating of SUBSCRIBE Requests ................4
3.3.1. Defining the Filtering Rules ........................4
3.3.2. Request-URI vs. Filter URI ..........................5
3.3.3. Changing Filters within a Dialog ....................5
3.3.4. Subscriber Interpreting of SIP Responses ............6
3.4. Subscriber Processing of NOTIFY Requests ...................6
4. Resource List Server Behaviour ..................................7
4.1. Request-URI vs. Filter URI .................................7
4.2. Changing Filters within a Dialog ...........................9
5. Server Operation ................................................9
5.1. NOTIFY Bodies ..............................................9
5.2. Notifier Processing of SUBSCRIBE Requests ..................9
5.2.1. Request-URI vs. Filter URI .........................10
5.2.2. Changing Filters within a Dialog ...................11
5.3. Notifier Generating of NOTIFY Requests ....................11
5.3.1. Generation of NOTIFY Contents ......................12
5.3.2. Handling of Notification Triggering Rules ..........13
5.4. Handling Abnormal Cases ...................................13
6. XML Document Validation ........................................14
7. Examples .......................................................14
7.1. Presence Specific Examples ................................14
7.1.1. Subscriber Requests Messaging-Related Information ..15
7.1.2. Subscriber Fetches Information about "Open"
Communication Means ................................16
7.1.3. Subscriber Requests Notifications When
Presentity's Status Changes ........................18
7.2. Watcher Information Specific Examples .....................21
7.2.1. Watcher Subscriber Makes Subscription to
Get All the Information about Active Watchers ......22
7.2.2. Watcher Subscriber Requests Information of
Watchers with Specific Subscription Duration
Conditions .........................................23
7.2.3. Watcher Subscriber Requests Specific
Watcher Info on Specific Triggers ..................24
8. Security Considerations ........................................27
9. IANA Considerations ............................................28
10. Acknowledgements ..............................................28
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................28
Khartabil, et al. Standards Track [Page 2]
RFC 4660 Functional Description of Filtering September 2006
1. Introduction
SIP event notification is described in [3]. 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. 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. However,
implementers need to be aware of the computational burden on the
source of the event notification. This is discussed further in
Section 8.
It is stated in [3] 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.
This document, together with [5], 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 [5].
2. 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.
"Content" refers to the XML document that appears in a notification
reflecting the state of a resource.
Khartabil, et al. Standards Track [Page 3]
RFC 4660 Functional Description of Filtering September 2006
3. Client Operation
3.1. Transport Mechanism
Transportation of the filter to the server is achieved by inserting
the XML document, as defined in [5], 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 of 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 [8],
[10], and [4]) are otherwise followed.
As defined in [3], the SUBSCRIBE message MAY contain a body. This
body would carry 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 the notifier is instructed to send
all the NOTIFY requests using the notifier's own or service-specific
policy. Note that, for example, in the list case [4], 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. Defining the Filtering Rules
Multiple filters MAY be included in one SUBSCRIBE. This is achieved
by including multiple <filter> elements in the filter [5]. Each
<filter> element may include a 'uri' attribute.
A SUBSCRIBE request destined to a list URI [4] MAY include multiple
filters specific to individual resources. This is achieved by
including multiple <filter> elements with different URIs of resources
in each of those elements. This resource specific resource-specific
filter are processed first before any list specific list-specific
filter, if any. The list specific list-specific filter may or may
not include a URI.
Khartabil, et al. Standards Track [Page 4]
RFC 4660 Functional Description of Filtering September 2006
Furthermore, regardless of whether the SUBSCRIBE is destined to a
list URI, there can only be one filter applicable to a single
resource or domain within a single SUBSCRIBE. That is, each filter
within a subscription MUST uniquely identify one resource or one
domain.
A filter can be enabled and disabled using the 'enabled' attribute in
the <filter> element, as described in [5].
3.3.2. Request-URI vs. Filter URI
The URI in the filter defines the target resource. For example, 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 [4], the filter URI
MUST be the list URI, a sub-list URI, or resource whose URI is one of
the URIs that result from a lookup, by a Resource List Server (RLS),
on the Request-URI. If it is not, the filter may be ignored or may
be rejected. URI matching is done according to the matching rules
defined for a particular scheme (SIP URI matching rules are defined
in RFC 3261 [2]).
A filter may also be addressed to a domain using the 'domain'
attribute instead of the 'uri' attribute. 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. If an individual resource-specific
filter is present along with the domain filter, this
resource-specific filter overrides any domain-specific filter, if
any.
3.3.3. Changing Filters within a Dialog
The subscriber 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 within a
dialog and are only explicitly removed.
A subscriber requiring removal of a filter may do so by using the
'remove="true"' attribute, as defined in [5].
In the case where the URI in the filter is that of a list, a
subscriber may override the existing filter with a filter for an
individual resource that is part of the list subscribed to earlier by
Khartabil, et al. Standards Track [Page 5]
RFC 4660 Functional Description of Filtering September 2006
issuing a new SUBSCRIBE within the existing dialog and including a
filter, specific for that individual resource, using a new filter ID.
The new filter need not include the original filter since a filter is
only removed in the manner indicated above.
A filter is replaced by the subscriber re-issuing the filter using
the same filter ID and replacing the contents of the filter.
Replacing a filter by changing the filter ID and keeping the resource
URI is considered an error since this causes the server to assume
that two filters are placed for the same resource.
Again, a filter can be disabled and re-enabled using the 'enabled'
attribute in the <filter> element, as described in [5].
3.3.4. Subscriber Interpreting of SIP Responses
The SUBSCRIBE request will be confirmed with a final response. A
200-class response indicates 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 that the filter
is accepted. A "202" response merely indicates that the subscription
has been understood, that 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.
A non-200 class final response indicates 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 [2] and [3].
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 [3],
the subscription is assumed to be terminated. Behaviour in such
events is also described in [3].
If the subscription is indicated as active, NOTIFY requests are
handled as described in package-specific documents and in [3].
Khartabil, et al. Standards Track [Page 6]
RFC 4660 Functional Description of Filtering September 2006
4. Resource List Server Behaviour
The Resource List Server is defined in [4]. This section describes
how such an entity behaves in the presence of a filter in a
subscription to a list.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -