RFC3903 日本語訳
3903 Session Initiation Protocol (SIP) Extension for Event StatePublication. A. Niemi, Ed.. October 2004. (Format: TXT=72062 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Niemi, Ed. Request for Comments: 3903 Nokia Category: Standards Track October 2004
ワーキンググループA.Niemi、エドをネットワークでつないでください。コメントのために以下を要求してください。 3903年のノキアカテゴリ: 標準化過程2004年10月
Session Initiation Protocol (SIP) Extension
for Event State Publication
イベント州政府出版物のためのセッション開始プロトコル(一口)拡大
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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 Events枠組みの中で使用された出版イベント状態のためにSession Initiationプロトコル(SIP)に拡大について説明します。 この拡大の最初の利用は存在情報の公表のためのものです。
The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.
適切なイベントパッケージが存在するどんなイベント状態の公表も支持するために本書では説明されたメカニズムは広げることができます。 それは任意のデータの輸送のための汎用メカニズムであることを意図しません、より十分合っているメカニズムがこのためにあるとき。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Document Conventions . . . . . . . . . . . . 3
3. Overall Operation . . . . . . . . . . . . . . . . . . . . . 4
4. Constructing PUBLISH Requests . . . . . . . . . . . . . . . 5
4.1. Identification of Published Event State. . . . . . . . 6
4.2. Creating Initial Publication . . . . . . . . . . . . . 7
4.3. Refreshing Event State . . . . . . . . . . . . . . . . 8
4.4. Modifying Event State . . . . . . . . . . . . . . . . 9
4.5. Removing Event State . . . . . . . . . . . . . . . . . 9
5. Processing PUBLISH Responses . . . . . . . . . . . . . . . . 10
6. Processing PUBLISH Requests . . . . . . . . . . . . . . . . 10
7. Processing OPTIONS Requests . . . . . . . . . . . . . . . . 13
8. Use of Entity-tags in PUBLISH . . . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 定義とドキュメントコンベンション. . . . . . . . . . . . 3 3。 総合的な操作. . . . . . . . . . . . . . . . . . . . . 4 4。 組み立てて、要求. . . . . . . . . . . . . . . 5 4.1を発表してください。 発行されたイベント状態の識別。 . . . . . . . 6 4.2. 初期の公表. . . . . . . . . . . . . 7 4.3を作成します。 イベント状態. . . . . . . . . . . . . . . . 8 4.4をリフレッシュします。 イベント状態. . . . . . . . . . . . . . . . 9 4.5を変更します。 イベント状態. . . . . . . . . . . . . . . . . 9 5を取り除きます。 処理して、応答. . . . . . . . . . . . . . . . 10 6を発行してください。 処理して、要求. . . . . . . . . . . . . . . . 10 7を発表してください。 オプションを処理すると、.138は要求されます。 実体タグの使用は中で.13を発行します。
Niemi Standards Track [Page 1] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[1ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
8.1. General Notes. . . . . . . . . . . . . . . . . . . . . 13
8.2. Client Usage . . . . . . . . . . . . . . . . . . . . . 14
8.3. Server Usage . . . . . . . . . . . . . . . . . . . . . 14
9. Controlling the Rate of Publication . . . . . . . . . . . . 15
10. Considerations for Event Packages using PUBLISH . . . . . . 15
10.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . 16
10.2. PUBLISH Response Bodies. . . . . . . . . . . . . . . . 16
10.3. Multiple Sources for Event State . . . . . . . . . . . 16
10.4. Event State Segmentation . . . . . . . . . . . . . . . 17
10.5. Rate of Publication. . . . . . . . . . . . . . . . . . 17
11. Protocol Element Definitions . . . . . . . . . . . . . . . . 17
11.1. New Methods. . . . . . . . . . . . . . . . . . . . . . 17
11.1.1. PUBLISH Method . . . . . . . . . . . . . . . . 17
11.2. New Response Codes . . . . . . . . . . . . . . . . . . 19
11.2.1. "412 Conditional Request Failed" Response Code 19
11.3. New Header Fields . . . . . . . . . . . . . . . . . . 20
11.3.1. "SIP-ETag" Header Field . . . . . . . . . . . 20
11.3.2. "SIP-If-Match" Header Field . . . . . . . . . 20
12. Augmented BNF Definitions . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
13.1. Methods . . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Response Codes . . . . . . . . . . . . . . . . . . . . 21
13.3. Header Field Names . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . 22
14.1. Access Control . . . . . . . . . . . . . . . . . . . . 22
14.2. Denial of Service Attacks . . . . . . . . . . . . . . 22
14.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . 22
14.4. Man in the Middle Attacks . . . . . . . . . . . . . . 23
14.5. Confidentiality . . . . . . . . . . . . . . . . . . . 23
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
18.1. Normative References . . . . . . . . . . . . . . . . . 30
18.2. Informative References . . . . . . . . . . . . . . . . 31
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 31
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 32
8.1. 一般注意事項。 . . . . . . . . . . . . . . . . . . . . 13 8.2. クライアント用法. . . . . . . . . . . . . . . . . . . . . 14 8.3。 サーバ用法. . . . . . . . . . . . . . . . . . . . . 14 9。 公表. . . . . . . . . . . . 15 10のレートを制御します。 出来事が使用をパッケージするので、問題は.15 10.1を発行します。 ボディー. . . . . . . . . . . . . . . . . . . . 16 10.2を発行してください。 応答本体を発行してください。 . . . . . . . . . . . . . . . 16 10.3. 出来事のための複数の情報筋が.16 10.4を述べます。 イベント州の分割. . . . . . . . . . . . . . . 17 10.5。 公表のレート。 . . . . . . . . . . . . . . . . . 17 11. 要素定義. . . . . . . . . . . . . . . . 17 11.1について議定書の中で述べてください。 新しい方法。 . . . . . . . . . . . . . . . . . . . . . 17 11.1.1. 方法. . . . . . . . . . . . . . . . 17 11.2を発行してください。 新しい応答は.1に.19 11.2をコード化します。 「412条件付き要求は失敗した」という応答コード19 11.3。 新しいヘッダーフィールド. . . . . . . . . . . . . . . . . . 20 11.3.1。 「一口ETag」ヘッダーフィールド. . . . . . . . . . . 20 11.3.2。 「マッチであるなら、ちびちび飲んでいる」ヘッダーフィールド. . . . . . . . . 20 12。 BNF定義. . . . . . . . . . . . . . . . . 21 13を増大させました。 IANA問題. . . . . . . . . . . . . . . . . . . . 21 13.1。 方法. . . . . . . . . . . . . . . . . . . . . . . 21 13.2。 応答は.21 13.3をコード化します。 ヘッダーフィールドは.21 14を命名します。 セキュリティ問題. . . . . . . . . . . . . . . . . . 22 14.1。 コントロール. . . . . . . . . . . . . . . . . . . . 22 14.2にアクセスしてください。 サービス不能攻撃. . . . . . . . . . . . . . 22 14.3。 反射攻撃. . . . . . . . . . . . . . . . . . . . 22 14.4。 中央攻撃. . . . . . . . . . . . . . 23 14.5でやれやれ。 秘密性. . . . . . . . . . . . . . . . . . . 23 15。 例. . . . . . . . . . . . . . . . . . . . . . . . . . 24 16。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . 29 17。 承認. . . . . . . . . . . . . . . . . . . . . . 30 18。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 30 18.1。 引用規格. . . . . . . . . . . . . . . . . 30 18.2。 有益な参照. . . . . . . . . . . . . . . . 31作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . 31 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
1. 序論
This specification provides a framework for the publication of event state from a user agent to an entity that is responsible for compositing this event state and distributing it to interested parties through the SIP Events [1] framework.
この仕様はSIP Events[1]枠組みを通してユーザエージェントからこのイベント状態を合成するのに原因となる実体とそれを分配するのから利害関係者までイベント状態の公表に枠組みを提供します。
Niemi Standards Track [Page 2] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[2ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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].
イベント公表枠組みを定義することに加えて、この仕様は存在状態[2]の公表のために存在植字工の存在ユーザエージェント[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出来事のアプリケーションは、1セットのユーザエージェントの向こう側に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でガイドラインセットを固く守る必要があるでしょう。 本書では説明されたメカニズムは任意のデータの輸送のための汎用メカニズムであることを意図しません、より十分合っているメカニズムがこのためにあるとき。
2. Definitions and Document Conventions
2. 定義とドキュメントコンベンション
In addition to the definitions of RFC 2778 [3], RFC 3265 [1], and RFC 3261 [4], this document introduces some new concepts:
RFC2778[3]、RFC3265[1]、およびRFC3261[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): イベント状態を発行するという要求をPUBLISHに出すUserエージェントClient(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を処理するUserエージェントServer(UAS)はリソースの完全で、合成しているイベント状態にイベント状態を合成するのに要求して、責任があります。
Presence Compositor: A type of Event State Compositor that is
responsible for compositing presence state for a presentity.
存在植字工: 一種のpresentityにおいて、合成存在状態に責任があるEvent州Compositor。
Publication: The act of an EPA sending a PUBLISH request to an ESC to
publish event state.
公表: EPAがイベント状態を発行するためにPUBLISH要求をESCに送る行為。
Event Hard State: The steady-state or default event state of a
resource, which the ESC may use in the absence of, or in addition
to, soft state publications.
イベントの固い州: リソースの安定した状態かデフォルトイベント状態。(ESCは刊行物か軟性国家刊行物でそれを使用するかもしれません)。
Niemi Standards Track [Page 3] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[3ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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によってPUBLISHメカニズムを使用することで発行されました。 プロトコル要素(すなわち、実体タグ)は、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[5]という本書ではことであり、対応する実現のために要件レベルを示すべきであるかをさせましょう。
Indented passages such as this one are used in this document to
provide additional information and clarifying text. They do not
contain descriptions of normative protocol behavior.
追加情報を提供するのに本書では使用されて、テキストをはっきりさせるこれなどの通路に入り込みました。 それらは標準のプロトコルの振舞いの記述を含んでいません。
3. Overall Operation
3. 総合的な操作
This document defines a new SIP method, PUBLISH, for publishing event state. PUBLISH is similar to REGISTER in that it allows a user to create, modify, and remove state in another entity which manages this state on behalf of the user. Addressing a PUBLISH request is identical to addressing a SUBSCRIBE request. The Request-URI of a PUBLISH request is populated with the address of the resource for which the user wishes to publish event state. The user may in turn have multiple User Agents or endpoints that publish event state. Each endpoint may publish its own unique state, out of which the event state compositor generates the composite event state of the resource. In addition to a particular resource, all published event state is associated with a specific event package. Through a subscription to that event package, the user is able to discover the composite event state of all of the active publications.
このドキュメントは新しいSIP方法、PUBLISHを出版イベント状態と定義します。 PUBLISHはユーザがそれでユーザを代表してこの状態を経営する別の実体で状態を創設して、変更して、取り除くという点においてREGISTERと同様です。 PUBLISH要求を記述するのは登録が要求するアドレシングと同じです。 PUBLISH要求のRequest-URIはユーザがイベント状態を発行したがっているリソースのアドレスで居住されます。 ユーザには、複数のUserエージェントかイベント状態を発行する終点が順番にあるかもしれません。 各終点はそれ自身のユニークな状態を発行するかもしれません。(イベント州の植字工はそれからリソースの合成イベント状態を発生させます)。 特定のリソースに加えて、すべての発行されたイベント状態が特定のイベントパッケージに関連しています。 そのイベントパッケージの購読で、ユーザはアクティブな刊行物のすべての合成イベント状態を発見できます。
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].
イベント状態を発行するUserエージェントClient(UAC)はEvent Publicationエージェント(EPA)とラベルされます。 存在において、これは[2]で定義されるように詳しいPresence Userエージェント(PUA)の役割です。 PUBLISH要求を処理する実体はEvent州Compositor(ESC)として知られています。 存在において、これは[2]で定義されるように詳しいPresenceエージェント(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
PUBLISH要求はESCで軟性国家を作成します。 このイベント軟性国家は、定義された生涯を持って、時間の買い取り金額の後に期限が切れるでしょう、公表がその後のPUBLISH要求でリフレッシュされるのが必要であることで。 また、特定のイベントパッケージのための各リソースのために食糧を供給されたイベントの固い状態があるかもしれません。 このイベント州はいつも存在していて、期限が切れないリソース状態を表します。 ESCは軟性国家かPUBLISHメカニズムを通して提供されたイベント軟性国家に、イベントの固い状態を使用するかもしれません。 設定
Niemi Standards Track [Page 4] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[4ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
this event hard state or configuring the ESC policy regarding the aggregation of different event state is out of the scope of this specification.
この仕様の範囲の外にこのイベントの固い状態か異なったイベント状態の集合に関するESC方針を構成するのがあります。
The body of a PUBLISH request carries the published event state. In response to every successful PUBLISH request, the ESC assigns an identifier to the publication in the form of an entity-tag. This identifier is then used by the EPA in any subsequent PUBLISH request that modifies, refreshes or removes the event state of that publication. When event state expires or is explicitly removed, the entity-tag associated with it becomes invalid. A publication for an invalid entity-tag will naturally fail, and the EPA needs to start anew and resend its event state without referencing a previous entity-tag.
PUBLISH要求のボディーは発行されたイベント状態を運びます。 あらゆるうまくいっているPUBLISH要求に対応して、ESCは実体タグの形で識別子を公表に割り当てます。 そして、この識別子はその公表のイベント状態を変更するか、リフレッシュするか、または取り除くどんなその後のPUBLISH要求でもEPAによって使用されます。 イベント状態を期限が切れるか、または明らかに取り除くとき、それに関連している実体タグは無効になります。 無効の実体タグのための刊行物が自然に失敗して、EPAは、前の実体タグに参照をつけないで新規まき直しで始めて、イベント状態を再送する必要があります。
4. Constructing PUBLISH Requests
4. 組み立てて、要求を発表してください。
PUBLISH requests create, modify, and remove event state associated with an address-of-record. A suitably authorized third party may also perform publication on behalf of a particular address-of-record.
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要求を送るクライアントの振舞いはRFC3261[4]のセクション8.1とセクション17.1で説明された一般的なUACの振舞いと同じです。
If necessary, clients may probe for the support of PUBLISH using the OPTIONS request defined in SIP [4]. The presence of "PUBLISH" in the "Allow" header field in a response to an OPTIONS request indicates support for the PUBLISH method. In addition, the "Allow-Events" header field indicates the supported event packages.
必要なら、クライアントは、PUBLISHのサポートのためにSIP[4]で定義されたOPTIONS要求を使用することで調べるかもしれません。 オプション要求へのa応答における「許容」ヘッダーフィールドにおける、「発行してください」の存在がサポートを示す、方法を発行してください。 添加で「出来事を許容する、」 ヘッダーフィールドは支持されたイベントパッケージについて簡単に述べます。
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以外のUserエージェントから応答を返してください。 その場合、PUBLISH方法のサポートはその特定のRequest-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.
PUBLISH要求は対話を確立しません。 UAC MAYはRFC3261[4]のセクション8.1で説明されるように先在のルートセットに基づくPUBLISH要求にRouteヘッダーフィールドを含んでいます。 Record-ルートヘッダーフィールドをPUBLISH要求か応答における意味でないのを持って、存在しているなら、無視しなければなりません。 特に、UAC MUST NOTはPUBLISH要求へのどんな応答でも、Record-ルートヘッダーフィールドの存在か欠如に基づく新しいルートセットを創設します。
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
PUBLISH要求がContactヘッダーフィールドを含むかもしれませんが、PUBLISH要求における1を含んでいるのは、イベント公表文脈に意味でないのを持って、ESCによって無視されるでしょう。 EPAはPUBLISHを送るかもしれません。
Niemi Standards Track [Page 5] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[5ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
request within an existing dialog. In that case, the request is received in the context of any media session or sessions associated with that dialog.
既存の対話の中で要求します。 その場合、その対話に関連しているどんなメディアセッションやセッションの文脈にも要求を受け取ります。
Note that while sending a PUBLISH request within an existing
dialog is not prohibited, it will typically not result in the
expected behavior. Unless the other end of the dialog is also an
ESC, it will probably reject the request.
既存の対話の中で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.
EPAは同じRequest-URIを求める新しいPUBLISH要求(再トランスミッションでない)を送ってはいけません、前のもののためのESCから最終的な応答を受けたか、または前のPUBLISH要求が外で時間があるまで。
4.1. Identification of Published Event State
4.1. 発行されたイベント状態の識別
Identification of published event state is provided by three pieces of information: Request-URI, event type, and (optionally) an entity- tag.
情報のスリーピースは発行されたイベント状態の識別を提供します: 要求URI、イベントタイプ、および(任意に)実体タグ。
The Request-URI of a PUBLISH request contains enough information to route the request to the appropriate entity per the request routing procedures outlined in RFC 3261 [4]. It also contains enough information to identify the resource whose event state is to be published, but not enough information to determine the type of the published event state.
PUBLISH要求のRequest-URIはRFC3261[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はPUBLISH要求でただ一つのEventヘッダーフィールドを含めなければなりません。 このヘッダーフィールドの値はこの要求がイベント状態を発行しているイベントパッケージについて簡単に述べます。
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.
それぞれのうまくいっているPUBLISHに関しては、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.
以前に発行されたイベント状態をアップデートするとき、PUBLISH要求がシングルを含まなければならない、SIP、マッチである、要求がリフレッシュするか、変更するか、または取り除いている特定のイベント状態を特定するヘッダーフィールド。 このヘッダーフィールドは前の刊行物への応答の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要求はボディーを含むかもしれません。(それは、クライアントが発行したがっているイベント状態を含みます)。 満足している形式と意味論はEventヘッダーフィールドで特定されたイベントパッケージに依存しています。
Niemi Standards Track [Page 6] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[6ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
The presence of a body and the SIP-If-Match header field determine the specific operation that the request is performing, as described in Table 1.
そして、ボディーの存在、SIP、マッチである、ヘッダーフィールドは要求が実行している特定の操作を決定します、Table1で説明されるように。
+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial | yes | no | > 0 |
| Refresh | no | yes | > 0 |
| Modify | yes | yes | > 0 |
| Remove | no | yes | 0 |
+-----------+-------+---------------+---------------+
+-----------+-------+---------------+---------------+ | 操作| ボディー? | マッチであるなら、ちびちび飲んでくれますか? | 値を吐き出します。| +-----------+-------+---------------+---------------+ | 初期| はい| いいえ| >0| | リフレッシュしてください。| いいえ| はい| >0| | 変更します。| はい| はい| >0| | 取り外してください。| いいえ| はい| 0 | +-----------+-------+---------------+---------------+
Table 1: Publication Operations
テーブル1: 公表操作
An 'Initial' publication sets the initial event state for a particular EPA. There may, of course, already be event state published by other EPAs (for the same address-of-record). That state is unaffected by an initial publication. A 'Refresh' publication refreshes the lifetime of a previous publication, whereas a 'Modify' publication modifies the event state of a previous publication. A 'Remove' publication requests immediate removal of event state. These operations are described in more detail in the following sections.
'初期'の刊行物は初期のイベント状態を特定のEPAに設定します。 もちろん、他のEPA(同じ記録されている住所のための)によって発行されたイベント状態が既にあるかもしれません。 その状態は初期の刊行物で影響を受けないです。 'リフレッシュしてください'という刊行物は前の刊行物の生涯をリフレッシュしますが、'変更'刊行物は前の刊行物のイベント状態を変更します。 '取り外してください'という刊行物はイベント状態の即座の取り外しを要求します。 これらの操作はさらに詳細に以下のセクションで説明されます。
4.2. Creating Initial Publication
4.2. 初期の公表を作成します。
An initial publication is a PUBLISH request created by the EPA and sent to the ESC that establishes soft state for the event package indicated in the Event header field of the request, and bound to the address in the Request-URI of the request.
初期の刊行物は要求のEventヘッダーフィールドで簡単に述べられたイベントパッケージのためにEPAによって作成されて、軟性国家を確立するESCに送られて、要求のRequest-URIにおけるアドレスに縛られた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.
初期のPUBLISH要求がaを含んではいけない、SIP、マッチである、ヘッダーフィールド。 しかしながら、EPAが適切で、局所的に格納された実体タグをまだ予想しているなら、有効であってください、それ。SHOULDは最初にセクション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.
初期のPUBLISH要求はただ一つのExpiresヘッダーフィールドを含むかもしれません。 この値はイベント州政府出版物の提案された生涯を示します。
Niemi Standards Track [Page 7] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[7ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
The ESC may lower the suggested lifetime of the publication, but it will never extend it. If an Expires header field is not present, the EPA is indicating its desire for the ESC to choose. The Expires header field in a 2xx response to the initial PUBLISH indicates the actual duration for which the publication will remain active. Unless refreshed before this lifetime is exceeded, the publication will expire.
ESCは公表の提案された生涯を下ろすかもしれませんが、それはそれを決して広げないでしょう。 Expiresヘッダーフィールドが存在していないなら、EPAはESCが選ぶ願望を示しています。 初期のPUBLISHへの2xx応答におけるExpiresヘッダーフィールドは公表のアクティブなままである実際の持続時間を示します。 この寿命が超えられる前にリフレッシュされないと、公表は期限が切れるでしょう。
4.3. Refreshing Event State
4.3. 壮快なイベント状態
An EPA is responsible for refreshing its previously established publications before their expiration interval has elapsed. To refresh a publication, the EPA MUST create a PUBLISH request that includes in a SIP-If-Match header field the entity-tag of the publication to be refreshed.
EPAは彼らの満了間隔が経過する前に以前に確立した刊行物をリフレッシュするのに責任があります。 刊行物をリフレッシュするために、EPAが中にaを含んでいるPUBLISH要求を作成しなければならない、SIP、マッチである、ヘッダーはリフレッシュされるために公表の実体タグをさばきます。
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、マッチである、実体タグを含むヘッダーフィールドが先の刊行物によって設置された特定のイベント状態をリフレッシュするというPUBLISH要求を条件とさせます。 実体タッグマッチが以前に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.
初期のPUBLISH要求への2xx応答、aへの2xx応答がリフレッシュするように、PUBLISH要求は実体タグがあるSIP-ETagヘッダーフィールドを含むでしょう。 どんな既存の実体タグにも壮快なイベント状態に取って代わって、EPAはこの実体タグを収納しなければなりません。 実体タグのEPA取り扱いの詳しい情報に関してセクション8.2を見てください。
If there is no matching event state, e.g., the event state to be refreshed has already expired, the EPA receives a 412 (Conditional Request Failed) response to the PUBLISH request.
合っているイベント状態が全くなければ、例えばリフレッシュされるべきイベント状態は既に期限が切れて、EPAはPUBLISH要求への412(条件付きのRequest Failed)応答を受けます。
A publication refresh MAY contain a single Expires header field. This value indicates the suggested lifetime of the event state.
公表がリフレッシュするAはただ一つのExpiresヘッダーフィールドを含むかもしれません。 この値はイベント状態の提案された生涯を示します。
The ESC may lower the suggested lifetime of the publication refresh, but it will never extend it. If an Expires header field is not present, the EPA is indicating its desire for the ESC to choose. The Expires header field in a 2xx response to the publication refresh indicates the actual duration for which the publication will remain active.
ESCは公表の寿命がリフレッシュする示唆を下ろすかもしれませんが、それはそれを決して広げないでしょう。 Expiresヘッダーフィールドが存在していないなら、EPAはESCが選ぶ願望を示しています。 公表への2xx応答におけるヘッダーフィールドがリフレッシュするExpiresは公表のアクティブなままである実際の持続時間を示します。
A publication refresh only extends the expiration time of already existing event state. It does not affect that event state in any other way. Therefore, a PUBLISH request that refreshes event state MUST NOT have a body.
公表がリフレッシュするAは既に既存のイベント状態の満了時間を延ばすだけです。 それはいかなる他の方法でもそのイベント状態に影響しません。 したがって、イベント状態をリフレッシュするPUBLISH要求はボディーを持ってはいけません。
Niemi Standards Track [Page 8] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[8ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
4.4. Modifying Event State
4.4. イベント状態を変更します。
Modifying event state closely resembles the creation of initial event state. However, instead of establishing completely new event state at the ESC, already existing event state is updated with modified event state. The nature of this update depends on the content of the body, and the semantics associated with the format of that body.
密接にイベント状態を変更すると、初期のイベント状態の創設は似通います。 しかしながら、ESCで完全に新しいイベント状態を設置することの代わりに、変更されたイベント状態と共に既に既存のイベント状態をアップデートします。 このアップデートの本質はボディーの内容、およびそのボディーの形式に関連している意味論によります。
To modify event state, the EPA MUST construct a PUBLISH request that includes in a SIP-If-Match header field the entity-tag of the event state publication to be modified. A PUBLISH request that modifies event state MUST contain a body that includes the modified event state.
イベント状態を変更するために、EPAが中にaを含んでいるPUBLISH要求を構成しなければならない、SIP、マッチである、ヘッダーは変更されるためにイベント州政府出版物の実体タグをさばきます。 イベント状態を変更する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、マッチである、ヘッダーフィールドは先の刊行物によって設置されて、実体タグによって特定された特定のイベント状態を変更するというPUBLISH要求を条件とさせます。 実体タッグマッチが以前に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.
初期のPUBLISH要求への2xx応答のように、PUBLISHが要求する変更への2xx応答は実体タグがあるSIP-ETagヘッダーフィールドを含むでしょう。 どんな既存の実体タグにも変更されたイベント状態に取って代わって、EPAはこの実体タグを収納しなければなりません。 実体タグのEPA取り扱いの詳しい情報に関してセクション8.2を見てください。
If there is no matching event state at the ESC, e.g., the event state to be modified has already expired, the EPA receives a 412 (Conditional Request Failed) response to the PUBLISH request.
ESC、例えば、出来事の州が変更されるために既に期限が切れたと述べる合っている出来事が全くなければ、EPAはPUBLISH要求への412(条件付きのRequest Failed)応答を受けます。
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は公表の提案された生涯を下ろすかもしれませんが、それはそれを決して広げないでしょう。 Expiresヘッダーフィールドが存在していないなら、EPAはESCが選ぶ願望を示しています。 PUBLISHが要求する変更への2xx応答におけるExpiresヘッダーフィールドは公表のアクティブなままである実際の持続時間を示します。 この寿命が超えられる前にリフレッシュされないと、公表は期限が切れるでしょう。
4.5. Removing Event State
4.5. イベント状態を取り除きます。
Event state established by a prior publication may also be explicitly removed.
また、明らかに先の刊行物によって設置されたイベント状態を取り除くかもしれません。
Niemi Standards Track [Page 9] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[9ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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がExpires値でPUBLISH要求を作成しなければならない、「0インチ、一口を設定してください、--マッチヘッダーが、実体タグを含むのをさばくなら出来事では、公表を述べて、取り除いてください、」
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.
リフレッシュするために出来事が、述べる同様であることで、イベント状態の取り外しはイベント状態の満期に影響するだけです。 したがって、イベント状態を取り除くPUBLISH要求はボディーを含んではいけません。
5. Processing PUBLISH Responses
5. 処理して、応答を発行してください。
When processing responses to PUBLISH requests, the steps in Section 8.1.2 of RFC 3261 [4] apply.
PUBLISH要求への応答を処理するとき、.2セクション8.1RFC3261[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(条件付きのRequest Failed)応答を受けるなら、それはPUBLISH要求を「再-試み」てはいけません。 イベント状態を発行するために、代わりに、EPA SHOULDは初期の刊行物を実行します、すなわち、aのないPUBLISH要求、SIP、マッチである、セクション4.2で説明されるようなヘッダーフィールド。 また、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(間隔Too Brief)応答を受けるなら、中では、満了間隔より等しいか、またはすばらしくなるようにExpiresヘッダーフィールドで満了間隔を変えた後に公表を再試行するかもしれない、423(間隔Too Brief)応答のヘッダーフィールドをMin吐き出します。
6. Processing PUBLISH Requests
6. 処理して、要求を発表してください。
The Event State Compositor (ESC) is a User Agent Server (UAS) that processes and responds to PUBLISH requests, and maintains a list of publications for a given address-of-record. The ESC has to know (e.g., through configuration) the set of addresses for which it maintains event state.
Event州Compositor(ESC)は与えられた記録されている住所のためにPUBLISH要求に処理して、応じて、刊行物のリストを維持するUserエージェントServer(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 MUSTはRecord-ルートヘッダーフィールドを無視します。 ESC MUST NOTはPUBLISH要求へのどんな応答にもRecord-ルートヘッダーフィールドを含んでいます。 1つがPUBLISH要求に存在しているなら、ESC MUSTはContactヘッダーフィールドを無視します。
Niemi Standards Track [Page 10] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[10ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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.
同じくらいがあるそれらがオーダーですが、受け取って、Request-ユリを処理しなければならないPUBLISH要求。 また、原子論的に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はRFC3261[4]のセクション8.2で一般的なUASの振舞いを定義する方法に従います。 さらに、PUBLISH特異的行動のために、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を点検します。 そうでなければ、404(Foundでない)応答を返して、ESC MUSTは残っているステップをサボります。
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はPUBLISH要求のEventヘッダーフィールドを調べます。 Eventヘッダーフィールドがなくなるか、またはESCが支えないイベントパッケージを含んでいるなら、ESC MUSTは489(悪いEvent)応答でPUBLISH要求に応じて、残っているステップをサボります。
3. The ESC examines the SIP-If-Match header field of the PUBLISH
request for the presence of a request precondition.
3. ESCが調べる、SIP、マッチである、要求前提条件の存在を求めるPUBLISH要求のヘッダーフィールド。
* 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.
* 要求がaを含んでいない、SIP、マッチである、ヘッダーフィールド、ESC MUSTは公表を特定するための局所的にユニークな実体タグを発生して、収納します。 この実体タグは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.
* ほか、要求でaがある、SIP、マッチである、ヘッダーフィールド、ESCは、ヘッダーフィールドが単一の実体タグを含むかどうかチェックします。 そうでなければ、要求が無効であり、ESC MUSTは400(無効のRequest)応答とともに帰って、残っているステップをサボります。
* 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.
* SIPに含まれて、ほかに、ESCは実体タグを抽出します。--マッチヘッダーがそれをさばいて、合っているなら、すべてに対する実体タグはこのリソースとイベントパッケージのために局所的に実体タグを収納しました。 マッチが全く見つけられないなら、ESC MUSTは412(条件付きのRequest Failed)の応答で公表を拒絶して、残っているステップをサボります。
Niemi Standards Track [Page 11] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[11ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
4. The ESC processes the Expires header field value from the PUBLISH
request.
4. ESCはPUBLISH要求からExpiresヘッダーフィールド価値を処理します。
* If the request has an Expires header field, that value MUST be
taken as the requested expiration.
* 要求にExpiresヘッダーフィールドがあるなら、要求された満了としてその値をみなさなければなりません。
* Else, a locally-configured default value MUST be taken as the
requested expiration.
* ほかに、要求された満了として局所的に構成されたデフォルト値をみなさなければなりません。
* The ESC MAY choose an expiration less than the requested
expiration interval. Only if the requested expiration interval
is greater than zero and less than a locally-configured
minimum, the ESC MAY reject the publication with a response of
423 (Interval Too Brief), and skip the remaining steps. This
response MUST contain a Min-Expires header field that states
the minimum expiration interval the ESC is willing to honor.
* ESC MAYは要求された満了間隔ほど満了を選びません。 要求された満了間隔がゼロと以下より局所的に構成された最小限、ESC MAYより大きい場合にだけ、423(間隔Too Brief)の応答で公表を拒絶してください、そして、残っているステップをサボってください。 この応答はaを含まなければなりません。ESCが光栄に思っても構わないと思っている最小の満了間隔を述べるヘッダーフィールドをMin吐き出します。
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 MUSTは415などの適切な応答(サポートされないメディアType)で要求を拒絶して、ステップの残りをスキップします。
* 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.
* 要求がメッセージ本体を全く持たないで、また実体タグを全く含まなかったなら、ESC SHOULDは400などの適切な応答(無効のRequest)で要求を拒絶して、ステップの残りをスキップします。 あるいはまた、ESCのローカルの方針かイベントパッケージのどちらかがメッセージ本体を全く含まない初期の刊行物のために意味論を定義したといけないので、ESC MAYはそれを受け入れます。
* 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 MUST NOTはそのような要求の結果、どんなイベント状態も格納します。
Niemi Standards Track [Page 12] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[12ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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 MUSTは504などの適切な誤り応答(外のサーバTime)に応じて失敗して、最後のステップをサボります。
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によって選ばれた満了間隔を示すExpiresヘッダーフィールドを含まなければなりません。 また、応答は公表を特定しながら単一の実体タグを含むSIP-ETagヘッダーフィールドを含まなければなりません。 そのイベント状態に関連している前のどんな実体タグも取り替えて、ESC MUSTはそれぞれのうまくいっている公表のために新しい実体タグを発生させます。 発生している実体タグは、現在割り当てられているいかなる他の実体タグからそのRequest-URIに関連しているイベント状態にもユニークでなければならなく、そのRequest-URIにおいて、以前に割り当てられたどんな実体タグからイベント状態までも異なっているに違いありません。 実体タグのESC取り扱いの詳しい情報に関してセクション8.3を見てください。
7. Processing OPTIONS Requests
7. 処理オプション要求
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.
クライアントは、PUBLISHのサポートのためにSIP[4]で定義されたOPTIONS要求を使用することでESCを調べるかもしれません。 ESCはRFC3261[4]のセクション11.2で定義されるようにOPTIONS要求を処理します。 OPTIONS要求への応答では、ESC SHOULDが中に許容方法のリストへの「発行してください」を含んでいる、ヘッダーフィールドを許容してください。 それ、もSHOULDはAllow-イベントヘッダーフィールドで支持されたイベントパッケージを記載します。
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 Capabilities[12]を見ます。)
8. Use of Entity-tags in PUBLISH
8. 実体タグの使用は中で発行されます。
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の実体タグ用法の概要を作ります。 それは、現実に有益であり、その結果、どんな標準のプロトコル記述も含んでいません。
8.1. General Notes
8.1. 一般注意事項
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:
PUBLISHメカニズムはHTTP/1.1[13]で定義されるように実体タグを利用します。 主な機能性は保存されますが、実体タグと対応するヘッダーフィールドのための構文と意味論は特に使用のために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 実体タグのための構文は引用文字列の代わりに象徴です。 また、弱い実体タグを示すために定義された接頭語が全くありません。
Niemi Standards Track [Page 13] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[13ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
o A PUBLISH precondition can only apply to a single entity-tag, so
request preconditions with multiple entity-tags are not allowed.
o PUBLISH前提条件が単一の実体タグに申し込まれることができるだけであるので、複数の実体タグがある前提条件が許容されていないよう要求してください。
o A request precondition can't apply to "any" entity, namely there
is no special "*" entity-tag value defined for PUBLISH.
o 「any」の実体に要求前提条件は適用できないで、すなわち、実体タグ値が定義したどんな特別な「*」もない、発行してください。
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帰りでは、PUBLISH ESCsの起源サーバはそうですが、いつもに必要であることで、うまくいっている刊行物のために実体タグを返してください。
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 PUT。(そのHTTP PUTに関して、キャッシュ合法化における特徴が実体タグを使用する部分集合だけがHTTP/1.1で許容されています)。 それはほとんどイベント状態へのこの部分集合以外の特徴を可能にする意味を公表にしません。
To make it apparent that the entity-tags usage in PUBLISH is similar but not identical to HTTP/1.1, we have not adopted the header field names directly from HTTP/1.1, but rather have created similar but distinct names, as can be seen in Section 11.
私たちは、PUBLISHの実体タグ用法がHTTP/1.1と同様ですが、同じでないことを明らかにするように、直接HTTP/1.1からヘッダーフィールド名を採用しませんが、むしろ同様の、しかし、異なった名前を作成しました、セクション11で見ることができるように。
8.2. Client Usage
8.2. クライアント用法
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(条件付きのRequest Failed)応答に応じて要求が失敗するなら、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実現まで達しています。
8.3. Server Usage
8.3. サーバ用法
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がアクティブな刊行物のセットで主要な検索として使用できる実体タグを含むでしょう。
Niemi Standards Track [Page 14] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[14ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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つ増加される整数カウンタが公表を処理したのでそれを実行することです。 実体タグを発生させるための他の、そして、等しく有効な方法は存在しています、そして、このドキュメントはただ一つの道のためのどんな推薦状も好みもしません。
9. Controlling the Rate of Publication
9. 公表のレートを制御します。
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で影響を受けることができます。 それは、EPAがそれが示すことにより長い満了値を選ぶと主張できて、ESCがローカルのデフォルト最小であるといけないので、満了値に達していません。 より長いデフォルトを最小に維持して、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 MAYは503(サービスUnavailable)でPUBLISH要求に応じます、RFC3261[4]で定義されるように。 この応答SHOULDは公表ソースが別のPUBLISH要求を送るまで待たなければならない時間間隔を示すヘッダーフィールドの後にRetryを含みます。
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で負荷を管理することに対する仕事は始めであることです。(その始めはイベント州政府出版物システムで負荷を管理するためのさらなるツールを提供できるかもしれません)。
10. Considerations for Event Packages using PUBLISH
10. 使用が発行するイベントパッケージのための問題
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メカニズムをイベントパッケージに適用するとき考慮に入れられるべきであるいくつかの問題について論じます。 また、それは存在公表に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.
どんな将来のイベントパッケージ仕様SHOULDもPUBLISHを使用するための問題の議論を含んでいます。 最小限では、それらの問題SHOULDは本章に提示された問題を記述して、追加問題を含むかもしれません。
Niemi Standards Track [Page 15] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[15ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
10.1. PUBLISH Bodies
10.1. ボディーを発行してください。
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メカニズムの応用が、どんな満足しているタイプかタイプが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.
Presence(CPP)存在情報Data Format(PIDF)[6]のためのCommon Profileが使用されているとき、このドキュメントは存在公表要求(イベントパッケージ「存在」)の意味論を定義します。 存在状態をPAに発行するのにPUBLISHを使用するPUAはPIDF存在形式を支持しなければなりません。 それは他の形式を支持するかもしれません。
10.2. PUBLISH Response Bodies
10.2. 応答本体を発行してください。
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.
存在刊行物への応答のボディーのためのどんなそのような意味もありません。
10.3. Multiple Sources for Event State
10.3. イベント状態への複数のソース
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)に集めるのに原因となる単一体、および複数のソースのものです。(或るものだけがソースからPUBLISHメカニズムを使用しているかもしれません)。
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メカニズムSHOULDを利用するイベントパッケージは、イベント州政府出版物のためのこのモデルが適切であるかどうか説明して、複数のソースからの刊行物に集めるのに使用される特定のメカニズムについて説明するかもしれません。
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に受け取る存在ドキュメントに合成されるかもしれないtuplesの部分集合のための存在状態を発行できます。 ESCがこの情報に集めるメカニズムは、ローカルの方針の問題であり、この仕様の範囲からのそうです。
Niemi Standards Track [Page 16] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[16ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
10.4. Event State Segmentation
10.4. イベント州の分割
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つと定義されます。 満足しているタイプがイベント状態のそのような分割を支持するどんなイベントパッケージ、SHOULDはこれらのイベント州のセグメントが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はtuplesの「イド」属性を実体タグの文脈で一貫しているように保たなければなりません。 刊行物がtupleのコンテンツを変更するなら、そのtupleはオリジナルの「イド」を維持しなければなりません。 ESCは要求が到着した実体タグの文脈の各tupleを解釈するでしょう。 オリジナルの公表と比べて、「イド」がなくなるtupleは取り除かれると考えられるでしょう。 同様に、tupleは、「イド」属性がオリジナルの公表が含まなかったものであるなら加えられながら、解釈されます。
10.5. Rate of Publication
10.5. 公表のレート
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で公表のレートを制御するのと議論します。 または、個人種目パッケージが順番に推薦を定義するかもしれない、(SHOULD、強さ) 刊行物が単一のEPAによって発生できる絶対最大値レートでそうしなければなりません。
There are no rate limiting recommendations for presence publication.
存在公表のためのレート制限推薦が全くありません。
11. Protocol Element Definitions
11. プロトコル要素定義
This section describes the extensions required for event publication in SIP.
このセクションはSIPでのイベント公表に必要である拡大について説明します。
11.1. New Methods
11.1. 新しい方法
11.1.1. PUBLISH Method
11.1.1. 方法を発行してください。
"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とTable3は追加コラムを加えることによって、RFC3261[4]のTables2と3を広げています、PUBLISH要求と応答に使用できるヘッダーフィールドを定義して。 これらのテーブルのキーはRFC3261[4]のセクション20で指定されます。
Niemi Standards Track [Page 17] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[17ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
+---------------------+---------+---------+ | 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 | +---------------------+---------+---------+
+---------------------+---------+---------+ | ヘッダーフィールド| どこ| 発行してください。| +---------------------+---------+---------+ | 受け入れてください。| R| o | | 受け入れてください。| 2xx| - | | 受け入れてください。| 415 | m*| | コード化を受け入れます。| R| o | | コード化を受け入れます。| 2xx| - | | コード化を受け入れます。| 415 | m*| | 言語を受け入れます。| R| o | | 言語を受け入れます。| 2xx| - | | 言語を受け入れます。| 415 | m*| | 注意深いインフォメーション| | - | | 許容します。| R| o | | 許容します。| r| o | | 許容します。| 405 | m| | 出来事を許容します。| R| o | | 出来事を許容します。| 489 | m| | 認証インフォメーション| 2xx| o | | 認可| R| o | | 呼び出しID| c| m| | 呼び出しインフォメーション| | o | | 接触| R| - | | 接触| 1xx| - | | 接触| 2xx| - | | 接触| 3xx| o | | 接触| 485 | o | | 満足している気質| | o | | 内容をコード化しています。| | o | | 満足している言語| | o | | コンテンツの長さ| | t| | コンテントタイプ| | * | | CSeq| c| m| | 日付| | o | | 出来事| R| m| | 誤りインフォメーション| 300-699 | o | | 期限が切れます。| | o | | 期限が切れます。| 2xx| m| | from| c| m| | in reply to| R| - | | 前方へマックス| R| m| | 分期限が切れます。| 423 | m| | MIMEバージョン| | o | | 組織| | o | +---------------------+---------+---------+
Table 2: Summary of header fields, A--O
テーブル2: A--ヘッダーフィールドの概要、O
Niemi Standards Track [Page 18] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[18ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
+---------------------+-----------------+---------+ | 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 | +---------------------+-----------------+---------+
+---------------------+-----------------+---------+ | ヘッダーフィールド| どこ| 発行してください。| +---------------------+-----------------+---------+ | 優先権| R| o | | プロキシで認証します。| 407 | m| | プロキシで認証します。| 401 | o | | プロキシ認可| R| o | | プロキシで必要です。| R| o | | 記録的なルート| | - | | 答えます。| | - | | 必要です。| | o | | -後に再試行してください。| 404,413,480,486 | o | | -後に再試行してください。| 500,503 | o | | -後に再試行してください。| 600,603 | o | | ルート| R| c| | サーバ| r| o | | 対象| R| o | | 支持されます。| R| o | | 支持されます。| 2xx| o | | タイムスタンプ| | o | | to| c(1)| m| | サポートされない| 420 | o | | ユーザエージェント| | o | | via| R| m| | via| rc| m| | 警告| r| o | | WWW認証します。| 401 | m| | WWW認証します。| 407 | o | +---------------------+-----------------+---------+
Table 3: Summary of header fields, P--Z
テーブル3: P--ヘッダーフィールドの概要、Z
11.2. New Response Codes
11.2. 新しい応答コード
11.2.1. "412 Conditional Request Failed" Response Code
11.2.1. 「412条件付き要求は失敗した」という応答コード
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(条件付きのRequest Failed)応答は「クライアント誤り」ヘッダーフィールド定義に加えられます。 412 (条件付きのRequest Failed)は、要求のために与えられた前提条件が失敗したのを示すのに使用されます。
Niemi Standards Track [Page 19] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[19ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
11.3. New Header Fields
11.3. 新しいヘッダーフィールド
Table 4, Table 5, and Table 6 expand on Table 3 in SIP [4], as amended by the changes in Section 11.1.
テーブル4、Table5、およびTable6はSIP[4]でTable3について詳述します、セクション11.1における変化によって修正されるように。
+--------------+-------+-------+-----+-----+-----+-----+-----+ | Header Field | where | proxy | ACK | BYE | CAN | INF | INV | +--------------+-------+-------+-----+-----+-----+-----+-----+ | SIP-ETag | 2xx | | - | - | - | - | - | | SIP-If-Match | R | | - | - | - | - | - | +--------------+-------+-------+-----+-----+-----+-----+-----+
+--------------+-------+-------+-----+-----+-----+-----+-----+ | ヘッダーフィールド| どこ| プロキシ| ACK| さようなら| 缶| INF| INV| +--------------+-------+-------+-----+-----+-----+-----+-----+ | 一口ETag| 2xx| | - | - | - | - | - | | マッチであるなら、ちびちび飲んでください。| 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 | | - | - | - | - | - | +--------------+-------+-------+-----+-----+-----+-----+-----+
+--------------+-------+-------+-----+-----+-----+-----+-----+ | ヘッダーフィールド| どこ| プロキシ| NOT| 選んでください。| PRA| レッジ| 潜水艦| +--------------+-------+-------+-----+-----+-----+-----+-----+ | 一口ETag| 2xx| | - | - | - | - | - | | マッチであるなら、ちびちび飲んでください。| 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 |
+--------------+-------+-------+-----+-----+-----+---------+
+--------------+-------+-------+-----+-----+-----+---------+ | ヘッダーフィールド| どこ| プロキシ| UPD| エムエスジー| 審判| 発行してください。| +--------------+-------+-------+-----+-----+-----+---------+ | 一口ETag| 2xx| | - | - | - | m| | マッチであるなら、ちびちび飲んでください。| R| | - | - | - | o | +--------------+-------+-------+-----+-----+-----+---------+
Table 6: Summary of header fields, P--Z
テーブル6: P--ヘッダーフィールドの概要、Z
11.3.1. "SIP-ETag" Header Field
11.3.1. 「一口ETag」ヘッダーフィールド
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で説明されます。
11.3.2. "SIP-If-Match" Header Field
11.3.2. 「マッチであるなら、ちびちび飲んでいる」ヘッダーフィールド
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、マッチである、SIPメッセージ文法との要素「一般的なヘッダー」の定義に加えられて. このヘッダーの使用法がセクション4とセクション6で説明されるということです。
Niemi Standards Track [Page 20] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[20ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
12. Augmented BNF Definitions
12. 増大しているBNF定義
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]で使用されるAugmented 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/象徴キャップ拡大方法によるPUBLISH=SIP-ETag=「一口ETag」HCOLON実体タグ、SIP、マッチである、= 「マッチであるなら、ちびちび飲んでください」というHCOLON実体タグ実体タグ=象徴
13. IANA Considerations
13. IANA問題
This document registers a new method name, a new response code and two new header field names.
このドキュメントは新しい方法名、新しい応答コード、および2つの新しいヘッダーフィールド名を示します。
13.1. Methods
13.1. 方法
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]
13.2. Response Codes
13.2. 応答コード
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デフォルト理由句: 条件付き要求は失敗しました。
13.3. Header Field Names
13.3. ヘッダーフィールド名
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)
ヘッダー名: 一口ETagコンパクト形: (なにも)
Niemi Standards Track [Page 21] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[21ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
Header Name: SIP-If-Match
Compact Form: (none)
ヘッダー名: マッチであるならちびちび飲んでいるコンパクト形: (なにも)
14. Security Considerations
14. セキュリティ問題
14.1. Access Control
14.1. アクセス管理
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.
州のエージェントSHOULDはEPAを認証します、そして、SHOULDは認可方針(例えば、アクセスコントロールリストに基づいている)をすべての要求に適用します。 構成モデルは同じネットワークの上、または、同じ管理ドメインに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.
ESCsとEPAは、RFC3261[4]で定義されるようにPUBLISH要求を認証するためにDigestを実行しなければなりません。 このドキュメントの範囲の外にESCのアクセス管理方針を作成して、操るための正確な方法があります。
14.2. Denial of Service Attacks
14.2. サービス不能攻撃
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].
そのような攻撃の可能性を小さくするために、ESCs SHOULDの実現はPUBLISH要求の認証を必要とします。 実現はRFC3261[4]で定義されるようにDigest認証を支持しなければなりません。
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 SHOULDはイベント状態の変化から生じる入って来る刊行物と対応する通知を阻止します。 第一歩として、ESCでの支持されたイベントパッケージが限界を助けることができるので、最小のExpiresヘッダーフィールドが評価するデフォルトの厳選はイベント状態をリフレッシュします。
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要求の結果、作成された通知交通を抑えるのにおいて賢明です。
14.3. Replay Attacks
14.3. 反射攻撃
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
PUBLISH要求を再演すると、有害な影響を持つことができます。 攻撃者は過去に何らかのポイントで実行されるのにおいてそれが目撃したどんなイベント州政府出版物も実行できるかもしれません、そのPUBLISH要求を再演することによって。 特に、そのような再生メッセージはそうするかもしれません。
Niemi Standards Track [Page 22] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[22ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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.
使用されて、古いイベント州の情報をだましてください、versioningメカニズム、例えば、州の情報のタイムスタンプは、そのような攻撃を緩和するのを助けるかもしれませんが。
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].
反射攻撃を防ぐために、実現はRFC3261[4]で定義されるように反復操作による保護でDigest認証を支持しなければなりません。 SIP[4]で反射攻撃を打ち返すためのさらなるメカニズムについて議論します。
14.4. Man in the Middle Attacks
14.4. 中央攻撃でやれやれ
Even with authentication, man-in-the-middle attacks using PUBLISH may be used to install arbitrary event state information, modify or remove existing event state information in publications, or even remove event state altogether at an ESC.
認証があっても、PUBLISHを使用する介入者攻撃は、任意のイベント州の情報をインストールするか、刊行物で既存のイベント州の情報を変更するか、取り除く、またはESCで全体でイベント状態を取り除くのさえ使用されるかもしれません。
To prevent such attacks, implementations SHOULD, at a minimum, provide integrity protection across the To, From, Event, SIP-If- Match, Route, and Expires header fields and the bodies of PUBLISH requests.
最小限で、そのような攻撃を防ぐために、実現SHOULDはToの向こう側に保全保護を提供します、From、Event、SIP、-、-合ってください、とRoute、およびExpiresヘッダーはさばいて、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要求では、NOTIFY要求でこのイベント状態の加入者にそれを露出する前に、ESC MUST NOTはイベント状態を変更します。 これは、終わりから終わりへのイベント状態の保全を保持するためのものです。
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].
保全保護のために、ESCsはTLS[8]を実行しなければならなくて、互いの、そして、片道の両方の認証を支持しなければならなくて、また、SIP[4]で定義されたSIPS URI計画を支持しなければなりません。 EPA SHOULD、TLSを開始できてください。そうすれば、SHOULDはSIPS URI計画を支持します。 ESCsとEPAはSIP[4]で定義されるように保全保護のためのS/MIME[9]を支持するかもしれません。
14.5. Confidentiality
14.5. 秘密性
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].
秘密性を提供するために、ESCsはTLS[8]を実行しなければならなくて、互いの、そして、片道の両方の認証を支持しなければならなくて、また、SIP[4]で定義されたSIPS URI計画を支持しなければなりません。 EPA SHOULD、TLSを開始できてください。そうすれば、SHOULDはSIPS URI計画を支持します。 ESCsとEPAはSIP[4]で定義されるようにイベント州の情報の暗号化のためのS/MIME[9]を支持するかもしれません。
Niemi Standards Track [Page 23] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[23ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
15. Examples
15. 例
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からのpresentityの存在情報に加入しています。 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-長さのヘッダーフィールドの値がある」とき、」 これは、値がボディーの計算された長さがことなら何でもであるべきであるか意味します。
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 ----- |
| | |
プアのPAウォッチャー(EPA)(ESC)| | | | | <、-、-、-- M1: 登録--- | | | | | | ----- M2: 200 OK----->|、|、|、|、|、| ----- M3: 通知してください。----->|、|、|、|、|、| <、-、-、-- M4: 200 OK------ | | | | | | | | ---- M5: 発行してください。--->|、|、|、|、|、| <-- M6: 200 OK---- | | | | | | | ----- M7: 通知してください。----->|、|、|、|、|、| <、-、-、-- M8: 200 OK------ | | | | | ---- M9: 発行してください。--->|、|、|、|、|、| <-- M10: 200 OK--- | | | | | | | | | --- M11: 発行してください。--->|、|、|、|、|、| <-- M12: 200 OK---- | | | | | | | ----- M13: 通知してください。---->|、|、|、|、|、| <、-、-、-- M14: 200 OK----- | | | |
Niemi Standards Track [Page 24] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[24ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
Message flow:
メッセージ流動:
M1: The watcher initiates a new subscription to the
presentity@example.com's presence agent.
M1: ウォッチャーは presentity@example.com の存在エージェントに新規申込みを開始します。
SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Contact: sip:user@host.example.com
Content-Length: 0
一口: 登録、 presentity@example.com SIP/2.0Via: 一口/2.0/UDP host.example.com; ブランチ=z9hG4bKnashds7To: <一口: presentity@example.com 、gt;、From: <一口: watcher@example.com 、gt;、; タグは12341234呼び出しIDと等しいです: 12345678@host.example.com CSeq: 1 前方へマックスを申し込んでください: 70 期限が切れます: 3600年の出来事: 存在Contact: 一口: user@host.example.com のContent-長さ: 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
以下を通って一口/2.0 200OK 一口/2.0/UDP host.example.com; ブランチはz9hG4bKnashds7と等しいです; =192.0.2.1To:を受けます。 <一口: presentity@example.com 、gt;、;=abcd1234From:にタグ付けをしてください <一口: watcher@example.com 、gt;、; タグは12341234呼び出しIDと等しいです: 12345678@host.example.com CSeq: 1 接触を申し込んでください: 一口: pa.example.com Expires: 3600年のコンテンツの長さ: 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: 過程を完了するために、存在エージェントはpresentityの現在の存在状態がある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: ...
NOTIFY一口: user@host.example.com SIP/2.0Via: 一口/2.0/UDP pa.example.com; ブランチ=z9hG4bK8sdf2To: <一口: watcher@example.com 、gt;、;=12341234From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =abcd1234呼び出しIDにタグ付けをしてください: 12345678@host.example.com CSeq: 1 前方へマックスに通知してください: 70出来事: 存在Subscription-州: アクティブ。 =3599Contactを吐き出します: 一口: pa.example.comコンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
Niemi Standards Track [Page 25] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[25ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
[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
以下を通って一口/2.0 200OK 一口/2.0/UDP pa.example.com; ブランチはz9hG4bK8sdf2と等しいです; =192.0.2.2To:を受けます。 <一口: watcher@example.com 、gt;、;=12341234From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =abcd1234呼び出しIDにタグ付けをしてください: 12345678@host.example.com CSeq: 1 通知してください。
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: 存在ユーザエージェント(presentityの代理をする)は、新しい存在情報でそれをアップデートするために存在エージェントにPUBLISH要求を開始します。 Expiresヘッダーフィールドはこのイベント軟性国家のために提案された持続時間を示します。
PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...
PUBLISH一口: presentity@example.com SIP/2.0Via: 一口/2.0/UDP pua.example.com; ブランチ=z9hG4bK652hsge To: <一口: presentity@example.com 、gt;、From: <一口: presentity@example.com 、gt;、; =1234wxyz呼び出しIDにタグ付けをしてください: 81818181@pua.example.com CSeq: 1 前方へマックスを発行してください: 70 期限が切れます: 3600年の出来事: 存在コンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
[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: 存在エージェントは、存在公表を受け取って、受け入れます。 公表データはpresentityの存在情報に組み入れられます。
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
以下を通って一口/2.0 200OK 一口/2.0/UDP pua.example.com; ブランチはz9hG4bK652hsgeと等しいです; =192.0.2.3To:を受けます。 <一口: presentity@example.com 、gt;、;=1a2b3c4d From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =1234wxyz呼び出しIDにタグ付けをしてください: 81818181@pua.example.com CSeq: 1 一口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: 存在エージェントは、報告可能変化がpresentityの存在情報に作られていて、新しい存在通知をウォッチャーに送ると決心しています。
Niemi Standards Track [Page 26] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[26ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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: ...
NOTIFY一口: user@host.example.com SIP/2.0Via: 一口/2.0/UDP pa.example.com; ブランチ=z9hG4bK4cd42a To: <一口: watcher@example.com 、gt;、;=12341234From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =abcd1234呼び出しIDにタグ付けをしてください: 12345678@host.example.com CSeq: 2 前方へマックスに通知してください: 70出来事: 存在Subscription-州: アクティブ。 =3400Contactを吐き出します: 一口: pa.example.comコンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
[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
以下を通って一口/2.0 200OK 一口/2.0/UDP pa.example.com; ブランチはz9hG4bK4cd42aと等しいです; =192.0.2.2To:を受けます。 <一口: watcher@example.com 、gt;、;=12341234From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =abcd1234呼び出しIDにタグ付けをしてください: 12345678@host.example.com CSeq: 2 コンテンツの長さに通知してください: 0
M9: The PUA determines that the event state it previously published
is about to expire, and refreshes that event state.
M9: PUAは、それが以前に発行したイベント州が期限が切れようとしていて、そのイベント状態をリフレッシュすることを決定します。
PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: dx200xyz
Expires: 3600
Event: presence
Content-Length: 0
PUBLISH一口: presentity@example.com SIP/2.0Via: 一口/2.0/UDP pua.example.com; ブランチ=z9hG4bK771ash02To: <一口: presentity@example.com 、gt;、From: <一口: presentity@example.com 、gt;、; =1234kljk呼び出しIDにタグ付けをしてください: 98798798@pua.example.com CSeq: 1 前方へマックスを発行してください: 70 マッチであるなら、ちびちび飲んでください: dx200xyz Expires: 3600年の出来事: 存在のContent-長さ: 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への応答で実体タグを返します。 ウォッチャーがNOTIFYsを全く受け取らないように、どんな実際の州の変化も起こっていないことに注意してください。
Niemi Standards Track [Page 27] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[27ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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
以下を通って一口/2.0 200OK 一口/2.0/UDP pua.example.com; ブランチはz9hG4bK771ash02と等しいです; =192.0.2.3To:を受けます。 <一口: presentity@example.com 、gt;、;=2affde434From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =1234kljk呼び出しIDにタグ付けをしてください: 98798798@pua.example.com CSeq: 1 一口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: presentityのPUAはユーザの存在状態の変化を検出します。 それは、最近の変化に伴う発行された存在情報を変更するために存在エージェントにPUBLISH要求を開始します。
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: ...
PUBLISH一口: presentity@example.com SIP/2.0Via: 一口/2.0/UDP pua.example.com; ブランチ=z9hG4bKcdad2To: <一口: presentity@example.com 、gt;、From: <一口: presentity@example.com 、gt;、; 54321mmの=呼び出しIDにタグ付けをしてください: 5566778@pua.example.com CSeq: 1 前方へマックスを発行してください: 70 マッチであるなら、ちびちび飲んでください: kwj449x Expires: 3600年の出来事: 存在コンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
[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からの前の公表をアップデートして、公表データはpresentityの存在情報に組み入れられます。
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
以下を通って一口/2.0 200OK 一口/2.0/UDP pua.example.com; ブランチはz9hG4bKcdad2と等しいです; =192.0.2.3To:を受けます。 <一口: presentity@example.com 、gt;、;=effe22aa From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; 54321mmの=呼び出しIDにタグ付けをしてください: 5566778@pua.example.com CSeq: 1 一口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: 存在エージェントは、報告可能変化がpresentityの存在ドキュメントに作られていて、新しい存在通知をすべての活発な購読に送ると決心しています。
Niemi Standards Track [Page 28] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[28ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
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: ...
NOTIFY一口: user@host.example.com SIP/2.0Via: 一口/2.0/UDP pa.example.com; ブランチ=z9hG4bK32defd3To: <一口: watcher@example.com 、gt;、;=12341234From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =abcd1234呼び出しIDにタグ付けをしてください: 12345678@host.example.com CSeq: 2 前方へマックスに通知してください: 70出来事: 存在Subscription-州: アクティブ。 =3400Contactを吐き出します: 一口: pa.example.comコンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
[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
以下を通って一口/2.0 200OK 一口/2.0/UDP pa.example.com; ブランチはz9hG4bK32defd3と等しいです; =192.0.2.3To:を受けます。 <一口: watcher@example.com 、gt;、;=12341234From:にタグ付けをしてください <一口: presentity@example.com 、gt;、; =abcd1234呼び出しIDにタグ付けをしてください: 12345678@host.example.com CSeq: 2 コンテンツの長さに通知してください: 0
16. Contributors
16. 貢献者
The original contributors to this specification are:
この仕様への元の貢献者は以下の通りです。
Ben Campbell
Estacado Systems
ベンキャンベルエスタカードSystems
Sean Olson
Microsoft
ショーンオルソンマイクロソフト
Jon Peterson
Neustar, Inc.
ジョンピーターソンNeustar Inc.
Jonathan Rosenberg
dynamicsoft
ジョナサンローゼンバーグdynamicsoft
Brian Stucker
Nortel Networks, Inc.
ブライアンStuckerノーテルはInc.をネットワークでつなぎます。
Niemi Standards Track [Page 29] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[29ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
17. Acknowledgements
17. 承認
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、Hisham Khartabil、ジョージFoti、キースDrage、Samir Srivastava、アルンクマー、アダム・ローチ、ペッカPessi、カイワング、Cullenジョニングス、ミッコLonnfors、エバ-マリアLeppanen、エルンスト・ホルバート、Thanos Diacakis、オーデッドCnaan、Rohanマーイ、およびディーン・ウィリス。
18. References
18. 参照
18.1. Normative References
18.1. 引用規格
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[1] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[2] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[2] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[3] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[3] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、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"、1997年11月のRFC2234。
[8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[8] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[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は仕様を通信する」RFC3851、7月2004日
Niemi Standards Track [Page 30] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[30ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
19.2. Informative References
19.2. 有益な参照
[10] Campbell, B., "SIMPLE Presence Publication Requirements", Work
in Progress, February 2003.
[10] キャンベル、B.、「簡単な存在公表要件」が進歩、2003年2月に働いています。
[11] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[11] マーイ、R.、「セッション開始のためのメッセージ概要とメッセージ待ち指示イベントパッケージは(一口)について議定書の中で述べます」、RFC3842、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] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[13] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
Author's Address
作者のアドレス
Aki Niemi (editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
FIN00045フィンランドのアキNiemi(エディタ)ノキア私書箱407Nokia Group
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
以下に電話をしてください。 +358 50 389 1644はメールされます: aki.niemi@nokia.com
Niemi Standards Track [Page 31] RFC 3903 SIP Event State Publication October 2004
Niemi標準化過程[31ページ]RFC3903はイベント州政府出版物2004年10月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Niemi Standards Track [Page 32]
Niemi標準化過程[32ページ]
一覧
スポンサーリンク
