[要約] RFC 3903は、SIP拡張機能であるイベント状態の公開に関するものであり、イベントの状態をSIPメッセージで公開するための仕様を提供しています。このRFCの目的は、SIPベースのアプリケーションでイベントの状態を効果的に共有するための標準化を促進することです。
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）The Internet Society（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
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]による[プレゼンス状態]による具体的なフレームワークの具体的な使用法を定義します。[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]で定義されている適切なイベントパッケージが存在するイベント状態の公開をサポートするために拡張できます。たとえば、メッセージ待機の表示[11]のSIPイベントのアプリケーションは、パブリッシュメカニズムを使用して、ユーザーエージェントのセット全体でボイスメールボックスのステータスを収集することを選択する場合があります。そのようなアプリケーションのコンポジタは、この状態をイベントパッケージのサブスクライバーに収集して配布する責任があります。
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.
Event State Compositor（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の公開リクエストをESCに送信して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.
イベントハードステート：リソースの定常状態またはデフォルトのイベント状態。これは、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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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メソッドを公開します。パブリッシュは、ユーザーがユーザーに代わってこの状態を管理する別のエンティティで状態を作成、変更、および削除できるという点で、登録に似ています。公開リクエストに対処することは、購読リクエストのアドレス指定と同じです。公開リクエストのリクエスト-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 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にソフト状態を作成します。このイベントソフトステートは生涯にわたって定義されており、交渉された時間の後に期限切れになります。また、特定のイベントパッケージのリソースごとにプロビジョニングされているイベントハードステートがあります。このイベント状態は、常に存在するリソース状態を表しており、期限切れになりません。ESCは、パブリッシュメカニズムを通じて提供されるイベントソフトステートの不在、またはそれに加えて、イベントハードステートを使用する場合があります。このイベントのハード状態を設定するか、異なるイベント状態の集約に関する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のセクション8.1およびセクション17.1で説明されている一般的なUACの動作と同じです[4]。
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]で定義されたオプションリクエストを使用して、パブリッシュのサポートを調査することができます。オプションリクエストへの応答に「許可」ヘッダーフィールドに「公開」が存在することは、パブリッシュメソッドのサポートを示します。さらに、「Allow-Ivents」ヘッダーフィールドは、サポートされているイベントパッケージを示します。
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 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.
パブリッシュリクエストには連絡先ヘッダーフィールドが含まれている場合がありますが、公開リクエストに1つを含めることは、イベントの公開コンテキストでは意味がなく、ESCによって無視されます。EPAは、既存のダイアログ内で公開リクエストを送信する場合があります。その場合、リクエストは、そのダイアログに関連するメディアセッションまたはセッションのコンテキストで受信されます。
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は、以前のものまたは前のパブリッシュリクエストのESCから最終的な応答を受け取るまで、同じリクエストURIの新しい公開要求（再送信ではなく）を送信してはなりません。
Identification of published event state is provided by three pieces of information: Request-URI, event type, and (optionally) an entity-tag.
公開されたイベント状態の識別は、リクエスト-URI、イベントタイプ、および（オプションでは）エンティティタグの3つの情報によって提供されます。
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-TETAGヘッダーフィールドに返します。
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.
以前に公開されたイベント状態を更新する場合、公開リクエストには、リクエストが更新、変更、または削除されている特定のイベントを識別する1つのSIP-IFマッチヘッダーフィールドを含める必要があります。このヘッダーフィールドには、以前の出版物への応答のSIP-TETAGヘッダーフィールドのESCによって返された単一のエンティティタグを含める必要があります。
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.
表1に記載されているように、ボディの存在とSIP-IFマッチヘッダーフィールドは、リクエストが実行されている特定の操作を決定します。
+-----------+-------+---------------+---------------+
| 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によって公開されているイベント状態がすでにある場合があります（同じ記録アドレスについて）。その状態は最初の出版物の影響を受けません。「更新」出版物は、以前の出版物の生涯を更新しますが、「Modify」出版物は以前の出版物のイベント状態を変更します。「削除」出版物は、イベント状態の即時削除を要求します。これらの操作については、以下のセクションで詳しく説明します。
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によって作成され、リクエストのイベントヘッダーフィールドに示されたイベントパッケージのソフトステートを確立し、リクエストのリクエスト-URIのアドレスにバインドされるESCに送信される公開要求です。
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マッチヘッダーフィールドを含めてはなりません。ただし、EPAが適切なローカルに保存されたエンティティタグがまだ有効であると予想される場合、最初に最初の出版物を提出する代わりに、セクション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.
最初の公開要求には、単一の有効期限が切れている場合があります。この値は、イベント州の出版物の提案された寿命を示しています。
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は、出版物の提案された寿命を減らすことができますが、決して拡張しません。ヘッダーフィールドの有効期限が存在しない場合、EPAはESCが選択するという要望を示しています。初期公開に対する2xx応答でヘッダーフィールドの有効期限は、出版物がアクティブのままである実際の期間を示します。この生涯を超える前にリフレッシュしない限り、出版物は期限切れになります。
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マッチヘッダーフィールドを含むパブリッシュリクエストを作成する必要があります。
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マッチヘッダーフィールドは、以前の出版物によって確立された特定のイベント状態を更新するための公開要求を条件としています。エンティティタグが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-TETAGヘッダーフィールドが含まれます。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.
出版物の更新には、ヘッダーフィールドの有効期限が切れる単一のものが含まれている場合があります。この値は、イベント状態の提案された寿命を示しています。
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は、出版物のリフレッシュの提案された寿命を下げることができますが、決して拡張することはありません。ヘッダーフィールドの有効期限が存在しない場合、EPAはESCが選択するという要望を示しています。出版物への2xx応答でヘッダーフィールドの有効期限は、出版物がアクティブのままである実際の期間を示します。
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マッチヘッダーフィールドを含む公開要求を作成する必要があります。イベント状態を変更する公開リクエストには、変更されたイベント状態を含む本体が含まれている必要があります。
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-TETAGヘッダーフィールドが含まれます。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.
修正パブリックリクエストには、ヘッダーフィールドが有効期限が切れる場合があります。この値は、イベント州の出版物の提案された寿命を示しています。
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は、出版物の提案された寿命を減らすことができますが、決して拡張しません。ヘッダーフィールドの有効期限が存在しない場合、EPAはESCが選択するという要望を示しています。修正パブリッシュリクエストに対する2xx応答でヘッダーフィールドの有効期限は、出版物がアクティブのままである実際の期間を示しています。この生涯を超える前にリフレッシュしない限り、出版物は期限切れになります。
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マッチヘッダーフィールドを設定して、削除するイベント状態の出版物のエンティティタグを含めるように設定する必要があります。
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マッチヘッダーフィールドのない公開要求を実行する必要があります。また、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（間隔が短すぎる）応答を受け取った場合、ヘッダーフィールドの有効期限間隔を変更した後、Min-Expiresヘッダーフィールド内の有効期限間隔以上になると再試行する可能性があります。423（間隔が短すぎる）応答。
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.
Event State Compositor（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.
また、Request-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-IT-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マッチのヘッダーフィールドが含まれていない場合、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マッチヘッダーフィールドがある場合、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は、パブリッシュリクエストからヘッダーフィールド値の有効期限を取得します。
* If the request has an Expires header field, that value MUST be taken as the requested expiration.
* リクエストの有効期限がヘッダーフィールドを持っている場合、その値は要求された有効期限としてとらなければなりません。
* 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は、要求された有効期限間隔よりも有効期限が少ないことを選択できます。要求された有効期限間隔がゼロより大きく、ローカルに構成された最小値よりも少ない場合にのみ、ESCは423の応答（間隔が短すぎる）で出版物を拒否し、残りの手順をスキップできます。この応答には、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.
公開要求の処理はアトミックでなければなりません。処理が完了する前に内部エラー（バックエンドデータベースにアクセスできないなど）が発生する場合、出版物は成功する必要はなく、504（サーバータイムアウト）などの適切なエラー応答でESCが失敗する必要があります。最後のステップをスキップします。
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（OK）応答を返します。応答には、ESCによって選択された有効期限間隔を示す有効期限がヘッダーフィールドを含める必要があります。応答には、出版物を識別する単一のエンティティタグを含むSIP-TETAGヘッダーフィールドも含める必要があります。ESCは、成功した出版物ごとに新しいエンティティタグを生成し、そのイベント状態に関連する以前のエンティティタグを置き換える必要があります。生成されたエンティティタグは、その要求-RIに関連付けられているイベント状態に現在割り当てられている他のエンティティタグと一意でなければならず、そのリクエスト-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には、許容ヘッダーフィールドの許可メソッドのリストに「公開」を含める必要があります。また、サポートされているイベントヘッダーフィールドにサポートされているイベントパッケージをリストする必要があります。
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では、オリジンサーバーの場合はエンティティタグを返すことがオプションですが、パブリッシュでは、出版物を成功させるために常にエンティティタグを返すために必要です。
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プットであることです。これは、エンティティタグを使用したキャッシュ検証の機能のサブセットのみが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.
パブリッシュでのエンティティタグの使用法は類似しているが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つの方法は、正常に処理された出版物ごとに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レベルのプッシュバックを使用して、特定の出版トラフィックのソースを消すことです。特定のソースから出版物を押し戻すために、ESCはRFC 3261 [4]で定義されているように、503（サービスが利用できない）で公開要求に応答する場合があります。この応答には、出版物ソースが別の公開リクエストを送信するまで待つ必要があることを示す、再試行後のヘッダーフィールドを含める必要があります。
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.
このセクションでは、イベントパッケージにパブリッシュメカニズムを適用する際に考慮すべきいくつかの問題について説明します。また、Punsion for Presence Publicationを使用するときにこれらの問題がどのように処理されるかを示しています。
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.
将来のイベントパッケージ仕様には、パブリッシュを使用するための考慮事項の議論を含める必要があります。少なくとも、これらの考慮事項は、この章で提示されている問題に対処する必要があり、追加の考慮事項を含めることができます。
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）の共通プロファイル（CPP）の存在情報データ形式（PIDF）[6]が使用された場合、存在する出版物リクエスト（イベントパッケージ「存在」）のセマンティクスを定義します。Publish Publisk Presence Stateに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.
一部のイベントパッケージには、セグメントへのイベント状態の自然な分解が存在します。各セグメントは、公開されているイベント状態で潜在的に多く識別可能なセクションの1つとして定義されます。コンテンツタイプがイベント状態のセグメンテーションをサポートするイベントパッケージは、これらのイベント状態セグメントが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.
Presence Publicationでは、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 |
+---------------------+---------+---------+
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 |
+---------------------+-----------------+---------+
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は、セクション11.1の変更によって修正されたように、SIP [4]の表3に拡張します。
+--------------+-------+-------+-----+-----+-----+-----+-----+
| 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 | | - | - | - | - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+
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 |
+--------------+-------+-------+-----+-----+-----+---------+
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メッセージ文法の要素「一般的なヘッダー」の定義に追加されます。このヘッダーの使用については、セクション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メッセージ文法の要素「一般的なヘッダー」の定義に追加されます。このヘッダーの使用については、セクション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
This document registers a new method name, a new response code and two new header field names.
このドキュメントは、新しいメソッド名、新しい応答コード、2つの新しいヘッダーフィールド名を登録します。
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.
このドキュメントは、2つの新しいSIPヘッダーフィールド名を登録します。これらのヘッダーは、http://www.iana.org/assignments/sip-parametersに基づいてヘッダーサブレジストリに追加された次の情報によって定義されています。
Header Name: SIP-ETag Compact Form: (none) Header Name: SIP-If-Match Compact Form: (none)
ヘッダー名：SIP-ETAGコンパクトフォーム：（なし）ヘッダー名：SIP-if-if-matchコンパクトフォーム：（なし）
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のIDに基づいて、認可されたソースからのみ出版物を選択的に受け入れる能力を持つ必要があります。
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は、着信出版物と、イベント状態の変更に起因する対応する通知をスロットルする必要があります。最初のステップとして、デフォルトの最小値を慎重に選択すると、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.
認証があっても、パブリッシュを使用した中間の攻撃を使用して、任意のイベント状態情報をインストールしたり、出版物で既存のイベント状態情報を変更または削除したり、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.
このような攻撃を防ぐために、実装は、少なくとも、試合中、sip-if-match、ルート、および有効期限のあるヘッダーフィールドと公開リクエストの団体全体を介して、整合性保護を提供する必要があります。
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と組み合わせたものです。通知リクエストで、このイベント状態のサブスクライバーにさらされる前に、イベント状態を変更してはなりません。これは、イベント状態のエンドツーエンドの完全性を維持するためです。
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スキームをサポートする必要があります。SIP [4]で定義されているように、ESCとEPAはS/MIME [9]をサポートする可能性があります[9]。
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スキームをサポートする必要があります。SIP [4]で定義されているように、ESCとEPAは、イベント状態情報の暗号化をS/MIME [9]をサポートする場合があります。
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.
このセクションでは、プレゼンスユーザーエージェントからプレゼンスエージェントへのプレゼンスドキュメントを公開するためにパブリッシュメソッドを使用する例を示します。この例のウォッチャーは、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 ----- |
| | |
Message flow:
メッセージフロー：
M1: The watcher initiates a new subscription to the presentity@example.com's presence agent.
M1：Watcherは、gupressity@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
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（OK）応答が送信されます。
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: ...
[PIDF document]
[PIDFドキュメント]
M4: The watcher confirms receipt of the NOTIFY request.
M4：ウォッチャーは、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：プレゼンスユーザーエージェント（プレゼンテーションのために演技）は、新しいプレゼンス情報で更新するために、プレゼンスエージェントにパブリッシュリクエストを開始します。有効期限は、このイベントのソフトステートの提案期間を示します。
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: ...
[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
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: ...
[New PIDF document]
[新しいPIDFドキュメント]
M8: The watcher confirms receipt of the NOTIFY request.
M8：ウォッチャーは、Notifyリクエストの受領を確認します。
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
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はパブリッシュの成功への応答でエンティティタグを返します。実際の状態の変更は発生していないため、ウォッチャーは通知を受け取らないことに注意してください。
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: ...
[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
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: ...
[New PIDF document]
[新しいPIDFドキュメント]
M14: The watcher confirms receipt of the NOTIFY request.
M14：ウォッチャーはNotifyリクエストの受信を確認します。
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
ベン・キャンベル・エスタカド・システム
Sean Olson Microsoft
ショーン・オルソン・マイクロソフト
Jon Peterson Neustar, Inc.
Jon Peterson Neustar、Inc。
Jonathan Rosenberg dynamicsoft
ジョナサンローゼンバーグダイナミクスソフト
Brian Stucker Nortel Networks, Inc.
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.
著者は、シンプルなワーキンググループの集団的努力、特にこの作品のレビューとサポートについて次の人々に感謝したいと思います。ヘニングシュルツリンヌ、ポールキジバット、ヒシャムハルタビル、ジョージフォティ、キースドレイジ、サミールスリバスタヴァ、アルンクマール、Adam Roach、Pekka Pessi、Kai Wang、Cullen Jennings、Mikko Lonfors、Eva-Maria Leppanen、Ernst Horvath、Thanos Diacakis、Oded Cnaan、Rohan Mahy、Dean Willis。
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[2] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[2] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、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 2778、2000年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：SESSION INTIATION Protocol"、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.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年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.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[10] Campbell, B., "SIMPLE Presence Publication Requirements", Work in Progress, February 2003.
[10] Campbell、B。、「Simple Presencion Publication要件」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
Author's Address
著者の連絡先
Aki Niemi (editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
Aki niemi（編集者）Nokia P.O.Box 407 Nokia Group、Fin 00045 Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。