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
        
1. Introduction
1. 介绍

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节中设置的准则。本文档中描述的机制并非用于传输任意数据的通用机制,因为有更适合此目的的机制。

2. Definitions and Document Conventions
2. 定义和文件惯例

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.

本文档中使用缩进段落(如本段落)来提供附加信息和澄清文本。它们不包含规范协议行为的描述。

3. Overall Operation
3. 整体运作

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需要重新开始并重新发送其事件状态,而不引用以前的实体标记。

4. Constructing PUBLISH Requests
4. 构造发布请求

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对上一个请求的最终响应或上一个发布请求超时。

4.1. Identification of Published Event State
4.1. 已发布事件状态的标识

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发布的事件状态(对于相同的记录地址)。该状态不受初始发布的影响。“刷新”发布刷新以前发布的生存期,而“修改”发布修改以前发布的事件状态。“删除”发布请求立即删除事件状态。以下各节将更详细地描述这些操作。

4.2. Creating Initial Publication
4.2. 创建初始出版物

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标头字段指示发布将保持活动状态的实际持续时间。除非在超过此生存期之前刷新,否则发布将过期。

4.3. Refreshing Event State
4.3. 刷新事件状态

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.

发布刷新只会延长现有事件状态的过期时间。它不会以任何其他方式影响该事件状态。因此,刷新事件状态的发布请求不能有正文。

4.4. Modifying Event State
4.4. 修改事件状态

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标头字段指示发布将保持活动状态的实际持续时间。除非在超过此生存期之前刷新,否则发布将过期。

4.5. Removing Event State
4.5. 删除事件状态

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.

与事件状态刷新类似,删除事件状态只会影响事件状态的到期。因此,删除事件状态的发布请求不能包含正文。

5. Processing PUBLISH Responses
5. 处理发布响应

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标头字段中的过期间隔后重试发布。

6. Processing PUBLISH Requests
6. 处理发布请求

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以确定此请求是否