Network Working Group A. Niemi, Ed. Request for Comments: 3903 Nokia Category: Standards Track October 2004 イベントステート発行のための セッション開始プロトコル(SIP)拡張 Session Initiation Protocol (SIP) Extension for Event State Publication 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書では、セッション開始プロトコル(Session Initiation Protocol/SIP) のイベントフレームワーク内で使用されるイベントステートを発行する、SIP 拡張を説明する。本拡張の第一の適用先は、プレゼンス情報の発行である。 本文書で説明される仕組みは、どのイベントステートの発行に対応するように 拡張することもできるが、その用途では他に適切なイベントパッケージが存在 する。本文書は、任意データを送信するための一般的な用途の仕組みを意図し たものではない。その用途では、より適切な仕組みが存在する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 定義および文書規約 . . . . . . . . . . . . . . . . . . . . . 3 3. 操作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. PUBLISHリクエストの構築 . . . . . . . . . . . . . . . . . . 5 4.1. 発行済みイベントステートの識別 . . . . . . . . . . . . 6 4.2. 最初の発行の作成 . . . . . . . . . . . . . . . . . . . 7 4.3. イベントステートの更新 . . . . . . . . . . . . . . . . 8 4.4. イベントステートの修正 . . . . . . . . . . . . . . . . 9 4.5. イベントステートの削除 . . . . . . . . . . . . . . . . 9 5. PUBLISH応答の処理 . . . . . . . . . . . . . . . . . . . . . 10 6. PUBLISHリクエストの処理 . . . . . . . . . . . . . . . . . . 10 7. OPTIONSリクエストの処理 . . . . . . . . . . . . . . . . . . 13 8. PUBLISHでのエンティティタグ使用 . . . . . . . . . . . . . . 13 Niemi Standards Track [Page 1] RFC 3903 SIP Event State Publication October 2004 8.1. 一般的な注記 . . . . . . . . . . . . . . . . . . . . . 13 8.2. クライアントの用法 . . . . . . . . . . . . . . . . . . 14 8.3. サーバーの用法 . . . . . . . . . . . . . . . . . . . . 14 9. 発行頻度の制御 . . . . . . . . . . . . . . . . . . . . . . . 15 10. PUBLISHを使用したイベントパッケージの考慮事項 . . . . . . . 15 10.1. PUBLISHのボディ . . . . . . . . . . . . . . . . . . . 16 10.2. PUBLISHの応答ボディ . . . . . . . . . . . . . . . . . 16 10.3. イベントステートの複数ソース . . . . . . . . . . . . . 16 10.4. イベントステートのセグメント化 . . . . . . . . . . . . 17 10.5. 発行頻度 . . . . . . . . . . . . . . . . . . . . . . . 17 11. プロトコル要素の定義 . . . . . . . . . . . . . . . . . . . . 17 11.1. 新しいメソッド . . . . . . . . . . . . . . . . . . . . 17 11.1.1. PUBLISHメソッド . . . . . . . . . . . . . . . 17 11.2. 新しい応答コード . . . . . . . . . . . . . . . . . . . 19 11.2.1. 「412 Conditional Request Failed」応答コード . 19 11.3. 新しいヘッダーフィールド . . . . . . . . . . . . . . . 20 11.3.1. 「SIP-ETag」ヘッダーフィールド . . . . . . . . 20 11.3.2. 「SIP-If-Match」ヘッダーフィールド . . . . . . 20 12. Augmented BNFの定義 . . . . . . . . . . . . . . . . . . . . 21 13. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. メソッド . . . . . . . . . . . . . . . . . . . . . . . 21 13.2. 応答コード . . . . . . . . . . . . . . . . . . . . . . 21 13.3. ヘッダーフィールド名 . . . . . . . . . . . . . . . . . 21 14. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . 22 14.1. アクセス制御 . . . . . . . . . . . . . . . . . . . . . 22 14.2. DoS攻撃 . . . . . . . . . . . . . . . . . . . . . . . 22 14.3. リプレイ攻撃 . . . . . . . . . . . . . . . . . . . . . 22 14.4. man-in-the-middle攻撃 . . . . . . . . . . . . . . . . 23 14.5. 機密性 . . . . . . . . . . . . . . . . . . . . . . . . 23 15. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 16. 寄稿者 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 17. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 18. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 18.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . 30 18.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . 31 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . 32 1. はじめに 本仕様では、ユーザーエージェントからエンティティにイベントステートを発 行するためのフレームワークを提供する。このエンティティとは、イベントス テートを合成し、またそれをSIPイベント(参考文献[1])のフレームワークに よって関連するパーティに配信する役割を持つものである。 Niemi Standards Track [Page 2] RFC 3903 SIP Event State Publication October 2004 イベント発行フレームワークの定義とは別に、本仕様では、プレゼンスステー ト(参考文献[2])の発行フレームワークについて、プレゼンスユーザーエー ジェント(参考文献[3])がプレゼンスコンポジタ(プレゼンスエージェントとの 関係と密接に関係性を持つ)に対して使用する場合の具体的な用法についても 定義する。 プレゼンス発行の要件およびモデルは、参考文献[10]にまとめられている。本 仕様は、これらの各要件を扱う。 本文書で説明される仕組みは、どのイベントステートの発行に対応するように 拡張することもできるが、参考文献[1]で定義されるように、その用途では他 に適切なイベントパッケージが存在する。たとえば、メッセージ待ち指示(参 考文献[11])のSIPイベントを持つアプリケーションでは、PUBLISHメカニズム を使用して、複数ユーザーエージェントにわたる音声メールボックスのステー タスを収集することを選択することもある。このようなアプリケーションのコ ンポジタは、このステートを収集して、イベントパッケージのサブスクライバ に配布する責任を持つ。 イベントステートの発行でPUBLISHメカニズムを利用するアプリケーション は、個々にセクション10の指針を順守する必要がある。本文書で説明されてい るメカニズムは、任意のデータを伝送するための汎用的なメカニズムを目標と したものではない。汎用的なメカニズムは他にあるためである。 2. 定義および文書規約 RFC 2778(参考文献[3])、RFC 3265(参考文献[1])およびRFC3261(参考文献[4]) の定義に加え、本文書は、以下の新たな概念を導入する。 イベントステート(Event State): リソースのステート情報。イベントパッ ケージおよびAddresses-of-Recordに関連付けられる。 イベントパッケージエージェント(Event Publication Agent/EPA): イベント ステートを公開するときにPUBLISHリクエストを発行するユーザーエージェ ントクライアント(User Agent Client/UAC)。 イベントステートコンポジタ(Event State Compositor/ESC): PUBLISHリクエ ストを処理し、イベントステートを完全なリソースの複合イベントステー ト(composite event state)へと合成する役割を持つ、ユーザーエージェン トサーバー(User Agent Server/UAS)。 プレゼンスコンポジタ(Presence Compositor): イベントステートコンポジタ の一種。プレゼンティティのプレゼンスステートを構成する役割を持つ。 発行(Publication): イベントステートを発行するときにPUBLISHリクエストを ESCに送信する、EPAの動作。 イベントハードステート(Event Hard State): リソースの定常ステートまたは デフォルトのイベントステート。ソフトステートの発行がない場合、また はソフトステートの発行とは別に、ESCが使用できる。 Niemi Standards Track [Page 3] RFC 3903 SIP Event State Publication October 2004 イベントソフトステート(Event Soft State): PUBLISHメカニズムを使用する EPAによって発行されるイベントステート。ESCで特定のソフトステートエ ンティティを識別するために、プロトコル要素(つまりエンティティタグ) が使用される。ソフトステートには、定義済みの生存時間があり、また、 ネゴシエートされた時間後に期限切れとなる。 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119のBCP 14(参考文献[5])に 記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベ ルを示すものである。 この文章のように字下げされた部分は、本文書では、補足情報の提示およ び文書を明確にするために使用される。この部分には規範的なプロトコル 動作の記述は含まれない。 3. 操作概要 本文書は、新規のSIPメソッドであるPUBLISHを、イベントステートの発行のた めに定義する。PUBLISHとREGISTERとは、ユーザーの代わりにステートを管理 する他のエンティティにおいて、ユーザーがステートを作成、修正および削除 できるようになる、という点で似ている。PUBLISHリクエストのアドレス指定 は、SUBSCRIBEリクエストのアドレス指定と同じである。PUBLISHのRequest- URIは、ユーザーがイベントステートを発行したいリソースのアドレスに設定 される。言い替えると、ユーザーは、イベントステートを発行するユーザー エージェント(User Agent)またはエンドポイントを複数持つことができる。各 エンドポイントは、イベントステートコンポジタがリソースの複合イベントス テートを生成するのとは別に、自身の一意なステートを発行できる。特定のリ ソースに加え、すべての発行済みイベントステートは特定のイベントパッケー ジに関連付けられる。そのイベントパッケージに対するサブスクリプションに よって、ユーザーは、すべてのアクティブな発行の複合イベントステートを検 出できる。 イベントステートを発行するユーザーエージェントクライアント(User Agent Client/UAC)は、イベント発行エージェント(Event Publication Agent/EPA)と 呼ばれる。プレゼンスでは、参考文献[2]で定義されているように、通常のプ レゼンスユーザーエージェント(Presence User Agent/PUA)の役割を持つ。 PUBLISHリクエストを処理するエンティティは、イベントステートコンポジタ (Event State Compositor/ESC)と呼ばれる。プレゼンスでは、参考文献[2]で 定義されているように、通常のプレゼンスエージェント(Presence Agent/PA) の役割を持つ。 PUBLISHリクエストはESCにおいてソフトステートを作成する。このイベントソ フトステートは、定義済みの生存時間を持ち、ネゴシエートされた時間後に期 限切れとなり、また、次のPUBLISHリクエストによって更新される発行を必要 とする。特定のイベントパッケージの各リソースごとに、組み込まれたイベン トハードステートも存在する可能性がある。イベントステートとは、常時存在 し、期限切れしないリソースステートを示す。ESCは、PUBLISHの仕組みによっ て提供されるイベントソフトステートがない場合に、あるいはイベントソフト ステートとは別に、イベントハードステートを使用する可能性がある。このイ Niemi Standards Track [Page 4] RFC 3903 SIP Event State Publication October 2004 ベントハードステートの設定方法、または多様なイベントステートの集積に関 するESCポリシーは、本仕様の範囲外である。 PUBLISHリクエストのボディは、発行済みのイベントステートを伝達する。正 常に送信されたすべてのPUBLISHリクエストに対する応答で、ESCは、エンティ ティタグの形式でその発行に識別子を割り当てる。この識別子は、後続の PUBLISHリクエスト(発行のイベントステートを修正、更新、または削除)で、 EPAによって使用される。イベントステートが期限切れになるか、明示的に削 除された場合、それに関連付けられていたエンティティタグは無効になる。無 効なエンティティタグの発行は当然ながら失敗するため、EPAは、以前のエン ティティタグを参照することなく、イベントステートを再び開始し、再送信す る必要がある。 4. PUBLISHリクエストの構築 PUBLISHリクエストは、Addresses-of-Recordに関連付けられるイベントステー トを、作成、修正、および削除する。適切に認可されたサードパーティもま た、特定のAddresses-of-Recordの代わりに発行を実行してもよい。 注記で除外されているように、PUBLISHリクエストの構築、およびPUBLISHリク エストを送信するクライアントの動作は、RFC3261(参考文献[4])のセクション 8.1およびセクション17.1に記載されている一般的なUACの動作と同一である。 必要に応じて、クライアントは、SIP(参考文献[4])で定義されているOPTIONS リクエストを使用して、PUBLISHの対応について打診してもよい。OPTIONSリク エストに対する応答で、「Allow」ヘッダーフィールドに「PUBLISH」が存在す ると、PUBLISHメソッドに対応していることを示す。さらに、「Allow- Events」ヘッダーフィールドは、対応するイベントパッケージを示す。 OPTIONSリクエストはフォークし、その結果、ESCではなくユーザーエー ジェントから応答が返ってくる可能性がある、ということに注意。その場 合、PUBLISHメソッドへの対応は、その特定のRequest-URI用に正しく示さ れていない可能性がある。 PUBLISHリクエストでは、ダイアログが確立されない。UACは、既存のルート セットに基づいて、PUBLISHリクエストにRouteヘッダーフィールドを含めても よい[MAY](RFC 3261(参考文献[4])のセクション8.1参照)。Record-Routeヘッ ダーフィールドは、PUBLISHリクエストまたは応答では何ら意味がなく、提示 されていても無視されるべきである[MUST]。特に、UACは、Record-Routeヘッ ダーフィールドがPUBLISHリクエストに対する応答に存在すること、または存 在しないことに基づいて、新規のルートセットを作成してはならない[MUST NOT]。 PUBLISHリクエストには、Contactヘッダーフィールドを含めてもよい[MAY] が、イベント発行の場合は意味がなく、あってもESCは無視する。EPAは既存の Niemi Standards Track [Page 5] RFC 3903 SIP Event State Publication October 2004 ダイアログ内でPUBLISHリクエストを送信してもよい[MAY]。この場合、リクエ ストは、任意のメディアセッション、またはそのダイアログに関連付けられて いるセッションのコンテキストで受信される。 既存のダイアログ内でPUBLISHリクエストを送信することは禁止されていな いが、通常、期待する動作結果にはならない。ダイアログのもう一方の終 端もESCではない場合、リクエストはおそらく拒否される。 EPAは、前のPUBLISHリクエストに対してESCから最終応答を受信するまで、あ るいは、前のPUBLISHリクエストが期限切れになるまで、同じRequest-URIに対 して新規のPUBLISHリクエストを送信(再送ではない)してはならない[MUST NOT]。 4.1. 発行済みイベントステートの識別 発行済みイベントステートの識別は、Request-URI、イベントタイプ、(オプ ションの)エンティティタグという3つの情報で可能になる。 PUBLISHリクエストのRequest-URIには、RFC 3261(参考文献[4])で概要説明さ れているリクエストルーティング手順によって、適切なエンティティへのリク エストをルートできる、十分な情報が含まれている。また、Request-URIに は、イベントステートが発行されるリソースを識別するための十分な情報も含 まれているが、発行済みのイベントステートのタイプを判別するためには情報 が足りない。 発行済みイベントステートのタイプを判別するには、EPAは1つのEventヘッ ダーフィールドをPUBLISHリクエストに含めなければならない[MUST]。この ヘッダーフィールドの値はイベントパッケージを示し、このリクエストは、そ れによってイベントステートを発行している。 正常に送信された各PUBLISHリクエストの場合、ESCはエンティティタグを生成 および割り当てて、それを2xx応答のSIP-ETagヘッダーフィールドで返す。 以前に発行されたイベントステートを更新する場合は、リクエストによって更 新、修正、または削除される特定のイベントステートを識別する1つのSIP-If- Matchヘッダーフィールドを、PUBLISHリクエストに含めなければならない [MUST]。このヘッダーフィールドには、ESCが前の発行に対する応答のSIP- ETagヘッダーフィールドで返す、1つのエンティティタグを含めなければなら ない[MUST]。 PUBLISHリクエストには、ボディを含めてもよい[MAY]。このボディには、クラ イアントが発行を希望するイベントステートが含まれる。内容の形式とセマン ティクスは、Eventヘッダーフィールドで特定されるイベントパッケージに依 存する。 Niemi Standards Track [Page 6] RFC 3903 SIP Event State Publication October 2004 ボディとSIP-If-Matchヘッダーフィールドが存在することで、リクエストが実 行する具体的な操作が決定する(表1参照)。 +-----------+-------+---------------+---------------+ | Operation | Body? | SIP-If-Match? | Expires Value | +-----------+-------+---------------+---------------+ | Initial | yes | no | > 0 | | Refresh | no | yes | > 0 | | Modify | yes | yes | > 0 | | Remove | no | yes | 0 | +-----------+-------+---------------+---------------+ 表1: 発行操作 「最初の」発行は、特定のEPAについて最初のイベントステートを設定する。 当然ながら、(同じAddresses-of-Recordの)他のEPAから発行されたイベントス テートがすでに存在する場合がある。このステートは、最初の発行による影響 を受けない。「更新」発行は、前回の発行の生存時間を更新する。一方で、 「修正」発行は、前回の発行のイベントステートを修正する。「削除」発行 は、イベントステートをただちに削除するように要求する。これらの操作の詳 細については、以降のセクションで記載される。 4.2. 最初の発行の作成 最初の発行とは、EPAによって作成されたPUBLISHリクエストのことで、リクエ ストのEventヘッダーフィールドで示されたイベントパッケージのソフトス テートを確立したESCに送信され、リクエストのRequest-URIに含まれるアドレ スに結合される。 最初のPUBLISHリクエストには、SIP-If-Matchヘッダーフィールドを含めては ならない[MUST NOT]。ただし、EPAは、ローカルに保存された適切なエンティ ティタグがまだ有効であると予想する場合、セクション4.4で説明されている ように、最初の発行を実行するのではなく、そのイベントステートの修正を最 初に試行すべきである[SHOULD]。 最初のPUBLISHリクエストには、発行済みのイベントステートを示したボディ を含めなければならない[MUST]。 最初のPUBLISHリクエストには、1つのExpiresヘッダーフィールドを含めても よい[MAY]。この値は、イベントステート発行の生存時間の提案を示す。 Niemi Standards Track [Page 7] RFC 3903 SIP Event State Publication October 2004 ESCは、提示された発行の生存時間を少なくすることはできるが、延長はしな い。Expiresヘッダーフィールドが存在しない場合、EPAは、ESCに対して選択 するように希望を示す。最初のPUBLISHに対する2xx応答にあるExpiresヘッ ダーフィールドは、発行が有効な状態を保つ実際の継続期間を示す。この生存 時間が終了する前に更新されなければ、発行は期限切れになる。 4.3. イベントステートの更新 EPAには、期限切れの間隔が過ぎる前に、以前に確立した発行を更新する役割 がある。発行を更新するには、EPAは、SIP-If-Matchヘッダーフィールドに更 新される発行のエンティティタグを含むPUBLISHリクエストを作成しなければ ならない[MUST]。 エンティティタグを含むSIP-If-Matchヘッダーフィールドは、PUBLISHリクエ ストに対して、前の発行で確立された特定のイベントステートを更新する、と いう条件を課す。エンティティタグがESCで前に発行された有効なイベントス テートにマッチする場合、更新は成功し、また、EPAは2xx応答を受け取る。 最初のPUBLISHリクエストに対する2xx応答と同様に、更新のPUBLISHリクエス トに対する2xx応答には、エンティティタグ付きのSIP-ETagヘッダーフィール ドが含まれる。EPAは、このエンティティタグを格納しなければならない [MUST]。また、このとき、既存のエンティティタグは、更新されたイベントス テートで置換される。EPAによるエンティティタグ処理の詳細については、セ クション8.2を参照。 マッチするイベントステートがない場合、たとえば、更新されるイベントス テートがすでに期限切れの場合、EPAは、PUBLISHリクエストに対して412 (Conditional Request Failed)応答を受け取る。 発行の更新には、1つのExpiresヘッダーフィールドを含めてもよい[MAY]。こ の値は、イベントステートの生存時間案を示す。 ESCは、提示された発行更新の生存時間を少なくすることはできるが、延長は しない。Expiresヘッダーフィールドが存在しない場合、EPAは、ESCに対して 選択するように希望を示す。発行更新に対する2xx応答にあるExpiresヘッダー フィールドは、発行が有効な状態を保つ実際の継続期間を示す。 発行の更新は、既存のイベントステートの有効期間を延長するのみである。他 の面ではイベントステートに影響を与えない。そのため、イベントステートを 更新するPUBLISHリクエストには、ボディが存在してはならない[MUST NOT]。 Niemi Standards Track [Page 8] RFC 3903 SIP Event State Publication October 2004 4.4. イベントステートの修正 イベントステートの修正は、最初のイベントステートの作成と非常によく似て いる。ただし、まったく新規のイベントステートをESCで確立するのではな く、既存のイベントステートが修正されたイベントステートで更新される。こ の更新の性質は、ボディの内容と、そのボディの形式に関連付けられるセマン ティクスによって異なる。 イベントステートを修正するには、EPAは、SIP-If-Matchヘッダーフィールド に修正されるイベントステート発行のエンティティタグを含むPUBLISHリクエ ストを構築しなければならない[MUST]。イベントステートを修正するPUBLISH リクエストには、修正対象のイベントステートを指定したボディを含めなけれ ばならない[MUST]。 SIP-If-Matchヘッダーフィールドには、PUBLISHリクエストに対して、前の発 行で確立され、エンティティタグによって識別される特定のイベントステート を、PUBLISHリクエストが修正する、という条件を課している。エンティティ タグがESCで前に発行されたイベントステートにマッチする場合、そのイベン トステートはPUBLISHリクエストで伝達されるイベントステートで置換され、 また、EPAは2xx応答を受け取る。 最初のPUBLISHリクエストに対する2xx応答と同様に、修正のPUBLISHリクエス トに対する2xx応答には、エンティティタグ付きのSIP-ETagヘッダーフィール ドが含まれる。EPAは、このエンティティタグを格納しなければならない [MUST]。また、このとき、既存のエンティティタグは、修正されたイベントス テートで置換される。EPAによるエンティティタグ処理の詳細については、セ クション8.2を参照。 ESCでマッチするイベントステートがない場合、たとえば、修正されるイベン トステートがすでに期限切れの場合、EPAは、PUBLISHリクエストに対して412 (Conditional Request Failed)応答を受け取る。 修正のPUBLISHリクエストには、1つのExpiresヘッダーフィールドを含めても よい[MAY]。この値は、イベントステート発行の生存時間の提案を示す。 ESCは、提示された発行の生存時間を少なくすることはできるが、延長はしな い。Expiresヘッダーフィールドが存在しない場合、EPAは、ESCに対して選択 するように希望を示す。修正のPUBLISHリクエストに対する2xx応答にある Expiresヘッダーフィールドは、発行が有効な状態を保つ実際の継続期間を示 す。この生存時間が終了する前に更新されなければ、発行は期限切れになる。 4.5. イベントステートの削除 前の発行で確立されたイベントステートもまた、明示的に削除される。 Niemi Standards Track [Page 9] RFC 3903 SIP Event State Publication October 2004 イベントステートを直ちに削除することを要求するには、EPAは、「0」の Expires値を指定したPUBLISHリクエストを作成し、削除するイベントステート 発行のエンティティタグを含むSIP-If- Matchヘッダーフィールドを設定しな ければならない[MUST]。 イベントステートの削除は、事実上、非常に小さい期限切れ間隔を提案す る発行の更新である、ということに注意。結果として、更新されたイベン トステートは、更新後、直ちに期限切れとなる。 イベントステートの更新と同様に、イベントステートの削除は、イベントス テートの有効期限にのみ影響を与える。そのため、イベントステートを削除す るPUBLISHリクエストには、ボディが存在してはならない[MUST NOT]。 5. PUBLISH応答の処理 PUBLISHリクエストに対する応答を処理する場合、RFC 3261(参考文献[4])のセ クション8.1.2の手順が適用される。 EPAが412 (Conditional Request Failed)応答を受け取る場合、PUBLISHリクエ ストを再試行(reattempt)してはならない[MUST NOT]。代わりに、イベントス テートを発行するには、EPAは、最初の発行、言い替えると、セクション4.2で 説明されているように、SIP-If-MatchヘッダーフィールドがないPUBLISHリク エストを、実行すべきである[SHOULD]。また、EPAは、このエラー応答を生成 したエンティティタグも破棄しなければならない[MUST]。 EPAがPUBLISHリクエストに対して423 (Interval Too Brief)応答を受け取った 場合、Expiresヘッダーフィールドの期限切れ間隔を変更してから、発行を再 試行してもよい[MAY]。このとき、423 (Interval Too Brief)応答のMin- Expiresヘッダーフィールド内の期限切れ間隔以上の値にする。 6. PUBLISHリクエストの処理 イベントステートコンポジタ(Event State Compositor/ESC)は、PUBLISHリク エストの処理と応答を行い、指定されたAddresses-of-Recordの発行一覧を維 持する、ユーザーエージェントサーバー(User Agent Server/UAS)である。ESC は、イベントステートを維持するアドレスのセットを(たとえば構成によって) 知っている必要がある。 ESCは、PUBLISHリクエストに含まれるRecord-Routeヘッダーフィールドを無視 しなければならない[MUST]。ESCは、PUBLISHリクエストへの応答にRecord- Routeヘッダーフィールドを含めてはならない[MUST NOT]。ESCは、PUBLISHリ クエストに存在するContactヘッダーフィールドを無視しなければならない [MUST]。 Niemi Standards Track [Page 10] RFC 3903 SIP Event State Publication October 2004 同じRequest-URIを持つPUBLISHリクエストは、受け取った順に処理されなけれ ばならない[MUST]。PUBLISHリクエストはまた、不可分に処理されなければな らない[MUST]。不可分とは、特にPUBLISHリクエストが完全に処理されるか、 あるいはまったく処理されない、ということを意味する。 PUBLISHリクエストを受信すると、ESCは、RFC 3261(参考文献[4])のセクショ ン8.2で定義されている一般的なUAS動作の手順に従う。さらに、PUBLISH固有 の動作の場合には、ESCは以下の手順に従う。 1. ESCは、Request-URIを調べて、自身がイベントステートの維持に責任を持 つリソース宛てのリクエストかどうかを決定する。そうではない場合、ESC は404 (Not Found)応答を返し、残りの手順を省略しなければならない [MUST]。 Request-URIは、ESCが責任を持たないドメインを指している可能性もあ る。この場合、リクエストを受け取ったUASは、プロキシサーバーの役割を 仮定して、リクエストをより適切な対象に転送(forward)することができ る。 2. ESCは、PUBLISHリクエストのEventヘッダーフィールドを検証する。Event ヘッダーフィールドがない場合、または、ESCが対応していないイベント パッケージを含む場合、ESCはそのPUBLISHリクエストに対して489 (Bad Event)応答を返し、残りの手順を省略しなければならない[MUST]。 3. ESCは、PUBLISHリクエストのSIP-If-Match header fieldヘッダーフィール ドに、リクエストの前提条件があるかどうかを検証する。 * リクエストにSIP-If-Matchヘッダーフィールドが含まれない場合、ESC は、発行を識別するために、ローカルで一意なエンティティタグを生成 して保存しなければならない[MUST]。このエンティティタグは、 PUBLISHリクエストのボディで伝達されるイベントステートに関連付け られる。 * 前項以外の場合、リクエストにSIP-If-Matchヘッダーフィールドがある 場合、ESCはそのヘッダーフィールドに1つのエンティティタグがあるか どうかを確認する。ない場合はリクエストは無効であり、ESCは400 (Invalid Request)応答を返し、残りの手順を省略しなければならない [MUST]。 * 上の2つの項以外の場合、ESCは、Self-If-Matchヘッダーフィールドに 含まれるエンティティタグを抽出し、そのエンティティタグを、このリ ソースとイベントパッケージ用にローカルに保存されたエンティティタ グすべてとマッチさせる。マッチが見つからない場合、ESCは412 (Conditional Request Failed)応答で発行を拒否し、残りの手順を省略 しなければならない[MUST]。 Niemi Standards Track [Page 11] RFC 3903 SIP Event State Publication October 2004 4. ESCは、PUBLISHリクエストのExpiresヘッダーフィールドを処理する。 * リクエストにExpiresヘッダーフィールドがある場合、その値は、要求 された期限切れとして扱わなければならない[MUST]。 * それ以外の場合、ローカルで構成されたデフォルト値を要求される期限 切れとして扱わなければならない[MUST]。 * ESCは、要求される期限切れ間隔よりも短い期限切れを選択してもよい [MAY]。要求される期限切れ間隔が0よりも大きく、かつローカルで構成 された最小値よりも小さい場合にのみ、ESCは、423 (Interval Too Brief)応答で発行を拒否し、残りの手順を省略してもよい[MAY]。この 応答には、ESCが順守する最小の期限切れ間隔を提示する、Min-Expires ヘッダーフィールドを含めなければならない[MUST]。 5. ESCは、PUBLISHリクエストのボディに含まれる発行済みイベントステート を処理する。リクエストのコンテンツタイプがイベントパッケージと一致 しない場合、またはESCがリクエストのコンテンツタイプを理解しない場 合、ESCは、415(Unsupported Media Type)などの適切な応答でリクエスト を拒否し、以降の手順を省略しなければならない[MUST]。 * PUBLISHリクエストのボディで配信され、対応するエンティティタグで 識別されるイベントステートは、ESCで格納される。既存のイベントス テートはそのエンティティタグで更新される。期限切れ値は、選択した 期限切れ間隔に設定される。 * リクエストにメッセージボディがなく、エンティティタグが含まれない 場合、ESCは、400 (Invalid Request)など、リクエストを適切な応答で 拒否し、残りの手順を省略すべきである[SHOULD]。または、ESCのロー カルポリシーまたはイベントパッケージのどちらかが、メッセージボ ディのない最初の発行用にセマンティクスを定義していた場合、ESCは その定義を受け入れてもよい[MAY]。 * その他の場合、エンティティタグによって識別されるイベントステート は更新され、選択された期限切れ間隔に期限切れ値を設定する。 * 選択された期限切れ間隔が「0」という特殊な値の場合、そのエンティ ティタグで識別されるイベントステートは、直ちに削除されなければな らない[MUST]。ESCは、このようなリクエストの結果として、イベント ステートを何も格納してはならない[MUST NOT]。 Niemi Standards Track [Page 12] RFC 3903 SIP Event State Publication October 2004 PUBLISHリクエストの処理は不可分でなければならない[MUST]。処理の完了 前に内部エラー(バックエンドのデータベースにアクセスできない、など) が発生した場合、発行を成功としてはならない[MUST NOT]。また、ESCは、 504 (Server Time-out)応答など、適切なエラー応答で失敗し、最後の手順 を省略しなければならない[MUST]。 6. ESCは200 (OK)応答を返す。応答には、ESCが選択した期限切れ間隔を示す Expiresヘッダーフィールドを含めなければならない[MUST]。応答には、発 行を識別する1 つのエンティティタグを指定したSIP-ETagヘッダーフィー ルドも含めなければならない[MUST]。ESCは、発行が成功するごとに、新規 のエンティティタグを生成しなければならない[MUST]。このとき、そのイ ベントステートと関連付けられる前のエンティティタグは置換される。生 成されるエンティティタグは、そのRequest-URIと関連付けられたイベント ステートに割り当たっている他のエンティティタグとは識別できなければ ばならない[MUST]。また、そのRequest-URIのイベントステートに以前割り 当てられていたエンティティタグとも区別しなければならない[MUST]。ESC によるエンティティタグ処理の詳細については、セクション8.3を参照。 7. OPTIONSリクエストの処理 クライアントは、ESCに対し、SIP(参考文献[4])で定義されているOPTIONSリク エストを使用して、PUBLISHの対応について打診してもよい。ESCは、RFC 3261 (参考文献[4])のセクション11.2で定義される通りに、OPTIONSリクエストを処 理する。OPTIONSリクエストの応答で、ESCは、Allowヘッダーフィールドの許 容されるメソッド一覧に、「PUBLISH」を含めるべきである[SHOULD]。また、 「Allow-Events」ヘッダーフィールドに、対応するイベントパッケージを列挙 すべきである[SHOULD]。 また、Allowヘッダーフィールドを使用して、登録時にPUBLISHメッセージへの 対応を具体的に宣言することもできる(詳細はSIP能力(参考文献[12])を参 照)。 8. PUBLISHでのエンティティタグ使用 ここでは、PUBLISHのエンティティタグについて、用法を概説する。このセク ションは通知の目的で書かれており、規範的なプロトコル記述は含まれていな い。 8.1. 一般的な注記 PUBLISHの仕組みは、HTTP/ 1.1(参考文献[13])で定義されているエンティティ タグを利用する。主な機能性は維持されているが、PUBLISHメソッドでの用途 に合わせて、エンティティタグの構文とセマンティクス、および対応するヘッ ダーフィールドが改変されている。主な違いは以下の通り。 o エンティティタグの構文は、引用符で囲まれた文字列ではなくトークンで ある。弱い(weak)エンティティタグを示すために定義される接頭辞もな い。 Niemi Standards Track [Page 13] RFC 3903 SIP Event State Publication October 2004 o PUBLISHの前提条件は、1つのエンティティタグにのみ適用できる。そのた め、複数のエンティティタグを持つリクエストは許容されていない。 o リクエストの前提条件は、「すべての」エンティティには適用できない。 PUBLISHでは、特殊な「*」エンティティタグ値は定義されていない。 o HTTP/1.1では、元のサーバーがエンティティタグを返すことはオプション だが、PUBLISHの場合、ESCは、正常な発行のときに常にエンティティタグ を返す必要がある。 上記のような改変の主な理由は、PUBLISHが概念的にHTTPのPUTであるためであ る。したがって、エンティティタグを使用したキャッシュの検証における機能 のサブセットのみが、HTTP/1.1で許容されている。このイベントステート発行 用のサブセット以外の機能を有効にすることは、ほとんど意味がない。 PUBLISHでのエンティティタグの用法がHTTP/1.1と似ているが同一ではない、 ということをわかりやすくするために、ヘッダーフィールド名をHTTP/1.1から 直接採用せず、似ているが区別できる名前を作成した(セクション11参照)。 8.2. クライアントの用法 発行が成功すると、発行ごとにエンティティタグが割り当てられる。次に、エ ンティティタグはPUBLISHリクエストへの応答でEPAに配信される。EPAはその エンティティタグを保存する必要があり、また、そのイベントステートで以前 のエンティティタグは置換される。リクエストが412 (Conditional Request Failed)応答で失敗した場合、EPAは、エラーを起こしたエンティティタグを破 棄する。 エンティティタグは、EPAにとって不透明なトークン(opaque tokens)である。 EPAは、エンティティタグから単純な識別子以上のセマンティクスを推測した り、特定の形式を仮定することはできない。エンティティタグは、単調に増加 していくカウンタの可能性もあれば、まったくランダムなトークンである可能 性もある。エンティティタグの形式については、ESCの実装による。 8.3. サーバーの用法 エンティティタグは、EPCによって生成され、維持される。エンティティタグ は、ESCによって維持されるステートの一部であり、実際のイベントステート と残りの有効期限も含まれている。エンティティタグは、成功したイベントス テート発行ごとに生成および保存され、EPAに200(OK)応答で返される。前の発 行を更新するEPAからの各イベントステート発行には、ESCがアクティブな複数 の発行で検索キーとして使用できるエンティティタグが含まれる。 Niemi Standards Track [Page 14] RFC 3903 SIP Event State Publication October 2004 エンティティタグの生成方法は、実装の判断による。エンティティタグの生成 方法の一例は、発行が成功したごとに1ずつインクリメントする整数カウンタ として実装することである。他にも同様にエンティティタグを生成する有効な 方法は存在するが、本文書では1つの方法を推奨すること、または優先度を付 けることはない。 9. 発行頻度の制御 エンティティは、潜在的に数多くのソースからステート情報を集積する責任が あるため、ESCは大量の発行トラフィックの対象になる可能性がある。ESCが受 け取るPUBLISHリクエストの量を減らすには以下の方法がある。 o ESCは、発行の期限切れ間隔の選択に影響を及ぼすことができる。ESCの ローカルのデフォルトの最小期限切れ値に達していない場合に、ESCは、提 案よりも長い期限切れ間隔をEPAが選択するように要求できる。より長いデ フォルトの最小期限切れ値をESCに保持することで、発行の更新頻度が減 る。 o 発行トラフィックを減らすもう1つの方法は、SIPレベルのプッシュバック を使用して、特定ソースの発行トラフィックを抑えることである。特定 ソースからの発行についてプッシュバックする場合、RFC 3261(参考文献 [4])で定義されているように、ESCは、PUBLISHリクエストに対して503 (Service Unavailable)で応答してもよい[MAY]。この応答には、Retry- Afterヘッダーフィールドを含めるべきである[SHOULD]。このヘッダー フィールドには、発行のソースが別のPUBLISHリクエストを送信する前に待 つ必要がある時間を示す。 本仕様の執筆時点では、SIPの負荷管理に関する研究が始まったところであ る。そのため、将来的にイベントステート発行システムの負荷を関するするた めに、他のツールが提示される可能性がある。 10. PUBLISHを使用したイベントパッケージの考慮事項 このセクションでは、PUBLISHの仕組みをイベントパッケージに適用する際 に、考慮すべきいくつかの問題について検討する。また、プレゼンスの発行に PUBLISHを使用する際のこれらの問題を操作する方法についても、論証する。 将来的にイベントパッケージ仕様で、PUBLISHを使用する場合の考慮事項を含 めるべきである[SHOULD]。最低でも、このような検討事項でこの章で提示され ている問題を扱うべき[SHOULD]であり、新規の検討事項を含めてもよい [MAY]。 Niemi Standards Track [Page 15] RFC 3903 SIP Event State Publication October 2004 10.1. PUBLISHのボディ PUBLISHリクエストのボディは、一般的に発行済みのイベントステートを伝達 する。特定のイベントパッケージ用にPUBLISHの仕組みを適用するものは、ど のcontent-type(複数もあり)がPUBLISHリクエストで要求されるかを定義しな ければならない[MUST]。各イベントパッケージもまた、そのコンテンツタイプ に関連付けられるセマンティクスを記述しなければならない[MUST]。また、デ フォルトの実装必須なMIMEタイプを規定しなければならない[MUST]。 本文書は、CPP (Common Profile for Presence) PIDF (Presence Information Data Format)(参考文献[6])を使用する場合の、プレゼンスの発行リクエスト (イベントパッケージ「presence」)のセマンティクスを定義する。PUBLISHを 使用してプレゼンスステートをPAに対して発行するPUAは、PIDFプレゼンス形 式に対応しなければならない[MUST]。他の形式に対応してもよい[MAY]。 10.2. PUBLISHの応答ボディ PUBLISHリクエストに対する応答は、リクエストが成功したかどうかを示す。 通常、こうした応答のボディは、イベントパッケージがボディ用に明示的な意 味を定義しない限り、空である。 プレゼンス発行に対する応答のボディの場合は、そのような意味はない。 10.3. イベントステートの複数ソース 一部のイベントパッケージでは、基礎となるモデルは、イベントステートを集 積する責任を持つ1つのエンティティ(ESC)と、複数のソースのモデルである。 このうち、PUBLISHの仕組みを使用してもよいのは一部のみである。 PUBLISHの仕組みを使用する以外のイベントステートのソースは、明確に許 容される、ということに注意。ただし、このようなインターフェースを定 義することは、本仕様の範囲外である。 PUBLISHの仕組みを利用するイベントパッケージは、イベントステート発行の このモデルが適用可能かどうかを記述すべきである[[SHOULD]]。また、複数 ソースから発行を収集するために使用される特定の仕組みについて記述しても よい[MAY]。 プレゼンスの場合ウォッチャーがNOTIFYで受信するプレゼンスドキュメントに 合成できるタプルのサブセットに対してのみ、PUAはプレゼンスステートを発 行できる。ESCがこの情報を集める仕組みは、ローカルポリシーの問題であ り、本仕様の範囲外である。 Niemi Standards Track [Page 16] RFC 3903 SIP Event State Publication October 2004 10.4. イベントステートのセグメント化 イベントパッケージによっては、イベントステートをセグメント化する自然分 解(natural decomposition)が存在する。各セグメントは、発行済みイベント ステートで識別可能な多くのセクションの1つとして定義されている。コンテ ンツタイプがこのようなイベントステートのセグメント化に対応しているイベ ントパッケージは、ESCがイベントステートのセグメントを識別する方法につ いて説明すべきである[SHOULD]。 プレゼンスの発行の場合、EPAは、タプルの「id」属性について、エンティ ティタグのコンテキストで整合性を保たなければならない[MUST]。発行によっ てタプルのコンテンツが修正される場合、そのタプルは元の「id」を維持しな ければならない[MUST]。ESCは、各タプルを、受け取ったリクエストのエン ティティタグのコンテキストで解釈する。元の発行に対応する「id」がなく なっているタプルは、削除されたと見なされる。同様に、「id」属性が元の発 行に含まれていない場合、タプルは追加されたと解釈される。 10.5. 発行頻度 発行頻度の制御は、セクション9に記載されている。個々のイベントパッケー ジでは、単一のEPAによって生成される発行での絶対最大率について、推奨 (SHOULDまたはMUSTの強度)を定義してもよい[MAY]。 プレゼンスの発行には頻度を限定する推奨はない。 11. プロトコル要素の定義 このセクションは、SIPにおけるイベント発行に必要な拡張について説明す る。 11.1. 新しいメソッド 11.1.1. PUBLISHメソッド 「PUBLISH」は、SIPメッセージ文法の要素「メソッド」の定義に追加される。 他のSIPメソッドと同様に、メソッド名は大文字・小文字を区別する。PUBLISH は、イベントステートを合成する責任を負うエンティティに対して、イベント ステートを発行するときに使用される。 表2と表3は、RFC 3261(参考文献[2])の表2と表3の拡張であり、新規の列を追 加し、PUBLISHリクエストと応答で使用されるヘッダーフィールドを定義して いる。この表の重要な点は、RFC 3261(参考文献[4])のセクション20で既定さ れる。 Niemi Standards Track [Page 17] RFC 3903 SIP Event State Publication October 2004 +---------------------+---------+---------+ | ヘッダーフィールド | 場所 | 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 | +---------------------+---------+---------+ 表2: ヘッダーフィールドの要約、A--O Niemi Standards Track [Page 18] RFC 3903 SIP Event State Publication October 2004 +---------------------+-----------------+---------+ | ヘッダーフィールド | 場所 | 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 | +---------------------+-----------------+---------+ 表3: ヘッダーフィールドの要約、P--Z 11.2. 新しい応答コード 11.2.1. 「412 Conditional Request Failed」応答コード 412 (Conditional Request Failed)応答が「Client-Error」ヘッダーフィール ド定義に追加される。412 (Conditional Request Failed)は、リクエストに指 定された前提条件が失敗したことを示すために使用されるる Niemi Standards Track [Page 19] RFC 3903 SIP Event State Publication October 2004 11.3. 新しいヘッダーフィールド 表4、表5、表6は、セクション11.1の変更を反映した、SIP(参考文献[4])の表3 の拡張である。 +--------------------+-------+-------+-----+-----+-----+-----+-----+ | ヘッダーフィールド | where | proxy | ACK | BYE | CAN | INF | INV | +--------------------+-------+-------+-----+-----+-----+-----+-----+ | SIP-ETag | 2xx | | - | - | - | - | - | | SIP-If-Match | R | | - | - | - | - | - | +--------------------+-------+-------+-----+-----+-----+-----+-----+ 表4: ヘッダーフィールドの要約、P--Z +--------------------+-------+-------+-----+-----+-----+-----+-----+ | ヘッダーフィールド | where | proxy | NOT | OPT | PRA | REG | SUB | +--------------------+-------+-------+-----+-----+-----+-----+-----+ | SIP-ETag | 2xx | | - | - | - | - | - | | SIP-If-Match | R | | - | - | - | - | - | +--------------------+-------+-------+-----+-----+-----+-----+-----+ 表5: ヘッダーフィールドの要約、P-Z +--------------------+-------+-------+-----+-----+-----+---------+ | ヘッダーフィールド | where | proxy | UPD | MSG | REF | PUBLISH | +--------------------+-------+-------+-----+-----+-----+---------+ | SIP-ETag | 2xx | | - | - | - | m | | SIP-If-Match | R | | - | - | - | o | +--------------------+-------+-------+-----+-----+-----+---------+ 表6: ヘッダーフィールドの要約、P--Z 11.3.1. 「SIP-ETag」ヘッダーフィールド SIP-ETagは、SIPメッセージ文法の要素「general-header」の定義に追加され る。このヘッダーフィールドの用法は、セクション4とセクション6に記載され ている。 11.3.2. 「SIP-If-Match」ヘッダーフィールド SIP-If-Matchは、SIPメッセージ文法の要素「general-header」の定義に追加 される。このヘッダーフィールドの用法は、セクション4とセクション6に記載 されている。 Niemi Standards Track [Page 20] RFC 3903 SIP Event State Publication October 2004 12. Augmented BNFの定義 このセクションは、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 13. IANA条項 本文書は、新規のメソッド名1つ、新規の応答コード1つ、および新規のヘッ ダーフィールド名2つを登録する。 13.1. メソッド 本文書は、以下の情報で定義される、新規のSIPメソッドを登録する。これは 以下のURLの、メソッドおよび応答コードの下位登録に追加された。 http://www.iana.org/assignments/sip-parameters メソッド名: PUBLISH 参考文献: [RFC3903] 13.2. 応答コード 本文書は、新規の応答コードを登録する。本文書は、以下の情報で定義され る、新規の応答コードを登録する。これは以下のURLの、メソッドおよび応答 コードの下位登録に追加された。 http://www.iana.org/assignments/sip-parameters 応答コード番号: 412 デフォルトの理由フレーズ: Conditional Request Failed 13.3. ヘッダーフィールド名 本文書は、新規のSIPヘッダーフィールド名を2つ登録する。これのヘッダー フィールドは、以下の情報で定義される。これは、以下のURLの、ヘッダーの 下位登録に追加された。 http://www.iana.org/assignments/sip-parameters ヘッダー名: SIP-ETag 短縮形: (なし) Niemi Standards Track [Page 21] RFC 3903 SIP Event State Publication October 2004 ヘッダー名: SIP-If-Match 短縮形: (なし) 14. セキュリティの考慮事項 14.1. アクセス制御 イベントステートは機密情報と考えられる場合があるため、ESCは、認可済み のソース (EPAのアイデンティティに基づく) から送信された発行のみを選択 して受け入れる機能を持つべきである。 ステートエージェントは、EPAを認証すべきである[SHOULD]。また、すべての リクエストに対して、認可ポリシーを(たとえば、アクセス制御リストに基づ いて)適用すべきである[SHOULD]。構成モデルは、ESCに対するすべての入力 ソースが同一のネットワーク上または同じ管理ドメインにある、ということは 想定していない。 ESCとEPAは、RFC3261(参考文献[4])で定義されるように、PUBLISHリクエスト を認証する場合、ダイジェスト認証を実装しなければならない[MUST]。ESCで アクセス制御ポリシーを作成かつ操作する具体的な方法については、本文書の 範囲外である。 14.2. DoS攻撃 PUBLISHリクエストの受信時にESCでステートを作成することは、対象のマシン 上のリソースを破壊し、使用不能にさせる可能性もある攻撃者によって、利用 される可能性がある。 このような攻撃の機会を減らすために、ESCの実装は、PUBLISHリクエストの認 証を必要とすべきである[SHOULD]。実装では、RFC3261(参考文献[4])で定義さ れるように、ダイジェスト認証に対応しなければならない[MUST]。 また、ESCは、送られてくる発行と、対応する通知(イベントステートが変更さ れる結果として生じる)を制御すべきである[SHOULD]。最初の段階で、ESCでサ ポートされるイベントパッケージ用にデフォルトのExpiresヘッダーフィール ドの最小値を慎重に選択することで、イベントステートの更新を制限するため に役立つ。 PUBLISHリクエストの結果として生じる通知のトラフィックをさらに減らすた めに、制限ロジックやデバウンスロジックをESCに付加することが望ましい。 14.3. リプレイ攻撃 PUBLISHリクエストを繰り返すことは、弊害をもたらす可能性がある。攻撃者 は、PUBLISHリクエストを繰り返すことによって、過去のある時点で見ていた すべてのイベントステート発行を実行できる可能性がある。このようなリプレ イメッセージは、特に古いイベントステート情報をまねるために使用される可 Niemi Standards Track [Page 22] RFC 3903 SIP Event State Publication October 2004 能性があるが、バージョン付けの仕組み(たとえばタイムスタンプ)をステート 情報に使用することによって、このような攻撃を緩和するのに役立つ可能性も ある。 リプレイ攻撃を防ぐには、実装では、RFC3261(参考文献[4])で定義されるよう に、リプレイ保護にダイジェスト認証に対応しなければならない[MUST]。リプ レイ攻撃に対処する仕組みについては、SIP(参考文献[4])に詳しく記載されて いる。 14.4. man-in-the-middle攻撃 認証している場合でも、PUBLISHを使用するman-in-the-middle(仲介者)攻撃に よって、任意のイベントステート情報がインストールされたり、既存の発行の イベントステート情報を修正または削除したり、ESCにあるイベントステート も一緒に削除されてしまう可能性がある。 このような攻撃を防ぐために、実装は、最低でも、To、From、Event、SIP-If- Match、Route、およびExpiresの各ヘッダーフィールドと、PUBLISHリクエスト のボディについて、整合性の保護機能を持つべきである[SHOULD]。 ESCが関連していないセキュリティ上のつながりを使用して整合性が保護され たPUBLISHリクエストで、ESCは、イベントステートを受け取る場合がある(た とえば、整合性の保護はエンドツーエンド、つまりパブリッシャからサブスク ライバに適用される)。この場合、ESCと結びつけられたステートエージェント は、NOTIFYリクエストに含まれるイベントステートのサブスクライバに対して イベントステートを公開する前に、イベントステートを修正してはならない [MUST NOT]。これによって、イベントステートのエンドツーエンドの整合性が 維持される。 整合性保護のために、ESCは、TLS(参考文献[8])を実装しなければならない [MUST]。また、ESCは、双方向と一方向の認証の両方に対応しなければならな い[MUST]。さらに、SIP(参考文献[4])で定義されるSIPS URIスキームにも対応 しなければならない[MUST]。EPAは、TLSを初期化する機能を持つべきである [SHOULD]。また、SIPS URIスキームに対応すべきである[SHOULD]。ESCとEPA は、SIP(参考文献[4])で定義されるように、整合性保護の目的でS/MIME(参考 文献[9])に対応してもよい[MAY]。 14.5. 機密性 PUBLISHメッセージに含まれるステート情報は、機密情報を含む可能性があ る。実装は、このような情報の機密性を保護するために、暗号化してもよい [MAY]。 機密保持のために、ESCは、TLS(参考文献[8])を実装しなければならない [MUST]。また、ESCは、双方向と一方向の認証の両方に対応しなければならな い[MUST]。さらに、SIP(参考文献[4])で定義されるSIPS URIスキームにも対応 しなければならない[MUST]。EPAは、TLSを初期化する機能を持つべきである [SHOULD]。また、SIPS URIスキームに対応すべきである[SHOULD]。ESCとEPA は、SIP(参考文献[4])で定義されるように、イベントステート情報の暗号化の 目的でS/MIME(参考文献[9])に対応してもよい[MAY]。 Niemi Standards Track [Page 23] RFC 3903 SIP Event State Publication October 2004 15. 例 ここでは、プレゼンスユーザーエージェントからプレゼンスエージェントへプ レゼンスドキュメントを発行するときに、PUBLISHメソッドを使用する例を示 す。この例のウォッチャーは、PAから、プレゼンティティのプレゼンス情報に サブスクライブしている。また、PUAは、自身のプレゼンスにSUBSCRIBEして、 PAから公開された合成プレゼンスステートを表示してもよい。これは、オプ ションだがPUAにとってよくある手順である。この例では示していない。 Content-Lengthヘッダーフィールドの値が「...」の場合、この値は、任意の 長さを持つボディであることを示す。 PUA PA ウォッチャー (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 ----- | | | | Niemi Standards Track [Page 24] RFC 3903 SIP Event State Publication October 2004 メッセージフロー: M1: ウォッチャーは、新規のサブスクリプションをpresentity@example.comの ユーザーエージェントに対して開始する。 SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7 To: From: ;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Contact: sip:user@host.example.com Content-Length: 0 M2: 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: ;tag=abcd1234 From: ;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Contact: sip:pa.example.com Expires: 3600 Content-Length: 0 M3: 処理を完了するために、プレゼンスエージェントは、ウォッチャーに、プ レゼンティティの現在のプレゼンスステートを持つNOTIFYを送信する。 NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 To: ;tag=12341234 From: ;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: ... Niemi Standards Track [Page 25] RFC 3903 SIP Event State Publication October 2004 [PIDFドキュメント] M4: ウォッチャーは、NOTIFYリクエストの受信を確認する。 SIP/2.0 200 OK Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 ;received=192.0.2.2 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 1 NOTIFY M5: プレゼンスユーザーエージェント(プレゼンティティのために動作)は、新 規のプレゼンス情報で更新するために、PUBLISHリクエストをプレゼン ティティのプレゼンスエージェントに対して開始する。Expiresヘッダー フィールドは、このイベントソフトステートに、有効期限案を示す。 PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge To: From: ;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: ... [発行されたPIDFドキュメント] M6: プレゼンスエージェントは、プレゼンス発行を受信して、受け入れる。発 行されたデータは、プレゼンティティのプレゼンス情報に組み込まれる。 SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge ;received=192.0.2.3 To: ;tag=1a2b3c4d From: ;tag=1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH SIP-ETag: dx200xyz Expires: 1800 M7: プレゼンスエージェントは、プレゼンティティのプレゼンス情報に対して レポート可能な変更が加えられたことを判断し、新しいプレゼンス通知を ウォッチャーに送信する。 Niemi Standards Track [Page 26] RFC 3903 SIP Event State Publication October 2004 NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a To: ;tag=12341234 From: ;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: ... [新しいPIDFドキュメント] M8: ウォッチャーは、NOTIFYリクエストの受信を確認する。 SIP/2.0 200 OK Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a ;received=192.0.2.2 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Content-Length: 0 M9: PUAは、以前に発行されたイベントステートが期限切れになりそうである と判断し、そのイベントステートを更新する。 PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02 To: From: ;tag=1234kljk Call-ID: 98798798@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 SIP-If-Match: dx200xyz Expires: 3600 Event: presence Content-Length: 0 M10: プレゼンスエージェントは、更新を受信して、受け入れる。エンティ ティタグで識別される、特定のイベントステートの期限切れに関するタイ マーが更新される。通常通り、ESCはエンティティタグを成功したPUBLISH に対する応答で返す。実際のステートは変更されないため、ウォッチャー はNOTIFYを受け取らない、ということに注意。 Niemi Standards Track [Page 27] RFC 3903 SIP Event State Publication October 2004 SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02 ;received=192.0.2.3 To: ;tag=2affde434 From: ;tag=1234kljk Call-ID: 98798798@pua.example.com CSeq: 1 PUBLISH SIP-ETag: kwj449x Expires: 1800 M11: プレゼンティティのPUAは、ユーザーのプレゼンスステートの変更を検出 する。PUBLISHリクエストをプレゼンスエージェントに対して開始し、発行 済みのプレゼンス情報を最新の変更に合わせて修正する。 PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 To: From: ;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: ... [発行されたPIDFドキュメント] M12: プレゼンスエージェントは、修正の発行を受信して、受け入れる。発行 されたデータは、プレゼンティティのプレゼンス情報に組み込まれ、同じ PUAによる前の発行が更新される。 SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2 ;received=192.0.2.3 To: ;tag=effe22aa From: ;tag=54321mm Call-ID: 5566778@pua.example.com CSeq: 1 PUBLISH SIP-ETag: qwi982ks Expires: 3600 M13: プレゼンスエージェントは、プレゼンティティのプレゼンスドキュメン トに対してレポート可能な変更が加えられたことを判断し、新しいプレゼ ンス通知をアクティブなサブスクリプションすべてに送信する。 Niemi Standards Track [Page 28] RFC 3903 SIP Event State Publication October 2004 NOTIFY sip:user@host.example.com SIP/2.0 Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3 To: ;tag=12341234 From: ;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: ... [新しいPIDFドキュメント] M14: ウォッチャーは、NOTIFYリクエストの受信を確認する。 SIP/2.0 200 OK Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3 ;received=192.0.2.3 To: ;tag=12341234 From: ;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Content-Length: 0 16. 寄稿者 本仕様の元の寄稿者は以下の通り。 Ben Campbell Estacado Systems Sean Olson Microsoft Jon Peterson Neustar, Inc. Jonathan Rosenberg dynamicsoft Brian Stucker Nortel Networks, Inc. Niemi Standards Track [Page 29] RFC 3903 SIP Event State Publication October 2004 17. 謝辞 著者は、SIMPLEワーキンググループ全体の協力に感謝を述べたい。特に、以下 の方々からこの研究にいただいたレビューと支援について感謝する。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、Dean Willis。 18. 参考文献 18.1. 規範となる参考文献 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [3] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [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. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [9] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. Niemi Standards Track [Page 30] RFC 3903 SIP Event State Publication October 2004 19.2. 有益な参考文献 [10] Campbell, B., "SIMPLE Presence Publication Requirements", Work in Progress, February 2003. [11] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [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. 著者の連絡先 Aki Niemi (editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Niemi Standards Track [Page 31] RFC 3903 SIP Event State Publication October 2004 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に 記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保 証、商用利用および特定目的への適合性への保証を含め、また、これらだけに 限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記 載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Niemi Standards Track [Page 32]