Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 6665 Tekelec
Obsoletes: 3265 July 2012
Updates: 3261, 4660
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 6665 Tekelec
Obsoletes: 3265 July 2012
Updates: 3261, 4660
Category: Standards Track
ISSN: 2070-1721
SIP-Specific Event Notification
特定于SIP的事件通知
Abstract
摘要
This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. 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.
本文档描述了RFC 3261定义的会话启动协议（SIP）的扩展。此扩展的目的是提供一个可扩展的框架，通过该框架，SIP节点可以从远程节点请求指示已发生某些事件的通知。
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.
请注意，本文定义的事件通知机制并不打算成为所有类别的事件订阅和通知的通用基础设施。
This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document.
考虑到多年的实施经验，本文件代表了对RFC 3265所述原始机制的向后兼容改进。因此，本文件废除了RFC 3265。本文档还略微更新了RFC 4660，以适应该文档中讨论的机制的一些小更改。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6665.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6665.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview of Operation . . . . . . . . . . . . . . . . . . 5
1.2. Documentation Conventions . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. SIP Methods for Event Notification . . . . . . . . . . . . . . 7
3.1. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Subscription Duration . . . . . . . . . . . . . . . . 7
3.1.2. Identification of Subscribed Events and Event
Classes . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Additional SUBSCRIBE Header Field Values . . . . . . . 9
3.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Identification of Reported Events, Event Classes,
and Current State . . . . . . . . . . . . . . . . . . 9
4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10
4.1.1. Detecting Support for SIP Events . . . . . . . . . . . 10
4.1.2. Creating and Maintaining Subscriptions . . . . . . . . 10
4.1.3. Receiving and Processing State Information . . . . . . 14
4.1.4. Forking of SUBSCRIBE Requests . . . . . . . . . . . . 16
4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Subscription Establishment and Maintenance . . . . . . 17
4.2.2. Sending State Information to Subscribers . . . . . . . 20
4.2.3. PSTN/Internet Interworking (PINT) Compatibility . . . 23
4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Dialog Creation and Termination . . . . . . . . . . . 24
4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 24
4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 25
4.4.4. "Allow-Events" Header Field Usage . . . . . . . . . . 26
4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 26
4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview of Operation . . . . . . . . . . . . . . . . . . 5
1.2. Documentation Conventions . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. SIP Methods for Event Notification . . . . . . . . . . . . . . 7
3.1. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Subscription Duration . . . . . . . . . . . . . . . . 7
3.1.2. Identification of Subscribed Events and Event
Classes . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Additional SUBSCRIBE Header Field Values . . . . . . . 9
3.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Identification of Reported Events, Event Classes,
and Current State . . . . . . . . . . . . . . . . . . 9
4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10
4.1.1. Detecting Support for SIP Events . . . . . . . . . . . 10
4.1.2. Creating and Maintaining Subscriptions . . . . . . . . 10
4.1.3. Receiving and Processing State Information . . . . . . 14
4.1.4. Forking of SUBSCRIBE Requests . . . . . . . . . . . . 16
4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Subscription Establishment and Maintenance . . . . . . 17
4.2.2. Sending State Information to Subscribers . . . . . . . 20
4.2.3. PSTN/Internet Interworking (PINT) Compatibility . . . 23
4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Dialog Creation and Termination . . . . . . . . . . . 24
4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 24
4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 25
4.4.4. "Allow-Events" Header Field Usage . . . . . . . . . . 26
4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 26
4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 27
4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 27
4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions . . 29
5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 29
5.2. Event Template-Packages . . . . . . . . . . . . . . . . . 30
5.3. Amount of State to Be Conveyed . . . . . . . . . . . . . . 31
5.3.1. Complete State Information . . . . . . . . . . . . . . 31
5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 32
5.4. Event Package Responsibilities . . . . . . . . . . . . . . 32
5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 33
5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 33
5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 33
5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33
5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 34
5.4.6. Notifier Processing of SUBSCRIBE Requests . . . . . . 34
5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 34
5.4.8. Subscriber Processing of NOTIFY Requests . . . . . . . 34
5.4.9. Handling of Forked Requests . . . . . . . . . . . . . 34
5.4.10. Rate of Notifications . . . . . . . . . . . . . . . . 35
5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35
5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36
6.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 37
6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
6.5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 37
6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Registration Information . . . . . . . . . . . . . . . 39
7.1.2. Registration Template . . . . . . . . . . . . . . . . 40
7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 40
7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 41
7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.1. SUBSCRIBE Method . . . . . . . . . . . . . . . . . . . 42
8.1.2. NOTIFY Method . . . . . . . . . . . . . . . . . . . . 42
8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42
8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 42
8.2.2. "Allow-Events" Header Field . . . . . . . . . . . . . 43
8.2.3. "Subscription-State" Header Field . . . . . . . . . . 43
8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43
8.3.1. 202 (Accepted) Response Code . . . . . . . . . . . . . 43
8.3.2. 489 (Bad Event) Response Code . . . . . . . . . . . . 44
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 44
4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 27
4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions . . 29
5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 29
5.2. Event Template-Packages . . . . . . . . . . . . . . . . . 30
5.3. Amount of State to Be Conveyed . . . . . . . . . . . . . . 31
5.3.1. Complete State Information . . . . . . . . . . . . . . 31
5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 32
5.4. Event Package Responsibilities . . . . . . . . . . . . . . 32
5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 33
5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 33
5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 33
5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33
5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 34
5.4.6. Notifier Processing of SUBSCRIBE Requests . . . . . . 34
5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 34
5.4.8. Subscriber Processing of NOTIFY Requests . . . . . . . 34
5.4.9. Handling of Forked Requests . . . . . . . . . . . . . 34
5.4.10. Rate of Notifications . . . . . . . . . . . . . . . . 35
5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35
5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36
6.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 37
6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 37
6.5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 37
6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Registration Information . . . . . . . . . . . . . . . 39
7.1.2. Registration Template . . . . . . . . . . . . . . . . 40
7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 40
7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 41
7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.1. SUBSCRIBE Method . . . . . . . . . . . . . . . . . . . 42
8.1.2. NOTIFY Method . . . . . . . . . . . . . . . . . . . . 42
8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42
8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 42
8.2.2. "Allow-Events" Header Field . . . . . . . . . . . . . 43
8.2.3. "Subscription-State" Header Field . . . . . . . . . . 43
8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43
8.3.1. 202 (Accepted) Response Code . . . . . . . . . . . . . 43
8.3.2. 489 (Bad Event) Response Code . . . . . . . . . . . . 44
8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 48
B.1. Bug 666: Clarify use of "expires=xxx" with "terminated" . 48
B.2. Bug 667: Reason code for unsub/poll not clearly
spelled out . . . . . . . . . . . . . . . . . . . . . . . 48
B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be
answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 48
B.4. Bug 670: Dialog State Machine needs clarification . . . . 49
B.5. Bug 671: Clarify timeout-based removal of subscriptions . 49
B.6. Bug 672: Mandate "expires" in NOTIFY . . . . . . . . . . . 49
B.7. Bug 673: INVITE 481 response effect clarification . . . . 49
B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 49
B.9. Bug 695: Document is not explicit about response to
NOTIFY at subscription termination . . . . . . . . . . . . 49
B.10. Bug 696: Subscription state machine needs clarification . 49
B.11. Bug 697: Unsubscription behavior could be clarified . . . 49
B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
requests . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 50
B.14. Bug 741: Guidance needed on when to not include
"Allow-Events" . . . . . . . . . . . . . . . . . . . . . . 50
B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but
should not . . . . . . . . . . . . . . . . . . . . . . . . 50
B.16. Bug 752: Detection of forked requests is incorrect . . . . 50
B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 50
B.18. Bug 774: Need new reason for terminating subscriptions
to resources that never change . . . . . . . . . . . . . . 50
B.19. Clarify Handling of "Route"/"Record-Route" in NOTIFY . . . 50
B.20. Eliminate Implicit Subscriptions . . . . . . . . . . . . . 51
B.21. Deprecate Dialog Reuse . . . . . . . . . . . . . . . . . . 51
B.22. Rationalize Dialog Creation . . . . . . . . . . . . . . . 51
B.23. Refactor Behavior Sections . . . . . . . . . . . . . . . . 51
B.24. Clarify Sections That Need to Be Present in Event
Packages . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.25. Make CANCEL Handling More Explicit . . . . . . . . . . . . 51
B.26. Remove "State Agent" Terminology . . . . . . . . . . . . . 51
B.27. Miscellaneous Changes . . . . . . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 48
B.1. Bug 666: Clarify use of "expires=xxx" with "terminated" . 48
B.2. Bug 667: Reason code for unsub/poll not clearly
spelled out . . . . . . . . . . . . . . . . . . . . . . . 48
B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be
answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 48
B.4. Bug 670: Dialog State Machine needs clarification . . . . 49
B.5. Bug 671: Clarify timeout-based removal of subscriptions . 49
B.6. Bug 672: Mandate "expires" in NOTIFY . . . . . . . . . . . 49
B.7. Bug 673: INVITE 481 response effect clarification . . . . 49
B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 49
B.9. Bug 695: Document is not explicit about response to
NOTIFY at subscription termination . . . . . . . . . . . . 49
B.10. Bug 696: Subscription state machine needs clarification . 49
B.11. Bug 697: Unsubscription behavior could be clarified . . . 49
B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh
requests . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 50
B.14. Bug 741: Guidance needed on when to not include
"Allow-Events" . . . . . . . . . . . . . . . . . . . . . . 50
B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but
should not . . . . . . . . . . . . . . . . . . . . . . . . 50
B.16. Bug 752: Detection of forked requests is incorrect . . . . 50
B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 50
B.18. Bug 774: Need new reason for terminating subscriptions
to resources that never change . . . . . . . . . . . . . . 50
B.19. Clarify Handling of "Route"/"Record-Route" in NOTIFY . . . 50
B.20. Eliminate Implicit Subscriptions . . . . . . . . . . . . . 51
B.21. Deprecate Dialog Reuse . . . . . . . . . . . . . . . . . . 51
B.22. Rationalize Dialog Creation . . . . . . . . . . . . . . . 51
B.23. Refactor Behavior Sections . . . . . . . . . . . . . . . . 51
B.24. Clarify Sections That Need to Be Present in Event
Packages . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.25. Make CANCEL Handling More Explicit . . . . . . . . . . . . 51
B.26. Remove "State Agent" Terminology . . . . . . . . . . . . . 51
B.27. Miscellaneous Changes . . . . . . . . . . . . . . . . . . 52
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) [RFC2848] status (based on call state events).
请求异步事件通知的能力在许多类型的SIP服务中证明是有用的，这些服务需要终端节点之间的协作。此类服务的示例包括自动回调服务（基于终端状态事件）、好友列表（基于用户存在事件）、消息等待指示（基于邮箱状态更改事件）以及PSTN和互联网互联（PINT）[RFC2848]状态（基于呼叫状态事件）。
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 that is not so complex as to be unusable for simple features, but that is still flexible enough to provide powerful services. Note, however, that event packages based on this framework may define arbitrarily elaborate rules that govern the subscription and notification for the events or classes of events they describe.
本文定义的事件通知机制并不打算成为所有类别的事件订阅和通知的通用基础设施。满足订阅和通知的一般问题集的要求对于单个协议来说太复杂了。我们的目标是为事件通知提供一个特定于SIP的框架，该框架不太复杂，不能用于简单的功能，但仍然足够灵活，可以提供强大的服务。但是，请注意，基于此框架的事件包可能会定义任意详细的规则，用于管理它们所描述的事件或事件类的订阅和通知。
This document does not describe an extension that 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 that must be derived into an instantiable class by further extensions. Guidelines for creating these extensions are described in Section 5.
本文件不描述可直接使用的扩展；必须通过其他文件（此处称为“事件包”）进行扩展。在面向对象的设计术语中，它可能被认为是一个抽象基类，必须通过进一步的扩展派生成一个可实例化的类。第5节介绍了创建这些扩展的指导原则。
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 requests.
订阅已过期，必须由后续订阅请求刷新。
There are several paragraphs throughout this document that 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.
这是非规范性解释性文本的一个例子。它不构成本规范的一部分，仅用于澄清。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In particular, implementors need to take careful note of the meaning of "SHOULD" defined in RFC 2119. To rephrase: violation of "SHOULD"- strength requirements requires careful analysis and clearly enumerable reasons. It is a protocol violation to fail to comply with "SHOULD"-strength requirements whimsically or for ease of implementation.
具体而言，实施者需要仔细注意RFC2119中定义的“应该”的含义。换言之：违反“应该”-强度要求需要仔细分析并明确列举原因。不遵守“应该”——异想天开的强度要求或为便于实施而违反协议。
Event Package: An event package is an additional specification that defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics that are based on the framework defined by this document and are required to convey such state information.
事件包：事件包是一个附加规范，它定义了一组状态信息，由通知程序向订阅服务器报告。事件包还定义了进一步的语法和语义，这些语法和语义基于本文档定义的框架，并且是传递此类状态信息所必需的。
Event Template-Package: An event template-package is a special kind of event package that defines a set of states that may be applied to all possible event packages, including itself.
事件模板包：事件模板包是一种特殊的事件包，它定义了一组可应用于所有可能的事件包（包括其自身）的状态。
Notification: Notification is the act of a notifier sending a NOTIFY request to a subscriber to inform the subscriber of the state of a resource.
通知：通知是通知程序向订户发送通知请求以通知订户资源状态的行为。
Notifier: A notifier is a user agent that generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept SUBSCRIBE requests to create subscriptions.
通知程序：通知程序是一个用户代理，它生成通知请求，以便通知订阅者资源的状态。通知程序通常也接受订阅请求以创建订阅。
Subscriber: A subscriber is a user agent that 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 requests are target refresh requests, as that term is defined in [RFC3261].
SUBSCRIBE方法用于从远程节点请求当前状态和状态更新。订阅请求是目标刷新请求，该术语在[RFC3261]中定义。
SUBSCRIBE requests SHOULD contain an "Expires" header field (defined in [RFC3261]). This expires value indicates the duration of the subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header field, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE request on the same dialog as defined in [RFC3261].
订阅请求应包含“Expires”标头字段（在[RFC3261]中定义）。此expires值指示订阅的持续时间。为了使订阅在“Expires”标题字段中传达的持续时间之后保持有效，订阅方需要在[RFC3261]中定义的同一对话框中使用新订阅请求定期刷新订阅。
If no "Expires" header field is present in a SUBSCRIBE request, the implied default MUST be defined by the event package being used.
如果订阅请求中不存在“Expires”头字段，则所使用的事件包必须定义隐含的默认值。
200-class responses to SUBSCRIBE requests also MUST contain an "Expires" header field. The period of time in the response MAY be shorter but MUST NOT be longer than specified in the request. The notifier is explicitly allowed to shorten the duration to zero. The period of time in the response is the one that defines the duration of the subscription.
订阅请求的200类响应还必须包含“Expires”头字段。响应中的时间段可能较短，但不得长于请求中指定的时间段。明确允许通知程序将持续时间缩短为零。响应中的时间段是定义订阅持续时间的时间段。
An "expires" parameter on the "Contact" header field has no semantics for the SUBSCRIBE method and is explicitly not equivalent to an "Expires" header field in a SUBSCRIBE request or response.
“Contact”头字段上的“expires”参数对于SUBSCRIBE方法没有语义，并且显式地不等同于订阅请求或响应中的“expires”头字段。
A natural consequence of this scheme is that a SUBSCRIBE request with an "Expires" of 0 constitutes a request to unsubscribe from the matching subscription.
此方案的自然结果是，“Expires”为0的订阅请求构成从匹配订阅取消订阅的请求。
In addition to being a request to unsubscribe, a SUBSCRIBE request with "Expires" of 0 also causes a fetch of state; see Section 4.4.3.
除了作为取消订阅的请求外，“Expires”为0的订阅请求还导致获取状态；见第4.4.3节。
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 4.2.2.
通知者也可能希望取消对事件的订阅；例如，当订阅引用的资源不再可用时，这非常有用。第4.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 [RFC3261]. 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@example.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包含足够的信息，可以根据[RFC3261]中概述的请求路由过程将请求路由到适当的实体。它还包含足够的信息来标识需要事件通知的资源，但不一定包含足够的信息来唯一标识事件的性质（例如，“sip:adam@example.com"将是订阅我的状态的适当URI；它也是订阅我的语音邮箱状态的适当URI）。
Subscribers MUST include exactly one "Event" header field in SUBSCRIBE requests, indicating to which event or class of events they are subscribing. The "Event" header field will contain a token that 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 that further describes the semantics of the event or event class.
订阅服务器必须在订阅请求中仅包含一个“事件”头字段，指示订阅的事件或事件类别。“事件”标题字段将包含一个令牌，该令牌指示请求订阅的状态类型。该令牌将在IANA中注册，并与进一步描述事件或事件类语义的事件包相对应。
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 field; if they do so, they must define the semantics for such parameters.
事件包还可以定义“事件”标题字段的参数；如果他们这样做，他们必须定义这些参数的语义。
Because SUBSCRIBE requests create a dialog usage as defined in [RFC3261], they MAY contain an "Accept" header field. This header field, if present, indicates the body formats allowed in subsequent NOTIFY requests. Event packages MUST define the behavior for SUBSCRIBE requests without "Accept" header fields; usually, this will connote a single, default body type.
因为订阅请求创建了[RFC3261]中定义的对话框用法，所以它们可能包含一个“接受”标题字段。此标头字段（如果存在）指示后续NOTIFY请求中允许的正文格式。事件包必须定义不带“Accept”头字段的订阅请求的行为；通常，这将意味着一个单一的默认主体类型。
Header values not described in this document are to be interpreted as described in [RFC3261].
本文件中未描述的标题值应按照[RFC3261]中的说明进行解释。
NOTIFY requests are sent to inform subscribers of changes in state to which the subscriber has a subscription. Subscriptions are created using the SUBSCRIBE method. In legacy implementations, it is possible that other means of subscription creation have been used. However, this specification does not allow the creation of subscriptions except through SUBSCRIBE requests and (for backwards-compatibility) REFER requests [RFC3515].
发送NOTIFY请求以通知订阅服务器订阅状态的更改。使用SUBSCRIBE方法创建订阅。在遗留实现中，可能使用了其他订阅创建方法。但是，本规范不允许创建订阅，除非通过订阅请求和（为了向后兼容性）REFER请求[RFC3515]。
NOTIFY is a target refresh request, as that term is defined in [RFC3261].
NOTIFY是一个目标刷新请求，该术语在[RFC3261]中定义。
A NOTIFY request 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 request "Event" header fields MUST contain a single event package name for which a notification is being generated. The package name in the "Event" header field MUST match the "Event" header field in the corresponding SUBSCRIBE request.
与在订阅请求中一样，NOTIFY request“Event”标头字段必须包含正在为其生成通知的单个事件包名称。“事件”标题字段中的包名称必须与相应订阅请求中的“事件”标题字段匹配。
Event packages may define semantics associated with the body of their NOTIFY requests; if they do so, those semantics apply. NOTIFY request bodies are expected to provide additional details about the nature of the event that has occurred and the resultant resource state.
事件包可以定义与其NOTIFY请求主体相关联的语义；如果他们这样做了，这些语义就适用了。NOTIFY请求机构应提供有关已发生事件的性质和结果资源状态的其他详细信息。
When present, the body of the NOTIFY request MUST be formatted into one of the body formats specified in the "Accept" header field of the corresponding SUBSCRIBE request (or the default type according to the event package description, if no "Accept" header field was specified). 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 5.4.13).
当存在时，通知请求的正文必须格式化为相应订阅请求的“接受”标题字段中指定的正文格式之一（或根据事件包描述的默认类型，如果未指定“接受”标题字段）。此正文将包含订阅资源的状态或URI形式的指向该状态的指针（见第5.4.13节）。
The extension described in this document does not make use of the "Require" or "Proxy-Require" header fields; similarly, there is no token defined for "Supported" header fields. Potential subscribers may probe for the support of SIP events using the OPTIONS request defined in [RFC3261].
本文档中描述的扩展未使用“Require”或“Proxy Require”标题字段；类似地，没有为“支持的”头字段定义令牌。潜在订阅者可以使用[RFC3261]中定义的选项请求来探测对SIP事件的支持。
The presence of "SUBSCRIBE" in the "Allow" header field of any request or response indicates support for SIP events; further, in the absence of an "Allow" header field, the simple presence of an "Allow-Events" header field is sufficient to indicate that the node that sent the message is capable of acting as a notifier (see Section 4.4.4).
任何请求或响应的“允许”头字段中出现“订阅”表示支持SIP事件；此外，在没有“允许”报头字段的情况下，“允许事件”报头字段的简单存在足以表明发送消息的节点能够充当通知者（参见第4.4.4节）。
The "methods" parameter for Contact may also be used to specifically announce support for SUBSCRIBE and NOTIFY requests when registering. (See [RFC3840] for details on the "methods" parameter.)
联系人的“方法”参数也可用于在注册时专门宣布对订阅和通知请求的支持。（有关“方法”参数的详细信息，请参见[RFC3840]
From the subscriber's perspective, a subscription proceeds according to the following state diagram. Events that result in a transition back to the same state are not represented in this diagram.
从订户的角度来看，订阅按照以下状态图进行。导致转换回相同状态的事件不在此图中表示。
+-------------+
| init |<-----------------------+
+-------------+ |
| Retry-after
Send SUBSCRIBE expires
| |
V Timer N Fires; |
+-------------+ SUBSCRIBE failure |
+------------| notify_wait |-- response; --------+ |
| +-------------+ or NOTIFY, | |
| | state=terminated | |
| | | |
++========|===================|============================|==|====++
|| | | V | ||
|| Receive NOTIFY, Receive NOTIFY, +-------------+ ||
|| state=active state=pending | terminated | ||
|| | | +-------------+ ||
|| | | Re-subscription A A ||
|| | V times out; | | ||
|| | +-------------+ Receive NOTIFY, | | ||
|| | | pending |-- state=terminated; --+ | ||
|| | +-------------+ or 481 response | ||
|| | | to SUBSCRIBE | ||
|| | Receive NOTIFY, refresh | ||
|| | state=active | ||
|| | | Re-subscription | ||
|| | V times out; | ||
|| | +-------------+ Receive NOTIFY, | ||
|| +----------->| active |-- state=terminated; -----+ ||
|| +-------------+ or 481 response ||
|| to SUBSCRIBE ||
|| Subscription refresh ||
++=================================================================++
+-------------+
| init |<-----------------------+
+-------------+ |
| Retry-after
Send SUBSCRIBE expires
| |
V Timer N Fires; |
+-------------+ SUBSCRIBE failure |
+------------| notify_wait |-- response; --------+ |
| +-------------+ or NOTIFY, | |
| | state=terminated | |
| | | |
++========|===================|============================|==|====++
|| | | V | ||
|| Receive NOTIFY, Receive NOTIFY, +-------------+ ||
|| state=active state=pending | terminated | ||
|| | | +-------------+ ||
|| | | Re-subscription A A ||
|| | V times out; | | ||
|| | +-------------+ Receive NOTIFY, | | ||
|| | | pending |-- state=terminated; --+ | ||
|| | +-------------+ or 481 response | ||
|| | | to SUBSCRIBE | ||
|| | Receive NOTIFY, refresh | ||
|| | state=active | ||
|| | | Re-subscription | ||
|| | V times out; | ||
|| | +-------------+ Receive NOTIFY, | ||
|| +----------->| active |-- state=terminated; -----+ ||
|| +-------------+ or 481 response ||
|| to SUBSCRIBE ||
|| Subscription refresh ||
++=================================================================++
In the state diagram, "Re-subscription times out" means that an attempt to refresh or update the subscription using a new SUBSCRIBE request does not result in a NOTIFY request before the corresponding Timer N expires.
在状态图中，“重新订阅超时”表示尝试使用新订阅请求刷新或更新订阅不会导致在相应计时器N到期之前发出通知请求。
Any transition from "notify_wait" into a "pending" or "active" state results in a new subscription. Note that multiple subscriptions can be generated as the result of a single SUBSCRIBE request (see Section 4.4.1). Each of these new subscriptions exists in its own independent state machine and runs its own set of timers.
从“notify_wait”到“pending”或“active”状态的任何转换都会导致新订阅。请注意，单个订阅请求可以生成多个订阅（请参阅第4.4.1节）。每个新订阅都存在于自己的独立状态机中，并运行自己的一组计时器。
SUBSCRIBE is a dialog-creating method, as described in [RFC3261].
订阅是一种对话框创建方法，如[RFC3261]所述。
When a subscriber wishes to subscribe to a particular state for a resource, it forms a SUBSCRIBE request. If the initial SUBSCRIBE request represents a request outside of a dialog (as it typically will), its construction follows the procedures outlined in [RFC3261] for User Agent Client (UAC) request generation outside of a dialog.
当订户希望订阅资源的特定状态时，它会形成一个订阅请求。如果初始订阅请求表示对话框外部的请求（通常会这样），则其构造遵循[RFC3261]中概述的在对话框外部生成用户代理客户端（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 request will be sent immediately.
此订阅请求将得到最终响应的确认。200个类响应表示订阅已被接受，并且将立即发送通知请求。
The "Expires" header field in a 200-class response to SUBSCRIBE request indicates the actual duration for which the subscription will remain active (unless refreshed). The received value might be smaller than the value indicated in the SUBSCRIBE request but cannot be larger; see Section 4.2.1 for details.
订阅请求200类响应中的“Expires”标头字段指示订阅将保持活动状态的实际持续时间（除非刷新）。接收的值可能小于订阅请求中指示的值，但不能大于；详见第4.2.1节。
Non-200-class final responses indicate that no subscription or new dialog usage has been created, and no subsequent NOTIFY request will be sent. All non-200-class responses (with the exception of 489 (Bad Event), described herein) have the same meanings and handling as described in [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains an "Accept" header field, but that field does not indicate a media type that the notifier is capable of generating in its NOTIFY requests, then the proper error response is 406 (Not Acceptable).
非200类最终响应表示尚未创建订阅或新对话框使用，并且不会发送后续通知请求。所有非200类响应（此处所述的489（坏事件）除外）具有与[RFC3261]中所述相同的含义和处理。为清楚起见：如果订阅请求包含“接受”标头字段，但该字段不表示通知程序能够在其通知请求中生成的媒体类型，则正确的错误响应为406（不可接受）。
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. The handling for such a request is the same as for the initial creation of a subscription except as described below.
在订阅到期之前的任何时间，订户可以通过在与现有订阅相同的对话框上发送另一个订阅请求来刷新此类订阅的计时器。除下文所述外，此类请求的处理与初始创建订阅的处理相同。
If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST consider the subscription terminated. (See [RFC5057] for further details and notes about the effect of error codes on dialogs and usages within dialog, such as subscriptions). 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 4.1.2.1).
如果刷新订阅的订阅请求接收到404, 405, 410、416、480-48、489, 501或604响应，则订阅者必须考虑终止订阅。（有关错误代码对对话框和对话框内的用法（如订阅）的影响的更多详细信息和注释，请参见[RFC5057]）。如果订户希望重新订阅该状态，他可以通过使用新生成的呼叫ID和新的、唯一的“From”标记（见第4.1.2.1节）编写一个不相关的初始订阅请求来重新订阅该状态。
If a SUBSCRIBE request to refresh a subscription fails with any error code other than those listed above, the original subscription is still considered valid for the duration of the most recently known "Expires" value as negotiated by the most recent successful SUBSCRIBE transaction, or as communicated by a NOTIFY request in its "Subscription-State" header field "expires" parameter.
如果刷新订阅的订阅请求失败，且出现除上述错误代码以外的任何错误代码，则原始订阅在最近成功的订阅事务协商的最新已知“到期”值的持续时间内，或在其“订阅状态”标题字段“过期”参数。
Note that many such errors indicate that there may be a problem with the network or the notifier such that no further NOTIFY requests will be received.
请注意，许多此类错误表明网络或通知程序可能存在问题，因此不会收到进一步的通知请求。
When refreshing a subscription, a subscriber starts Timer N, set to 64*T1, when it sends the SUBSCRIBE request. If this Timer N expires prior to the receipt of a NOTIFY request, the subscriber considers the subscription terminated. If the subscriber receives a success response to the SUBSCRIBE request that indicates that no NOTIFY request will be generated -- such as the 204 response defined for use with the optional extension described in [RFC5839] -- then it MUST cancel Timer N.
刷新订阅时，订阅服务器在发送订阅请求时启动计时器N，设置为64*T1。如果此计时器N在收到通知请求之前过期，则订户认为订阅已终止。如果订阅者接收到一个对订阅请求的成功响应，该响应指示不会生成通知请求——例如为与[RFC5839]中描述的可选扩展一起使用而定义的204响应——那么它必须取消计时器N。
Unsubscribing is handled in the same way as refreshing of a subscription, with the "Expires" header field set to "0". Note that a successful unsubscription will also trigger a final NOTIFY request.
取消订阅的处理方式与刷新订阅相同，“Expires”标题字段设置为“0”。请注意，成功取消订阅也将触发最终通知请求。
The final NOTIFY request may or may not contain information about the state of the resource; subscribers need to be prepared to receive final NOTIFY requests both with and without state.
最终通知请求可能包含也可能不包含有关资源状态的信息；订阅者需要准备好接收带有和不带状态的最终通知请求。
The subscriber can expect to receive a NOTIFY request from each node which has processed a successful subscription or subscription refresh. To ensure that subscribers do not wait indefinitely for a subscription to be established, a subscriber starts a Timer N, set to 64*T1, when it sends a SUBSCRIBE request. If this Timer N expires prior to the receipt of a NOTIFY request, the subscriber considers the subscription failed, and cleans up any state associated with the subscription attempt.
订户可以期望从已成功处理订阅或订阅刷新的每个节点接收通知请求。为了确保订阅者不会无限期地等待建立订阅，订阅者在发送订阅请求时启动设置为64*T1的计时器N。如果此计时器N在收到通知请求之前过期，订阅者将认为订阅失败，并清除与订阅尝试相关的任何状态。
Until Timer N expires, several NOTIFY requests may arrive from different destinations (see Section 4.4.1). Each of these requests establishes a new dialog usage and a new subscription. After the expiration of Timer N, the subscriber SHOULD reject any such NOTIFY requests that would otherwise establish a new dialog usage with a 481 (Subscription does not exist) response code.
在计时器N过期之前，可能会有多个通知请求从不同的目的地到达（见第4.4.1节）。每个请求都会建立一个新的对话框用法和一个新的订阅。计时器N过期后，订阅者应拒绝任何此类NOTIFY请求，否则将使用481（订阅不存在）响应代码建立新的对话用法。
Until the first NOTIFY request arrives, the subscriber should consider the state of the subscribed resource to be in a neutral state. Event package specifications MUST define this "neutral state" in such a way that makes sense for their application (see Section 5.4.7).
在第一通知请求到达之前，订阅者应该考虑订阅资源的状态处于中立状态。事件包规范必须以对其应用有意义的方式定义此“中性状态”（见第5.4.7节）。
Due to the potential for out-of-order messages, packet loss, and forking, the subscriber MUST be prepared to receive NOTIFY requests before the SUBSCRIBE transaction has completed.
由于可能出现无序消息、数据包丢失和分叉，订阅者必须在订阅事务完成之前准备好接收通知请求。
Except as noted above, processing of this NOTIFY request is the same as in Section 4.1.3.
除上述情况外，本通知请求的处理与第4.1.3节相同。
Subscribers receive information about the state of a resource to which they have subscribed in the form of NOTIFY requests.
订阅者以NOTIFY请求的形式接收有关其已订阅的资源状态的信息。
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 usage are described in Section 4.4.1. Notifications for subscriptions that were created inside an existing dialog match if they are in the same dialog and the "Event" header fields match (as described in Section 8.2.1).
收到通知请求后，订阅者应检查其是否与至少一个未完成订阅匹配；如果不是，它必须返回481（订阅不存在）响应，除非另一个400或500类响应更合适。第4.4.1节介绍了将通知请求与创建新对话框用法的订阅相匹配的规则。如果在现有对话框中创建的订阅的通知位于同一对话框中且“事件”标题字段匹配（如第8.2.1节所述），则通知将匹配。
If, for some reason, the event package designated in the "Event" header field of the NOTIFY request is not supported, the subscriber will respond with a 489 (Bad Event) response.
如果由于某种原因，NOTIFY请求的“event”（事件）标头字段中指定的事件包不受支持，订阅者将以489（坏事件）响应进行响应。
To prevent spoofing of events, NOTIFY requests SHOULD be authenticated using any defined SIP authentication mechanism, such as those described in Sections 22.2 and 23 of [RFC3261].
为防止事件欺骗，应使用任何定义的SIP身份验证机制（如[RFC3261]第22.2节和第23节所述）对NOTIFY请求进行身份验证。
NOTIFY requests MUST contain "Subscription-State" header fields that indicate the status of the subscription.
通知请求必须包含指示订阅状态的“订阅状态”标头字段。
If the "Subscription-State" header field value is "active", it means that the subscription has been accepted and (in general) has been authorized. If the header field 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 field 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 MUST consider the subscription terminated. The "expires" parameter has no semantics for "terminated" -- notifiers SHOULD NOT include an "expires" parameter on a "Subscription-State" header field with a value of "terminated", and subscribers MUST ignore any such parameter, if present. 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-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 reason codes defined by this document are:
如果“订阅状态”值“终止”，则订阅服务器必须考虑订阅终止。“expires”参数没有“terminated”的语义——通知程序不应在“Subscription State”标头字段中包含值为“terminated”的“expires”参数，并且订阅者必须忽略任何此类参数（如果存在）。如果存在原因代码，则客户端的行为应如下所述。如果不存在原因代码或未知原因代码，则客户端可随时尝试重新订阅（除非存在“重试后”参数，在这种情况下，客户端在“重试后”参数指定的秒数之前不应尝试重新订阅）。本文件定义的原因代码为：
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 (as long as the resource's state is still relevant to the client at that 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". This reason code is also associated with polling of resource state, as detailed in Section 4.4.3.
超时：订阅已终止，因为它在过期之前未刷新。客户可以立即重新订阅。“retry after”参数没有“timeout”的语义。该原因码还与资源状态轮询相关，详见第4.4.3节。
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 that 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”的语义。
invariant: The subscription has been terminated because the resource state is guaranteed not to change for the foreseeable future. This may be the case, for example, when subscribing to the location information of a fixed-location land-line telephone. When using this reason code, notifiers are advised to include a "retry-after" parameter with a large value (for example, 31536000 -- or one year) to prevent older clients that are RFC 3265 compliant from periodically re-subscribing. Clients SHOULD NOT attempt to re-subscribe after receiving a reason code of "invariant", regardless of the presence of or value of a "retry-after" parameter.
不变：订阅已终止，因为资源状态保证在可预见的将来不会更改。例如，当订阅固定位置陆地电话的位置信息时，可能是这种情况。使用此原因码时，建议通知程序包含一个大值的“retry after”（重试后）参数（例如，31536000——或一年），以防止符合RFC 3265的旧客户端定期重新订阅。无论“retry after”参数的存在或值如何，客户端在收到“invariant”原因码后都不应尝试重新订阅。
Other specifications may define new reason codes for use with the "Subscription-State" header field.
其他规范可能会定义用于“订阅状态”标题字段的新原因码。
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 field.
一旦订户认为该通知可接受，订户应返回200响应。一般来说，NOTIFY回复不会包含实体；但是，如果NOTIFY请求包含“Accept”头字段，则它们可以。
Other responses defined in [RFC3261] 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.
也可以根据需要返回[RFC3261]中定义的其他响应。在任何情况下，NOTIFY事务的扩展时间都不得超过自动处理所需的时间。特别是，订户在返回对NOTIFY请求的最终响应之前，不能等待用户响应。
In accordance with the rules for proxying non-INVITE requests as defined in [RFC3261], 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 that differ from the "To:" tag received in the SUBSCRIBE 200-class response.
根据[RFC3261]中定义的代理非INVITE请求的规则，成功的SUBSCRIBE请求将只收到一个200类响应；但是，由于分叉，订阅可能已被多个节点接受。因此，订户必须准备好接收带有“From:”标记的NOTIFY请求，这些标记不同于SUBSCRIBE 200类响应中接收的“to:”标记。
If multiple NOTIFY requests are received in different dialogs in response to a single SUBSCRIBE request, each dialog represents a different destination to which the SUBSCRIBE request was forked. Subscriber handling in such situations varies by event package; see Section 5.4.9 for details.
如果在不同的对话框中收到多个NOTIFY请求以响应单个订阅请求，则每个对话框表示订阅请求分叉到的不同目的地。订户在这种情况下的处理因事件包而异；详见第5.4.9节。
Notifiers learn about subscription requests by receiving SUBSCRIBE requests from interested parties. Notifiers MUST NOT create subscriptions except upon receipt of a SUBSCRIBE request. However, for historical reasons, the implicit creation of subscriptions as defined in [RFC3515] is still permitted.
通知程序通过接收相关方的订阅请求来了解订阅请求。除非收到订阅请求，否则通知程序不得创建订阅。但是，由于历史原因，仍然允许隐式创建[RFC3515]中定义的订阅。
[RFC3265] allowed the creation of subscriptions using means other than the SUBSCRIBE method. The only standardized use of this mechanism is the REFER method [RFC3515]. Implementation experience with REFER has shown that the implicit creation of a subscription has a number of undesirable effects, such as the inability to signal the success of a REFER request while signaling a problem with the subscription, and difficulty performing one action without the other. Additionally, the proper exchange of dialog identifiers is difficult without dialog reuse (which has its own set of problems; see Section 4.5).
[RFC3265]允许使用SUBSCRIBE方法以外的方法创建订阅。该机制的唯一标准化使用是REFER方法[RFC3515]。REFER的实现经验表明，订阅的隐式创建具有许多不良影响，例如，在发送订阅问题的信号时，无法发送REFER请求成功的信号，以及难以执行一个操作而不执行另一个操作。此外，如果没有对话框重用，则很难正确交换对话框标识符（这有其自身的一系列问题；请参见第4.5节）。
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 [RFC3261]) from firing during the SUBSCRIBE transaction, since interaction with a user would often exceed 64*T1 seconds.
此要求主要用于防止在订阅事务期间触发非邀请事务超时计时器F（请参见[RFC3261]），因为与用户的交互通常会超过64*T1秒。
The notifier SHOULD check that the event package specified in the "Event" header field 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 4.2.1.3.
通知程序还应根据其本地策略执行任何必要的身份验证和授权。见第4.2.1.3节。
The notifier MAY also check that the duration in the "Expires" header field 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 Brief) error that contains a "Min-Expires" header field. The "Min-Expires" header field is described in [RFC3261].
通知程序还可以检查“Expires”标题字段中的持续时间是否过小。如果且仅当过期间隔大于零且小于一小时且小于通知程序配置的最小值时，通知程序可能返回包含“Min Expires”标题字段的423（间隔太短）错误。[RFC3261]中描述了“Min Expires”标题字段。
Once the notifier determines that it has enough information to create the subscription (i.e., it understands the event package, the subscription pertains to a known resource, and there are no other barriers to creating the subscription), it creates the subscription and a dialog usage, and returns a 200 (OK) response.
一旦通知程序确定它有足够的信息来创建订阅（即，它了解事件包，订阅属于已知资源，并且创建订阅没有其他障碍），它将创建订阅和对话框用法，并返回200（确定）响应。
When a subscription is created in the notifier, it stores the event package name as part of the subscription information.
在通知程序中创建订阅时，它将事件包名称存储为订阅信息的一部分。
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 request 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 [RFC3261] may be used in response to SUBSCRIBE requests, as appropriate.
[RFC3261]中定义的其他响应代码可用于响应订阅请求（视情况而定）。
Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY request immediately to communicate the current resource state to the subscriber. This NOTIFY request 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 request is processed, this NOTIFY request MAY contain an empty or neutral body. See Section 4.2.2 for further details on NOTIFY request generation.
成功接受或刷新订阅后，通知程序必须立即发送通知请求，以将当前资源状态告知订阅服务器。此通知请求在订阅响应创建的同一对话框中发送。如果资源在处理订阅请求时没有有意义的状态，则此NOTIFY请求可能包含空的或中性的正文。有关通知请求生成的更多详细信息，请参见第4.2.2节。
Note that a NOTIFY request is always sent immediately after any 200-class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized.
请注意，无论订阅是否已被授权，通知请求总是在订阅请求的任何200类响应之后立即发送。
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 [RFC3261]. Note that, even if the notifier node typically acts as a proxy, authentication for SUBSCRIBE requests will always be performed via a 401 (Unauthorized) response, not a 407 (Proxy Authentication Required). Notifiers always act as user agents when accepting subscriptions and sending notifications.
[RFC3261]中讨论了SIP认证机制。注意，即使通知程序节点通常充当代理，订阅请求的身份验证也将始终通过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 user agents and, as such, perform user agent authentication.
当然，当充当代理时，节点将执行正常的代理身份验证（使用407）。前面的解释提醒我们，通知程序始终是用户代理，因此，执行用户代理身份验证。
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 6.2.
如果基于访问列表或某些其他自动机制的授权失败（即，可以自动权威地确定订阅者未被授权订阅），通知者应使用403（禁止）或603（拒绝）响应回复请求，除非这样做可能会泄露应保密的信息；见第6.2节。
If the notifier owner is interactively queried to determine whether a subscription is allowed, a 200 (OK) response is returned immediately. Note that a NOTIFY request is still formed and sent under these circumstances, as described in the previous section.
如果以交互方式查询通知程序所有者以确定是否允许订阅，则会立即返回200（确定）响应。请注意，如前一节所述，在这些情况下仍会形成并发送通知请求。
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 request containing a "Subscription-State" header field 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 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
当通知程序接收到订阅刷新时，假设订阅服务器仍被授权，通知程序将更新订阅的过期时间。与初始订阅一样，服务器可以缩短到期前的时间，但不能增加时间。最后的过期时间放在“Expires”标题中
field in the response. If the duration specified in a SUBSCRIBE request is unacceptably short, the notifier SHOULD respond with a 423 (Interval Too Brief) response.
响应中的字段。如果订阅请求中指定的持续时间短得令人无法接受，则通知程序应以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 request with a "Subscription-State" value of "terminated" to inform it that the subscription is being removed. If such a request is sent, the "Subscription-State" header field SHOULD contain a "reason=timeout" parameter.
如果在通知地址过期之前未收到任何刷新，则订阅将被删除。删除订阅时，通知程序应发送“订阅状态”值为“已终止”的NOTIFY请求，以通知其正在删除订阅。如果发送了此类请求，“订阅状态”标题字段应包含“原因=超时”参数。
Clients can cause a subscription to be terminated immediately by sending a SUBSCRIBE request with an "Expires" header field set to '0'. Notifiers largely treat this the same way as any other subscription expiration: they send a NOTIFY request containing a "Subscription-State" of "terminated", with a reason code of "timeout." For consistency with state polling (see Section 4.4.3) and subscription refreshes, the notifier may choose to include resource state in this final NOTIFY request. However, in some cases, including such state makes no sense. Under such circumstances, the notifier may choose to omit state information from the terminal NOTIFY request.
客户端可以通过发送“Expires”头字段设置为“0”的订阅请求来立即终止订阅。通知程序在很大程度上与处理任何其他订阅过期的方式相同：它们发送一个包含“已终止”的“订阅状态”的通知请求，其原因代码为“超时”。为了与状态轮询（见第4.4.3节）和订阅刷新保持一致，通知程序可以选择在此最终通知请求中包含资源状态。然而，在某些情况下，包括这样的国家是没有意义的。在这种情况下，通知者可以选择从终端通知请求中省略状态信息。
The sending of a NOTIFY request when a subscription expires allows the corresponding dialog usage to be terminated, if appropriate.
订阅到期时发送NOTIFY请求允许终止相应的对话框使用（如果适用）。
Notifiers use the NOTIFY method to send information about the state of a resource to subscribers. The notifier's view of a subscription is shown in the following state diagram. Events that result in a transition back to the same state are not represented in this diagram.
通知程序使用NOTIFY方法向订阅服务器发送有关资源状态的信息。通知程序的订阅视图显示在以下状态图中。导致转换回相同状态的事件不在此图中表示。
+-------------+
| init |
+-------------+
|
Receive SUBSCRIBE,
Send NOTIFY
|
V NOTIFY failure,
+-------------+ subscription expires,
+------------| resp_wait |-- or terminated ----+
| +-------------+ per local policy |
| | |
| | |
| | V
Policy grants Policy needed +-------------+
permission | | terminated |
| | +-------------+
| | A A
| V NOTIFY failure, | |
| +-------------+ subscription expires,| |
| | pending |-- or terminated -------+ |
| +-------------+ per local policy |
| | |
| Policy changed to |
| grant permission |
| | |
| V NOTIFY failure, |
| +-------------+ subscription expires, |
+----------->| active |-- or terminated ---------+
+-------------+ per local policy
+-------------+
| init |
+-------------+
|
Receive SUBSCRIBE,
Send NOTIFY
|
V NOTIFY failure,
+-------------+ subscription expires,
+------------| resp_wait |-- or terminated ----+
| +-------------+ per local policy |
| | |
| | |
| | V
Policy grants Policy needed +-------------+
permission | | terminated |
| | +-------------+
| | A A
| V NOTIFY failure, | |
| +-------------+ subscription expires,| |
| | pending |-- or terminated -------+ |
| +-------------+ per local policy |
| | |
| Policy changed to |
| grant permission |
| | |
| V NOTIFY failure, |
| +-------------+ subscription expires, |
+----------->| active |-- or terminated ---------+
+-------------+ per local policy
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, unless the state transition is caused by a NOTIFY transaction failure. The sending of this NOTIFY message is also subject to authorization, local policy, and throttling considerations.
当订阅请求得到200类响应的响应时，通知程序必须立即构造并向订阅服务器发送通知请求。当订阅状态发生更改时，通知程序应立即构造并发送NOTIFY请求，除非状态转换是由NOTIFY事务失败引起的。发送此NOTIFY消息还需要考虑授权、本地策略和限制因素。
If the NOTIFY request fails due to expiration of SIP Timer F (transaction timeout), the notifier SHOULD remove the subscription.
如果NOTIFY请求由于SIP计时器F（事务超时）过期而失败，则通知程序应删除订阅。
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 [RFC3261] (instead of the typical single transmission for functioning clients), continuing to service them when no client is available
此行为可防止对已崩溃或从网络中消失的订阅者进行不必要的状态信息传输。由于此类传输将根据[RFC3261]中定义的重传算法（而不是功能客户端的典型单次传输）发送多次，因此在没有可用客户端时继续为其提供服务
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 requests to refresh potentially stale state information; such requests will reinstall subscriptions in all relevant nodes.
承认它们可能会给网络带来不必要的压力。在客户端重新启动或重新建立网络连接时，预期客户端将发送订阅请求以刷新可能过时的状态信息；此类请求将在所有相关节点中重新安装订阅。
If the NOTIFY transaction fails due to the receipt of a 404, 405, 410, 416, 480-485, 489, 501, or 604 response to the NOTIFY request, the notifier MUST remove the corresponding subscription. See [RFC5057] for further details and notes about the effect of error codes on dialogs and usages within dialog (such as subscriptions).
如果NOTIFY事务因收到对NOTIFY请求的404、405、410、416、480-485、489、501或604响应而失败，则通知程序必须删除相应的订阅。有关错误代码对对话框和对话框内的用法（如订阅）的影响的更多详细信息和注释，请参见[RFC5057]。
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 sending of SUBSCRIBE requests to refresh the expiration timer will reinstall subscription state once the network problem has been resolved.
notify错误响应通常表示订阅服务器或某个代理服务器在发送到订阅服务器的过程中出现问题。如果订户出错，在错误情况得到处理后，允许订户纠正情况（通过重新订阅）是最有意义的。如果代理出错，则在网络问题解决后，定期发送订阅请求以刷新过期计时器将重新安装订阅状态。
NOTIFY requests MUST contain a "Subscription-State" header field 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 6.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.
通知请求必须包含“订阅状态”标题字段，其值为“活动”、“挂起”或“终止”。“活动”值表示订阅已被接受并已被授权（在大多数情况下，请参见第6.2节）。“pending”值表示已收到订阅，但此时策略信息不足以接受或拒绝订阅。“terminated”值表示订阅未激活。
If the value of the "Subscription-State" header field is "active" or "pending", the notifier MUST also include in the "Subscription-State" header field an "expires" parameter that 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.
如果“订阅状态”标题字段的值为“活动”或“挂起”，则通知程序还必须在“订阅状态”标题字段中包含一个“过期”参数，该参数指示订阅的剩余时间。通知程序可以使用此机制缩短订阅；但是，此机制不得用于延长订阅。
Including expiration information for active and pending subscriptions is necessary in case the SUBSCRIBE request forks, since the response to a forked SUBSCRIBE request may not be received by the subscriber. [RFC3265] allowed the notifier some discretion in the inclusion of this parameter, so subscriber implementations are warned to handle the lack of an "expires" parameter gracefully. Note well that this "expires" value is a parameter on the "Subscription-State" header field NOT the "Expires" header field.
在订阅请求分叉的情况下，包括活动订阅和挂起订阅的到期信息是必要的，因为订阅方可能不会收到对分叉订阅请求的响应。[RFC3265]允许通知程序在包含此参数时有一定的自由裁量权，因此会警告订户实现优雅地处理缺少“expires”参数的问题。请注意，这个“expires”值是“Subscription State”头字段上的一个参数，而不是“expires”头字段。
The period of time for a subscription can be shortened to zero by the notifier. In other words, it is perfectly valid for a SUBSCRIBE request with a non-zero expires to be answered with a NOTIFY request that contains "Subscription-Status: terminated;reason=expired". This merely means that the notifier has shortened the subscription timeout to zero, and the subscription has expired instantaneously. The body may contain valid state, or it may contain a neutral state (see Section 5.4.7).
通知程序可以将订阅的时间段缩短为零。换句话说，对于过期时间非零的订阅请求，使用包含“订阅状态：已终止；原因=已过期”的NOTIFY请求进行响应是完全有效的。这仅仅意味着通知程序已将订阅超时缩短为零，并且订阅已即时过期。阀体可能包含有效状态，也可能包含中性状态（见第5.4.7节）。
If the value of the "Subscription-State" header field 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 4.1.3.
如果“订阅状态”标题字段的值为“终止”，通知程序还应包括“原因”参数。在适当的情况下，通知程序还可以包括“重试后”参数。有关“reason”和“retry after”参数的值和语义的详细信息，请参见第4.1.3节。
The "Event" header field is considered mandatory for the purposes of this document. However, to maintain compatibility with PINT (see [RFC2848]), notifiers MAY interpret a SUBSCRIBE request with no "Event" header field as requesting a subscription to PINT events. If a notifier does not support PINT, it SHOULD return 489 (Bad Event) to any SUBSCRIBE requests without an "Event" header field.
在本文档中，“事件”标题字段被视为必填字段。但是，为了保持与PINT的兼容性（请参见[RFC2848]），通知程序可能会将没有“事件”头字段的订阅请求解释为请求对PINT事件的订阅。如果通知程序不支持PINT，它应该向任何订阅请求返回489（坏事件），而不包含“事件”头字段。
Proxies need no additional behavior beyond that described in [RFC3261] to support SUBSCRIBE and NOTIFY transactions. If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST add a "Record-Route" header field to the initial SUBSCRIBE request and all NOTIFY requests. It MAY choose to include "Record-Route" in subsequent SUBSCRIBE requests; however, these requests cannot cause the dialog's route set to be modified.
除了[RFC3261]中描述的行为之外，代理不需要其他行为来支持订阅和通知事务。如果代理希望查看给定对话框的所有订阅和通知请求，则必须向初始订阅请求和所有通知请求添加“记录路由”头字段。它可以选择在后续订阅请求中包括“记录路由”；但是，这些请求不能导致修改对话框的路由集。
Proxies that did not add a "Record-Route" header field to the initial SUBSCRIBE request MUST NOT add a "Record-Route" header field to any of the associated NOTIFY requests.
未向初始订阅请求添加“记录路由”标头字段的代理不得向任何相关通知请求添加“记录路由”标头字段。
Note that subscribers and notifiers may elect to use Secure/ Multipurpose Internet Mail Extensions (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 [RFC3261].
请注意，订阅者和通知者可以选择对订阅和通知请求使用安全/多用途Internet邮件扩展（S/MIME）加密；因此，代理不能依赖于能够访问[RFC3261]不明确要求代理可读的任何信息。
Dialogs usages are created upon completion of a NOTIFY transaction for a new subscription, unless the NOTIFY request contains a "Subscription-State" of "terminated."
对话框用法在新订阅的NOTIFY事务完成时创建，除非NOTIFY请求包含“已终止”的“订阅状态”
Because the dialog usage is established by the NOTIFY request, the route set at the subscriber is taken from the NOTIFY request itself, as opposed to the route set present in the 200-class response to the SUBSCRIBE request.
由于对话框的使用是由NOTIFY请求建立的，因此订阅者处设置的路由来自NOTIFY请求本身，而不是订阅请求的200类响应中存在的路由集。
NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header field "tag" parameter that matches the "From" header field "tag" parameter of the SUBSCRIBE request, and the same "Event" header field. Rules for comparisons of the "Event" header fields are described in Section 8.2.1.
如果通知请求包含相同的“调用ID”、与订阅请求的“From”header field“tag”参数匹配的“to”header field“tag”参数以及相同的“Event”header字段，则通知请求与此类订阅请求匹配。“事件”标题字段的比较规则见第8.2.1节。
A subscription is destroyed after a notifier sends a NOTIFY request with a "Subscription-State" of "terminated", or in certain error situations described elsewhere in this document. The subscriber will generally answer such final requests with a 200 (OK) response (unless a condition warranting an alternate response has arisen). Except when the mechanism described in Section 4.5.2 is used, the destruction of a subscription results in the termination of its associated dialog.
在通知程序发送“订阅状态”为“已终止”的NOTIFY请求后，或在本文档其他地方描述的某些错误情况下，订阅将被销毁。订阅者通常会以200（OK）响应来回答此类最终请求（除非出现了保证替代响应的条件）。除非使用第4.5.2节中描述的机制，否则订阅的销毁将导致其相关对话框的终止。
A subscriber may send a SUBSCRIBE request with an "Expires" header field 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 transaction with a "Subscription-State" of "terminated" completes.
订阅者可以发送“Expires”头字段为0的订阅请求，以触发此类通知请求的发送；但是，出于订阅和对话框生存期的目的，在“订阅状态”为“已终止”的NOTIFY事务完成之前，订阅不会被视为已终止。
It is often useful to allow migration of subscriptions between notifiers. Such migration may be effected by sending a NOTIFY request with a "Subscription-State" header field of "terminated" and a reason parameter of "deactivated". This NOTIFY request is otherwise normal and is formed as described in Section 4.2.2.
允许在通知程序之间迁移订阅通常很有用。这种迁移可以通过发送带有“Subscription State”头字段“terminated”和原因参数“deactivated”的NOTIFY请求来实现。该通知请求在其他方面是正常的，其格式如第4.2.2节所述。
Upon receipt of this NOTIFY request, 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 reuse 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 request 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 requests triggered by SUBSCRIBE requests with "Expires" header fields of 0 will contain a "Subscription-State" value of "terminated" and a "reason" parameter of "timeout".
请注意，“Expires”头字段为0的订阅请求触发的NOTIFY请求将包含“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.
使用轮询时，订阅者应尝试在轮询之间缓存身份验证凭据，以减少发送的消息数。
Due to the requirement on notifiers to send a NOTIFY request immediately upon receipt of a SUBSCRIBE request, the state provided by polling is limited to the information that the notifier has immediate local access to when it receives the SUBSCRIBE request. If, for example, the notifier generally needs to retrieve state from another network server, then that state will be absent from the NOTIFY request that results from polling.
由于要求通知程序在收到订阅请求后立即发送通知请求，因此轮询提供的状态仅限于通知程序在收到订阅请求时可立即在本地访问的信息。例如，如果通知程序通常需要从另一个网络服务器检索状态，则轮询产生的NOTIFY请求中将不存在该状态。
The "Allow-Events" header field, if present, MUST include a comprehensive and inclusive list of tokens that indicates the event packages for which the user agent can act as a notifier. In other words, a user agent sending an "Allow-Events" header field is advertising that it can process SUBSCRIBE requests and generate NOTIFY requests for all of the event packages listed in that header field.
“允许事件”标题字段（如果存在）必须包括一个全面且包含的令牌列表，该列表指示用户代理可以作为通知程序的事件包。换句话说，发送“Allow Events”头字段的用户代理正在宣传它可以处理订阅请求并为该头字段中列出的所有事件包生成NOTIFY请求。
Any user agent that can act as a notifier for one or more event packages SHOULD include an appropriate "Allow-Events" header field 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.
该信息非常有用，例如，允许用户代理根据实现它们所表示的功能所需的事件是否得到相应节点的支持，适当地呈现特定的接口元素。
On the other hand, it doesn't necessarily make much sense to indicate supported events inside a dialog established by a NOTIFY request if the only event package supported is the one associated with that subscription.
另一方面，如果唯一受支持的事件包是与该订阅关联的事件包，那么在由NOTIFY请求建立的对话框中指示受支持的事件不一定有多大意义。
Note that "Allow-Events" header fields MUST NOT be inserted by proxies.
请注意，“允许事件”标题字段不能由代理插入。
The "Allow-Events" header field does not include a list of the event template-packages supported by an implementation. If a subscriber wishes to determine which event template-packages are supported by a notifier, it can probe for such support by attempting to subscribe to the event template-packages it wishes to use.
“允许事件”标题字段不包括实现支持的事件模板包的列表。如果订阅者希望确定通知程序支持哪些事件模板包，则可以通过尝试订阅其希望使用的事件模板包来探测此类支持。
For example: to check for support for the templatized package "presence.winfo", a client may attempt to subscribe to that event package for a known resource, using an "Expires" header value of 0. If the response is a 489 error code, then the client can deduce that "presence.winfo" is unsupported.
例如：要检查对模板化包“presence.winfo”的支持，客户端可以尝试使用“Expires”头值0为已知资源订阅该事件包。如果响应是489错误代码，则客户端可以推断“presence.winfo”不受支持。
[RFC3265] defined a mechanism by which subscriptions could share dialogs with invite usages and with other subscriptions. The purpose of this behavior was to allow subscribers to ensure that a subscription arrived at the same device as an established dialog. Unfortunately, the reuse of dialogs has proven to be exceedingly confusing. [RFC5057] attempted to clarify proper behavior in a
[RFC3265]定义了一种机制，通过该机制，订阅可以与invite用法和其他订阅共享对话框。此行为的目的是允许订阅者确保订阅到达与已建立对话框相同的设备。不幸的是，对话框的重用被证明是非常令人困惑的。[RFC5057]试图澄清
variety of circumstances; however, the ensuing rules remain confusing and prone to implementation error. At the same time, the mechanism described in [RFC5627] now provides a far more elegant and unambiguous means to achieve the same goal.
各种情况；然而，随后的规则仍然令人困惑，并且容易出现实现错误。同时，[RFC5627]中描述的机制现在提供了一种更优雅、更明确的方法来实现相同的目标。
Consequently, the dialog reuse technique described in RFC 3265 is now deprecated.
因此，RFC3265中描述的对话框重用技术现在已被弃用。
This dialog-sharing technique has also historically been used as a means for targeting an event package at a dialog. This usage can be seen, for example, in certain applications of the REFER method [RFC3515]. With the removal of dialog reuse, an alternate (and more explicit) means of targeting dialogs needs to be used for this type of correlation. The appropriate means of such targeting is left up to the actual event packages. Candidates include the "Target-Dialog" header field [RFC4538], the "Join" header field [RFC3911], and the "Replaces" header field [RFC3891], depending on the semantics desired. Alternately, if the semantics of those header fields do not match the event package's purpose for correlation, event packages can devise their own means of identifying dialogs. For an example of this approach, see the Dialog Event Package [RFC4235].
这种对话共享技术在历史上也被用作在对话中定位事件包的方法。例如，在REFER方法[RFC3515]的某些应用中可以看到这种用法。随着对话框重用的取消，这种类型的关联需要使用另一种（更明确的）针对对话框的方法。此类目标的适当方式由实际事件包决定。候选项包括“目标对话框”标题字段[RFC4538]、“加入”标题字段[RFC3911]和“替换”标题字段[RFC3891]，具体取决于所需的语义。或者，如果这些标题字段的语义与事件包的关联目的不匹配，则事件包可以设计自己的方法来标识对话框。有关此方法的示例，请参阅对话框事件包[RFC4235]。
Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target. This allows subscribers to explicitly target desired devices.
通知程序必须实现[RFC5627]中定义的全局可路由用户代理URI（GRUU）扩展，并且必须使用GRUU作为其本地目标。这允许订阅者明确地以所需的设备为目标。
If a subscriber wishes to subscribe to a resource on the same device as an established dialog, it should check whether the remote contact in that dialog is a GRUU (i.e., whether it contains a "gr" URI parameter). If so, the subscriber creates a new dialog, using the GRUU as the Request URI for the new SUBSCRIBE request.
如果订阅者希望订阅与已建立对话相同的设备上的资源，则应检查该对话中的远程联系人是否为GRUU（即，是否包含“gr”URI参数）。如果是这样，订阅服务器将创建一个新对话框，使用GRUU作为新订阅请求的请求URI。
Because GRUUs are guaranteed to route to a specific device, this ensures that the subscription will be routed to the same place as the established dialog.
因为保证GROU路由到特定的设备，这确保订阅将路由到与已建立的对话框相同的位置。
For compatibility with older clients, subscriber and notifier implementations may choose to allow dialog sharing. The behavior of multiple usages within a dialog are described in [RFC5057].
为了与旧客户端兼容，订户和通知程序实现可以选择允许对话框共享。[RFC5057]中描述了对话框中多种用法的行为。
Subscribers MUST NOT attempt to reuse dialogs whose remote target is a GRUU.
订阅者不得尝试重用远程目标为GRUU的对话框。
Note that the techniques described in this section are included for backwards-compatibility purposes only. Because subscribers cannot reuse dialogs with a GRUU for their remote target, and because notifiers must use GRUUs as their local target, any two implementations that conform to this specification will automatically use the mechanism described in Section 4.5.1.
请注意，本节中描述的技术仅用于向后兼容目的。由于订阅者不能将带有GRUU的对话框重新用于其远程目标，并且由于通知程序必须将GRUU用作其本地目标，因此符合本规范的任何两个实现都将自动使用第4.5.1节中描述的机制。
Further note that the prohibition on reusing dialogs does not exempt implicit subscriptions created by the REFER method. This means that implementations complying with this specification are required to use the "Target-Dialog" mechanism described in [RFC4538] when the remote target is a GRUU.
进一步注意，禁止重用对话框并不能免除由refere方法创建的隐式订阅。这意味着当远程目标是GRUU时，符合本规范的实现需要使用[RFC4538]中描述的“目标对话框”机制。
If a subscriber wishes to subscribe to a resource on the same device as an established dialog and the remote contact is not a GRUU, it MAY revert to dialog-sharing behavior. Alternately, it MAY choose to treat the remote party as incapable of servicing the subscription (i.e., the same way it would behave if the remote party did not support SIP events at all).
如果订户希望订阅与已建立对话相同的设备上的资源，并且远程联系人不是GRUU，则可能会恢复到对话共享行为。或者，它可以选择将远程方视为无法为订阅提供服务（即，如果远程方根本不支持SIP事件，它的行为方式相同）。
If a notifier receives a SUBSCRIBE request for a new subscription on an existing dialog, it MAY choose to implement dialog sharing behavior. Alternately, it may choose to fail the SUBSCRIBE request with a 403 (Forbidden) response. The error text of such 403 responses SHOULD indicate that dialog sharing is not supported.
如果通知程序在现有对话框上收到新订阅的订阅请求，则它可以选择实现对话框共享行为。或者，它可以选择使用403（禁止）响应使订阅请求失败。此类403响应的错误文本应表明不支持对话共享。
To implement dialog sharing, subscribers and notifiers perform the following additional processing:
要实现对话框共享，订阅者和通知者将执行以下附加处理：
o When subscriptions exist in dialogs associated with INVITE-created application state and/or other subscriptions, these sets of application state do not interact beyond the behavior described for a dialog (e.g., route set handling). In particular, multiple subscriptions within a dialog expire independently and require independent subscription refreshes.
o 当订阅存在于与邀请创建的应用程序状态和/或其他订阅相关联的对话框中时，这些应用程序状态集的交互不会超出为对话框描述的行为（例如，路由集处理）。特别是，对话框中的多个订阅将独立过期，并需要独立的订阅刷新。
o 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. This means that, when dialogs are reused, 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.
o 如果订阅的销毁没有留下与对话框关联的其他应用程序状态，则对话框终止。如果订阅仍与该对话框关联，则销毁其他应用程序状态（如由INVITE创建的状态）不会终止该对话框。这意味着，当对话框被重用时，使用INVITE创建的对话框不一定在收到BYE时终止。类似地，如果多个订阅与单个对话框相关联，则该对话框在销毁其中的所有订阅之前不会终止。
o Subscribers MAY include an "id" parameter in a SUBSCRIBE request's "Event" header field to allow differentiation between multiple subscriptions in the same dialog. This "id" parameter, if present, contains an opaque token that identifies the specific subscription within a dialog. An "id" parameter is only valid within the scope of a single dialog.
o 订阅者可以在订阅请求的“事件”头字段中包含“id”参数，以允许在同一对话框中区分多个订阅。此“id”参数（如果存在）包含一个不透明令牌，用于标识对话框中的特定订阅。“id”参数仅在单个对话框的范围内有效。
o If an "id" parameter is present in the SUBSCRIBE request used to establish a subscription, that "id" parameter MUST also be present in all corresponding NOTIFY requests.
o 如果用于建立订阅的订阅请求中存在“id”参数，则该“id”参数也必须存在于所有相应的NOTIFY请求中。
o When a subscriber refreshes the subscription timer, the SUBSCRIBE request MUST contain the same "Event" header field "id" parameter as was present in the SUBSCRIBE request that created the subscription. (Otherwise, the notifier will interpret the SUBSCRIBE request as a request for a new subscription in the same dialog.)
o 当订阅者刷新订阅计时器时，订阅请求必须包含与创建订阅的订阅请求中相同的“事件”头字段“id”参数。（否则，通知程序将在同一对话框中将订阅请求解释为新订阅请求。）
o When a subscription is created in the notifier, it stores any "Event" header field "id" parameter as part of the subscription information (along with the event package name).
o 在通知程序中创建订阅时，它会将任何“事件”标题字段“id”参数存储为订阅信息的一部分（以及事件包名称）。
o If an initial SUBSCRIBE request is sent on a pre-existing dialog, a matching NOTIFY request merely creates a new subscription associated with that dialog.
o 如果在预先存在的对话框上发送初始订阅请求，则匹配的通知请求仅创建与该对话框关联的新订阅。
Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a User Agent Server (UAS) receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY transaction, it MUST respond to the CANCEL request, but otherwise ignore it. In particular, the CANCEL request MUST NOT affect processing of the SUBSCRIBE or NOTIFY request in any way.
无法取消订阅或通知请求。如果用户代理服务器（UAS）接收到与已知订阅或通知事务匹配的取消请求，它必须响应取消请求，否则将忽略该请求。特别是，取消请求不得以任何方式影响订阅或通知请求的处理。
UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY transactions.
UAC不应发送取消订阅请求或通知交易。
This section covers several issues that should be taken into consideration when event packages based on the SUBSCRIBE and NOTIFY methods 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
当使用本文档中描述的用于事件通知的方法设计事件包时，必须考虑：是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 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.
问题集的适当机制？选择SIP是因为协议提供了一些独特的功能（例如，用户移动性），还是仅仅因为“可以做到”？如果您发现自己正在定义与网络管理或汽车发动机内部温度相关的通知的事件包，您可能需要重新考虑协议的选择。
Those interested in extending the mechanism defined in this document are urged to follow the development of "Guidelines for Authors of SIP Extensions" [RFC4485] for further guidance regarding appropriate uses of SIP.
对于扩展本文件中定义的机制感兴趣的人，请遵循“SIP扩展作者指南”[RFC4485]的制定，以获得有关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 signaling 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 that 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 that 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 the "Event" header field would be "presence.winfo".
应用于包的事件模板包的名称是通过在包的末尾附加句点，后跟事件模板包名称形成的。例如，如果一个名为“winfo”的模板包被应用于名为“presence”的包，“event”头字段中使用的事件标记将是“presence.winfo”。
This scheme may be arbitrarily extended. For example, application of the "winfo" package to the "presence.winfo" state of a resource would be represented by the name "presence.winfo.winfo". It naturally follows from this syntax that the order in which templates are specified is significant.
这个计划可以任意扩展。例如，将“winfo”包应用于资源的“presence.winfo”状态将由名称“presence.winfo.winfo”表示。根据这种语法，指定模板的顺序很重要。
For example: consider a theoretical event template-package called "list". The event "presence.winfo.list" would be the application of the "list" template to "presence.winfo", which would presumably be a list of winfo state associated with presence. On the other hand, the event "presence.list.winfo" would represent the application of winfo to "presence.list", which would be represent the winfo state of a list of presence information.
例如：考虑一个名为“Listar”的理论事件模板包。事件“presence.winfo.list”将是“list”模板对“presence.winfo”的应用程序，它可能是与presence关联的winfo状态列表。另一方面，事件“presence.list.winfo”将代表winfo对“presence.list”的应用程序，后者将代表状态信息列表的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 that 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条语音消息”）。这使订阅实体的实现复杂化（因为它们必须维护其订阅的实体的完整状态），并且特别容易出现同步问题。
This problem has two possible solutions that event packages may choose to implement.
这个问题有两种可能的解决方案，事件包可以选择实现。
In general, event packages need to be able to convey a well-defined and complete state, rather than just a stream of events. If it is not possible to describe complete system state for transmission in NOTIFY requests, then the problem set is not a good candidate for an event package.
通常，事件包需要能够传递定义良好的完整状态，而不仅仅是事件流。如果无法在NOTIFY请求中描述传输的完整系统状态，则问题集不是事件包的理想候选。
For packages that 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 whenever 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 requests contain state deltas instead of complete state.
在要传送的状态信息很大的情况下，事件包可以选择详述一个方案，通过该方案，通知请求包含状态增量而不是完整状态。
Such a scheme would work as follows: any NOTIFY request sent in immediate response to a SUBSCRIBE request contains full state information. NOTIFY requests 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.
这种方案的工作原理如下：在对订阅请求的即时响应中发送的任何NOTIFY请求都包含完整的状态信息。由于状态更改而发送的NOTIFY请求将只包含已更改的状态信息；然后，订阅者将这些信息合并到其关于资源状态的当前知识中。
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 field.
任何支持状态增量更改的事件包都必须包含一个版本号，该版本号对于订阅中的每个NOTIFY事务增加一个版本号。请注意，状态版本号显示在消息正文中，而不是SIP头字段中。
If a NOTIFY request 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 request containing the state delta (except for the version number, which it retains to detect message loss), and re-sends a SUBSCRIBE request to force a NOTIFY request containing a complete state snapshot.
如果到达的NOTIFY请求的版本号增加了一个以上，则订户知道状态增量已丢失；它忽略包含状态增量的NOTIFY请求（版本号除外，它保留该版本号以检测消息丢失），并重新发送SUBSCRIBE请求以强制执行包含完整状态快照的NOTIFY请求。
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" requirements 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. For clarity: well-formed event package definitions contain sections addressing each of these issues, ideally in the same order and with the same titles as these subsections.
除了标准跟踪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 that appears in the IANA registration of the token. For information on registering such types, see Section 7.
此部分必须存在，定义用于指定事件包的令牌名称。它必须包括令牌的IANA注册中显示的信息。有关注册此类类型的信息，请参见第7节。
If parameters are to be used on the "Event" header field to modify the behavior of the event package, the syntax and semantics of such header fields MUST be clearly defined.
如果要在“事件”标题字段上使用参数来修改事件包的行为，则必须明确定义此类标题字段的语法和语义。
Any "Event" header field parameters defined by an event package MUST be registered in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. An "Event" header field parameter, once registered in conjunction with an event package, MUST NOT be reused with any other event package. Non-event-package specifications MAY define "Event" header field parameters that apply across all event packages (with emphasis on "all", as opposed to "several"), such as the "id" parameter defined in this document. The restriction of a parameter to use with a single event package only applies to parameters that are defined in conjunction with an event package.
事件包定义的任何“事件”标题字段参数必须在[RFC3968]定义的“标题字段参数和参数值”注册表中注册。“事件”标题字段参数一旦与事件包一起注册，就不能与任何其他事件包一起重用。非事件包规范可定义适用于所有事件包的“事件”标题字段参数（强调“全部”，而不是“几个”），如本文件中定义的“id”参数。与单个事件包一起使用的参数限制仅适用于与事件包一起定义的参数。
It is expected that most, but not all, event packages will define syntax and semantics for SUBSCRIBE request 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 reuse existing media types for message bodies where practical. See [RFC4288] for information on media type specification and registration.
预计大多数（但不是全部）事件包将定义订阅请求体的语法和语义；这些机构通常会修改、扩展、过滤、调节和/或设置所请求事件类别的阈值。强烈鼓励事件包的设计者在可行的情况下重用消息体的现有媒体类型。有关介质类型规范和注册的信息，请参阅[RFC4288]。
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 request 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 bodies.
NOTIFY请求主体用于报告所监视资源的状态。每个包必须定义NOTIFY请求中预期的事件体类型。此类包必须指定或引用与此类事件体相关的语法和语义的详细规范。
Event packages also MUST define which media type is to be assumed if none are specified in the "Accept" header field of the SUBSCRIBE request.
如果在订阅请求的“接受”标头字段中未指定任何媒体类型，则事件包还必须定义将采用的媒体类型。
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.
本节中的信息包括如何对订阅服务器进行身份验证以及包的授权问题的详细信息。
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 request 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 what the deltas are for notifications; see Section 5.3. Such a section is required.
事件包的这一部分描述了通知程序生成和发送通知请求的过程。这包括关于哪些事件导致发送NOTIFY请求的详细信息，如何计算NOTIFY中的状态信息，如何生成中立或虚假的状态信息以隐藏用户的授权延迟和决定，以及状态信息是否完整或通知的增量是什么；见第5.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 requests that correspond to the SUBSCRIBE request (i.e., have
如果不允许这种行为，则建立消息的第一个潜在对话框将创建一个对话框。与订阅请求相对应的所有后续通知请求（即
matching "To", "From", "Call-ID", and "Event" header fields, as well as "From" header field "tag" parameter and "Event" header field "id" parameter) but that do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE request can arrive after a matching NOTIFY request has been received; such responses might not correlate to the same dialog established by the NOTIFY request. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored.
匹配“To”、“From”、“Call ID”和“Event”标题字段，以及“From”标题字段“tag”参数和“Event”标题字段“ID”参数），但与对话框不匹配的将被481响应拒绝。注意，对订阅请求的200类响应可以在接收到匹配的通知请求之后到达；此类响应可能与NOTIFY请求建立的同一对话框不相关。除了完成SUBSCRIBE事务所需的响应外，此类不匹配的200类响应将被忽略。
If installing of multiple subscriptions by way of a single forked SUBSCRIBE request is allowed, the subscriber establishes a new dialog towards each notifier by returning a 200-class response to each NOTIFY request. Each dialog is then handled as its own entity and is refreshed independently 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 that 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) that 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 that allows subscribers to further limit the rate of notification.
每个包可以进一步定义节流机制，允许订阅者进一步限制通知速率。
Many event packages inherently work by collecting information about a resource from a number of other sources -- either through the use of PUBLISH [RFC3903], by subscribing to state information, or through other state-gathering mechanisms.
许多事件包本质上是通过从许多其他源收集关于资源的信息来工作的——或者通过使用PUBLISH[RFC3903]，或者通过订阅状态信息，或者通过其他状态收集机制。
Event packages that involve retrieval of state information for a single resource from more than one source need to consider how notifiers aggregate information into a single, coherent state. Such packages MUST specify how notifiers aggregate information and how they provide authentication and authorization.
涉及从一个以上的源检索单个资源的状态信息的事件包需要考虑通知器如何将信息聚合成单一的、一致的状态。这些包必须指定通知程序如何聚合信息以及它们如何提供身份验证和授权。
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 that 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检索实际状态信息。
[RFC4483] defines a mechanism that can be used by event packages to convey information in such a fashion.
[RFC4483]定义了一种机制，事件包可以使用该机制以这种方式传递信息。
The ability to accept subscriptions should be under the direct control of the notifier's user, since many types of events may be considered private. 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 are outside the scope of this document.
接受订阅的能力应该由通知程序的用户直接控制，因为许多类型的事件可能被认为是私有的。类似地，通知程序应该能够使用标准SIP身份验证机制，基于订户身份（基于访问控制列表）选择性地拒绝订阅。此类访问控制列表的创建和分发方法不在本文件范围内。
The mere act of returning certain 400- and 600-class 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 200 (OK) response. While the subsequent NOTIFY request 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.
在某些情况下，仅返回订阅请求的400类和600类响应的行为可能会通过泄露敏感的策略信息而引起隐私问题。在这些情况下，通知程序应始终返回200（OK）响应。虽然后续的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 [RFC2779] for user presence information.
对于这种操作模式有意义的各个包及其相关文档，可以进一步描述如何以及为什么生成这种潜在正确的数据。例如，[RFC2779]强制要求这种操作模式用于用户状态信息。
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 [CERT1998a].
当前模型（一个订阅请求触发一个订阅响应和一个或多个通知请求）是smurf攻击中使用的放大器节点的经典设置[CERT1998a]。
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 [RFC3261].
为了减少此类攻击的机会，通知程序的实现应该需要身份验证。[RFC3261]中讨论了身份验证问题。
Replaying of either SUBSCRIBE or NOTIFY requests can have detrimental effects.
重播订阅或通知请求可能会产生有害影响。
In the case of SUBSCRIBE requests, an attacker may be able to install any arbitrary subscription that it witnessed being installed at some point in the past. Replaying of NOTIFY requests may be used to spoof old state information (although a good versioning mechanism in the body of the NOTIFY requests may help mitigate such an attack). Note that the prohibition on sending NOTIFY requests to nodes that have not subscribed to an event also aids in mitigating the effects of such an attack.
在订阅请求的情况下，攻击者可能能够安装其在过去某个时间点目睹安装的任何任意订阅。重放NOTIFY请求可用于欺骗旧的状态信息（尽管NOTIFY请求主体中良好的版本控制机制可能有助于缓解此类攻击）。请注意，禁止向尚未订阅事件的节点发送NOTIFY请求也有助于减轻此类攻击的影响。
To prevent such attacks, implementations SHOULD require authentication with anti-replay protection. Authentication issues are discussed in [RFC3261].
为防止此类攻击，实现应要求具有防重放保护的身份验证。[RFC3261]中讨论了身份验证问题。
Even with authentication, man-in-the-middle attacks using SUBSCRIBE requests 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" header fields (at a minimum) of SUBSCRIBE requests. If SUBSCRIBE
即使使用身份验证，使用订阅请求的中间人攻击也可能用于安装任意订阅、劫持现有订阅、终止未完成的订阅或修改正在订阅的资源。为防止此类攻击，实现应跨订阅请求的“联系人”、“路由”、“过期”、“事件”和“收件人”头字段（至少）提供完整性保护。如果订阅
request bodies are used to define further information about the state of the call, they SHOULD be included in the integrity protection scheme.
请求主体用于定义有关调用状态的进一步信息，它们应包含在完整性保护方案中。
Man-in-the-middle attacks may also attempt to use NOTIFY requests 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" header fields and the bodies of NOTIFY requests.
中间人攻击还可能试图使用NOTIFY请求欺骗任意状态信息和/或终止未完成的订阅。为防止此类攻击，实现应跨“调用ID”、“CSeq”和“订阅状态”头字段以及NOTIFY请求主体提供完整性保护。
Integrity protection of message header fields and bodies is discussed in [RFC3261].
[RFC3261]中讨论了消息头字段和正文的完整性保护。
The state information contained in a NOTIFY request 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 request 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 requests.
为了允许远程方隐藏它认为敏感的信息，所有实现都应该能够处理加密的订阅和通知请求。
The mechanisms for providing confidentiality are detailed in [RFC3261].
提供保密性的机制详见[RFC3261]。
With the exception of Section 7.2, the subsections here are for current reference, carried over from the original specification (RFC 3265). IANA has updated all registry references that pointed to RFC 3265 to instead indicate this document and created the new "reason code" registry described in Section 7.2.
除第7.2节外，此处各小节仅供当前参考，由原始规范（RFC 3265）继承。IANA已更新了所有指向RFC 3265的注册表参考，以代替该文件，并创建了第7.2节中所述的新“原因代码”注册表。
This document defines an event-type namespace that 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 5.2. To avoid confusion, template-package names and package names share the same namespace; in other words, an event template-package is forbidden from sharing a name with a package.
有两种不同类型的事件类型：普通事件包和事件模板包；见第5.2节。为避免混淆，模板包名称和包名称共享同一名称空间；换句话说，禁止事件模板包与包共享名称。
Policies for registration of SIP event packages and SIP event package templates are defined in Section 4.1 of [RFC5727].
[RFC5727]第4.1节定义了SIP事件包和SIP事件包模板的注册策略。
Registrations with the IANA are required to 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 that describes the event package. Event template-package token registrations are also required to include a pointer to the published RFC that defines the event template-package.
IANA注册需要包括正在注册的令牌以及令牌是包还是模板包。此外，文件包必须包括负责注册的一方的联系信息和/或描述事件包的已发布文件。事件模板包令牌注册还需要包含指向定义事件模板包的已发布RFC的指针。
Registered tokens to designate packages and template-packages are disallowed from containing the character ".", which is used to separate template-packages from packages.
不允许用于指定包和模板包的已注册令牌包含字符“.”，该字符用于将模板包与包分开。
This document specifies no package or template-package names. All entries in this table are added by other documents. 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 four possible permutations of package type, contact, and reference.
此文档未指定包或模板包名称。此表中的所有条目都由其他文档添加。本节剩余部分给出了IANA需要维护的信息类型示例；它还演示了包类型、联系人和引用的所有四种可能的排列。
The table below lists the event packages and template-packages defined for use with the "SIP-Specific Event Notification" mechanism [RFC 6665]. Each name is designated as a package or a template-package under "Type".
下表列出了定义用于“SIP特定事件通知”机制[RFC 6665]的事件包和模板包。每个名称都被指定为“类型”下的包或模板包。
Package Name Type Contact Reference
------------ ---- ------- ---------
example1 package [Doe] [RFCnnnn]
example2 package [RFCnnnn]
example3 template [Doe] [RFCnnnn]
example4 template [RFCnnnn]
Package Name Type Contact Reference
------------ ---- ------- ---------
example1 package [Doe] [RFCnnnn]
example2 package [RFCnnnn]
example3 template [Doe] [RFCnnnn]
example4 template [RFCnnnn]
PEOPLE
------
[Doe] John Doe <john.doe@example.com>
PEOPLE
------
[Doe] John Doe <john.doe@example.com>
REFERENCES
----------
[RFCnnnn] Doe, J., "Sample Document", RFC nnnn, Month YYYY.
REFERENCES
----------
[RFCnnnn] Doe, J., "Sample Document", RFC nnnn, Month YYYY.
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 8.2.1.)
（软件包名称必须符合第8.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:
联系人和电子邮件地址，以获取更多信息：
(self-explanatory)
（不言自明）
This document further defines "reason" codes for use in the "Subscription-State" header field (see Section 4.1.3).
本文件进一步定义了“订阅状态”标题字段中使用的“原因”代码（见第4.1.3节）。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], new reason codes require a Standards Action.
按照“在RFCs中编写IANA注意事项部分的指南”[RFC5226]中概述的政策，新的原因代码需要标准行动。
Registrations with the IANA include the reason code being registered and a reference to a published document that describes the event package. Insertion of such values takes place as part of the RFC publication process or as the result of liaison activity between standards development organizations (SDOs), the result of which will be publication of an associated RFC. New reason codes must conform to the syntax of the ABNF "token" element defined in [RFC3261].
IANA注册包括注册的原因代码和对描述事件包的已发布文档的引用。作为RFC发布过程的一部分，或作为标准开发组织（SDO）之间联络活动的结果，插入此类值，其结果将是相关RFC的发布。新的原因码必须符合[RFC3261]中定义的ABNF“token”元素的语法。
[RFC4660] defined a new reason code prior to the establishment of an IANA registry. We include its reason code ("badfilter") in the initial list of reason codes to ensure a complete registry.
[RFC4660]在建立IANA注册表之前定义了新的原因码。我们将其原因代码（“badfilter”）包括在原因代码的初始列表中，以确保完整的注册表。
The IANA registry for reason codes has been initialized with the following values:
原因代码的IANA注册表已使用以下值初始化：
Reason Code Reference
----------- ---------
deactivated [RFC6665]
probation [RFC6665]
rejected [RFC6665]
timeout [RFC6665]
giveup [RFC6665]
noresource [RFC6665]
invariant [RFC6665]
badfilter [RFC4660]
Reason Code Reference
----------- ---------
deactivated [RFC6665]
probation [RFC6665]
rejected [RFC6665]
timeout [RFC6665]
giveup [RFC6665]
noresource [RFC6665]
invariant [RFC6665]
badfilter [RFC4660]
REFERENCES
----------
[RFC6665] A.B. Roach, "SIP-Specific Event Notification", RFC 6665,
July 2012.
REFERENCES
----------
[RFC6665] A.B. Roach, "SIP-Specific Event Notification", RFC 6665,
July 2012.
[RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "Functional Description of Event Notification Filtering", September 2006.
[RFC4660]Khartabil，H.，Leppanen，E.，Lonnfors，M.，和J.Costa Requena，“事件通知过滤的功能描述”，2006年9月。
This document registers three new header field names, described elsewhere in this document. These header fields are defined by the following information, which is to be added to the header field 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 4. Note that the formal syntax definitions described in this document are expressed in the ABNF format used in [RFC3261] and contain references to elements defined therein.
本节介绍SIP中事件通知所需的语法扩展。第4节描述了语义。请注意，本文档中描述的正式语法定义以[RFC3261]中使用的ABNF格式表示，并包含对其中定义元素的引用。
This document describes two new SIP methods: SUBSCRIBE and NOTIFY.
本文档描述了两种新的SIP方法：订阅和通知。
"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 that has been requested by an earlier SUBSCRIBE method has occurred. It may also provide further details about the event.
NOTIFY方法用于通知SIP节点发生了以前的SUBSCRIBE方法请求的事件。它还可能提供有关该活动的进一步详情。
Event is added to the definition of the element "message-header field" in the SIP message grammar.
事件添加到SIP消息语法中元素“消息头字段”的定义中。
For the purposes of matching NOTIFY requests with SUBSCRIBE requests, the event-type portion of the "Event" header field is compared byte by byte, and the "id" parameter token (if present) is compared byte by byte. An "Event" header field containing an "id" parameter never matches an "Event" header field without an "id" parameter. No other parameters are considered when performing a comparison. SUBSCRIBE responses are matched per the transaction handling rules in [RFC3261].
为了将NOTIFY请求与SUBSCRIBE请求进行匹配，“事件”头字段的事件类型部分逐字节进行比较，“id”参数标记（如果存在）逐字节进行比较。包含“id”参数的“事件”标题字段永远不会与没有“id”参数的“事件”标题字段匹配。执行比较时不考虑其他参数。订阅响应根据[RFC3261]中的事务处理规则进行匹配。
Note that the foregoing 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 field. Multiple events per message are disallowed.
每个“事件”标题字段必须只列出一种事件类型。不允许每条消息有多个事件。
The "Event" header field is defined only for use in SUBSCRIBE and NOTIFY requests and other requests whose definition explicitly calls for its use. It MUST NOT appear in any other SIP requests and MUST NOT appear in responses.
“事件”头字段仅定义用于订阅和通知请求以及其他定义明确要求使用它的请求。它不得出现在任何其他SIP请求中，也不得出现在响应中。
"Allow-Events" is added to the definition of the element "general-header field" in the SIP message grammar. Its usage is described in Section 4.4.4.
“允许事件”被添加到SIP消息语法中元素“general header field”的定义中。第4.4.4节描述了其用途。
User agents MAY include the "Allow-Events" header field in any request or response, as long as its contents comply with the behavior described in Section 4.4.4.
用户代理可以在任何请求或响应中包含“允许事件”标题字段，只要其内容符合第4.4.4节中描述的行为。
"Subscription-State" is added to the definition of the element "request-header" field in the SIP message grammar. Its usage is described in Section 4.1.3. "Subscription-State" header fields are defined for use in NOTIFY requests only. They MUST NOT appear in other SIP requests or responses.
“订阅状态”添加到SIP消息语法中元素“请求头”字段的定义中。第4.1.3节描述了其用途。“订阅状态”标头字段仅定义用于NOTIFY请求。它们不得出现在其他SIP请求或响应中。
For historical purposes, the 202 (Accepted) response code is added to the "Success" header field definition.
出于历史目的，202（已接受）响应代码被添加到“成功”标题字段定义中。
This document does not specify the use of the 202 response code in conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions of the SIP Events Framework assigned specific meaning to the 202 response code.
本文档未指定202响应代码与SUBSCRIBE或NOTIFY方法结合使用。SIP事件框架的早期版本为202响应代码赋予了特定的含义。
Due to response handling in forking cases, any 202 response to a SUBSCRIBE request may be absorbed by a proxy, and thus it can never be guaranteed to be received by the UAC. Furthermore, there is no actual processing difference for a 202 as compared to a 200; a NOTIFY request is sent after the subscription is processed, and it conveys the correct state. SIP interoperability tests found that implementations were handling 202 differently from 200, leading to incompatibilities. Therefore, the 202 response is being deprecated to make it clear there is no such difference and 202 should not be handled differently than 200.
由于分叉情况下的响应处理，订阅请求的任何202响应都可能被代理吸收，因此无法保证UAC接收到。此外，与200相比，202没有实际的处理差异；处理订阅后将发送通知请求，并传递正确的状态。SIP互操作性测试发现，实现处理202的方式与处理200的方式不同，从而导致不兼容。因此，不推荐使用202响应，以明确不存在此类差异，并且202的处理方式不应与200不同。
Implementations conformant with the current specification MUST treat an incoming 202 response as identical to a 200 response and MUST NOT generate 202 response codes to SUBSCRIBE or NOTIFY requests.
符合当前规范的实现必须将传入的202响应视为与200响应相同，并且不得生成202响应代码来订阅或通知请求。
This document also updates [RFC4660], which reiterates the 202-based behavior in several places. Implementations compliant with the present document MUST NOT send a 202 response to a SUBSCRIBE request and will send an alternate success response (such as 200) in its stead.
本文档还更新了[RFC4660]，其中在多个地方重申了基于202的行为。符合本文档的实现不得向订阅请求发送202响应，而是将发送替代的成功响应（如200）。
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 [RFC5234] definitions for the various new and modified syntax elements follows. The notation is as used in [RFC3261], and any elements not defined in this section are as defined in SIP and the documents to which it refers.
下面是各种新语法元素和修改语法元素的扩充BNF[RFC5234]定义。符号在[RFC3261]中使用，本节中未定义的任何元素在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 = ( "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 / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
; The use of the "id" parameter is deprecated; it is included ; for backwards-compatibility purposes only.
; 不推荐使用“id”参数；包括,；仅用于向后兼容目的。
event-param = generic-param / ( "id" EQUAL token )
事件参数=通用参数/（“id”相等标记）
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"
/ "invariant"
/ 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"
/ "invariant"
/ event-reason-extension
event-reason-extension = token
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, June 2000.
[RFC2848]Petrack，S.和L.Conroy，“PINT服务协议：电话呼叫服务IP访问的SIP和SDP扩展”，RFC 28482000年6月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]Burger，E.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC2779]Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息/存在协议要求”，RFC 27792000年2月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3911]Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 4235，2005年11月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
[RFC4485]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）扩展作者指南”，RFC 4485，2006年5月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，2006年6月。
[RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006.
[RFC4660]Khartabil，H.，Leppanen，E.，Lonnfors，M.，和J.Costa Requena，“事件通知过滤的功能描述”，RFC 4660，2006年9月。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057]Sparks，R.，“会话启动协议中的多个对话用法”，RFC 5057，2007年11月。
[RFC5839] Niemi, A. and D. Willis, "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", RFC 5839, May 2010.
[RFC5839]Niemi，A.和D.Willis，“用于条件事件通知的会话启动协议（SIP）事件的扩展”，RFC 5839，2010年5月。
[CERT1998a] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks", 1998, <http://www.cert.org/advisories/CA-1998-01.html>.
[CERT1998a]证书，“证书咨询CA-1998-01:Smurf IP拒绝服务攻击”，1998年<http://www.cert.org/advisories/CA-1998-01.html>.
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 first draft version, 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对初稿进行了彻底清理，以及“SIP存在扩展”的作者文档用于订阅和通知请求语义的输入。
I also owe a debt of gratitude to all the implementors who have provided feedback on areas of confusion or difficulty in the original specification. In particular, Robert Sparks' Herculean efforts organizing, running, and collecting data from the SIPit events have proven invaluable in shaking out specification bugs. Robert Sparks is also responsible for untangling the dialog usage mess, in the form of RFC 5057 [RFC5057].
我还要感谢所有的实现者，他们对原始规范中的混乱或困难提供了反馈。尤其是，罗伯特·斯帕克斯（Robert Sparks）在组织、运行和收集SIPit活动数据方面所做的巨大努力在消除规范缺陷方面证明了其无价。Robert Sparks还负责以RFC 5057[RFC5057]的形式解开对话框使用混乱。
This document represents several changes from the mechanism originally described in RFC 3265. This section summarizes those changes. Bug numbers refer to the identifiers for the bug reports kept on file at http://bugs.sipit.net/.
本文件代表了对RFC 3265中最初描述的机制的一些更改。本节总结了这些变化。错误编号是指保存在文件中的错误报告的标识符http://bugs.sipit.net/.
Strengthened language in Section 4.1.3 to clarify that "expires" should not be sent with "terminated", and must be ignored if received.
加强了第4.1.3节中的语言，以澄清“到期”不应与“终止”一起发送，并且在收到时必须忽略。
Clarified description of "timeout" in Section 4.1.3. (n.b., the text in Section 4.4.3 is actually pretty clear about this).
澄清了第4.1.3节中“超时”的说明。（注意，第4.4.3节中的文本实际上对此非常清楚）。
B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered with
a NOTIFY/expires=0
B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered with
a NOTIFY/expires=0
Added clarifying text to Section 4.2.2 explaining that shortening a subscription to zero seconds is valid. Also added sentence to Section 3.1.1 explicitly allowing shortening to zero.
在第4.2.2节中添加了澄清文本，解释将订阅缩短到零秒是有效的。还向第3.1.1节添加了明确允许缩短为零的句子。
The issues associated with the bug deal exclusively with the handling of multiple usages with a dialog. This behavior has been deprecated and moved to Section 4.5.2. This section, in turn, cites [RFC5057], which addresses all of the issues in Bug 670.
与bug相关的问题专门涉及通过对话框处理多种用法。此行为已被弃用并移至第4.5.2节。本节依次引用[RFC5057]，它解决了Bug 670中的所有问题。
Changed Section 4.2.2 to specifically cite Timer F (so as to avoid ambiguity between transaction timeouts and retransmission timeouts).
更改了第4.2.2节，特别引用了计时器F（以避免事务超时和重传超时之间的歧义）。
Changed strength of including of "expires" in a NOTIFY from "SHOULD" to "MUST" in Section 4.2.2.
将第4.2.2节中通知中包含“到期”的强度从“应该”更改为“必须”。
This bug was addressed in [RFC5057].
此错误已在[RFC5057]中解决。
Fixed Section 8.2.1 to remove incorrect "...responses and..." -- explicitly pointed to SIP for transaction response handling.
修正了第8.2.1节删除不正确的“…响应和…”——明确指向SIP进行事务响应处理。
B.9. Bug 695: Document is not explicit about response to NOTIFY at subscription termination
B.9. 错误695：文档没有明确说明订阅终止时通知的响应
Added text to Section 4.4.1 indicating that the typical response to a terminal NOTIFY is a 200 (OK).
在第4.4.1节中添加文本，表明对终端通知的典型响应为200（OK）。
Added state machine diagram to Section 4.1.2 with explicit handling of what to do when a SUBSCRIBE never shows up. Added definition of and handling for new Timer N to Section 4.1.2.4. Added state machine to Section 4.2.2 to reinforce text.
在第4.1.2节中添加了状态机图，明确处理了当订阅从未出现时的操作。在第4.1.2.4节中增加了新定时器N的定义和处理。将状态机添加到第4.2.2节，以加强文本。
Added text to Section 4.2.1.4 encouraging (but not requiring) full state in final NOTIFY request. Also added text to Section 4.1.2.3 warning subscribers that full state may or may not be present in the final NOTIFY.
在第4.2.1.4节中添加了鼓励（但不要求）最终通知请求中的完整状态的文本。还向第4.1.2.3节添加了警告订阅者最终通知中可能存在或不存在完整状态的文本。
Added text to both Sections 3.1 and 3.2 explicitly indicating that SUBSCRIBE and NOTIFY are target refresh methods.
在第3.1节和第3.2节中都添加了明确指出SUBSCRIBE和NOTIFY是目标刷新方法的文本。
Changed reason phrase to "Interval Too Brief" in Sections 4.2.1.1 and 4.2.1.4, to match 423 reason phrase in SIP [RFC3261].
将第4.2.1.1节和第4.2.1.4节中的原因短语更改为“间隔过短”，以匹配SIP[RFC3261]中的423个原因短语。
Added non-normative clarification to Section 4.4.4 regarding inclusion of "Allow-Events" in a NOTIFY for the one-and-only package supported by the notifier.
在第4.4.4节中增加了非规范性澄清，涉及在通知程序支持的唯一程序包的通知中包含“允许事件”。
Issue of subscription (usage) termination versus dialog termination is handled in [RFC5057]. The text in Section 4.2.2 has been updated to summarize the behavior described by RFC 5057, and cites it for additional detail and rationale.
订阅（使用）终止与对话框终止的问题在[RFC5057]中处理。第4.2.2节中的文本已更新，以总结RFC 5057所描述的行为，并引用其作为补充细节和理由。
Removed erroneous "CSeq" from list of matching criteria in Section 5.4.9.
从第5.4.9节中的匹配标准列表中删除了错误的“CSeq”。
Added Section 7.2 to create and populate IANA registry.
增加了第7.2节以创建和填充IANA注册表。
B.18. Bug 774: Need new reason for terminating subscriptions to resources that never change
B.18. Bug 774:需要新的原因来终止对永不更改的资源的订阅
Added new "invariant" reason code to Section 4.1.3 and to ABNF syntax in Section 8.4.
在第4.1.3节和第8.4节的ABNF语法中添加了新的“不变”原因码。
Changed text in Section 4.3 in order to mandate "Record-Route" in initial SUBSCRIBE and all NOTIFY requests, and add "MAY"-level statements for subsequent SUBSCRIBE requests.
更改了第4.3节中的文本，以便在初始订阅和所有通知请求中强制执行“记录路由”，并为后续订阅请求添加“可能”级别的语句。
Added text to Section 4.2.1 explaining some of the problems associated with implicit subscriptions, and added normative language prohibiting them. Removed language from Section 3.2 describing "non-SUBSCRIBE" mechanisms for creating subscriptions. Simplified language in Section 4.2.2, now that the soft-state/non-soft-state distinction is unnecessary.
在第4.2.1节中添加了解释与隐式订阅相关的一些问题的文本，并添加了禁止这些问题的规范性语言。从第3.2节中删除了描述创建订阅的“非订阅”机制的语言。第4.2.2节中的简化语言，现在软状态/非软状态的区别是不必要的。
Moved handling of dialog reuse and "id" handling to Section 4.5.2. It is documented only for backwards-compatibility purposes.
将对话框重用处理和“id”处理移至第4.5.2节。仅出于向后兼容的目的对其进行记录。
Section 4.4.1 has been updated to specify that dialogs should be created when the NOTIFY arrives. Previously, the dialog was established by the SUBSCRIBE 200 or by the NOTIFY transaction. This was unnecessarily complicated; the newer rules are easier to implement (and result in effectively the same behavior on the wire).
第4.4.1节已更新，以指定在通知到达时应创建对话框。以前，该对话框是由SUBSCRIBE 200或NOTIFY事务建立的。这是不必要的复杂；较新的规则更容易实现（并在网络上有效地产生相同的行为）。
Reorganized Section 4 to consolidate behavior along role lines (subscriber/notifier/proxy) instead of method lines.
重新组织了第4节，以按照角色行（订阅者/通知者/代理）而不是方法行整合行为。
Added sentence to Section 5 clarifying that event packages are expected to include explicit sections covering the issues discussed in this section.
在第5节中增加了一句话，澄清了事件包应包括涵盖本节中讨论的问题的明确章节。
Text in Section 4.6 now clearly calls out behavior upon receipt of a CANCEL. We also echo the "...SHOULD NOT send..." requirement from [RFC3261].
第4.6节中的文本现在清楚地指出了收到取消后的行为。我们还响应了[RFC3261]中的“…不应发送…”要求。
As originally planned, we anticipated a fairly large number of event packages that would move back and forth between end-user devices and servers in the network. In practice, this has ended up not being the case. Certain events, like dialog state, are inherently hosted at end-user devices; others, like presence, are almost always hosted in the network (due to issues like composition, and the ability to deliver information when user devices are offline). Further, the
按照最初的计划，我们预计会有相当多的事件包在网络中的最终用户设备和服务器之间来回移动。实际上，情况并非如此。某些事件（如对话框状态）固有地托管在最终用户设备上；其他的，比如presence，几乎总是托管在网络中（由于合成和用户设备离线时传递信息的能力等问题）。此外
concept of State Agents is the most misunderstood by event package authors. In my expert review of event packages, I have yet to find one that got the concept of State Agents completely correct -- and most of them start out with the concept being 100% backwards from the way RFC 3265 described it.
状态代理的概念是事件包作者最误解的。在我对事件包的专家评审中，我还没有找到一个能够完全正确理解状态代理概念的程序包——大多数程序包都是从RFC3265描述的100%向后的概念开始的。
Rather than remove the ability to perform the actions previously attributed to the widely misunderstood term "State Agent", we have simply eliminated this term. Instead, we talk about the behaviors required to create state agents (state aggregation, subscription notification) without defining a formal term to describe the servers that exhibit these behaviors. In effect, this is an editorial change to make life easier for event package authors; the actual protocol does not change as a result.
我们没有取消以前被广泛误解的“国家代理人”一词所指的执行行动的能力，而是简单地取消了这一术语。相反，我们讨论创建状态代理（状态聚合、订阅通知）所需的行为，而不定义一个正式术语来描述表现这些行为的服务器。实际上，这是一个编辑性的改变，使事件包作者的生活更轻松；实际协议不会因此而改变。
The definition of "State Agent" has been removed from Section 2. Section 4.4.2 has been retooled to discuss migration of subscription in general, without calling out the specific example of state agents. Section 5.4.11 has been focused on state aggregation in particular, instead of state aggregation as an aspect of state agents.
“国家代理人”的定义已从第2节中删除。对第4.4.2节进行了重组，以讨论订阅的一般迁移，而不调用状态代理的具体示例。第5.4.11节特别关注状态聚合，而不是将状态聚合作为状态代理的一个方面。
The following changes are relatively minor revisions to the document that resulted primarily from review of this document in the working group and IESG, rather than implementation reports.
以下更改是对本文件的相对较小的修订，主要源于工作组和IESG对本文件的审查，而非实施报告。
o Clarified scope of "Event" header field parameters. In RFC 3265, the scope is ambiguous, which causes problems with the registry in RFC 3968. The new text ensures that "Event" header field parameters are unique across all event packages.
o 澄清了“事件”标题字段参数的范围。在RFC3265中，作用域不明确，这导致RFC3968中的注册表出现问题。新文本确保“事件”标题字段参数在所有事件包中都是唯一的。
o Removed obsoleted language around IANA registration policies for event packages. Instead, we now cite RFC 5727, which updates RFC 3265, and is authoritative on event package registration policy.
o 删除了事件包的IANA注册策略周围过时的语言。相反，我们现在引用RFC 5727，它更新了RFC 3265，并且在事件包注册策略方面具有权威性。
o Several editorial updates after input from working group, including proper designation of "dialog usage" rather than "dialog" where needed.
o 根据工作组的输入，进行了几次编辑更新，包括在需要时正确指定“对话用法”而不是“对话”。
o Clarified two normative statements about subscription termination by changing from plain English prose to RFC2119 language.
o 通过将纯英语散文更改为RFC2119语言，澄清了关于认购终止的两项规范性声明。
o Removed "Table 2" expansions, per WG consensus on how SIP Table 2 is to be handled.
o 根据工作组关于如何处理SIP表2的共识，删除了“表2”扩展。
o Removed 202 response code.
o 删除了202响应代码。
o Clarified that "Allow-Events" does not list event template-packages.
o 澄清“允许事件”未列出事件模板包。
o Added clarification about proper response when the SUBSCRIBE indicates an unknown media type in its "Accept" header field.
o 添加了关于订阅在其“接受”标题字段中指示未知媒体类型时正确响应的说明。
o Minor clarifications to "Route" and "Record-Route" behavior.
o 对“路线”和“记录路线”行为的次要澄清。
o Added non-normative warning about the limitations of state polling.
o 增加了关于州投票限制的非规范性警告。
o Added information about targeting subscriptions at specific dialogs.
o 添加了有关在特定对话框中定位订阅的信息。
o Added RFC 3261 to list of documents updated by this one (rather than the "2543" indicated by RFC 3265).
o 将RFC 3261添加到该文件更新的文件列表中（而不是RFC 3265指示的“2543”）。
o Clarified text in Section 3.1.1 explaining the meaning of "Expires: 0".
o 第3.1.1节中解释“到期日：0”含义的澄清文本。
o Changed text in definition of "probation" reason code to indicate that subscribers don't need to re-subscribe if the associated state is no longer of use to them.
o 更改了“试用期”原因代码定义中的文本，表明如果关联状态不再对订阅者有用，订阅者无需重新订阅。
o Specified that the termination of a subscription due to a NOTIFY transaction failure does not require sending another NOTIFY message.
o 指定由于NOTIFY事务失败而终止订阅不需要发送其他NOTIFY消息。
o Clarified how order of template application affects the meaning of an "Event" header field value (e.g., "foo.bar.baz" is different than "foo.baz.bar").
o 阐明了模板应用程序的顺序如何影响“事件”标题字段值的含义（例如，“foo.bar.baz”不同于“foo.baz.bar”）。
Author's Address
作者地址
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
美国德克萨斯州达拉斯坎贝尔路17210号Adam Roach Tekelec 250套房，邮编75252
EMail: adam@nostrum.com
EMail: adam@nostrum.com