Network Working Group A. B. Roach Request for Comments: 3265 dynamicsoft Updates: 2543 June 2002 Category: Standards Track セッション開始プロトコル(SIP)特有のイベント通知 Session Initiation Protocol (SIP)-Specific Event Notification 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を 依頼するものである。標準化の段階や、プロトコルの位置付けについては、 最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。 この文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 このドキュメントはセッション開始プロトコル(SIP)の拡張について述べる ものである。この拡張の目的は、SIPノードが、リモートノードからある特 定のイベントが起こったことを示す通知を要求できる、拡張可能なフレー ムワークを提供することである。 このドキュメント中で述べられているメカニズムの具体的な用法は、将来 標準化されるかもしれない。 ここで定義されているイベント通知メカニズムは、イベントサブスクリプ ションと通知のすべてのクラスのための一般目的の基盤となることをめざ してはいない[NOT]ということに注意すること。 目次 1. はじめに............................................... 3 1.1. 操作概要............................................... 4 1.2. 表記基準............................................... 4 2. 定義................................................... 5 3. ノードの動作........................................... 6 3.1. SUBSCRIBE 動作説明..................................... 6 3.1.1. サブスクリプション期間................................. 6 3.1.2. サブスクライブされたイベントとイベントクラスの同定..... 6 3.1.3. 付加的な SUBSCRIBE ヘッダー値.......................... 7 3.1.4. サブスクライバーの SUBSCRIBE 動作...................... 7 3.1.5. プロキシの SUBSCRIBE 動作.............................. 9 3.1.6. ノーティファイアの SUBSCRIBE 動作...................... 10 Roach Standards Track [Page 1] RFC 3265 SIP-Specific Event Notification June 2002 3.2. NOTIFY 動作説明........................................ 13 3.2.1. 報告されたイベント、イベントクラス、現在のステート の識別................................................. 13 3.2.2. ノーティファイアの NOTIFY 動作......................... 14 3.2.3. プロキシの NOTIFY 動作................................. 15 3.2.4. サブスクライバーの NOTIFY 動作......................... 16 3.3. 概要................................................... 18 3.3.1. SUBSCRIBE と NOTIFY に対するサポートの検出............. 18 3.3.2. CANCEL リクエスト...................................... 18 3.3.3. フォーク............................................... 18 3.3.4. ダイアログの生成と終了................................. 18 3.3.5. ステートエージェントとノーティファイア移行............. 19 3.3.6. リソースステートのポーリング........................... 20 3.3.7. Allow-Events ヘッダーの用法............................ 21 3.3.8. PINT 互換性............................................ 21 4. イベントパッケージ..................................... 21 4.1. 用途の適切性........................................... 21 4.2. イベントテンプレートパッケージ......................... 22 4.3. 伝達されるステートの量................................. 22 4.3.1. 完全なステート情報..................................... 23 4.3.2. ステート差分........................................... 23 4.4. イベントパッケージの責務............................... 24 4.4.1. イベントパッケージ名................................... 24 4.4.2. イベントパッケージのパラメータ......................... 24 4.4.3. SUBSCRIBE のボディー................................... 24 4.4.4. サブスクリプション期間................................. 25 4.4.5. NOTIFY のボディー...................................... 25 4.4.6. ノーティファイアでの SUBSCRIBE リクエスト処理.......... 25 4.4.7. ノーティファイアでの NOTIFY リクエストの生成........... 25 4.4.8. サブスクライバでの NOTIFY リクエスト処理............... 26 4.4.9. フォークされたリクエストのハンドリング................. 26 4.4.10. 通知レート............................................. 26 4.4.11. ステートエージェント................................... 27 4.4.12. 例..................................................... 27 4.4.13. ステートを取り出すための URI の使用.................... 27 5. セキュリティの考慮..................................... 28 5.1. アクセス制御........................................... 28 5.2. ノーティファイアのプライバシーメカニズム............... 28 5.3. DoS 攻撃............................................... 28 5.4. リプレイ攻撃........................................... 29 5.5. man-in-the-middle攻撃.................................. 29 5.6. 機密性................................................. 29 6. IANA 条項.............................................. 30 6.1. 登録情報............................................... 30 6.2. 登録テンプレート....................................... 31 6.3. ヘッダーフィールド名称................................. 31 6.4. 応答コード............................................. 32 7. シンタックス........................................... 32 Roach Standards Track [Page 2] RFC 3265 SIP-Specific Event Notification June 2002 7.1. 新規メソッド........................................... 32 7.1.1. SUBSCRIBE メソッド..................................... 34 7.1.2. NOTIFY メソッド........................................ 34 7.2. 新規ヘッダー........................................... 34 7.2.1. Event ヘッダー......................................... 34 7.2.2. Allow-Events ヘッダー.................................. 35 7.2.3. Subscription-State ヘッダー............................ 35 7.3. 新規応答コード......................................... 35 7.3.1. 202 Accepted 応答コード................................ 35 7.3.2. 489 Bad Event 応答コード............................... 35 7.4. 拡張BNF定義............................................ 35 8. 規範的な参考文献....................................... 36 9. 有益な参考文献......................................... 37 10. 謝辞................................................... 37 11. 知的所有権に関する告知................................. 37 12. 著者の連絡先........................................... 37 13. 完全な著作権表示....................................... 38 1. はじめに イベントの非同期通知を要求する能力は、エンドノード間の協調が求めら れる多くのタイプのSIPサービスにおいて有用であることがわかる。そのよ うなサービスの例としては、(ターミナルステートイベントに基づく)自動 コールバックサービス、(ユーザープレゼンスイベントに基づく)バディリ スト、(メールボックスステート変更イベントに基づく)メッセージ待ち表 示、および(コールステートイベントに基づく) PSTN とインターネットの 相互接続(PINT)(参考文献[2])ステータスが含まれる。 このドキュメント中で述べられるメソッドは、これらのイベントに対する 通知を頼むことができるフレームワークを提供する。 ここで定義されるイベント通知メカニズムは、イベントサブスクリプショ ンと通知のすべてのクラスのための一般目的の基盤となることをめざして はいない[NOT]。サブスクリプションと通知の一般的な諸問題に対する要求 を満たすことは、一つのプロトコルには複雑すぎる。我々の目的は、単純 な機能で使用不可能なほどに複雑ではないが、それでも有力なサービスを 提供するための十分な柔軟性がある、SIP特有のフレームワークを提供する ことである。しかしながら、このフレームワークに基づくイベントパッケ ージは、任意に、それらが記述するイベントやイベントクラスに対するサ ブスクリプションと通知を管理する、複雑なルールを定義するかもしれな いということに注意すること。 このドキュメントでは直ちに使用できる拡張について述べない。つまり、 それは他のドキュメント(ここでは「イベントパッケージ」と呼ぶ)で拡張 されなけ ればならない。オブジェクト指向デザインの用語では、それは、 更なる拡張によってインスタンス作成が可能なクラスに派生させなければ Roach Standards Track [Page 3] RFC 3265 SIP-Specific Event Notification June 2002 ならない、抽象ベースクラスとみなされるかもしれない。これらの拡張を 作成するためのガイドラインはセクション4で述べられている。 1.1. 操作概要 概略のコンセプトは、ネットワーク上のエンティティは、そのネットワー ク上の様々なリソースや呼に対するリソースやコールステートにサブスク ライブでき、それらのエンティティ(またはそれらのかわりに動作している エンティティ)はそれらのステートが変わったときに通知を送ることができ るというものである。 典型的なメッセージの流れは以下のようである。 サブスクライバー ノーティファイア |-----SUBSCRIBE---->| ステートサブスクリプション要求 |<-------200--------| サブスクリプションの承認 |<------NOTIFY----- | 現在のステート情報を返す |--------200------->| |<------NOTIFY----- | 現在のステート情報を返す |--------200------->| サブスクリプションは期限切れになるので、これ以降のSUBSCRIBEメッセー ジでリフレッシュされなければならない。 1.2. 表記基準 ドキュメント全体を通して、動機付け(motivational)や明確化(clarifying) をおこなう文を提示するいくつかのパラグラフがある。このような節は規 範となるものではなく、読者の理解を助けるためにのみ提供されている。 これらの節は次のように字下げすることで、それ以外の部分の文と区別さ れている。 これは規範とはならない説明文の例である。これはこの仕様の一部を なさず、明確化のためだけに使用される。 角括弧にはさまれた数字(例: [1])は、「参考文献」セクションのエントリ のうちの一つを参照することを意味する。セクション8と9を参照。 すべて大文字の用語、「MUST」、「SHOULD」、「MAY」、「SHOULD NOT」、 「MUST NOT」および「RECOMMENDED」は、RFC2119(参考文献[5])で定義され ているように使用される。 ピリオドとカンマの隣の引用符の用法は、アメリカ数学協会(American Mathematical Society)で使用されている表記に従う。この用法は伝統的な アメリカ英語の表記には反するが、ある特定の節において明確さを与える。 Roach Standards Track [Page 4] RFC 3265 SIP-Specific Event Notification June 2002 2. 定義 イベントパッケージ: イベントパッケージはノーティファイアからサブス クライバーに報告されることになるステート情報のセットを定義する 追加仕様である。イベントパッケージはまた、このドキュメントで定 義されるフレームワークに基づいた、そのようなステート情報を伝え るために必要とされる更なるシンタックスやセマンティクスを定義す る。 イベントテンプレートパッケージ: イベントテンプレートパッケージは、 それ自身を含めすべての可能なイベントパッケージに適用することが できる、ステートのセットを定義する特別な種類のイベントパッケー ジである。 通知: 通知は、リソースのステートをサブスクライバーに知らせるために、 サブスクライバーにNOTIFYメッセージを送るノーティファイアの動作 である。 ノーティファイア: ノーティファイアは、リソースのステートをサブスク ライバーに通知する目的でNOTIFYリクエストを生成するユーザーエー ジェントである。ノーティファイアは一般に、サブスクリプションを 生成するためにSUBSCRIBEリクエストも受け入れる。 ステートエージェント: ステートエージェントはリソースに成り代わって ステート情報を発行するノーティファイアである。それを行うために、 ステートエージェントは複数のソースからそのようなステート情報を 収集する必要があるかもしれない。ステートエージェントは常にリソ ース(ステートエージェントはそのリソースのために通知を生成する) の完全なステート情報を持っている。 サブスクライバー: サブスクライバーはノーティファイアからNOTIFYリク エストを受け取るユーザーエージェントである。NOTIFYリクエストは、 サブスクライバーが関心を持つリソースのステートについての情報を 含む。サブスクライバーは一般的にSUBSCRIBEリクエストも生成し、サ ブスクリプションを生成するためにそれをノーティファイアに送る。 サブスクリプション: サブスクリプションはダイアログに関連付けられた アプリケーションステートのセットである。このアプリケーションス テートは、関連付けられたダイアログへのポインタ、イベントパッケ ージ名、そしておそらくは識別トークンを含む。イベントパッケージ は付加的なサブスクリプションステート情報を定義するだろう。定義 では、サブスクリプションはサブスクライバーとノーティファイアの 双方に存在する。 サブスクリプション移行: サブスクリプション移行は、一つのノーティフ ァイアから別のノーティファイアへのサブスクリプションの移動行為 である。 Roach Standards Track [Page 5] RFC 3265 SIP-Specific Event Notification June 2002 3. ノードの動作 3.1. SUBSCRIBE 動作説明 SUBSCRIBE メソッドは、リモートノードから現在のステートとステートの アップデートを要求するために使用される。 3.1.1. サブスクリプション期間 SUBSCRIBE リクエストは Expires ヘッダー(SIP(参考文献[1])で定義され ている)を含むべきである[SHOULD]。この有効期限値はサブスクリプション の期間を示す。Expires ヘッダーで伝えられたこの期間を過ぎてもサブス クリプションを有効にし続けるために、サブスクライバーは、SIP(参考文 献[1])で定義されている同一ダイアログ上で、新しい SUBSCRIBE メッセー ジを使用して定期的にサブスクリプションをリフレッシュする必要がある。 SUBSCRIBE リクエストに Expires ヘッダーがない場合、暗黙の初期値は使 用されているイベントパッケージによって定義される。 SUBSCRIBE リクエストに対する200クラス応答も Expires ヘッダーを含まな ければならない[MUST]。応答中の期間は短くしてもよい[MAY]が、リクエス トで指定されたものより長くしてはならない[MUST NOT]。応答中の期間はサ ブスクリプションの継続期間を定義するものである。 Contact ヘッダーの expires パラメータは、SUBSCRIBE に対してはセマン ティクスを持たず、SUBSCRIBE リクエストまたは応答の Expires ヘッダー とは明らかに等価ではない。 このスキームの自然な帰結として、0 という値の Expires を持つ SUBSCRIBE は、イベントからアンサブスクライブするためのリクエストを構成する。 アンサブスクライブのためのリクエストであるということに加えて、 0 という値の Expires を持つ SUBSCRIBE メッセージは、ステートを 取得することにもなる。セクション3.3.6参照のこと。 ノーティファイアもイベントに対するサブスクリプションを取り消したい と望むかもしれない。これは、たとえば、サブスクリプションが参照する リソースがもはや有効でなくなったときに有用である。このメカニズムに ついての更なる詳細はセクション3.2.2で議論する。 3.1.2. サブスクライブされたイベントとイベントクラスの識別 イベントの識別は、3つの情報によって与えられる。Request URI、イベント タイプ、および(オプションで)メッセージボディである。 Roach Standards Track [Page 6] RFC 3265 SIP-Specific Event Notification June 2002 SUBSCRIBE リクエストの Request URI は、最も重要なことだが、SIP(参考 文献[1])で概説されているリクエストルーティングの手順によってリクエス トを適切なエンティティにルートするための十分な情報を含む。これはまた、 イベント通知が望まれているリソースを特定するために十分な情報を含む。 しかし、イベントの種類を一意に特定するために十分な情報ではない(例: sip:adam@dynamicsoft.com は私のプレゼンスステートにサブスクライブす るための適切な URI であろう。それはまた、私のボイスメールボックスの ステートにサブスクライブするための適切な URI でもあるだろう)。 サブスクライバーは SUBSCRIBE リクエストに、どのイベントあるいはイベ ントのクラスにサブスクライブするかを示す厳密に一つの Event ヘッダー を含めなければならない[MUST]。Event ヘッダーは、サブスクリプションが 要求されているステートタイプを示すトークンを含む。このトークンは IANA に登録され、イベントやイベントクラスのセマンティクスについて更 に詳しく記述するイベントパッケージに対応する。Event ヘッダーは id パ ラメータを含んでもよい[MAY]。この id パラメータは、もし存在すれば、 ダイアログ内で特定のサブスクリプションを特定する不透明トークン (opaque token)を含む。id パラメータは単一のダイアログのスコープ内で のみ有効である。 イベントトークンが対応するイベントパッケージが、それの SUBSCRIBE リ クエストのボディに関連付けられた動作を定義する場合、それのセマンテ ィクスを適用する。 イベントパッケージは Event ヘッダーのパラメータも定義することができ る。定義した場合、イベントパッケージはそのようなパラメータに対する セマンティクスも定義しなければならない。 3.1.3. 付加的な SUBSCRIBE ヘッダー値 SUBSCRIBE リクエストは SIP(参考文献[1])で定義されているようにダイア ログを生成するので、Accept ヘッダーを含んでもよい[MAY]。このヘッダー は、もし存在すれば、この後の NOTIFY リクエストで許可されるボディフォ ーマットを示す。イベントパッケージは Accept ヘッダーを持たない SUBSCRIBE リクエストに対する動作を定義しなければならない[MUST]。 通常、これは一つのデフォルトボディタイプを伴う。 このドキュメントで述べられていないヘッダー値は、SIP(参考文献[1])で 述べられているように解釈される。 3.1.4. サブスクライバーの SUBSCRIBE 動作 3.1.4.1. サブスクリプションの要求 SUBSCRIBE は、SIP(参考文献[1])で述べられているようなダイアログ生成 メソッドである。 サブスクライバーがあるリソースの特定のステートにサブスクライブする ことを望むとき、それは SUBSCRIBE メッセージを作る。最初の SUBSCRIBE Roach Standards Track [Page 7] RFC 3265 SIP-Specific Event Notification June 2002 が(通常そうであるように)ダイアログ外のリクエストを表す場合、それの 構築は SIP(参考文献[1])で概説されている、ダイアログ外のUACリクエス ト生成のための手順に従う。 この SUBSCRIBE リクエストは最終応答で正式に認められる。200クラス応 答は、サブスクリプションが受け入れられ、すぐに NOTIFY が送られるこ とを示す。200応答は、サブスクリプションが受け入れられ、ユーザーが要 求したリソースにサブスクライブすることが認可されたことを示す。202応 答は、サブスクリプションは理解されたが、認可されたかどうかわからな いことを単に示している。 SUBSCRIBE に対する200クラス応答の Expires ヘッダーは、サブスクリプ ションが(もしリフレッシュされなければ)アクティブであり続ける実際の 期間を示す。 非200クラス最終応答は、サブスクリプションもダイアログも生成されてお らず、これ以降に NOTIFY メッセージが送られることもないことを示す。 (このドキュメントで述べられている489を例外として)すべての非200クラ ス応答は、SIP(参考文献[1])に述べられているのと同じ意味を持ち、同じ にハンドリングされる。 SUBSCRIBE リクエストは、同一ダイアログ内の複数のサブスクリプションの 区別を可能にするために、Event ヘッダーに id パラメータを含んでもよい [MAY]。 3.1.4.2. サブスクリプションのリフレッシュ サブスクリプションが期限切れになる前ならいつでも、既存のサブスクリ プションと同じダイアログ上で、(もし最初のサブスクリプションに Event ヘッダー id パラメータが存在したなら)同じ Event ヘッダー id パラメ ータを持つ別の SUBSCRIBE リクエストを送ることにより、サブスクライバ ーはそのサブスクリプションのタイマーをリフレッシュすることができる。 そのようなリクエストのハンドリングは、以下に述べられていることを除 いてサブスクリプションの最初の生成と同じである。 最初の SUBSCRIBE メッセージが Event ヘッダーに id パラメータを 含んでいた場合、サブスクリプションのリフレッシュも同一の id パ ラメータを含まなければならない。そうでなければ既存ダイアログ中 の新規サブスクリプションとみなされる。 サブスクリプションをリフレッシュする SUBSCRIBE リクエストが481応答 を受け取る場合、サブスクリプションは既に終了されており、サブスクラ イバーはこの事実の通知を受け取っていなかったことを示す。この場合、 サブスクライバーはサブスクリプションが無効であるとみなすべきである。 サブスクライバーがそのステートに再度サブスクライブすることを望む場 合、新たに生成された Call-ID と新規で一意な From tag を持つ前のもの とは関連性のない最初の SUBSCRIBE リクエストを構成することでそれを行 える(セクション3.1.4.1参照)。 Roach Standards Track [Page 8] RFC 3265 SIP-Specific Event Notification June 2002 サブスクリプションをリフレッシュする SUBSCRIBE リクエストが481以外 の応答で失敗する場合、SUBSCRIBE とそれに対する応答でネゴシエートさ れた最新の Expires 値の期間、または NOTIFY の Subscription-State ヘ ッダーの expires パラメータで伝えられた期間、オリジナルのサブスクリ プションは依然として有効であるとみなされる。 このようなエラーの多くは、ネットワークやノーティファイアに問題 があり、更なる NOTIFY メッセージを受け取ることがないことを示す、 ということに注意すること。 3.1.4.3. アンサブスクライブ アンサブスクライブは、Expires ヘッダーに 0 を設定して、サブスクリプ ションのリフレッシュと同じようにハンドリングされる。成功したアンサ ブスクライブは最後の NOTIFY メッセージも引き起こすということに注意 すること。 3.1.4.4. サブスクリプション生成の確認 サブスクライバーは、成功したサブスクリプションやサブスクリプションの リフレッシュを処理した各ノードから NOTIFY メッセージを受け取ることを 期待できる。最初の NOTIFY メッセージが到着するまで、サブスクライバー はサブスクライブしたリソースのステートがニュートラルステートであると みなすべきである。新しいイベントパッケージを定義するドキュメントは、 それらのアプリケーションにとって意味をなすようにこの「ニュートラルス テート」を定義しなければならない[MUST](セクション4.4.7参照)。 順番が乱れたメッセージとフォークの2つの可能性があるため、サブスクラ イバーは SUBSCRIBE トランザクションが完了する前に NOTIFY メッセージ を受け取ることに備えなければならない[MUST]。 上記の例外を除いて、NOTIFY の処理はセクション3.2.4と同じである。 3.1.5. プロキシの SUBSCRIBE 動作 SUBSCRIBE をサポートするために、SIP(参考文献[1])で述べられているこ と以外の追加動作をプロキシは必要としない。プロキシが特定のダ イアログのすべての SUBSCRIBE と NOTIFY リクエストを見ることを望む場 合、プロキシは最初の SUBSCRIBE と ダイアログを確立するすべての NOTIFY リクエストを record-route しなければならない[MUST]。そのようなプロ キシは、他のすべての SUBSCRIBE と NOTIFY リクエストも record-route するべきである[SHOULD]。 サブスクライバーとノーティファイアは SUBSCRIBE と NOTIFY リクエ ストの S/MIME 暗号化を選択するかもしれないということに注意する こと。その結果としてプロキシは、SIP(参考文献[1])においてプロキ シで読み取り可能であることを明示的に要求していないすべての情報 にアクセスできることを当てにできない。 Roach Standards Track [Page 9] RFC 3265 SIP-Specific Event Notification June 2002 3.1.6. ノーティファイアの SUBSCRIBE 動作 3.1.6.1. 最初の SUBSCRIBE トランザクション処理 どのような場合でも、SUBSCRIBE トランザクションは、自動処理に必要と される時間以上に延長されるべきでない。特に、ノーティファイアは SUBSCRIBE リクエストに対する最終応答を返す前に、ユーザーの応答を待 ってはならない[MUST NOT]。 この要求は、ユーザーとのやりとりが 64*T1 秒を超えることが多いの で、非INVITEトランザクションのタイムアウトタイマー F (参考文献 [1]参照)が切れるのを防ぐことを主目的として課せられた。 ノーティファイアは Event ヘッダーで指定されたイベントパッケージが理 解できるかどうかチェックするべきである[SHOULD]。理解できない場合、 ノーティファイアは指定されたイベントまたはイベントクラスが理解でき ないことを示す「489 Bad Event」応答を返すべきである[SHOULD]。 ノーティファイアはローカルポリシーに従って、必要とされるすべての認 証と認可も実行するべきである[SHOULD]。セクション3.1.6.3参照のこと。 ノーティファイアは Expires ヘッダー中の継続期間が短すぎないかどうか もチェックしてもよい[MAY]。有効期限間隔がゼロよりも大きく、かつ [AND]1時間よりも小さく、かつ[AND]ノーティファイアで設定されている最 小値よりも小さい場合にのみ、ノーティファイアは Min-Expires ヘッダー フィールドを含む「423 Interval too small」エラーを返してもよい[MAY]。 Min-Expires ヘッダーフィールドは SIP(参考文献[1])に述べられている。 認証されたサブスクライバーがサブスクライブすることを認可されたイベ ントパッケージを、ノーティファイアが理解できることを直ちに確定でき、 サブスクリプションを生成するにあたって他のいかなる障害も存在しない 場合、それはサブスクリプションと(必要であれば)ダイアログを生成し、 「200 OK」応答を返す(そうしなければ、望まない形で認可のポリシーを明 かすことになるだろう。セクション5.2参照)。 ノーティファイアが直ちにサブスクリプションを生成できない(例: 認可の ためにユーザーの入力を待つ必要があったり、現在到達不可能な他のノー ドのために動作している)、または認可のポリシーをマスクすることを望む 場合、それは「202 Accepted」応答を返す。この応答は、リクエストが受 け取られて理解されたが、サブスクリプションがすでに認可されたことを 必ずしも意味しないことを示す。 サブスクリプションがノーティファイアで生成されたとき、それはサブス クリプション情報の一部としてイベントパッケージ名と(もし存在すれば) Event ヘッダーの id パラメータを保存している。 Roach Standards Track [Page 10] RFC 3265 SIP-Specific Event Notification June 2002 SUBSCRIBE に対する200クラス応答に存在する Expires 値は、REGISTER 応 答に含まれるものと同じように処理される。サーバーはその期間を短くして もよい[MAY]が、延ばしてはならない[MUST NOT]。 SUBSCRIBE メッセージで指定された継続期間が受け入れがたいほど短 い場合、このセクションの前のほうで述べたように、ノーティファイ アは423応答を送ることができるかもしれない。 SUBSCRIBE リクエストに対する200クラス応答は、サブスクリプション継続 期間以上の有用な情報を通常は含まないだろう。この応答の主たる目的は 信頼性メカニズムとして役立つことである。ステート情報は、これ以降の NOTIFY リクエストによってノーティファイアから伝えられる。 SIP(参考文献[1])で定義されているその他の応答コードを、必要に応じて SUBSCRIBE リクエストに対する応答で使用できる。 3.1.6.2. サブスクリプション生成・リフレッシュの確認 サブスクリプションをうまく受け入れるまたはリフレッシュするとき、ノー ティファイアはサブスクライバーに現在のリソースのステートを伝えるため に、直ちに NOTIFY メッセージを送らなければならない[MUST]。この NOTIFY メッセージは、SUBSCRIBE 応答によって生成されたのと同じダイア ログ上で送られる。SUBSCRIBE メッセージが処理される時点でリソースが意 味のあるステートを持たない場合、この NOTIFY メッセージは空のボディま たはニュートラルボディを含んでもよい[MAY]。NOTIFY メッセージの生成に ついての更なる詳細については、セクション3.2.2参照のこと。 サブスクリプションが既に認可されているか否かに関わらず、NOTIFY メッ セージは常に、SUBSCRIBE リクエストに対するどのような200クラス応答の 後でも直ちに送られる。 3.1.6.3. SUBSCRIBE リクエストの認証・認可 プライバシーの重要性は、特定のノーティファイアが特定のイベントのセ ットにサブスクライブすることを認可されているかどうか確定するための ポリシーを適用することを要求するかもしれない。そのようなポリシーは、 アクセス制御リストやユーザーとのリアルタイムでのやりとりといったメ カニズムによって定義されるかもしれない。一般的に、認証前のサブスク ライバーの認可は、特に有用ではない。 SIPの認証メカニズムは SIP(参考文献[1])で議論されている。ノーティフ ァイアのノードが通常はプロキシとして動作する場合であっても、SUBSCRIBE リクエストに対する認証は常に407応答ではなくて401応答で実行されると いうことに注意すること。ノーティファイアは、サブスクリプションを受 け入れるときと通知を送るときは常にユーザーエージェントとして動作す る。 Roach Standards Track [Page 11] RFC 3265 SIP-Specific Event Notification June 2002 当然ながらプロキシとして動作するときには、ノードは(407を使用し て)通常のプロキシ認証を実行する。前述の説明は、ノーティファイア は常にUAであり、そのためUA認証を実行するということを注意喚起す るものである。 アクセスリストや他の自動化されたメカニズムに基づく認可が失敗する場 合(すなわち、サブスクライバーがサブスクライブを認可されないというこ とが自動的に厳然と確定される)、そのリクエストに対して「403 Forbidden」 または「603 Decline」応答で答えることでプライベートであるべき情報が 明かされる可能性がないのであれば、ノーティファイアはそれらの応答で 答えるべきである[SHOULD](セクション5.2参照)。 ノーティファイアの所有者が、サブスクリプションが許可されるかどうか 確定するためにインタラクティブに問い合わせを受ける場合、「202 Accept」 応答が直ちに返される。このような状況下でも、前のセクションで述べら れているように、なお NOTIFY メッセージが形成されて送られるというこ とに注意すること。 サブスクリプションの認可が遅れ、ノーティファイアがそのような認可は 拒否されたと伝えることを望む場合、terminated という値を持つ Subscription-State ヘッダーと rejected という値を持つ reason パラメ ータを含む NOTIFY メッセージを送ることができる。 3.1.6.4. サブスクリプションのリフレッシュ サブスクライバーがまだ認可されていると仮定して、ノーティファイアがサ ブスクリプションのリフレッシュを受け取るとき、ノーティファイアはサブ スクリプションの有効期限をアップデートする。最初のサブスクリプション と同様に、サーバーは有効期限まで時間を短縮してもよい[MAY]が、それを 延ばしてはならない[MUST NOT]。最終的な有効期限時間は応答の Expiresヘ ッダーに置かれる。SUBSCRIBE メッセージで指定された期間が受け入れられ ないほど短い場合、ノーティファイアは「423 Subscription Too Brief」 メッセージで応答するべきである[SHOULD]。 有効期限時間の前に、通知アドレスに対するリフレッシュを受け取らない 場合、サブスクリプションは削除される。サブスクリプションを削除する とき、ノーティファイアはサブスクリプションが削除されることをそれに 知らせるために、terminated という値の Subscription-State を持つ NOTIFY メッセージを送るべきである[SHOULD]。そのようなメッセージが送 られる場合、Subscription-State ヘッダーは reason=timeout というパラ メータを含むべきである[SHOULD]。 サブスクリプションが期限切れになるときの NOTIFY の送信は、対応 するダイアログの切断を許可する(適切であれば)。 Roach Standards Track [Page 12] RFC 3265 SIP-Specific Event Notification June 2002 3.2. NOTIFY 動作説明 NOTIFY メッセージは、サブスクライバーがサブスクリプションを持つステ ートに変更があったことを知らせるために送られる。サブスクリプション は通常 SUBSCRIBE メソッドを用いて準備される。しかしながら、それ以外 の方法が使用されることも可能である。 サブスクリプションを生成するために何らかの非SUBSCRIBEメカニズムが定 義される場合、NOTIFY メッセージをそれに対応するサブスクリプションに 関連付け可能なことを保証することは、それらのメカニズムを定義する団 体の義務である。そのようなメカニズムの設計者は、サブスクリプション を認識しているサブスクライバーに NOTIFY メッセージを送ることと、思 いもよらないノードに NOTIFY メッセージを送ることとの区別をするよう に警告されている。後者の動作は無効であり、(他の400クラスか500クラス のエラーコードがより適切というのでなければ)セクション3.2.4で述べら れているように「481 Subscription does not exist」応答を受け取らなけ ればならない[MUST]。言い換えるなら、有効であるためには、非SUBSCRIBE メカニズムで設定された場合でも、サブスクライバーとノーティファイア の双方にサブスクリプションの認識が存在しなければならない。 NOTIFY はそれの対応するサブスクリプションを終了しない。言い換えるな ら、一つの SUBSCRIBE リクエストはいくつかの NOTIFY リクエストを引き 起こすことができる。 3.2.1. 報告されたイベント、イベントクラス、現在のステートの識別 通知で報告されることになるイベントの識別は、イベントへのサブスクリ プションについて述べられたものと非常に似ている(セクション3.1.2参照)。 SUBSCRIBE リクエストでのように、NOTIFY の Event ヘッダーは通知が生成 されることになる一つのイベントパッケージ名を含む。Event ヘッダーのパ ッケージ名は、対応する SUBSCRIBE メッセージの Event ヘッダーに一致し なければならない[MUST]。SUBSCRIBE メッセージに id パラメータが存在し た場合、その id パラメータが、対応する NOTIFY メッセージにも存在しな ければならない[MUST]。 イベントパッケージは、それの NOTIFY リクエストのボディに関連付けら れた、セマンティクスを定義できる。イベントパッケージがそれを行う場 合、そのセマンティクスが適用される。NOTIFY のボディは、起こったイベ ントの特長についての付加的な詳細と、その結果としてのリソースのステ ートを提供することが期待されている。 NOTIFY リクエストのボディが存在する場合、それは、対応する SUBSCRIBE リクエストの Accept ヘッダーで指定されたボディフォーマットのうちの 一つでフォーマットされなければならない[MUST]。このボディは、サブス クライブされたリソースのステート、または、URIの形でそのようなステー トへのポインタを含む(セクション4.4.13参照)。 Roach Standards Track [Page 13] RFC 3265 SIP-Specific Event Notification June 2002 3.2.2. ノーティファイアの NOTIFY 動作 SUBSCRIBE リクエストに200クラス応答で答えるとき、ノーティファイアは NOTIFY リクエストを直ちに構築してサブスクライバーに送らなければなら ない[MUST]。サブスクライブしたステートに変化が起こるとき、ノーティフ ァイアは認可、ローカルポリシー、および抑制の考慮にしたがって、 NOTIFY リクエストを直ちに構築して送るべきである[SHOULD]。 応答がタイムアウトするか、または Retry-After ヘッダーを持たず、リク エストを再試行するために取ることができる更なる動作を示さない、非200 クラス応答コード(例: 401 Authorization Required)を受け取る場合、 NOTIFY リクエストは失敗したとみなされる。 タイムアウト状態のため(上記で定義したように) NOTIFY リクエストが失 敗し、かつサブスクリプションが(SUBSCRIBE のような)ソフトステートメ カニズムを使用して設定されていた場合、ノーティファイアはサブスクリ プションを削除するべきである[SHOULD]。 この動作は、クラッシュしていたりネットワークから消滅しているサ ブスクライバーに対しての、ステート情報の不要な通信を防ぐ。その ような通信は、(クライアントを機能させるための通常の1回の通信の 替わりに)SIP(参考文献[1])で定義されている再送アルゴリズムに従っ て複数回送られることになるので、それらを承認するクライアントが 一つも有効でないときにそれらへのサービスを継続することは、ネッ トワークに過度の負担をかけることがありうる。クライアントの再起 動やネットワーク接続の再確立の時点で、クライアントは、古くなっ てしまった可能性があるステート情報をリフレッシュするために SUBSCRIBE メッセージを送ることが期待されている。そのようなメッ セージは、すべての関連するノードのサブスクリプションを再設定す る。 エラー応答のため(上記で定義したように) NOTIFY リクエストが失敗し、 かつサブスクリプションがソフトステートメカニズムを使用して設定され ていた場合、ノーティファイアは対応するサブスクリプションを削除しな ければならない[MUST]。 NOTIFY に対するエラー応答は、サブスクライバーまたはサブスクライ バーまでの経路の途中にあるプロキシで何かがうまくいかなかったこ とを示す。サブスクライバーがエラー状態にある場合、そのエラー状 態が処理されたらすぐに、(再サブスクライブすることで)サブスクラ イバーが状況を修正することを許可するのがもっとも理にかなってい る。プロキシがエラー状態にある場合、定期的に SUBSCRIBE のリフレ ッシュを行うことで、ネットワークの問題が解決されたらすぐに、サ ブスクリプションの状態を再設定する。 NOTIFY リクエストが481応答を受け取る場合、ノーティファイアは対応す るサブスクリプションを、たとえそれが SUBSCRIBE 以外の手段(たとえば 管理用インターフェース)で設定されたものであっても、削除しなければな らない[MUST]。 Roach Standards Track [Page 14] RFC 3265 SIP-Specific Event Notification June 2002 上記の動作が要求されなかった場合、未知のサブスクリプションに対 する NOTIFY を受け取るサブスクライバーは、その NOTIFY に対する 応答でエラーステータスコード、また、そのサブスクリプションを削 除するために SUBSCRIBE リクエストを送る必要があるだろう。この動 作は、サブスクライバーをDoS攻撃の増幅装置として使うことを可能に するので、481応答に特別な意味を与えることにした。481応答は、サ ブスクリプションがすべての状況下でキャンセルされなければならな いことを示すために使用される。 NOTIFY リクエストは、active、pending、あるいは terminated という値 を持つ Subscription-State ヘッダーを含まなければならない[MUST]。 active という値は、サブスクリプションが受け入れられ、(たいていの場 合)認可されたことを示す(セクション5.2参照)。pending という値は、サ ブスクリプションは受け取られたが、そのポリシー情報が現時点でサブス クリプションを受け入れ/拒否するために不十分であることを示す。 terminated という値は、サブスクリプションが active でないことを示す。 Subscription-State ヘッダーの値が active または pending の場合、ノ ーティファイアは Subscription-State ヘッダーに、サブスクリプション に残されている時間を示す expires パラメータも含めるべきである[SHOULD]。 ノーティファイアはサブスクリプションを短縮するためにこのメカニズムを 使ってもよい[MAY]。しかしながら、このメカニズムはサブスクリプション を延長するために使われてはならない[MUST NOT]。 active と pending のサブスクリプションに有効期限情報を含めるこ とは、SUBSCRIBE リクエストがフォークする場合に、フォークされた SUBSCRIBE に対する応答がサブスクライバーに受信されないかもしれ ないので、有用である。この expires 値は Subscription-State ヘッ ダーのパラメータであって、Expires ヘッダーのパラメータでは「ない」 ということに十分注意すること。 Subscription-State ヘッダーの値が terminated の場合、ノーティファイ アは reason パラメータも含めるべきである[SHOULD]。ノーティファイアは 適切な場合には retry-after パラメータも含めてもよい[MAY]。reason と retry-after パラメータの値とセマンティクスについての詳細は、セクシ ョン3.2.4参照のこと。 3.2.3. プロキシの NOTIFY 動作 NOTIFY をサポートするために、SIP(参考文献[1])で述べられていること以 外の追加動作をプロキシは必要としない。プロキシが特定のダイアログの すべての SUBSCRIBE と NOTIFY リクエストを見ることを望む場合、プロキ シは最初の SUBSCRIBE と ダイアログを確立するすべての NOTIFY リクエ ストを record-route しなければならない[MUST]。そのようなプロキシは、 他のすべての SUBSCRIBE と NOTIFY リクエストも record-route するべき である[SHOULD]。 Roach Standards Track [Page 15] RFC 3265 SIP-Specific Event Notification June 2002 サブスクライバーとノーティファイアは SUBSCRIBE と NOTIFY リクエ ストの S/MIME 暗号化を選択するかもしれないということに注意する こと。その結果としてプロキシは、SIP(参考文献[1])においてプロキ シで読み取り可能であることを明示的に要求していないすべての情報 にアクセスできることを当てにできない。 3.2.4. サブスクライバーの NOTIFY 動作 NOTIFY リクエストの受信時に、サブスクライバーはそれが少なくとも一つ の未決定サブスクリプションに一致することをチェックするべきである。 一致しない場合は、他の400クラスか500クラスのエラーコードがより適切と いうのでなければ「481 Subscription does not exist」応答を返さなけれ ばならない[MUST]。NOTIFY リクエストを新規ダイアログを生成するサブス クリプションとマッチングするためのルールはセクション3.3.4で述べられ ている。既存のダイアログ内で生成されたサブスクリプション(複数)に対す る通知(複数)は、それらが同じダイアログ内にあって、かつ Event ヘッダ ーが一致するならマッチする(セクション7.2.1で述べられているように)。 何らかの理由により、NOTIFY リクエストの Event ヘッダーで示されたイ ベントパッケージがサポートされていない場合、サブスクライバーは「489 Bad Event」応答で応答する。 イベントのなりすましを防ぐために、NOTIFY リクエストは何らかの定義済 み SIP 認証メカニズムを使用して認証を行うべきである[SHOULD]。 NOTIFY リクエストはサブスクリプションのステータスを示す Subscription- State ヘッダーを含まなければならない[MUST]。 Subscription-State ヘッダーの値が active である場合、それはサブスク リプションが受け入れられ、(一般的に)認可されたことを意味する。 Subscription-State ヘッダーが expires パラメータも含む場合、サブス クライバーはそれを信頼できるサブスクリプション期間であると解釈し、 そのように調整するべきである[SHOULD]。retry-after と reason パラメ ータは active に対してのセマンティクスを持たない。 Subscription-State の値が pending である場合、サブスクリプションは ノーティファイアによって受け取られたが、そのサブスクリプションを承 認/拒否するための十分なポリシー情報がまだない。Subscription-State ヘッダーが expires パラメータも含む場合、サブスクライバーはそれを信 頼できるサブスクリプション期間であると解釈し、そのように調整するべ きである[SHOULD]。サブスクライバーのパートではそれ以上の動作は必要 でない。retry-after と reason パラメータは pending に対してのセマン ティクスを持たない。 Subscription-State の値が terminated である場合、サブスクライバーは サブスクリプションが終了したとみなすべきである。expires パラメータ は terminated に対してのセマンティクスを持たない。reason コードが存 在する場合、クライアントは以下に記述されるように動作するべきである。 reason コードが存在しないか未知の reason コードが存在する場合、 Roach Standards Track [Page 16] RFC 3265 SIP-Specific Event Notification June 2002 (retry-after パラメータが存在しなければ[この場合、クライアントは retry-after パラメータで指定されている秒数が経過するまで再サブスクラ イブを試みるべきではない[SHOULD NOT]])クライアントはいつでも再サブス クライブを試みてもよい[MAY]。定義済みの reason コードは以下のとおり である。 deactivated: サブスクリプションは終了したが、サブスクライバーはただ ちに新規サブスクリプションで再試行するべきである[SHOULD]。この ようなステータスコードの主たる用途の一つは、ノード間でのサブス クリプションの移行を許可することである。retry-after パラメータは deactivated に対してのセマンティクスを持たない。 probation: サブスクリプションは終了したが、クライアントは後ほど再試 行するべきである[SHOULD]。retry-after パラメータも存在する場合、 クライアントは再サブスクライブを試みる前に少なくともそのパラメ ータで指定された秒数だけ待つべきである[SHOULD]。 rejected: 認可ポリシーの変更によりサブスクリプションは終了した。ク ライアントは再サブスクライブを試みるべきではない[SHOULD NOT]。 retry-after パラメータは rejected に対してのセマンティクスを持 たない。 timeout: 期限切れになる前にリフレッシュされなかったので、サブスクリ プションは終了した。クライアントはただちに再サブスクライブしてもよい [MAY]。retry-after パラメータは timeout に対してのセマンティクスを持 たない。 giveup: ノーティファイアが時宜にかなった方法で認可を取得できなかっ たので、サブスクリプションは終了した。retry-after パラメータも 存在した場合、クライアントは再サブスクライブを試みる前に少なく ともそのパラメータで指定された秒数だけ待つべきである[SHOULD]。 クライアントはただちに再試行してもよい[MAY]が、pending 状態に戻 される可能性が高い。 noresource: 監視されていたリソースの状態がもう存在しないので、サブ スクリプションは終了した。クライアントは再サブスクライブを試み るべきではない[SHOULD NOT]。retry-after パラメータは noresource に対してのセマンティクスを持たない。 サブスクライバーにとって通知が受け入れ可能であると思われたらすぐに、 サブスクライバーは200応答を返すべきである[SHOULD]。一般的に、NOTIFY に対する応答がボディを含むことは期待されていない。しかしながら、 NOTIFY リクエストが Accept ヘッダーを含んでいた場合、ボディを含んで もよい[MAY]。 SIP(参考文献[1])で定義されているその他の応答も、適切に応じて返すこ とができる。どのような場合でも、NOTIFY トランザクションは、自動処理 に必要とされる時間以上に延長されるべきでない。特に、サブスクライバ ーは NOTIFY リクエストに対する最終応答を返す前に、ユーザーの応答を 待ってはならない[MUST NOT]。 Roach Standards Track [Page 17] RFC 3265 SIP-Specific Event Notification June 2002 3.3. 概要 3.3.1. SUBSCRIBE と NOTIFY に対するサポートの検出 SUBSCRIBE も NOTIFY も Require ヘッダーや Proxy-Require ヘッダーの 使用を必要としない。同様に、Supported ヘッダーに対して定義されたト ークンはない。必要であれば、クライアントは SIP(参考文献[1])で定義さ れている OPTIONS リクエストを使用して、SUBSCRIBE と NOTIFY のサポー トを調べることができる。 SUBSCRIBE と NOTIFY に対するサポートを示すためには、メッセージ中に Allow-Events ヘッダーがあれば十分である。 登録を行うときに、SUBSCRIBE と NOTIFY メッセージに対するサポー トを明確に告知するために、Contact の methods パラメータも使用で きる。(methods パラメータの詳細については参考文献[8]参照のこと) 3.3.2. CANCEL リクエスト SUBSCRIBE または NOTIFY をキャンセルすることにセマンティクスは関連 付けられていない。 3.3.3. フォーク SIP(参考文献[1])で定義されているように非INVITEリクエストをプロキシ するためのルールにしたがい、成功する SUBSCRIBE リクエストはただ一つ の200クラス応答を受け取る。しかしながら、フォークにより、サブスクリ プションは複数のノードに受け入れられているかもしれない。したがって サブスクライバーは、SUBSCRIBE に対する200クラス応答で受け取った To: tag とは異なる From tag を持つ NOTIFY リクエストを受け取ることに備 えなければならない[MUST]。 一つの SUBSCRIBE メッセージに対して応答において異なるダイアログで複 数の NOTIFY メッセージを受け取る場合、各ダイアログは SUBSCRIBE リク エストがフォークされた異なるデスティネーションを表す。そのような状況 でのサブスクライバーのハンドリングについての情報は、セクション4.4.9 を参照すること。 3.3.4. ダイアログの生成と終了 最初の SUBSCRIBE リクエストが既存のダイアログ上で送られない場合、サ ブスクライバーは、その SUBSCRIBE リクエストに対する応答、またはマッ チする NOTIFY を待つだろう。 応答と SUBSCRIBE リクエストが同じ Call-ID、同じ From ヘッダーの tag、 および同じ CSeq を含む場合、それらはマッチする。これらのヘッダーの 比較のためのルールは SIP(参考文献[1])で述べられている。200クラス応 答がそのような SUBSCRIBE リクエストにマッチする場合、それは新規サブ スクリプションと新規ダイアログを生成する(マッチする NOTIFY リクエス トによってすでに生成されていなければ。下記参照)。 Roach Standards Track [Page 18] RFC 3265 SIP-Specific Event Notification June 2002 NOTIFY リクエストと SUBSCRIBE リクエストが同じ Call-ID、SUBSCRIBE の From ヘッダーの tag パラメータにマッチする To ヘッダーの tag パ ラメータ、および同じ Event ヘッダーフィールドを含む場合、それらはマ ッチする。Event ヘッダーの比較のためのルールはセクション7.2.1で述べ られている。マッチする NOTIFY リクエストが active または pending と いう値を持つ Subscription-State を含む場合、それは新規サブスクリプ ションと新規ダイアログを生成する(上述のように、マッチする応答によっ てすでに生成されていなければ)。 最初の SUBSCRIBE が既存のダイアログ上で送られた場合、マッチする200 クラス応答または成功する NOTIFY リクエストは、単にそのダイアログに 関連付けられたサブスクリプションを生成するだけである。 複数のサブスクリプションを一つのダイアログに関連付けることができる。 INVITE で生成されたアプリケーション状態、および他の仕様で定義された メカニズムによって生成されたその他のアプリケーション状態に関連付けら れたダイアログ上にも、サブスクリプションは存在するかもしれない。 これらのアプリケーション状態のセットは、ダイアログに対して記述され ている動作以外の相互作用をしない(例: ルートセットのハンドリング)。 ノーティファイアが Subscription-State に terminate という値を持つ NOTIFY リクエストを送るとき、サブスクリプションは破棄される。 そのような NOTIFY リクエストを送るきっかけを作るために、サブス クライバーは Expires ヘッダーに 0 という値を持つ SUBSCRIBE リク エストを送ることができる。しかしながら、サブスクリプションとダ イアログの存続期間の目的のために、Subscription-State に terminated という値を持つ NOTIFY が送られるまでは、サブスクリプションが終 了したとみなされない。 サブスクリプションの破棄が、ダイアログに関連付けられたそれ以外のア プリケーション状態を残さない場合、そのダイアログは終了する。それ以 外のアプリケーション状態(INVITE で生成されたものなど)の破棄は、サブ スクリプションがまだダイアログに関連付けられているなら、そのダイア ログを終了しない。 上記の動作は、INVITE で生成されたダイアログが BYE の受信時に必 ずしも破棄されないことを意味する、ということに注意すること。同 様に、一つのダイアログにいくつかのサブスクリプションが関連付け られている場合、ダイアログ内のすべてのサブスクリプションが破棄 されるまで、そのダイアログは終了しない。 3.3.5. ステートエージェントとノーティファイア移行 ステートエージェント(セクション4.4.11参照)が使用されるとき、ステー トエージェントとそれらがステートの集合体を提供するノードとのあいだ で(あるいは様々なステートエージェントのあいだでも)サブスクリプショ ンの移行を許可することは有用であることが多い。そのような移行は、 Roach Standards Track [Page 19] RFC 3265 SIP-Specific Event Notification June 2002 Subscription-State ヘッダーに terminated という値を持ち、reason パ ラメータに deactivated という値を持つ NOTIFY メッセージを送ることで なされるかもしれない。この NOTIFY リクエストはその他の点では通常と 何ら変わるところがなく、セクション3.2.2で述べられているように形成さ れる。 この NOTIFY メッセージの受信時に、サブスクライバーは(前述のセクショ ンで述べられているように)再サブスクライブを試みるべきである[SHOULD]。 このサブスクリプションは新規ダイアログ上で確立され、前のサブスクリ プションのダイアログからルートセットを再利用しないということに注意 すること。 他のノードが SUBSCRIBE リクエストに対して応答することになるように、 その SUBSCRIBE リクエストが送られる一つ以上のサーバーのポリシー(た とえばルーティング決定)を変更することで、実際の移行はなされる。これ は、サブスクリプションの移行元のノーティファイアが、ノーティファイ アの代わりにプロキシまたはリダイレクトサーバーとしての役割を果たす ように、ノーティファイアのローカルポリシーを変更することと同じくら い単純なことかもしれない。 ノーティファイアの移行を実行するかどうか、いつ実行するか、そしてな ぜ実行するかは、個々のイベントパッケージで述べられるかもしれない。 そうでなければ、そのようなことの決定はローカルノーティファイアのポ リシーの問題であり、個々の実装に任される。 3.3.6. リソースステートのポーリング 前述のセクションで述べられている動作の自然な帰結として、Expires に 0 という値を持つ SUBSCRIBE を送ることで、持続するサブスクリプション なしで即時取得がなされる。 サブスクリプションが active のあいだの即時取得は、当然、Expires に サブスクリプションに残っている秒数と等しい値を持つ SUBSCRIBE を送る ことでなされる。 この SUBSCRIBE リクエストの受信時に、ノーティファイア(SUBSCRIBE リ クエストがフォークされた場合には複数のノーティファイア)は、リソース ステートを含む NOTIFY リクエストを同じダイアログ内で送る。 Expires ヘッダーに 0 という値を持つ SUBSCRIBE メッセージによって引 き起こされた NOTIFY メッセージは、Subscription-State 値として terminated、そして reason パラメータに timeout を含むということに注 意すること。 イベントステートのポーリングは、ネットワークとノーティファイアの負 荷に重大な増加をもたらすことがありうる。したがって、それは控えめに 使用されるべきである。特に、ポーリングが長時間動作しているサブスク リプションよりも多くのネットワークメッセージを一般的にもたらす結果 になるような状況では、ポーリングは使用されるべきではない[SHOULD NOT]。 Roach Standards Track [Page 20] RFC 3265 SIP-Specific Event Notification June 2002 ポーリングが使用されるとき、サブスクライバーは送られるメッセージの 数を減らすために、ポーリング間で認証の信用証明書をキャッシュするこ とを試みるべきである[SHOULD]。 3.3.7. Allow-Events ヘッダーの用法 (もし存在すれば)Allow-Events ヘッダーは(リクエストで送られた場合に は)クライアントによってサポートされるイベントパッケージを、(応答で 送られた場合には)サーバーによってサポートされるイベントパッケージを 示すトークンのリストを含む。言い換えるなら、Allow-Events ヘッダーを 送るノードは、そのヘッダーにリストされているイベントパッケージすべ てに対しての SUBSCRIBE リクエストを処理することと NOTIFY リクエスト を生成することができるということを広告している。 一つ以上のイベントパッケージを実装するいかなるノードも、すべてのメ ソッド(そのメソッドは、ダイアログとそれらに対する応答を開始する。た とえば INVITE)、およびOPTIONS に対する応答に、サポートされるすべて のイベントを示す適切な Allow-Events ヘッダーを含むべきである[SHOULD]。 たとえば、特定のインターフェースエレメントが表す機能を組み込むため に必要とされるイベントが、しかるべきノードでサポートされているかど うかということに応じて、ユーザーエージェントがそのインターフェース エレメントを適切に描写することを可能にするために、この情報はとても 有用である。 Allow-Events ヘッダーをプロキシが挿入してはならない、ということに注 意すること。 3.3.8. PINT 互換性 Event ヘッダーはこのドキュメントの目的を達成するために必須であるとみ なされる。しかしながら、PINT(参考文献[2])との互換性を維持するために、 サーバーは Event ヘッダーを持たない SUBSCRIBE リクエストを PINTイベ ントへのサブスクリプションを要求しているものと解釈してもよい[MAY]。 サーバーが PINT をサポートしない場合、それは、Event ヘッダーを持たな いいかなる SUBSCRIBE メッセージに対しても「489 Bad Event」 を返すべきである[SHOULD]。 4. イベントパッケージ このセクションでは、SUBSCRIBE と NOTIFY に基づいてイベントパッケー ジがプロポーズされるときに考慮されるべき、いくつかの問題を取り上げ る。 4.1. 用途の適切性 イベント通知のためにこのドキュメントで述べられているメソッドを使用 して、イベントパッケージを設計するとき、次の点を考慮することが大切 である。 ・問題セットに対して、SIP は適切なメカニズムであるか。 ・プロトコルで提供される独自の機能(例: ユーザーモビリティ)、あるい は単に「それができる」という理由で SIP が選択されているのか。 たとえば、ネットワーク管理や車のエンジン内の温度に関する通知のため Roach Standards Track [Page 21] RFC 3265 SIP-Specific Event Notification June 2002 にイベントパッケージを定義しているのだと気付いたなら、プロトコルの 選択を再考したほうが良いだろう。 このドキュメントで定義されているメカニズムの拡張に興味がある人 は、SIP の適切な用途に関する更に詳しい手引きのための「SIP 拡張 の著者のためのガイドライン」(参考文献[7])の動きにしたがうことが 強く要求される。 さらに、報告可能なイベントの頻度が過剰に多い(例: 1秒につきおよそ2回 以上)アプリケーションでは、このメカニズムが使用されないことが望まれ る。SIP ネットワークは、一般的に、適度なシグナリング量のために用意 される。ユーザーのGPS位置が1/100秒単位で変化するたびに通知を送るこ とは、そのようなネットワークを容易にオーバーロードするのではないだ ろうか。 4.2. イベントテンプレートパッケージ 通常のイベントパッケージは、ユーザープレゼンス、コールステート、メ ッセージングメールボックス ステートのようなリソースの特定のタイプに 適用されるステートのセットを定義する。 イベントテンプレートパッケージは、統計、アクセスポリシー、サブスク ライバーリストのような他のパッケージに適用される、ステートのセット を定義する特別なタイプのパッケージである。イベントテンプレートパッ ケージは、他のイベントテンプレートパッケージに適用することもできる。 初期に作られたオブジェクト指向アナロジーを拡張するために、イベント テンプレートパッケージは、他のパッケージが有用であるために適用され なければならない、テンプレート化された C++ パッケージと考えることが できる。 パッケージに適用されるときのイベントテンプレートパッケージの名称は、 そのパッケージの最後にピリオドとそれに続くイベントテンプレートパッ ケージ名を追加することで形成される。たとえば、winfo というテンプレ ートパッケージが presence というパッケージに適用されていた場合、 Event と Allow-Events で使用されるイベントトークンは presence.winfo となるだろう。 イベントテンプレートパッケージは、それらが任意のいかなるパッケージ にも適用可能なように定義されなければならない。言い換えるなら、イベ ントテンプレートパッケージは、他のパッケージと連携しないような方法 で、一つあるいはいくつかの「親」パッケージに特別に関連付けることは できない。 4.3. 伝達されるステートの量 イベントパッケージを設計するとき、通知時に伝えられることになる情報 のタイプを考慮することが大切である。 Roach Standards Track [Page 22] RFC 3265 SIP-Specific Event Notification June 2002 単にイベントだけ(例: 「a new voice message just arrived (新しいボイ スメッセージが届きました)」)をステート(例: 「7 total voice messages (全部で7件のボイスメッセージ)」)を付けずに伝えることが、自然な誘惑 である。これは、サブスクライブするエンティティの実装を複雑にし(なぜ なら、それらは、サブスクライブ先のエンティティの完全なステートを保 持しなければならないので)、また同期問題に特に影響を受けやすい。 実装するためにイベントパッケージが選択できる、この問題に対する考え られる2つの解決策がある。 4.3.1. 完全なステート情報 適度に小さい(1KBくらいのオーダーで)ステート情報を通常運ぶパッケージ は、イベントが発生したときに完全なステート情報を送るようにイベント パッケージを設計することを提案する。 ある状況下では、現在のステートのみを伝えることは、特定のイベントク ラスにとっては不十分であるかもしれない。この場合、イベントパッケー ジは、発生したイベントと共に完全なステート情報も含めるべきである。 たとえば、「no customer service representatives available (カスタマ ーサービス担当者は不在です)」を伝えることは、「no customer service representatives available; representative sip:46@cs.xyz.int just logged off (カスタマーサービス担当者は不在です。担当者 sip:46@cs.xyz.int はログオフしました。)」を伝えることと同程度には有 用でないかもしれない。 4.3.2. ステートの差分 伝えられるステート情報が大きい場合、イベントパッケージは、NOTIFY メ ッセージが完全なステートの代わりにステートの差分を含むことで、スキ ームを詳述することを選択できる。 そのようなスキームは次のように機能する。SUBSCRIBE に対する即時応答 で送られたいかなる NOTIFY も、完全なステート情報を含む。ステートが 変化したために送られた NOTIFY メッセージは、変化したステート情報だ けを含む。それからサブスクライバーは、この情報をリソースのステート について現在知っていることにマージする。 ステートに対する変化の差分をサポートするいかなるイベントパッケージ も、サブスクリプションのそれぞれの NOTIFY メッセージに対して正確に 1 ずつ増加するバージョン番号を含まなければならない[MUST]。ステート のバージョン番号は SIP ヘッダーではなく、メッセージのボディに現れる ことに注意すること。 2 以上増加されたバージョン番号を持つ NOTIFY が到着する場合、サブス クライバーはステートの差分が失われたことを知る。サブスクライバーは ステートの差分を含むその NOTIFY メッセージを無視し(バージョン番号を Roach Standards Track [Page 23] RFC 3265 SIP-Specific Event Notification June 2002 除く。メッセージロスを検知するためにサブスクライバーはバージョン番 号を保持する)、完全なステートのスナップショットを含む NOTIFY を強制 するために、SUBSCRIBE を再送する。 4.4. イベントパッケージの責務 イベントパッケージは、このドキュメントで述べられているいかなる動作 も、繰り返すことを要求されないが、明確さや強調のためにそうすること を選択できる。しかし一般的に、そのようなパッケージは、このドキュメ ントで述べられている動作を拡張したり修正したりする動作だけを述べる ことが望まれている。 「SHOULD」や「MUST」で指定されたいかなる動作も、拡張ドキュメントで 弱められることが認められていない。しかしながら、アプリケーションに 必要とされる場合は、そのようなドキュメントは「SHOULD」要求を「MUST」 に強めることを選択できる。 standards-track RFC および SIP 拡張のドキュメントで要求されてい る通常のセクションに加えて、イベントパッケージの著者は、以下の サブセクションで詳述されている各問題に当てはまる場合にはいつでも、 対応する必要がある。 4.4.1. イベントパッケージ名 必ず存在しなければならない[MUST]このセクションは、イベントパッケー ジを指定するために使用されるトークン名を定義する。それは、トークン を IANA に登録するときに出ている情報を含まなければならない[MUST]。 そのようなタイプの登録については、セクション 6 を参照のこと。 4.4.2. イベントパッケージのパラメータ イベントパッケージの動作を修正するために Event ヘッダーでパラメータ が使用される場合、そのようなヘッダーのシンタックスとセマンティクス が明確に定義されなければならない[MUST]。 4.4.3. SUBSCRIBE のボディー すべてではないがほとんどのイベントパッケージが、SUBSCRIBE メソッド のボディのためにシンタックスとセマンティクスを定義することが望まれ ている。これらのボディは通常、要求されているイベントのクラスに対し て、修正、拡張、フィルター、抑制、および/または閾値の設定をおこなう。 イベントパッケージの設計者は、メッセージボディに対して、実用性があ れば既存の MIME タイプを再利用することが強く奨励されている。 Roach Standards Track [Page 24] RFC 3265 SIP-Specific Event Notification June 2002 イベントパッケージのこの必須のセクションは、どのタイプ(一つまたは複 数)が SUBSCRIBE リクエストに望まれているかを定義する(またはイベント ボディがまったく望まれていないことを明記する)。このセクションは、参 照されているすべてのボディタイプのためのシンタックスとセマンティク スの詳細な定義を指し示すべきである。 4.4.4. サブスクリプション期間 イベントパッケージはサブスクリプション期間として、合理的と思われる 推奨時間幅を提示することが推奨される[RECOMMENDED]。そのようなパッケ ージは、Expires 値が指定されなかった場合に使用される Expires の初期 値も定義しなければならない[MUST]。 4.4.5. NOTIFY のボディー NOTIFY のボディは監視されているリソースのステートを報告するために使 用される。各パッケージは、NOTIFY リクエスト中にどのタイプ(ひとつまた は複数)のイベントボディが望まれているかを定義しなければならない [MUST]。そのようなパッケージはそのようなイベントボディに関連付けられ たシンタックスとセマンティクスのための詳細な仕様を規定または引用しな ければならない[MUST]。 イベントパッケージは、SUBSCRIBE リクエストの Accept ヘッダーで何も 指定されていない場合にどの MIME タイプだと仮定するかも定義しなけれ ばならない[MUST]。 4.4.6. ノーティファイアでの SUBSCRIBE リクエスト処理 このセクションでは、SUBSCRIBE リクエストの受信時にノーティファイア で実行される処理について述べる。このようなセクションは必須である。 このセクション内の情報には、サブスクライバーをどのように認証するか、 およびパッケージの認可問題についての詳細が含まれる。このような認可 問題は、たとえば、このパッケージに対するすべての SUBSCRIBE リクエス トが202応答で答えられるかどうか(セクション5.2参照)といったことを含 むことができる。 4.4.7. ノーティファイアでの NOTIFY リクエストの生成 イベントパッケージのこのセクションは、ノーティファイアが NOTIFY リ クエストを生成して送る過程について述べる。これは、何のイベントが NOTIFY を送らせることになるか、NOTIFY の情報をどのように計算するか、 認可の遅延と決定をユーザーから隠すためにニュートラルまたは偽のステ ート情報をどのように生成するか、通知のためのステート情報が完全なも のかまたは差分か、についての詳細な情報を含む(セクション4.3参照)。 このようなセクションは必須である。 このセクションは、その後の応答を処理するために使用される動作につい て随意に述べることができる。 Roach Standards Track [Page 25] RFC 3265 SIP-Specific Event Notification June 2002 4.4.8. サブスクライバでの NOTIFY リクエスト処理 イベントパッケージのこのセクションは、(妥当であれば)首尾一貫したリ ソースのステートを形成するために必要とされるすべてのロジックを含め て、NOTIFY リクエスト受信時にサブスクライバが従う処理について述べる。 4.4.9. フォークされたリクエストのハンドリング 各イベントパッケージは、複数のサブスクリプションを組み込むために、 フォークされた SUBSCRIBE リクエストが認められるかどうかを規定しなけ ればならない[MUST]。 そのような動作が認められない場合、ダイアログを確立する可能性のある 最初のメッセージがダイアログを生成する。SUBSCRIBE メッセージに対応 する(すなわち、To、From、From ヘッダーの tag パラメータ、Call-ID、 CSeq、Event、および Event ヘッダーの id パラメータがマッチする)が、 ダイアログにはマッチしないそれ以降のすべての NOTIFY メッセージは、 481応答で拒否されるだろう。マッチする NOTIFY が受信された後に SUBSCRIBE に対する200クラス応答が到着することがある、ということに注 意すること。そのような応答は、その NOTIFY によって確立されたのと同 じダイアログに関連付けられないかもしれない。SUBSCRIBE トランザクシ ョンを完了するために必要とされるとき以外は、そのようなマッチしない 200クラス応答は無視される。 フォークされたひとつの SUBSCRIBE を通して複数のサブスクリプションを 組み込むことが認められている場合、サブスクライバーは各 NOTIFY に対 して200クラス応答を返すことで、各ノーティファイアに対して新規ダイア ログを確立する。各ダイアログはその後、それ自身のエンティティとして ハンドリングされ、他のダイアログとは独立にリフレッシュされる。 複数のサブスクリプションが認められている場合、イベントパッケージは ひとつのステートを形成するために通知をマージする必要があるかどうか、 そしてそのようなマージをどのように実行するかを規定しなければならな い[MUST]。各ダイアログが他のダイアログに影響を受けない互いに相容れ ないステートに結び付けられるように、いくつかのイベントパッケージは 定義されることがありえるということに注意すること。その場合には、こ れは明確に述べられなければならない[MUST]。 4.4.10. 通知レート 各イベントパッケージは、ひとつのノーティファイアで生成されることが 認められている通知のレートの絶対的な最大値を定義する要求(SHOULD ま たは MUST 強度)を定義することが望まれている。 各パッケージは、サブスクライバーが通知レートをさらに制限することを認 める、抑制メカニズムをさらに定義してもよい[MAY]。 Roach Standards Track [Page 26] RFC 3265 SIP-Specific Event Notification June 2002 4.4.11. ステートエージェント イベントパッケージの設計者は、パッケージがネットワーク集成ポイント (ステートエージェント)および/または他のノードの代わりに動作するノー ドから利益を得ることができるかどうか考慮するべきである。(たとえば、 リソースがそれ自身でステート情報を提供することができないかそのつも りがないときに、そのリソースについてのステート情報を提供するノード) そのようなアプリケーションの例は、ネットワーク上でユーザーのプレゼ ンスや有効性を追跡するノードである。 パッケージによってステートエージェントが使用されることになる場合、 そのパッケージは、そのステートエージェントがどのように情報を集成す るか、そしてそれらが認証と認可をどのように提供するかを規定しなけれ ばならない[MUST]。 イベントパッケージは、ノーティファイアの移行が起こる場合の具体的なシ ナリオを概説してもよい[MAY]。 4.4.12. 例 イベントパッケージは、いくつかの典型的でシンタックス的に正確かつ完 全なメッセージと組み合わせた、いくつかの例証的なメッセージフロー図 を含めるべきである[SHOULD]。 イベントパッケージについて述べるドキュメントは、正確なプロトコルの 詳細については実装者はドキュメントのメインテキストを参照することと いう指示とともに、その例は情報を与えるためのものであって規範となる ものではないということを明確に示すことが推奨される[RECOMMENDED]。 4.4.13. ステートを取り出すための URI の使用 いくつかのタイプのイベントパッケージは、SIP メッセージで合理的に送 るには大きすぎる可能性があるステート情報を定義するかもしれない。こ の問題を緩和するために、イベントパッケージはステート情報の代わりに URI を伝える能力を含むことができる。この URI はその後、実際のステー ト情報を取り出すために使用される。 このような URI を伝えるための正確なメカニズムは、このドキュメントの 適用範囲外である。 Roach Standards Track [Page 27] RFC 3265 SIP-Specific Event Notification June 2002 5. セキュリティの考慮 5.1. アクセス制御 多くのタイプのイベントはプライバシーのために重要であると考えることが できるので、サブスクリプションを受け入れる能力はノーティファイアのユ ーザーの直接の制御下にあるべきである。同様に、ノーティファイアは標準 的な SIP 認証メカニズムを使用して、(アクセス制御リストに基づく)サブ スクライバーの身元に基づいてサブスクリプションを選択的に拒否する能力 を持つべきである。そのようなアクセス制御リストの生成と配布は、このド キュメントの適用範囲外である。 5.2. ノーティファイアのプライバシーメカニズム SUBSCRIBE リクエストに対して単に200応答または特定の4xx応答と6xx応答 を返す動作は、特定の状況下で、重要なポリシー情報を明かすことによっ てプライバシーに対する懸念を生み出すかもしれない。これらの場合、ノ ーティファイアは常に202応答を返すべきである[SHOULD]。それ以降の NOTIFY メッセージが正しいステートを伝えないかもしれないとしても、有 効な応答と区別できないように、サブスクライバーの視点からみて正しい 可能性のあるデータ片を含んでいるように見せなければならない[MUST]。 要求されたステートにユーザーがサブスクライブすることを認可されたか どうかについての情報は、これらの状況下ではオリジナルのユーザーに送 り返されることは決してない。 このようなオペレーションモードが道理にかなう個々のパッケージとそれ らが関連するドキュメントは、そのような正しい可能性のあるデータをど のようにそしてなぜ生成するかについてさらに詳しく述べることができる。 たとえば、そのようなオペレーションモードは、ユーザープレゼンス情報 のために RFC2779(参考文献[6])で必須とされている。 5.3. DoS 攻撃 現在のモデル(ひとつの SUBSCRIBE リクエストが SUBSCRIBE に対する応答 とひとつ以上の NOTIFY リクエストを引き起こす)は、スマーフ攻撃におい て使用される増幅ノードのための典型的な機構である。 また、SUBSCRIBE リクエスト受信時にステートの生成をすることは、被害 者のマシン上のリソースを消費してそれを使用不可能にするために、攻撃 者が利用できる。 このような攻撃の機会を減らすために、ノーティファイアの実装は認証を 要求するべきである[SHOULD]。認証の問題は SIP(参考文献[1])で議論され ている。 Roach Standards Track [Page 28] RFC 3265 SIP-Specific Event Notification June 2002 5.4. リプレイ攻撃 SUBSCRIBE または NOTIFY いずれかのリプレイは、有害な効果を持つこと がある。 SUBSCRIBE メッセージの場合、攻撃者は、過去のある時点で設定されてい るのを目撃した任意のいかなるサブスクリプションでも設定できるかもし れない。NOTIFY メッセージのリプレイは、古いステート情報になりすます ために使用することができる(NOTIFY メッセージのボディの優秀なバージ ョン付けメカニズムは、そのような攻撃を軽減する役に立つが)。イベント にサブスクライブしていないノードへの NOTIFY メッセージ送信を禁止す ることも、そのような攻撃の効果を軽減する助けになる、ということに注 意すること。 そのような攻撃を防ぐために、実装は、リプレイ攻撃に対する防御を兼ね 備えた認証を要求するべきである[SHOULD]。認証の問題は SIP(参考文献[1]) で議論されている。 5.5. man-in-the-middle攻撃 たとえ認証を行っても、SUBSCRIBE を利用するman-in-the-middle(仲介者) 攻撃は、任意のサブスクリプションを設定するため、既存のサブスクリプ ションを乗っ取るため、未解決のサブスクリプションを終了させるため、 あるいはサブスクリプションが行われることになるリソースを修正するた めに使用されるかもしれない。このような攻撃を防ぐために、実装は、少な くとも SUBSCRIBEの Contact、Route、Expires、および To ヘッダーにまた がる一貫性防御を提供するべきである[SHOULD]。SUBSCRIBE のボディが呼の ステートについての更なる情報を定義するために使用される場合、それは一 貫性防御スキームに含まれるべきである[SHOULD]。 man-in-the-middle攻撃は、任意のステート情報になりすますためおよび/ま たは未解決のサブスクリプションを終了させるために NOTIFY メッセージの 使用も試みるかもしれない。このような攻撃を防ぐために、実装は、NOTIFY メッセージの Call-ID、CSeq、Subscription-State ヘッダー、およびボディ にまたがる一貫性防御を提供するべきである[SHOULD]。 メッセージヘッダーとボディの一貫性防御は SIP(参考文献[1])で議論され ている。 5.6. 機密性 NOTIFY メッセージに含まれるステート情報は、重要な情報を含む可能性が ある。実装は機密性を保障するために、そのような情報を暗号化してもよい [MAY]。 可能性は少ないが、SUBSCRIBE メッセージに含まれる情報が、明かされるこ とをユーザーが望まないかもしれない情報を含むこともありえる。実装は機 密性を保障するために、そのような情報を暗号化してもよい[MAY]。 Roach Standards Track [Page 29] RFC 3265 SIP-Specific Event Notification June 2002 リモートパーティが重要であるとみなす情報を、そのリモートパーティが 隠すことを許可するために、すべての実装は暗号化された SUBSCRIBE と NOTIFY メッセージをハンドリングできるべきである[SHOULD]。 機密性を提供するためのメカニズムは SIP(参考文献[1])で詳述されている。 6. IANA 条項 このドキュメントは、中心となる調整機関を必要とする event-type の名 前空間を定義する。この調整のために選ばれた機関は、Internet Assigned Numbers Authority (IANA) である。 event-types には異なる2つのタイプがある。通常のイベントパッケージと イベントテンプレートパッケージである(セクション4.2参照)。混乱を避け るため、テンプレートパッケージ名とパッケージ名は同一の名前空間を共 有する。言い換えるなら、イベントテンプレートパッケージはパッケージ と名前を共有してはならない[MUST NOT]ということである。 「Guidelines for Writing an IANA Considerations Section in RFCs (RFC において「IANA の考慮」セクションを執筆するためのガイドライン)」(参 考文献[4])で概説されているポリシーに従い、通常のイベントパッケージ を識別するトークンは先着順で割り当てられ、イベントテンプレートパッ ケージを識別するトークンは IETF の総意に基づいて割り当てられる。 IANA への登録は、登録されるトークンと、そのトークンがパッケージであ るかテンプレートパッケージであるかを含めなければならない[MUST]。さ らに、パッケージは、登録に責任を負う団体の連絡先および/またはそのイ ベントパッケージについて述べた発行済みドキュメントを含まなければな らない[MUST]。イベントテンプレートパッケージのトークンの登録は、そ のイベントテンプレートパッケージについて述べた発行済み RFC へのポイ ンタを含まなければならない[MUST]。 パッケージとテンプレートパッケージを指定するために登録されたトーク ンは、テンプレートパッケージをパッケージから分離するために使用され る文字「.」を含んではならない[MUST NOT]。 6.1. 登録情報 このドキュメントではパッケージ名もテンプレートパッケージ名も規定し ないので、イベントタイプについての当初の IANA への登録は何もない。 このセクションのこれ以降の部分では、IANA によって維持される情報の種 別の例を与える。また、可能性のある5つのすべてのパッケージタイプ、連 絡先、参考文献の順列も説明する。 以下の表は、「SIP-Specific Event Notification (SIP 特有のイベント通 知)」[RFCxxxx]において定義されているイベントパッケージとテンプレー トパッケージをリストしたものである。各名称は、Type 欄で package ま たは template-package として指定されている。 Roach Standards Track [Page 30] RFC 3265 SIP-Specific Event Notification June 2002 Package Name Type Contact Reference (パッケージ名) (種別) (連絡先) (参考文献) ------------ ---- ------- --------- example1 package [Roach] example2 package [Roach] [RFC 3265] example3 package [RFC 3265] example4 template [Roach] [RFC 3265] example5 template [RFC 3265] PEOPLE ------ [Roach] Adam Roach REFERENCES ---------- [RFC 3265] A. Roach "SIP-Specific Event Notification", RFC 3265, August 2002. 6.2. 登録テンプレート To: ietf-sip-events@iana.org Subject: Registration of new SIP event package Package Name: (パッケージ名はセクション7.2.1で述べられているシンタックスに準 拠しなければならない) Is this registration for a Template Package: (この登録はテンプレートパッケージについてのものか) (indicate yes or no) (yes または no で示す) Published Specification(s): (発行済みの規格) (テンプレートパッケージには発行済みの RFC が必要とされる。他の パッケージは、適切なときには、規格を参照することができる) Person & email address to contact for further information: (更なる情報を得るために連絡を取るための人とE-メールアドレス) 6.3. ヘッダーフィールド名称 このドキュメントでは、このドキュメントの他の場所で述べられている、 新しい 3つのヘッダーフィールド名を登録する。これらのヘッダーは以下 の情報によって定義される。この情報は、 http://www.iana.org/assignments/sip-parameters のヘッダーサブレジストリに追加されることになる。 Header Name: Allow-Events Compact Form: u Roach Standards Track [Page 31] RFC 3265 SIP-Specific Event Notification June 2002 Header Name: Subscription-State Compact Form: (なし) Header Name: Event Compact Form: o 6.4. 応答コード このドキュメントでは、新しい 2つの応答コードを登録する。これらの 応答コードは以下の情報によって定義される。この情報は、 http://www.iana.org/assignments/sip-parameters のメソッドと応答コードのサブレジストリに追加されることになる。 Response Code Number: 202 Default Reason Phrase: Accepted Response Code Number: 489 Default Reason Phrase: Bad Event 7. シンタックス このセクションは、SIP のイベント通知に必要とされるシンタックスの拡 張について述べる。セマンティクスはセクション3で述べられている。この ドキュメントで述べられている正式なシンタックス定義は、SIP(参考文献[1]) で使用されている ABNF 形式で表現されており、そこで定義されているエ レメントへの参照を含むということに注意すること。 7.1. 新規メソッド このドキュメントでは新しい2つの SIP メソッド、SUBSCRIBE と NOTIFY について述べている。 この表は、SIP(参考文献[1])の表2 および表3 を拡張する。 Header Where SUB NOT ------ ----- --- --- Accept R o o Accept 2xx - - Accept 415 o o Accept-Encoding R o o Accept-Encoding 2xx - - Accept-Encoding 415 o o Accept-Language R o o Accept-Language 2xx - - Accept-Language 415 o o Alert-Info R - - Alert-Info 180 - - Allow R o o Roach Standards Track [Page 32] RFC 3265 SIP-Specific Event Notification June 2002 Allow 2xx o o Allow r o o Allow 405 m m Authentication-Info 2xx o o Authorization R o o Call-ID c m m Contact R m m Contact 1xx o o Contact 2xx m o Contact 3xx m m Contact 485 o o Content-Disposition o o Content-Encoding o o Content-Language o o Content-Length t t Content-Type * * CSeq c m m Date o o Error-Info 300-699 o o Expires o - Expires 2xx m - From c m m In-Reply-To R - - Max-Forwards R m m Min-Expires 423 m - MIME-Version o o Organization o - Priority R o - Proxy-Authenticate 407 m m Proxy-Authorization R o o Proxy-Require R o o RAck R - - Record-Route R o o Record-Route 2xx,401,484 o o Reply-To - - Require o o Retry-After 404,413,480,486 o o Retry-After 500,503 o o Retry-After 600,603 o o Route R c c RSeq 1xx o o Server r o o Subject R - - Supported R o o Supported 2xx o o Timestamp o o To c(1) m m Unsupported 420 o o Roach Standards Track [Page 33] RFC 3265 SIP-Specific Event Notification June 2002 User-Agent o o Via c m m Warning R - o Warning r o o WWW-Authenticate 401 m m 7.1.1. SUBSCRIBE メソッド SIP メッセージの文法中のエレメントである Method の定義に、SUBSCRIBE が追加される。 他のすべての SIP メソッド名と同様に、SUBSCRIBE メソッドの名称は大文 字小文字を区別する。SUBSCRIBE メソッドは、後ほど、イベントまたはイ ベントセットの非同期通知を要求するために使用される。 7.1.2. NOTIFY メソッド SIP メッセージの文法中のエレメントである Method の定義に、NOTIFY が 追加される。 NOTIFY メソッドは、以前の SUBSCRIBE メソッドで要求されているイベン トが起こったことを、SIP ノードに通知するために使用される。NOTIFY メ ソッドは、イベントについての更なる詳細を提供することもできる。 7.2. 新規ヘッダー この表は、セクション7.1で述べられている変更点を反映することで、SIP (参考文献[1])の表2 および表3 を拡張する。 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT ----------------------------------------------------------------- Allow-Events R o o - o o o o o o Allow-Events 2xx - o - o o o o o o Allow-Events 489 - - - - - - - m m Event R - - - - - - - m m Subscription-State R - - - - - - - - m 7.2.1. Event ヘッダー SIP メッセージの文法中のエレメントである message-header の定義に、 Event が追加される。 応答と NOTIFY メッセージを SUBSCRIBE メッセージにマッチングする目的 で、Event ヘッダーの event-type 部分がバイトごとに比較され、 id パ ラメータトークンが(もし存在すれば)バイトごとに比較される。id パラメ ータを含む Event ヘッダーは、id パラメータを持たない Event ヘッダー には決してマッチしない。比較を行うときに他のパラメータは考慮されな い。 Roach Standards Track [Page 34] RFC 3265 SIP-Specific Event Notification June 2002 上述の文章は、「Event: foo; id=1234」は「Event: foo; param=abcd; id=1234」にマッチするが、「Event: foo」(id がマッチしない)や 「Event: Foo; id=1234」(イベント部分がマッチしない)にはマッチし ないことを意味する。 このドキュメントは event-types の値を定義しない。これらの値は個々の イベントパッケージで定義され、IANA に登録されなければならない[MUST]。 一つの Event ヘッダーに一つの event type がリストされなければならな い[MUST]。一つのメッセージに複数のイベントは認められていない。 7.2.2. Allow-Events ヘッダー SIP メッセージの文法中のエレメントである general-header の定義に、 Allow-Events が追加される。それの用途はセクション3.3.7で述べられて いる。 7.2.3. Subscription-State ヘッダー SIP メッセージの文法中のエレメントである request-header の定義に、 Subscription-State が追加される。それの用途はセクション3.2.4で述べ られている。 7.3. 新規応答コード 7.3.1. 202 Accepted 応答コード Success ヘッダーフィールドの定義に 202 応答が追加される。 「202 Accepted」は、HTTP/1.1(参考文献[3])で定義されているのと同じ意 味を持つ。 7.3.2. 489 Bad Event 応答コード Client-Error ヘッダーフィールドの定義に 489 イベント応答が追加される。 「489 Bad Event」は、Event ヘッダーフィールドで指定されたイベントパ ッケージを、サーバーが理解しないことを示すために使用される。 7.4. 拡張BNF定義 様々な新規および修正されたシンタックスエレメントのための拡張BNFの定 義は以下のようである。表記法は SIP(参考文献[1])で用いられているもの と同じであり、このセクションで定義されていないいかなるエレメントも SIP およびそれが参照するドキュメントで定義されている通りである。 SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE は大文字 NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY は大文字 extension-method = SUBSCRIBEm / NOTIFYm / token Roach Standards Track [Page 35] RFC 3265 SIP-Specific Event Notification June 2002 Event = ( "Event" / "o" ) HCOLON event-type *( SEMI event-param ) event-type = event-package *( "." event-template ) event-package = token-nodot event-template = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) event-param = generic-param / ( "id" EQUAL token ) Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type *(COMMA event-type) Subscription-State = "Subscription-State" HCOLON substate-value *( SEMI subexp-params ) substate-value = "active" / "pending" / "terminated" / extension-substate extension-substate = token subexp-params = ("reason" EQUAL event-reason-value) / ("expires" EQUAL delta-seconds) / ("retry-after" EQUAL delta-seconds) / generic-param event-reason-value = "deactivated" / "probation" / "rejected" / "timeout" / "giveup" / "noresource" / event-reason-extension event-reason-extension = token 8. 規範的な参考文献 [1] 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. [2] Petrack, S. and L. Conroy, "The PINT Service Protocol", RFC 2848, June 2000. [3] 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. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Roach Standards Track [Page 36] RFC 3265 SIP-Specific Event Notification June 2002 [5] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000. 9. 有益な参考文献 [7] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP Extensions", Work in Progress. [8] Schulzrinne, H. and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities", Work in Progress. 10. 謝辞 SIP Events メーリングリストで意見や提案を与えてくれた人々、およびピ ッツバーグで開催された第48回 IETF ミーティングにおいて、Events BOF に参加してくれた人たちに感謝の意を表したい。特に、コロンビア大学の Henning Schulzrinne には、最終的な3段階のイベント識別スキームを提案 してくれたことに、Sean Olson には、様々なガイダンスをしてくれたこと に、Jonathan Rosenberg には、ドラフト -00 の徹底的な洗い出しをして くれたことに、そして「SIP Extensions for Presence」の著者たちには、 SUBSCRIBE と NOTIFY リクエストのセマンティクスについての考えを与え てくれたことに感謝したい。 11. 知的所有権に関する告知 このドキュメントに含まれる一部またはすべての仕様に関して、知的所有 権が主張されていることを IETF は通知されている。詳細については、 http://www.ietf.org/ipr.html で、主張されている権利についてのオンラ インリストを調べること。 12. 著者の連絡先 Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA EMail: adam@dynamicsoft.com Voice: sip:adam@dynamicsoft.com Roach Standards Track [Page 37] RFC 3265 SIP-Specific Event Notification June 2002 13. 完全な著作権表示 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2004年 --------------------------------------------------------------------------- Roach Standards Track [Page 38]