Network Working Group J. Rosenberg
Request for Comments: 3857 dynamicsoft
Category: Standards Track August 2004
Network Working Group J. Rosenberg
Request for Comments: 3857 dynamicsoft
Category: Standards Track August 2004
A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的观察者信息事件模板包
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself.
本文档定义了会话启动协议（SIP）事件框架的观察者信息模板包。观察者信息是指订阅特定事件包中特定资源的用户集。当用户订阅、取消订阅、被批准或被拒绝时，观察者信息会动态变化。用户可以订阅此信息，从而了解对其所做的更改。此事件包是一个模板包，因为它可以应用于任何事件包，包括它本身。
Table of Contents
目录
1. Introduction ........................................ 2
2. Terminology ......................................... 3
3. Usage Scenarios ..................................... 3
3.1. Presence Authorization ........................ 4
3.2. Blacklist Alerts .............................. 5
4. Package Definition .................................. 5
4.1. Event Package Name ............................ 5
4.2. Event Package Parameters ...................... 5
4.3. SUBSCRIBE Bodies .............................. 6
4.4. Subscription Duration ......................... 6
4.5. NOTIFY Bodies ................................. 7
4.6. Notifier Processing of SUBSCRIBE Requests...... 7
4.7. Notifier Generation of NOTIFY Requests ........ 8
4.7.1. The Subscription State Machine......... 9
4.7.2. Applying the State Machine............. 11
4.8. Subscriber Processing of NOTIFY Requests ...... 12
4.9. Handling of Forked Requests ................... 12
4.10. Rate of Notifications ......................... 13
4.11. State Agents .................................. 13
5. Example Usage ....................................... 14
6. Security Considerations ............................. 17
6.1. Denial of Service Attacks ..................... 17
6.2. Divulging Sensitive Information ............... 17
7. IANA Considerations ................................. 18
8. Acknowledgements .................................... 18
9. Normative References ................................ 18
10. Informative References .............................. 19
11. Author's Address .................................... 19
12. Full Copyright Statement ............................ 20
1. Introduction ........................................ 2
2. Terminology ......................................... 3
3. Usage Scenarios ..................................... 3
3.1. Presence Authorization ........................ 4
3.2. Blacklist Alerts .............................. 5
4. Package Definition .................................. 5
4.1. Event Package Name ............................ 5
4.2. Event Package Parameters ...................... 5
4.3. SUBSCRIBE Bodies .............................. 6
4.4. Subscription Duration ......................... 6
4.5. NOTIFY Bodies ................................. 7
4.6. Notifier Processing of SUBSCRIBE Requests...... 7
4.7. Notifier Generation of NOTIFY Requests ........ 8
4.7.1. The Subscription State Machine......... 9
4.7.2. Applying the State Machine............. 11
4.8. Subscriber Processing of NOTIFY Requests ...... 12
4.9. Handling of Forked Requests ................... 12
4.10. Rate of Notifications ......................... 13
4.11. State Agents .................................. 13
5. Example Usage ....................................... 14
6. Security Considerations ............................. 17
6.1. Denial of Service Attacks ..................... 17
6.2. Divulging Sensitive Information ............... 17
7. IANA Considerations ................................. 18
8. Acknowledgements .................................... 18
9. Normative References ................................ 18
10. Informative References .............................. 19
11. Author's Address .................................... 19
12. Full Copyright Statement ............................ 20
The Session Initiation Protocol (SIP) event framework is described in RFC 3265 [1]. It defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. Packages have been defined for user presence [5], for example.
RFC 3265[1]中描述了会话启动协议（SIP）事件框架。它定义了一个通用框架，用于订阅和通知与SIP系统相关的事件。该框架定义了SUBSCRIBE和NOTIFY方法，并引入了包的概念。包是事件框架对特定事件类的具体应用。例如，已经为用户状态[5]定义了包。
This document defines a "template-package" within the SIP event framework. A template-package has all the properties of a regular SIP event package. However, it is always associated with some other event package, and can always be applied to any event package, including the template-package itself.
本文档在SIP事件框架中定义了一个“模板包”。模板包具有常规SIP事件包的所有属性。但是，它始终与其他一些事件包相关联，并且始终可以应用于任何事件包，包括模板包本身。
The template-package defined here is for watcher information, and is denoted with the token "winfo". For any event package, such as presence, there exists a set (perhaps an empty set) of subscriptions that have been created or requested by users trying to ascertain the state of a resource in that package. This set of subscriptions changes over time as new subscriptions are requested by users, old subscriptions expire, and subscriptions are approved or rejected by the owners of that resource. The set of users subscribed to a particular resource for a specific event package, and the state of their subscriptions, is referred to as watcher information. Since this state is itself dynamic, it is reasonable to subscribe to it in order to learn about changes to it. The watcher information event template-package is meant to facilitate exactly that - tracking the state of subscriptions to a resource in another package.
此处定义的模板包用于查看者信息，并用标记“winfo”表示。对于任何事件包（如presence），都存在一组订阅（可能是一个空集），这些订阅是由试图确定该包中资源状态的用户创建或请求的。随着用户请求新订阅、旧订阅过期以及该资源的所有者批准或拒绝订阅，此订阅集会随着时间的推移而更改。为特定事件包订阅特定资源的用户集及其订阅状态称为观察者信息。因为这种状态本身是动态的，所以订阅它以了解它的变化是合理的。watcher information事件模板包的目的就是为了准确地跟踪对另一个包中的资源的订阅状态。
To denote this template-package, the name is constructed by appending ".winfo" to the name of whatever package is being tracked. For example, the set of people subscribed to presence is defined by the "presence.winfo" package.
为了表示这个模板包，这个名称是通过在跟踪的任何包的名称后面附加“.winfo”来构造的。例如，订阅状态的人员集由“presence.winfo”包定义。
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 BCP14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP14、RFC 2119[2]中的描述进行解释，并指出合规实施的要求级别。
This document fundamentally deals with recursion - subscriptions to subscriptions. Therefore, the term "subscription" itself can be confusing in this document. To reduce confusion, the term "watcherinfo subscription" refers to a subscription to watcher information, and the term "watcherinfo subscriber" refers to a user that has subscribed to watcher information. The term "watcherinfo notification" refers to a NOTIFY request sent as part of a watcherinfo subscription. When the terms "subscription", "subscriber", and "notification" are used unqualified, they refer to the "inner" subscriptions, subscribers and notifications - those that are being monitored through the watcherinfo subscriptions. We also use the term "watcher" to refer to a subscriber to the "inner" resource. Information on watchers is reported through watcherinfo subscriptions.
本文档从根本上处理递归订阅。因此，在本文件中，“订阅”一词本身可能会引起混淆。为了减少混淆，术语“watcherinfo subscription”指对观察者信息的订阅，术语“watcherinfo subscriber”指已订阅观察者信息的用户。术语“watcherinfo通知”是指作为watcherinfo订阅的一部分发送的通知请求。当使用术语“订阅”、“订阅者”和“通知”时，它们指的是“内部”订阅、订阅者和通知，即通过watcherinfo订阅监视的订阅。我们还使用术语“观察者”来指代“内部”资源的订户。通过watcherinfo订阅报告有关观察者的信息。
There are many useful applications for the watcher information template-package.
观察者信息模板包有许多有用的应用程序。
The motivating application for this template-package is presence authorization. When user A subscribes to the presence of user B, the subscription needs to be authorized. Frequently, that authorization needs to occur through direct user intervention. For that to happen, B's software needs to become aware that a presence subscription has been requested. This is supported through watcher information. B's client software would SUBSCRIBE to the watcher information for the presence of B:
此模板包的激励应用程序是状态授权。当用户A订阅用户B的存在时，需要对订阅进行授权。通常，授权需要通过直接用户干预进行。为了实现这一点，B的软件需要知道已经请求了状态订阅。这通过观察者信息得到支持。B的客户端软件将订阅观察者信息，以便B：
SUBSCRIBE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:B@example.com;tag=123s8a
To: sip:B@example.com
Call-ID: 9987@pc34.example.com
Max-Forwards: 70
CSeq: 9887 SUBSCRIBE
Contact: sip:B@pc34.example.com
Event: presence.winfo
SUBSCRIBE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:B@example.com;tag=123s8a
To: sip:B@example.com
Call-ID: 9987@pc34.example.com
Max-Forwards: 70
CSeq: 9887 SUBSCRIBE
Contact: sip:B@pc34.example.com
Event: presence.winfo
The policy of the server is such that it allows B to subscribe to its own watcher information. So, when A subscribes to B's presence, B gets a notification of the change in watcher information state:
服务器的策略允许B订阅自己的观察者信息。因此，当A订阅B的存在时，B收到观察者信息状态变化的通知：
NOTIFY sip:B@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g From: sip:B@example.com;tag=xyz887 To: sip:B@example.com;tag=123s8a Call-ID: 9987@pc34.example.com Max-Forwards: 70 CSeq: 1288 NOTIFY Contact: sip:B@server.example.com Event: presence.winfo Content-Type: application/watcherinfo+xml Content-Length: ...
通知sip：B@pc34.example.comSIP/2.0 Via:SIP/2.0/UDP server.example.com；分支=z9hG4bKna66g来源：sip:B@example.com;标签=xyz887至：sip:B@example.com;tag=123s8a呼叫标识：9987@pc34.example.com最大转发：70 CSeq:1288通知联系人：sip:B@server.example.com事件：presence.winfo内容类型：application/watcherinfo+xml内容长度：。。。
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:B@example.com" package="presence">
<watcher id="7768a77s" event="subscribe"
status="pending">sip:A@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:B@example.com" package="presence">
<watcher id="7768a77s" event="subscribe"
status="pending">sip:A@example.com</watcher>
</watcher-list>
</watcherinfo>
This indicates to B that A has subscribed, and that the subscription is pending (meaning, it is awaiting authorization). B's software can alert B that this subscription is awaiting authorization. B can then set policy for that subscription.
这向B指示A已订阅，且订阅处于挂起状态（表示它正在等待授权）。B的软件可以提醒B此订阅正在等待授权。B然后可以为该订阅设置策略。
Applications can subscribe to watcher information in order to provide value-added features. An example application is "blacklist alerts". In this scenario, an application server maintains a list of known "bad guys". A user, Joe, signs up for service with the application provider, presumably by going to a web page and entering in his presence URI. The application server subscribes to the watcher information for Joe's presence. When someone attempts to SUBSCRIBE to Joe's user presence, the application learns of this subscription as a result of its watcher info subscription. It checks the watcher's URI against the database of known bad guys. If there is a match, it sends email to Joe letting him know about this.
应用程序可以订阅观察者信息以提供增值功能。一个示例应用程序是“黑名单警报”。在这个场景中，应用服务器维护一个已知“坏人”的列表。用户Joe向应用程序提供商注册服务，大概是通过转到一个网页并输入他的状态URI。应用程序服务器订阅Joe在场的观察者信息。当有人试图订阅Joe的用户状态时，应用程序会从其watcher info订阅中得知此订阅。它根据已知坏人的数据库检查观察者的URI。如果有匹配，它会发送电子邮件给乔，让他知道这一点。
For this application to work, Joe needs to make sure that the application is allowed to subscribe to his presence.winfo.
为了使该应用程序正常工作，Joe需要确保允许该应用程序订阅他的presence.winfo。
This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [1].
本节填写了指定RFC 3265[1]第4.4节中定义的事件包所需的详细信息。
RFC 3265 [1] requires package definitions to specify the name of their package or template-package.
RFC 3265[1]要求包定义指定其包或模板包的名称。
The name of this template-package is "winfo". It can be applied to any other package. Watcher information for any package foo is denoted by the name "foo.winfo". Recursive template-packaging is explicitly allowed (and useful), so that "foo.winfo.winfo" is a valid package name.
此模板包的名称为“winfo”。它可以应用于任何其他包。任何包foo的观察者信息都由名称“foo.winfo”表示。递归模板打包是明确允许的（并且非常有用），因此“foo.winfo.winfo”是一个有效的包名。
RFC 3265 [1] requires package and template-package definitions to specify any package specific parameters of the Event header field.
RFC 3265[1]需要包和模板包定义来指定事件头字段的任何包特定参数。
No package specific Event header field parameters are defined for this event template-package.
没有为此事件模板包定义包特定的事件标头字段参数。
RFC 3265 [1] requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
RFC 3265[1]需要包或模板包定义来定义订阅请求中实体的用法（如果有）。
A SUBSCRIBE request for watcher information MAY contain a body. This body would serve the purpose of filtering the watcherinfo subscription. The definition of such a body is outside the scope of this specification. For example, in the case of presence, the body might indicate that notifications should contain full state every time something changes, and that the time the subscription was first made should not be included in the watcherinfo notifications.
对观察者信息的订阅请求可能包含正文。此主体将用于筛选watcherinfo订阅。此类主体的定义不在本规范的范围内。例如，在存在的情况下，主体可能会指示每次发生更改时通知应包含完整状态，并且首次进行订阅的时间不应包含在watcherinfo通知中。
A SUBSCRIBE request for a watcher information package MAY be sent without a body. This implies the default watcherinfo subscription filtering policy has been requested. The default policy is:
可以在没有正文的情况下发送对观察者信息包的订阅请求。这意味着已请求默认的watcherinfo订阅筛选策略。默认策略为：
o Watcherinfo notifications are generated every time there is any change in the state of the watcher information.
o 每次观察者信息的状态发生任何更改时，都会生成Watcherinfo通知。
o Watcherinfo notifications triggered from a SUBSCRIBE contain full state (the list of all watchers that the watcherinfo subscriber is permitted to know about). Watcherinfo notifications triggered from a change in watcher state only contain information on the watcher whose state has changed.
o 从订阅触发的Watcherinfo通知包含完整状态（允许Watcherinfo订阅服务器知道的所有观察者的列表）。监视程序状态更改触发的监视程序信息通知仅包含状态已更改的监视程序的信息。
Of course, the server can apply any policy it likes to the subscription.
当然，服务器可以对订阅应用它喜欢的任何策略。
RFC 3265 [1] requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.
RFC 3265[1]要求包定义定义订阅持续时间的默认值，并讨论明确指定持续时间时的合理选择。
Watcher information changes as users subscribe to a particular resource for some package, or their subscriptions time out. As a result, the state of watcher information can change very dynamically, depending on the number of subscribers for a particular resource in a given package. The rate at which subscriptions time out depends on how long a user maintains its subscription. Typically, watcherinfo subscriptions will be timed to span the lifetime of the subscriptions being watched, and therefore range from minutes to days.
当用户订阅某个包的特定资源或其订阅超时时，观察者信息会发生变化。因此，观察者信息的状态可以非常动态地改变，这取决于给定包中特定资源的订户数量。订阅超时的速率取决于用户维护其订阅的时间。通常，watcherinfo订阅的时间安排将跨越正在监视的订阅的生存期，因此从分钟到天不等。
As a result of these factors, it is difficult to define a broadly useful default value for the lifetime of a watcherinfo subscription. We arbitrarily choose one hour. However, clients SHOULD use an Expires header field to specify their preferred duration.
由于这些因素，很难为watcherinfo订阅的生命周期定义一个广泛有用的默认值。我们任意选择一小时。但是，客户端应使用Expires标头字段指定其首选的持续时间。
RFC 3265 [1] requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header field in the SUBSCRIBE request.
RFC 3265[1]要求包定义描述NOTIFY请求中允许的一组正文类型，并指定订阅请求中没有Accept header字段时使用的默认值。
The body of the watcherinfo notification contains a watcher information document. This document describes some or all of the watchers for a resource within a given package, and the state of their subscriptions. All watcherinfo subscribers and notifiers MUST support the application/watcherinfo+xml format described in [3], and MUST list its MIME type, application/watcherinfo+xml, in any Accept header field present in the SUBSCRIBE request.
watcherinfo通知的正文包含一个watcher信息文档。本文档描述给定包中资源的部分或全部监视程序及其订阅状态。所有watcherinfo订阅者和通知者必须支持[3]中描述的application/watcherinfo+xml格式，并且必须在订阅请求中的任何Accept header字段中列出其MIME类型application/watcherinfo+xml。
Other watcher information formats might be defined in the future. In that case, the watcherinfo subscriptions MAY indicate support for other formats. However, they MUST always support and list application/watcherinfo+xml as an allowed format.
将来可能会定义其他观察者信息格式。在这种情况下，watcherinfo订阅可能表示支持其他格式。但是，它们必须始终支持并将application/watcherinfo+xml列为允许的格式。
Of course, the watcherinfo notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request. If no Accept header field was present, the notifications MUST use the application/watcherinfo+xml format described in [3].
当然，服务器生成的watcherinfo通知必须采用SUBSCRIBE请求中Accept header字段中指定的格式之一。如果不存在Accept header字段，则通知必须使用[3]中描述的application/watcherinfo+xml格式。
RFC 3265 [1] specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization.
RFC 3265[1]规定包应在通知程序中定义订阅请求的任何包特定处理，特别是关于身份验证和授权。
The watcher information for a particular package contains sensitive information. Therefore, all watcherinfo subscriptions SHOULD be authenticated and then authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms [4]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
特定包的观察者信息包含敏感信息。因此，所有watcherinfo订阅都应该经过身份验证，然后在批准之前进行授权。可以使用SIP中可用的任何技术执行身份验证，包括摘要、S/MIME、TLS或其他特定于传输的机制[4]。与往常一样，授权策略由管理员自行决定。然而，可以提出一些建议。
It is RECOMMENDED that user A be allowed to subscribe to their own watcher information for any package. This is true recursively, so that it is RECOMMENDED that a user be able to subscribe to the watcher information for their watcher information for any package.
建议允许用户A为任何包订阅自己的观察者信息。这是递归的，因此建议用户能够订阅任何包的观察者信息的观察者信息。
It is RECOMMENDED that watcherinfo subscriptions for some package foo for user A be allowed from some other user B, if B is an authorized subscriber to A within the package foo. However, it is RECOMMENDED
如果B是包foo中A的授权订户，建议允许其他用户B订阅用户A的某些包foo的watcherinfo。但是，建议您这样做
that the watcherinfo notifications sent to B only contain the state of B's own subscription. In other words, it is RECOMMENDED that a user be allowed to monitor the state of their own subscription.
发送到B的watcherinfo通知只包含B自己订阅的状态。换句话说，建议允许用户监视自己订阅的状态。
To avoid infinite recursion of authorization policy, it is RECOMMENDED that only user A be allowed to subscribe to foo.winfo.winfo for user A, for any foo. It is also RECOMMENDED that by default, a server does not authorize any subscriptions to foo.winfo.winfo.winfo or any other deeper recursions.
为了避免授权策略的无限递归，建议仅允许用户A为用户A为任何foo订阅foo.winfo.winfo。还建议默认情况下，服务器不授权对foo.winfo.winfo.winfo或任何其他更深层次递归的任何订阅。
The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed.
SIP事件框架请求包指定为该包发送通知的条件，以及如何构造此类通知。
Each watcherinfo subscription is associated with a set of "inner" subscriptions being watched. This set is defined by the URI in the Request URI of the watcherinfo SUBSCRIBE request, along with the parent event package of the watcherinfo subscription. The parent event package is obtained by removing the trailing ".winfo" from the value of the Event header field from the watcherinfo SUBSCRIBE request. If the Event header field in the watcherinfo subscription has a value of "presence.winfo", the parent event package is "presence". If the Event header field has a value of "presence.winfo.winfo", the parent event package is "presence.winfo". Normally, the URI in the Request URI of the watcherinfo SUBSCRIBE identifies an address-of-record within the domain. In that case, the set of subscriptions to be watched are all of the subscriptions for the parent event package that have been made to the resource in the Request URI of the watcherinfo SUBSCRIBE. However, the Request URI can contain a URI that identifies any set of subscriptions, including the subscriptions to a larger collection of resources. For example, sip:all-resources@example.com might be defined within example.com to refer to all resources. In that case, a watcherinfo subscription for "presence.winfo" to sip:all-resources@example.com is requesting notifications any time the state of any presence subscription for any resource within example.com changes. A watcherinfo notifier MAY generate a notification any time the state of any of the watched subscriptions changes.
每个watcherinfo订阅都与一组正在监视的“内部”订阅相关联。此集合由watcherinfo订阅请求的请求URI中的URI以及watcherinfo订阅的父事件包定义。父事件包是通过从watcherinfo SUBSCRIBE请求的事件头字段值中删除尾随“.winfo”获得的。如果watcherinfo订阅中的事件头字段的值为“presence.winfo”，则父事件包为“presence”。如果事件标题字段的值为“presence.winfo.winfo”，则父事件包为“presence.winfo”。通常，watcherinfo订阅的请求URI中的URI标识域内的记录地址。在这种情况下，要监视的订阅集是对watcherinfo订阅的请求URI中的资源所做的父事件包的所有订阅。但是，请求URI可以包含标识任何订阅集的URI，包括对更大资源集合的订阅。例如，sip:all-resources@example.com可以在example.com中定义以引用所有资源。在这种情况下，将“presence.winfo”的watcherinfo订阅改为sip:all-resources@example.com在example.com中的任何资源的任何状态订阅的状态发生更改时请求通知。watcherinfo通知程序可以在任何监视订阅的状态发生更改时生成通知。
Because a watcherinfo subscription is made to a collection of subscriptions, the watcher information package needs a model of subscription state. This is accomplished by specifying a subscription Fine State Machine (FSM), described below, which governs the subscription state of a user in any package. Watcherinfo notifications MAY be generated on transitions in this state machine. It's important to note that this FSM is just a model of the
因为watcherinfo订阅是对订阅集合进行的，所以watcher信息包需要订阅状态的模型。这是通过指定订阅精细状态机（FSM）来实现的，如下所述，它控制任何包中用户的订阅状态。此状态机中的转换可能会生成Watcherinfo通知。值得注意的是，该FSM只是
subscription state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner.
由服务器维护的订阅状态机器。实现将以特定于实现的方式将自己的状态机映射到此状态机。
The underlying state machine for a subscription is shown in Figure 1. It derives almost entirely from the descriptions in RFC 3265 [1], but adds the notion of a waiting state.
订阅的底层状态机如图1所示。它几乎完全源自RFC3265[1]中的描述，但添加了等待状态的概念。
When a SUBSCRIBE request arrives, the subscription FSM is created in the init state. This state is transient. The next state depends on whether policy exists for the subscription. If there is an existing policy that determines that the subscription is forbidden, it moves into the terminated state immediately, where the FSM can be destroyed. If there is existing policy that determines that the subscription is authorized, the FSM moves into the active state. This state indicates that the subscriber will receive notifications.
当订阅请求到达时，将在init状态下创建订阅FSM。这种状态是暂时的。下一个状态取决于订阅是否存在策略。如果存在确定禁止订阅的现有策略，则它会立即进入终止状态，在该状态下可以销毁FSM。如果存在确定订阅已授权的现有策略，则FSM将进入活动状态。此状态表示订阅服务器将接收通知。
If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. No notifications are generated on changes in presence state (an initial NOTIFY will have been delivered as per RFC 3265 [1]), but the subscription FSM is maintained. If the authorization decision comes back positive, the subscription is approved, and moves into the active state. If the authorization is negative, the subscription is rejected, and the FSM goes into the terminated state. It is possible that the authorization decision can take a very long time. In fact, no authorization decision may arrive until after the subscription itself expires. If a pending subscription suffers a timeout, it moves into the waiting state. At any time, the server can decide to end a pending or waiting subscription because it is concerned about allocating memory and CPU resources to unauthorized subscription state. If this happens, a "giveup" event is generated by the server, moving the subscription to terminated.
如果在订阅到达时，不存在授权策略，则订阅将进入挂起状态。在此状态下，服务器正在等待授权决定。状态发生变化时不会生成通知（初始通知将按照RFC 3265[1]的规定进行传递），但订阅FSM会得到维护。如果授权决定为肯定，则订阅已批准，并进入活动状态。如果授权为否定，则拒绝订阅，FSM进入终止状态。授权决策可能需要很长时间。事实上，只有在订阅本身过期之后，才能做出授权决定。如果挂起的订阅超时，它将进入等待状态。在任何时候，服务器都可以决定结束挂起或等待的订阅，因为它关心将内存和CPU资源分配给未经授权的订阅状态。如果发生这种情况，服务器将生成一个“放弃”事件，将订阅移动到已终止。
The waiting state is similar to pending, in that no notifications are generated. However, if the subscription is approved or denied, the FSM enters the terminated state, and is destroyed. Furthermore, if another subscription is received to the same resource, from the same watcher, for the same event package, event package parameters and filter in the body of the SUBSCRIBE request (if one was present initially), the FSM enters the terminated state with a "giveup" event, and is destroyed. This transition occurs because, on arrival of a new subscription with identical parameters, it will enter the pending state, making the waiting state for the prior subscription redundant. The purpose of the waiting state is so that a user can
等待状态类似于挂起状态，即不生成通知。但是，如果订阅被批准或拒绝，FSM将进入终止状态并被销毁。此外，如果针对订阅请求主体中的相同事件包、事件包参数和过滤器（如果最初存在），从相同观察者接收到对相同资源的另一订阅，则FSM进入终止状态，并发生“放弃”事件，并被销毁。发生此转换的原因是，在到达具有相同参数的新订阅时，它将进入挂起状态，从而使先前订阅的等待状态冗余。等待状态的目的是让用户能够
fetch watcherinfo state at any time, and learn of any subscriptions that arrived previously (and which may arrive again) which require an authorization decision. Consider an example. A subscribes to B. B has not defined policy about this subscription, so it moves into the pending state. B is not "online", so that B's software agent cannot be contacted to approve the subscription. The subscription expires. Let's say it were destroyed. B logs in, and fetches its watcherinfo state. There is no record of the subscription from A, so no policy decision is made about subscriptions from A. B logs off. A refreshes its subscription. Once more, the subscription is pending since no policy is defined for it. This process could continue indefinitely. The waiting state ensures that B can find out about this subscription attempt.
随时获取watcherinfo状态，并了解以前到达（可能再次到达）且需要授权决策的任何订阅。考虑一个例子。A订阅B。B未定义有关此订阅的策略，因此它将进入挂起状态。B不是“在线”，因此无法联系B的软件代理以批准订阅。订阅到期。假设它被摧毁了。B登录并获取其watcherinfo状态。没有来自A的订阅记录，所以不会对来自A的订阅做出任何策略决定。B注销。A刷新其订阅。订阅再次处于挂起状态，因为没有为其定义任何策略。这一进程可以无限期地继续下去。等待状态确保B可以了解有关此订阅尝试的信息。
subscribe,
policy= +----------+
reject | |<------------------------+
+------------>|terminated|<---------+ |
| | | | |
| | | |noresource |
| +----------+ |rejected |
| ^noresource |deactivated |
| |rejected |probation |
| |deactivated |timeout |noresource
| |probation | |rejected
| |giveup | |giveup
| | | |approved
+-------+ +-------+ +-------+ |
| |subscribe| |approved| | |
| init |-------->|pending|------->|active | |
| |no policy| | | | |
| | | | | | |
+-------+ +-------+ +-------+ |
| | ^ |
| subscribe, | | |
+-----------------------------------+ |
policy = accept | +-------+ |
| | | |
| |waiting|----------+
+----------->| |
timeout | |
+-------+
subscribe,
policy= +----------+
reject | |<------------------------+
+------------>|terminated|<---------+ |
| | | | |
| | | |noresource |
| +----------+ |rejected |
| ^noresource |deactivated |
| |rejected |probation |
| |deactivated |timeout |noresource
| |probation | |rejected
| |giveup | |giveup
| | | |approved
+-------+ +-------+ +-------+ |
| |subscribe| |approved| | |
| init |-------->|pending|------->|active | |
| |no policy| | | | |
| | | | | | |
+-------+ +-------+ +-------+ |
| | ^ |
| subscribe, | | |
+-----------------------------------+ |
policy = accept | +-------+ |
| | | |
| |waiting|----------+
+----------->| |
timeout | |
+-------+
Figure 1: Subscription State Machine
图1：订阅状态机
The waiting state is also needed to allow for authorization of fetch attempts, which are subscriptions that expire immediately.
还需要等待状态以允许授权获取尝试，这些尝试是立即过期的订阅。
Of course, policy may never be specified for the subscription. As a result, the server can generate a giveup event to move the waiting subscription to the terminated state. The amount of time to wait before issuing a giveup event is system dependent.
当然，可能永远不会为订阅指定策略。因此，服务器可以生成放弃事件，将等待的订阅移动到终止状态。发出放弃事件之前的等待时间取决于系统。
The giveup event is generated in either the waiting or pending states to destroy resources associated with unauthorized subscriptions. This event is generated when a giveup timer fires. This timer is set to a timeout value when entering either the pending or waiting states. Servers need to exercise care in selecting this value. It needs to be large in order to provide a useful user experience; a user should be able to log in days later and see that someone tried to subscribe to them. However, allocating state to unauthorized subscriptions can be used as a source of DoS attacks. Therefore, it is RECOMMENDED that servers that retain state for unauthorized subscriptions add policies which prohibit a particular subscriber from having more than some number of pending or waiting subscriptions.
在等待或挂起状态下生成放弃事件，以销毁与未授权订阅关联的资源。此事件在放弃计时器触发时生成。当进入挂起或等待状态时，此计时器设置为超时值。服务器在选择此值时需要小心。它需要很大，以便提供有用的用户体验；用户应该能够在几天后登录，并看到有人试图订阅它们。但是，将状态分配给未经授权的订阅可能会被用作DoS攻击的来源。因此，建议为未经授权的订阅保留状态的服务器添加策略，以禁止特定订阅服务器拥有超过一定数量的挂起或等待订阅。
At any time, the server can deactivate a subscription. Deactivation implies that the subscription is discarded without a change in authorization policy. This may be done in order to trigger refreshes of subscriptions for a graceful shutdown or subscription migration operation. A related event is probation, where a subscription is terminated, and the subscriber is requested to wait some amount of time before trying again. The meaning of these events is described in more detail in Section 3.2.4 of RFC 3265 [1].
服务器可以随时停用订阅。停用意味着在不更改授权策略的情况下放弃订阅。这可能是为了触发订阅刷新，以便正常关闭或订阅迁移操作。一个相关的事件是试用，其中订阅被终止，并且订户被要求在重试之前等待一段时间。RFC 3265[1]第3.2.4节详细描述了这些事件的含义。
A subscription can be terminated at any time because the resource associated with that subscription no longer exists. This corresponds to the noresource event.
订阅可以随时终止，因为与该订阅关联的资源已不存在。这对应于noresource事件。
The server MAY generate a notification to watcherinfo subscribers on a transition of the state machine. Whether it does or not is policy dependent. However, several guidelines are defined.
服务器可以在状态机转换时向watcherinfo订户生成通知。它是否存在取决于策略。但是，定义了若干准则。
Consider some event package foo. A subscribes to B for events within that package. A also subscribes to foo.winfo for B. In this scenario (where the subscriber to foo.winfo is also a subscriber to foo for the same resource), it is RECOMMENDED that A receive watcherinfo notifications only about the changes in its own subscription. Normally, A will receive notifications about changes in its subscription to foo through the Subscription-State header field. This will frequently obviate the need for a separate subscription to foo.winfo. However, if such a subscription is performed by A, the foo.winfo notifications SHOULD NOT report any
考虑一些事件包FO。A向B订阅该包中的事件。A还为B订阅foo.winfo。在这种情况下（foo.winfo的订户也是相同资源的foo订户），建议A只接收有关其自身订阅中更改的watcherinfo通知。通常，A将通过subscription State header字段接收有关其对foo的订阅更改的通知。这样通常就不需要单独订阅foo.winfo了。但是，如果此类订阅由执行，则foo.winfo通知不应报告任何
state changes which would not be reported (because of authorization policy) in the Subscription-State header field in notifications on foo.
在foo上的通知的订阅状态标头字段中不会报告（由于授权策略）的状态更改。
As a general rule, when a watcherinfo subscriber is authorized to receive watcherinfo notifications about more than one watcher, it is RECOMMENDED that watcherinfo notifications contain information about those watchers which have changed state (and thus triggered a notification), instead of delivering the current state of every watcher in every watcherinfo notification. However, watcherinfo notifications triggered as a result of a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all watchers (of course, only those watchers that have been authorized to be divulged to the watcherinfo subscriber) to be present in the NOTIFY.
作为一般规则，当watcherinfo订户被授权接收有关多个观察者的watcherinfo通知时，建议watcherinfo通知包含有关已更改状态（从而触发通知）的观察者的信息，而不是在每个watcherinfo通知中传递每个观察者的当前状态。但是，由于获取操作（过期时间为0的订阅）而触发的watcherinfo通知应导致所有观察者（当然，只有那些被授权泄露给watcherinfo订阅者的观察者）的完整状态出现在通知中。
Frequently, states in the subscription state machine will be transient. For example, if an authorized watcher performs a fetch operation, this will cause the state machine to be created, transition from init to active, and then from active to terminated, followed by a destruction of the FSM. In such cases, watcherinfo notifications SHOULD NOT be sent for any transient states. In the prior example, the server wouldn't send any notifications, since all of the states are transient.
订阅状态机中的状态通常是瞬态的。例如，如果授权的观察者执行提取操作，这将导致创建状态机，从init转换为active，然后从active转换为terminated，然后销毁FSM。在这种情况下，任何瞬态状态都不应发送watcherinfo通知。在前面的示例中，服务器不会发送任何通知，因为所有状态都是暂时的。
RFC 3265 [1] expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically, the watcherinfo NOTIFY will only contain information about those watchers whose state has changed. To construct a coherent view of the total state of all watchers, a watcherinfo subscriber will need to combine NOTIFYs received over time. This details of this process depend on the document format. See [3] for details on the application/watcherinfo+xml format.
RFC 3265[1]期望包指定订阅者如何以包特定的方式处理NOTIFY请求，特别是如何使用NOTIFY请求来构建订阅资源状态的一致视图。通常，watcherinfo NOTIFY只包含状态已更改的观察者的信息。为了构建所有观察者的总状态的一致视图，watcherinfo订阅者需要合并随时间接收的NOTIFY。此过程的详细信息取决于文档格式。有关应用程序/watcherinfo+xml格式的详细信息，请参见[3]。
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
SIP事件框架要求包指示分叉订阅请求是否可以安装多个订阅。
When a user wishes to obtain watcher information for some resource for package foo, the SUBSCRIBE to the watcher information will need to reach a collection of servers that have, unioned together, complete information about all watchers on that resource for package foo. If there are a multiplicity of servers handling subscriptions for that resource for package foo (for load balancing reasons,
当用户希望获得包foo的某些资源的观察者信息时，订阅观察者信息将需要到达一组服务器，这些服务器已联合在一起，提供关于包foo资源上所有观察者的完整信息。如果有多个服务器为包foo处理该资源的订阅（出于负载平衡的原因，
typically), it is very likely that no single server will have the complete set of watcher information. There are several solutions in this case. This specification does not mandate a particular one, nor does it rule out others. It merely ensures that a broad range of solutions can be built.
通常情况下），很可能没有一台服务器拥有完整的观察者信息集。在这种情况下，有几种解决方案。本规范不强制要求特定的规范，也不排除其他规范。它只是确保可以构建广泛的解决方案。
One solution is to use forking. The system can be designed so that a SUBSCRIBE for watcher information arrives at a special proxy which is aware of the requirements for watcher information. This proxy would fork the SUBSCRIBE request to all of the servers which could possibly maintain subscriptions for that resource for that package. Each of these servers, whether or not they have any current subscribers for that resource, would accept the watcherinfo subscription. Each needs to accept because they may all eventually receive a subscription for that resource. The watcherinfo subscriber would receive some number of watcherinfo NOTIFY requests, each of which establishes a separate dialog. By aggregating the information across each dialog, the watcherinfo subscriber can compute full watcherinfo state. In many cases, a particular dialog might never generate any watcherinfo notifications; this would happen if the servers never receive any subscriptions for the resource.
一种解决方法是使用分叉。该系统的设计可以使对观察者信息的订阅到达一个特殊的代理，该代理知道对观察者信息的要求。这个代理将把SUBSCRIBE请求分叉给所有可能维护该包的资源订阅的服务器。这些服务器中的每一个，无论它们是否有该资源的任何当前订阅服务器，都将接受watcherinfo订阅。每个人都需要接受，因为他们可能最终都会收到该资源的订阅。watcherinfo订阅者将收到一定数量的watcherinfo NOTIFY请求，每个请求建立一个单独的对话框。通过聚合每个对话框中的信息，watcherinfo订阅者可以计算完整的watcherinfo状态。在许多情况下，特定的对话框可能永远不会生成任何watcherinfo通知；如果服务器从未收到任何资源订阅，就会发生这种情况。
In order for such a system to be built in an interoperable fashion, all watcherinfo subscribers MUST be prepared to install multiple subscriptions as a result of a multiplicity of NOTIFY messages in response to a single SUBSCRIBE.
为了以可互操作的方式构建这样一个系统，所有watcherinfo订阅者都必须准备好安装多个订阅，因为响应单个订阅会有多个NOTIFY消息。
Another approach for handling the server multiplicity problem is to use state agents. See Section 4.11 for details.
处理服务器多重性问题的另一种方法是使用状态代理。详见第4.11节。
RFC 3265 [1] mandates that packages define a maximum rate of notifications for their package.
RFC 3265[1]要求包定义其包的最大通知速率。
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate watcherinfo notifications for a single watcherinfo subscriber at a rate faster than once every 5 seconds.
出于拥塞控制的原因，重要的是通知速率不要过高。因此，建议服务器不要以超过每5秒一次的速度为单个watcherinfo订阅服务器生成watcherinfo通知。
RFC 3265 [1] asks packages to consider the role of state agents in their design.
RFC 3265（1）要求包考虑状态代理在其设计中的作用。
State agents play an important role in this package. As discussed in Section 4.9, there may be a multiplicity of servers sharing the load of subscriptions for a particular package. A watcherinfo
国家代理人在这一方案中发挥着重要作用。如第4.9节所述，可能有多个服务器共享特定包的订阅负载。守望者
subscription might require subscription state spread across all of those servers. To handle that, a farm of state agents can be used. Each of these state agents would know the entire watcherinfo state for some set of resources. The means by which the state agents would determine the full watcherinfo state is outside the scope of this specification. When a watcherinfo subscription is received, it would be routed to a state agent that has the full watcherinfo state for the requested resource. This server would accept the watcherinfo subscription (assuming it was authorized, of course), and generate watcherinfo notifications as the watcherinfo state changed. The watcherinfo subscriber would only have a single dialog in this case.
订阅可能要求订阅状态分布在所有这些服务器上。为了解决这一问题，可以使用一批国家特工。这些状态代理中的每一个都知道某一组资源的整个watcherinfo状态。状态代理确定完整watcherinfo状态的方法不在本规范的范围内。收到watcherinfo订阅时，它将被路由到具有请求资源的完整watcherinfo状态的状态代理。此服务器将接受watcherinfo订阅（当然，假设它已被授权），并在watcherinfo状态更改时生成watcherinfo通知。在这种情况下，watcherinfo订阅服务器将只有一个对话框。
The following section discusses an example application and call flows using the watcherinfo package.
以下部分讨论使用watcherinfo包的示例应用程序和调用流。
In this example, a user Joe, sip:joe@example.com provides presence through the example.com presence server. Joe subscribes to his own watcher information, in order to learn about people who subscribe to his presence, so that he can approve or reject their subscriptions. Joe sends the following SUBSCRIBE request:
在此示例中，用户Joe，sip：joe@example.com通过example.com状态服务器提供状态。Joe订阅他自己的watcher信息，以便了解订阅他的状态的人，以便他可以批准或拒绝他们的订阅。Joe发送以下订阅请求：
SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@pc34.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:joe@pc34.example.com
Event: presence.winfo
Max-Forwards: 70
SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@pc34.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:joe@pc34.example.com
Event: presence.winfo
Max-Forwards: 70
The server responds with a 401 to authenticate, and Joe resubmits the SUBSCRIBE with credentials (message not shown). The server then authorizes the subscription, since it allows Joe to subscribe to his own watcher information for presence. It responds with a 200 OK:
服务器响应401进行身份验证，Joe使用凭据重新提交SUBSCRIBE（消息未显示）。然后服务器授权订阅，因为它允许Joe订阅他自己的观察者信息以供查看。它的响应为200 OK：
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
;received=192.0.2.8
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@pc34.example.com
CSeq: 9988 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
Event: presence.winfo
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
;received=192.0.2.8
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@pc34.example.com
CSeq: 9988 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
Event: presence.winfo
The server then sends a NOTIFY with the current state of presence.winfo for joe@example.com:
然后，服务器发送一个带有当前状态presence.winfo的通知joe@example.com:
NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ...
通知sip：joe@pc34.example.comSIP/2.0 Via:SIP/2.0/UDP server19.example.com；分支=z9hG4bKnasaii来源：sip:joe@example.com;tag=xyzygg To:sip:joe@example.com;tag=123aa9呼叫ID:9987@pc34.example.comCSeq:1288通知联系人：sip:server19.example.com事件：presence.winfo订阅状态：active Max-Forwards:70内容类型：application/watcherinfo+xml内容长度：。。。
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:joe@example.com" package="presence">
<watcher id="77ajsyy76" event="subscribe"
status="pending">sip:A@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:joe@example.com" package="presence">
<watcher id="77ajsyy76" event="subscribe"
status="pending">sip:A@example.com</watcher>
</watcher-list>
</watcherinfo>
Joe then responds with a 200 OK to the NOTIFY:
然后，Joe以200 OK响应通知：
SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY
SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY
The NOTIFY tells Joe that user A currently has a pending subscription. Joe then authorizes A's subscription through some means. This causes a change in the status of the subscription (which moves from pending to active), and the delivery of another notification:
通知告诉Joe用户A当前有一个挂起的订阅。然后，Joe通过某种方式授权A的订阅。这会导致订阅状态发生变化（从挂起状态变为活动状态），并发送另一个通知：
NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ...
通知sip：joe@pc34.example.comSIP/2.0 Via:SIP/2.0/UDP server19.example.com；branch=z9hG4bKnasaij发件人：sip:joe@example.com;tag=xyzygg To:sip:joe@example.com;tag=123aa9呼叫ID:9987@pc34.example.comCSeq:1289通知联系人：sip:server19.example.com事件：presence.winfo订阅状态：active Max Forwards:70内容类型：application/watcherinfo+xml内容长度：。。。
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="1" state="partial">
<watcher-list resource="sip:joe@example.com" package="presence">
<watcher id="77ajsyy76" event="approved"
status="active">sip:A@example.com</watcher>
</watcher-list>
</watcherinfo>
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="1" state="partial">
<watcher-list resource="sip:joe@example.com" package="presence">
<watcher id="77ajsyy76" event="approved"
status="active">sip:A@example.com</watcher>
</watcher-list>
</watcherinfo>
B then responds with a 200 OK to the NOTIFY:
B然后以200 OK响应通知：
SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1289 NOTIFY
SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1289 NOTIFY
Watcher information generates notifications about changes in the state of watchers for a particular resource. It is possible for a single resource to have many watchers, resulting in the possibility of a large volume of notifications. This makes watcherinfo subscription a potential tool for denial of service attacks. Preventing these can be done through a combination of sensible authorization policies and good operating principles.
观察者信息生成有关特定资源的观察者状态更改的通知。单个资源可能有多个观察者，这可能导致大量通知。这使得WaterInfo订阅成为拒绝服务攻击的潜在工具。可以通过合理的授权策略和良好的操作原则来防止这些问题。
First, when a resource has a lot of watchers, watcherinfo subscriptions to that resource should only be allowed from explicitly authorized entities, whose identity has been properly authenticated. That prevents a watcherinfo NOTIFY stream from being generated from subscriptions made by an attacker.
首先，当一个资源有很多观察者时，对该资源的watcherinfo订阅应该只允许来自明确授权的实体，这些实体的身份已经过正确的身份验证。这可防止攻击者通过订阅生成watcherinfo NOTIFY流。
Even when watcherinfo subscriptions are properly authenticated, there are still potential attacks. For example, consider a valid user, T, who is to be the target of an attack. T has subscribed to their own watcher information. The attacker generates a large number of subscriptions (not watcherinfo subscriptions). If the server creates subscription state for unauthenticated subscriptions, and reports those changes in watcherinfo notifications, user T would receive a flood of watcherinfo notifications. In fact, if the server generates a watcherinfo notification when the subscription is created, and another when it is terminated, there will be an amplification by a factor of two. The amplification would actually be substantial if the server generates full state in each watcherinfo notification. Indeed, the amount of data sent to T would be the square of the data generated by the attacker! Each of the N subscriptions generated by the attacker would result in a watcherinfo NOTIFY being sent to T, each of which would report on up to N watchers. To avoid this, servers should never generate subscription state for unauthenticated SUBSCRIBE requests, and should never generate watcherinfo notifications for them either.
即使watcherinfo订阅经过正确的身份验证，仍然存在潜在的攻击。例如，考虑一个有效的用户T，它是攻击的目标。T已经订阅了他们自己的观察者信息。攻击者生成大量订阅（而不是watcherinfo订阅）。如果服务器为未经验证的订阅创建订阅状态，并在watcherinfo通知中报告这些更改，则用户T将收到大量watcherinfo通知。事实上，如果服务器在创建订阅时生成一个watcherinfo通知，在终止订阅时生成另一个watcherinfo通知，则会放大两倍。如果服务器在每个watcherinfo通知中生成完整状态，那么放大的效果实际上是巨大的。实际上，发送到T的数据量是攻击者生成的数据的平方！攻击者生成的N个订阅中的每一个都会导致向T发送一个watcherinfo通知，每个通知都会报告多达N个观察者。为了避免这种情况，服务器不应该为未经验证的订阅请求生成订阅状态，也不应该为它们生成watcherinfo通知。
Watcher information indicates what users are interested in a particular resource. Depending on the package and the resource, this can be very sensitive information. For example, in the case of presence, the watcher information for some user represents the friends, family, and business relations of that person. This information can be used for a variety of malicious purposes.
观察者信息表示用户对特定资源感兴趣的内容。根据包和资源的不同，这可能是非常敏感的信息。例如，在存在的情况下，某些用户的观察者信息表示该用户的朋友、家人和业务关系。此信息可用于各种恶意目的。
One way in which this information can be revealed is eavesdropping. An attacker can observe watcherinfo notifications, and learn this information. To prevent that, watchers MAY use the sips URI scheme when subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 of RFC 3261).
透露这些信息的一种方式是窃听。攻击者可以观察WaterInfo通知并了解此信息。为了防止这种情况，观察者在订阅watcherinfo资源时可以使用sips URI方案。watcherinfo的通知程序必须支持TLS和SIP，就像它们是代理一样（参见RFC 3261第26.3.1节）。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
使用S/MIME的SIP加密可用于端到端传输订阅和通知请求。
Another way in which this information can be revealed is through spoofed subscriptions. These attacks can be prevented by authenticating and authorizing all watcherinfo subscriptions. In order for the notifier to authenticate the subscriber, it MAY use HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP Digest. This is a redundant requirement, however, since all SIP user agents are mandated to support it by RFC 3261.
另一种泄露信息的方式是通过欺骗订阅。通过对所有watcherinfo订阅进行身份验证和授权，可以防止这些攻击。为了让通知程序对订户进行身份验证，它可以使用HTTP摘要（RFC 3261的第22节）。因此，所有观察者都必须支持HTTP摘要。然而，这是一个冗余需求，因为RFC3261强制所有SIP用户代理支持它。
This specification registers an event template package as specified in Section 6.2 of RFC 3265 [1].
本规范按照RFC 3265[1]第6.2节的规定注册事件模板包。
Package Name: winfo
软件包名称：winfo
Template Package: yes
模板包：是
Published Specification: RFC 3857
已发布规范：RFC3857
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
联系人：Jonathan Rosenberg，jdrosen@jdrosen.net.
The authors would like to thank Adam Roach, Allison Mankin and Brian Stucker for their detailed comments.
作者要感谢亚当·罗奇、埃里森·曼金和布赖恩·斯图克的详细评论。
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[3] Rosenberg，J.，“基于可扩展标记语言（XML）的观察者信息格式”，RFC3858，2004年8月。
[4] 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.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, July 2004.
[5] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年7月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Jonathan Rosenberg dynamicsoft 600新泽西州帕西帕尼拉尼德斯广场07054
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。