Network Working Group H. Khartabil
Request for Comments: 4660 Telio
Category: Standards Track E. Leppanen
M. Lonnfors
J. Costa-Requena
Nokia
September 2006
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
SIP事件通知框架描述会话启动协议（SIP）用于订阅和通知资源状态的更改。本文件未描述可实现事件通知信息过滤的机制。
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.
本文档描述订阅服务器执行的操作，以便将与事件通知信息订阅相关联的筛选规则放置到位。还描述了订阅者对带有过滤规则的订阅的响应的处理以及对应用了过滤规则的通知的处理。此外，文档还传达了通知程序在接收此类过滤规则时的行为以及通知的构造方式。
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
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
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.
事件[3]在SIP通知中描述。它定义了一个通用框架，用于在基于SIP的系统中发送订阅和接收通知。它介绍了事件包的概念，事件包是通用事件框架对事件特定用法的具体应用。
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.
过滤是一种控制事件通知内容的机制。此外，订户可以指定何时向其发送通知的规则。预计该过滤机制对移动无线接入设备的用户特别有价值。设备的特征通常包括高延迟、低带宽、低数据处理能力、小显示和有限的电池电量。此类设备可以从过滤事件通知源生成的信息量的能力中获益。然而，实现者需要知道事件通知源的计算负担。这将在第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.
[3]中指出，通知程序可随时发送通知，但通常在资源状态发生变化时发送通知。它还声明通知将包含授权给特定订阅者查看的资源的完整和当前状态。此类资源状态信息的格式是特定于包的。在本备忘录中，我们假设任何包的NOTIFY都包含一个XML文档。
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.
本文档与[5]一起提供了一种过滤机制，订阅者通过该机制描述了其对何时向其发送通知以及通知内容的偏好。它还描述了通过考虑包/服务的过滤器和默认功能来生成通知时通知程序的工作方式。
The XML format for defining the filter is described in [5].
定义过滤器的XML格式如[5]所述。
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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可能”和“可选”将按照RFC 2119[1]中的描述进行解释，并指明符合性实施的要求级别。
"Content" refers to the XML document that appears in a notification reflecting the state of a resource.
“内容”是指出现在通知中反映资源状态的XML文档。
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.
将过滤器传输到服务器是通过将XML文档（如[5]中所定义）插入订阅请求的主体来实现的。或者，可以使用本文档范围之外的方法将XML文档上载到服务器。
SIP entities compliant with this specification MUST support the content type 'application/simple-filter+xml'.
符合此规范的SIP实体必须支持内容类型“application/simple filter+xml”。
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.
本节介绍在订阅请求主体中使用筛选器时订阅方所需的其他功能。服务的正常操作（例如，如[8]、[10]和[4]中所定义的）以其他方式进行。
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.
如[3]中所定义，订阅消息可能包含正文。该机构将携带过滤信息。遵守这些过滤器由通知者自行决定，可能取决于当地政策。
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).
订阅主体中没有任何内容向通知程序指示未请求任何筛选器，因此通知程序被指示使用通知程序自己的或特定于服务的策略发送所有通知请求。请注意，例如，在列表案例[4]中，筛选器可能已事先上载到服务器（通过本文档范围之外的方式）。
If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'.
如果订阅的主体包括筛选器，则主体必须是MIME类型“application/simple filter+xml”。
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.
一个订阅中可以包括多个筛选器。这是通过在过滤器[5]中包含多个<filter>元素来实现的。每个<filter>元素可能包含一个“uri”属性。
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.
目的地为列表URI[4]的订阅请求可以包括特定于单个资源的多个过滤器。这是通过在每个元素中包含具有不同资源URI的多个<filter>元素来实现的。在任何特定于列表的筛选器（如果有）之前，首先处理此特定于资源的筛选器。特定于列表的筛选器可能包括也可能不包括URI。
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.
此外，无论订阅是否以列表URI为目的地，在单个订阅中只能有一个筛选器适用于单个资源或域。也就是说，订阅中的每个筛选器必须唯一标识一个资源或一个域。
A filter can be enabled and disabled using the 'enabled' attribute in the <filter> element, as described in [5].
可以使用<filter>元素中的“enabled”属性启用和禁用过滤器，如[5]中所述。
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]).
筛选器中的URI定义了目标资源。例如，在存在服务情况下，应用过滤器的是存在实体的存在信息。订阅者可以选择将筛选器中的URI保留为未定义。如果未在筛选器中定义URI，则筛选器将应用于请求URI中标识的资源。类似地，订户可以定义过滤器URI。如果请求URI是列表URI[4]，则筛选器URI必须是列表URI、子列表URI或其URI是资源列表服务器（RLS）对请求URI进行查找后产生的URI之一的资源。如果不是，则过滤器可能会被忽略或被拒绝。URI匹配是根据为特定方案定义的匹配规则进行的（SIP URI匹配规则在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.
也可以使用“域”属性而不是“uri”属性将筛选器寻址到域。在这种情况下，筛选器将应用于该域中的资源。当订阅针对的资源是一个包含来自不同域的许多资源的事件列表时，可以使用此选项。如果单个特定于资源的筛选器与域筛选器一起存在，则此特定于资源的筛选器将覆盖任何特定于域的筛选器（如果有）。
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].
要求删除筛选器的订阅服务器可以使用[5]中定义的“remove=“true”属性来删除筛选器。
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
在筛选器中的URI是列表的URI的情况下，订阅者可以使用单个资源的筛选器覆盖现有筛选器，该资源是先前订阅者订阅的列表的一部分
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.
在现有对话框中发出新的订阅，并使用新的筛选器ID包含特定于该单个资源的筛选器。新筛选器不需要包含原始筛选器，因为筛选器仅以上述方式移除。
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.
订阅服务器使用相同的筛选器ID重新发布筛选器并替换筛选器内容，从而替换筛选器。通过更改筛选器ID并保留资源URI来替换筛选器被视为错误，因为这会导致服务器假定为同一资源放置了两个筛选器。
Again, a filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
同样，可以使用<filter>元素中的“enabled”属性禁用和重新启用过滤器，如[5]中所述。
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.
订阅请求将得到最终响应的确认。200类响应表示订阅已被接受，并将立即发送通知。“200”响应表示订阅已被接受，并且筛选器已被接受。“202”响应仅表示订阅已被理解，内容类型已被接受，授权可能已被授予，也可能未被授予。“202”响应还表示过滤器尚未被接受。过滤器的验收可能在随后的通知中到达。
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].
非200类最终响应表示尚未创建订阅或对话框，并且不会发送后续通知消息。所有非200类最终回答的含义和处理方式与[2]和[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.
具体地，“415”响应指示通知程序不理解MIME类型“application/simple filter+xml”。“488”响应表示内容类型（筛选器）已被理解，但其某些方面未被理解或未被接受。
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.
如果为订阅返回了2xx响应，则下面的通知可能包含一个正文，描述应用筛选器后资源的当前状态。
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].
如果通知指示订阅已终止[3]，则假定订阅已终止。[3]中还描述了此类事件中的行为。
If the subscription is indicated as active, NOTIFY requests are handled as described in package-specific documents and in [3].
如果订阅指示为活动，则按照包特定文档和[3]中的说明处理通知请求。
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.
[4]中定义了资源列表服务器。本节描述了此类实体在列表订阅中存在筛选器时的行为。
If the URI is not defined within the filter, the filter applies to the resource list identified in the Request-URI of the SUBSCRIBE request. This results in the filters being applied to all the notifications that the RLS issues to this subscription. The same processing applies to a filter that defines a URI that matches the request-URI of the SUBSCRIBE request. That is, the filter applies to all notifications that the RLS issues to this subscription.
如果未在筛选器中定义URI，则筛选器将应用于订阅请求的请求URI中标识的资源列表。这将导致筛选器应用于RLS向该订阅发出的所有通知。相同的处理适用于定义与订阅请求的请求URI匹配的URI的筛选器。也就是说，筛选器应用于RLS向该订阅发出的所有通知。
If the URI indicated by the filter is for one resource whose 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 request body, and therefore a filter specific to a resource MUST be extracted and only that one is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@example.com", where "bob@example.com" is a resource belonging to that list, and the URI in a filter is "sip:bob@example.com", the filter specific for Bob is extracted and placed in the body of the SUBSCRIBE sent to "bob@example.com".
如果筛选器指示的URI用于一个资源，该资源的URI是RLS对请求URI进行查找后产生的URI之一，则在发送到该资源的订阅请求中提取并传播该特定资源的筛选器。订阅请求主体中可能有多个筛选器，因此必须提取特定于资源的筛选器，并且只传播该筛选器。例如，如果订阅中的请求URI的值为“sip:mybuddies@example.com“，其中”bob@example.com是属于该列表的资源，筛选器中的URI是“sip:bob@example.com，将提取特定于Bob的筛选器，并将其放置在发送到的订阅的主体中bob@example.com".
If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter 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 are under a different administrative domain from that where the original subscription was sent, and the subscriber wishes to set a filter for a resource in that sub-list.
如果筛选器所指示的URI用于其URI不受RLS管理控制的一个资源，则RLS将筛选器传播到所有扇出订阅。这是为了适应这样的场景：订阅者知道事件列表中有子列表与发送原始订阅的子列表位于不同的管理域下，并且订阅者希望为该子列表中的资源设置筛选器。
If the URI indicated by the filter is for one resource whose URI is under the RLS administrative control but is not part of the resource list that the subscription was addressed to, the filter is not propagated. In this case, it is the RLS's responsibility to make sure that this filter is applied to notifications issued, if information about that resource is present.
如果筛选器指示的URI用于一个资源，该资源的URI受RLS管理控制，但不属于订阅寻址到的资源列表的一部分，则不会传播筛选器。在这种情况下，如果存在关于该资源的信息，则RLS负责确保将此筛选器应用于发出的通知。
For example: If we have 2 lists, each located on its own RLS:
例如：如果我们有两个列表，每个列表位于各自的RLS上：
List1 (list1@example.com) on RLS1 has: bob@example.com
List1 (list1@example.com) on RLS1 has: bob@example.com
list2@biloxi.com
list2@biloxi.com
List2 on RLS2 has: alice@biloxi.com sarah@example.com
(Note: list2 is a resource in list1)
List2 on RLS2 has: alice@biloxi.com sarah@example.com
(Note: list2 is a resource in list1)
RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is addressed to list1 and contains 2 filters: one for sarah@example.com and the other for alice@biloxi.com):
RLS1接收以下订阅请求（订阅地址为list1，包含2个筛选器：一个用于sarah@example.com另一个是给你的alice@biloxi.com):
SUBSCRIBE sip:List1@example.com SIP/2.0
...
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="999" uri="sip:sarah@example.com">
<what>
<include type="namespace">
urn:ietf:params:xml:ns:pidf</include>
<exclude>
//pidf:tuple/pidf:note</exclude>
</what>
</filter>
<filter id="8439" uri="sip:alice@biloxi.com">
<what>
<include>
//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
SUBSCRIBE sip:List1@example.com SIP/2.0
...
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="999" uri="sip:sarah@example.com">
<what>
<include type="namespace">
urn:ietf:params:xml:ns:pidf</include>
<exclude>
//pidf:tuple/pidf:note</exclude>
</what>
</filter>
<filter id="8439" uri="sip:alice@biloxi.com">
<what>
<include>
//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
RLS1 fans out subscriptions to resources on list1. The text above suggests that if a filter is destined to a resource that is not part of the list and is outside the administrative domain of an RLS, then that filter is propagated. The rest are consumed. In our example, only the filter to alice@biloxi.com is propagated since biloxi.com is not under the administrative domain of RLS1. The filter to sarah@example.com is consumed, and RLS1 needs to apply that filter to notifications it receives.
RLS1扇出对列表1上资源的订阅。上面的文本表明，如果某个筛选器的目的地不是列表的一部分，并且在RLS的管理域之外，则该筛选器将被传播。其余的都被消耗掉了。在我们的示例中，只有过滤器alice@biloxi.com由于biloxi.com不在RLS1的管理域下，因此被传播。过滤到sarah@example.com已使用，RLS1需要将该筛选器应用于它接收的通知。
URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
URI匹配是根据为特定方案定义的匹配规则进行的（SIP URI匹配规则在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, and 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.
也可以使用“域”属性而不是“uri”属性将筛选器寻址到域。在这种情况下，筛选器应用于该域中的资源，并且RLS不得将筛选器应用于其发送的任何通知。相反，它必须将包含所有扇出订阅的筛选器转发给通知程序。
As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, an RLS MUST check that there are no filters addressed to the same resource or domain, and if there are, it MUST reject the SUBSCRIBE request with a "488" error response.
如第3.3.1节所述，订阅请求中可以存在多个筛选器。也可以按照第3.3.3节的说明添加或修改过滤器。在这种情况下，RLS必须检查是否没有针对同一资源或域的筛选器，如果有，则必须以“488”错误响应拒绝订阅请求。
If an RLS receives a subscription refresh request with no filters specified (empty payload), the RLS assumes that the client does not wish to update the filters. If an RLS receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the RLS assumes that the client is removing that filter identified by the filter ID.
如果RLS接收到未指定筛选器（空负载）的订阅刷新请求，则RLS假定客户端不希望更新筛选器。如果RLS接收到订阅刷新，其中筛选器包含[5]中定义的“remove=“true”属性，则RLS假定客户端正在删除由筛选器ID标识的筛选器。
If an RLS receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), the RLS interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the RLS to assume that two filters are in place for the same resource.
如果RLS接收到订阅刷新请求，且该请求中的筛选器已经存在（即，具有相同的筛选器ID），则RLS将其解释为现有筛选器的替换。通过更改筛选器ID并保留资源URI来替换筛选器被视为错误，因为这会导致RLS假定同一资源有两个筛选器。
A filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
可以使用<filter>元素中的“enabled”属性禁用和重新启用筛选器，如[5]中所述。
SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml'.
符合此规范的SIP实体必须支持内容类型“应用程序/简单筛选器+xml”。
This section presents additional functionality required from the notifier when filters are used in the bodies of the SUBSCRIBE requests. Normal package-specific functionality is otherwise followed.
本节介绍在订阅请求主体中使用筛选器时通知程序所需的其他功能。否则将遵循正常的包特定功能。
The notifier will examine the Content-Type header field and will return a 415 response if it does not understand the content type 'application/simple-filter+xml'.
通知程序将检查内容类型标头字段，如果不理解内容类型“应用程序/简单筛选器+xml”，则将返回415响应。
A 200-class response indicates 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 that 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.
200类响应表示订阅已被接受，通知将立即发送。“200”响应表示订阅已被接受，用户已被授权，并且筛选器已被接受。“202”响应仅表示订阅已被理解，但授权可能已被授予，也可能未被授予。“202”响应还表示尚未接受过滤器。过滤器验收可能会在随后的通知中到达。
Procedures described in Section 5.4 are followed if an error is encountered.
如果遇到错误，则遵循第5.4节中描述的程序。
As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, a server MUST check that there are no filters addressed to the same resource or domain, and if they are, it MUST reject the SUBSCRIBE request with a "488" error response.
如第3.3.1节所述，订阅请求中可以存在多个筛选器。也可以按照第3.3.3节的说明添加或修改过滤器。在这种情况下，服务器必须检查是否没有针对同一资源或域的筛选器，如果有，则必须以“488”错误响应拒绝订阅请求。
The subscriber may have chosen 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.
订户可能已选择将筛选器中的URI保留为未定义。如果未在筛选器中定义URI，则筛选器将应用于请求URI中标识的资源。
Similarly, the subscriber may have chosen to include a URI in the filter. In this case, the filter applies to all notifications sent with content associated with the resource with that URI for this subscription. If the Request-URI and the URI in the filter do not match, the filter may be ignored or 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]).
类似地，订阅者可能已经选择在过滤器中包括URI。在这种情况下，筛选器将应用于所有发送的通知，这些通知包含与此订阅的具有该URI的资源相关联的内容。如果请求URI和筛选器中的URI不匹配，则可能会忽略或拒绝筛选器。URI匹配是根据为特定方案定义的匹配规则进行的（SIP URI匹配规则在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. A notifier MUST ignore any filter using a 'domain' attribute containing a domain for which this notifier is not responsible. The notifier MUST NOT apply such a filter to any notification it sends. Notifiers belonging to the domain MUST apply the filter to all notifications it sends for that subscription, unless policy dictates otherwise.
也可以使用“域”属性而不是“uri”属性将筛选器寻址到域。在这种情况下，筛选器将应用于该域中的资源。通知程序必须忽略使用“域”属性的任何筛选器，该属性包含该通知程序不负责的域。通知程序不得将此类筛选器应用于其发送的任何通知。除非策略另有规定，否则属于域的通知程序必须将筛选器应用于它为该订阅发送的所有通知。
If a server receives a subscription refresh request with no filters specified (empty payload), it assumes that the client does not wish to update the filters. If it receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the server assumes that the client is removing the filter identified by the filter ID.
如果服务器接收到未指定筛选器（空负载）的订阅刷新请求，则假定客户端不希望更新筛选器。如果服务器接收到订阅刷新，且筛选器包含[5]中定义的“remove=“true”属性，则服务器假定客户端正在删除由筛选器ID标识的筛选器。
If the server receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), it interprets it as a replacement of the existing 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.
如果服务器收到一个订阅刷新请求，其中包含一个已经存在的筛选器（即，具有相同的筛选器ID），它会将其解释为现有筛选器的替换。通过更改筛选器ID并保留资源URI来替换筛选器被视为错误，因为这会导致服务器假定为同一资源放置了两个筛选器。
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 a "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 is found unacceptable.
如果发送给订阅的响应是“202”，并且选择“202”是因为此时无法接受筛选器，则如果发现筛选器不可接受，则可以使用通知终止订阅。
As described in [3], 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 field of the SUBSCRIBE, or in the package-specific default if the Accept header field is omitted.
如[3]所述，NOTIFY消息可能包含描述资源状态的正文。此正文采用订阅的Accept header字段中列出的格式之一，如果省略Accept header字段，则采用特定于包的默认格式。
Based on the contents of a filter, the following processing occurs:
根据筛选器的内容，将进行以下处理：
o A filter with only a <what> element will result in sending the requested resource state information in that <what> element whenever there is a change in the resource state.
o 只有<what>元素的筛选器将导致在资源状态发生更改时，在该<what>元素中发送请求的资源状态信息。
o A filter with only a <trigger> element will result in sending all resource state information whenever there is a change in the resource state that matches the triggers.
o 只有<trigger>元素的筛选器将导致在与触发器匹配的资源状态发生更改时发送所有资源状态信息。
o A filter with <what> and <trigger> elements will result in sending the requested resource state information in that <what> element whenever there is a change in the resource state that matches the triggers.
o 带有<what>和<trigger>元素的筛选器将导致在与触发器匹配的资源状态发生更改时，在该<what>元素中发送请求的资源状态信息。
When a filter is disabled (by setting the 'enabled' attribute to "false"), it means the same thing as the absence of that filter. That is, all state and state changes are reported by issuing a notification to the subscriber (assuming there are no other filters).
当一个过滤器被禁用时（通过将“enabled”属性设置为“false”），它意味着与缺少该过滤器相同的事情。也就是说，所有状态和状态更改都是通过向订阅服务器发出通知来报告的（假设没有其他筛选器）。
When a filter is re-enabled (by setting the 'enabled' attribute to "true" or by omitting the 'enabled' attribute), the notifier behaves as if the filter has just been placed by the SUBSCRIBE request enabling it. Immediate NOTIFY rules, as stated in Section 5.3.1, apply.
当过滤器被重新启用时（通过将“enabled”属性设置为“true”或省略“enabled”属性），通知程序的行为就好像过滤器刚刚被启用它的订阅请求放置一样。如第5.3.1节所述，立即通知规则适用。
If the NOTIFY being sent is the one sent immediately after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter <what> element, unless the processing of the filters will take too long or the NOTIFY request is following a "202" response to the SUBSCRIBE request and is terminating the subscription. In the case that the filter is taking too long to process, the NOTIFY request being sent may be empty or may be populated with a pre-configured value as authorised to that subscriber. If applying the filter results in no content to be delivered, the NOTIFY MUST be sent with empty contents. If the filter contains <trigger> elements, the notifier ignores the trigger values when generating the first NOTIFY request.
如果要发送的通知是在对原始订阅的2xx响应之后立即发送的通知，则必须根据filter<what>元素填充其内容，除非过滤器的处理将花费太长时间，或者通知请求是在对订阅请求的“202”响应之后并终止订阅。如果过滤器处理时间过长，则发送的通知请求可能为空，或者可能会填充该订户授权的预配置值。如果应用筛选器导致没有要传递的内容，则必须发送包含空内容的通知。如果筛选器包含<trigger>元素，则在生成第一个NOTIFY请求时，通知程序将忽略触发器值。
The input to the content filter is a package-specific XML document (e.g., [7] and [9]) derived according to the package-specific specifications, (e.g., [8] and [10]).
内容过滤器的输入是根据包特定规范（例如[8]和[10]）派生的包特定XML文档（例如[7]和[9]）。
The content is filtered according to the expressions in the <what> 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.
根据过滤器的<what>元素中的表达式过滤内容。表达式表示交付的XML元素和/或属性。在将筛选器应用于项之前，必须展开要筛选的XML文档项的名称空间前缀。
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, the namespaces of all the selected items are also included in the NOTIFY. The XML elements and/or attributes indicated by the expression in the <what> element must be items that the subscriber is authorised to see. If they are not, the notifier policy dictates the behaviour of the notifier (which can 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
该表达式直接声明要在NOTIFY中传递的XML元素和属性及其值。除了所选内容之外，所有所选项目的名称空间也包含在通知中。<what>元素中的表达式所指示的XML元素和/或属性必须是订阅者有权查看的项目。如果不是，则通知程序策略指示通知程序的行为（可以忽略过滤器、过滤器的部分或完全拒绝过滤器）。实施者需要仔细考虑这样的实施决定；订阅者可能不知道授权内容，因此很可能会包括请求未授权内容的过滤器。因此，建议通知程序
just ignore the parts of the filter that are requesting unauthorised info (i.e., the filter in the <filter> element where the unauthorised contents are requested is ignored). If polite blocking is used by the notifier, the notifier may choose to deliver notifications containing bogus information in the unauthorised elements or attributes and applying the filter afterwards.
只需忽略过滤器中请求未授权信息的部分（即，<filter>元素中请求未授权内容的过滤器将被忽略）。如果通知者使用礼貌阻止，通知者可以选择发送包含未经授权元素或属性中的虚假信息的通知，然后应用过滤器。
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 result 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 valid.
根据XML模式，生成的XML文档必须格式良好且有效。这意味着无论表达式如何，XML文档中都必须包含所有必需的元素和属性及其值。换句话说，如果对XML文档应用过滤器的结果是无效的XML文档，通知程序必须将原始XML文档中的元素和属性及其值添加到新制定的文档中，才能使其有效。
There can be several <trigger> elements inside one <filter> element. If the criteria for any of the <trigger> elements are satisfied, a NOTIFY SHOULD be generated.
一个<filter>元素中可以有多个<trigger>元素。如果满足任何<trigger>元素的条件，则应生成通知。
The items (XML elements and/or attributes) indicated by the expression in the <changed> element, <added> element, or <removed> element must be items that the subscriber is authorised to access. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely).
<changed>元素、<added>元素或<removed>元素中的表达式所指示的项目（XML元素和/或属性）必须是订阅者有权访问的项目。如果不是，则通知程序策略指示通知程序的行为（可以忽略过滤器、过滤器的部分或完全拒绝过滤器）。
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 [5], the notifier rejects the SUBSCRIBE request with a "488" response. A Warning header field in the response may give a better indication as to 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 [3] MAY be included.
如果过滤器定义无效，且过滤器的XML文档未与过滤器格式[5]的XML模式对齐，则通知程序将以“488”响应拒绝订阅请求。响应中的警告标题字段可以更好地指示过滤器未被接受的原因。如果订阅被“202”响应接受，但随后发现无效筛选器，则发送订阅状态为“已终止”的通知。这里介绍的subexp params[3]的事件原因值“badfilter”可能包括在内。
In case of an erroneous expression in the filter definition, the notifier either ignores the filter definition or terminates the subscription.
如果筛选器定义中存在错误的表达式，通知程序将忽略筛选器定义或终止订阅。
If a <what> or <trigger> element is empty, the notifier proceeds as if the element did not exist.
如果<what>或<trigger>元素为空，通知程序将继续处理，就像该元素不存在一样。
The subscriber of the filter MUST ensure that the XML document inserted as the SUBSCRIBE request body is well formed and valid. The subscriber MUST NOT insert any extension elements or attributes into the XML document unless it has access to the extension schema and can validate the XML document. The XML document notifier MAY validate the XML document according to the schemas, including extension schemas, to which it has access that are applicable to this XML document.
筛选器的订阅方必须确保作为订阅请求主体插入的XML文档格式正确且有效。订阅者不得在XML文档中插入任何扩展元素或属性，除非它可以访问扩展架构并验证XML文档。XML文档通知程序可以根据模式（包括扩展模式）验证XML文档，它可以访问适用于此XML文档的模式。
The following sections include filtering examples for Presence and Watcher Information. The format of filter is according to [5].
以下部分包括状态和观察者信息的过滤示例。过滤器的格式符合[5]。
This section describes three use cases where the presence information filtering solution is utilised [8]. 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 on which the presentity is currently available for communication. The third case shows how a presentity can request triggers to receive notifications.
本节描述了使用状态信息过滤解决方案的三个用例[8]。在第一个用例中，观察者感兴趣的是获取特定实体的消息传递特定信息。在第二个用例中，观察者感兴趣的是获取关于通信手段和联系人地址的信息，其中存在实体当前可用于通信。第三个案例展示了实体如何请求触发器来接收通知。
Below is the presentity's presence information in PIDF [7]. It includes two tuples: one for the instant messaging and another for the voice-related information.
以下是存在实体在PIDF中的存在信息[7]。它包括两个元组：一个用于即时消息，另一个用于语音相关信息。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
</tuple>
</presence>
The subscriber initiates a subscription to the presentity's messaging (MMS, IM, and SMS) related presence information. The subscription includes the content limiting filter.
订户发起对存在实体的消息（MMS、IM和SMS）相关存在信息的订阅。订阅包括内容限制筛选器。
The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <class> element contains "MMS", "SMS", or "IM".
过滤后的内容用表达式表示。此表达式选择<basic>元素和所有父元素（即<status>、<tuple>及其根元素）、<class>元素和<contact>元素。如果<class>元素包含“MMS”、“SMS”或“IM”，则过滤器匹配。
In this case, the notification includes the contents of the tuple that has the value "IM" in its <class> element.
在这种情况下，通知包括在其<class>元素中具有值“IM”的元组的内容。
SUBSCRIBE request from the subscriber including filter:
来自订阅服务器的订阅请求，包括筛选器：
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
订阅sip：presentity@example.comVia:SIP/2.0/TCP client.example.com:5060；分支=z9hG4bKxjfdsjfk到：<sip:presentity@example.com>发件人：<sip:watcher@example.com>;标记：12341111呼叫ID:32432udfidfjmk342 Cseq:1订阅过期：3600事件：状态联系人：<sip:watcher@client.example.com>内容类型：应用程序/简单筛选器+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:status/pidf:basic
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/rpid:class
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:status/pidf:basic
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/rpid:class
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:contact
</include>
</what>
</filter>
</filter-set>
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:contact
</include>
</what>
</filter>
</filter-set>
Notification to the subscriber:
向订户发出的通知：
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：watcher@client.example.comSIP/2.0 Via:SIP/2.0/TCP presence.example.com:5060；分支=z9hG4bKxjfder到：<sip:watcher@example.com>;标签：12341111发件人：<sip:presentity@example.com>;标记：232321呼叫ID:32432udfidfjmk342 Cseq:1通知事件：状态订阅状态：活动；expires=3599联系人：sip:presentity@server.example.com内容类型：应用程序/pidf+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
</presence>
The subscriber makes a subscription to the presentity's available communication means. The subscription includes the content-limiting filter.
订户订阅实体的可用通信手段。订阅包括内容限制筛选器。
The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <basic> element's value is "open".
过滤后的内容用表达式表示。此表达式选择<basic>元素和所有父元素（即<status>、<tuple>及其根元素）、<class>元素和<contact>元素。如果<basic>元素的值为“open”，则过滤器匹配。
In this case, the notification returns the contents of the tuple that has the value "open" inside the <status> element.
在这种情况下，通知返回在<status>元素中具有值“open”的元组的内容。
SUBSCRIBE request from the subscriber including filter:
来自订阅服务器的订阅请求，包括筛选器：
SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
订阅sip：presentity@example.comSIP/2.0 Via:SIP/2.0/TCP client.example.com:5060；分支=z9hG4bKxjfdsjfk到：<sip:presentity@example.com>发件人：<sip:watcher@example.com>;标记：12341111呼叫ID:32432udfidfjmk342 Cseq:1订阅过期：3600事件：状态联系人：<sip:watcher@client.example.com>内容类型：应用程序/简单筛选器+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
//pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
<include type="xpath">
//pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class
</include>
<include type="xpath">
//pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact
</include>
</what>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
//pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
<include type="xpath">
//pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class
</include>
<include type="xpath">
//pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact
</include>
</what>
</filter>
</filter-set>
Notification to the subscriber:
向订户发出的通知：
NOTIFY sip:watcher@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: <sip:watcher@example.com>;tag:12341111
From: <sip:presentity@example.com>;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Event: Presence
NOTIFY sip:watcher@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: <sip:watcher@example.com>;tag:12341111
From: <sip:presentity@example.com>;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Event: Presence
Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
订阅状态：活动；expires=3599联系人：sip:presentity@server.example.com内容类型：应用程序/pidf+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
7.1.3. Subscriber Requests Notifications When Presentity's Status Changes
7.1.3. 订户在实体状态更改时请求通知
The subscriber subscribes to the presentity, specifying in the filter that it wants notifications only when the <basic> element has changed to value "open".
订阅者订阅presentity，在筛选器中指定它只在<basic>元素更改为值“open”时才需要通知。
SUBSCRIBE request from the subscriber including filter:
来自订阅服务器的订阅请求，包括筛选器：
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
订阅sip：presentity@example.comVia:SIP/2.0/TCP client.example.com:5060；分支=z9hG4bKxjfdsjfk到：<sip:presentity@example.com>发件人：<sip:watcher@example.com>;标记：12341111呼叫ID:32432udfidfjmk342 Cseq:1订阅过期：3600事件：状态联系人：<sip:watcher@client.example.com>内容类型：应用程序/简单筛选器+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="closed" to="open">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="closed" to="open">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic
</changed>
</trigger>
</filter>
</filter-set>
</changed>
</trigger>
</filter>
</filter-set>
At some point during the subscription, a second PIDF document is created with both tuples having a status of "closed":
在订阅过程中的某个时刻，将创建第二个PIDF文档，其中两个元组的状态均为“closed”：
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>closed</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>closed</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
A NOTIFY is not sent to the subscriber in this case.
在这种情况下，不会向订阅服务器发送通知。
Now, a third PIDF document is created when the IM status changes to "open":
现在，当IM状态更改为“打开”时，将创建第三个PIDF文档：
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>open</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>closed</basic>
</status>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>open</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>closed</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
Notification containing both tuples is sent to the subscriber in this case:
在这种情况下，将向订阅服务器发送包含两个元组的通知：
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：watcher@client.example.comSIP/2.0 Via:SIP/2.0/TCP presence.example.com:5060；分支=z9hG4bKxjfder到：<sip:watcher@example.com>;标签：12341111发件人：<sip:presentity@example.com>;标记：232321呼叫ID:32432udfidfjmk342 Cseq:1通知事件：状态订阅状态：活动；expires=3599联系人：sip:presentity@server.example.com内容类型：应用程序/pidf+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
The examples in this section use the winfo template-package with the presence event package [10].
本节中的示例使用winfo模板包和状态事件包[10]。
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@example.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@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.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@example.com"</watcher>
</watcher-list>
</watcherinfo>
7.2.1. Watcher Subscriber Makes Subscription to Get All the Information about Active Watchers
7.2.1. 观察者订户订阅以获取有关活动观察者的所有信息
SUBSCRIBE request from the presentity including the filter:
来自实体的订阅请求，包括筛选器：
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence.winfo Contact: sip:presentity@client.example.com Content-Type: application/simple-filter+xml Content-Length: ...
订阅sip：presentity@example.comVia:SIP/2.0/TCP client.example.com:5060；分支=z9hG4bKxjfdsjfk到：<sip:presentity@example.com>发件人：<sip:presentity@example.com>;标记：12341111呼叫ID:32432udfidfjmk342 Cseq:1订阅过期：3600事件：状态。winfo联系人：sip:presentity@client.example.com内容类型：应用程序/简单筛选器+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list[@package="presence"]/
wi:watcher[@status="active"]
</include>
</what>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list[@package="presence"]/
wi:watcher[@status="active"]
</include>
</what>
</filter>
</filter-set>
Notification to the subscriber:
向订户发出的通知：
NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@server.example.com
Event: Presence.winfo
NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@server.example.com
Event: Presence.winfo
Content-Type: application/watcherinfo+xml Content-Length: ...
内容类型：application/watcherinfo+xml内容长度：。。。
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="active"
id="sr8fdsj"
duration-subscribed="20"
expiration="30"
event="approved">sip:watcherD@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="active"
id="sr8fdsj"
duration-subscribed="20"
expiration="30"
event="approved">sip:watcherD@example.com"</watcher>
</watcher-list>
</watcherinfo>
7.2.2. Watcher Subscriber Requests Information of Watchers with Specific Subscription Duration Conditions
7.2.2. 观察者订户请求具有特定订阅持续时间条件的观察者信息
SUBSCRIBE request from the presentity including the filter:
来自实体的订阅请求，包括筛选器：
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com>;tag:12341111 From: <sip:presentity@example.com> Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 0 Event: Presence.winfo Contact: <sip:presentity@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
订阅sip：presentity@example.comVia:SIP/2.0/TCP client.example.com:5060；分支=z9hG4bKxjfdsjfk到：<sip:presentity@example.com>;标签：12341111发件人：<sip:presentity@example.com>呼叫ID:32432udfidfjmk342 Cseq:1订阅过期：0事件：状态。winfo联系人：<sip:presentity@client.example.com>内容类型：应用程序/简单筛选器+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list[@package="presence"]/
wi:watcher[@duration-subscribed>500]
</include>
</what>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list[@package="presence"]/
wi:watcher[@duration-subscribed>500]
</include>
</what>
</filter>
</filter-set>
</filter>
</filter-set>
Notification to the subscriber:
向订户发出的通知：
NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@server.example.com
Event: Presence.winfo
NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@server.example.com
Event: Presence.winfo
Content-Type: application/watcherinfo+xml Content-Length: ...
内容类型：application/watcherinfo+xml内容长度：。。。
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.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-list>
</watcherinfo>
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.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-list>
</watcherinfo>
7.2.3. Watcher Subscriber Requests Specific Watcher Info on Specific Triggers
7.2.3. 观察者订户请求特定触发器上的特定观察者信息
This filter selects watcher information notifications [9] to be sent when the pending subscription status has changed from "pending" to "terminated". In the notification, only the watchers that have a status of "terminated" and an event of "rejected" are included.
当挂起的订阅状态从“挂起”更改为“已终止”时，此筛选器选择要发送的观察者信息通知[9]。在通知中，仅包括状态为“已终止”且事件为“已拒绝”的观察者。
SUBSCRIBE request from the Watcher Subscriber including the filter:
来自观察者订阅者的订阅请求，包括筛选器：
SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>;tag:12341111
SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>;tag:12341111
From: <sip:presentity@example.com> Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 0 Event: Presence.winfo Contact: <sip:presentity@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
发件人：<sip:presentity@example.com>呼叫ID:32432udfidfjmk342 Cseq:1订阅过期：0事件：状态。winfo联系人：<sip:presentity@client.example.com>内容类型：应用程序/简单筛选器+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list[@package="presence"]/
wi:watcher[@status="terminated" and @event="rejected"]
</include>
</what>
<trigger>
<changed from="pending"
to="terminated">
//@status
</changed>
</trigger>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list[@package="presence"]/
wi:watcher[@status="terminated" and @event="rejected"]
</include>
</what>
<trigger>
<changed from="pending"
to="terminated">
//@status
</changed>
</trigger>
</filter>
</filter-set>
At some point during the subscription, a second Winfo document is created due to some change:
在订阅过程中的某个时刻，由于某些更改，会创建第二个Winfo文档：
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
event="rejected">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@example.com"</watcher>
</watcher-list>
</watcherinfo>
event="rejected">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@example.com"</watcher>
</watcher-list>
</watcherinfo>
Notification to the subscriber is created, taking into account the <trigger> and <what> elements:
创建对订阅者的通知时，应考虑<trigger>和<what>元素：
NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@server.example.com
Event: Presence.winfo
NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@server.example.com
Event: Presence.winfo
Content-Type: application/watcherinfo+xml Content-Length: ...
内容类型：application/watcherinfo+xml内容长度：。。。
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
event="rejected">sip:watcherB@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="500"
expiration="0"
event="rejected">sip:watcherC@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
event="rejected">sip:watcherB@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="500"
expiration="0"
event="rejected">sip:watcherC@example.com"</watcher>
</watcher-list>
</watcherinfo>
The presence of filters in the body of 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. Authentication can be achieved using the Digest Authentication mechanism described in [2]. The authorisation decision is based on the permissions that the resource (notifier) has given to the watcher. An example of such auhorisation policy can be found in [11].
SIP消息体中过滤器的存在对服务器处理请求的方式有重大影响。因此，对包含此扩展的消息进行身份验证和授权尤为重要。可以使用[2]中描述的摘要身份验证机制实现身份验证。授权决定基于资源（通知者）给予观察者的权限。[11]中可以找到此类Auhorization政策的示例。
Processing of requests and looking up filters 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 of messages with large contents, in the hopes of overloading the server. To counter this, the server can establish a limit on the number of occurrences of the <what>, <changed>, <added>, and <removed> elements that are allowed in the filters. A default limit of 40 is RECOMMENDED; however, servers may raise or lower the limit depending upon their specific engineered capacity.
处理请求和查找筛选器需要设置操作和搜索，这可能需要一些计算量。这使得DoS攻击成为可能，用户可以通过此攻击发送包含大量内容的消息的请求，以期使服务器过载。为了解决这个问题，服务器可以对过滤器中允许的<what>、<changed>、<added>和<removed>元素的出现次数进行限制。建议默认限制为40；但是，服务器可能会根据其特定的工程容量提高或降低限制。
Requests can reveal sensitive information about a User Agent's (UA's) capabilities. If this information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities [6]. All package-specific security measures MUST be followed.
请求可能会泄露有关用户代理（UA）能力的敏感信息。如果此信息是敏感信息，则应使用SIP S/MIME功能对其进行加密[6]。必须遵守所有特定于包装的安全措施。
Propagating filters in SUBSCRIBE requests to foreign domains reveals sensitive information about a user's resource lists. It is therefore required that an RLS does not forward a filter if that filter is addressed to a resource that is under the administrative domain of the RLS, but that is not on the resource list. Section 4.1 shows an example where such a scenario can occur.
将订阅请求中的筛选器传播到外部域会显示有关用户资源列表的敏感信息。因此，如果筛选器被寻址到位于RLS的管理域下但不在资源列表上的资源，则要求RLS不转发筛选器。第4.1节给出了可能出现这种情况的示例。
Note that a filtered document located at a subscriber may project false reality. For example, if a subscriber asked to be notified when a resource has changed his presence state from "closed" to "open" but not from "open" to "closed", then the subscriber may afterwards be under the false impression that the resource's presence state is "open", even long after the resource has changed it to "closed". Therefore, subscribers need to be sure what they put in a filter, understand what they asked for, and be prepared to be out of sync with the real state of a resource.
请注意，位于订阅者处的过滤文档可能会投射虚假现实。例如，如果当资源将其存在状态从“关闭”更改为“打开”而不是从“打开”更改为“关闭”时，请求通知订阅者，则订阅者随后可能会误以为资源的存在状态是“打开”，即使在资源将其更改为“关闭”很久之后也是如此。因此，订阅者需要确定他们在过滤器中放入了什么，了解他们需要什么，并准备好与资源的真实状态不同步。
A new event-reason-value "badfilter" is defined to represent the event where the filter is not well formed and/or not accepted. No IANA registration is required for this value.
定义了一个新的事件原因值“badfilter”，以表示筛选器格式不正确和/或不被接受的事件。此值不需要IANA注册。
The authors would like to thank George Foti, Tim Moran, Sreenivas Addagatla, Juha Kalliokulju, Jari Urpalainen, and Mary Barnes for their valuable input.
作者要感谢George Foti、Tim Moran、Sreenivas Addagatla、Juha Kalliokulju、Jari Urpalainen和Mary Barnes的宝贵意见。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[4] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4663, September 2006.
[4] Roach，A.B.，Campbell，B.和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4663，2006年9月。
[5] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", RFC 4661, September 2006.
[5] H.Khartabil、Leppanen、E.Lonnfors、M.和J.Costa Requena，“基于可扩展标记语言（XML）的事件通知过滤格式”，RFC 46612006年9月。
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[6] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[7] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[9] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[9] Rosenberg，J.，“基于可扩展标记语言（XML）的观察者信息格式”，RFC3858，2004年8月。
[10] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[10] Rosenberg，J.，“会话启动协议（SIP）的观察者信息事件模板包”，RFC3857，2004年8月。
[11] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[11] Rosenberg，J.，“在场授权规则”，正在进行的工作，2006年6月。
Authors' Addresses
作者地址
Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway
Hisham Khartabil Telio邮政信箱1203 Vika Oslo Norway
Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no
Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no
Eva Leppanen Nokia P.O BOX 785 Tampere Finland
Eva Leppanen诺基亚邮政信箱785坦佩雷芬兰
Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com
Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com
Mikko Lonnfors Nokia P.O BOX 321 Helsinki Finland
Mikko Lonnfors诺基亚邮政信箱321芬兰赫尔辛基
Phone: + 358 71800 8000
EMail: mikko.lonnfors@nokia.com
Phone: + 358 71800 8000
EMail: mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 FIN-00045 NOKIA GROUP FINLAND
Jose Costa Requena诺基亚邮政信箱321 FIN-00045诺基亚芬兰集团
Phone: +358 71800 8000
EMail: jose.costa-requena@nokia.com
Phone: +358 71800 8000
EMail: jose.costa-requena@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。