Network Working Group A. Niemi, Ed.
Request for Comments: 3903 Nokia
Category: Standards Track October 2004
Network Working Group A. Niemi, Ed.
Request for Comments: 3903 Nokia
Category: Standards Track October 2004
Session Initiation Protocol (SIP) Extension for Event State Publication
事件状态发布的会话启动协议（SIP）扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information.
本文档描述了会话启动协议（SIP）的扩展，用于发布SIP事件框架中使用的事件状态。此扩展的第一个应用是发布状态信息。
The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.
本文档中描述的机制可以扩展为支持发布任何存在适当事件包的事件状态。它不是用于传输任意数据的通用机制，因为有更适合此目的的机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Document Conventions . . . . . . . . . . . . 3
3. Overall Operation . . . . . . . . . . . . . . . . . . . . . 4
4. Constructing PUBLISH Requests . . . . . . . . . . . . . . . 5
4.1. Identification of Published Event State. . . . . . . . 6
4.2. Creating Initial Publication . . . . . . . . . . . . . 7
4.3. Refreshing Event State . . . . . . . . . . . . . . . . 8
4.4. Modifying Event State . . . . . . . . . . . . . . . . 9
4.5. Removing Event State . . . . . . . . . . . . . . . . . 9
5. Processing PUBLISH Responses . . . . . . . . . . . . . . . . 10
6. Processing PUBLISH Requests . . . . . . . . . . . . . . . . 10
7. Processing OPTIONS Requests . . . . . . . . . . . . . . . . 13
8. Use of Entity-tags in PUBLISH . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Document Conventions . . . . . . . . . . . . 3
3. Overall Operation . . . . . . . . . . . . . . . . . . . . . 4
4. Constructing PUBLISH Requests . . . . . . . . . . . . . . . 5
4.1. Identification of Published Event State. . . . . . . . 6
4.2. Creating Initial Publication . . . . . . . . . . . . . 7
4.3. Refreshing Event State . . . . . . . . . . . . . . . . 8
4.4. Modifying Event State . . . . . . . . . . . . . . . . 9
4.5. Removing Event State . . . . . . . . . . . . . . . . . 9
5. Processing PUBLISH Responses . . . . . . . . . . . . . . . . 10
6. Processing PUBLISH Requests . . . . . . . . . . . . . . . . 10
7. Processing OPTIONS Requests . . . . . . . . . . . . . . . . 13
8. Use of Entity-tags in PUBLISH . . . . . . . . . . . . . . . 13
8.1. General Notes. . . . . . . . . . . . . . . . . . . . . 13
8.2. Client Usage . . . . . . . . . . . . . . . . . . . . . 14
8.3. Server Usage . . . . . . . . . . . . . . . . . . . . . 14
9. Controlling the Rate of Publication . . . . . . . . . . . . 15
10. Considerations for Event Packages using PUBLISH . . . . . . 15
10.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . 16
10.2. PUBLISH Response Bodies. . . . . . . . . . . . . . . . 16
10.3. Multiple Sources for Event State . . . . . . . . . . . 16
10.4. Event State Segmentation . . . . . . . . . . . . . . . 17
10.5. Rate of Publication. . . . . . . . . . . . . . . . . . 17
11. Protocol Element Definitions . . . . . . . . . . . . . . . . 17
11.1. New Methods. . . . . . . . . . . . . . . . . . . . . . 17
11.1.1. PUBLISH Method . . . . . . . . . . . . . . . . 17
11.2. New Response Codes . . . . . . . . . . . . . . . . . . 19
11.2.1. "412 Conditional Request Failed" Response Code 19
11.3. New Header Fields . . . . . . . . . . . . . . . . . . 20
11.3.1. "SIP-ETag" Header Field . . . . . . . . . . . 20
11.3.2. "SIP-If-Match" Header Field . . . . . . . . . 20
12. Augmented BNF Definitions . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
13.1. Methods . . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Response Codes . . . . . . . . . . . . . . . . . . . . 21
13.3. Header Field Names . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . 22
14.1. Access Control . . . . . . . . . . . . . . . . . . . . 22
14.2. Denial of Service Attacks . . . . . . . . . . . . . . 22
14.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . 22
14.4. Man in the Middle Attacks . . . . . . . . . . . . . . 23
14.5. Confidentiality . . . . . . . . . . . . . . . . . . . 23
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
18.1. Normative References . . . . . . . . . . . . . . . . . 30
18.2. Informative References . . . . . . . . . . . . . . . . 31
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 31
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 32
8.1. General Notes. . . . . . . . . . . . . . . . . . . . . 13
8.2. Client Usage . . . . . . . . . . . . . . . . . . . . . 14
8.3. Server Usage . . . . . . . . . . . . . . . . . . . . . 14
9. Controlling the Rate of Publication . . . . . . . . . . . . 15
10. Considerations for Event Packages using PUBLISH . . . . . . 15
10.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . 16
10.2. PUBLISH Response Bodies. . . . . . . . . . . . . . . . 16
10.3. Multiple Sources for Event State . . . . . . . . . . . 16
10.4. Event State Segmentation . . . . . . . . . . . . . . . 17
10.5. Rate of Publication. . . . . . . . . . . . . . . . . . 17
11. Protocol Element Definitions . . . . . . . . . . . . . . . . 17
11.1. New Methods. . . . . . . . . . . . . . . . . . . . . . 17
11.1.1. PUBLISH Method . . . . . . . . . . . . . . . . 17
11.2. New Response Codes . . . . . . . . . . . . . . . . . . 19
11.2.1. "412 Conditional Request Failed" Response Code 19
11.3. New Header Fields . . . . . . . . . . . . . . . . . . 20
11.3.1. "SIP-ETag" Header Field . . . . . . . . . . . 20
11.3.2. "SIP-If-Match" Header Field . . . . . . . . . 20
12. Augmented BNF Definitions . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
13.1. Methods . . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Response Codes . . . . . . . . . . . . . . . . . . . . 21
13.3. Header Field Names . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . 22
14.1. Access Control . . . . . . . . . . . . . . . . . . . . 22
14.2. Denial of Service Attacks . . . . . . . . . . . . . . 22
14.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . 22
14.4. Man in the Middle Attacks . . . . . . . . . . . . . . 23
14.5. Confidentiality . . . . . . . . . . . . . . . . . . . 23
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
18.1. Normative References . . . . . . . . . . . . . . . . . 30
18.2. Informative References . . . . . . . . . . . . . . . . 31
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 31
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 32
This specification provides a framework for the publication of event state from a user agent to an entity that is responsible for compositing this event state and distributing it to interested parties through the SIP Events [1] framework.
本规范提供了一个框架，用于将事件状态从用户代理发布到负责合成此事件状态并通过SIP事件[1]框架将其分发给相关方的实体。
In addition to defining an event publication framework, this specification defines a concrete usage of that framework for the publication of presence state [2] by a presence user agent [3] to a presence compositor, which has a tightly coupled relationship with the presence agent [1].
除了定义事件发布框架外，本规范还定义了该框架的具体用途，用于存在用户代理[3]向存在合成器发布存在状态[2]，该存在合成器与存在代理[1]具有紧密耦合的关系。
The requirements and model for presence publication are documented in [10]. This specification will address each of those requirements.
[10]中记录了状态发布的要求和模型。本规范将解决这些要求中的每一项。
The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package as defined in [1]. For instance, an application of SIP events for message waiting indications [11] might choose to collect the statuses of voice-mail boxes across a set of user agents using the PUBLISH mechanism. The compositor in such an application would then be responsible for collecting and distributing this state to the subscribers of the event package.
本文档中描述的机制可以扩展为支持发布任何事件状态，其中存在[1]中定义的适当事件包。例如，用于消息等待指示的SIP事件应用程序[11]可以选择使用发布机制跨一组用户代理收集语音信箱的状态。然后，此类应用程序中的合成器将负责收集此状态并将其分发给事件包的订阅者。
Each application that makes use of the PUBLISH mechanism in the publication of event state will need to adhere to the guidelines set in Section 10. The mechanism described in this document is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.
在发布事件状态时使用发布机制的每个应用程序都需要遵守第10节中设置的准则。本文档中描述的机制并非用于传输任意数据的通用机制，因为有更适合此目的的机制。
In addition to the definitions of RFC 2778 [3], RFC 3265 [1], and RFC 3261 [4], this document introduces some new concepts:
除了RFC 2778[3]、RFC 3265[1]和RFC 3261[4]的定义外，本文件还引入了一些新概念：
Event State: State information for a resource, associated with an event package and an address-of-record.
事件状态：资源的状态信息，与事件包和记录地址关联。
Event Publication Agent (EPA): The User Agent Client (UAC) that issues PUBLISH requests to publish event state.
事件发布代理（EPA）：发布发布事件状态的发布请求的用户代理客户端（UAC）。
Event State Compositor (ESC): The User Agent Server (UAS) that processes PUBLISH requests, and is responsible for compositing event state into a complete, composite event state of a resource.
事件状态合成器（ESC）：处理发布请求的用户代理服务器（UAS），负责将事件状态合成为资源的完整复合事件状态。
Presence Compositor: A type of Event State Compositor that is responsible for compositing presence state for a presentity.
状态合成器：一种事件状态合成器，负责合成存在实体的状态。
Publication: The act of an EPA sending a PUBLISH request to an ESC to publish event state.
发布：环境保护局向ESC发送发布请求以发布事件状态的行为。
Event Hard State: The steady-state or default event state of a resource, which the ESC may use in the absence of, or in addition to, soft state publications.
事件硬状态：资源的稳态或默认事件状态，ESC可在无软状态发布或软状态发布之外使用。
Event Soft State: Event state published by an EPA using the PUBLISH mechanism. A protocol element (i.e., an entity-tag) is used to identify a specific soft state entity at the ESC. Soft state has a defined lifetime and will expire after a negotiated amount of time.
事件软状态：EPA使用发布机制发布的事件状态。协议元素（即实体标签）用于标识ESC处的特定软状态实体。软状态具有定义的生存期，并将在协商的时间后过期。
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 BCP 14, RFC 2119 [5] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[5]中的描述进行解释，并指出合规实施的要求级别。
Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain descriptions of normative protocol behavior.
本文档中使用缩进段落（如本段落）来提供附加信息和澄清文本。它们不包含规范协议行为的描述。
This document defines a new SIP method, PUBLISH, for publishing event state. PUBLISH is similar to REGISTER in that it allows a user to create, modify, and remove state in another entity which manages this state on behalf of the user. Addressing a PUBLISH request is identical to addressing a SUBSCRIBE request. The Request-URI of a PUBLISH request is populated with the address of the resource for which the user wishes to publish event state. The user may in turn have multiple User Agents or endpoints that publish event state. Each endpoint may publish its own unique state, out of which the event state compositor generates the composite event state of the resource. In addition to a particular resource, all published event state is associated with a specific event package. Through a subscription to that event package, the user is able to discover the composite event state of all of the active publications.
本文档定义了一个新的SIP方法PUBLISH，用于发布事件状态。发布类似于注册，因为它允许用户在代表用户管理此状态的另一个实体中创建、修改和删除状态。寻址发布请求与寻址订阅请求相同。发布请求的请求URI由用户希望发布其事件状态的资源的地址填充。用户可以依次拥有多个发布事件状态的用户代理或端点。每个端点都可以发布自己的唯一状态，事件状态合成器根据该状态生成资源的复合事件状态。除了特定的资源外，所有已发布的事件状态都与特定的事件包相关联。通过订阅该事件包，用户能够发现所有活动发布的复合事件状态。
A User Agent Client (UAC) that publishes event state is labeled an Event Publication Agent (EPA). For presence, this is the familiar Presence User Agent (PUA) role as defined in [2]. The entity that processes the PUBLISH request is known as an Event State Compositor (ESC). For presence, this is the familiar Presence Agent (PA) role as defined in [2].
发布事件状态的用户代理客户端（UAC）被标记为事件发布代理（EPA）。对于状态，这是[2]中定义的熟悉的状态用户代理（PUA）角色。处理发布请求的实体称为事件状态合成器（ESC）。对于状态，这是[2]中定义的熟悉的状态代理（PA）角色。
PUBLISH requests create soft state in the ESC. This event soft state has a defined lifetime and will expire after a negotiated amount of time, requiring the publication to be refreshed by subsequent PUBLISH requests. There may also be event hard state provisioned for each resource for a particular event package. This event state represents the resource state that is present at all times, and does not expire. The ESC may use event hard state in the absence of, or in addition to, event soft state provided through the PUBLISH mechanism. Setting
发布请求在ESC中创建软状态。此事件软状态具有定义的生存期，并将在协商的时间量后过期，需要通过后续发布请求刷新发布。还可以为特定事件包的每个资源配置事件硬状态。此事件状态表示始终存在且不会过期的资源状态。在没有通过发布机制提供的事件软状态或除此之外，ESC可使用事件硬状态。背景
this event hard state or configuring the ESC policy regarding the aggregation of different event state is out of the scope of this specification.
此事件硬状态或配置有关不同事件状态聚合的ESC策略超出本规范的范围。
The body of a PUBLISH request carries the published event state. In response to every successful PUBLISH request, the ESC assigns an identifier to the publication in the form of an entity-tag. This identifier is then used by the EPA in any subsequent PUBLISH request that modifies, refreshes or removes the event state of that publication. When event state expires or is explicitly removed, the entity-tag associated with it becomes invalid. A publication for an invalid entity-tag will naturally fail, and the EPA needs to start anew and resend its event state without referencing a previous entity-tag.
发布请求的主体包含已发布的事件状态。为了响应每个成功的发布请求，ESC以实体标记的形式为发布分配一个标识符。EPA随后在修改、刷新或删除该发布的事件状态的任何后续发布请求中使用该标识符。当事件状态过期或被显式删除时，与其关联的实体标记将变为无效。无效实体标记的发布自然会失败，EPA需要重新开始并重新发送其事件状态，而不引用以前的实体标记。
PUBLISH requests create, modify, and remove event state associated with an address-of-record. A suitably authorized third party may also perform publication on behalf of a particular address-of-record.
发布请求创建、修改和删除与记录地址关联的事件状态。经适当授权的第三方也可以代表特定的记录地址进行发布。
Except as noted, the construction of the PUBLISH request and the behavior of clients sending a PUBLISH request are identical to the general UAC behavior described in Section 8.1 and Section 17.1 of RFC 3261 [4].
除非另有说明，发布请求的构造和发送发布请求的客户端的行为与RFC 3261[4]第8.1节和第17.1节中描述的一般UAC行为相同。
If necessary, clients may probe for the support of PUBLISH using the OPTIONS request defined in SIP [4]. The presence of "PUBLISH" in the "Allow" header field in a response to an OPTIONS request indicates support for the PUBLISH method. In addition, the "Allow-Events" header field indicates the supported event packages.
如有必要，客户端可以使用SIP[4]中定义的选项请求来探测对发布的支持。在对选项请求的响应中，“允许”标题字段中出现“发布”表示支持发布方法。此外，“允许事件”标题字段指示支持的事件包。
Note that it is possible for the OPTIONS request to fork, and consequently return a response from a User Agent other than the ESC. In that case, support for the PUBLISH method may not be appropriately represented for that particular Request-URI.
请注意，选项请求可能会分叉，并因此从ESC以外的用户代理返回响应。在这种情况下，可能无法为该特定请求URI适当地表示对发布方法的支持。
A PUBLISH request does not establish a dialog. A UAC MAY include a Route header field in a PUBLISH request based on a pre-existing route set as described in Section 8.1 of RFC 3261 [4]. The Record-Route header field has no meaning in PUBLISH requests or responses, and MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a PUBLISH request.
发布请求不建立对话框。UAC可根据RFC 3261[4]第8.1节所述的预先存在的路由集，在发布请求中包括路由头字段。记录路由标头字段在发布请求或响应中没有意义，如果存在，则必须忽略该字段。特别是，UAC不得基于对发布请求的任何响应中是否存在记录路由头字段来创建新路由集。
The PUBLISH request MAY contain a Contact header field, but including one in a PUBLISH request has no meaning in the event publication context and will be ignored by the ESC. An EPA MAY send a PUBLISH
发布请求可能包含联系人标头字段，但在发布请求中包含联系人标头字段在事件发布上下文中没有任何意义，ESC将忽略该字段。环境保护局可以发送一份公告
request within an existing dialog. In that case, the request is received in the context of any media session or sessions associated with that dialog.
在现有对话框中请求。在这种情况下，将在任何媒体会话或与该对话框关联的会话的上下文中接收请求。
Note that while sending a PUBLISH request within an existing dialog is not prohibited, it will typically not result in the expected behavior. Unless the other end of the dialog is also an ESC, it will probably reject the request.
请注意，虽然在现有对话框中发送发布请求并不被禁止，但通常不会导致预期的行为。除非对话框的另一端也是ESC，否则它可能会拒绝请求。
EPAs MUST NOT send a new PUBLISH request (not a re-transmission) for the same Request-URI, until they have received a final response from the ESC for the previous one or the previous PUBLISH request has timed out.
EPA不得为同一请求URI发送新的发布请求（不是重新传输），直到他们收到ESC对上一个请求的最终响应或上一个发布请求超时。
Identification of published event state is provided by three pieces of information: Request-URI, event type, and (optionally) an entity-tag.
已发布事件状态的标识由三条信息提供：请求URI、事件类型和（可选）实体标记。
The Request-URI of a PUBLISH request contains enough information to route the request to the appropriate entity per the request routing procedures outlined in RFC 3261 [4]. It also contains enough information to identify the resource whose event state is to be published, but not enough information to determine the type of the published event state.
发布请求的请求URI包含足够的信息，可以按照RFC 3261[4]中概述的请求路由过程将请求路由到适当的实体。它还包含足够的信息来标识要发布其事件状态的资源，但没有足够的信息来确定已发布事件状态的类型。
For determining the type of the published event state, the EPA MUST include a single Event header field in PUBLISH requests. The value of this header field indicates the event package for which this request is publishing event state.
为了确定已发布事件状态的类型，EPA必须在发布请求中包含单个事件头字段。此标头字段的值表示此请求正在发布其事件状态的事件包。
For each successful PUBLISH request, the ESC will generate and assign an entity-tag and return it in the SIP-ETag header field of the 2xx response.
对于每个成功的发布请求，ESC将生成并分配一个实体标记，并将其返回到2xx响应的SIP ETag头字段中。
When updating previously published event state, PUBLISH requests MUST contain a single SIP-If-Match header field identifying the specific event state that the request is refreshing, modifying or removing. This header field MUST contain a single entity-tag that was returned by the ESC in the SIP-ETag header field of the response to a previous publication.
更新以前发布的事件状态时，发布请求必须包含单个SIP If Match标头字段，该字段标识请求正在刷新、修改或删除的特定事件状态。此标头字段必须包含单个实体标记，该标记由ESC在对先前发布的响应的SIP ETag标头字段中返回。
The PUBLISH request MAY contain a body, which contains event state that the client wishes to publish. The content format and semantics are dependent on the event package identified in the Event header field.
发布请求可能包含一个主体，其中包含客户端希望发布的事件状态。内容格式和语义取决于事件头字段中标识的事件包。
The presence of a body and the SIP-If-Match header field determine the specific operation that the request is performing, as described in Table 1.
主体和SIP If Match头字段的存在决定了请求正在执行的特定操作，如表1所述。
+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial | yes | no | > 0 |
| Refresh | no | yes | > 0 |
| Modify | yes | yes | > 0 |
| Remove | no | yes | 0 |
+-----------+-------+---------------+---------------+
+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial | yes | no | > 0 |
| Refresh | no | yes | > 0 |
| Modify | yes | yes | > 0 |
| Remove | no | yes | 0 |
+-----------+-------+---------------+---------------+
Table 1: Publication Operations
表1：出版业务
An 'Initial' publication sets the initial event state for a particular EPA. There may, of course, already be event state published by other EPAs (for the same address-of-record). That state is unaffected by an initial publication. A 'Refresh' publication refreshes the lifetime of a previous publication, whereas a 'Modify' publication modifies the event state of a previous publication. A 'Remove' publication requests immediate removal of event state. These operations are described in more detail in the following sections.
“初始”出版物设置特定EPA的初始事件状态。当然，可能已经有其他EPA发布的事件状态（对于相同的记录地址）。该状态不受初始发布的影响。“刷新”发布刷新以前发布的生存期，而“修改”发布修改以前发布的事件状态。“删除”发布请求立即删除事件状态。以下各节将更详细地描述这些操作。
An initial publication is a PUBLISH request created by the EPA and sent to the ESC that establishes soft state for the event package indicated in the Event header field of the request, and bound to the address in the Request-URI of the request.
初始发布是由EPA创建并发送给ESC的发布请求，该请求为请求的事件头字段中指示的事件包建立软状态，并绑定到请求URI中的地址。
An initial PUBLISH request MUST NOT contain a SIP-If-Match header field. However, if the EPA expects an appropriate, locally stored entity-tag to still be valid, it SHOULD first try to modify that event state as described in Section 4.4, instead of submitting an initial publication.
初始发布请求不得包含SIP If Match标头字段。然而，如果环境保护局希望适当的、本地存储的实体标签仍然有效，则应首先尝试按照第4.4节所述修改该事件状态，而不是提交初始出版物。
An initial PUBLISH request MUST contain a body that contains the published event state.
初始发布请求必须包含包含已发布事件状态的正文。
An initial PUBLISH request MAY contain a single Expires header field. This value indicates the suggested lifetime of the event state publication.
初始发布请求可能包含单个Expires标头字段。此值表示事件状态发布的建议生存期。
The ESC may lower the suggested lifetime of the publication, but it will never extend it. If an Expires header field is not present, the EPA is indicating its desire for the ESC to choose. The Expires header field in a 2xx response to the initial PUBLISH indicates the actual duration for which the publication will remain active. Unless refreshed before this lifetime is exceeded, the publication will expire.
ESC可能会降低出版物的建议寿命，但它永远不会延长它。如果Expires标头字段不存在，则EPA表示希望ESC进行选择。初始发布的2xx响应中的Expires标头字段指示发布将保持活动状态的实际持续时间。除非在超过此生存期之前刷新，否则发布将过期。
An EPA is responsible for refreshing its previously established publications before their expiration interval has elapsed. To refresh a publication, the EPA MUST create a PUBLISH request that includes in a SIP-If-Match header field the entity-tag of the publication to be refreshed.
EPA负责在过期时间间隔之前刷新其先前建立的出版物。要刷新发布，EPA必须创建一个发布请求，该请求在SIP If Match头字段中包含要刷新的发布的实体标记。
The SIP-If-Match header field containing an entity-tag conditions the PUBLISH request to refresh a specific event state established by a prior publication. If the entity-tag matches previously published event state at the ESC, the refresh succeeds, and the EPA receives a 2xx response.
包含实体标记的SIP If Match标头字段将发布请求条件设置为刷新先前发布建立的特定事件状态。如果实体标记与ESC上先前发布的事件状态匹配，则刷新成功，EPA收到2xx响应。
Like the 2xx response to an initial PUBLISH request, the 2xx response to a refresh PUBLISH request will contain a SIP-ETag header field with an entity-tag. The EPA MUST store this entity-tag, replacing any existing entity-tag for the refreshed event state. See Section 8.2 for more information on the EPA handling of entity-tags.
与对初始发布请求的2xx响应一样，对刷新发布请求的2xx响应将包含带有实体标记的SIP ETag头字段。EPA必须存储此实体标记，替换刷新事件状态的任何现有实体标记。有关EPA处理实体标签的更多信息，请参见第8.2节。
If there is no matching event state, e.g., the event state to be refreshed has already expired, the EPA receives a 412 (Conditional Request Failed) response to the PUBLISH request.
如果没有匹配的事件状态，例如，要刷新的事件状态已经过期，EPA将收到对发布请求的412（条件请求失败）响应。
A publication refresh MAY contain a single Expires header field. This value indicates the suggested lifetime of the event state.
发布刷新可能包含单个Expires标头字段。此值表示事件状态的建议生存期。
The ESC may lower the suggested lifetime of the publication refresh, but it will never extend it. If an Expires header field is not present, the EPA is indicating its desire for the ESC to choose. The Expires header field in a 2xx response to the publication refresh indicates the actual duration for which the publication will remain active.
ESC可能会降低发布刷新的建议生存期，但它永远不会延长它。如果Expires标头字段不存在，则EPA表示希望ESC进行选择。对发布刷新的2xx响应中的Expires标头字段指示发布将保持活动状态的实际持续时间。
A publication refresh only extends the expiration time of already existing event state. It does not affect that event state in any other way. Therefore, a PUBLISH request that refreshes event state MUST NOT have a body.
发布刷新只会延长现有事件状态的过期时间。它不会以任何其他方式影响该事件状态。因此，刷新事件状态的发布请求不能有正文。
Modifying event state closely resembles the creation of initial event state. However, instead of establishing completely new event state at the ESC, already existing event state is updated with modified event state. The nature of this update depends on the content of the body, and the semantics associated with the format of that body.
修改事件状态与创建初始事件状态非常相似。但是，不是在ESC上建立全新的事件状态，而是使用修改后的事件状态更新现有的事件状态。此更新的性质取决于正文的内容以及与正文格式相关的语义。
To modify event state, the EPA MUST construct a PUBLISH request that includes in a SIP-If-Match header field the entity-tag of the event state publication to be modified. A PUBLISH request that modifies event state MUST contain a body that includes the modified event state.
要修改事件状态，EPA必须构造一个发布请求，该请求在SIP If Match头字段中包含要修改的事件状态发布的实体标记。修改事件状态的发布请求必须包含包含已修改事件状态的正文。
The SIP-If-Match header field conditions the PUBLISH request to modify a specific event state established by a prior publication, and identified by the entity-tag. If the entity-tag matches previously published event state at the ESC, that event state is replaced by the event state carried in the PUBLISH request, and the EPA receives a 2xx response.
SIP If Match标头字段对发布请求进行条件设置，以修改由先前发布建立并由实体标记标识的特定事件状态。如果实体标记与ESC上先前发布的事件状态匹配，则该事件状态将被发布请求中携带的事件状态替换，EPA将收到2xx响应。
Like the 2xx response to an initial PUBLISH request, the 2xx response to a modifying PUBLISH request will contain a SIP-ETag header field with an entity-tag. The EPA MUST store this entity-tag, replacing any existing entity-tag for the modified event state. See Section 8.2 for more information on the EPA handling of entity-tags.
与初始发布请求的2xx响应类似，修改发布请求的2xx响应将包含一个带有实体标记的SIP ETag头字段。EPA必须存储该实体标记，替换修改事件状态的任何现有实体标记。有关EPA处理实体标签的更多信息，请参见第8.2节。
If there is no matching event state at the ESC, e.g., the event state to be modified has already expired, the EPA receives a 412 (Conditional Request Failed) response to the PUBLISH request.
如果ESC没有匹配的事件状态，例如，要修改的事件状态已经过期，EPA将收到对发布请求的412（条件请求失败）响应。
A modifying PUBLISH request MAY contain a single Expires header field. This value indicates the suggested lifetime of the event state publication.
修改发布请求可能包含单个Expires标头字段。此值表示事件状态发布的建议生存期。
The ESC may lower the suggested lifetime of the publication, but it will never extend it. If an Expires header field is not present, the EPA is indicating its desire for the ESC to choose. The Expires header field in a 2xx response to the modifying PUBLISH request indicates the actual duration for which the publication will remain active. Unless refreshed before this lifetime is exceeded, the publication will expire.
ESC可能会降低出版物的建议寿命，但它永远不会延长它。如果Expires标头字段不存在，则EPA表示希望ESC进行选择。对修改发布请求的2xx响应中的Expires标头字段指示发布将保持活动状态的实际持续时间。除非在超过此生存期之前刷新，否则发布将过期。
Event state established by a prior publication may also be explicitly removed.
以前的出版物建立的事件状态也可以明确删除。
To request the immediate removal of event state, an EPA MUST create a PUBLISH request with an Expires value of "0", and set the SIP-If-Match header field to contain the entity-tag of the event state publication to be removed.
要请求立即删除事件状态，EPA必须创建一个过期值为“0”的发布请求，并将SIP If Match头字段设置为包含要删除的事件状态发布的实体标记。
Note that removing event state is effectively a publication refresh suggesting an infinitesimal expiration interval. Consequently, the refreshed event state expires immediately after being refreshed.
请注意，删除事件状态实际上是一次发布刷新，提示无限小的过期时间间隔。因此，刷新的事件状态在刷新后立即过期。
Similar to an event state refresh, the removal of event state only affects the expiry of the event state. Therefore, a PUBLISH request that removes event state MUST NOT contain a body.
与事件状态刷新类似，删除事件状态只会影响事件状态的到期。因此，删除事件状态的发布请求不能包含正文。
When processing responses to PUBLISH requests, the steps in Section 8.1.2 of RFC 3261 [4] apply.
在处理发布请求的响应时，RFC 3261[4]第8.1.2节中的步骤适用。
If an EPA receives a 412 (Conditional Request Failed) response, it MUST NOT reattempt the PUBLISH request. Instead, to publish event state, the EPA SHOULD perform an initial publication, i.e., a PUBLISH request without a SIP-If-Match header field, as described in Section 4.2. The EPA MUST also discard the entity-tag that produced this error response.
如果EPA收到412（条件请求失败）响应，则不得重新尝试发布请求。相反，要发布事件状态，EPA应执行初始发布，即，如第4.2节所述，不带SIP If Match头字段的发布请求。EPA还必须丢弃产生此错误响应的实体标签。
If an EPA receives a 423 (Interval Too Brief) response to a PUBLISH request, it MAY retry the publication after changing the expiration interval in the Expires header field to be equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response.
如果EPA接收到对发布请求的423（间隔太短）响应，它可以在将Expires标头字段中的过期间隔更改为等于或大于423（间隔太短）响应的Min Expires标头字段中的过期间隔后重试发布。
The Event State Compositor (ESC) is a User Agent Server (UAS) that processes and responds to PUBLISH requests, and maintains a list of publications for a given address-of-record. The ESC has to know (e.g., through configuration) the set of addresses for which it maintains event state.
事件状态合成器（ESC）是一个用户代理服务器（UAS），用于处理和响应发布请求，并维护给定记录地址的发布列表。ESC必须知道（例如，通过配置）其维护事件状态的地址集。
The ESC MUST ignore the Record-Route header field if it is included in a PUBLISH request. The ESC MUST NOT include a Record-Route header field in any response to a PUBLISH request. The ESC MUST ignore the Contact header field if one is present in a PUBLISH request.
如果发布请求中包含记录路由标头字段，则ESC必须忽略该字段。ESC不得在对发布请求的任何响应中包含记录路由头字段。如果发布请求中存在联系人标题字段，则ESC必须忽略该字段。
PUBLISH requests with the same Request-URI MUST be processed in the order that they are received. PUBLISH requests MUST also be processed atomically, meaning that a particular PUBLISH request is either processed completely or not at all.
必须按照接收顺序处理具有相同请求URI的发布请求。发布请求还必须以原子方式处理，这意味着特定的发布请求要么完全处理，要么根本不处理。
When receiving a PUBLISH request, the ESC follows the steps defining general UAS behavior in Section 8.2 of RFC 3261 [4]. In addition, for PUBLISH specific behavior the ESC follows these steps:
当收到发布请求时，ESC遵循RFC 3261[4]第8.2节中定义一般UAS行为的步骤。此外，对于发布特定行为，ESC遵循以下步骤：
1. The ESC inspects the Request-URI to determine whether this request is targeted to a resource for which the ESC is responsible for maintaining event state. If not, the ESC MUST return a 404 (Not Found) response and skip the remaining steps.
1. ESC检查请求URI以确定此请求是否针对ESC负责维护事件状态的资源。否则，ESC必须返回404（未找到）响应并跳过其余步骤。
It may also be that the Request-URI points to a domain that the ESC is not responsible for. In that case, the UAS receiving the request can assume the role of a proxy server and forward the request to a more appropriate target.
也可能是请求URI指向ESC不负责的域。在这种情况下，接收请求的UAS可以扮演代理服务器的角色，并将请求转发给更合适的目标。
2. The ESC examines the Event header field of the PUBLISH request. If the Event header field is missing or contains an event package which the ESC does not support, the ESC MUST respond to the PUBLISH request with a 489 (Bad Event) response, and skip the remaining steps.
2. ESC检查发布请求的事件头字段。如果事件标题字段缺失或包含ESC不支持的事件包，则ESC必须以489（错误事件）响应响应发布请求，并跳过其余步骤。
3. The ESC examines the SIP-If-Match header field of the PUBLISH request for the presence of a request precondition.
3. ESC检查发布请求的SIP If Match头字段是否存在请求先决条件。
* If the request does not contain a SIP-If-Match header field, the ESC MUST generate and store a locally unique entity-tag for identifying the publication. This entity-tag is associated with the event-state carried in the body of the PUBLISH request.
* 如果请求不包含SIP If Match标头字段，则ESC必须生成并存储一个本地唯一的实体标记，用于标识发布。此实体标记与发布请求主体中携带的事件状态相关联。
* Else, if the request has a SIP-If-Match header field, the ESC checks whether the header field contains a single entity-tag. If not, the request is invalid, and the ESC MUST return with a 400 (Invalid Request) response and skip the remaining steps.
* 否则，如果请求具有SIP if Match头字段，则ESC将检查头字段是否包含单个实体标记。否则，请求无效，ESC必须返回400（无效请求）响应并跳过其余步骤。
* Else, the ESC extracts the entity-tag contained in the SIP-If-Match header field and matches that entity-tag against all locally stored entity-tags for this resource and event package. If no match is found, the ESC MUST reject the publication with a response of 412 (Conditional Request Failed), and skip the remaining steps.
* 否则，ESC将提取SIP If Match标头字段中包含的实体标记，并将该实体标记与此资源和事件包的所有本地存储的实体标记进行匹配。如果未找到匹配项，ESC必须以412响应拒绝发布（条件请求失败），并跳过其余步骤。
4. The ESC processes the Expires header field value from the PUBLISH request.
4. ESC处理发布请求中的Expires标头字段值。
* If the request has an Expires header field, that value MUST be taken as the requested expiration.
* 如果请求具有Expires标头字段，则该值必须作为请求的过期时间。
* Else, a locally-configured default value MUST be taken as the requested expiration.
* 否则，必须将本地配置的默认值作为请求的过期时间。
* The ESC MAY choose an expiration less than the requested expiration interval. Only if the requested expiration interval is greater than zero and less than a locally-configured minimum, the ESC MAY reject the publication with a response of 423 (Interval Too Brief), and skip the remaining steps. This response MUST contain a Min-Expires header field that states the minimum expiration interval the ESC is willing to honor.
* ESC可选择一个小于请求的到期时间间隔的到期时间。只有当请求的过期时间间隔大于零且小于本地配置的最小值时，电子稳定控制系统才能以423响应（时间间隔太短）拒绝发布，并跳过其余步骤。该响应必须包含一个Min Expires标头字段，该字段说明ESC愿意遵守的最小到期时间间隔。
5. The ESC processes the published event state contained in the body of the PUBLISH request. If the content type of the request does not match the event package, or is not understood by the ESC, the ESC MUST reject the request with an appropriate response, such as 415 (Unsupported Media Type), and skip the remainder of the steps.
5. ESC处理发布请求主体中包含的已发布事件状态。如果请求的内容类型与事件包不匹配，或者ESC不理解，则ESC必须使用适当的响应（例如415（不支持的媒体类型））拒绝请求，并跳过其余步骤。
* The ESC stores the event state delivered in the body of the PUBLISH request and identified by the associated entity-tag, updating any existing event state for that entity-tag. The expiration value is set to the chosen expiration interval.
* ESC存储发布请求主体中传递的事件状态，并由关联实体标记标识，更新该实体标记的任何现有事件状态。过期值设置为所选的过期时间间隔。
* If the request has no message body and contained no entity-tag, the ESC SHOULD reject the request with an appropriate response, such as 400 (Invalid Request), and skip the remainder of the steps. Alternatively, in case either ESC local policy or the event package has defined semantics for an initial publication containing no message body, the ESC MAY accept it.
* 如果请求没有消息体且不包含实体标记，则ESC应使用适当的响应（例如400（无效请求））拒绝请求，并跳过其余步骤。或者，如果ESC本地策略或事件包为不包含消息正文的初始发布定义了语义，则ESC可以接受它。
* Else, the event state identified by the entity-tag is refreshed, setting the expiration value to the chosen expiration interval.
* 否则，将刷新实体标记标识的事件状态，并将过期值设置为所选的过期间隔。
* If the chosen expiration interval has a special value of "0", the event state identified by the entity-tag MUST be immediately removed. The ESC MUST NOT store any event state as a result of such a request.
* 如果选择的过期时间间隔具有特殊值“0”，则必须立即删除实体标记标识的事件状态。ESC不得存储因此类请求而产生的任何事件状态。
The processing of the PUBLISH request MUST be atomic. If internal errors (such as the inability to access a back-end database) occur before processing is complete, the publication MUST NOT succeed, and the ESC MUST fail with an appropriate error response, such as 504 (Server Time-out), and skip the last step.
发布请求的处理必须是原子的。如果在处理完成之前发生内部错误（例如无法访问后端数据库），则发布不得成功，ESC必须失败并给出适当的错误响应，例如504（服务器超时），并跳过最后一步。
6. The ESC returns a 200 (OK) response. The response MUST contain an Expires header field indicating the expiration interval chosen by the ESC. The response MUST also contain a SIP-ETag header field that contains a single entity-tag identifying the publication. The ESC MUST generate a new entity-tag for each successful publication, replacing any previous entity-tag associated with that event state. The generated entity-tag MUST be unique from any other entity-tags currently assigned to event state associated with that Request-URI, and MUST be different from any entity-tag assigned previously to event state for that Request-URI. See Section 8.3 for more information on the ESC handling of entity-tags.
6. ESC返回200（正常）响应。响应必须包含一个Expires标头字段，指示ESC选择的过期时间间隔。响应还必须包含SIP ETag头字段，该字段包含标识发布的单个实体标记。ESC必须为每个成功的发布生成一个新的实体标记，替换与该事件状态关联的任何以前的实体标记。生成的实体标记必须与当前分配给与该请求URI关联的事件状态的任何其他实体标记唯一，并且必须与之前分配给该请求URI的事件状态的任何实体标记不同。有关ESC处理实体标记的更多信息，请参见第8.3节。
A client may probe the ESC for the support of PUBLISH using the OPTIONS request defined in SIP [4]. The ESC processes OPTIONS requests as defined in Section 11.2 of RFC 3261 [4]. In the response to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of allowed methods in the Allow header field. Also, it SHOULD list the supported event packages in an Allow-Events header field.
客户机可以使用SIP[4]中定义的选项请求探测ESC以获得发布支持。ESC处理RFC 3261[4]第11.2节中定义的选项请求。在对选项请求的响应中，ESC应在Allow header字段中向允许的方法列表中包含“PUBLISH”。此外，它还应在Allow Events标头字段中列出支持的事件包。
The Allow header field may also be used to specifically announce support for PUBLISH messages when registering. (See SIP Capabilities [12] for details).
“允许标头”字段还可用于在注册时专门宣布对发布消息的支持。（有关详细信息，请参见SIP功能[12]）。
This section makes a general overview of the entity-tags usage in PUBLISH. It is informative in nature and thus contains no normative protocol description.
本节概括介绍发布中实体标记的使用。它本质上是信息性的，因此不包含规范性协议描述。
The PUBLISH mechanism makes use of entity-tags, as defined in HTTP/ 1.1 [13]. While the main functionality is preserved, the syntax and semantics for entity-tags and the corresponding header fields is adapted specifically for use with the PUBLISH method. The main differences are:
发布机制使用HTTP/1.1[13]中定义的实体标记。虽然保留了主要功能，但实体标记的语法和语义以及相应的头字段都是专门为与发布方法一起使用而调整的。主要区别在于：
o The syntax for entity-tags is a token instead of quoted-string. There is also no prefix defined for indicating a weak entity-tag.
o 实体标记的语法是标记，而不是带引号的字符串。也没有为指示弱实体标记定义前缀。
o A PUBLISH precondition can only apply to a single entity-tag, so request preconditions with multiple entity-tags are not allowed.
o 发布前提条件只能应用于单个实体标记，因此不允许具有多个实体标记的请求前提条件。
o A request precondition can't apply to "any" entity, namely there is no special "*" entity-tag value defined for PUBLISH.
o 请求前提条件不能应用于“任何”实体，即没有为发布定义特殊的“*”实体标记值。
o Whereas in HTTP/1.1 returning an entity-tag is optional for origin servers, in PUBLISH ESCs are required to always return an entity-tag for a successful publication.
o 在HTTP/1.1中，返回实体标记对于源服务器是可选的，而在发布中，要求ESC始终为成功发布返回实体标记。
The main motivation for the above adaptation is that PUBLISH is conceptually an HTTP PUT, for which only a subset of the features in cache validation using entity-tags is allowed in HTTP/1.1. It makes little sense to enable features other than this subset for event state publication.
上述调整的主要动机是，发布在概念上是一个HTTP PUT，HTTP/1.1中只允许使用实体标记进行缓存验证中的一部分功能。为事件状态发布启用除此子集以外的功能没有什么意义。
To make it apparent that the entity-tags usage in PUBLISH is similar but not identical to HTTP/1.1, we have not adopted the header field names directly from HTTP/1.1, but rather have created similar but distinct names, as can be seen in Section 11.
为了说明PUBLISH中的实体标记用法与HTTP/1.1相似但不完全相同，我们没有直接采用HTTP/1.1中的头字段名称，而是创建了类似但不同的名称，如第11节所示。
Each successful publication will get assigned an entity-tag which is then delivered to the EPA in the response to the PUBLISH request. The EPA needs to store that entity-tag, replacing any previous entity-tag for that event state. If a request fails with a 412 (Conditional Request Failed) response, the EPA discards the entity-tag that caused the failure.
每个成功的发布都将被分配一个实体标签，然后在对发布请求的响应中提交给EPA。EPA需要存储该实体标记，替换该事件状态的任何以前的实体标记。如果一个请求因412（条件请求失败）响应而失败，EPA将丢弃导致失败的实体标记。
Entity-tags are opaque tokens to the EPA. The EPA cannot infer any further semantics from an entity-tag beyond a simple identifier, or assume a specific formatting. An entity-tag may be a monotonically increasing counter, but it may also be a totally random token. It is up to the ESC implementation as to what the formatting of an entity-tag is.
实体标记是EPA的不透明标记。EPA不能从一个简单标识符之外的实体标记推断出任何进一步的语义，也不能假设特定的格式。实体标记可以是单调递增的计数器，但也可以是完全随机的标记。实体标记的格式由ESC实现。
Entity-tags are generated and maintained by the ESC. They are part of the state maintained by the ESC that also includes the actual event state and its remaining expiration interval. An entity-tag is generated and stored for each successful event state publication, and returned to the EPA in a 200 (OK) response. Each event state publication from the EPA that updates a previous publication will include an entity-tag that the ESC can use as a search key in the set of active publications.
实体标记由ESC生成和维护。它们是ESC维护的状态的一部分，该状态还包括实际事件状态及其剩余过期时间间隔。为每个成功的事件状态发布生成并存储一个实体标记，并在200（OK）响应中返回给EPA。EPA更新先前出版物的每个事件状态出版物将包括一个实体标签，ESC可将其用作活动出版物集中的搜索键。
The way in which an entity-tag is generated is an implementation decision. One possible way to generate an entity-tag is to implement it as an integer counter that is incremented by one for each successfully processed publication. Other, equally valid ways for generating entity-tags exist, and this document makes no recommendations or preference for a single way.
实体标记的生成方式是一个实现决策。生成实体标记的一种可能方法是将其实现为整数计数器，对于每个成功处理的发布，该计数器递增1。其他同样有效的生成实体标记的方法也存在，本文档对单一方法没有任何建议或偏好。
As an entity responsible for aggregating state information from potentially many sources, the ESC can be subject to considerable amounts of publication traffic. There are ways to reduce the amount of PUBLISH requests that the ESC receives:
作为一个负责汇总来自潜在多个来源的状态信息的实体，ESC可能会受到大量发布流量的影响。有几种方法可以减少ESC收到的发布请求量：
o Choice of the expiration interval for a publication can be affected by the ESC. It can insist that an EPA chooses a longer expiration value to what it suggests, in case the ESC's local default minimum expiration value is not reached. Maintaining a longer default minimum expiration value at the ESC reduces the rate at which publications are refreshed.
o 发布过期时间间隔的选择可能受ESC的影响。如果未达到ESC的本地默认最小到期值，它可以坚持要求EPA根据其建议选择更长的到期值。在ESC中保持较长的默认最小过期时间值会降低发布的刷新速率。
o Another way of reducing publication traffic is to use a SIP-level push-back to quench a specific source of publication traffic. To push back on publications from a particular source, the ESC MAY respond to a PUBLISH request with a 503 (Service Unavailable), as defined in RFC 3261 [4]. This response SHOULD contain a Retry-After header field indicating the time interval that the publication source is required to wait until sending another PUBLISH request.
o 减少发布流量的另一种方法是使用SIP级别的回推来消除特定的发布流量源。如RFC 3261[4]中所定义，为了回退特定来源的发布，ESC可使用503（服务不可用）响应发布请求。此响应应包含Retry After标头字段，指示发布源在发送另一个发布请求之前需要等待的时间间隔。
At the time of writing this specification, work on managing load in SIP is starting, which may be able to provide further tools for managing load in event state publication systems.
在编写本规范时，正在开始在SIP中管理负载的工作，这可能会为管理事件状态发布系统中的负载提供进一步的工具。
This section discusses several issues which should be taken into consideration when applying the PUBLISH mechanism to event packages. It also demonstrates how these issues are handled when using PUBLISH for presence publication.
本节讨论将发布机制应用于事件包时应考虑的几个问题。它还演示了在使用PUBLISH for presence发布时如何处理这些问题。
Any future event package specification SHOULD include a discussion of its considerations for using PUBLISH. At a minimum those considerations SHOULD address the issues presented in this chapter, and MAY include additional considerations.
任何未来的事件包规范都应该包括对其使用PUBLISH的注意事项的讨论。这些考虑至少应涉及本章中提出的问题，并可能包括其他考虑。
The body of the PUBLISH request typically carries the published event state. Any application of the PUBLISH mechanism for a given event package MUST define what content type or types are expected in PUBLISH requests. Each event package MUST also describe the semantics associated with that content type, and MUST prescribe a default, mandatory to implement MIME type.
发布请求的主体通常携带已发布的事件状态。给定事件包的发布机制的任何应用程序都必须定义发布请求中预期的内容类型。每个事件包还必须描述与该内容类型相关联的语义，并且必须规定一个默认的、强制的MIME类型。
This document defines the semantics of the presence publication requests (event package "presence") when the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) [6] is used. A PUA that uses PUBLISH to publish presence state to the PA MUST support the PIDF presence format. It MAY support other formats.
本文档定义了使用公共状态概要文件（CPP）状态信息数据格式（PIDF）[6]时状态发布请求（事件包“状态”）的语义。使用发布将状态发布到PA的PUA必须支持PIDF状态格式。它可能支持其他格式。
The response to a PUBLISH request indicates whether the request was successful or not. In general, the body of such a response will be empty unless the event package defines explicit meaning for such a body.
对发布请求的响应指示该请求是否成功。通常，除非事件包定义了此类响应的明确含义，否则此类响应的主体将为空。
There is no such meaning for the body of a response to a presence publication.
对状态出版物的响应主体没有这样的含义。
For some event packages, the underlying model is that of a single entity responsible for aggregating event state (ESC), and multiple sources, out of which only some may be using the PUBLISH mechanism.
对于某些事件包，底层模型是负责聚合事件状态（ESC）的单个实体和多个源的模型，其中只有一些可能正在使用发布机制。
Note that sources for event state other than those using the PUBLISH mechanism are explicitly allowed. However, it is beyond the scope of this document to define such interfaces.
请注意，明确允许使用发布机制以外的事件状态源。但是，定义此类接口超出了本文档的范围。
Event packages that make use of the PUBLISH mechanism SHOULD describe whether this model for event state publication is applicable, and MAY describe specific mechanisms used for aggregating publications from multiple sources.
使用发布机制的事件包应该描述此事件状态发布模型是否适用，并且可以描述用于聚合来自多个源的发布的特定机制。
For presence, a PUA can publish presence state for just a subset of the tuples that may be composited into the presence document that watchers receive in a NOTIFY. The mechanism by which the ESC aggregates this information is a matter of local policy and out of the scope of this specification.
对于状态，PUA可以只发布元组的一个子集的状态，元组可以合成到观察者在通知中接收的状态文档中。ESC收集这些信息的机制是当地政策的问题，不在本规范的范围内。
For some event packages, there exists a natural decomposition of event state into segments. Each segment is defined as one of potentially many identifiable sections in the published event state. Any event package whose content type supports such segmentation of event state, SHOULD describe the way in which these event state segments are identified by the ESC.
对于某些事件包，存在事件状态到段的自然分解。每个段定义为已发布事件状态中可能存在的多个可识别段之一。任何内容类型支持事件状态分段的事件包，都应描述ESC识别这些事件状态分段的方式。
In presence publication, the EPA MUST keep the "id" attributes of tuples consistent in the context of an entity-tag. If a publication modifies the contents of a tuple, that tuple MUST maintain its original "id". The ESC will interpret each tuple in the context of the entity-tag with which the request arrived. A tuple whose "id" is missing compared to the original publication will be considered as being removed. Similarly, a tuple is interpreted as being added if its "id" attribute is one that the original publication did not contain.
在存在发布中，EPA必须在实体标记的上下文中保持元组的“id”属性一致。如果发布修改元组的内容，该元组必须保持其原始“id”。ESC将在请求到达的实体标记的上下文中解释每个元组。与原始发布相比，缺少“id”的元组将被视为已删除。类似地，如果元组的“id”属性是原始发布不包含的属性，则元组被解释为已添加。
Controlling the rate of publication is discussed in Section 9. Individual event packages MAY in turn define recommendations (SHOULD or MUST strength) on absolute maximum rates at which publications are allowed to be generated by a single EPA.
第9节讨论了控制出版速度。个别事件包可以反过来定义关于单个EPA允许生成出版物的绝对最大速率的建议（应该或必须强度）。
There are no rate limiting recommendations for presence publication.
目前还没有针对在线发布的速率限制建议。
This section describes the extensions required for event publication in SIP.
本节描述SIP中事件发布所需的扩展。
"PUBLISH" is added to the definition of the element "Method" in the SIP message grammar. As with all other SIP methods, the method name is case sensitive. PUBLISH is used to publish event state to an entity responsible for compositing this event state.
“发布”添加到SIP消息语法中元素“方法”的定义中。与所有其他SIP方法一样，方法名称区分大小写。发布用于将事件状态发布到负责合成此事件状态的实体。
Table 2 and Table 3 extend Tables 2 and 3 of RFC 3261 [4] by adding an additional column, defining the header fields that can be used in PUBLISH requests and responses. The keys in these tables are specified in Section 20 of RFC 3261 [4].
表2和表3扩展了RFC 3261[4]的表2和表3，增加了一列，定义了可用于发布请求和响应的标题字段。RFC 3261[4]第20节规定了这些表中的键。
+---------------------+---------+---------+
| Header Field | where | PUBLISH |
+---------------------+---------+---------+
| Accept | R | o |
| Accept | 2xx | - |
| Accept | 415 | m* |
| Accept-Encoding | R | o |
| Accept-Encoding | 2xx | - |
| Accept-Encoding | 415 | m* |
| Accept-Language | R | o |
| Accept-Language | 2xx | - |
| Accept-Language | 415 | m* |
| Alert-Info | | - |
| Allow | R | o |
| Allow | r | o |
| Allow | 405 | m |
| Allow-Events | R | o |
| Allow-Events | 489 | m |
| Authentication-Info | 2xx | o |
| Authorization | R | o |
| Call-ID | c | m |
| Call-Info | | o |
| Contact | R | - |
| Contact | 1xx | - |
| Contact | 2xx | - |
| Contact | 3xx | o |
| Contact | 485 | o |
| Content-Disposition | | o |
| Content-Encoding | | o |
| Content-Language | | o |
| Content-Length | | t |
| Content-Type | | * |
| CSeq | c | m |
| Date | | o |
| Event | R | m |
| Error-Info | 300-699 | o |
| Expires | | o |
| Expires | 2xx | m |
| From | c | m |
| In-Reply-To | R | - |
| Max-Forwards | R | m |
| Min-Expires | 423 | m |
| MIME-Version | | o |
| Organization | | o |
+---------------------+---------+---------+
+---------------------+---------+---------+
| Header Field | where | PUBLISH |
+---------------------+---------+---------+
| Accept | R | o |
| Accept | 2xx | - |
| Accept | 415 | m* |
| Accept-Encoding | R | o |
| Accept-Encoding | 2xx | - |
| Accept-Encoding | 415 | m* |
| Accept-Language | R | o |
| Accept-Language | 2xx | - |
| Accept-Language | 415 | m* |
| Alert-Info | | - |
| Allow | R | o |
| Allow | r | o |
| Allow | 405 | m |
| Allow-Events | R | o |
| Allow-Events | 489 | m |
| Authentication-Info | 2xx | o |
| Authorization | R | o |
| Call-ID | c | m |
| Call-Info | | o |
| Contact | R | - |
| Contact | 1xx | - |
| Contact | 2xx | - |
| Contact | 3xx | o |
| Contact | 485 | o |
| Content-Disposition | | o |
| Content-Encoding | | o |
| Content-Language | | o |
| Content-Length | | t |
| Content-Type | | * |
| CSeq | c | m |
| Date | | o |
| Event | R | m |
| Error-Info | 300-699 | o |
| Expires | | o |
| Expires | 2xx | m |
| From | c | m |
| In-Reply-To | R | - |
| Max-Forwards | R | m |
| Min-Expires | 423 | m |
| MIME-Version | | o |
| Organization | | o |
+---------------------+---------+---------+
Table 2: Summary of header fields, A--O
表2：标题字段摘要，A--O
+---------------------+-----------------+---------+
| Header Field | where | PUBLISH |
+---------------------+-----------------+---------+
| Priority | R | o |
| Proxy-Authenticate | 407 | m |
| Proxy-Authenticate | 401 | o |
| Proxy-Authorization | R | o |
| Proxy-Require | R | o |
| Record-Route | | - |
| Reply-To | | - |
| Require | | o |
| Retry-After | 404,413,480,486 | o |
| Retry-After | 500,503 | o |
| Retry-After | 600,603 | o |
| Route | R | c |
| Server | r | o |
| Subject | R | o |
| Supported | R | o |
| Supported | 2xx | o |
| Timestamp | | o |
| To | c(1) | m |
| Unsupported | 420 | o |
| User-Agent | | o |
| Via | R | m |
| Via | rc | m |
| Warning | r | o |
| WWW-Authenticate | 401 | m |
| WWW-Authenticate | 407 | o |
+---------------------+-----------------+---------+
+---------------------+-----------------+---------+
| Header Field | where | PUBLISH |
+---------------------+-----------------+---------+
| Priority | R | o |
| Proxy-Authenticate | 407 | m |
| Proxy-Authenticate | 401 | o |
| Proxy-Authorization | R | o |
| Proxy-Require | R | o |
| Record-Route | | - |
| Reply-To | | - |
| Require | | o |
| Retry-After | 404,413,480,486 | o |
| Retry-After | 500,503 | o |
| Retry-After | 600,603 | o |
| Route | R | c |
| Server | r | o |
| Subject | R | o |
| Supported | R | o |
| Supported | 2xx | o |
| Timestamp | | o |
| To | c(1) | m |
| Unsupported | 420 | o |
| User-Agent | | o |
| Via | R | m |
| Via | rc | m |
| Warning | r | o |
| WWW-Authenticate | 401 | m |
| WWW-Authenticate | 407 | o |
+---------------------+-----------------+---------+
Table 3: Summary of header fields, P--Z
表3：标题字段摘要，P--Z
The 412 (Conditional Request Failed) response is added to the "Client-Error" header field definition. 412 (Conditional Request Failed) is used to indicate that the precondition given for the request has failed.
412（条件请求失败）响应被添加到“客户端错误”头字段定义中。412（条件请求失败）用于指示为请求提供的先决条件已失败。
Table 4, Table 5, and Table 6 expand on Table 3 in SIP [4], as amended by the changes in Section 11.1.
表4、表5和表6扩展了SIP[4]中的表3，并根据第11.1节中的变更进行了修订。
+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | ACK | BYE | CAN | INF | INV |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag | 2xx | | - | - | - | - | - |
| SIP-If-Match | R | | - | - | - | - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+
+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | ACK | BYE | CAN | INF | INV |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag | 2xx | | - | - | - | - | - |
| SIP-If-Match | R | | - | - | - | - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+
Table 4: Summary of header fields, P--Z
表4：标题字段摘要，P--Z
+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | NOT | OPT | PRA | REG | SUB |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag | 2xx | | - | - | - | - | - |
| SIP-If-Match | R | | - | - | - | - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+
+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | NOT | OPT | PRA | REG | SUB |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag | 2xx | | - | - | - | - | - |
| SIP-If-Match | R | | - | - | - | - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+
Table 5: Summary of header fields, P--Z
表5：标题字段摘要，P--Z
+--------------+-------+-------+-----+-----+-----+---------+
| Header Field | where | proxy | UPD | MSG | REF | PUBLISH |
+--------------+-------+-------+-----+-----+-----+---------+
| SIP-ETag | 2xx | | - | - | - | m |
| SIP-If-Match | R | | - | - | - | o |
+--------------+-------+-------+-----+-----+-----+---------+
+--------------+-------+-------+-----+-----+-----+---------+
| Header Field | where | proxy | UPD | MSG | REF | PUBLISH |
+--------------+-------+-------+-----+-----+-----+---------+
| SIP-ETag | 2xx | | - | - | - | m |
| SIP-If-Match | R | | - | - | - | o |
+--------------+-------+-------+-----+-----+-----+---------+
Table 6: Summary of header fields, P--Z
表6：标题字段摘要，P--Z
SIP-ETag is added to the definition of the element "general-header" in the SIP message grammar. Usage of this header is described in Section 4 and Section 6.
SIP ETag被添加到SIP消息语法中元素“general header”的定义中。第4节和第6节介绍了此标题的用法。
SIP-If-Match is added to the definition of the element "general-header" in the SIP message grammar. Usage of this header is described in Section 4 and Section 6.
SIP If Match被添加到SIP消息语法中元素“general header”的定义中。第4节和第6节介绍了此标题的用法。
This section describes the syntax extensions required for event publication in SIP. The formal syntax definitions described in this section are expressed in the Augmented BNF [7] format used in SIP [4], and contain references to elements defined therein.
本节描述SIP中事件发布所需的语法扩展。本节中描述的正式语法定义以SIP[4]中使用的扩充BNF[7]格式表示，并包含对其中定义元素的引用。
PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH in caps.
extension-method = PUBLISHm / token
SIP-ETag = "SIP-ETag" HCOLON entity-tag
SIP-If-Match = "SIP-If-Match" HCOLON entity-tag
entity-tag = token
PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH in caps.
extension-method = PUBLISHm / token
SIP-ETag = "SIP-ETag" HCOLON entity-tag
SIP-If-Match = "SIP-If-Match" HCOLON entity-tag
entity-tag = token
This document registers a new method name, a new response code and two new header field names.
该文档注册了一个新的方法名、一个新的响应代码和两个新的标题字段名。
This document registers a new SIP method, defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
本文档注册了一个新的SIP方法，该方法由以下信息定义，已添加到下面的方法和响应代码子注册表中http://www.iana.org/assignments/sip-parameters.
Method Name: PUBLISH Reference: [RFC3903]
方法名称：发布引用：[RFC3903]
This document registers a new response code. This response code is defined by the following information, which has been 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: 412 Default Reason Phrase: Conditional Request Failed
响应代码：412默认原因短语：条件请求失败
This document registers two new SIP header field names. These headers are defined by the following information, which has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
本文档注册了两个新的SIP头字段名。这些标头由以下信息定义，这些信息已添加到下的标头子注册表中http://www.iana.org/assignments/sip-parameters.
Header Name: SIP-ETag Compact Form: (none)
标题名称：SIP ETag压缩格式：（无）
Header Name: SIP-If-Match Compact Form: (none)
标题名称：SIP如果匹配压缩格式：（无）
Since event state may be considered sensitive information, the ESC should have the ability to selectively accept publications from authorized sources only, based on the identity of the EPA.
由于事件状态可能被视为敏感信息，ESC应能够根据EPA的身份，有选择地仅接受授权来源的出版物。
The state agent SHOULD authenticate the EPA, and SHOULD apply its authorization policies (e.g., based on access control lists) to all requests. The composition model makes no assumptions that all input sources for an ESC are on the same network, or in the same administrative domain.
州代理应认证EPA，并应将其授权策略（例如，基于访问控制列表）应用于所有请求。组合模型不假设ESC的所有输入源位于同一网络或同一管理域中。
ESCs and EPAs MUST implement Digest for authenticating PUBLISH requests, as defined in RFC 3261 [4]. The exact methods for creating and manipulating access control policies in the ESC are outside the scope of this document.
ESC和EPA必须实现RFC 3261[4]中定义的发布请求认证摘要。在ESC中创建和操作访问控制策略的确切方法不在本文档范围内。
The creation of state at the ESC upon receipt of a PUBLISH request can be used by attackers to consume resources on a victim's machine, possibly rendering it unusable.
攻击者可利用收到发布请求后在ESC处创建的状态来消耗受害者机器上的资源，可能使其无法使用。
To reduce the chances of such an attack, implementations of ESCs SHOULD require authentication of PUBLISH requests. Implementations MUST support Digest authentication, as defined in RFC 3261 [4].
为了减少此类攻击的机会，ESC的实现应该要求对发布请求进行身份验证。实现必须支持摘要身份验证，如RFC 3261[4]中所定义。
Also, the ESC SHOULD throttle incoming publications and the corresponding notifications resulting from the changes in event state. As a first step, careful selection of default minimum Expires header field values for the supported event packages at an ESC can help limit refreshes of event state.
此外，电子稳定控制系统还应限制由事件状态变化引起的传入发布和相应通知。作为第一步，在ESC上仔细选择支持的事件包的默认最小过期标头字段值有助于限制事件状态的刷新。
Additional throttling and debounce logic at the ESC is advisable to further reduce the notification traffic produced as a result of a PUBLISH request.
建议在ESC处增加节流和去盎司逻辑，以进一步减少由于发布请求而产生的通知流量。
Replaying a PUBLISH request can have detrimental effects. An attacker may be able to perform any event state publication it witnessed being performed at some point in the past, by replaying that PUBLISH request. Among other things, such a replay message may
重播发布请求可能会产生有害影响。通过重播发布请求，攻击者可能能够执行其在过去某个时刻目睹的任何事件状态发布。除其他事项外，这样的重播消息可以
be used to spoof old event state information, although a versioning mechanism, e.g., a timestamp, in the state information may help mitigate such an attack.
用于欺骗旧事件状态信息，尽管状态信息中的版本控制机制（例如时间戳）可能有助于缓解此类攻击。
To prevent replay attacks, implementations MUST support Digest authentication with replay protection, as defined in RFC 3261 [4]. Further mechanisms for countering replay attacks are discussed in SIP [4].
为了防止重播攻击，实现必须支持具有重播保护的摘要身份验证，如RFC 3261[4]中所定义。SIP[4]中讨论了对抗重放攻击的进一步机制。
Even with authentication, man-in-the-middle attacks using PUBLISH may be used to install arbitrary event state information, modify or remove existing event state information in publications, or even remove event state altogether at an ESC.
即使使用身份验证，使用PUBLISH的中间人攻击也可用于安装任意事件状态信息、修改或删除发布中的现有事件状态信息，甚至在ESC上完全删除事件状态。
To prevent such attacks, implementations SHOULD, at a minimum, provide integrity protection across the To, From, Event, SIP-If-Match, Route, and Expires header fields and the bodies of PUBLISH requests.
为防止此类攻击，实现至少应跨To、From、Event、SIP If Match、Route和EXIRES头字段以及发布请求主体提供完整性保护。
If the ESC receives event state in a PUBLISH request which is integrity protected using a security association that is not with the ESC (e.g., integrity protection is applied end-to-end, from publisher to subscriber), the state agent coupled with the ESC MUST NOT modify the event state before exposing it to the subscribers of this event state in NOTIFY requests. This is to preserve the end-to-end integrity of the event state.
如果ESC在发布请求中接收到事件状态，该事件状态使用与ESC无关的安全关联进行完整性保护（例如，从发布服务器到订阅服务器端到端应用完整性保护），与ESC耦合的状态代理在NOTIFY请求中将事件状态公开给此事件状态的订阅者之前，不得修改事件状态。这是为了保持事件状态的端到端完整性。
For integrity protection, ESCs MUST implement TLS [8], and MUST support both mutual and one-way authentication, and MUST also support the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs MAY support S/MIME [9] for integrity protection, as defined in SIP [4].
对于完整性保护，ESC必须实现TLS[8]，必须支持双向和单向身份验证，还必须支持SIP[4]中定义的SIPS URI方案。EPA应能够启动TLS，并应支持SIPS URI方案。ESC和EPA可能支持S/MIME[9]以进行完整性保护，如SIP[4]中所定义。
The state information contained in a PUBLISH message may potentially contain sensitive information. Implementations MAY encrypt such information to ensure confidentiality.
发布消息中包含的状态信息可能包含敏感信息。实施可能会加密此类信息以确保机密性。
For providing confidentiality, ESCs MUST implement TLS [8], MUST support both mutual and one-way authentication, and MUST also support the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs MAY support S/MIME [9] for encryption of event state information, as defined in SIP [4].
为了提供机密性，ESC必须实现TLS[8]，必须支持双向和单向身份验证，还必须支持SIP[4]中定义的SIPS URI方案。EPA应能够启动TLS，并应支持SIPS URI方案。ESCs和EPA可能支持S/MIME[9]对事件状态信息进行加密，如SIP[4]中所定义。
This section shows an example of using the PUBLISH method for publishing a presence document from a presence user agent to a presence agent. The watcher in this example is subscribing to the presentity's presence information from the PA. The PUA may also SUBSCRIBE to its own presence to see the composite presence state exposed by the PA. This is an optional but likely step for the PUA, and is not shown in this example.
本节显示了使用PUBLISH方法将状态文档从状态用户代理发布到状态代理的示例。本示例中的观察者从PA订阅存在实体的存在信息。PUA也可以订阅其自身的存在以查看PA公开的复合存在状态。这是PUA的可选但可能的步骤，本示例中未显示。
When the value of the Content-Length header field is "..." this means that the value should be whatever the computed length of the body is.
当内容长度标题字段的值为“…”时，这意味着该值应为正文的计算长度。
PUA PA WATCHER
(EPA) (ESC)
| | |
| | <---- M1: SUBSCRIBE --- |
| | |
| | ----- M2: 200 OK -----> |
| | |
| | ----- M3: NOTIFY -----> |
| | |
| | <---- M4: 200 OK ------ |
| | |
| | |
| ---- M5: PUBLISH ---> | |
| | |
| <--- M6: 200 OK ---- | |
| | |
| | ----- M7: NOTIFY -----> |
| | |
| | <---- M8: 200 OK ------ |
| | |
| ---- M9: PUBLISH ---> | |
| | |
| <--- M10: 200 OK --- | |
| | |
| | |
| --- M11: PUBLISH ---> | |
| | |
| <-- M12: 200 OK ---- | |
| | |
| | ----- M13: NOTIFY ----> |
| | |
| | <---- M14: 200 OK ----- |
| | |
PUA PA WATCHER
(EPA) (ESC)
| | |
| | <---- M1: SUBSCRIBE --- |
| | |
| | ----- M2: 200 OK -----> |
| | |
| | ----- M3: NOTIFY -----> |
| | |
| | <---- M4: 200 OK ------ |
| | |
| | |
| ---- M5: PUBLISH ---> | |
| | |
| <--- M6: 200 OK ---- | |
| | |
| | ----- M7: NOTIFY -----> |
| | |
| | <---- M8: 200 OK ------ |
| | |
| ---- M9: PUBLISH ---> | |
| | |
| <--- M10: 200 OK --- | |
| | |
| | |
| --- M11: PUBLISH ---> | |
| | |
| <-- M12: 200 OK ---- | |
| | |
| | ----- M13: NOTIFY ----> |
| | |
| | <---- M14: 200 OK ----- |
| | |
Message flow:
消息流：
M1: The watcher initiates a new subscription to the presentity@example.com's presence agent.
M1：观察者发起新的订阅presentity@example.com的出席代理人。
SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Contact: sip:user@host.example.com
Content-Length: 0
SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Contact: sip:user@host.example.com
Content-Length: 0
M2: The presence agent for presentity@example.com processes the subscription request and creates a new subscription. A 200 (OK) response is sent to confirm the subscription.
M2：的存在代理presentity@example.com处理订阅请求并创建新订阅。发送200（确定）响应以确认订阅。
SIP/2.0 200 OK
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:presentity@example.com>;tag=abcd1234
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Contact: sip:pa.example.com
Expires: 3600
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:presentity@example.com>;tag=abcd1234
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Contact: sip:pa.example.com
Expires: 3600
Content-Length: 0
M3: In order to complete the process, the presence agent sends the watcher a NOTIFY with the current presence state of the presentity.
M3：为了完成该过程，状态代理向观察者发送一个通知，告知存在实体的当前状态。
NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 1 NOTIFY Max-Forwards: 70 Event: presence Subscription-State: active; expires=3599 Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：user@host.example.comSIP/2.0 Via:SIP/2.0/UDP pa.example.com；分支=z9hG4bK8sdf2至：<sip:watcher@example.com>;标签=12341234发件人：<sip:presentity@example.com>;标签=abcd1234呼叫ID:12345678@host.example.comCSeq:1通知最大转发：70事件：状态订阅状态：活动；expires=3599联系人：sip:pa.example.com内容类型：应用程序/pidf+xml内容长度：。。。
[PIDF document]
[PIDF文件]
M4: The watcher confirms receipt of the NOTIFY request.
M4：观察者确认收到通知请求。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 1 NOTIFY
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 1 NOTIFY
M5: A presence user agent (acting for the presentity) initiates a PUBLISH request to the presence agent in order to update it with new presence information. The Expires header field indicates the suggested duration for this event soft state.
M5：状态用户代理（代表状态实体）向状态代理发起发布请求，以便用新的状态信息更新它。Expires标头字段指示此事件软状态的建议持续时间。
PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ...
发布sip：presentity@example.comSIP/2.0 Via:SIP/2.0/UDP pua.example.com；分支=z9hG4bK652hsge至：<sip:presentity@example.com>发件人：<sip:presentity@example.com>;tag=1234wxyz呼叫ID:81818181@pua.example.comCSeq:1发布最大转发：70过期：3600事件：状态内容类型：应用程序/pidf+xml内容长度：。。。
[Published PIDF document]
[已出版的PIDF文件]
M6: The presence agent receives, and accepts the presence publication. The published data is incorporated into the presentity's presence information.
M6：状态代理接收并接受状态发布。发布的数据被合并到实体的状态信息中。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=1a2b3c4d
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: dx200xyz
Expires: 1800
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=1a2b3c4d
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: dx200xyz
Expires: 1800
M7: The presence agent determines that a reportable change has been made to the presentity's presence information, and sends a new presence notification to the watcher.
M7：状态代理确定对状态实体的状态信息进行了可报告的更改，并向观察者发送新的状态通知。
NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Max-Forwards: 70 Event: presence Subscription-State: active; expires=3400 Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：user@host.example.comSIP/2.0 Via:SIP/2.0/UDP pa.example.com；分支=z9hG4bK4cd42a至：<sip:watcher@example.com>;标签=12341234发件人：<sip:presentity@example.com>;标签=abcd1234呼叫ID:12345678@host.example.comCSeq:2通知最大转发：70事件：状态订阅状态：活动；expires=3400联系人：sip:pa.example.com内容类型：应用程序/pidf+xml内容长度：。。。
[New PIDF document]
[新的PIDF文件]
M8: The watcher confirms receipt of the NOTIFY request.
M8：观察者确认收到通知请求。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0
M9: The PUA determines that the event state it previously published is about to expire, and refreshes that event state.
M9:PUA确定其先前发布的事件状态即将过期，并刷新该事件状态。
PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: dx200xyz
Expires: 3600
Event: presence
Content-Length: 0
PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: dx200xyz
Expires: 3600
Event: presence
Content-Length: 0
M10: The presence agent receives, and accepts the publication refresh. The timers regarding the expiration of the specific event state identified by the entity-tag are updated. As always, the ESC returns an entity-tag in the response to a successful PUBLISH. Note that no actual state change has occurred, so the watchers will receive no NOTIFYs.
M10：状态代理接收并接受发布刷新。更新实体标记标识的特定事件状态过期的计时器。与往常一样，ESC在对成功发布的响应中返回一个实体标记。请注意，没有发生实际的状态更改，因此观察者将不会收到NOTIFY。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=2affde434
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: kwj449x
Expires: 1800
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=2affde434
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: kwj449x
Expires: 1800
M11: The PUA of the presentity detects a change in the user's presence state. It initiates a PUBLISH request to the presence agent to modify the published presence information with the recent change.
M11：存在实体的PUA检测到用户存在状态的变化。它向状态代理发起发布请求，以使用最近的更改修改已发布的状态信息。
PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=54321mm Call-ID: 5566778@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 SIP-If-Match: kwj449x Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ...
发布sip：presentity@example.comSIP/2.0 Via:SIP/2.0/UDP pua.example.com；分支=z9hG4bKcdad2至：<sip:presentity@example.com>发件人：<sip:presentity@example.com>;标签=54321mm呼叫ID：5566778@pua.example.comCSeq:1发布最大转发：70 SIP如果匹配：kwj449x过期：3600事件：状态内容类型：应用程序/pidf+xml内容长度：。。。
[Published PIDF Document]
[已出版的PIDF文件]
M12: The presence agent receives, and accepts the modifying publication. The published data is incorporated into the presentity's presence information, updating the previous publication from the same PUA.
M12：状态代理接收并接受修改发布。发布的数据被合并到实体的状态信息中，更新来自同一PUA的先前发布。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=effe22aa
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: qwi982ks
Expires: 3600
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=effe22aa
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: qwi982ks
Expires: 3600
M13: The presence agent determines that a reportable change has been made to the presentity's presence document, and sends a new presence notification to all active subscriptions.
M13：状态代理确定对状态实体的状态文档进行了可报告的更改，并向所有活动订阅发送新的状态通知。
NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Max-Forwards: 70 Event: presence Subscription-State: active; expires=3400 Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：user@host.example.comSIP/2.0 Via:SIP/2.0/UDP pa.example.com；分支=z9hG4bK32defd3至：<sip:watcher@example.com>;标签=12341234发件人：<sip:presentity@example.com>;标签=abcd1234呼叫ID:12345678@host.example.comCSeq:2通知最大转发：70事件：状态订阅状态：活动；expires=3400联系人：sip:pa.example.com内容类型：应用程序/pidf+xml内容长度：。。。
[New PIDF document]
[新的PIDF文件]
M14: The watcher confirms receipt of the NOTIFY request.
M14：观察者确认收到通知请求。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
;received=192.0.2.3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
;received=192.0.2.3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0
The original contributors to this specification are:
本规范的原始贡献者包括：
Ben Campbell Estacado Systems
Ben Campbell Estacado系统公司
Sean Olson Microsoft
肖恩奥尔森微软
Jon Peterson Neustar, Inc.
乔恩·彼得森纽斯达公司。
Jonathan Rosenberg dynamicsoft
乔纳森·罗森伯格动态软件公司
Brian Stucker Nortel Networks, Inc.
布莱恩·斯图克北电网络公司。
The authors would like to thank the SIMPLE Working Group for their collective effort, and specifically the following people for their review and support of this work: Henning Schulzrinne, Paul Kyzivat, Hisham Khartabil, George Foti, Keith Drage, Samir Srivastava, Arun Kumar, Adam Roach, Pekka Pessi, Kai Wang, Cullen Jennings, Mikko Lonnfors, Eva-Maria Leppanen, Ernst Horvath, Thanos Diacakis, Oded Cnaan, Rohan Mahy, and Dean Willis.
作者要感谢简单工作组的集体努力，特别是以下人员对这项工作的审查和支持：Henning Schulzrinne、Paul Kyzivat、Hisham Khartabil、George Foti、Keith Drage、Samir Srivastava、Arun Kumar、Adam Roach、Pekka Pessi、Kai Wang、Cullen Jennings、Mikko Lonnfors、，伊娃·玛丽亚·莱普潘、恩斯特·霍瓦思、塔诺斯·迪亚卡基斯、奥德·卡南、罗汉·马伊和迪安·威利斯。
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[2] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[2] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[3] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[3] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[6] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[8] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[9] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[9] Ramsdell，B.，编辑，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[10] Campbell, B., "SIMPLE Presence Publication Requirements", Work in Progress, February 2003.
[10] 坎贝尔，B.，“简单存在出版物要求”，正在进行的工作，2003年2月。
[11] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[11] Mahy，R.，“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[12] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[13] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
Author's Address
作者地址
Aki Niemi (editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
Aki Niemi（编辑）芬兰芬兰诺基亚集团407号诺基亚邮政信箱00045
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。