Network Working Group A. B. Roach
Request for Comments: 3265 dynamicsoft
Updates: 2543 June 2002
Category: Standards Track
Network Working Group A. B. Roach
Request for Comments: 3265 dynamicsoft
Updates: 2543 June 2002
Category: Standards Track
Session Initiation Protocol (SIP)-Specific Event Notification
会话启动协议（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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.
本文档描述了会话启动协议（SIP）的扩展。此扩展的目的是提供一个可扩展的框架，通过该框架，SIP节点可以从远程节点请求指示已发生某些事件的通知。
Concrete uses of the mechanism described in this document may be standardized in the future.
本文件中所述机制的具体用途将来可能会标准化。
Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.
请注意，本文定义的事件通知机制并不打算成为所有类别的事件订阅和通知的通用基础设施。
Table of Contents
目录
1. Introduction........................................... 3
1.1. Overview of Operation.................................. 4
1.2. Documentation Conventions.............................. 4
2. Definitions............................................ 5
3. Node Behavior.......................................... 6
3.1. Description of SUBSCRIBE Behavior...................... 6
3.1.1. Subscription Duration.................................. 6
3.1.2. Identification of Subscribed Events and Event Classes.. 6
3.1.3. Additional SUBSCRIBE Header Values..................... 7
3.1.4. Subscriber SUBSCRIBE Behavior.......................... 7
3.1.5. Proxy SUBSCRIBE Behavior............................... 9
3.1.6. Notifier SUBSCRIBE Behavior............................ 10
1. Introduction........................................... 3
1.1. Overview of Operation.................................. 4
1.2. Documentation Conventions.............................. 4
2. Definitions............................................ 5
3. Node Behavior.......................................... 6
3.1. Description of SUBSCRIBE Behavior...................... 6
3.1.1. Subscription Duration.................................. 6
3.1.2. Identification of Subscribed Events and Event Classes.. 6
3.1.3. Additional SUBSCRIBE Header Values..................... 7
3.1.4. Subscriber SUBSCRIBE Behavior.......................... 7
3.1.5. Proxy SUBSCRIBE Behavior............................... 9
3.1.6. Notifier SUBSCRIBE Behavior............................ 10
3.2. Description of NOTIFY Behavior......................... 13
3.2.1. Identification of Reported Events, Event Classes, and
Current State.......................................... 13
3.2.2. Notifier NOTIFY Behavior............................... 14
3.2.3. Proxy NOTIFY Behavior.................................. 15
3.2.4. Subscriber NOTIFY Behavior............................. 16
3.3. General................................................ 18
3.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 18
3.3.2. CANCEL requests........................................ 18
3.3.3. Forking................................................ 18
3.3.4. Dialog creation and termination........................ 18
3.3.5. State Agents and Notifier Migration.................... 19
3.3.6. Polling Resource State................................. 20
3.3.7. Allow-Events header usage.............................. 21
3.3.8. PINT Compatibility..................................... 21
4. Event Packages......................................... 21
4.1. Appropriateness of Usage............................... 21
4.2. Event Template-packages................................ 22
4.3. Amount of State to be Conveyed......................... 22
4.3.1. Complete State Information............................. 23
4.3.2. State Deltas........................................... 23
4.4. Event Package Responsibilities......................... 24
4.4.1. Event Package Name..................................... 24
4.4.2. Event Package Parameters............................... 24
4.4.3. SUBSCRIBE Bodies....................................... 24
4.4.4. Subscription Duration.................................. 25
4.4.5. NOTIFY Bodies.......................................... 25
4.4.6. Notifier processing of SUBSCRIBE requests.............. 25
4.4.7. Notifier generation of NOTIFY requests................. 25
4.4.8. Subscriber processing of NOTIFY requests............... 26
4.4.9. Handling of forked requests............................ 26
4.4.10. Rate of notifications.................................. 26
4.4.11. State Agents........................................... 27
4.4.12. Examples............................................... 27
4.4.13. Use of URIs to Retrieve State.......................... 27
5. Security Considerations................................ 28
5.1. Access Control......................................... 28
5.2. Notifier Privacy Mechanism............................. 28
5.3. Denial-of-Service attacks.............................. 28
5.4. Replay Attacks......................................... 29
5.5. Man-in-the middle attacks.............................. 29
5.6. Confidentiality........................................ 29
6. IANA Considerations.................................... 30
6.1. Registration Information............................... 30
6.2. Registration Template.................................. 31
6.3. Header Field Names..................................... 31
6.4. Response Codes......................................... 32
7. Syntax................................................. 32
3.2. Description of NOTIFY Behavior......................... 13
3.2.1. Identification of Reported Events, Event Classes, and
Current State.......................................... 13
3.2.2. Notifier NOTIFY Behavior............................... 14
3.2.3. Proxy NOTIFY Behavior.................................. 15
3.2.4. Subscriber NOTIFY Behavior............................. 16
3.3. General................................................ 18
3.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 18
3.3.2. CANCEL requests........................................ 18
3.3.3. Forking................................................ 18
3.3.4. Dialog creation and termination........................ 18
3.3.5. State Agents and Notifier Migration.................... 19
3.3.6. Polling Resource State................................. 20
3.3.7. Allow-Events header usage.............................. 21
3.3.8. PINT Compatibility..................................... 21
4. Event Packages......................................... 21
4.1. Appropriateness of Usage............................... 21
4.2. Event Template-packages................................ 22
4.3. Amount of State to be Conveyed......................... 22
4.3.1. Complete State Information............................. 23
4.3.2. State Deltas........................................... 23
4.4. Event Package Responsibilities......................... 24
4.4.1. Event Package Name..................................... 24
4.4.2. Event Package Parameters............................... 24
4.4.3. SUBSCRIBE Bodies....................................... 24
4.4.4. Subscription Duration.................................. 25
4.4.5. NOTIFY Bodies.......................................... 25
4.4.6. Notifier processing of SUBSCRIBE requests.............. 25
4.4.7. Notifier generation of NOTIFY requests................. 25
4.4.8. Subscriber processing of NOTIFY requests............... 26
4.4.9. Handling of forked requests............................ 26
4.4.10. Rate of notifications.................................. 26
4.4.11. State Agents........................................... 27
4.4.12. Examples............................................... 27
4.4.13. Use of URIs to Retrieve State.......................... 27
5. Security Considerations................................ 28
5.1. Access Control......................................... 28
5.2. Notifier Privacy Mechanism............................. 28
5.3. Denial-of-Service attacks.............................. 28
5.4. Replay Attacks......................................... 29
5.5. Man-in-the middle attacks.............................. 29
5.6. Confidentiality........................................ 29
6. IANA Considerations.................................... 30
6.1. Registration Information............................... 30
6.2. Registration Template.................................. 31
6.3. Header Field Names..................................... 31
6.4. Response Codes......................................... 32
7. Syntax................................................. 32
7.1. New Methods............................................ 32
7.1.1. SUBSCRIBE method....................................... 34
7.1.2. NOTIFY method.......................................... 34
7.2. New Headers............................................ 34
7.2.1. "Event" header......................................... 34
7.2.2. "Allow-Events" Header.................................. 35
7.2.3. "Subscription-State" Header............................ 35
7.3. New Response Codes..................................... 35
7.3.1. "202 Accepted" Response Code........................... 35
7.3.2. "489 Bad Event" Response Code.......................... 35
7.4. Augmented BNF Definitions.............................. 35
8. Normative References................................... 36
9. Informative References................................. 37
10. Acknowledgements....................................... 37
11. Notice Regarding Intellectual Property Rights.......... 37
12. Author's Address....................................... 37
13. Full Copyright Statement............................... 38
7.1. New Methods............................................ 32
7.1.1. SUBSCRIBE method....................................... 34
7.1.2. NOTIFY method.......................................... 34
7.2. New Headers............................................ 34
7.2.1. "Event" header......................................... 34
7.2.2. "Allow-Events" Header.................................. 35
7.2.3. "Subscription-State" Header............................ 35
7.3. New Response Codes..................................... 35
7.3.1. "202 Accepted" Response Code........................... 35
7.3.2. "489 Bad Event" Response Code.......................... 35
7.4. Augmented BNF Definitions.............................. 35
8. Normative References................................... 36
9. Informative References................................. 37
10. Acknowledgements....................................... 37
11. Notice Regarding Intellectual Property Rights.......... 37
12. Author's Address....................................... 37
13. Full Copyright Statement............................... 38
The ability to request asynchronous notification of events proves useful in many types of SIP services for which cooperation between end-nodes is required. Examples of such services include automatic callback services (based on terminal state events), buddy lists (based on user presence events), message waiting indications (based on mailbox state change events), and PSTN and Internet Internetworking (PINT) [2] status (based on call state events).
请求异步事件通知的能力在许多类型的SIP服务中证明是有用的，这些服务需要终端节点之间的协作。此类服务的示例包括自动回叫服务（基于终端状态事件）、好友列表（基于用户存在事件）、消息等待指示（基于邮箱状态更改事件）以及PSTN和互联网互联（PINT）[2]状态（基于呼叫状态事件）。
The methods described in this document provide a framework by which notification of these events can be ordered.
本文档中描述的方法提供了一个框架，通过该框架可以对这些事件的通知进行排序。
The event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. Meeting requirements for the general problem set of subscription and notification is far too complex for a single protocol. Our goal is to provide a SIP-specific framework for event notification which is not so complex as to be unusable for simple features, but which is still flexible enough to provide powerful services. Note, however, that event packages based on this framework may define arbitrarily elaborate rules which govern the subscription and notification for the events or classes of events they describe.
本文定义的事件通知机制并不打算成为所有类别的事件订阅和通知的通用基础设施。满足订阅和通知的一般问题集的要求对于单个协议来说太复杂了。我们的目标是为事件通知提供一个特定于SIP的框架，该框架不太复杂，不能用于简单的功能，但仍然足够灵活，可以提供强大的服务。但是，请注意，基于此框架的事件包可能会定义任意详细的规则，这些规则用于管理它们所描述的事件或事件类的订阅和通知。
This document does not describe an extension which may be used directly; it must be extended by other documents (herein referred to as "event packages"). In object-oriented design terminology, it may
本文件不描述可直接使用的扩展；必须通过其他文件（此处称为“事件包”）进行扩展。在面向对象设计术语中，它可能
be thought of as an abstract base class which must be derived into an instantiatable class by further extensions. Guidelines for creating these extensions are described in section 4.
被认为是一个抽象的基类，必须通过进一步的扩展派生成一个可实例化的类。第4节介绍了创建这些扩展的指导原则。
The general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change.
一般概念是，网络中的实体可以订阅网络中各种资源或呼叫的资源或呼叫状态，并且这些实体（或代表它们的实体）可以在这些状态改变时发送通知。
A typical flow of messages would be:
典型的消息流是：
Subscriber Notifier
|-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information
|--------200------->|
|<------NOTIFY----- | Return current state information
|--------200------->|
Subscriber Notifier
|-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information
|--------200------->|
|<------NOTIFY----- | Return current state information
|--------200------->|
Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE messages.
订阅已过期，必须由后续订阅消息刷新。
There are several paragraphs throughout this document which provide motivational or clarifying text. Such passages are non-normative, and are provided only to assist with reader comprehension. These passages are set off from the remainder of the text by being indented thus:
本文件中有几个段落提供了激励性或澄清性文本。这些段落是非规范性的，仅用于帮助读者理解。这些段落通过缩进的方式与正文的其余部分隔开：
This is an example of non-normative explanatory text. It does not form part of the specification, and is used only for clarification.
这是非规范性解释性文本的一个例子。它不构成本规范的一部分，仅用于澄清。
Numbers in square brackets (e.g., [1]) denote a reference to one of the entries in the reference sections; see sections 8 and 9.
方括号中的数字（例如，[1]）表示引用章节中的一个条目；见第8节和第9节。
The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5].
所有大写术语“必须”、“应该”、“可以”、“不应该”、“不得”和“建议”均按照RFC 2119[5]中的定义使用。
The use of quotation marks next to periods and commas follows the convention used by the American Mathematical Society; although contrary to traditional American English convention, this usage lends clarity to certain passages.
句号和逗号旁边的引号的使用遵循美国数学学会的惯例；尽管与传统的美式英语习惯相反，这种用法使某些段落更加清晰。
Event Package: An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by this document required to convey such state information.
事件包：事件包是一个附加规范，它定义了一组状态信息，由通知程序向订阅服务器报告。事件包还基于本文档定义的框架定义了进一步的语法和语义，该框架是传递此类状态信息所必需的。
Event Template-Package: An event template-package is a special kind of event package which defines a set of states which may be applied to all possible event packages, including itself.
事件模板包：事件模板包是一种特殊的事件包，它定义了一组可应用于所有可能的事件包（包括其自身）的状态。
Notification: Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource.
通知：通知是通知程序向订户发送通知消息以通知订户资源状态的行为。
Notifier: A notifier is a user agent which generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept SUBSCRIBE requests to create subscriptions.
通知程序：通知程序是一个用户代理，它生成通知请求，以便通知订阅者资源的状态。通知程序通常也接受订阅请求以创建订阅。
State Agent: A state agent is a notifier which publishes state information on behalf of a resource; in order to do so, it may need to gather such state information from multiple sources. State agents always have complete state information for the resource for which they are creating notifications.
状态代理：状态代理是代表资源发布状态信息的通知程序；为此，可能需要从多个来源收集此类状态信息。状态代理始终具有为其创建通知的资源的完整状态信息。
Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions.
订阅者：订阅者是从通知者接收通知请求的用户代理；这些通知请求包含有关订阅服务器感兴趣的资源状态的信息。订阅者通常还生成订阅请求并将其发送给通知程序以创建订阅。
Subscription: A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier.
订阅：订阅是与对话框关联的一组应用程序状态。此应用程序状态包括指向关联对话框的指针、事件包名称以及可能的标识令牌。事件包将定义其他订阅状态信息。根据定义，订阅存在于订阅服务器和通知程序中。
Subscription Migration: Subscription migration is the act of moving a subscription from one notifier to another notifier.
订阅迁移：订阅迁移是将订阅从一个通知程序移动到另一个通知程序的行为。
The SUBSCRIBE method is used to request current state and state updates from a remote node.
SUBSCRIBE方法用于从远程节点请求当前状态和状态更新。
SUBSCRIBE requests SHOULD contain an "Expires" header (defined in SIP [1]). This expires value indicates the duration of the subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE message on the same dialog as defined in SIP [1].
订阅请求应包含一个“Expires”头（在SIP[1]中定义）。此expires值指示订阅的持续时间。为了使订阅在“Expires”（过期）报头中通信的持续时间之后保持有效，订阅方需要在SIP[1]中定义的同一对话框中使用新的订阅消息定期刷新订阅。
If no "Expires" header is present in a SUBSCRIBE request, the implied default is defined by the event package being used.
如果订阅请求中不存在“Expires”头，则所使用的事件包将定义隐含的默认值。
200-class responses to SUBSCRIBE requests also MUST contain an "Expires" header. The period of time in the response MAY be shorter but MUST NOT be longer than specified in the request. The period of time in the response is the one which defines the duration of the subscription.
订阅请求的200个类响应还必须包含“Expires”头。响应中的时间段可能较短，但不得长于请求中指定的时间段。响应中的时间段是定义订阅持续时间的时间段。
An "expires" parameter on the "Contact" header has no semantics for SUBSCRIBE and is explicitly not equivalent to an "Expires" header in a SUBSCRIBE request or response.
“Contact”头上的“expires”参数对于SUBSCRIBE没有语义，并且显式地不等同于SUBSCRIBE请求或响应中的“expires”头。
A natural consequence of this scheme is that a SUBSCRIBE with an "Expires" of 0 constitutes a request to unsubscribe from an event.
此方案的一个自然结果是，“Expires”为0的订阅构成取消订阅事件的请求。
In addition to being a request to unsubscribe, a SUBSCRIBE message with "Expires" of 0 also causes a fetch of state; see section 3.3.6.
除了作为取消订阅的请求之外，“Expires”为0的订阅消息还导致获取状态；见第3.3.6节。
Notifiers may also wish to cancel subscriptions to events; this is useful, for example, when the resource to which a subscription refers is no longer available. Further details on this mechanism are discussed in section 3.2.2.
通知者也可能希望取消对事件的订阅；例如，当订阅引用的资源不再可用时，这非常有用。第3.2.2节讨论了该机制的更多细节。
Identification of events is provided by three pieces of information: Request URI, Event Type, and (optionally) message body.
事件的标识由三条信息提供：请求URI、事件类型和（可选）消息体。
The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity per the request routing procedures outlined in SIP [1]. It also contains enough information to identify the resource for which event notification is desired, but not necessarily enough information to uniquely identify the nature of the event (e.g., "sip:adam@dynamicsoft.com" would be an appropriate URI to subscribe to for my presence state; it would also be an appropriate URI to subscribe to the state of my voice mailbox).
最重要的是，订阅请求的请求URI包含足够的信息，可以根据SIP[1]中概述的请求路由过程将请求路由到适当的实体。它还包含足够的信息来标识需要事件通知的资源，但不一定包含足够的信息来唯一标识事件的性质（例如，“sip:adam@dynamicsoft.com"将是订阅我的状态的适当URI；它也是订阅我的语音邮箱状态的适当URI）。
Subscribers MUST include exactly one "Event" header in SUBSCRIBE requests, indicating to which event or class of events they are subscribing. The "Event" header will contain a token which indicates the type of state for which a subscription is being requested. This token will be registered with the IANA and will correspond to an event package which further describes the semantics of the event or event class. The "Event" header MAY also contain an "id" parameter. This "id" parameter, if present, contains an opaque token which identifies the specific subscription within a dialog. An "id" parameter is only valid within the scope of a single dialog.
订阅者必须在订阅请求中只包含一个“事件”头，指示他们订阅的事件或事件类别。“事件”标头将包含一个令牌，该令牌指示请求订阅的状态类型。该令牌将向IANA注册，并将对应于一个事件包，该事件包将进一步描述事件或事件类的语义。“事件”标题还可能包含“id”参数。此“id”参数（如果存在）包含一个不透明令牌，用于标识对话框中的特定订阅。“id”参数仅在单个对话框的范围内有效。
If the event package to which the event token corresponds defines behavior associated with the body of its SUBSCRIBE requests, those semantics apply.
如果事件令牌所对应的事件包定义了与其订阅请求主体相关联的行为，则这些语义适用。
Event packages may also define parameters for the Event header; if they do so, they must define the semantics for such parameters.
事件包还可以定义事件头的参数；如果他们这样做，他们必须定义这些参数的语义。
Because SUBSCRIBE requests create a dialog as defined in SIP [1], they MAY contain an "Accept" header. This header, if present, indicates the body formats allowed in subsequent NOTIFY requests. Event packages MUST define the behavior for SUBSCRIBE requests without "Accept" headers; usually, this will connote a single, default body type.
因为订阅请求创建了SIP[1]中定义的对话框，所以它们可能包含一个“Accept”头。此标头（如果存在）指示后续NOTIFY请求中允许的正文格式。事件包必须定义没有“接受”头的订阅请求的行为；通常，这将意味着一个单一的默认主体类型。
Header values not described in this document are to be interpreted as described in SIP [1].
本文件中未描述的标题值应按照SIP[1]中的说明进行解释。
SUBSCRIBE is a dialog-creating method, as described in SIP [1].
SUBSCRIBE是一种对话框创建方法，如SIP[1]中所述。
When a subscriber wishes to subscribe to a particular state for a resource, it forms a SUBSCRIBE message. If the initial SUBSCRIBE
当订户希望订阅资源的特定状态时，它会形成一条订阅消息。如果最初的订阅
represents a request outside of a dialog (as it typically will), its construction follows the procedures outlined in SIP [1] for UAC request generation outside of a dialog.
表示对话框外部的请求（通常会这样），其构造遵循SIP[1]中概述的在对话框外部生成UAC请求的过程。
This SUBSCRIBE request will be confirmed with a final response. 200-class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately. A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted.
此订阅请求将得到最终响应的确认。200个类响应表示订阅已被接受，并且将立即发送通知。200响应表示订阅已被接受，并且用户被授权订阅所请求的资源。202响应仅指示订阅已被理解，并且授权可能已被授予，也可能未被授予。
The "Expires" header in a 200-class response to SUBSCRIBE indicates the actual duration for which the subscription will remain active (unless refreshed).
订阅200类响应中的“Expires”标头指示订阅将保持活动状态的实际持续时间（除非刷新）。
Non-200 class final responses indicate that no subscription or dialog has been created, and no subsequent NOTIFY message will be sent. All non-200 class responses (with the exception of "489", described herein) have the same meanings and handling as described in SIP [1].
非200类最终响应表示尚未创建订阅或对话框，并且不会发送后续通知消息。所有非200类响应（本文所述的“489”除外）具有与SIP[1]中所述相同的含义和处理。
A SUBSCRIBE request MAY include an "id" parameter in its "Event" header to allow differentiation between multiple subscriptions in the same dialog.
订阅请求可以在其“事件”头中包含“id”参数，以允许在同一对话框中区分多个订阅。
At any time before a subscription expires, the subscriber may refresh the timer on such a subscription by sending another SUBSCRIBE request on the same dialog as the existing subscription, and with the same "Event" header "id" parameter (if one was present in the initial subscription). The handling for such a request is the same as for the initial creation of a subscription except as described below.
在订阅到期之前的任何时候，订户可以通过在与现有订阅相同的对话框上发送另一个订阅请求，并使用相同的“事件”标题“id”参数（如果初始订阅中存在）来刷新此类订阅的计时器。除下文所述外，此类请求的处理与初始创建订阅的处理相同。
If the initial SUBSCRIBE message contained an "id" parameter on the "Event" header, then refreshes of the subscription must also contain an identical "id" parameter; they will otherwise be considered new subscriptions in an existing dialog.
如果初始订阅消息在“事件”标头上包含“id”参数，则订阅的刷新也必须包含相同的“id”参数；否则，它们将被视为现有对话框中的新订阅。
If a SUBSCRIBE request to refresh a subscription receives a "481" response, this indicates that the subscription has been terminated and that the subscriber did not receive notification of this fact. In this case, the subscriber should consider the subscription invalid. If the subscriber wishes to re-subscribe to the state, he does so by composing an unrelated initial SUBSCRIBE request with a freshly-generated Call-ID and a new, unique "From" tag (see section 3.1.4.1.)
如果刷新订阅的订阅请求收到“481”响应，则表示订阅已终止，并且订阅方未收到此事实的通知。在这种情况下，订阅服务器应该考虑订阅无效。如果订阅者希望重新订阅该状态，他可以使用新生成的呼叫ID和新的、唯一的“From”标记（见第3.1.4.1节）编写一个不相关的初始订阅请求
If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the original subscription is still considered valid for the duration of the most recently known "Expires" value as negotiated by SUBSCRIBE and its response, or as communicated by NOTIFY in the "Subscription-State" header "expires" parameter.
如果刷新订阅的订阅请求因非481响应而失败，则原始订阅在订阅及其响应协商的最新已知“Expires”值的持续时间内，或在“订阅状态”标头“Expires”参数中通知的持续时间内，仍然视为有效。
Note that many such errors indicate that there may be a problem with the network or the notifier such that no further NOTIFY messages will be received.
请注意，许多此类错误表明网络或通知程序可能存在问题，因此不会收到进一步的通知消息。
Unsubscribing is handled in the same way as refreshing of a subscription, with the "Expires" header set to "0". Note that a successful unsubscription will also trigger a final NOTIFY message.
取消订阅的处理方式与刷新订阅相同，“Expires”标题设置为“0”。请注意，成功取消订阅还将触发最终通知消息。
The subscriber can expect to receive a NOTIFY message from each node which has processed a successful subscription or subscription refresh. Until the first NOTIFY message arrives, the subscriber should consider the state of the subscribed resource to be in a neutral state. Documents which define new event packages MUST define this "neutral state" in such a way that makes sense for their application (see section 4.4.7.).
订户可以期望从已成功处理订阅或订阅刷新的每个节点接收通知消息。在第一通知消息到达之前，订阅者应该考虑订阅资源的状态处于中立状态。定义新事件包的文档必须以对其应用有意义的方式定义此“中立状态”（见第4.4.7节）。
Due to the potential for both out-of-order messages and forking, the subscriber MUST be prepared to receive NOTIFY messages before the SUBSCRIBE transaction has completed.
由于可能出现无序消息和分叉，订阅者必须在订阅事务完成之前准备好接收通知消息。
Except as noted above, processing of this NOTIFY is the same as in section 3.2.4.
除上述情况外，本通知的处理与第3.2.4节相同。
Proxies need no additional behavior beyond that described in SIP [1] to support SUBSCRIBE. If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests.
除了SIP[1]中描述的行为之外，代理不需要其他行为来支持订阅。如果代理希望看到给定对话框的所有订阅和通知请求，它必须记录初始订阅路由和建立通知请求的任何对话框。此类代理还应记录路由所有其他订阅和通知请求。
Note that subscribers and notifiers may elect to use S/MIME encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies cannot rely on being able to access any information that is not explicitly required to be proxy-readable by SIP [1].
请注意，订阅者和通知者可以选择对订阅和通知请求使用S/MIME加密；因此，代理不能依赖于能够访问SIP[1]不明确要求代理可读的任何信息。
In no case should a SUBSCRIBE transaction extend for any longer than the time necessary for automated processing. In particular, notifiers MUST NOT wait for a user response before returning a final response to a SUBSCRIBE request.
在任何情况下，订阅事务的扩展时间都不得超过自动处理所需的时间。特别是，通知程序在返回对订阅请求的最终响应之前，不能等待用户响应。
This requirement is imposed primarily to prevent the non-INVITE transaction timeout timer F (see [1]) from firing during the SUBSCRIBE transaction, since interaction with a user would often exceed 64*T1 seconds.
此要求主要用于防止在订阅事务期间触发非邀请事务超时计时器F（参见[1]），因为与用户的交互通常会超过64*T1秒。
The notifier SHOULD check that the event package specified in the "Event" header is understood. If not, the notifier SHOULD return a "489 Bad Event" response to indicate that the specified event/event class is not understood.
通知程序应检查“事件”标题中指定的事件包是否已被理解。如果没有，通知程序应返回“489坏事件”响应，以指示指定的事件/事件类未被理解。
The notifier SHOULD also perform any necessary authentication and authorization per its local policy. See section 3.1.6.3.
通知程序还应根据其本地策略执行任何必要的身份验证和授权。见第3.1.6.3节。
The notifier MAY also check that the duration in the "Expires" header is not too small. If and only if the expiration interval is greater than zero AND smaller than one hour AND less than a notifier-configured minimum, the notifier MAY return a "423 Interval too small" error which contains a "Min-Expires" header field. The "Min-Expires" header field is described in SIP [1].
通知程序还可以检查“Expires”头中的持续时间是否过小。如果且仅当过期间隔大于零且小于一小时且小于通知程序配置的最小值时，通知程序可能返回“423 interval To small”错误，该错误包含“Min Expires”标头字段。SIP[1]中描述了“Min Expires”头字段。
If the notifier is able to immediately determine that it understands the event package, that the authenticated subscriber is authorized to subscribe, and that there are no other barriers to creating the subscription, it creates the subscription and a dialog (if necessary), and returns a "200 OK" response (unless doing so would reveal authorization policy in an undesirable fashion; see section 5.2.).
如果通知程序能够立即确定它了解事件包、经过身份验证的订阅者被授权订阅，并且创建订阅没有其他障碍，那么它将创建订阅和对话框（如有必要），并返回“200 OK”响应（除非这样做会以不希望的方式暴露授权策略；请参见第5.2节。）。
If the notifier cannot immediately create the subscription (e.g., it needs to wait for user input for authorization, or is acting for another node which is not currently reachable), or wishes to mask authorization policy, it will return a "202 Accepted" response. This response indicates that the request has been received and understood, but does not necessarily imply that the subscription has been authorized yet.
如果通知程序无法立即创建订阅（例如，它需要等待用户输入以进行授权，或者正在代理当前无法访问的另一个节点），或者希望屏蔽授权策略，它将返回“202已接受”响应。此响应表示已接收并理解请求，但不一定表示订阅已获得授权。
When a subscription is created in the notifier, it stores the event package name and the "Event" header "id" parameter (if present) as part of the subscription information.
在通知程序中创建订阅时，它将事件包名称和“事件”标题“id”参数（如果存在）存储为订阅信息的一部分。
The "Expires" values present in SUBSCRIBE 200-class responses behave in the same way as they do in REGISTER responses: the server MAY shorten the interval, but MUST NOT lengthen it.
SUBSCRIBE 200类响应中存在的“Expires”值的行为与REGISTER响应中的行为相同：服务器可以缩短间隔，但不能延长间隔。
If the duration specified in a SUBSCRIBE message is unacceptably short, the notifier may be able to send a 423 response, as described earlier in this section.
如果订阅消息中指定的持续时间短得令人无法接受，则通知程序可能能够发送423响应，如本节前面所述。
200-class responses to SUBSCRIBE requests will not generally contain any useful information beyond subscription duration; their primary purpose is to serve as a reliability mechanism. State information will be communicated via a subsequent NOTIFY request from the notifier.
订阅请求的200类响应通常不会包含订阅持续时间以外的任何有用信息；其主要目的是作为可靠性机制。状态信息将通过来自通知者的后续通知请求进行通信。
The other response codes defined in SIP [1] may be used in response to SUBSCRIBE requests, as appropriate.
SIP[1]中定义的其他响应代码可用于响应订阅请求（视情况而定）。
Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. See section 3.2.2. for further details on NOTIFY message generation.
成功接受或刷新订阅后，通知程序必须立即发送通知消息，以将当前资源状态告知订阅服务器。此通知消息在订阅响应创建的同一对话框中发送。如果资源在处理SUBSCRIBE消息时没有有意义的状态，则此NOTIFY消息可能包含空正文或中性正文。见第3.2.2节。有关NOTIFY消息生成的详细信息。
Note that a NOTIFY message is always sent immediately after any 200- class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized.
请注意，无论订阅是否已被授权，在订阅请求的任何200类响应之后，都会立即发送NOTIFY消息。
Privacy concerns may require that notifiers apply policy to determine whether a particular subscriber is authorized to subscribe to a certain set of events. Such policy may be defined by mechanisms such as access control lists or real-time interaction with a user. In general, authorization of subscribers prior to authentication is not particularly useful.
隐私问题可能要求通知者应用策略来确定特定订阅者是否有权订阅特定的事件集。这种策略可以由诸如访问控制列表或与用户的实时交互等机制来定义。一般来说，在身份验证之前对订阅者进行授权并不特别有用。
SIP authentication mechanisms are discussed in SIP [1]. Note that, even if the notifier node typically acts as a proxy, authentication for SUBSCRIBE requests will always be performed via a "401" response, not a "407;" notifiers always act as a user agents when accepting subscriptions and sending notifications.
SIP认证机制在SIP[1]中进行了讨论。注意，即使通知程序节点通常充当代理，订阅请求的身份验证也将始终通过“401”响应而不是“407”响应执行；在接受订阅和发送通知时，通知程序始终充当用户代理。
Of course, when acting as a proxy, a node will perform normal proxy authentication (using 407). The foregoing explanation is a reminder that notifiers are always UAs, and as such perform UA authentication.
当然，当充当代理时，节点将执行正常的代理身份验证（使用407）。前面的解释提醒我们，通知者总是UAs，因此执行UA身份验证。
If authorization fails based on an access list or some other automated mechanism (i.e., it can be automatically authoritatively determined that the subscriber is not authorized to subscribe), the notifier SHOULD reply to the request with a "403 Forbidden" or "603 Decline" response, unless doing so might reveal information that should stay private; see section 5.2.
如果基于访问列表或某些其他自动机制授权失败（即，可以自动权威地确定订阅者未被授权订阅），通知者应使用“403禁止”或“603拒绝”响应回复请求，除非这样做可能会泄露应保密的信息；见第5.2节。
If the notifier owner is interactively queried to determine whether a subscription is allowed, a "202 Accept" response is returned immediately. Note that a NOTIFY message is still formed and sent under these circumstances, as described in the previous section.
如果以交互方式查询通知程序所有者以确定是否允许订阅，则会立即返回“202接受”响应。请注意，如前一节所述，在这些情况下，仍然会生成并发送通知消息。
If subscription authorization was delayed and the notifier wishes to convey that such authorization has been declined, it may do so by sending a NOTIFY message containing a "Subscription-State" header with a value of "terminated" and a reason parameter of "rejected".
如果订阅授权被延迟，并且通知者希望传达该授权已被拒绝，则其可以通过发送包含“订阅状态”标头的通知消息来实现，该标头的值为“终止”，原因参数为“拒绝”。
When a notifier receives a subscription refresh, assuming that the subscriber is still authorized, the notifier updates the expiration time for the subscription. As with the initial subscription, the server MAY shorten the amount of time until expiration, but MUST NOT increase it. The final expiration time is placed in the "Expires" header in the response. If the duration specified in a SUBSCRIBE message is unacceptably short, the notifier SHOULD respond with a "423 Subscription Too Brief" message.
当通知程序接收到订阅刷新时，假设订阅服务器仍被授权，通知程序将更新订阅的过期时间。与初始订阅一样，服务器可以缩短到期前的时间，但不能增加时间。最后的过期时间放在响应的“Expires”标题中。如果订阅消息中指定的持续时间短得令人无法接受，通知程序应以“423订阅太短”消息响应。
If no refresh for a notification address is received before its expiration time, the subscription is removed. When removing a subscription, the notifier SHOULD send a NOTIFY message with a "Subscription-State" value of "terminated" to inform it that the subscription is being removed. If such a message is sent, the "Subscription-State" header SHOULD contain a "reason=timeout" parameter.
如果在通知地址过期之前未收到任何刷新，则订阅将被删除。删除订阅时，通知程序应发送一条“订阅状态”值为“已终止”的通知消息，通知其订阅正在被删除。如果发送了这样的消息，“订阅状态”标头应包含“reason=timeout”参数。
The sending of a NOTIFY when a subscription expires allows the corresponding dialog to be terminated, if appropriate.
在订阅过期时发送通知，可以在适当的情况下终止相应的对话框。
NOTIFY messages are sent to inform subscribers of changes in state to which the subscriber has a subscription. Subscriptions are typically put in place using the SUBSCRIBE method; however, it is possible that other means have been used.
发送NOTIFY消息是为了通知订阅服务器订阅状态的更改。订阅通常使用SUBSCRIBE方法进行；然而，也可能使用了其他方法。
If any non-SUBSCRIBE mechanisms are defined to create subscriptions, it is the responsibility of the parties defining those mechanisms to ensure that correlation of a NOTIFY message to the corresponding subscription is possible. Designers of such mechanisms are also warned to make a distinction between sending a NOTIFY message to a subscriber who is aware of the subscription, and sending a NOTIFY message to an unsuspecting node. The latter behavior is invalid, and MUST receive a "481 Subscription does not exist" response (unless some other 400- or 500-class error code is more applicable), as described in section 3.2.4. In other words, knowledge of a subscription must exist in both the subscriber and the notifier to be valid, even if installed via a non-SUBSCRIBE mechanism.
如果定义了任何非订阅机制来创建订阅，则定义这些机制的各方有责任确保NOTIFY消息与相应订阅的关联是可能的。此类机制的设计者还被警告要区分向知道订阅的订户发送通知消息和向不知情的节点发送通知消息。后一种行为无效，必须收到“481订阅不存在”响应（除非其他400或500类错误代码更适用），如第3.2.4节所述。换句话说，订阅的知识必须存在于订阅服务器和通知程序中才能有效，即使是通过非订阅机制安装的。
A NOTIFY does not terminate its corresponding subscription; in other words, a single SUBSCRIBE request may trigger several NOTIFY requests.
通知不终止其相应的订阅；换句话说，一个订阅请求可能会触发多个NOTIFY请求。
3.2.1. Identification of Reported Events, Event Classes, and Current State
3.2.1. 报告事件、事件类别和当前状态的标识
Identification of events being reported in a notification is very similar to that described for subscription to events (see section 3.1.2.).
通知中报告的事件标识与订阅事件的标识非常相似（见第3.1.2节）。
As in SUBSCRIBE requests, NOTIFY "Event" headers will contain a single event package name for which a notification is being generated. The package name in the "Event" header MUST match the "Event" header in the corresponding SUBSCRIBE message. If an "id" parameter was present in the SUBSCRIBE message, that "id" parameter MUST also be present in the corresponding NOTIFY messages.
与订阅请求一样，NOTIFY“Event”标头将包含一个正在为其生成通知的事件包名称。“事件”标题中的包名称必须与相应订阅消息中的“事件”标题匹配。如果订阅消息中存在“id”参数，则相应的通知消息中也必须存在该“id”参数。
Event packages may define semantics associated with the body of their NOTIFY requests; if they do so, those semantics apply. NOTIFY bodies are expected to provide additional details about the nature of the event which has occurred and the resultant resource state.
事件包可以定义与其NOTIFY请求主体相关联的语义；如果他们这样做了，这些语义就适用了。通知机构应提供有关已发生事件性质和结果资源状态的更多详细信息。
When present, the body of the NOTIFY request MUST be formatted into one of the body formats specified in the "Accept" header of the corresponding SUBSCRIBE request. This body will contain either the state of the subscribed resource or a pointer to such state in the form of a URI (see section 4.4.13).
当存在时，通知请求的正文必须格式化为相应订阅请求的“Accept”头中指定的正文格式之一。此正文将包含订阅资源的状态或URI形式的指向该状态的指针（参见第4.4.13节）。
When a SUBSCRIBE request is answered with a 200-class response, the notifier MUST immediately construct and send a NOTIFY request to the subscriber. When a change in the subscribed state occurs, the notifier SHOULD immediately construct and send a NOTIFY request, subject to authorization, local policy, and throttling considerations.
当订阅请求得到200类响应的响应时，通知程序必须立即构造并向订阅服务器发送通知请求。当订阅状态发生更改时，通知程序应根据授权、本地策略和限制因素立即构造并发送NOTIFY请求。
A NOTIFY request is considered failed if the response times out, or a non-200 class response code is received which has no "Retry-After" header and no implied further action which can be taken to retry the request (e.g., "401 Authorization Required".)
如果响应超时，或者收到的非200类响应代码没有“Retry After”（重试之后）标头，并且没有可用于重试请求的暗示进一步操作（例如，“需要401授权”），则NOTIFY请求被视为失败
If the NOTIFY request fails (as defined above) due to a timeout condition, and the subscription was installed using a soft-state mechanism (such as SUBSCRIBE), the notifier SHOULD remove the subscription.
如果NOTIFY请求由于超时条件而失败（如上所述），并且订阅是使用软状态机制（如SUBSCRIBE）安装的，则通知程序应删除订阅。
This behavior prevents unnecessary transmission of state information for subscribers who have crashed or disappeared from the network. Because such transmissions will be sent multiple times, per the retransmission algorithm defined in SIP [1] (instead of the typical single transmission for functioning clients), continuing to service them when no client is available to acknowledge them could place undue strain on a network. Upon client restart or reestablishment of a network connection, it is expected that clients will send SUBSCRIBE messages to refresh potentially stale state information; such messages will re-install subscriptions in all relevant nodes.
此行为可防止对已崩溃或从网络中消失的订阅者进行不必要的状态信息传输。由于此类传输将根据SIP[1]中定义的重传算法（而不是正常运行的客户端的典型单次传输）发送多次，因此在没有可用的客户端确认它们时继续为它们提供服务可能会对网络造成不适当的压力。在客户端重新启动或重新建立网络连接时，预期客户端将发送订阅消息以刷新可能过时的状态信息；此类消息将在所有相关节点中重新安装订阅。
If the NOTIFY request fails (as defined above) due to an error response, and the subscription was installed using a soft-state mechanism, the notifier MUST remove the corresponding subscription.
如果NOTIFY请求因错误响应而失败（如上所述），并且订阅是使用软状态机制安装的，则通知程序必须删除相应的订阅。
A notify error response would generally indicate that something has gone wrong with the subscriber or with some proxy on the way to the subscriber. If the subscriber is in error, it makes the most sense to allow the subscriber to rectify the situation (by re-subscribing) once the error condition has been handled. If a proxy is in error, the periodic SUBSCRIBE refreshes will re-install subscription state once the network problem has been resolved.
notify错误响应通常表示订阅服务器或某个代理服务器在发送到订阅服务器的过程中出现问题。如果订户出错，在错误情况得到处理后，允许订户纠正情况（通过重新订阅）是最有意义的。如果代理出错，网络问题解决后，定期订阅刷新将重新安装订阅状态。
If a NOTIFY request receives a 481 response, the notifier MUST remove the corresponding subscription even if such subscription was installed by non-SUBSCRIBE means (such as an administrative interface).
如果NOTIFY请求收到481响应，则通知程序必须删除相应的订阅，即使该订阅是通过非订阅方式（如管理接口）安装的。
If the above behavior were not required, subscribers receiving a notify for an unknown subscription would need to send an error status code in response to the NOTIFY and also send a SUBSCRIBE request to remove the subscription. Since this behavior would make subscribers available for use as amplifiers in denial of service attacks, we have instead elected to give the 481 response special meaning: it is used to indicate that a subscription must be cancelled under all circumstances.
如果不需要上述行为，则接收未知订阅通知的订阅服务器将需要发送错误状态代码以响应通知，并发送订阅请求以删除订阅。由于此行为将使订阅者在拒绝服务攻击中可用作放大器，因此我们选择赋予481响应特殊含义：它用于指示在任何情况下都必须取消订阅。
NOTIFY requests MUST contain a "Subscription-State" header with a value of "active", "pending", or "terminated". The "active" value indicates that the subscription has been accepted and has been authorized (in most cases; see section 5.2.). The "pending" value indicates that the subscription has been received, but that policy information is insufficient to accept or deny the subscription at this time. The "terminated" value indicates that the subscription is not active.
通知请求必须包含一个“订阅状态”标头，其值为“活动”、“挂起”或“终止”。“活动”值表示订阅已被接受和授权（在大多数情况下，请参见第5.2节）。“pending”值表示已收到订阅，但此时策略信息不足以接受或拒绝订阅。“terminated”值表示订阅未激活。
If the value of the "Subscription-State" header is "active" or "pending", the notifier SHOULD also include in the "Subscription-State" header an "expires" parameter which indicates the time remaining on the subscription. The notifier MAY use this mechanism to shorten a subscription; however, this mechanism MUST NOT be used to lengthen a subscription.
如果“订阅状态”标头的值为“活动”或“挂起”，则通知程序还应在“订阅状态”标头中包含一个“expires”参数，该参数指示订阅上剩余的时间。通知程序可以使用此机制缩短订阅；但是，此机制不得用于延长订阅。
Including expiration information for active and pending subscriptions is useful in case the SUBSCRIBE request forks, since the response to a forked SUBSCRIBE may not be received by the subscriber. Note well that this "expires" value is a parameter on the "Subscription-State" header, NOT an "Expires" header.
在订阅请求分叉的情况下，包括活动订阅和挂起订阅的到期信息非常有用，因为订阅方可能不会收到对分叉订阅的响应。请注意，这个“expires”值是“Subscription State”头上的一个参数，而不是“expires”头。
If the value of the "Subscription-State" header is "terminated", the notifier SHOULD also include a "reason" parameter. The notifier MAY also include a "retry-after" parameter, where appropriate. For details on the value and semantics of the "reason" and "retry-after" parameters, see section 3.2.4.
如果“订阅状态”头的值为“终止”，通知程序还应包括“原因”参数。在适当的情况下，通知程序还可以包括“重试后”参数。有关“reason”和“retry after”参数的值和语义的详细信息，请参见第3.2.4节。
Proxies need no additional behavior beyond that described in SIP [1] to support NOTIFY. If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests.
除了SIP[1]中描述的行为之外，代理不需要其他行为来支持NOTIFY。如果代理希望看到给定对话框的所有订阅和通知请求，它必须记录初始订阅路由和建立通知请求的任何对话框。此类代理还应记录路由所有其他订阅和通知请求。
Note that subscribers and notifiers may elect to use S/MIME encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies cannot rely on being able to access any information that is not explicitly required to be proxy-readable by SIP [1].
请注意，订阅者和通知者可以选择对订阅和通知请求使用S/MIME加密；因此，代理不能依赖于能够访问SIP[1]不明确要求代理可读的任何信息。
Upon receiving a NOTIFY request, the subscriber should check that it matches at least one of its outstanding subscriptions; if not, it MUST return a "481 Subscription does not exist" response unless another 400- or 500-class response is more appropriate. The rules for matching NOTIFY requests with subscriptions that create a new dialog are described in section 3.3.4. Notifications for subscriptions which were created inside an existing dialog match if they are in the same dialog and the "Event" headers match (as described in section 7.2.1.)
收到通知请求后，订阅者应检查其是否与至少一个未完成订阅匹配；否则，它必须返回“481订阅不存在”响应，除非另一个400或500类响应更合适。第3.3.4节介绍了将通知请求与创建新对话框的订阅相匹配的规则。在现有对话框中创建的订阅通知如果在同一对话框中且“事件”标题匹配（如第7.2.1节所述），则会匹配
If, for some reason, the event package designated in the "Event" header of the NOTIFY request is not supported, the subscriber will respond with a "489 Bad Event" response.
如果由于某种原因，NOTIFY请求的“event”（事件）标头中指定的事件包不受支持，订阅者将以“489 Bad event”（489坏事件）响应进行响应。
To prevent spoofing of events, NOTIFY requests SHOULD be authenticated, using any defined SIP authentication mechanism.
为防止事件欺骗，应使用任何定义的SIP身份验证机制对NOTIFY请求进行身份验证。
NOTIFY requests MUST contain "Subscription-State" headers which indicate the status of the subscription.
通知请求必须包含指示订阅状态的“订阅状态”标头。
If the "Subscription-State" header value is "active", it means that the subscription has been accepted and (in general) has been authorized. If the header also contains an "expires" parameter, the subscriber SHOULD take it as the authoritative subscription duration and adjust accordingly. The "retry-after" and "reason" parameters have no semantics for "active".
如果“订阅状态”标题值为“活动”，则表示订阅已被接受且（通常）已被授权。如果标头还包含“expires”参数，则订阅者应将其作为权威订阅持续时间并进行相应调整。“retry after”和“reason”参数没有“active”的语义。
If the "Subscription-State" value is "pending", the subscription has been received by the notifier, but there is insufficient policy information to grant or deny the subscription yet. If the header also contains an "expires" parameter, the subscriber SHOULD take it as the authoritative subscription duration and adjust accordingly. No further action is necessary on the part of the subscriber. The "retry-after" and "reason" parameters have no semantics for "pending".
如果“订阅状态”值为“挂起”，则通知程序已收到订阅，但没有足够的策略信息来授予或拒绝订阅。如果标头还包含“expires”参数，则订阅者应将其作为权威订阅持续时间并进行相应调整。认购人无需采取进一步行动。“retry after”和“reason”参数没有“pending”的语义。
If the "Subscription-State" value is "terminated", the subscriber should consider the subscription terminated. The "expires" parameter has no semantics for "terminated". If a reason code is present, the client should behave as described below. If no reason code or an unknown reason code is present, the client MAY attempt to re-
如果“订阅状态”值“终止”，则订阅服务器应考虑终止订阅。“expires”参数没有“terminated”的语义。如果存在原因代码，则客户端的行为应如下所述。如果不存在原因代码或未知原因代码，客户端可能会尝试重新设置-
subscribe at any time (unless a "retry-after" parameter is present, in which case the client SHOULD NOT attempt re-subscription until after the number of seconds specified by the "retry-after" parameter). The defined reason codes are:
随时订阅（除非存在“重试后”参数，在这种情况下，客户端在“重试后”参数指定的秒数之前不应尝试重新订阅）。定义的原因代码为：
deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. The "retry-after" parameter has no semantics for "deactivated".
已停用：订阅已终止，但订阅服务器应立即使用新订阅重试。这种状态代码的一个主要用途是允许在节点之间迁移订阅。“retry after”参数没有“deactivated”的语义。
probation: The subscription has been terminated, but the client SHOULD retry at some later time. If a "retry-after" parameter is also present, the client SHOULD wait at least the number of seconds specified by that parameter before attempting to re-subscribe.
试用期：订阅已终止，但客户端应稍后重试。如果还存在“retry after”参数，则客户端应至少等待该参数指定的秒数，然后再尝试重新订阅。
rejected: The subscription has been terminated due to change in authorization policy. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "rejected".
已拒绝：由于授权策略的更改，订阅已终止。客户端不应尝试重新订阅。“retry after”参数没有“rejected”的语义。
timeout: The subscription has been terminated because it was not refreshed before it expired. Clients MAY re-subscribe immediately. The "retry-after" parameter has no semantics for "timeout".
超时：订阅已终止，因为它在过期之前未刷新。客户可以立即重新订阅。“retry after”参数没有“timeout”的语义。
giveup: The subscription has been terminated because the notifier could not obtain authorization in a timely fashion. If a "retry-after" parameter is also present, the client SHOULD wait at least the number of seconds specified by that parameter before attempting to re-subscribe; otherwise, the client MAY retry immediately, but will likely get put back into pending state.
放弃：订阅已终止，因为通知程序无法及时获得授权。如果还存在“重试后”参数，则客户端应至少等待该参数指定的秒数，然后再尝试重新订阅；否则，客户端可能会立即重试，但很可能会恢复到挂起状态。
noresource: The subscription has been terminated because the resource state which was being monitored no longer exists. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "noresource".
noresource:订阅已终止，因为正在监视的资源状态不再存在。客户端不应尝试重新订阅。“retry after”参数没有“noresource”的语义。
Once the notification is deemed acceptable to the subscriber, the subscriber SHOULD return a 200 response. In general, it is not expected that NOTIFY responses will contain bodies; however, they MAY, if the NOTIFY request contained an "Accept" header.
一旦订户认为该通知可接受，订户应返回200响应。一般来说，NOTIFY回复不会包含实体；但是，如果NOTIFY请求包含“Accept”头，则它们可以。
Other responses defined in SIP [1] may also be returned, as appropriate. In no case should a NOTIFY transaction extend for any longer than the time necessary for automated processing. In particular, subscribers MUST NOT wait for a user response before returning a final response to a NOTIFY request.
视情况而定，也可以返回SIP[1]中定义的其他响应。在任何情况下，NOTIFY事务的扩展时间都不得超过自动处理所需的时间。特别是，订户在返回对NOTIFY请求的最终响应之前，不能等待用户响应。
Neither SUBSCRIBE nor NOTIFY necessitate the use of "Require" or "Proxy-Require" headers; similarly, there is no token defined for "Supported" headers. If necessary, clients may probe for the support of SUBSCRIBE and NOTIFY using the OPTIONS request defined in SIP [1].
订阅或通知都不需要使用“Require”或“Proxy Require”标题；类似地，没有为“受支持的”头定义令牌。如有必要，客户机可以使用SIP[1]中定义的选项请求来探测订阅和通知的支持。
The presence of the "Allow-Events" header in a message is sufficient to indicate support for SUBSCRIBE and NOTIFY.
消息中存在“允许事件”头足以表示支持订阅和通知。
The "methods" parameter for Contact may also be used to specifically announce support for SUBSCRIBE and NOTIFY messages when registering. (See reference [8] for details on the "methods" parameter).
联系人的“方法”参数也可用于在注册时专门宣布对订阅和通知消息的支持。（有关“方法”参数的详细信息，请参见参考文献[8]）。
No semantics are associated with cancelling SUBSCRIBE or NOTIFY.
没有语义与取消订阅或通知关联。
In accordance with the rules for proxying non-INVITE requests as defined in SIP [1], successful SUBSCRIBE requests will receive only one 200-class response; however, due to forking, the subscription may have been accepted by multiple nodes. The subscriber MUST therefore be prepared to receive NOTIFY requests with "From:" tags which differ from the "To:" tag received in the SUBSCRIBE 200-class response.
根据SIP[1]中定义的代理非INVITE请求的规则，成功的SUBSCRIBE请求将只收到一个200类响应；但是，由于分叉，订阅可能已被多个节点接受。因此，订户必须准备好接收带有“From:”标记的NOTIFY请求，这些标记不同于SUBSCRIBE 200类响应中接收的“to:”标记。
If multiple NOTIFY messages are received in different dialogs in response to a single SUBSCRIBE message, each dialog represents a different destination to which the SUBSCRIBE request was forked. For information on subscriber handling in such situations, see section 4.4.9.
如果在不同的对话框中接收到多条通知消息以响应单个订阅消息，则每个对话框表示订阅请求的不同目的地。有关此类情况下用户处理的信息，请参见第4.4.9节。
If an initial SUBSCRIBE request is not sent on a pre-existing dialog, the subscriber will wait for a response to the SUBSCRIBE request or a matching NOTIFY.
如果未在预先存在的对话框上发送初始订阅请求，订户将等待对订阅请求的响应或匹配的通知。
Responses are matched to such SUBSCRIBE requests if they contain the same the same "Call-ID", the same "From" header "tag", and the same "CSeq". Rules for the comparison of these headers are described in SIP [1]. If a 200-class response matches such a SUBSCRIBE request, it creates a new subscription and a new dialog (unless they have already been created by a matching NOTIFY request; see below).
如果响应包含相同的“呼叫ID”、相同的“来自”头“标记”和相同的“CSeq”，则响应与此类订阅请求匹配。SIP[1]中描述了这些头的比较规则。如果200类响应与这样的订阅请求匹配，它将创建一个新订阅和一个新对话框（除非它们已经由匹配的NOTIFY请求创建；请参见下文）。
NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header "tag" parameter which matches the "From" header "tag" parameter of the SUBSCRIBE, and the same "Event" header field. Rules for comparisons of the "Event" headers are described in section 7.2.1. If a matching NOTIFY request contains a "Subscription-State" of "active" or "pending", it creates a new subscription and a new dialog (unless they have already been created by a matching response, as described above).
如果通知请求包含相同的“调用ID”、与订阅的“From”header“tag”参数匹配的“to”header“tag”参数以及相同的“Event”header字段，则通知请求与此类订阅请求匹配。“事件”标题的比较规则见第7.2.1节。如果匹配的NOTIFY请求包含“活动”或“挂起”的“订阅状态”，则会创建一个新订阅和一个新对话框（除非它们已由匹配响应创建，如上所述）。
If an initial SUBSCRIBE is sent on a pre-existing dialog, a matching 200-class response or successful NOTIFY request merely creates a new subscription associated with that dialog.
如果在预先存在的对话框上发送初始订阅，则匹配的200类响应或成功的NOTIFY请求只会创建与该对话框关联的新订阅。
Multiple subscriptions can be associated with a single dialog. Subscriptions may also exist in dialogs associated with INVITE-created application state and other application state created by mechanisms defined in other specifications. These sets of application state do not interact beyond the behavior described for a dialog (e.g., route set handling).
多个订阅可以与单个对话框关联。订阅也可能存在于与INVITE创建的应用程序状态和其他规范中定义的机制创建的其他应用程序状态相关联的对话框中。这些应用程序状态集的交互不会超出为对话框描述的行为（例如，路由集处理）。
A subscription is destroyed when a notifier sends a NOTIFY request with a "Subscription-State" of "terminated".
当通知程序发送“订阅状态”为“已终止”的NOTIFY请求时，订阅将被销毁。
A subscriber may send a SUBSCRIBE request with an "Expires" header of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY with a "Subscription-State" of "terminated" is sent.
订户可以发送“Expires”报头为0的订阅请求，以触发此类通知请求的发送；但是，出于订阅和对话框生存期的目的，在发送“订阅状态”为“已终止”的通知之前，订阅不会被视为已终止。
If a subscription's destruction leaves no other application state associated with the dialog, the dialog terminates. The destruction of other application state (such as that created by an INVITE) will not terminate the dialog if a subscription is still associated with that dialog.
如果订阅的销毁没有留下与对话框关联的其他应用程序状态，则对话框终止。如果订阅仍与该对话框关联，则销毁其他应用程序状态（如由INVITE创建的状态）不会终止该对话框。
Note that the above behavior means that a dialog created with an INVITE does not necessarily terminate upon receipt of a BYE. Similarly, in the case that several subscriptions are associated with a single dialog, the dialog does not terminate until all the subscriptions in it are destroyed.
请注意，上述行为意味着使用INVITE创建的对话框不一定在收到BYE时终止。类似地，如果多个订阅与单个对话框相关联，则该对话框在销毁其中的所有订阅之前不会终止。
When state agents (see section 4.4.11.) are used, it is often useful to allow migration of subscriptions between state agents and the nodes for which they are providing state aggregation (or even among various state agents). Such migration may be effected by sending a
当使用状态代理（见第4.4.11节）时，允许在状态代理和为其提供状态聚合的节点之间（甚至在各种状态代理之间）迁移订阅通常很有用。这种迁移可以通过发送
NOTIFY message with a "Subscription-State" header of "terminated", and a reason parameter of "deactivated". This NOTIFY request is otherwise normal, and is formed as described in section 3.2.2.
通知消息的“订阅状态”标题为“已终止”，原因参数为“已停用”。该通知请求在其他方面是正常的，其格式如第3.2.2节所述。
Upon receipt of this NOTIFY message, the subscriber SHOULD attempt to re-subscribe (as described in the preceding sections). Note that this subscription is established on a new dialog, and does not re-use the route set from the previous subscription dialog.
收到此通知消息后，订户应尝试重新订阅（如前几节所述）。请注意，此订阅是在新对话框上建立的，不会重新使用上一个订阅对话框中的路由集。
The actual migration is effected by making a change to the policy (such as routing decisions) of one or more servers to which the SUBSCRIBE request will be sent in such a way that a different node ends up responding to the SUBSCRIBE request. This may be as simple as a change in the local policy in the notifier from which the subscription is migrating so that it serves as a proxy or redirect server instead of a notifier.
实际迁移是通过对订阅请求将被发送到的一个或多个服务器的策略（例如路由决定）进行更改来实现的，这种更改的方式使得不同的节点最终响应订阅请求。这可能很简单，只需在从中迁移订阅的通知程序中更改本地策略，使其充当代理服务器或重定向服务器，而不是通知程序。
Whether, when, and why to perform notifier migrations may be described in individual event packages; otherwise, such decisions are a matter of local notifier policy, and are left up to individual implementations.
是否、何时以及为什么执行通知程序迁移可以在单个事件包中描述；否则，此类决策将取决于本地通知程序策略，并由各个实现决定。
A natural consequence of the behavior described in the preceding sections is that an immediate fetch without a persistent subscription may be effected by sending a SUBSCRIBE with an "Expires" of 0.
前面几节中描述的行为的一个自然结果是，如果发送“Expires”为0的订阅，则可能会影响没有持久订阅的即时获取。
Of course, an immediate fetch while a subscription is active may be effected by sending a SUBSCRIBE with an "Expires" equal to the number of seconds remaining in the subscription.
当然，当订阅处于活动状态时，可以通过发送“过期”等于订阅中剩余秒数的订阅来实现即时获取。
Upon receipt of this SUBSCRIBE request, the notifier (or notifiers, if the SUBSCRIBE request was forked) will send a NOTIFY request containing resource state in the same dialog.
收到此订阅请求后，通知程序（如果订阅请求已分叉，则通知程序）将在同一对话框中发送包含资源状态的通知请求。
Note that the NOTIFY messages triggered by SUBSCRIBE messages with "Expires" headers of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout".
请注意，由“Expires”标头为0的订阅消息触发的通知消息将包含“Subscription State”值“terminated”，以及“reason”参数“timeout”。
Polling of event state can cause significant increases in load on the network and notifiers; as such, it should be used only sparingly. In particular, polling SHOULD NOT be used in circumstances in which it will typically result in more network messages than long-running subscriptions.
轮询事件状态可能导致网络和通知程序上的负载显著增加；因此，应尽量少用。特别是，在轮询通常会产生比长时间运行的订阅更多的网络消息的情况下，不应使用轮询。
When polling is used, subscribers SHOULD attempt to cache authentication credentials between polls so as to reduce the number of messages sent.
使用轮询时，订阅者应尝试在轮询之间缓存身份验证凭据，以减少发送的消息数。
The "Allow-Events" header, if present, includes a list of tokens which indicates the event packages supported by the client (if sent in a request) or server (if sent in a response). In other words, a node sending an "Allow-Events" header is advertising that it can process SUBSCRIBE requests and generate NOTIFY requests for all of the event packages listed in that header.
“允许事件”标头（如果存在）包括一个令牌列表，该列表指示客户端（如果在请求中发送）或服务器（如果在响应中发送）支持的事件包。换句话说，发送“允许事件”报头的节点表明它可以处理订阅请求并为该报头中列出的所有事件包生成通知请求。
Any node implementing one or more event packages SHOULD include an appropriate "Allow-Events" header indicating all supported events in all methods which initiate dialogs and their responses (such as INVITE) and OPTIONS responses.
实现一个或多个事件包的任何节点都应该包含一个适当的“允许事件”头，指示所有启动对话框的方法中所有支持的事件及其响应（如INVITE）和选项响应。
This information is very useful, for example, in allowing user agents to render particular interface elements appropriately according to whether the events required to implement the features they represent are supported by the appropriate nodes.
该信息非常有用，例如，允许用户代理根据实现它们所表示的功能所需的事件是否得到相应节点的支持，适当地呈现特定的接口元素。
Note that "Allow-Events" headers MUST NOT be inserted by proxies.
请注意，“允许事件”标题不能由代理插入。
The "Event" header is considered mandatory for the purposes of this document. However, to maintain compatibility with PINT (see [2]), servers MAY interpret a SUBSCRIBE request with no "Event" header as requesting a subscription to PINT events. If a server does not support PINT, it SHOULD return "489 Bad Event" to any SUBSCRIBE messages without an "Event" header.
在本文件中，“事件”标题被视为是强制性的。然而，为了保持与PINT的兼容性（参见[2]），服务器可能会将没有“事件”头的订阅请求解释为请求对PINT事件的订阅。如果服务器不支持PINT，则应将“489坏事件”返回给没有“事件”标头的任何订阅消息。
This section covers several issues which should be taken into consideration when event packages based on SUBSCRIBE and NOTIFY are proposed.
本节介绍了在提出基于SUBSCRIBE和NOTIFY的事件包时应考虑的几个问题。
When designing an event package using the methods described in this document for event notification, it is important to consider: is SIP an appropriate mechanism for the problem set? Is SIP being selected because of some unique feature provided by the protocol (e.g., user mobility), or merely because "it can be done?" If you find yourself
当使用本文档中描述的事件通知方法设计事件包时，必须考虑：SIP是否是问题集的适当机制？选择SIP是因为协议提供了一些独特的功能（例如，用户移动性），还是仅仅因为“它可以做到？”如果您发现自己
defining event packages for notifications related to, for example, network management or the temperature inside your car's engine, you may want to reconsider your selection of protocols.
定义与网络管理或汽车发动机内部温度相关的通知的事件包，您可能需要重新考虑协议的选择。
Those interested in extending the mechanism defined in this document are urged to follow the development of "Guidelines for Authors of SIP Extensions" [7] for further guidance regarding appropriate uses of SIP.
有兴趣扩展本文件中定义的机制的人，请遵循“SIP扩展作者指南”[7]的制定，以获得有关SIP适当使用的进一步指导。
Further, it is expected that this mechanism is not to be used in applications where the frequency of reportable events is excessively rapid (e.g., more than about once per second). A SIP network is generally going to be provisioned for a reasonable signalling volume; sending a notification every time a user's GPS position changes by one hundredth of a second could easily overload such a network.
此外，预计该机制不会用于可报告事件频率过快（例如，超过每秒一次）的应用中。SIP网络通常将被配置为合理的信令量；每当用户的GPS位置改变百分之一秒时发送通知，很容易使这样的网络过载。
Normal event packages define a set of state applied to a specific type of resource, such as user presence, call state, and messaging mailbox state.
普通事件包定义应用于特定类型资源的一组状态，例如用户状态、呼叫状态和消息邮箱状态。
Event template-packages are a special type of package which define a set of state applied to other packages, such as statistics, access policy, and subscriber lists. Event template-packages may even be applied to other event template-packages.
事件模板包是一种特殊类型的包，它定义应用于其他包的一组状态，例如统计信息、访问策略和订户列表。事件模板包甚至可以应用于其他事件模板包。
To extend the object-oriented analogy made earlier, event template-packages can be thought of as templatized C++ packages which must be applied to other packages to be useful.
为了扩展前面的面向对象类比，事件模板包可以被认为是模板化的C++包，这些包必须应用于其他包是有用的。
The name of an event template-package as applied to a package is formed by appending a period followed by the event template-package name to the end of the package. For example, if a template-package called "winfo" were being applied to a package called "presence", the event token used in "Event" and "Allow-Events" would be "presence.winfo".
应用于包的事件模板包的名称是通过在包的末尾附加句点，后跟事件模板包名称形成的。例如，如果一个名为“winfo”的模板包被应用到名为“presence”的包中，“event”和“Allow Events”中使用的事件令牌将是“presence.winfo”。
Event template-packages must be defined so that they can be applied to any arbitrary package. In other words, event template-packages cannot be specifically tied to one or a few "parent" packages in such a way that they will not work with other packages.
必须定义事件模板包，以便将其应用于任意包。换句话说，事件模板包不能专门绑定到一个或几个“父”包，这样它们就不能与其他包一起工作。
When designing event packages, it is important to consider the type of information which will be conveyed during a notification.
在设计事件包时，重要的是要考虑在通知期间传递的信息的类型。
A natural temptation is to convey merely the event (e.g., "a new voice message just arrived") without accompanying state (e.g., "7 total voice messages"). This complicates implementation of subscribing entities (since they have to maintain complete state for the entity to which they have subscribed), and also is particularly susceptible to synchronization problems.
自然的诱惑是只传达事件（例如，“新语音消息刚刚到达”），而不附带状态（例如，“总共7条语音消息”）。这使订阅实体的实现复杂化（因为它们必须维护其订阅的实体的完整状态），并且特别容易出现同步问题。
There are two possible solutions to this problem that event packages may choose to implement.
对于这个问题，事件包可以选择实现两种可能的解决方案。
For packages which typically convey state information that is reasonably small (on the order of 1 kb or so), it is suggested that event packages are designed so as to send complete state information when an event occurs.
对于通常传递相当小（大约1KB）的状态信息的包，建议将事件包设计为在事件发生时发送完整的状态信息。
In some circumstances, conveying the current state alone may be insufficient for a particular class of events. In these cases, the event packages should include complete state information along with the event that occurred. For example, conveying "no customer service representatives available" may not be as useful as conveying "no customer service representatives available; representative sip:46@cs.xyz.int just logged off".
在某些情况下，仅传达当前状态可能不足以处理特定类别的事件。在这些情况下，事件包应包括完整的状态信息以及发生的事件。例如，传达“没有可用的客户服务代表”可能不如传达“没有可用的客户服务代表；代表sip:46@cs.xyz.int刚刚注销”。
In the case that the state information to be conveyed is large, the event package may choose to detail a scheme by which NOTIFY messages contain state deltas instead of complete state.
在要传送的状态信息较大的情况下，事件包可以选择详述一种方案，通过该方案，通知消息包含状态增量而不是完整状态。
Such a scheme would work as follows: any NOTIFY sent in immediate response to a SUBSCRIBE contains full state information. NOTIFY messages sent because of a state change will contain only the state information that has changed; the subscriber will then merge this information into its current knowledge about the state of the resource.
这样一个方案的工作原理如下：立即响应订阅发送的任何通知都包含完整的状态信息。由于状态更改而发送的通知消息将仅包含已更改的状态信息；然后，订阅者将这些信息合并到其关于资源状态的当前知识中。
Any event package that supports delta changes to states MUST include a version number that increases by exactly one for each NOTIFY transaction in a subscription. Note that the state version number appears in the body of the message, not in a SIP header.
任何支持状态增量更改的事件包都必须包含一个版本号，该版本号对于订阅中的每个NOTIFY事务增加一个版本号。请注意，状态版本号显示在消息体中，而不是SIP头中。
If a NOTIFY arrives that has a version number that is incremented by more than one, the subscriber knows that a state delta has been missed; it ignores the NOTIFY message containing the state delta
如果通知到达时版本号增加了一个以上，则订户知道状态增量已丢失；它忽略包含状态增量的NOTIFY消息
(except for the version number, which it retains to detect message loss), and re-sends a SUBSCRIBE to force a NOTIFY containing a complete state snapshot.
（版本号除外，它保留该版本号以检测消息丢失），并重新发送订阅以强制发送包含完整状态快照的通知。
Event packages are not required to reiterate any of the behavior described in this document, although they may choose to do so for clarity or emphasis. In general, though, such packages are expected to describe only the behavior that extends or modifies the behavior described in this document.
事件包不需要重复本文档中描述的任何行为，尽管为了清晰或强调，他们可能会选择这样做。但是，一般来说，这些包只需要描述扩展或修改本文档中描述的行为的行为。
Note that any behavior designated with "SHOULD" or "MUST" in this document is not allowed to be weakened by extension documents; however, such documents may elect to strengthen "SHOULD" requirements to "MUST" strength if required by their application.
注意，本文件中任何标有“应该”或“必须”的行为都不允许被扩展文件削弱；但是，如果应用需要，这些文件可以选择将“应该”要求强化为“必须”强度。
In addition to the normal sections expected in standards-track RFCs and SIP extension documents, authors of event packages need to address each of the issues detailed in the following subsections, whenever applicable.
除了标准跟踪RFC和SIP扩展文档中预期的正常部分外，事件包的作者需要在适用的情况下解决以下小节中详述的每个问题。
This section, which MUST be present, defines the token name to be used to designate the event package. It MUST include the information which appears in the IANA registration of the token. For information on registering such types, see section 6.
此部分必须存在，定义用于指定事件包的令牌名称。它必须包括令牌的IANA注册中显示的信息。有关注册此类类型的信息，请参见第6节。
If parameters are to be used on the "Event" header to modify the behavior of the event package, the syntax and semantics of such headers MUST be clearly defined.
如果要在“事件”头上使用参数来修改事件包的行为，则必须明确定义此类头的语法和语义。
It is expected that most, but not all, event packages will define syntax and semantics for SUBSCRIBE method bodies; these bodies will typically modify, expand, filter, throttle, and/or set thresholds for the class of events being requested. Designers of event packages are strongly encouraged to re-use existing MIME types for message bodies where practical.
预计大多数（但不是全部）事件包将定义SUBSCRIBE方法体的语法和语义；这些机构通常会修改、扩展、过滤、调节和/或设置所请求事件类别的阈值。强烈鼓励事件包的设计者在可行的情况下重用消息体的现有MIME类型。
This mandatory section of an event package defines what type or types of event bodies are expected in SUBSCRIBE requests (or specify that no event bodies are expected). It should point to detailed definitions of syntax and semantics for all referenced body types.
事件包的此必填部分定义订阅请求中预期的事件体类型（或指定不预期任何事件体）。它应该指向所有引用的主体类型的语法和语义的详细定义。
It is RECOMMENDED that event packages give a suggested range of times considered reasonable for the duration of a subscription. Such packages MUST also define a default "Expires" value to be used if none is specified.
建议事件包在订阅期间提供合理的建议时间范围。如果未指定任何值，则此类包还必须定义要使用的默认“Expires”值。
The NOTIFY body is used to report state on the resource being monitored. Each package MUST define what type or types of event bodies are expected in NOTIFY requests. Such packages MUST specify or cite detailed specifications for the syntax and semantics associated with such event body.
NOTIFY body用于报告正在监视的资源的状态。每个包必须定义NOTIFY请求中预期的事件体类型。此类包必须指定或引用与此类事件体相关联的语法和语义的详细规范。
Event packages also MUST define which MIME type is to be assumed if none are specified in the "Accept" header of the SUBSCRIBE request.
如果订阅请求的“Accept”头中未指定MIME类型，则事件包还必须定义将采用的MIME类型。
This section describes the processing to be performed by the notifier upon receipt of a SUBSCRIBE request. Such a section is required.
本节描述通知程序在收到订阅请求时要执行的处理。这一节是必需的。
Information in this section includes details of how to authenticate subscribers and authorization issues for the package. Such authorization issues may include, for example, whether all SUBSCRIBE requests for this package are answered with 202 responses (see section 5.2.).
本节中的信息包括如何对订阅服务器进行身份验证以及包的授权问题的详细信息。此类授权问题可能包括，例如，是否对此包的所有订阅请求都有202个响应（见第5.2节）。
This section of an event package describes the process by which the notifier generates and sends a NOTIFY request. This includes detailed information about what events cause a NOTIFY to be sent, how to compute the state information in the NOTIFY, how to generate neutral or fake state information to hide authorization delays and decisions from users, and whether state information is complete or deltas for notifications; see section 4.3. Such a section is required.
事件包的这一部分描述了通知程序生成和发送通知请求的过程。这包括关于哪些事件导致发送通知的详细信息，如何计算通知中的状态信息，如何生成中立或虚假的状态信息以隐藏用户的授权延迟和决定，以及状态信息是否完整或通知的增量；见第4.3节。这一节是必需的。
This section may optionally describe the behavior used to process the subsequent response.
本节可以选择性地描述用于处理后续响应的行为。
This section of an event package describes the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state (if applicable).
事件包的这一部分描述订阅者在收到通知请求后遵循的过程，包括形成一致资源状态所需的任何逻辑（如果适用）。
Each event package MUST specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions.
每个事件包必须指定是否允许分叉订阅请求安装多个订阅。
If such behavior is not allowed, the first potential dialog-establishing message will create a dialog. All subsequent NOTIFY messages which correspond to the SUBSCRIBE message (i.e., match "To", "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and "Event" header "id" parameter) but which do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE can arrive after a matching NOTIFY has been received; such responses might not correlate to the same dialog established by the NOTIFY. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored.
如果不允许这种行为，则建立消息的第一个潜在对话框将创建一个对话框。与订阅消息（即，匹配“to”、“From”、“From”header“tag”参数、“Call ID”、“CSeq”、“Event”和“Event”header“ID”参数）相对应但与对话框不匹配的所有后续通知消息将被481响应拒绝。注意，对订阅的200类响应可以在接收到匹配通知之后到达；此类响应可能与NOTIFY建立的同一对话框不相关。除了完成SUBSCRIBE事务所需的响应外，此类不匹配的200类响应将被忽略。
If installing of multiple subscriptions by way of a single forked SUBSCRIBE is allowed, the subscriber establishes a new dialog towards each notifier by returning a 200-class response to each NOTIFY. Each dialog is then handled as its own entity, and is refreshed independent of the other dialogs.
如果允许通过单个分叉订阅安装多个订阅，则订阅服务器通过向每个通知返回200类响应，向每个通知程序建立一个新对话框。然后将每个对话框作为自己的实体进行处理，并独立于其他对话框进行刷新。
In the case that multiple subscriptions are allowed, the event package MUST specify whether merging of the notifications to form a single state is required, and how such merging is to be performed. Note that it is possible that some event packages may be defined in such a way that each dialog is tied to a mutually exclusive state which is unaffected by the other dialogs; this MUST be clearly stated if it is the case.
在允许多个订阅的情况下，事件包必须指定是否需要合并通知以形成单个状态，以及如何执行此类合并。请注意，某些事件包的定义方式可能会使每个对话框绑定到不受其他对话框影响的互斥状态；如果是这样，必须明确说明。
Each event package is expected to define a requirement (SHOULD or MUST strength) which defines an absolute maximum on the rate at which notifications are allowed to be generated by a single notifier.
每个事件包都需要定义一个需求（应该或必须强度），该需求定义了单个通知程序允许生成通知的速率的绝对最大值。
Each package MAY further define a throttle mechanism which allows subscribers to further limit the rate of notification.
每个包可以进一步定义节流机制，该机制允许订阅者进一步限制通知速率。
Designers of event packages should consider whether their package can benefit from network aggregation points (state agents) and/or nodes which act on behalf of other nodes. (For example, nodes which provide state information about a resource when such a resource is unable or unwilling to provide such state information itself). An example of such an application is a node which tracks the presence and availability of a user in the network.
事件包的设计者应该考虑它们的包是否可以受益于网络聚合点（状态代理）和/或代表其他节点的节点。（例如，当资源本身不能或不愿意提供这种状态信息时，提供关于资源的状态信息的节点）。这种应用程序的一个示例是跟踪网络中用户的存在和可用性的节点。
If state agents are to be used by the package, the package MUST specify how such state agents aggregate information and how they provide authentication and authorization.
如果包要使用状态代理，则包必须指定此类状态代理如何聚合信息以及它们如何提供身份验证和授权。
Event packages MAY also outline specific scenarios under which notifier migrations take place.
事件包还可以概述发生通知程序迁移的特定场景。
Event packages SHOULD include several demonstrative message flow diagrams paired with several typical, syntactically correct, and complete messages.
事件包应该包括几个演示性的消息流图，以及几个典型的、语法正确的、完整的消息。
It is RECOMMENDED that documents describing event packages clearly indicate that such examples are informative and not normative, with instructions that implementors refer to the main text of the document for exact protocol details.
建议描述事件包的文件明确指出此类示例是信息性的，而不是规范性的，并说明实施者参考文件的主要文本以了解确切的协议细节。
Some types of event packages may define state information which is potentially too large to reasonably send in a SIP message. To alleviate this problem, event packages may include the ability to convey a URI instead of state information; this URI will then be used to retrieve the actual state information.
某些类型的事件包可能会定义可能太大而无法在SIP消息中合理发送的状态信息。为了缓解这个问题，事件包可以包括传递URI而不是状态信息的能力；然后将使用此URI检索实际状态信息。
The precise mechanisms for conveying such URIs are out of the scope of this document.
传递此类URI的精确机制不在本文档的范围内。
The ability to accept subscriptions should be under the direct control of the notifier's user, since many types of events may be considered sensitive for the purposes of privacy. Similarly, the notifier should have the ability to selectively reject subscriptions based on the subscriber identity (based on access control lists), using standard SIP authentication mechanisms. The methods for creation and distribution of such access control lists is outside the scope of this document.
接受订阅的能力应由通知者的用户直接控制，因为出于隐私目的，许多类型的事件可能被视为敏感事件。类似地，通知程序应该能够使用标准SIP身份验证机制，基于订户身份（基于访问控制列表）选择性地拒绝订阅。此类访问控制列表的创建和分发方法不在本文件范围内。
The mere act of returning a 200 or certain 4xx and 6xx responses to SUBSCRIBE requests may, under certain circumstances, create privacy concerns by revealing sensitive policy information. In these cases, the notifier SHOULD always return a 202 response. While the subsequent NOTIFY message may not convey true state, it MUST appear to contain a potentially correct piece of data from the point of view of the subscriber, indistinguishable from a valid response. Information about whether a user is authorized to subscribe to the requested state is never conveyed back to the original user under these circumstances.
在某些情况下，仅返回200个或某些4xx和6xx响应以订阅请求的行为可能会泄露敏感的政策信息，从而引起隐私问题。在这些情况下，通知程序应始终返回202响应。虽然随后的NOTIFY消息可能无法传递真实状态，但从订阅者的角度来看，它必须似乎包含可能正确的数据段，与有效响应无法区分。在这些情况下，关于用户是否被授权订阅请求状态的信息永远不会传回原始用户。
Individual packages and their related documents for which such a mode of operation makes sense can further describe how and why to generate such potentially correct data. For example, such a mode of operation is mandated by RFC 2779 [6] for user presence information.
对于这种操作模式有意义的各个包及其相关文档，可以进一步描述如何以及为什么生成这种潜在正确的数据。例如，RFC 2779[6]规定了这种操作模式用于用户状态信息。
The current model (one SUBSCRIBE request triggers a SUBSCRIBE response and one or more NOTIFY requests) is a classic setup for an amplifier node to be used in a smurf attack.
当前模型（一个订阅请求触发一个订阅响应，一个或多个通知请求）是smurf攻击中使用的放大器节点的经典设置。
Also, the creation of state upon receipt of a SUBSCRIBE request can be used by attackers to consume resources on a victim's machine, rendering it unusable.
此外，攻击者可以利用收到订阅请求时创建的状态来消耗受害者机器上的资源，从而使其无法使用。
To reduce the chances of such an attack, implementations of notifiers SHOULD require authentication. Authentication issues are discussed in SIP [1].
为了减少此类攻击的机会，通知程序的实现应该需要身份验证。SIP[1]中讨论了身份验证问题。
Replaying of either SUBSCRIBE or NOTIFY can have detrimental effects.
重播订阅或通知可能会产生有害影响。
In the case of SUBSCRIBE messages, attackers may be able to install any arbitrary subscription which it witnessed being installed at some point in the past. Replaying of NOTIFY messages may be used to spoof old state information (although a good versioning mechanism in the body of the NOTIFY messages may help mitigate such an attack). Note that the prohibition on sending NOTIFY messages to nodes which have not subscribed to an event also aids in mitigating the effects of such an attack.
在订阅消息的情况下，攻击者可能能够安装其在过去某个时间见证安装的任何任意订阅。重放NOTIFY消息可用于欺骗旧的状态信息（尽管NOTIFY消息体中良好的版本控制机制可能有助于缓解此类攻击）。请注意，禁止向尚未订阅事件的节点发送通知消息也有助于减轻此类攻击的影响。
To prevent such attacks, implementations SHOULD require authentication with anti-replay protection. Authentication issues are discussed in SIP [1].
为防止此类攻击，实现应要求具有防重放保护的身份验证。SIP[1]中讨论了身份验证问题。
Even with authentication, man-in-the-middle attacks using SUBSCRIBE may be used to install arbitrary subscriptions, hijack existing subscriptions, terminate outstanding subscriptions, or modify the resource to which a subscription is being made. To prevent such attacks, implementations SHOULD provide integrity protection across "Contact", "Route", "Expires", "Event", and "To" headers of SUBSCRIBE messages, at a minimum. If SUBSCRIBE bodies are used to define further information about the state of the call, they SHOULD be included in the integrity protection scheme.
即使使用身份验证，使用SUBSCRIBE的中间人攻击也可能用于安装任意订阅、劫持现有订阅、终止未完成的订阅或修改正在订阅的资源。为防止此类攻击，实现应至少跨订阅消息的“联系人”、“路由”、“过期”、“事件”和“收件人”头提供完整性保护。如果使用SUBSCRIBE body来定义有关调用状态的进一步信息，则应将它们包括在完整性保护方案中。
Man-in-the-middle attacks may also attempt to use NOTIFY messages to spoof arbitrary state information and/or terminate outstanding subscriptions. To prevent such attacks, implementations SHOULD provide integrity protection across the "Call-ID", "CSeq", and "Subscription-State" headers and the bodies of NOTIFY messages.
中间人攻击还可能试图使用NOTIFY消息欺骗任意状态信息和/或终止未完成的订阅。为防止此类攻击，实现应跨“调用ID”、“CSeq”和“订阅状态”头以及NOTIFY消息体提供完整性保护。
Integrity protection of message headers and bodies is discussed in SIP [1].
SIP[1]中讨论了消息头和消息体的完整性保护。
The state information contained in a NOTIFY message has the potential to contain sensitive information. Implementations MAY encrypt such information to ensure confidentiality.
NOTIFY消息中包含的状态信息可能包含敏感信息。实施可能会加密此类信息以确保机密性。
While less likely, it is also possible that the information contained in a SUBSCRIBE message contains information that users might not want to have revealed. Implementations MAY encrypt such information to ensure confidentiality.
虽然不太可能，但订阅消息中包含的信息也可能包含用户可能不想透露的信息。实施可能会加密此类信息以确保机密性。
To allow the remote party to hide information it considers sensitive, all implementations SHOULD be able to handle encrypted SUBSCRIBE and NOTIFY messages.
为了允许远程方隐藏它认为敏感的信息，所有实现都应该能够处理加密的订阅和通知消息。
The mechanisms for providing confidentiality are detailed in SIP [1].
SIP[1]中详细介绍了提供机密性的机制。
This document defines an event-type namespace which requires a central coordinating body. The body chosen for this coordination is the Internet Assigned Numbers Authority (IANA).
本文档定义了一个需要中央协调机构的事件类型命名空间。为此协调选择的机构是互联网分配号码管理局（IANA）。
There are two different types of event-types: normal event packages, and event template-packages; see section 4.2. To avoid confusion, template-package names and package names share the same namespace; in other words, an event template-package MUST NOT share a name with a package.
有两种不同类型的事件类型：普通事件包和事件模板包；见第4.2节。为避免混淆，模板包名称和包名称共享同一名称空间；换句话说，事件模板包不能与包共享名称。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [4], normal event package identification tokens are allocated as First Come First Served, and event template-package identification tokens are allocated on a IETF Consensus basis.
按照“RFCs中编写IANA注意事项部分的指南”[4]中概述的政策，普通事件包标识令牌按先到先得的方式分配，事件模板包标识令牌按IETF共识分配。
Registrations with the IANA MUST include the token being registered and whether the token is a package or a template-package. Further, packages MUST include contact information for the party responsible for the registration and/or a published document which describes the event package. Event template-package token registrations MUST include a pointer to the published RFC which defines the event template-package.
IANA注册必须包括正在注册的令牌以及令牌是包还是模板包。此外，文件包必须包括负责注册的一方的联系信息和/或描述活动文件包的已发布文件。事件模板包令牌注册必须包括指向已发布RFC的指针，该RFC定义了事件模板包。
Registered tokens to designate packages and template-packages MUST NOT contain the character ".", which is used to separate template-packages from packages.
用于指定包和模板包的已注册令牌不得包含字符“”，该字符用于将模板包与包分开。
As this document specifies no package or template-package names, the initial IANA registration for event types will be empty. The remainder of the text in this section gives an example of the type of information to be maintained by the IANA; it also demonstrates all five possible permutations of package type, contact, and reference.
由于本文档未指定包或模板包名称，因此事件类型的初始IANA注册将为空。本节剩余部分给出了IANA需要维护的信息类型示例；它还演示了包类型、联系人和引用的所有五种可能的排列。
The table below lists the event packages and template-packages defined in "SIP-Specific Event Notification" [RFC3265]. Each name is designated as a package or a template-package under "Type".
下表列出了“SIP特定事件通知”[RFC3265]中定义的事件包和模板包。每个名称都被指定为“类型”下的包或模板包。
Package Name Type Contact Reference
------------ ---- ------- ---------
example1 package [Roach]
example2 package [Roach] [RFC3265]
example3 package [RFC3265]
example4 template [Roach] [RFC3265]
example5 template [RFC3265]
Package Name Type Contact Reference
------------ ---- ------- ---------
example1 package [Roach]
example2 package [Roach] [RFC3265]
example3 package [RFC3265]
example4 template [Roach] [RFC3265]
example5 template [RFC3265]
PEOPLE
------
[Roach] Adam Roach <adam@dynamicsoft.com>
PEOPLE
------
[Roach] Adam Roach <adam@dynamicsoft.com>
REFERENCES
----------
[RFC3265] Roach, A., "SIP-Specific Event Notification", RFC 3265,
June 2002.
REFERENCES
----------
[RFC3265] Roach, A., "SIP-Specific Event Notification", RFC 3265,
June 2002.
To: ietf-sip-events@iana.org Subject: Registration of new SIP event package
致：ietf sip-events@iana.org主题：注册新SIP事件包
Package Name:
包名称：
(Package names must conform to the syntax described in section 7.2.1.)
（软件包名称必须符合第7.2.1节中描述的语法。）
Is this registration for a Template Package:
这是对模板包的注册：
(indicate yes or no)
（表示是或否）
Published Specification(s):
已发布的规范：
(Template packages require a published RFC. Other packages may reference a specification when appropriate).
（模板包要求发布RFC。其他包可在适当时引用规范）。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
This document registers three new header field names, described elsewhere in this document. These headers are defined by the following information, which is to be added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
本文档注册了三个新的标题字段名，如本文档其他部分所述。这些标头由以下信息定义，这些信息将添加到下的标头子注册表中http://www.iana.org/assignments/sip-parameters.
Header Name: Allow-Events Compact Form: u
标题名称：允许事件压缩格式：u
Header Name: Subscription-State Compact Form: (none)
标题名称：订阅状态压缩表单：（无）
Header Name: Event Compact Form: o
标题名称：事件压缩格式：o
This document registers two new response codes. These response codes are defined by the following information, which is to be added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
本文件登记了两个新的响应代码。这些响应代码由以下信息定义，这些信息将添加到下的方法和响应代码子注册表中http://www.iana.org/assignments/sip-parameters.
Response Code Number: 202 Default Reason Phrase: Accepted
响应代码：202默认原因短语：已接受
Response Code Number: 489 Default Reason Phrase: Bad Event
响应代码：489默认原因短语：错误事件
This section describes the syntax extensions required for event notification in SIP. Semantics are described in section 3. Note that the formal syntax definitions described in this document are expressed in the ABNF format used in SIP [1], and contain references to elements defined therein.
本节介绍SIP中事件通知所需的语法扩展。第3节描述了语义。请注意，本文档中描述的正式语法定义以SIP[1]中使用的ABNF格式表示，并包含对其中定义的元素的引用。
This document describes two new SIP methods: SUBSCRIBE and NOTIFY.
本文档描述了两种新的SIP方法：订阅和通知。
This table expands on tables 2 and 3 in SIP [1].
此表扩展了SIP[1]中的表2和表3。
Header Where SUB NOT
------ ----- --- ---
Accept R o o
Accept 2xx - -
Accept 415 o o
Accept-Encoding R o o
Accept-Encoding 2xx - -
Accept-Encoding 415 o o
Accept-Language R o o
Accept-Language 2xx - -
Accept-Language 415 o o
Alert-Info R - -
Alert-Info 180 - -
Allow R o o
Header Where SUB NOT
------ ----- --- ---
Accept R o o
Accept 2xx - -
Accept 415 o o
Accept-Encoding R o o
Accept-Encoding 2xx - -
Accept-Encoding 415 o o
Accept-Language R o o
Accept-Language 2xx - -
Accept-Language 415 o o
Alert-Info R - -
Alert-Info 180 - -
Allow R o o
Allow 2xx o o Allow r o o Allow 405 m m Authentication-Info 2xx o o Authorization R o o Call-ID c m m Contact R m m Contact 1xx o o Contact 2xx m o Contact 3xx m m Contact 485 o o Content-Disposition o o Content-Encoding o o Content-Language o o Content-Length t t Content-Type * * CSeq c m m Date o o Error-Info 300-699 o o Expires o - Expires 2xx m - From c m m In-Reply-To R - - Max-Forwards R m m Min-Expires 423 m - MIME-Version o o Organization o - Priority R o - Proxy-Authenticate 407 m m Proxy-Authorization R o o Proxy-Require R o o RAck R - - Record-Route R o o Record-Route 2xx,401,484 o o Reply-To - - Require o o Retry-After 404,413,480,486 o o Retry-After 500,503 o o Retry-After 600,603 o o Route R c c RSeq 1xx o o Server r o o Subject R - - Supported R o o Supported 2xx o o Timestamp o o To c(1) m m Unsupported 420 o o
允许2xx o o允许r o o o允许405m身份验证信息2xx o授权r o o呼叫ID c m m m联系人r m m m联系人1xx o联系人2xx m o联系人3xx m m m联系人485 o o内容处理o内容编码o内容语言o内容长度t内容类型**CSeq c m日期o错误信息300-699 o过期o-过期2xxm-从c m m回复R--最大转发R m最小过期423 m-MIME版本o o组织o-优先级R o-代理验证407 m代理授权R o代理要求R o机架R--记录路由R o记录路由2xx，401484 o o回复-要求o在404413480486后重试o在500503后重试o在600603后重试o路由R c c RSeq 1x o服务器R o主题R-支持的R o支持的2xx o时间戳o到c（1）m m m不支持的420 o o
User-Agent o o Via c m m Warning R - o Warning r o o WWW-Authenticate 401 m m
用户代理o o通过c m m Warning R-o Warning R o WWW验证401 m
"SUBSCRIBE" is added to the definition of the element "Method" in the SIP message grammar.
“SUBSCRIBE”被添加到SIP消息语法中元素“Method”的定义中。
Like all SIP method names, the SUBSCRIBE method name is case sensitive. The SUBSCRIBE method is used to request asynchronous notification of an event or set of events at a later time.
与所有SIP方法名称一样，SUBSCRIBE方法名称区分大小写。SUBSCRIBE方法用于在以后请求事件或事件集的异步通知。
"NOTIFY" is added to the definition of the element "Method" in the SIP message grammar.
“NOTIFY”被添加到SIP消息语法中元素“Method”的定义中。
The NOTIFY method is used to notify a SIP node that an event which has been requested by an earlier SUBSCRIBE method has occurred. It may also provide further details about the event.
NOTIFY方法用于通知SIP节点发生了由早期订阅方法请求的事件。它还可能提供有关该活动的进一步详情。
This table expands on tables 2 and 3 in SIP [1], as amended by the changes described in section 7.1.
本表扩展了SIP[1]中的表2和表3，并根据第7.1节中所述的变更进行了修订。
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Allow-Events R o o - o o o o o o
Allow-Events 2xx - o - o o o o o o
Allow-Events 489 - - - - - - - m m
Event R - - - - - - - m m
Subscription-State R - - - - - - - - m
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Allow-Events R o o - o o o o o o
Allow-Events 2xx - o - o o o o o o
Allow-Events 489 - - - - - - - m m
Event R - - - - - - - m m
Subscription-State R - - - - - - - - m
Event is added to the definition of the element "message-header" in the SIP message grammar.
事件添加到SIP消息语法中元素“消息头”的定义中。
For the purposes of matching responses and NOTIFY messages with SUBSCRIBE messages, the event-type portion of the "Event" header is compared byte-by-byte, and the "id" parameter token (if present) is compared byte-by-byte. An "Event" header containing an "id" parameter never matches an "Event" header without an "id" parameter. No other parameters are considered when performing a comparison.
为了将响应和通知消息与订阅消息进行匹配，“事件”头的事件类型部分逐字节比较，“id”参数标记（如果存在）逐字节比较。包含“id”参数的“事件”标头与没有“id”参数的“事件”标头从不匹配。执行比较时不考虑其他参数。
Note that the forgoing text means that "Event: foo; id=1234" would match "Event: foo; param=abcd; id=1234", but not "Event: foo" (id does not match) or "Event: Foo; id=1234" (event portion does not match).
请注意，上述文本表示“事件：foo；id=1234”将匹配“事件：foo；参数=abcd；id=1234”，但不匹配“事件：foo”（id不匹配）或“事件：foo；id=1234”（事件部分不匹配）。
This document does not define values for event-types. These values will be defined by individual event packages, and MUST be registered with the IANA.
本文档不定义事件类型的值。这些值将由单个事件包定义，并且必须向IANA注册。
There MUST be exactly one event type listed per event header. Multiple events per message are disallowed.
每个事件头必须只列出一个事件类型。不允许每条消息有多个事件。
Allow-Events is added to the definition of the element "general-header" in the SIP message grammar. Its usage is described in section 3.3.7.
允许事件被添加到SIP消息语法中元素“general header”的定义中。第3.3.7节描述了其用途。
Subscription-State is added to the definition of the element "request-header" in the SIP message grammar. Its usage is described in section 3.2.4.
订阅状态添加到SIP消息语法中元素“请求头”的定义中。第3.2.4节描述了其用途。
The 202 response is added to the "Success" header field definition. "202 Accepted" has the same meaning as that defined in HTTP/1.1 [3].
202响应被添加到“Success”头字段定义中。“202已接受”与HTTP/1.1[3]中定义的含义相同。
The 489 event response is added to the "Client-Error" header field definition. "489 Bad Event" is used to indicate that the server did not understand the event package specified in a "Event" header field.
489事件响应被添加到“客户端错误”标题字段定义中。“489错误事件”用于表示服务器不理解“事件”标题字段中指定的事件包。
The Augmented BNF definitions for the various new and modified syntax elements follows. The notation is as used in SIP [1], and any elements not defined in this section are as defined in SIP and the documents to which it refers.
下面是各种新的和修改过的语法元素的扩充BNF定义。符号与SIP[1]中使用的符号相同，本节中未定义的任何元素与SIP及其引用的文件中的定义相同。
SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE in caps
NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY in caps
extension-method = SUBSCRIBEm / NOTIFYm / token
SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE in caps
NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY in caps
extension-method = SUBSCRIBEm / NOTIFYm / token
Event = ( "Event" / "o" ) HCOLON event-type
*( SEMI event-param )
event-type = event-package *( "." event-template )
event-package = token-nodot
event-template = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
event-param = generic-param / ( "id" EQUAL token )
Event = ( "Event" / "o" ) HCOLON event-type
*( SEMI event-param )
event-type = event-package *( "." event-template )
event-package = token-nodot
event-template = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
event-param = generic-param / ( "id" EQUAL token )
Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type
*(COMMA event-type)
Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type
*(COMMA event-type)
Subscription-State = "Subscription-State" HCOLON substate-value
*( SEMI subexp-params )
substate-value = "active" / "pending" / "terminated"
/ extension-substate
extension-substate = token
subexp-params = ("reason" EQUAL event-reason-value)
/ ("expires" EQUAL delta-seconds)
/ ("retry-after" EQUAL delta-seconds)
/ generic-param
event-reason-value = "deactivated"
/ "probation"
/ "rejected"
/ "timeout"
/ "giveup"
/ "noresource"
/ event-reason-extension
event-reason-extension = token
Subscription-State = "Subscription-State" HCOLON substate-value
*( SEMI subexp-params )
substate-value = "active" / "pending" / "terminated"
/ extension-substate
extension-substate = token
subexp-params = ("reason" EQUAL event-reason-value)
/ ("expires" EQUAL delta-seconds)
/ ("retry-after" EQUAL delta-seconds)
/ generic-param
event-reason-value = "deactivated"
/ "probation"
/ "rejected"
/ "timeout"
/ "giveup"
/ "noresource"
/ event-reason-extension
event-reason-extension = token
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Petrack, S. and L. Conroy, "The PINT Service Protocol", RFC 2848, June 2000.
[2] Petrack，S.和L.Conroy，“品脱服务协议”，RFC 28482000年6月。
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[5] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.
[6] Day，M.，Aggarwal，S.，Mohr，G.和J.Vincent，“即时消息传递/存在协议要求”，RFC 27792000年2月。
[7] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP Extensions", Work in Progress.
[7] Rosenberg，J.和H.Schulzrinne，“SIP扩展作者指南”，正在进行中。
[8] Schulzrinne, H. and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
[8] Schulzrinne，H.和J.Rosenberg，“SIP呼叫方偏好和被呼叫方能力”，正在进行中。
Thanks to the participants in the Events BOF at the 48th IETF meeting in Pittsburgh, as well as those who gave ideas and suggestions on the SIP Events mailing list. In particular, I wish to thank Henning Schulzrinne of Columbia University for coming up with the final three-tiered event identification scheme, Sean Olson for miscellaneous guidance, Jonathan Rosenberg for a thorough scrubbing of the -00 draft, and the authors of the "SIP Extensions for Presence" document for their input to SUBSCRIBE and NOTIFY request semantics.
感谢匹兹堡第48届IETF会议上BOF活动的参与者，以及那些对SIP活动邮件列表提出想法和建议的人。特别是，我要感谢哥伦比亚大学的Henning Schulzrinne提出了最终的三层事件识别方案，Sean Olson提供了杂项指导，Jonathan Rosenberg对-00草案进行了彻底清理，以及“SIP存在扩展”的作者文档用于订阅和通知请求语义的输入。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights at http://www.ietf.org/ipr.html
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请参阅以下网站的在线权利主张列表：http://www.ietf.org/ipr.html
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
美国德克萨斯州普莱诺市坦尼森大道1200号亚当·罗奇动力软件5100套房，邮编75024
EMail: adam@dynamicsoft.com
Voice: sip:adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
Voice: sip:adam@dynamicsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。