Network Working Group A. B. Roach Request for Comments: 4662 B. Campbell Category: Standards Track Estacado Systems J. Rosenberg Cisco Systems August 2006 リソースリストのためのセッション開始プロトコル(SIP)イベント通知拡張 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 本文書は、同種のリソースのリストにサブスクライブするための、セッショ ン開始プロトコル(Session Initiation Protocol / SIP)特有のイベント通 知の仕組みを提示する。サブスクライバ(subscriber)は、SUBSCRIBEを個々 のリソースに送信する代わりに、全体のリストにサブスクライブしてから、 リストのリソースステートが変更されたときに通知を受け取ることができ る。 Roach, et al. Standards Track [Page 1] RFC 4662 SIP Event Lists August 2006 目次 1. はじめに ...................................................... 3 2. 用語 .......................................................... 4 3. 操作の概要 .................................................... 4 4. リストのサブスクリプション操作 ................................ 5 4.1. リソースリストへの対応のネゴシエーション .................. 6 4.2. サブスクリプションの有効期間 .............................. 7 4.3. NOTIFYのボディ ............................................ 7 4.4. SUBSCRIBEリクエストのRLS処理 .............................. 7 4.5. NOTIFYリクエストのRLS生成 ................................ 7 4.6. NOTIFYリクエストのサブスクライバ処理 ...................... 9 4.7. 分岐したリクエストの処理 ................................. 10 4.8. 通知の頻度 ............................................... 10 5. 全体のステートを伝達するためのmultipart/related使用 ........... 10 5.1. XML構文 ................................................. 11 5.2. list属性 ................................................. 13 5.3. resource属性 ............................................. 14 5.4. name属性 ................................................. 14 5.5. instance属性 ............................................. 14 5.6. 一貫したリソースステートの構築 ........................... 16 5.6.1. 完全なステート通知の処理 ............................... 17 5.6.2. 部分的なステート通知の処理 ............................. 17 6. 例 ........................................................... 18 7. セキュリティの考慮事項 ....................................... 31 7.1. 認証 ..................................................... 31 7.1.1. 同じドメイン内のRLSとサブスクライバ ............... 31 7.1.2. 異なるドメインのRLSとサブスクライバ ............... 32 7.2. 不正な統合の危険性 ....................................... 33 7.3. シグナリングと隠蔽 ....................................... 33 7.4. 無限ループ ............................................... 34 8. IANA条項 ..................................................... 34 8.1. 新規SIPオプションタグ: eventlist ......................... 34 8.2. リソースリストメタ情報の新規MIMEタイプ ................... 34 8.3. URN下位名前空間 ......................................... 35 9. 謝辞 ......................................................... 36 10. 参考文献 ..................................................... 36 10.1. 規範となる参考文献 ..................................... 36 10.2. 有益な参考文献 ......................................... 37 Roach, et al. Standards Track [Page 2] RFC 4662 SIP Event Lists August 2006 1. はじめに SIP特有のイベント通知の仕組み[2]を使用して、ユーザー(サブスクライ バ)は、特定リソースのステート変更について、通知を受けるように要求す ることができる。これは、リソースに対するSUBSCRIBEリクエストをサブス クライバに生成させることによって実現される。また、このリクエストは リソースを示すノーティファイア(notifier)によって処理される。 多くの場合、サブスクライバは関連するリソースのリストを保持している。 統合する仕組みがない場合、サブスクライバは、情報を取得したい個々のリ ソースに対してSUBSCRIBEリクエストを生成する必要がある。帯域幅が限ら れている無線ネットワークなどの環境では、個々のリソースに対するサブス クライブは問題である。このような場合特有の問題を以下に挙げる。 o 実行によって、各リソースに対する最初のSUBSCRIBEリクエストと、個々 のサブスクリプションの更新という形で、メッセージトラフィックが増 大する。 o ノーティファイアは、サブスクリプションのステートが長い間存続する ことを防ぐために、更新間隔を短くするように要求する可能性がある。 これは、サブスクライバの要望よりも短い間隔でSUBSCRIBEの更新を生成 しなければならない可能性がある、ということを意味する。 o ノーティファイアは、サブスクライバの要望よりも高い頻度でNOTIFYを 生成する可能性がある。そのため、NOTIFYのトラフィック量はサブスク ライバの要望よりも多くなる。 こうした問題を解決するために、本仕様では、リソースのリストに関する通 知を要求および伝達することを可能にするRFC 3265[2]に対する拡張を定義 する。リソースリストはURIによって特定され、0個以上のURIのリストを表 す。この各URIは、サブスクライバが情報を受け取りたいと望む個々のリ ソースの識別子である。多くの場合、リソースリストの識別に使用される URIはSIP URI[1]だが、他のスキーマ(pres:[10]など)も予測される。 リストのノーティファイアは、「リソースリストサーバー(resource list server / RLS)」と呼ばれる。リスト全体のステートを決定するために、RLS はリスト内の各リソースにサブスクリプションを生成したように動作する。 リソースリストは、サブスクライバのドメイン内に限定されない。同様に、 リスト内のリソースは、リソースリストサーバーのドメイン内に限定され ない。 Roach, et al. Standards Track [Page 3] RFC 4662 SIP Event Lists August 2006 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[5]に記載に従って解釈 されるべきである。 以下の用語が本文書で使用される。 バックエンドサブスクリプション(Back-End Subscription): RLSがリソース のステートを知るために生成する任意のサブスクリプション(SIPなど)。 RLSはバックエンドサブスクリプションを生成して、RLSが権限を持たな いリソースのステートを知る。バックエンドサブスクリプションの場合、 RLSはサブスクライバとして動作する。 リストサブスクリプション(List Subscription): リソースリストに対する サブスクリプション。リストサブスクリプションでは、RLSはノーティ ファイアとして動作する。 リソース(Resource): リソースは、サブスクライブされる可能性のある1 ステートまたは複数ステートを持つ論理エンティティである。リソース はURIによって特定される。 リソースリスト(Resource List): 1つのサブスクリプションで、サブスクラ イブされる個別のステートを持つ可能性がある0個以上のリソースのリ スト。 RLMI: リソースリストメタ情報(Resource List Meta-Information)。RLMI は、リストサブスクリプションに関連付けられる仮想サブスクリプショ ンのステートを記述するドキュメント。 RLS: リソースリストサーバー(RLS)RLSは、リソースリストに対するサブス クリプションを受け入れ、通知を送信することによって、リソースリス トに含まれるリソースのステートのサブスクライバを更新する。 仮想サブスクリプション(Virtual Subscription): 仮想サブスクリプション は、リソースリストのリソースに対するサブスクリプションを示すRLS内 の論理的な構成概念である。提供する個々のリストサブスクリプション では、RLSは、サブスクライブされているリソースリストの各リソースご とに、最低でも1つの仮想サブスクリプションを作成する。RLSがリソー スのステートに権限を持たない場合など、場合によっては、この仮想サ ブスクリプションはバックエンドサブスクリプションに関連付けられる。 RLSがリソースのステートに権限を持つ場合などは、仮想サブスクリプ ションはバックエンドサブスクリプションに関連付けられない。 3. 操作の概要 このセクションでは、本拡張の代表的な操作方法の概要を説明する。これは 規範ではない。 Roach, et al. Standards Track [Page 4] RFC 4662 SIP Event Lists August 2006 ユーザーがリソースリストのリソースにサブスクライブしたい場合、本仕様 に記載されている仕組みを利用できる。最初の手順は、リソースリストの作 成である。このリソースリストは、SIP URIで表される。リストには複数の URIが登録されており、それぞれ、サブスクライバが情報を受け取ることを 望んでいるリソースを表している。リソースリストは、任意のドメインに置 くことができる。リストは、Webページ、音声応答システムなど、他のプロ トコル経由で操作される可能性がある。リストを作成、保守するための手 段は、本仕様の範囲外である。 リストにある複数要素のリソースステートを知るために、ユーザーは、リス トのURIに対して、1個のSUBSCRIBEリクエストを送信する。これは、そのURL のRLSにルートされる。RLSはノーティファイアとして動作し、サブスクライ バを認証して、サブスクリプションを受け入れる。 RLSは、リストで指定されたリソースの一部またはすべてに関して、直接情 報を保持している可能性がある。保持していない場合、リストリソースに よって指定されている非ローカルのリソースにサブスクライブできる。 非ローカルのリソースに対するサブスクリプションは、SIPのサブスクリプ ションであっても、そうでなくてもよい、ということに注意。この情報を決 定するには、任意の仕組みを採用できる。本文書では、SIPがサブスクリプ ションの確立およびサービスに使用されたかどうかは関係く、こうしたサブ スクリプションを指すときに「バックエンドサブスクリプション」という用 語を使用している。 リストに含まれるリソースのステートが変更されると、RLSはリストのサブ スクライバに対して通知を生成する。RLSは、任意にリソース変更の通知を バッファすることができ、また個々にではなくバッチ処理で、サブスクライ バにリソース情報を送信することができる。これによって、RLSはサブスク ライバに対して頻度制限を提供できるようになる。 リスト通知にはmultipart/related型のボディが含まれる。 multipart/relatedコンテンツのルートセクションは、リストに存在する各 リソースに関するメタ情報が提示されるXMLドキュメントである。以降のセ クションでは、各リソースに関する実際のステート情報を説明する。 4. リストのサブスクリプション操作 イベントリスト拡張の動作は、多くの点でイベントテンプレートパッケージ と似ている。特に、個々のリストサブスクリプションは、いずれも基礎とな るイベントパッケージと同種でなければならない。言い替えると、1個のリ ストサブスクリプションは、リソースリストに含まれるすべてのリソースに 対して1個のイベントパッケージのみを適用できる。 Roach, et al. Standards Track [Page 5] RFC 4662 SIP Event Lists August 2006 RLSで、異なるイベントパッケージを使用するために、同じリストに対して 複数のサブスクリプションを許容することが完全に有効であることに注意。 リストサブスクリプションとテンプレートの主な違いは、一般的に、リスト サブスクリプションを任意にネストすることへの対応を、リストサブスクリ プションで示すことができる点である。言い替えると、リスト内の要素は、 不可分な(atomic)要素である可能性もあり、またはその要素自体がリストで ある可能性もある。 したがって、リストであるURIに対するサブスクリプションは、実際のとこ ろ、リソースのツリーに対する数個の仮想サブスクリプションという結果に なる。このツリーの葉ノード(leaf nodes)は、「Event」ヘッダーフィール ドで指定されたイベント型の仮想サブスクリプションである。ツリーに含ま れる他のノードは、このセクションとサブセクションで説明されるように機 能するリストサブスクリプションである。 仮想サブスクリプションは、(RLSの実装によって、結果的にSIPサブスクリ プションになったとしても)文字通りのSIPサブスクリプションではないとい う点に注意する必要がある。 4.1. リソースリストへの対応のネゴシエーション 本文書で定義される拡張への対応についてネゴシエートするために、本仕様 ではSIPオプションタグの仕組みを使用する。「Supported」および 「Require」ヘッダーフィールドと、421 (Extension Required)応答コード の処理に関する規範については、RFC 3261[1]を参照のこと。 以下に、オプションタグの実装について、規範的ではない説明を記載 する。 イベントリスト拡張に対応するすべてのクライアントは、リストを処理 する意思があるサブスクリプションについて、全SUBSCRIBEメッセージ の「Supported」ヘッダーフィールドに、「eventlist」のオプションタ グを含める。サブスクリプションが、リストであるURIに対して作成され る場合、RLSは、SUBSCRIBEに対する応答の「Require」ヘッダーフィール ドと、またそのサブスクリプション内のすべてのNOTIFYメッセージに、 「eventlist」を含める。 NOTIFYメッセージでの「Require: eventlist」の使用は、ノーティファ イアによって適用される。これは、リクエスト処理のために、UACがUAS に対して拡張の理解を要求したい場合、UACはリクエストにRequireヘッ ダーフィールドを挿入しなければならない[MUST]、というRFC 3261の要 件を満たすためである。eventlistオプションを適用せずにNOTIFYを使用 することはできないため、ノーティファイアはeventlistを含める義務が ある。 相互運用性を損なう場合を除き、SUBSCRIBEリクエストの「Require」ヘッ ダーフィールドに「eventlist」を含めることには何も意味がないため、推 奨されない[NOT RECOMMENDED]。 Roach, et al. Standards Track [Page 6] RFC 4662 SIP Event Lists August 2006 NOTIFYメッセージで「Supported: eventlist」を送信することは意味がな く、愚かなことである。実装では、SUBSCRIBE以外のリクエストに 「Supported: eventlist」を含めるべきではない[SHOULD NOT]。 SIP URIが、1個のリソースリストを示すか、1個のリソースを示すか、とい うことを表すものは、SIP URIにない。したがって、サブスクライバが、 「eventlist」トークンを列挙するSupportedヘッダーフィールドを含めず に、リストのリソースを表すURIに対してリクエストを送信する場合、ノー ティファイアは通常421(Extension Required)応答コードを返す。RFC 3261 [1]では、サーバーは421を返さず、代わりに拡張なしでリクエストを処理す るように助言されている。 ただし、この場合、URIは基本的にリストのリソースを表すため、この拡張 を使用しなければ、サブスクリプションは処理できない。 4.2. サブスクリプションの有効期間 リソースリストサーバーの主な利点は、サブスクライバに対する総メッセー ジ量を減らすことなので、リストに対するサブスクリプションの継続期間を 適度な長さにすることが推奨される[RECOMMENDED]。デフォルト(継続期間が 指定されない場合)は、基礎となるイベントパッケージから取得される。当 然ながら、この総量の増減には、標準的な技術[2]を使用できる。 4.3. NOTIFYのボディ 本仕様に準拠する実装では、 multipart/relatedおよび application/rlmi+xmlのMIMEタイプに対応しなければならない[MUST]。これ らのタイプは、クライアントが対応する他のタイプ(使用されているイベン トパッケージに必要な任意のタイプを含む)とともに、SUBSCRIBEメッセージ で送信されるAcceptヘッダーに含まれなければならない[MUST]。 4.4. SUBSCRIBEリクエストのRLS処理 サブスクライバが認証されると、RLSはローカルポリシーに従って認可を実行 する。多くの場合、各リソースリストは特定のユーザー(リソースリストを 作成し、リスト内の要素を管理する人物)に関連付けられ、そのユーザーの みがサブスクライブできる。当然ながら、この操作方式はリソースリストの 使用に独自のものではなく、RLSでは任意の認可ポリシーを使用できる。 4.5. NOTIFYリクエストのRLS生成 本仕様では、NOTIFYリクエストの生成方法および生成のタイミングは、実装 者の裁量にゆだねる。多様なRLS実装間の差異の1つは、通知が生成される際 の、統合、頻度制限、または最適化の手段である。基本の動作として、RLS Roach, et al. Standards Track [Page 7] RFC 4662 SIP Event Lists August 2006 は、リストの任意リソースのステートが変更された場合はいつでも、RLSサ ブスクライバに対してNOTIFYを生成してもよい[MAY]。 あるサブスクリプションが、単一のリソースに対するものか複数リソースの リストに対するものかを理解することは重要である。 この性質(単一のリソースと複数リソースのリスト)は、単一のサブスクリプ ションの有効期間中に変更できない。つまり、これは、RLMIを含むRLSサブ スクリプションでNOTIFYメッセージを以前に送信したことがある場合、その RLSサブスクリプションのRLMIを含まないNOTIFYメッセージをRLSは送信して はならない[MUST NOT]ことを特に指す。同様に、RLSは、サブスクリプショ ンのRLMIを含むNOTIFYメッセージを送信したことがある場合、含まないサブ スクリプションを送信してはならない[MUST NOT]。 リスト表記には、2つの理由からRLMI文書を含める必要がある。重要な点 は、イベントステートと対応するリソースをRLMI文書が識別することで ある。多くのステート構文は、ステートを適用するリソースを完全に識 別することはない。また、リストに表記されているのとは異なる方法で リソースを識別する可能性がある。たとえば、PIDFドキュメントには、 取得に使用されるURIと同一ではないリソースURIが含まれる場合があ る。さらに、RLMIドキュメントは、単一リソースの複数インスタンスの あいまいさを解消するために機能している。 リソースリストのステートを伝達するために使用される構文の詳細な定義に ついては、セクション5を参照のこと。以下の議論では、全体のリストには0 個以上のリソースが含まれ、リソースには0個以上のインスタンスが含まれ ていることを理解しておくことが重要である。各インスタンスには、関連付 けられているステート(pending、active、terminating)があり、仮想サブス クリプションのステートを表す。 通知には、マルチパートドキュメントが含まれ、最初のパートにはリストに 関するメタ情報(たとえば、構成メンバー、リソースに対する仮想サブスク リプションのステート)が常に含まれる。残りのパートは、メタ情報で列挙 されているリソースの実際のステートを伝達するために使用される。 メタ情報にあるリソースの各インスタンスの「state」属性は、仮想サブス クリプションのステートに従って設定される。「state」属性の意味は、 RFC 3265 [2]に記載されている。 サブスクライバに対して以前に伝えられたリソースのインスタンスが、使用 不可能になっている場合(つまり、そのインスタンスに対する仮想サブスク リプションが終了していた場合)、リソースリストサーバーは、インスタン スが使用できなくなってからサブスクライバに対して送信される最初の NOTIFYメッセージで、そのリソースのインスタンスをメタ情報に含めるべき Roach, et al. Standards Track [Page 8] RFC 4662 SIP Event Lists August 2006 である[SHOULD]。RLSは、後続の通知でもその実行を続けてもよい[MAY]。 終了したリソースのインスタンスに関する情報を送信する場合、RLSは 「teminated」のステートと適切な理由値を示す。 有効な理由値とその意味は、RFC 3265[2]に記載されている。 後にRLSがリソースステートを改めて復元しようと試みる場合(たとえば、 メタ情報にある理由が「probation(試用期間)」である場合)、インスタンス のステートが利用可能になるか、ステートが利用可能になるのをRLSがあきら めるまで、リソースのインスタンスをメタ情報に残すべきである[SHOULD]。 特定のサブスクリプションに対する最初のSUBSCRIBEメッセージをRLSが受け 取る際に、RLSは、リソースリストで指定されているすべてリソースについ て、ステート情報を知らないことが多い。ステート情報が知られていないリ ソースの場合、対応する「uri」属性は適切に設定されるが、要素 はリソースに対して提示されない。 最初の通知の場合、RLSがステートを保持しているリソースに対応するセク ションは、(もちろんローカルポリシーの判断に従って)適切なデータに組み 込まれる。これは、リソースリストサーバーが、リストで指定されている1 個以上のリソースのサーバーと同居している場合に発生する。 後続のSUBSCRIBEメッセージの結果、直後にトリガされる通知には、完全な ステートが指定されたRLMIドキュメントを含めるべきである[SHOULD]。ま た、RLSは、ポリシーの制限に従って、RLSがステートを保持しているリスト に、すべてのリソースに関するステート情報も含めるべきである[SHOULD]。 これによって、サブスクライバはステートを更新でき、失われた通知からの 復元が可能になる。 4.6. NOTIFYリクエストのサブスクライバ処理 リソースリストに対する通知では、リスト要素のサブセットに関する情報を 伝達できる。これは、一貫性があり矛盾のないステートを構築するには、明 確なアルゴリズムを定義する必要があるということを意味する。 multipart/relatedドキュメントのルートにあるXMLドキュメントには、リス ト内のリソースすべてまたは一部の要素が含まれる。各 要素には、そのセクションが対応するリソースを一意に特定す るURIが含まれる。NOTIFYが届くと、完全なステートまたは部分的ステート (トップレベルの要素の「fullState」属性で示される)が含まれてい る可能性がある。完全なステートが指定される場合、受信側は、リストに関 連付けられるすべてのステートを、NOTIFYボディのエンティティで置換す る。完全なステートが指定されない場合、NOTIFYの受信側は指定された各 Roach, et al. Standards Track [Page 9] RFC 4662 SIP Event Lists August 2006 リソースの情報を更新する。NOTIFYで特定されないリソースの情報は、以前 のNOTIFYメッセージで指定されなかった場合でも、変更されない。詳しく は、セクション5.6を参照のこと。 完全なステートが指定される場合は、その指定されたRLMIドキュメントに のみ適用されるということに注意すること。特に、ドキュメントの 要素の1つが、順に別のリソースリストを参照する可能性が ある。このようなサブリストは、RLMIドキュメント(完全なステートが示 されている場合とそうではない場合がある)に列挙される。 さらに、基礎となるイベントパッケージで、部分的ステート通知を合成 するための独自の規則がある可能性がある、ということに注意すること。 このようなパッケージに関連するデータを処理する場合、そのパッケー ジの規則が適用される(つまり、リストの一部であると伝えられた事実に よって、部分的通知のセマンティクスが変更されることはない)。 最後に、リソースリストのサブスクリプションが機能した結果として、 リソースステートのポーリングは特に有効ではない可能性がある、とい うことに注意すること。このようなポーリングでリソースリストは取り 出されるが、リストの一部のリソースまたはすべてのリソースについて、 ステートが含まれているとは限らない。 4.7. 分岐したリクエストの処理 イベントリストに対するサブスクリプションの本来の趣旨は、通知のソース を一元化するというものなので、分岐はほとんど意味がない。 したがって、リストに対するサブスクライバは、最初のリクエストが分岐す るときに、複数のサブスクリプションを組み込んではならない[MUST NOT]。 複数の応答を受け取る場合、RFC 3265[2]のセクション4.4.9に記載されてい る手法を使用して処理する。 4.8. 通知の頻度 RLSの潜在的な役割の1つに、サブスクライバに代わって頻度制限を実行する ことがある。本仕様では、特定の頻度制限を必須とせず、実装の判断にゆだ ねる。 5. 全体のステートを伝達するためのmultipart/related使用 複数リソースのステートを伝達するために、リスト拡張では 「multipart/related」のMIMEタイプを使用する。multipart/relatedの構 文は、「The MIME Multipart/Related Content- type」[4]で定義されて いる。 Roach, et al. Standards Track [Page 10] RFC 4662 SIP Event Lists August 2006 5.1. XML構文 multipart/relatedボディのルートドキュメントは、リソースリストメタ情 報(Resource List Meta-Information / RLMI)ドキュメントでなければなら ない[MUST]。これは、「application/pidf+xml」タイプである。このドキュ メントには、通知に含まれているリソースに関するメタ情報が含まれる。こ のXMLドキュメントのスキーマは、以下の通り。 An example of a document formatted using this schema follows. Buddy List Liste d'amis Bob Smith Dave Jones Roach, et al. Standards Track [Page 12] RFC 4662 SIP Event Lists August 2006 Jim Ed 5.2. list属性 リスト通知に提示される要素には、3つの属性を含めなければならな い[MUST]。 の第1の必須属性は「uri」であり、リストに対応するURIが含まれ る。通常、これはSUBSCRIBEリクエストが送信された先のURIである。 の第2の必須属性は「version」であり、0から2^32-1の数値が含ま れる。サブスクリプション内で送信される最初のNOTIFYメッセージの場合、 このバージョン番号は、0にしなければならず[MUST]、サブスクリプション 内で送信される後続の各NOTIFYごとに1ずつ増やさなければならない[MUST]。 第3の必須属性は「fullState」である。「fullState」属性は、NOTIFYメッ セージに、リストの全リソースの情報が含まれているかどうかを示す。含ま れている場合、属性の値は「true」(または「1」)、含まれない場合は 「false」(または「0」)である。サブスクリプションで送信される最初の NOTIFYには、完全なステートが含まれなければならない[MUST]。これは、サ ブスクリプションに対するSUBSCRIBEリクエストの受信後に送信される最初 のNOTIFYの通りである。 最後に、要素には、「cid」属性を含めてもよい[MAY]。提示される 場合、「cid」属性は、リスト内のリソースの統合ステート情報が含まれる multipart/relatedボディ内のセクションを特定する。このような統合情報 の定義は、本文書の範囲外であり、必要に応じてパッケージごとに定義され るものである。cid属性は、マルチパートボディで対応するセクションの Content-IDである。 cid属性は、提示されるRLMIドキュメントがルートであるmultipart/related ドキュメントの、トップレベルのパートのみを参照しなければならない [MUST]。例はセクション5.5を参照のこと。 Roach, et al. Standards Track [Page 13] RFC 4662 SIP Event Lists August 2006 5.3. resource属性 リソースリストには、通知で伝えられている各リソースごとに1個の 要素が含まれる。これらのresource要素には、各リソースに関連 付けられるメタデータを特定する属性が含まれる。 「uri」属性は、要素が対応するリソースを特定する。これは、 通常、(サブスクライブされる場合)リソースのステートを返すSIP URIとな る。この属性は提示しなければならない[MUST]。 5.4. name属性 各リストとリソース要素には0個以上のinstance要素が含まれる。 これらのname要素には、リソースリストまたはリソースの人間が読み取り可 能な説明または名前が含まれる。これらの要素のコンテンツは、SIPの name-addr要素で提示される「Display Name」とやや似ている。 name要素にはオプションで標準XMLの「xml:lang」属性が含まれる。 「xml:lang」属性を提示する場合、人間が読み取り可能な名前の言語を指定 する。この属性が提示される場合、有効な言語タグを含めなければならな い[MUST]。言語タグはRFC 3066 [6]で定義されている。ユーザーに表示する 複数のname要素を決定する上で、言語タグはアプリケーションを補助する。 5.5. instance属性 各リソースには0個以上のinstance要素が含まれる。これらのinstance要素 は、リソースに対する1個のノーティファイアを表すために使用される。分 岐を許容するイベントパッケージの場合、特定リソースに対して複数の仮想 サブスクリプションが存在する可能性がある。複数の仮想サブスクリプショ ンは、対応するresource要素で複数のinstance要素として表される。分岐が 発生していないサブスクリプションの場合、特定リソースに対して最大でも 1個のインスタンスが存在する。 「id」属性には、リソースのインスタンスを一意に特定するために使用さ れる、不透明な文字列(opaque string)が含まれる。「id」属性は、リソー スのコンテキスト内でのみ一意である。この文字列の構造は、実装の判断に ゆだねられる。リソース内の一意性が確保されていれば、この文字列を生成 する仕組みは有効である。 「state」属性には、特定されたリソースのインスタンスに関するサブスク リプションのステートが含まれる。この属性には、「active」、 「pending」、「terminated」という値のいずれかが含まれる。これらの値 Roach, et al. Standards Track [Page 14] RFC 4662 SIP Event Lists August 2006 の意味は、RFC 3265[2]で「Subscription-State」ヘッダーフィールドにつ いて定義されている。 「state」属性が「teminated」と指定される場合、「reason」属性も提示さ れなければならない[MUST]。この「reason」属性の値と意味は、RFC 3265 [2]で指定されている「Subscription-State」ヘッダーフィールドでの 「reason」パラメータと同じである。「reason」属性は、情報通知の目的で 含まれており、リストサブスクライバに対して、reasonの値に基づいて何ら かの動作を自動実行することを期待するものではない、ということに注意。 最後に、「cid」属性(「state」属性が「active」の場合に提示はなければな らない[MUST])は、実際のリソースステートが含まれるmultipart/relatedボ ディ内のセクションを特定する。このステートは、ステートを伝達するイベ ントパッケージによって定義されるコンテンツタイプで表現される。cid属 性は、マルチパートボディで対応するセクションのContent-ID である。 cid属性は、提示されるRLMIドキュメントがルートであるmultipart/related ドキュメントの、トップレベルのパートのみを参照しなければならない [MUST]。 Roach, et al. Standards Track [Page 15] RFC 4662 SIP Event Lists August 2006 たとえば、A、B、Cという3つのパートを持つmultipart/relatedドキュメ ントがあるとする。パートAのタイプはapplication/rlmi+xml、パートBの タイプはmultipart/related、パートCのタイプはapplication/pidf+xmlで ある。同様に、パートBは、D、E、Fという3つのパートを持つドキュメン トである。パートDのタイプはapplication/rlmi+xml、パートEとFのタイ プはapplication/pidf+xmlである。 +-------------------------------------------+ | Top Level Document: multipart/related | | | | +---------------------------------------+ | | | Part A: application/rlmi+xml | | | +---------------------------------------+ | | | Part B: multipart/related | | | | | | | | +-----------------------------------+ | | | | | Part D: application/rlmi+xml | | | | | +-----------------------------------+ | | | | | Part E: application/pidf+xml | | | | | +-----------------------------------+ | | | | | Part F: application/pidf+xml | | | | | +-----------------------------------+ | | | | | | | +---------------------------------------+ | | | Part C: application/pidf+xml | | | +---------------------------------------+ | | | +-------------------------------------------+ ドキュメントAの「cid」属性は、パートBまたはCのみを参照しなければな らない。パートD、E、Fへの参照は不正である。同様に、ドキュメントDの 「cid」属性は、パートEまたはFのみを参照しなければならない。他の パートの参照は不正である。 また、バックエンドサブスクリプションのサブスクリプション継続期間 は、いかなる方法でも、メタ情報に伝搬されない。 5.6. 一貫したリソースステートの構築 リソースリストのサブスクライバは、各リソースリストごとに1つの表を保持 する。その表には、リソースリストの各リソースリストごとに1行が登録され ている。各行はそのリソースのURIによってインデックスされる。そのURI は、各要素上の「uri」属性から取得される。各行の内容には、 リソースドキュメントで伝達された、そのリソースのステートが含まれる。 Roach, et al. Standards Track [Page 16] RFC 4662 SIP Event Lists August 2006 バージョン情報([2]では、部分的情報を許容するすべてのフォーマットで必 須とされている)を提供するリソースの場合、各行にはリソースステートの バージョン番号も含まれている。行のバージョン番号は、対応するイベント パッケージによって定義されるように、最初に受け取ったドキュメントで指 定されたバージョンに初期化される。この値は、リソースの部分的通知の バージョンと比較するときに使用される。 リソースリスト通知の処理は、含まれているのが完全なステートか部分的な ステートかによって異なる。 5.6.1. 完全なステート通知の処理 通知に完全なステートが含まれている場合(属性の「fullState」が 「true」に設定されていることが示される)、通知は表を更新するために使 用される。最初に行われるチェックで、受け取ったメッセージにある 属性の「version」属性がローカルのバージョン番号より大きいかどうか確 認される。大きくない場合、受け取ったドキュメントは破棄され、その後の 処理は実行されない。大きい場合、リソースリスト表のコンテンツは消去 され、ドキュメントのコンテンツから改めて組み込まれる。表の新規の行 は、各「resource」要素ごとに作成される。 5.6.2. 部分的なステート通知の処理 通知に部分的ステートが含まれている場合(属性の「fullState」が 「false」に設定されていることで示される)、通知は表を更新するために使 用される。ローカルのバージョン番号の値(要素の「version」属性) は、新規ドキュメントのバージョン番号と比較される。 o 新規ドキュメントの値がローカルのバージョン番号より1だけ大きい場 合、ローカルのバージョン番号は1増加され、ドキュメントは後述のよう に処理される。 o 新規ドキュメントの値がローカルのバージョン番号より2以上大きい場 合、ローカルのバージョン番号は新規ドキュメントの値に設定され、ド キュメントは後述のように処理される。リストサブスクライバは、更新 リクエストも送信して、完全なステート通知をトリガすべきであ る[SHOULD]。 o ドキュメントのバージョンがローカルのバージョン番号以下の場合、そ のドキュメントは破棄され、以降の処理は行われない。 サブスクライバは、ドキュメントに列挙されている各リソースごとに、その リソースの行が存在するかどうかを確認する。このチェックは、Request-URI 値と、行に関連付けられているURIとを比較することで行われる。そのリソー Roach, et al. Standards Track [Page 17] RFC 4662 SIP Event Lists August 2006 スが表に存在しない場合、行が追加され、ステートは「resource」要素の情 報に設定される。リソースが存在する場合、イベントパッケージの定義の通 りに、ステートは「resource」要素の情報に更新される。ステートが 「terminated」になるように行が更新または作成される場合、そのエントリ は任意のタイミングで表から削除してよい[MAY]。 6. 例 このセクションでは、コールフロー例を示す。これは規範ではない。この コールフローと、本文書または別の文書に記載されている規範的な動作とで 矛盾がある場合は、規範の方に従うべきである。 この例では、ネストされたプレゼンスリストに対してサブスクリプションを 必要とする。サブスクライバのAddresses-of-Recordは 「sip:adam@vancouver.example.com」、サブスクライブする先の、ネストさ れたリストリソースの名前は 「sip:adam-buddies@pres.vancouver.example.com」とする。基礎となるイ ベントパッケージは、[8]に記載されている「presence」である。 この例では、RLSでは、リスト上のリソースの一部を提供するための情報を 持っているが、他の情報を取得するには他のサーバーに問い合せる必要があ る。この例のRLS実装では、こうした情報を取得するためにSUBSCRIBE/NOTIFY の仕組みを使用している。 Roach, et al. Standards Track [Page 18] RFC 4662 SIP Event Lists August 2006 Terminal pres.vancouver.example.com pres.stockholm.example.org | | pres.dallas.example.net | 1 |---SUBSCRIBE--->| | | 2 |<-----200-------| | | 3 |<----NOTIFY-----| | | 4 |------200------>| | | 5 | |---SUBSCRIBE--->| | 6 | |<-----200-------| | 7 | |<----NOTIFY-----| | 8 | |------200------>| | 9 | |------------SUBSCRIBE----------->| 10| |<--------------200---------------| 11| |<-------------NOTIFY-------------| 12| |---------------200-------------->| 13|<----NOTIFY-----| | | 14|------200------>| | | 1. ここでは、ローカルのRLSに対してSUBSCRIBEを送信することでサブスク リプションを初期化している。(当然ながら、ここで接続するRLSは自ド メイン内に存在する必要はない。)イベントリスト拡張に対応している ため、application/rlmi+xmlとmultipart/relatedに対応していること を公表しなければならない、ということに注意。また、サブスクリプ ションの提示を必要としているため、application/pidf+xmlへの対応 も公表しなければならない、ということにも注意すること。 Terminal -> Local RLS SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP terminal.vancouver.example.com; branch=z9hG4bKwYb6QREiCL Max-Forwards: 70 To: From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 322723822 SUBSCRIBE Contact: Event: presence Expires: 7200 Supported: eventlist Accept: application/pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: application/pkcs7-mime Content-Length: 0 Roach, et al. Standards Track [Page 19] RFC 4662 SIP Event Lists August 2006 2. Local RLSがSUBSCRIBEのトランザクションを終了する。通常、認証と 認可はコールフローのこの時点で実行される、ということに注意する こと。この手順については、簡潔にするため、省略する。 Local RLS -> Terminal SIP/2.0 200 OK Via: SIP/2.0/TCP terminal.vancouver.example.com; branch=z9hG4bKwYb6QREiCL To: ;tag=zpNctbZq From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 322723822 SUBSCRIBE Contact: Expires: 7200 Require: eventlist Content-Length: 0 3. RFC 3265[2]で要求されているように、サブスクリプションを受け取っ た直後に、RLSはNOTIFYを送信する。また、この例では、ローカルの RLSは、「vancouver.example.com」ドメイン内のユーザーのプレゼン ス情報に対して権限も持っていると仮定している。NOTIFYには、既知 ユーザーのプレゼンス情報と同様に、全体のボディリストが記述され ているRLMIドキュメントが含まれている(最初の通知は完全なステート を必要とする)。RLSは、リストにある全体の情報のうち、一部の情報 をまだ取得していないため、要素には要素が含 まれていない、ということに注意。 Local RLS -> Terminal NOTIFY sip:terminal.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKMgRenTETmm Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935768 NOTIFY Contact: Event: presence Subscription-State: active;expires=7200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml"; start=""; boundary="50UBfW7LSCVLtggUPe5z" Content-Length: 1560 Roach, et al. Standards Track [Page 20] RFC 4662 SIP Event Lists August 2006 --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" Buddy List at COM Liste der Freunde an COM Bob Smith Dave Jones Ed at NET My Friends at ORG Meine Freunde an ORG --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" open sip:bob@vancouver.example.com --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Roach, et al. Standards Track [Page 21] RFC 4662 SIP Event Lists August 2006 Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" closed --50UBfW7LSCVLtggUPe5z-- 4. 端末がトランザクションを終了する。 Terminal -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKMgRenTETmm From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935768 NOTIFY Contact: Content-Length: 0 5. サブスクリプションを提供するため、ローカルのRLSはリソースのス テートにサブスクライブする。この手順で、RLSは、リソース 「sip:ed@dallas.example.net」のプレゼンスステートに対して、サブ スクライブを試みる。ローカルのRLSは、リストのサブスクリプション に対する通知を受け取る方法を理解しているため、リクエストに 「Supported: eventlist」ヘッダーフィールドを含める。このサブス クリプションと端末から送信されるサブスクリプションとの連結は、 アプリケーションに任されるが、このメッセージは、サブスクライバ (端末)が対応していることがわかる全ボディタイプについて「Accept」 ヘッダーフィールドを含める、という妥当な動作を明示している。 ローカルのRLSは、これらの書式をサブスクライバまで渡すのみであ り、実際に内容を理解する必要はないため、この例を実行することが 安全である。 Local RLS -> dallas.example.net内のPresence Server SUBSCRIBE sip:ed@dallas.example.net SIP/2.0 Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKMEyGjdG1LH Roach, et al. Standards Track [Page 22] RFC 4662 SIP Event Lists August 2006 Max-Forwards: 70 To: From: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 870936068 SUBSCRIBE Contact: Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K Identity-Info: https://vancouver.example.com/cert Event: presence Expires: 3600 Supported: eventlist Accept: application/pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: application/pkcs7-mime Content-Length: 0 6. dallas.example.netのPresence Serverが、SUBSCRIBEトランザクション を終了する。通常、認証はコールフローのこの時点で実行される、と いうことに注意すること。この手順については、簡潔にするため、省 略する。 dallas.example.net内のPresence Server -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKMEyGjdG1LH To: ;tag=e45TmHTh From: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 870936068 SUBSCRIBE Contact: Expires: 3600 Content-Length: 0 7. この例では、dallas.example.netのサーバーは、こちらのサブスクリ プションを拒否するか受け入れるかについて、判断するに足る認可情 報を持っていない。したがって、最初の通知には「pending」の 「Subscription-State」が含まれる。おそらく、リソースの権限を受 け入れるか拒否するかについて責任を持つパーティは、この変更を通 知されるが、この手順については、簡潔にするためにこのコールフ ローには含まれない。 Roach, et al. Standards Track [Page 23] RFC 4662 SIP Event Lists August 2006 dallas.example.net内のPresence Server -> Local RLS NOTIFY sip:pres.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP pres.dallas.example.net; branch=z9hG4bKfwpklPxmrW Max-Forwards: 70 From: ;tag=e45TmHTh To: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 1002640632 NOTIFY Contact: Subscription-State: pending;expires=3600 Event: presence Require: eventlist Content-Length: 0 8. ローカルのRLSがNOTIFYのトランザクションを終了する。この時点で、 Local RLSにはサブスクライバに伝える新規の情報がある、ということ に注意。その情報をすぐに伝えるか、スプールして後で配信するかに ついては、アプリケーションに一任される。この例では、送信したサブ スクリプションで有益なデータを提示する時間が十分取れるように、 RLSは実行前に少しの間待機する。 Local RLS -> dallas.example.net内のPresence Server SIP/2.0 200 OK Via: SIP/2.0/TCP pres.dallas.example.net; branch=z9hG4bKfwpklPxmrW From: ;tag=e45TmHTh To: ;tag=aM5icQu9 Call-ID: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 1002640632 NOTIFY Contact: Content-Length: 0 9. Local RLSは、他の非ローカルリソースのステートにサブスクライブ する。 Local RLS -> stockholm.example.org内のRLS SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0 Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKFSrAF8CZFL Max-Forwards: 70 To: From: ;tag=a12eztNf Roach, et al. Standards Track [Page 24] RFC 4662 SIP Event Lists August 2006 Call-ID: kBq5XhtZLN@pres.vancouver.example.com CSeq: 980774491 SUBSCRIBE Contact: Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K Identity-Info: https://vancouver.example.com/cert Event: presence Expires: 3600 Supported: eventlist Accept: application/pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: application/pkcs7-mime Content-Length: 0 10. stockholm.example.orgのRLSはSUBSCRIBEのトランザクションを完了す る。通常、認証はコールフローのこの時点で実行される、ということ に注意すること。この手順については、簡潔にするため、省略する。 stockholm.example.org内のRLS -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKFSrAF8CZFL To: ;tag=JenZ40P3 From: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.vancouver.example.com CSeq: 980774491 SUBSCRIBE Contact: Expires: 3600 Content-Length: 0 11. また、この例では、stockholm.example.orgのRLSは、 「stockholm.example.org」ドメイン内のユーザーのプレゼンス情報に 対しての権限も持っていると仮定している。NOTIFYには、内容のバディ リストが記述されているRLMIドキュメントと、それらユーザーのプレ ゼンス情報が含まれる。このケースでは、stockholm.example.orgの RLSは、NOTIFYメッセージのボディを署名[14]することを選択した。 RFC 3851に記載されているように、署名は、2つのパートを持つ multipart/signedドキュメントを作成することで実行される。1つ目の パートは署名されるドキュメント(この例では、リストリソースのス テートを記述しているmultipart/relatedドキュメント)であり、2つ目 のパートは実際の署名である。 Roach, et al. Standards Track [Page 25] RFC 4662 SIP Event Lists August 2006 stockholm.example.org内のRLS -> Local RLS NOTIFY sip:pres.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP pres.stockholm.example.org; branch=z9hG4bKmGL1nyZfQI Max-Forwards: 70 From: ;tag=JenZ40P3 To: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.vancouver.example.com CSeq: 294444656 NOTIFY Contact: Event: presence Subscription-State: active;expires=3600 Require: eventlist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" Content-Length: 2038 --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: multipart/related;type="application/rlmi+xml"; start=""; boundary="tuLLl3lDyPZX0GMr2YOo" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" Buddy List at COM Liste der Freunde an COM Joe Thomas Mark Edwards Roach, et al. Standards Track [Page 26] RFC 4662 SIP Event Lists August 2006 --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" open sip:joe@stockholm.example.org --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" closed --tuLLl3lDyPZX0GMr2YOo-- --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pkcs7-signature [PKCS #7 signature here] --l3WMZaaL8NpQWGnQ4mlU-- Roach, et al. Standards Track [Page 27] RFC 4662 SIP Event Lists August 2006 12. ローカルのRLSがNOTIFYトランザクションを完了する。 Local RLS -> stockholm.example.org内のRLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.stockholm.example.org; branch=z9hG4bKmGL1nyZfQI From: ;tag=JenZ40P3 To: ;tag=a12eztNf Call-ID: kBq5XhtZLN@pres.vancouver.example.com CSeq: 294444656 NOTIFY Contact: Content-Length: 0 13. この時点で、Local RLSは、新規の通知をユーザーに送信するに値する 十分な追加情報を収集した、と判断する。完全な通知を送信すること が許容できる場合でも、RLSは代わりに部分的通知を送信する方を選択 する。「fullState」パラメータが「false」に設定されているため、 RLMIドキュメントには、更新されたリソースの情報のみが含まれる。 stockholm.example.orgのRLSから受け取ったデートのS/MIME署名が破 損しないように、ローカルのRLSは、送信する通知に、全体の multipart/signedボディをそのままコピーする。 Local RLS -> Terminal NOTIFY sip:terminal.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bK4EPlfSFQK1 Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935769 NOTIFY Contact: Event: presence Subscription-State: active;expires=7200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml"; start="<2BEI83@pres.vancouver.example.com>"; boundary="TfZxoxgAvLqgj4wRWPDL" Content-Length: 2862 --TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: binary Content-ID: <2BEI83@pres.vancouver.example.com> Content-Type: application/rlmi+xml;charset="UTF-8" Roach, et al. Standards Track [Page 28] RFC 4662 SIP Event Lists August 2006 Buddy List at COM Liste der Freunde an COM Ed at NET My Friends at ORG Meine Freunde an ORG --TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: binary Content-ID: <1KQhyE@pres.vancouver.example.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU" --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: multipart/related;type="application/rlmi+xml"; start=""; boundary="tuLLl3lDyPZX0GMr2YOo" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/rlmi+xml;charset="UTF-8" Buddy List at ORG Liste der Freunde an ORG Joe Thomas Roach, et al. Standards Track [Page 29] RFC 4662 SIP Event Lists August 2006 Mark Edwards --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" open sip:joe@stockholm.example.org --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" closed --tuLLl3lDyPZX0GMr2YOo-- --l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pkcs7-signature [PKCS #7 signature here] --l3WMZaaL8NpQWGnQ4mlU-- --TfZxoxgAvLqgj4wRWPDL-- Roach, et al. Standards Track [Page 30] RFC 4662 SIP Event Lists August 2006 14. The terminal completes the NOTIFY transaction. Terminal -> Local RLS SIP/2.0 200 OK Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bK4EPlfSFQK1 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935769 NOTIFY Contact: Content-Length: 0 7. セキュリティの考慮事項 リストにあるリソースのステート情報を取得するための仕組みは、通常、RLS の実装にゆだねられる。以下に述べるセキュリティ問題の一部は、SIPのバッ クエンドサブスクリプションがこのような目的に使用される環境に特有のも のである。リストのリソースのステート情報取得に非SIPの仕組みを使用する ことによって、通常、その仕組み自体に関連するセキュリティ問題を持つこ とになる。ただし、本文書でそのような手法を完全に列挙することは不可能 である。このような仕組みを使用する実装では、選択したアクセス手法の関 連するセキュリティ問題について検討しなければならない。 7.1. 認証 バックエンドサブスクリプションが、リソースステート情報を取得するよう に要求されている場合、エンドユーザーは、リソースのステートに対して直 接のサブスクライバではなくなる。つまり、ユーザーの直接認証は不可能に なる。 7.1.1. 同じドメイン内のRLSとサブスクライバ ほとんどの一般的なRLSの展開には、RLSへのサブスクライバがRLSと同じド メインに所属する必要があると予想される。 この場合、RLSには認証サービスとして動作する機能がある。認証サービス の役割は、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)」[7]で定義されている。 高レベルでは、このシステムの下でRLSはサブスクライバを認証し、その認 証済みユーザーの代理で実行されるすべてのバックエンドサブスクリプショ ンに「Identity」ヘッダーフィールドを含める。この「Identity」ヘッダー フィールドは、「From」ヘッダーフィールドに指定されたユーザーの代理で リクエストが認可されたことを暗号化して主張する。 Roach, et al. Standards Track [Page 31] RFC 4662 SIP Event Lists August 2006 リクエストを認証する機能は、ネットワークが正しく機能するために中央に あるため、SIPのバックエンドSUBSCRIBEを使用してリソースリストのリソー スに関する情報を獲得するRLSは、ローカルの管理ポリシーで許容されてい る限り、[7]の定義に従って認証サービスとして動作しなければならない [MUST]。 言い換えると、バックエンドのSIPサブスクリプションに対応するすべて のRLS実装は、認証サービスとして動作するように設定された機能も含め なければならない。ある管理者がこのような機能をアクティブ化するか どうかは、管理者の判断に委ねられる。当然ながら、RLSにはアイデン ティティサーバーとして動作する機能がなく、実質的にはユーザーとは 異なるドメインに所属する場合と同様に動作するため、構成したRLSは以 降のセクションの説明に従って動作する。 7.1.2. 異なるドメインのRLSとサブスクライバ 一般的に、SIP Authenticated Identity拡張は、サブスクリプションがエン ドユーザーの代理で実行されていることをRLSが安全に主張できる手段を提 供するものではない。特に、サブスクライバとRLSが異なるドメインに所属 する場合、RLSにはユーザーのアイデンティティを保証できる手段がない。 このような場合のバックエンドサブスクリプションを認証できるメカニズ ムは、将来的な研究として残されている。 このような一般的な解決方法が開発されるまで、バックエンドサブスクリプ ションを代理で作成するサブスクライバとは異なるドメインに所属するRLS は、自身のアイデンティティを使用してリソースにサブスクライブすべきで ある[SHOULD]。こうすることで、RLSは、公に使用できるようになったリソー ス情報のみを一般的に取得する。 このような一般的な解決策がない場合、サブスクライバユーザーエージェン トの実装は、ドメイン外のRLSにサブスクライブする場合、(直接的なサブス クリプション、または他のリソースリストのサブスクリプションを利用して) リソースリストのリソースに対して直接のサブスクリプションを試行しても よい[MAY]。サブスクライブされるリソースは、RLSが返すRLMIドキュメント で提示される要素の「uri」属性で指定されるリソースになる。 リソースに直接サブスクライブすることで、ユーザー認証を正しく実行する ことができる。それによって、一般的に、より完全なステート情報を受信で きるようユーザーを認可できる。 このような直接的サブスクリプションを実行することを選択した実装の場 合、リストのサブスクリプション経由で取得したリソースに関する情報の代 わりに、取得したデータを使用すべきである[SHOULD]。 Roach, et al. Standards Track [Page 32] RFC 4662 SIP Event Lists August 2006 7.2. 不正な統合の危険性 通常、リソースリストサーバーは、同時に複数のサブスクライバに対して情 報を提供する。多くの場合、リソースはいくつかのリストに存在する。さら に、同じリストにサブスクライブする2ユーザーがリソースリストサーバー に存在することは十分にあり得る。 この場合、RLSの実装が判断を誤ると、リストのリソースに対して1つのバッ クエンドサブスクリプションのみを保持し、さらに2ユーザー以上にこのよ うなサブスクリプションの結果を提示することによって、ネットワーク負荷 を最小化しようと試みる可能性がある。当然ながら、そうすると、リソース のノーティファイアが保持している認可ポリシーを免れる。 認可は、1つのバイナリ「allowed/not allowed」の判断だけによるものでは ない、ということに気を付ける必要がある。リソースは、サブスクライブす るユーザーのアイデンティティによって、まったく異なる(矛盾することも あり得る)リソースステートを提示する可能性がある。 目的の受信者とは異なる相手にイベント情報が送信されることを回避するた めに、以下の場合を除き、複数のユーザーに対するバックエンドサブスクリ プションの結果を実装で提示してはならない[MUST NOT]。 a. バックエンドのサブスクリプションを実行したリソースと関連付けられ た、完全な認可ポリシーに対して、RLSが適切なアクセス権を持ってい る場合、かつ b. 複数のユーザーに対して情報を提示することがそのポリシーに違反して いないことをRLSが判断できる場合、および判断した場合。 これは、非常に解決が困難な問題である。このようなアクセスが可能と考え られる場合でも、この操作方法は推奨されない[NOT RECOMMENDED]。 7.3. シグナリングと隠蔽 実装では、MIMEボディのセクションが、必要に応じて署名されているか、暗 号化されている可能性がある、ということに注意すべきである。RLSは、バッ クエンドサブスクリプションから受け取るMIMEボディを修正しないように気 を付けるべきであり、また、通常、読み取り可能であることに依存すべきで はない。 セキュリティを円滑にするために、リソースリストサーバーは、サブスクラ イバが「multipart/signed」および「application/ pkcs7-mime」コンテン ツタイプを最初のSUBSCRIBEメッセージに含めている場合、そのコンテンツ タイプへの対応を、SIPバックエンドサブスクリプションに対して伝えるべ きである[SHOULD]。伝えないと、(ノーティファイアのポリシーで暗号化が 必要とされているが、対応していることをRLSが伝えられなかった場合)リ ソースがステートを公開することを拒否する結果になったり、(サブスクラ イバのポリシーで署名が必要とされているが、対応していることをRLSが伝 えられなかった場合)サブスクライバが有効なステートを破棄する結果に なったりする可能性がある。 Roach, et al. Standards Track [Page 33] RFC 4662 SIP Event Lists August 2006 RLSによる暗号化と署名の実装では、署名されたボディまたは暗号化された ボディを通過させることが可能である必要はない。 7.4. 無限ループ リソースリストをネスト可能にすることによる危険性の1つは、最終的に自身 をサブリストとして含むリストを作成する可能性である。RLSがすべての仮想 サブスクリプションを内部で提供している場合は、このようなケースを検知 し対応する重要性は低い。ただし、バックエンドサブスクリプションが仮想 サブスクリプションを提供するために作成される場合は、このような状況を 検知することは、より困難な問題となる。 バックエンドサブスクリプションを作成するRLSの実装では、このネストに よってサブスクリプションの永久ループが作成されないように保護手段を実 装しなければならない[MUST]。通常、このような仕組みは、バックエンドサ ブスクリプションのプロトコルで対応している必要がある。特に、フィルタ をバックエンドサブスクリプションに適用することは、このような問題を回 避するために有効な可能性がある。 8. IANA条項 8.1. 新規SIPオプションタグ: eventlist 本仕様は、RFC 3261[1]のセクション27.1で作成された登録に新規のオプ ションタグを定義する。 オプションタグ名: eventlist 説明: リソースのリストに対するサブスクリプションを許容する拡張 公開されている仕様: RFC 4662 8.2. リソースリストメタ情報の新規MIMEタイプ MIMEメディアタイプ名: application MIMEサブタイプ名: rlmi+xml 必須のパラメータ: なし オプションのパラメータ: charset XMLから派生したMIMEタイプに関するcharsetパラメータの解説につい ては、RFC 3023[12]を参照のこと。このMIMEタイプはSIPでのみ使用され るため、UTF-8エンコーディングの使用が強く推奨される。 エンコーディングの考慮事項: 8ビットテキスト Roach, et al. Standards Track [Page 34] RFC 4662 SIP Event Lists August 2006 セキュリティの考慮事項: このMIMEタイプの使用に固有のセキュリティの考 慮事項は、RFC 4662で論じられている。RFC 1874[11]とRFC 3023[12]で は、XMLの使用全体に共通したセキュリティ問題が論じられている。 相互運用性の考慮事項: このMIMEボディの用法は、一般的に相互運用可能で あるように意図されている。独自の考慮事項はない。 公開されている仕様: RFC 4662 このメディアタイプを使用するアプリケーション: このメディアタイプは、 セッション開始プロトコル(SIP)のサブスクリプション内で、リソースの リストのステートに関するメタ情報を伝達するために使用される。 補足情報: マジックナンバー: なし。 ファイルの拡張子: なし。 Macintoshファイルタイプコード: なし。 オブジェクト識別子(OID): なし 用途: 限定的な使用 その他の情報/全般的なコメント: なし より詳しい情報についての連絡先窓口: 名前: Adam Roach E-Mail: adam@estacado.net 著者/改版管理者: このMIMEタイプの仕様は、SIMPLEワーキンググループ の研究結果であり、Adam Roach、Jonathan Rosenberg、Ben Campbell によって執筆された。IETFが本仕様の改版管理権を持つ。 8.3. URN下位名前空間 URI: urn:ietf:params:xml:ns:rlmi 説明: これは、複数のサブスクリプションが1個のSIPサブスクリプション内 で統合される際にサブスクリプションに関する情報を記述するために、 RFC 4662で定義されたXML要素のXML名前空間URIである。 「application/pidf+xml」ボディタイプで使用される。 登録者の連絡先: 名前: Adam Roach E-Mail: adam@estacado.net 著者/改版管理者: このMIMEタイプの仕様は、SIMPLEワーキンググループ の研究結果であり、Adam Roach、Jonathan Rosenberg、Ben Campbell によって執筆された。IETFが本仕様の改版管理権を持つ。 Roach, et al. Standards Track [Page 35] RFC 4662 SIP Event Lists August 2006 XML: BEGIN Namespace for SIP Event Resource List Meta-Information

Namespace for SIP Event Resource List Meta-Information

application/rlmi+xml

See RFC4662.

END 9. 謝辞 本プロトコルのXMLの用法についての確認と修正について、Sean Olsonに感謝 を述べたい。 また、本文書を慎重に確認および助言をくださったHisham Khartabil、Paul Kyzivat、Keith Drage、Robert Sparksにも感謝を述べたい。 10. 参考文献 10.1. 規範となる参考文献 [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] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Roach, et al. Standards Track [Page 36] RFC 4662 SIP Event Lists August 2006 [4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [7] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. 10.2. 有益な参考文献 [8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [9] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [11] Levinson, E., "SGML Media Types", RFC 1874, December 1995. [12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Roach, et al. Standards Track [Page 37] RFC 4662 SIP Event Lists August 2006 著者の連絡先 Adam Roach Estacado Systems US EMail: adam@estacado.net Ben Campbell Estacado Systems US EMail: ben@estacado.net Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US EMail: jdrosen@cisco.com Roach, et al. Standards Track [Page 38] RFC 4662 SIP Event Lists August 2006 完全な著作権表記 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Roach, et al. Standards Track [Page 39]