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
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
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.
この仕様は、このイベントの状態を合成し、[1]のフレームワークSIPイベントを通じて利害関係者に配布する責任があるエンティティへのユーザエージェントからイベント状態の出版のためのフレームワークを提供します。
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] PUBLISHメカニズムを使用してユーザーエージェントのセットにわたってボイスメールボックスの状態を収集することを選択するかもしれません。このようなアプリケーションでのコンポジターは、イベントパッケージの加入者に、この状態を収集し、配布する責任を負うことになります。
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.
イベント状態のパブリケーション内のPUBLISH機構を利用する各アプリケーションは、同様に、本書で説明されたメカニズムは、任意のデータの輸送のための汎用機構であることを意図されていないセクション10に設定ガイドラインに準拠する必要がありますこの目的のために、より良い最適メカニズムがあります。
In addition to the definitions of RFC 2778 [3], RFC 3265 [1], and RFC 3261 [4], this document introduces some new concepts:
RFC 2778の定義に加えて、[3]、RFC 3265 [1]、及びRFC 3261 [4]は、この文書は、いくつかの新しい概念が導入されています。
Event State: State information for a resource, associated with an event package and an address-of-record.
イベント状態：リソースの状態情報、イベントパッケージとアドレス・オブ・レコードに関連付けられています。
Event Publication Agent (EPA): The User Agent Client (UAC) that issues PUBLISH requests to publish event state.
イベント公開エージェント（EPA）：ユーザエージェントクライアント（UAC）の問題は、イベント状態を発行する要求を発行すること。
Event State Compositor (ESC): The User Agent Server (UAS) that processes PUBLISH requests, and is responsible for compositing event state into a complete, composite event state of a resource.
イベントステートコンポジ（ESC）：PUBLISHリクエストを処理し、リソースの完全な、複合イベント状態にイベント状態を合成する責任があるユーザエージェントサーバ（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にPUBLISHリクエストを送信するEPAの行為。
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.
イベントソフトステート：イベント状態はPUBLISHメカニズムを使用して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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
この文書では、イベント状態を発行するため、PUBLISH、新しいSIPメソッドを定義します。 PUBLISHそれは、ユーザーが作成、変更、およびユーザーに代わって、この状態を管理する別のエンティティの状態を削除することができますということでレジスタに似ています。 PUBLISHリクエストに対処するSUBSCRIBEリクエストに取り組むと同じです。 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）の役割です。 PUBLISHリクエストを処理するエンティティは、イベントステートコンポジ（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でソフト状態を作成リクエストを発行します。このイベントは柔らかい状態が定義された寿命を有し、後続のPUBLISHリクエストによってリフレッシュされる出版物を必要とする、時間のネゴシエート量の後に期限切れになります。また、特定のイベント・パッケージの各リソースのプロビジョニングイベント難しい状態があるかもしれません。このイベントの状態は常に存在しているリソースの状態を表しており、有効期限はありません。 ESCは、の非存在下でイベントハード状態を使用し、またはPUBLISH機構を介して設けられ、イベント柔らかい状態に加えてもよいです。このイベントハード状態を設定するか、別のイベント状態の集約に関する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.
PUBLISHリクエストのボディは、公表されたイベントの状態を運びます。すべての成功したPUBLISH要求に応答して、ESCは、エンティティタグの形式で出版物に識別子を割り当てます。この識別子は、その後、変更後続PUBLISHリクエストで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.
要求は、アドレスのレコードに関連付けられたイベントの状態を作成、変更、および削除PUBLISH。適切に認可された第三者は、特定のアドレスのレコードに代わって発行を行うことができます。
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].
注目されている場合を除き、PUBLISHリクエストとPUBLISH要求を送信するクライアントの動作の構成[4]セクション8.1およびRFC 3261のセクション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]で定義されたOPTIONS要求を使用してPUBLISHのサポートを探索してもよいです。 OPTIONS要求に応答して「許可」ヘッダフィールドに「PUBLISH」の存在は、PUBLISHメソッドに対するサポートを示します。また、「許可 - イベント」ヘッダフィールドは、サポートされているイベントパッケージを示します。
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.
OPTIONS要求をフォークすることが可能であることに注意してください、その結果、ESC以外のユーザーエージェントからの応答を返します。その場合には、適宜その特定のRequest-URIのために示されない可能性PUBLISHメソッドのサポート。
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.
PUBLISHリクエストは、ダイアログを確立しません。 UACは、RFC 3261のセクション8.1に記載されるように設定され、既存の経路[4]に基づいて、PUBLISHリクエストのRouteヘッダフィールドを含んでいてもよいです。 Record-Routeヘッダーフィールドは、PUBLISHリクエストやレスポンスでは意味を持たず、存在する場合無視しなければなりません。特に、UACは、PUBLISHリクエストに対する応答でRecord-Routeヘッダフィールドの有無に基づいて、新しいルートセットを作成してはいけません。
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.
PUBLISHリクエストは、Contactヘッダーフィールドが含まれていますが、PUBLISHリクエストの1を含めてイベント公開コンテキストでは意味がありませんし、ESCによって無視されるかもしれません。 EPAは、既存のダイアログ内PUBLISH要求を送信することができます。その場合には、要求は、そのダイアログに関連付けられた任意のメディアセッションまたはセッションのコンテキストで受信されます。
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.
禁止されていない既存のダイアログ内のPUBLISHリクエストを送っている間、それは一般的に期待される動作が発生しないことに注意してください。ダイアログのもう一方の端でも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.
彼らは以前のもののためのESCからの最終的な応答を受信しているか、以前のPUBLISHリクエストがタイムアウトするまでのEPAは、同じ要求URIのための新しいPUBLISHリクエスト（ない再送信）を送ってはいけません。
Identification of published event state is provided by three pieces of information: Request-URI, event type, and (optionally) an entity-tag.
Request-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.
PUBLISH要求のリクエスト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ヘッダフィールドを含まなければならないPUBLISH。このヘッダーフィールドは、以前の出版物への応答のSIP-ETagヘッダフィールドで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.
PUBLISHリクエストは、クライアントが公開したいイベントの状態が含まれている体を含んでいてもよいです。コンテンツのフォーマット及びセマンティクスは、イベントヘッダフィールドで識別されたイベントパッケージに依存しています。
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-Matchヘッダフィールドの存在は、要求が実行されている具体的な動作を決定します。
+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial | yes | no | > 0 |
| Refresh | no | yes | > 0 |
| Modify | yes | yes | > 0 |
| Remove | no | yes | 0 |
+-----------+-------+---------------+---------------+
Table 1: Publication Operations
表1：出版事業
An 'Initial' publication sets the initial event state for a particular EPA. There may, of course, already be event state published by other EPAs (for the same address-of-record). That state is unaffected by an initial publication. A 'Refresh' publication refreshes the lifetime of a previous publication, whereas a 'Modify' publication modifies the event state of a previous publication. A 'Remove' publication requests immediate removal of event state. These operations are described in more detail in the following sections.
「初期の」刊行物には、特定のEPAの初期イベント状態を設定します。もちろん、すでにイベント状態は（同じアドレス・オブ・レコードの）他のEPAであり、公開することができます。その状態は、初期の出版物による影響を受けません。 「変更」パブリケーションが以前出版のイベント状態を変更し、一方、「更新」出版物は、出版前のライフタイムをリフレッシュ。 「削除」を出版、イベント状態の即時削除を要求します。これらの操作は、以下のセクションで詳しく説明されています。
An initial publication is a PUBLISH request created by the EPA and sent to the ESC that establishes soft state for the event package indicated in the Event header field of the request, and bound to the address in the Request-URI of the request.
初期の出版物は、要求のリクエストURI内のアドレスにソフト要求のイベントヘッダフィールドで示されたイベントパッケージの状態、および結合を確立ESCにEPAによって作成され、送信されたPUBLISHリクエストです。
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ヘッダフィールドを含んではならないPUBLISH。 EPAは、適切な、ローカルに格納されたエンティティタグがまだ有効であると想定した場合しかし、それは最初のセクション4.4で説明したように代わりに初期の出版物を提出すると、そのイベントの状態を変更しようとすべきです。
An initial PUBLISH request MUST contain a body that contains the published event state.
最初の要求が発行されたイベントの状態が含まれている体を含まなければならないPUBLISH。
An initial PUBLISH request MAY contain a single Expires header field. This value indicates the suggested lifetime of the event state publication.
最初の要求は、単一のExpiresヘッダーフィールドを含むかもしれPUBLISH。この値は、イベント状態発行の提案寿命を示しています。
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応答にExpiresヘッダーフィールド。この寿命を超過する前にリフレッシュされていない限り、出版物が期限切れになります。
An EPA is responsible for refreshing its previously established publications before their expiration interval has elapsed. To refresh a publication, the EPA MUST create a PUBLISH request that includes in a SIP-If-Match header field the entity-tag of the publication to be refreshed.
EPAは、その有効期間が経過する前に、その以前に確立された出版物を更新する責任があります。パブリケーションをリフレッシュするために、EPAは、リフレッシュされるSIP-If-Matchヘッダフィールドに出版のエンティティタグを含むPUBLISHリクエストを作成する必要があります。
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ヘッダフィールドを含むであろうPUBLISH。 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（該当する要求が失敗した）PUBLISH要求に対する応答を受信します。
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は、出版リフレッシュの提案寿命を低下させることができるが、それはそれを拡張することはありません。ヘッダフィールドが存在しない満了した場合、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.
出版リフレッシュは、すでに既存のイベント状態の有効期限を延長します。これは、他の方法でそのイベントの状態には影響を与えません。そのため、イベントの状態を更新するPUBLISHリクエストは、ボディを持ってはいけません。
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ヘッダフィールドに変更されるイベント状態出版のエンティティタグを含むPUBLISHリクエストを構築しなければなりません。修飾されたイベントの状態を含む本体を含まなければならないイベントの状態を変更する要求を発行します。
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で以前に発表されたイベントの状態と一致する場合、そのイベントの様子は、PUBLISHリクエストで運ばイベント状態によって置き換えられ、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ヘッダフィールドを含むであろうPUBLISH。 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は、PUBLISHリクエストに対して412（該当する要求が失敗した）応答を受信します。
A modifying PUBLISH request MAY contain a single Expires header field. This value indicates the suggested lifetime of the event state publication.
単を含むかもしれ修正PUBLISHリクエストは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は、出版の提案寿命を低下させることができるが、それはそれを拡張することはありません。ヘッダフィールドが存在しない満了した場合、EPAは、ESCを選択するための希望を示しています。修飾に2xx応答にExpiresヘッダーフィールドリクエストを発行する出版物は、活性なままでいるために実際の期間を示しています。この寿命を超過する前にリフレッシュされていない限り、出版物が期限切れになります。
Event state established by a prior publication may also be explicitly removed.
事前公表によって確立されたイベントの状態も明示的に除去することができます。
To request the immediate removal of event state, an EPA MUST create a PUBLISH request with an Expires value of "0", and set the SIP-If-Match header field to contain the entity-tag of the event state publication to be removed.
イベント状態の即時削除を要求するために、EPAは、「0」の値を有効期限とPUBLISHリクエストを作成し、削除するイベント状態出版のエンティティタグを含むように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のセクション8.1.2の手順は、[4]適用します。
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（条件付きリクエストが失敗した）応答を受信した場合、それはPUBLISHリクエストを再試行してはなりません。代わりに、イベント状態を公開し、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はPUBLISHリクエストに対して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.
イベントステートコンポジ（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.
それはPUBLISHリクエストに含まれている場合、ESCは、Record-Routeヘッダフィールドを無視しなければなりません。 ESCは、PUBLISHリクエストに対する応答にRecord-Routeヘッダフィールドを含んではいけません。一つはPUBLISHリクエストで存在する場合、ESCは、Contactヘッダーフィールドを無視しなければなりません。
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とのPUBLISHリクエストをそれらが受信された順序で処理しなければなりません。 PUBLISHリクエストは、特定のリクエストを発行することを意味し、アトミックに処理しなければなりませんで完全に、または全く処理さのどちらか。
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:
PUBLISHリクエストを受信した場合、ESCは、RFC 3261のセクション8.2で一般的なUASの動作を規定する手順を以下[4]。特定の動作を公開するために加えて、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は、この要求はESCは、イベントの状態を維持する責任があるためにリソースを対象としているかどうかを判断するためのRequest-URIを検査します。そうでない場合、ESCは404（Not Found）応答を返し、残りの手順を省略しなければなりません。
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.
また、ESCは責任を負いませんドメインへのRequest-URIのポイントということかもしれません。その場合には、要求を受け取る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は、PUBLISHリクエストのイベントヘッダフィールドを検査します。 Eventヘッダーフィールドが欠落しているかESCがサポートされていないイベントパッケージが含まれている場合は、ESCは489（不良イベント）応答でPUBLISH要求に応答し、残りの手順を省略しなければなりません。
3. The ESC examines the SIP-If-Match header field of the PUBLISH request for the presence of a request precondition.
3. ESCは、要求前提条件の存在についてPUBLISH要求のSIP-If-Matchヘッダフィールドを検査します。
* If the request does not contain a SIP-If-Match header field, the ESC MUST generate and store a locally unique entity-tag for identifying the publication. This entity-tag is associated with the event-state carried in the body of the PUBLISH request.
*リクエストがSIP-If-Matchヘッダフィールドが含まれていない場合、ESCは、出版物を識別するための局所的に一意のエンティティタグを生成して格納しなければなりません。このエンティティタグは、PUBLISHリクエストのボディに運ばイベント状態に関連しています。
* Else, if the request has a SIP-If-Match header field, the ESC checks whether the header field contains a single entity-tag. If not, the request is invalid, and the ESC MUST return with a 400 (Invalid Request) response and skip the remaining steps.
リクエストがSIP-If-Matchヘッダフィールドを持っている場合*さもなければ、ESCは、ヘッダフィールドは、単一のエンティティタグを含むかどうかをチェックします。そうでない場合、要求は無効であり、ESCは400（不正な要求）応答を返し、残りの手順を省略しなければなりません。
* Else, the ESC extracts the entity-tag contained in the SIP-If-Match header field and matches that entity-tag against all locally stored entity-tags for this resource and event package. If no match is found, the ESC MUST reject the publication with a response of 412 (Conditional Request Failed), and skip the remaining steps.
*そうでない場合、ESCは、SIP-If-Matchヘッダフィールドに含まれるエンティティタグを抽出し、このリソースとイベントパッケージのためのすべてのローカルに保存されたエンティティタグに対するそのエンティティタグに一致します。一致が見つからない場合、ESCは、412の応答（該当する要求が失敗した）を用いて文書を拒否し、残りの手順をスキップしなければなりません。
4. The ESC processes the Expires header field value from the PUBLISH request.
4. ESCは、PUBLISHリクエストのヘッダフィールド値を有効期限処理します。
* 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は、PUBLISHリクエストのボディに含まれる公表されたイベントの状態を処理します。リクエストのコンテンツタイプは、イベントパッケージに一致しない、または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はそのエンティティタグの既存のイベントの状態を更新し、関連付けられたエンティティタグによってPUBLISHリクエストのボディに送達され、識別されたイベントの状態を格納します。満了値は、選択された期限切れ間隔に設定されています。
* 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.
*要求メッセージ・ボディを有していないとNOエンティティタグを含まない場合、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.
PUBLISHリクエストの処理はアトミックでなければなりません。処理が完了する前に（例えばバックエンドデータベースにアクセスできないように）内部エラーが発生した場合、パブリケーションは成功してはいけません、とESCは、504（サーバタイムアウト）として、適切なエラー応答に失敗しなければなりません、そして最後のステップをスキップします。
6. The ESC returns a 200 (OK) response. The response MUST contain an Expires header field indicating the expiration interval chosen by the ESC. The response MUST also contain a SIP-ETag header field that contains a single entity-tag identifying the publication. The ESC MUST generate a new entity-tag for each successful publication, replacing any previous entity-tag associated with that event state. The generated entity-tag MUST be unique from any other entity-tags currently assigned to event state associated with that Request-URI, and MUST be different from any entity-tag assigned previously to event state for that Request-URI. See Section 8.3 for more information on the ESC handling of entity-tags.
6. ESCは、200（OK）レスポンスを返します。応答は、ESCによって選択された有効期限間隔を示す有効期限ヘッダーフィールドを含まなければなりません。応答はまた、文書を識別する単一のエンティティタグを含むSIP-ETagヘッダフィールドを含まなければなりません。 ESCは、そのイベントの状態に関連付けられた以前のエンティティタグを置き換える、各成功したパブリケーションの新しいエンティティタグを生成しなければなりません。生成されたエンティティタグは、現在その要求URIに関連付けられているイベントの状態に割り当てられた任意の他のエンティティタグから固有でなければならず、そのリクエストURIのイベント状態に以前に割り当てられたエンティティタグ異なっていなければなりません。エンティティタグのESCの取り扱いの詳細については、セクション8.3を参照してください。
A client may probe the ESC for the support of PUBLISH using the OPTIONS request defined in SIP [4]. The ESC processes OPTIONS requests as defined in Section 11.2 of RFC 3261 [4]. In the response to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of allowed methods in the Allow header field. Also, it SHOULD list the supported event packages in an Allow-Events header field.
クライアントは、SIP [4]で定義されたOPTIONS要求を使用してPUBLISHのサポートのためにESCを調べることができます。 ESC [4] RFC 3261のセクション11.2で定義されるようにOPTIONS要求を処理します。 OPTIONS要求に応答して、ESCは、許可ヘッダーフィールドで許可された方法のリストに「公開」を含むべきです。また、許可 - イベントヘッダーフィールドでサポートされているイベントパッケージをリストする必要があります。
The Allow header field may also be used to specifically announce support for PUBLISH messages when registering. (See SIP Capabilities [12] for details).
Allowヘッダーフィールドはまた、特に登録時にメッセージをPUBLISHのサポートを発表するために使用することができます。 （詳細については、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.
このセクションでは、PUBLISHでのエンティティタグの使用方法の概要を説明します。それは本質的に有益であるため、何の規範的なプロトコル記述が含まれていません。
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]で定義されるようにPUBLISHメカニズムは、エンティティタグを利用します。主な機能が保存されている間、エンティティタグと対応するヘッダフィールドの構文と意味論は、具体的にPUBLISH方法で使用するために適合されています。主な違いは次のとおりです。
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 Aは、複数のエンティティタグと要求前提条件が許可されていないので、前提条件は、単一のエンティティタグにのみ適用することができるPUBLISH。
o A request precondition can't apply to "any" entity, namely there is no special "*" entity-tag value defined for PUBLISH.
O要求の前提条件は、「任意の」エンティティは、すなわちPUBLISHために定義されたエンティティタグ値「*」特別な存在しないに適用することはできません。
o Whereas in HTTP/1.1 returning an entity-tag is optional for origin servers, in PUBLISH ESCs are required to always return an entity-tag for a successful publication.
O HTTP / 1.1にエンティティタグを返すことで、オリジンサーバのためのオプションであるのに対しことのESCを公開常に成功出版のためにエンティティタグを返すように要求されています。
The main motivation for the above adaptation is that PUBLISH is conceptually an HTTP PUT, for which only a subset of the features in cache validation using entity-tags is allowed in HTTP/1.1. It makes little sense to enable features other than this subset for event state publication.
上記の適応のための主な動機はPUBLISHエンティティタグを使用して、キャッシュの検証の機能のサブセットのみが、HTTP / 1.1で許可されたHTTPのPUTは、概念的であることです。これは、イベント状態発行のためのこのサブセット以外の機能を有効にするには、ほとんど意味がありません。
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と同一ではないPUBLISHそれ明らかにエンティティタグを使用することを作るために、我々は、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.
各成功した出版物は、PUBLISHリクエストに応じて、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に戻されます。以前の出版物は、ESCがアクティブ出版物のセットの検索キーとして使用できるエンティティタグを含むであろう更新EPAからの各イベント状態出版。
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は、受信したPUBLISHリクエストの量を削減する方法があります。
o Choice of the expiration interval for a publication can be affected by the ESC. It can insist that an EPA chooses a longer expiration value to what it suggests, in case the ESC's local default minimum expiration value is not reached. Maintaining a longer default minimum expiration value at the ESC reduces the rate at which publications are refreshed.
O出版物の有効間隔の選択は、ESCによって影響を受けることができます。それは場合にはESCのローカルのデフォルトの最小の有効期限値に達していない、EPAは、それが示唆するものに長い有効期限の値を選択することを主張することができます。 ESCの長いデフォルトの最小の有効期限値を維持することは、出版物が更新される速度を低減します。
o Another way of reducing publication traffic is to use a SIP-level push-back to quench a specific source of publication traffic. To push back on publications from a particular source, the ESC MAY respond to a PUBLISH request with a 503 (Service Unavailable), as defined in RFC 3261 [4]. This response SHOULD contain a Retry-After header field indicating the time interval that the publication source is required to wait until sending another PUBLISH request.
O出版トラフィックを低減する別の方法は、パブリケーション・トラフィックの特定のソースをクエンチSIPレベルのプッシュバックを使用することです。 RFC 3261で定義されている特定のソースからの刊行物に押し戻すために、ESCは、503（サービス利用不可）とPUBLISHリクエストに応答することができる[4]。この応答は、発行元が別の要求を発行する送信まで待つ必要とされる時間間隔を示す再試行後ヘッダーフィールドを含むべきです。
At the time of writing this specification, work on managing load in SIP is starting, which may be able to provide further tools for managing load in event state publication systems.
この明細書を書いている時点で、SIP負荷管理に関する作業は、イベント状態の出版システムに負荷を管理するためのさらなるツールを提供することであってもよい、起動されます。
This section discusses several issues which should be taken into consideration when applying the PUBLISH mechanism to event packages. It also demonstrates how these issues are handled when using PUBLISH for presence publication.
このセクションでは、イベントパッケージに公開するメカニズムを適用する際に考慮すべきいくつかの問題について説明します。また、プレゼンスの出版のためPUBLISHを使用した場合、これらの問題がどのように処理されるかを示しています。
Any future event package specification SHOULD include a discussion of its considerations for using PUBLISH. At a minimum those considerations SHOULD address the issues presented in this chapter, and MAY include additional considerations.
将来のイベントパッケージ仕様は、PUBLISH使用のためにその注意事項の説明を含むべきです。最低でも、これらの考慮事項は、この章で説明する問題に対処すべきである、と追加の考慮事項を含むかもしれません。
The body of the PUBLISH request typically carries the published event state. Any application of the PUBLISH mechanism for a given event package MUST define what content type or types are expected in PUBLISH requests. Each event package MUST also describe the semantics associated with that content type, and MUST prescribe a default, mandatory to implement MIME type.
PUBLISHリクエストのボディは、一般的に公表されたイベントの状態を運びます。与えられたイベントパッケージのためのPUBLISHメカニズムの任意のアプリケーションは、コンテンツの種類やタイプがリクエストを公開で期待されているかを定義しなければなりません。各イベントパッケージには、そのコンテンツタイプに関連付けられた意味論を記述しなければならない、とMIMEタイプを実装するために必須のデフォルトを、処方しなければなりません。
This document defines the semantics of the presence publication requests (event package "presence") when the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) [6] is used. A PUA that uses PUBLISH to publish presence state to the PA MUST support the PIDF presence format. It MAY support other formats.
プレゼンスのための共通プロファイル（CPP）、プレゼンス情報データフォーマット（PIDF）[6]を使用する場合は、この文書では、プレゼンス公開要求（イベントパッケージ「プレゼンス」）のセマンティクスを定義します。 PAへのプレゼンス状態を公開するPUBLISH使用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.
PUBLISHリクエストへの応答は、リクエストが成功したかどうかを示します。イベントパッケージは、このような身体の明示的な意味を定義しない限り、一般的には、このような応答のボディは空になります。
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.
PUBLISHメカニズムを使用した以外のイベント状態のソースが明示的に許可されていることに注意してください。しかし、このようなインターフェイスを定義するには、この文書の範囲外です。
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.
PUBLISH機構を利用するイベントパッケージは、イベント状態パブリケーションのこのモデルが適用可能であるかどうかを記述する必要があり、そして複数のソースからのパブリケーションを集約するために使用される特定のメカニズムを記述することができます。
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は、ウォッチャーはNOTIFYで受け取るプレゼンス文書に合成することができるタプルのサブセットだけのプレゼンス状態を公開することができます。 ESCは、この情報を集約するメカニズムは、ローカルポリシーのこの仕様の範囲外の問題です。
For some event packages, there exists a natural decomposition of event state into segments. Each segment is defined as one of potentially many identifiable sections in the published event state. Any event package whose content type supports such segmentation of event state, SHOULD describe the way in which these event state segments are identified by the ESC.
一部のイベントパッケージでは、セグメントにイベント状態の自然分解が存在します。各セグメントは、公開されたイベントの状態に潜在的に多くの識別可能なセクションの一つとして定義されます。そのコンテンツタイプ、イベント状態のそのようなセグメント化をサポートする任意のイベントパッケージは、これらのイベント状態セグメントはESCによって同定される方法を記述するべきです。
In presence publication, the EPA MUST keep the "id" attributes of tuples consistent in the context of an entity-tag. If a publication modifies the contents of a tuple, that tuple MUST maintain its original "id". The ESC will interpret each tuple in the context of the entity-tag with which the request arrived. A tuple whose "id" is missing compared to the original publication will be considered as being removed. Similarly, a tuple is interpreted as being added if its "id" attribute is one that the original publication did not contain.
プレゼンス発行において、EPAは、エンティティタグの文脈における一貫したタプルの「ID」属性を保持しなければなりません。出版タプルの内容を変更した場合、そのタプルは、その元の「ID」を維持しなければなりません。 ESCは、要求が到着したとエンティティタグのコンテキストで各タプルを解釈します。その「ID」初版発行に比べて不足しているタプルが除去されていると考えます。同様に、タプルは、その「id」属性は、元の出版物が含まれていなかったものである場合に添加されるものとして解釈されます。
Controlling the rate of publication is discussed in Section 9. Individual event packages MAY in turn define recommendations (SHOULD or MUST strength) on absolute maximum rates at which publications are allowed to be generated by a single EPA.
出版物の割合が9個々のイベントパッケージは順番に刊行物は、単一のEPAによって生成することが許可されている時、絶対最大速度に関する勧告を（SHOULDまたはMUST強度）を定義するかもしれ節で議論されて制御します。
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.
「PUBLISH」SIPメッセージ文法の要素「方法」の定義に追加されます。他のすべてのSIPメソッドと同様に、メソッド名は、大文字と小文字が区別されます。このイベントの状態を合成する責任エンティティにイベント状態を公開するために使用されるPUBLISH。
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は、[4]、追加の列を追加する要求と応答をパブリッシュに使用することができるヘッダーフィールドを定義することにより、表2及びRFC 3261の3延びます。これらのテーブルのキーは、RFC 3261のセクション20で指定されている[4]。
+---------------------+---------+---------+
| 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 SIPの表3に拡大[4]、セクション11.1の変化によって修正されます。
+--------------+-------+-------+-----+-----+-----+-----+-----+
| 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-マッチ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
PUBLISHm =％x50.55.42.4C.49.53.48。キャップに公開します。拡張方式= PUBLISHm /トークンSIP-ETagのは= "SIP-ETagを" HCOLONエンティティタグSIP-IF-マッチ= "SIP-IF-マッチ" HCOLONエンティティタグエンティティタグ=トークン
This document registers a new method name, a new response code and two new header field names.
この文書は、新しいメソッド名、新しい応答コードと二つの新しいヘッダフィールド名を登録します。
This document registers a new SIP method, defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
この文書はhttp://www.iana.org/assignments/sip-parameters下方法と応答コードのサブレジストリに追加された次の情報によって定義された新たなSIPメソッドを登録します。
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)
ヘッダー名：SIP-ETagのコンパクトなフォーム：（なし）
Header Name: SIP-If-Match Compact Form: (none)
ヘッダー名：SIP-IF-マッチコンパクトなフォーム：（なし）
Since event state may be considered sensitive information, the ESC should have the ability to selectively accept publications from authorized sources only, based on the identity of the EPA.
イベント状態が機密情報とみなすことができるので、ESCは、EPAのアイデンティティに基づいて、選択的にのみ許可されたソースからの出版物を受け入れる能力を持つべきです。
The state agent SHOULD authenticate the EPA, and SHOULD apply its authorization policies (e.g., based on access control lists) to all requests. The composition model makes no assumptions that all input sources for an ESC are on the same network, or in the same administrative domain.
状態エージェントは、EPAを認証しなければならず、すべての要求への認可ポリシーを（例えば、アクセス制御リストに基づいて）適用されるべきです。構成モデルは、ESCのためのすべての入力ソースは、同じネットワーク上、または同じ管理ドメイン内にある仮定を行いません。
ESCs and EPAs MUST implement Digest for authenticating PUBLISH requests, as defined in RFC 3261 [4]. The exact methods for creating and manipulating access control policies in the ESC are outside the scope of this document.
RFC 3261で定義されているのESCとのEPAは、リクエストを発行する認証するためのダイジェストを実装しなければならない[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.
PUBLISHリクエストを受信すると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の実装は、PUBLISHリクエストの認証を必要とすべきです。 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の追加のスロットリングとデバウンス論理はさらに、PUBLISHリクエストの結果として生成通知トラフィックを削減することをお勧めします。
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.
PUBLISHリクエストを再生すると、有害な影響を持つことができます。攻撃者は、それがそのPUBLISHリクエストを再生することによって、過去のある時点で行われて目撃任意のイベント状態パブリケーションを実行することができるかもしれません。とりわけ、そのような再生メッセージは、バージョン管理メカニズムが、例えば、状態情報のタイムスタンプは、そのような攻撃を軽減することができる、古いイベント状態情報を偽造するために使用することができます。
To prevent replay attacks, implementations MUST support Digest authentication with replay protection, as defined in RFC 3261 [4]. Further mechanisms for countering replay attacks are discussed in SIP [4].
RFC 3261で定義されているリプレイ攻撃を防ぐために、実装は、リプレイ保護をダイジェスト認証をサポートしなければならない[4]。リプレイ攻撃に対抗するための別のメカニズムは、SIPで議論されている[4]。
Even with authentication, man-in-the-middle attacks using PUBLISH may be used to install arbitrary event state information, modify or remove existing event state information in publications, or even remove event state altogether at an ESC.
でも認証で、PUBLISH使用してman-in-the-middle攻撃は、出版物の既存のイベント状態情報を変更したり、削除し、任意のイベント状態情報をインストールするために使用することができる、あるいは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-マッチ、ルートから、に渡って完全性保護を提供すべきであり、ヘッダフィールドと、PUBLISHリクエストのボディを有効期限。
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（例えば、完全性保護は、エンドツーエンド、出版社からの加入者に適用される）ではないセキュリティアソシエーションを使用して保護整合性あるPUBLISHリクエストでイベント状態を受信した場合、状態エージェントは、ESCと相まってNOTIFYリクエストを、このイベント状態の加入者にそれを暴露する前に、イベントの状態を変更してはいけません。これは、イベント状態のエンドツーエンドの整合性を維持することです。
For integrity protection, ESCs MUST implement TLS [8], and MUST support both mutual and one-way authentication, and MUST also support the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs MAY support S/MIME [9] for integrity protection, as defined in SIP [4].
完全性保護のために、ESCの[8] TLSを実装しなければなりません、そして相互と一方向認証の両方をサポートしなければなりません、また、SIPで定義されたSIPS URIスキーム[4]をサポートしなければなりません。 EPAは、TLSを開始することが可能であるべきとSIPS URIスキームをサポートする必要があります。 SIPで定義されているのESCとのEPAは、[4]、完全性保護のために[9] S / MIMEをサポートするかもしれません。
The state information contained in a PUBLISH message may potentially contain sensitive information. Implementations MAY encrypt such information to ensure confidentiality.
PUBLISHメッセージに含まれる状態情報は、潜在的に機密情報が含まれていてもよいです。実装は、機密性を確保するために、このような情報を暗号化してもよいです。
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の[8]、相互と一方向認証の両方をサポートしなければなりません、また、SIPで定義されたSIPS URIスキーム[4]をサポートしなければならないTLSを実装しなければなりません。 EPAは、TLSを開始することが可能であるべきとSIPS URIスキームをサポートする必要があります。 SIPで定義されているのESCとのEPAは、[4]、イベント状態情報の暗号化のための[9] S / MIMEをサポートするかもしれません。
This section shows an example of using the PUBLISH method for publishing a presence document from a presence user agent to a presence agent. The watcher in this example is subscribing to the presentity's presence information from the PA. The PUA may also SUBSCRIBE to its own presence to see the composite presence state exposed by the PA. This is an optional but likely step for the PUA, and is not shown in this example.
このセクションでは、プレゼンス・エージェントにプレゼンス・ユーザ・エージェントからのプレゼンス文書を公開するためのPUBLISH方法を使用した例を示します。この例では、ウォッチャは、PAからのプレゼンティティのプレゼンス情報をサブスクライブしています。 PUAはまた、PAによって公開された複合プレゼンス状態を確認するために、独自の存在に加入することができます。これは、PUAのためのオプションが、おそらく工程であり、この例には示されていません。
When the value of the Content-Length header field is "..." this means that the value should be whatever the computed length of the body is.
Content-Lengthヘッダフィールドの値が「...」この値は、本体の計算された長さがあるものは何でもあるべきであることを意味します。
PUA PA WATCHER
(EPA) (ESC)
| | |
| | <---- M1: SUBSCRIBE --- |
| | |
| | ----- M2: 200 OK -----> |
| | |
| | ----- M3: NOTIFY -----> |
| | |
| | <---- M4: 200 OK ------ |
| | |
| | |
| ---- M5: PUBLISH ---> | |
| | |
| <--- M6: 200 OK ---- | |
| | |
| | ----- M7: NOTIFY -----> |
| | |
| | <---- M8: 200 OK ------ |
| | |
| ---- M9: PUBLISH ---> | |
| | |
| <--- M10: 200 OK --- | |
| | |
| | |
| --- M11: PUBLISH ---> | |
| | |
| <-- M12: 200 OK ---- | |
| | |
| | ----- M13: NOTIFY ----> |
| | |
| | <---- M14: 200 OK ----- |
| | |
Message flow:
メッセージフロー：
M1: The watcher initiates a new subscription to the presentity@example.com's presence agent.
M1：ウォッチャーはpresentity@example.com'sプレゼンスエージェントに新しいサブスクリプションを開始します。
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
SIP SUBSCRIBE：presentity@example.comをSIP / 2.0経由：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bKnashds7へ：<SIP：presentity@example.com>から<SIP：watcher@example.com>。タグは= 12341234のCall-ID：12345678@host.example.comのCSeq：マックス-前方にSUBSCRIBE 1：70の有効期限：3600イベント：プレゼンス連絡先：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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bKnashds7は、受信= 192.0.2.1へ：<SIP：presentity@example.com>;タグ= ABCD1234から：<SIP：ウォッチャー@例.COM>;タグ= 12341234のCall-ID：12345678@host.example.comのCSeq：SIP：pa.example.comの有効期限：3600のContent-Length：連絡先をSUBSCRIBE 1 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ウォッチャに送信します。
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: ...
user@host.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP pa.example.comを、ブランチ= z9hG4bK8sdf2へ：<SIP：watcher@example.com>;タグ= 12341234から：<SIP：プレゼン@ example.com>;タグ= ABCD1234コール-ID：12345678@host.example.comのCSeq：1 NOTIFYマックス・フォワード：70イベント：プレゼンスサブスクリプション・ステート：アクティブ;有効期限が切れる= 3599お問い合わせ：SIP：pa.example.comのContent-Type：アプリケーション/ PIDF + XMLコンテンツ-長さ：...
[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
SIP / 2.0 200 OK経由：タグ= 12341234から;：<watcher@example.com SIP：>：<一口例：@プレゼンSIP / 2.0 / UDP pa.example.com;ブランチ= z9hG4bK8sdf2は= 192.0.2.2への受信しました.COM>;タグ= ABCD1234コール-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要求を開始します。期限切れヘッダフィールドは、このイベント柔らかい状態の推奨期間を示します。
PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ...
SIP PUBLISH：presentity@example.comをSIP / 2.0経由：SIP / 2.0 / UDP pua.example.com;ブランチ= z9hG4bK652hsgeへ：<SIP：presentity@example.com>から<SIP：presentity@example.com>。タグ= 1234wxyzコールID：81818181@pua.example.comのCSeqは：1マックス・フォワードを公開：70有効期限：3600イベント：プレゼンスのContent-Type：アプリケーション/ PIDF + XMLコンテンツ-長さ：...
[Published PIDF document]
[公開PIDFドキュメント]
M6: The presence agent receives, and accepts the presence publication. The published data is incorporated into the presentity's presence information.
M6：プレゼンスエージェントは、受信、およびプレゼンスの出版物を受け入れます。公表されたデータは、プレゼンティティのプレゼンス情報に組み込まれています。
SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge ;received=192.0.2.3 To: <sip:presentity@example.com>;tag=1a2b3c4d From: <sip:presentity@example.com>;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800
SIP / 2.0 200 OK経由：タグ= 1a2b3c4dから;：<presentity@example.com SIP：>：<一口例：@プレゼンSIP / 2.0 / UDP pua.example.com;ブランチ= z9hG4bK652hsgeは= 192.0.2.3への受信しました.COM>;タグ= 1234wxyzコールID：81818181@pua.example.comのCSeq：1 SIP-ETagのを公開：dx200xyzの有効期限：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: ...
user@host.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP pa.example.comを、ブランチ= z9hG4bK4cd42aへ：<SIP：watcher@example.com>;タグ= 12341234から：<SIP：プレゼン@ example.com>;タグ= ABCD1234コール-ID：12345678@host.example.comのCSeq：2 NOTIFYマックス - フォワード：70イベント：プレゼンスサブスクリプション・ステート：アクティブ;有効期限が切れる= 3400お問い合わせ：SIP：pa.example.comのContent-Type：アプリケーション/ PIDF + XMLコンテンツ-長さ：...
[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
SIP / 2.0 200 OK経由：タグ= 12341234から;：<watcher@example.com SIP：>：<一口例：@プレゼンSIP / 2.0 / UDP pa.example.com;ブランチ= z9hG4bK4cd42aは= 192.0.2.2への受信しました.COM>;タグ= ABCD1234コール-ID：12345678@host.example.comのCSeq：2のContent-LengthをNOTIFY：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
SIP PUBLISH：presentity@example.comをSIP / 2.0経由：SIP / 2.0 / UDP pua.example.com;ブランチ= z9hG4bK771ash02へ：<SIP：presentity@example.com>から<SIP：presentity@example.com>。タグ= 1234kljkコールID：98798798@pua.example.comのCSeq：70 SIP-IF-マッチ：1マックス-前方にPUBLISH dx200xyzが有効期限：3600イベント：プレゼンスの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は、PUBLISHの成功に応じて、エンティティタグを返します。実際の状態変化が発生していないことに注意してください、そうウォッチャーは一切のNOTIFYを受け取りません。
SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02 ;received=192.0.2.3 To: <sip:presentity@example.com>;tag=2affde434 From: <sip:presentity@example.com>;tag=1234kljk Call-ID: 98798798@pua.example.com CSeq: 1 PUBLISH SIP-ETag: kwj449x Expires: 1800
SIP / 2.0 200 OK経由：タグ= 2affde434から;：<presentity@example.com SIP：>：<一口例：@プレゼンSIP / 2.0 / UDP pua.example.com;ブランチ= z9hG4bK771ash02は= 192.0.2.3への受信しました.COM>;タグ= 1234kljkコールID：98798798@pua.example.comのCSeq：1 SIP-ETagのを公開：kwj449xの有効期限：1800年
M11: The PUA of the presentity detects a change in the user's presence state. It initiates a PUBLISH request to the presence agent to modify the published presence information with the recent change.
M11：プレゼンのPUAは、ユーザーのプレゼンス状態の変化を検出します。これは、最近の変更で公開プレゼンス情報を変更するためのプレゼンスエージェントに公開要求を開始します。
PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=54321mm Call-ID: 5566778@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 SIP-If-Match: kwj449x Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ...
SIP PUBLISH：presentity@example.comをSIP / 2.0経由：SIP / 2.0 / UDP pua.example.com;ブランチ= z9hG4bKcdad2へ：<SIP：presentity@example.com>から<SIP：presentity@example.com>。タグ= 54321ミリメートルコール-ID：5566778@pua.example.comのCSeq：1マックス・フォワードを公開：70 SIP-IF-マッチ：kwj449xの有効期限：3600イベント：プレゼンスのContent-Type：アプリケーション/ PIDF + XMLコンテンツ長を：。 。..
[Published PIDF Document]
[公開PIDFドキュメント]
M12: The presence agent receives, and accepts the modifying publication. The published data is incorporated into the presentity's presence information, updating the previous publication from the same PUA.
M12：プレゼンスエージェントは、受信し、及び修飾文書を受け付けます。公表されたデータは、同じPUAから以前の出版物を更新し、プレゼンティティのプレゼンス情報に組み込まれています。
SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 ;received=192.0.2.3 To: <sip:presentity@example.com>;tag=effe22aa From: <sip:presentity@example.com>;tag=54321mm Call-ID: 5566778@pua.example.com CSeq: 1 PUBLISH SIP-ETag: qwi982ks Expires: 3600
SIP / 2.0 200 OK経由：タグ= effe22aaから;：<presentity@example.com SIP：>：<一口例：@プレゼンSIP / 2.0 / UDP pua.example.com;ブランチ= z9hG4bKcdad2は= 192.0.2.3への受信しました.COM>;タグ= 54321ミリメートルのコールID：5566778@pua.example.comのCSeq：1 SIP-ETagのを公開：qwi982ksの有効期限：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: ...
user@host.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP pa.example.comを、ブランチ= z9hG4bK32defd3へ：<SIP：watcher@example.com>;タグ= 12341234から：<SIP：プレゼン@ example.com>;タグ= ABCD1234コール-ID：12345678@host.example.comのCSeq：2 NOTIFYマックス - フォワード：70イベント：プレゼンスサブスクリプション・ステート：アクティブ;有効期限が切れる= 3400お問い合わせ：SIP：pa.example.comのContent-Type：アプリケーション/ PIDF + XMLコンテンツ-長さ：...
[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
SIP / 2.0 200 OK経由：タグ= 12341234から;：<watcher@example.com SIP：>：<一口例：@プレゼンSIP / 2.0 / UDP pa.example.com;ブランチ= z9hG4bK32defd3は= 192.0.2.3への受信しました.COM>;タグ= ABCD1234コール-ID：12345678@host.example.comのCSeq：2のContent-LengthをNOTIFY：0
The original contributors to this specification are:
この仕様のオリジナルの貢献者は、次のとおりです。
Ben Campbell Estacado Systems
ベン・キャンベルEstacadoシステム
Sean Olson Microsoft
ショーン・オルソンマイクロソフト
Jon Peterson Neustar, Inc.
ジョンピーターソンNeustar社
Jonathan Rosenberg dynamicsoft
ジョナサン・ローゼンバーグdynamicsoft
Brian Stucker Nortel Networks, Inc.
ブライアンStuckerノーテルネットワークス株式会社
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.
著者は、彼らの集団的努力のためSIMPLEワーキンググループに感謝したいと思いますし、特にこの仕事の彼らのレビューとサポートのための以下の方々：ヘニングSchulzrinneと、ポールKyzivat、ヒシャムKhartabil、ジョージFOTI、キース糖剤、サミールSrivastava氏、アルン・クマール、アダムローチ、ペッカPessi、カイ王、カレン・ジェニングス、ミッコLonnfors、エヴァ・マリア・Leppanen、エルンストHorvathの、サノスDiacakis、オデッドCnaan、ローハンマーイ、およびディーンウィリス。
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[2] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[2]ローゼンバーグ、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日目、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[6]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7]クロッカー、D.、エド。そして、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]ダークス、T.とC.アレン、 "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.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[10] Campbell, B., "SIMPLE Presence Publication Requirements", Work in Progress, February 2003.
[10]キャンベル、B.、 "SIMPLEプレゼンス公開要件"、進歩、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]マーイ、R.、RFC 3842、2004年8月「セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ」。
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[12]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[13]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
Author's Address
著者のアドレス
Aki Niemi (editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
あき にえみ （えぢとｒ） のきあ Ｐ。お。 ぼｘ ４０７ のきあ ＧろうＰ、 ふぃん ０００４５ ふぃんぁんｄ
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
電話番号：+358 50 389 1644 Eメール：aki.niemi@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。