Network Working Group M. Garcia-Martin Request for Comments: 5365 G. Camarillo Category: Standards Track Ericsson October 2008 セッション開始プロトコル(SIP)における 複数受信者のMESSAGEリクエスト Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過 程プロトコルを規定し、改善のための議論や提案を依頼するものである。 標準化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は 無制限である。 概要 本文書は、SIP URIリスト(Uniform Resource Identifier list)サービスを 使用して、SIPユーザーエージェントクライアント(User Agent Client/UAC)が複数の宛先にSIP MESSAGEリクエストを送信できるメカニズ ムを規定する。 UACは、URIリストとともにペイロードを含むSIP MESSAGEリクエストを MESSAGE URIリストサービスに送信する。このサービスは、ペイロードを含 むMESSAGEリクエストを、リストに含まれる各URIに送信する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. URIリストドキュメント . . . . . . . . . . . . . . . . . . . . 5 5. オプションタグ . . . . . . . . . . . . . . . . . . . . . . . . 6 6. ユーザーエージェントクライアントでの手順 . . . . . . . . . . . 6 7. MESSAGE URIリストサービスにおける手順 . . . . . . . . . . . . 7 7.1. 対象受信者の決定 . . . . . . . . . . . . . . . . . . . . . 8 7.2. 送信MESSAGEリクエストの作成 . . . . . . . . . . . . . . . 8 7.3. 送信MESSAGEリクエストのボディの構築 . . . . . . . . . . . 10 8. UASにおける手順 . . . . . . . . . . . . . . . . . . . . . . . 11 9. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 15 11. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . 16 13.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . 17 Garcia-Martin & Camarillo Standards Track [Page 1] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 1. はじめに RFC 3261 (SIP) [RFC3261]は、MESSAGEリクエストでインスタントメッセー ジを伝達できるようにRFC 3428 [RFC3428]によって拡張されている。RFC 3428 [RFC3428]で説明されているように、SIPベースのメッセージングには 同じリクエストを複数の受信者に送信するメカニズムや、SIP MESSAGEリク エストの全受信者に対して応答するメカニズムはない。本文書はこれらの 機能に対応する。 最初の要件は以下のように表現することができる。 REQ-1: ユーザーがインスタントメッセージリクエストをアドホックグ ループに送信できる必要がある。受信者のIDはそのメッセージで伝達さ れる。 上記の要件を満たすための可能性の1つは、インスタントメッセージカン ファレンスサーバーを使用してインスタントメッセージのセッションを確 立し、たとえばMSRP (Message Session Relay Protocol) [RFC4975]を使用 してメッセージを交換する方法である。このオプションは多くのケースに 適しているように考えられるが、他の状況では、送信側ユーザーが、セッ ションを確立する負担を負わずに、アドホックグループにサイズの小さな ページャーモードのインスタントメッセージを送信したいだけの場合もあ る。本文書では、複数の対象受信者にページャーモードのインスタント メッセージを送信することに焦点を合わせている。 本文書では、ページャーモードのインスタントメッセージで要件を満たす ために、SIP MESSAGEリクエストで受信者リストのボディ(つまりURIリスト を含むボディ部分)を伝達できるようにした。RFC 5363 [RFC5363]の規定に 従い、このContent-Disposition (RFC 2183) [RFC2183]は 'recipient-list'である。SIP MESSAGE URIリストサービスは専門化したア プリケーションサービスであり、リクエストを受信して、受信したペイ ロードを含むMESSAGEリクエストを、リスト内の各URIに送信する。この各 MESSAGEリクエストには、元のMESSAGEリクエストに含まれていたボディの コピーが含まれる。 第2の要件では、"Reply-To-All (全員に返信)"機能に対応する。 REQ-2: グループインスタントメッセージの受信者は、同じグループイ ンスタントメッセージを受信した他の受信者全員に対してメッセージを 送信できる機能を持たなければならない[MUST](つまり、Reply-To-All)。 本文書では、この要件を満たすために、MESSAGE URIリストサービスがボ ディ部分にURIリストも含めることができるメカニズムを提供する。RFC 5363 [RFC5363]の規定に従い、このContent-Disposition (RFC 2183) [RFC2183]は'recipient-list-history'である。'recipient-list-history' ボディは、受信者に送信された各インスタントメッセージのインスタント メッセージペイロードとともに送信される。 Garcia-Martin & Camarillo Standards Track [Page 2] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 MESSAGEリクエストをMESSAGE URIリストサービスを送信するユーザーエー ジェントクライアント(UAC)は、この機能を提供するサービスのSIP URIを 使用して設定する必要がある。このURIを検出し、UACに対して提供する方 法は、本文書の対象外である。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119 [RFC2119]のBCP 14 に記載されるとおりに解釈されるべきであり、本文書に準拠する際の実装 レベルを示すものである。 本文書は、RFC 3261 [RFC3261]に定義されている以下の用語を再利用する。 o Address-of-Record (AOR) o ユーザーエージェント(User Agent/UA) o ユーザーエージェントクライアント(User Agent Client/UAC) o ユーザーエージェントサーバー(User Agent Server/UAS) 本文書では、以下の新しい用語を定義する。 MESSAGE URIリストサービス(MESSAGE URI-list service): URIリストを含 むMESSAGEリクエストを受信し、同様のMESSAGEリクエストをリスト内の 各URIに送信することに専門化したURIリストサービス。この文脈で、 「同様」とは、一部のSIPヘッダーフィールドは変化する可能性はある が、MESSAGE URIリストサービスによってインスタントメッセージペイ ロードは変化しないことを示す。 事実上、MESSAGE URIリストサービスは専門化したB2BUA (Back-to-Back-User-Agents)として動作する。MESSAGE URIリストサー ビスを提供するサーバーは、他の用途にURIリストサービスを提供する こともできる。ただし、この機能は本文書の対象外である。 本文書では、MESSAGE URIリストサービスについてのみ論じる。 受信MESSAGEリクエスト(Incoming MESSAGE request): UACが作成し、 MESSAGE URIリストサービス宛てに送信するSIP MESSAGEリクエスト。通 常のインスタントメッセージペイロードとは別に、受信MESSAGEリクエ ストにはURIリストが含まれる。 送信MESSAGEリクエスト(Outgoing MESSAGE request): MESSAGE URIリスト サービスが作成し、UAS (User Agent Server)宛てに送信するSIP MESSAGEリクエスト。 これには通常のインスタントメッセージペイロードが含まれる。 Garcia-Martin & Camarillo Standards Track [Page 3] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 対象受信者(Intended recipient): MESSAGE URIリストサービスが生成する リクエストの最終的な対象受信者。 全員に返信(Reply-To-All): ペイロードと受信者のリストを含むMESSAGEリ クエストを受信し、送信者とその他の受信者に対してMESSAGEリクエス トを作成して送信できる対象受信者の機能。返信側エンティティは、破 棄する場合にMESSAGE URIリストサービスを使用することができる。ま た、受信者が単一である一連のMESSAGEリクエストを各SIP AORに対して 作成することができる。 3. 概要 UACは、URI (対象受信者)のリストとインスタントメッセージを含むマルチ パートボディのMESSAGEリクエストを作成する。URIのリストは、RFC 4826 [RFC4826]に規定されているリソースリストドキュメント形式に従って書式 が設定される。また、RFC 5364 [RFC5364]に定義されている属性を使用し て拡張される。UACはこのMESSAGEリクエストをMESSAGE URIリストサービス に送信する。MESSAGE URIリストサービスは、この受信MESSAGEリクエスト を受信して、(URIリストに列挙されている)対象受信者ごとにMESSAGEリク エストを作成し、インスタントメッセージペイロードを各MESSAGEにコピー する。また、MESSAGE URIリストサービスは、RFC 5364 [RFC5364]に記載さ れている手順に従ってXMLリソースリストを操作し、インスタントメッセー ジペイロードとともに各MESSAGEリクエストの結果を添付する。次に MESSAGE URIリストサービスは、作成した送信MESSAGEリクエストを各受信 者に送信する。 送信者は、MESSAGE URIリストメカニズムを使用してMESSAGEリクエストに 複数の対象を指定することができる。この場合、RFC 5364 [RFC5364]に定 義されている属性を使用して拡張したMESSAGEリクエストのボディに、RFC 4826 [RFC4826]に従うXMLリソースリストドキュメントを含める。 RFC 5363 [RFC5363]の規定に従い、このリソースリストの Content-Disposition (RFC 2183) [RFC2183]は'recipient-list'である。 このリソースリストには対象のURIが含まれる。RFC 5364 [RFC5364]に記載 されている手順に従って、URIリストサービスが対象に果たす役割(たとえ ば"to"、"cc"、または"bcc")や、対象URIを匿名化すべきかどうかを示すた めに、各対象URIにマークを付けることもできる。MESSAGE URIリストサー バーは、MESSAGEリクエストを各受信者に拡張する場合、(受信したリクエ ストに基づいて)新しいURIリスト(およびインスタントメッセージペイロー ド)を含める。RFC 5364 [RFC5364]の規定に従い、この Content-Disposition (RFC 2183) [RFC2183]は'recipient-list-history' である。この新しいURIリストには、非匿名の"to"および"cc"の対象リスト が含まれ、両方の受信者は他の受信者の情報を知り、返信することができ る。 Garcia-Martin & Camarillo Standards Track [Page 4] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 4. URIリストドキュメント RFC 5363 [RFC5363]に記載されているように、各URIリストサービスの仕様 では、本文書に記載されているMESSAGE URIリストサービスと同様に、特定 のサービス内で使用する'recipient-list'ボディのデフォルト形式を指定 する必要がある。 MESSAGE URIリストサービスの'recipient-list'のデフォルト形式は、コ ピー制御属性[RFC5364]で拡張され、RFC 4826 [RFC4826]で規定されている リソースリストドキュメントである。'recipient-list'ボディを処理する UACとMESSAGE URIリストサービスは、これら両方の形式をサポートしなけ ればならない[MUST]。また、他の形式をサポートしてもよい[MAY]。 RFC 5364 [RFC5364]に記載されているように、"to"、"cc"、または"bcc"に 設定した'copyControl'属性を使用して、各URIにタグを付けることができ る。これは、受信者がMESSAGEリクエストを取得する際の役割を示す。さら に、URIに'anonymize'属性でタグを付けることで、MESSAGE URIリストサー バーがURIリストのターゲットURIを公開することを防ぐことができる。 さらに、RFC 5364 [RFC5364]では、対象受信者のリストを含む 'recipient-list-history'ボディを定義している。MESSAGE URIリストサー ビスの'recipient-list-history'のデフォルト形式も、コピー制御属性 [RFC5364]で拡張され、RFC 4826 [RFC4826]で規定されているリソースリス トドキュメントである。 MESSAGE URIリストサービスはこれら両方の形式をサポートしなければなら ない[MUST]。UASはこれらの形式をサポートしてもよい[MAY]。MESSAGE URI リストサーバーとUASは、他の形式をサポートしてもよい[MAY]。 RFC 4826 [RFC4826]に規定されているリソースリストドキュメントには、 本文書で定義しているMESSAGE URIリストサービスには必要ではない機能が 多数用意されている。MESSAGE URIリストサービスは、UACとMESSAGE URIリ ストサービス間、およびMESSAGE URIリストサーバーとUAS間で、単純な単 一階層のURIリストを転送する必要がある。 またこのサービスでは、階層的リストや、Extensible Configuration Access Protocol (XCAP) [RFC4825]ルートURIに対する相対参照でエントリ を含める機能は必要ない。したがって、本文書で規定しているMESSAGE URI リストサービスは、相対参照を含まない単一階層のリソースリストドキュ メントのみを使用する。 Garcia-Martin & Camarillo Standards Track [Page 5] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 5. オプションタグ 本文書は、SIPヘッダーフィールドのRequireおよびSupportedに使用する 'recipient-list-message'オプションタグを定義する。 このオプションタグは、サーバーがMESSAGEリクエストに使用する 'recipient-list'ボディを確実に処理できるようにするために使用され る。また、このオプションタグには、OPTIONSリクエストに対する応答 でサーバーの機能を検出するメカニズムも用意されている。 セクション6では、このオプションタグの用法に関して規範的手順を説明し ている。 6. ユーザーエージェントクライアントでの手順 受信者が複数のMESSAGEリクエストを作成したいUACは、RFC 3428 [RFC3428]のセクション4に従って書式を設定したMESSAGEリクエストを作成 しなければならない[MUST]。UACは、MESSAGE URIリストサービスのSIP URI またはSIPS URIを使用してRequest-URIを設定する。通常のインスタント メッセージボディとは別に、UACはContent-Dispositionタイプが 'recipient-list' (RFC 5363 [RFC5363]で規定)であるrecipient-listボ ディを追加する。このボディには、MESSAGEの受信者が指定されたURIリス トが含まれる。また、このボディの対象URIには、RFC 5364 [RFC5364]に規 定されている'copyControl'属性と'anonymize'属性でタグを付けてもよい [MAY]。さらにUACは、Requireヘッダーフィールドに 'recipient-list-message' (セクション5で定義)も含めなければならない [MUST]。 recipient-listボディを含むMESSAGEリクエストを生成するUACは、前のセ クションで説明したように、Requireヘッダーフィールドにこのオプション タグを含めなければならない[MUST]。recipient-listボディを含むMESSAGE を受信および処理する機能を持つUAは、前のセクションで説明したように、 OPTIONSリクエストへの応答時にSupportedヘッダーフィールドにこのオプ ションタグを含めるべきである[SHOULD]。 受信者が複数のMESSAGEリクエストには、リストと実際のインスタントメッ セージペイロードをボディに含む、マルチパートボディが含まれる。場合 によっては、MESSAGEリクエストに、テキストやリストのボディ以外のボ ディを含めることができる(たとえば、RFC 3851 [RFC3851]に従ってリクエ ストをS/MIMEで保護するときなど)。 通常、MESSAGE URIリストサービスは、送信MESSAGEリクエストに含まれる 重要なヘッダーフィールドすべてをコピーする。ただし、UACから送信され たMESSAGEリクエストに存在しないヘッダーフィールドでも、MESSAGE URI リストサービスが特定の値を指定した特定のヘッダーフィールドを追加す ることをSIP UAが希望する場合も考えられる。この場合、UACはRFC 3261 [RFC3261]のセクション19.1.1に記載されている「?」メカニズムを使用し て、リストの任意のURIに含まれる別の情報をエンコードしてもよい[MAY]。 Garcia-Martin & Camarillo Standards Track [Page 6] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 ただし、UACは特殊な"body" hname (RFC 3261 [RFC3261]のセクション 19.1.1参照)を使用してボディをエンコードしてはならない[MUST NOT]。こ れは、ボディがMESSAGEリクエスト自体に存在するためである。 以下に「?」メカニズムを使用するURIの例を示す。 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 前述のURIは、MESSAGE URIリストサービスに対して、bob@example.com宛て に送信するMESSAGEリクエストに以下のヘッダーフィールドを追加すること を要求する。 Accept-Contact: *;mobility="mobile" RFC 4826 [RFC4826]に規定されているリソースリストドキュメント形式に は、階層的リストや、XCAPルートURIに対する相対参照でエントリを含める ことができる機能などが用意されている。ただし、こうした機能は本文書 で定義している複数のMESSAGE URIリストサービスには必要ない。したがっ て、デフォルトのリソースリストドキュメントを使用する場合、UAは単一 階層のリスト(つまり非階層的リスト)を使用すべきである[SHOULD]。また、 要素を使用すべきではない[SHOULD NOT] 7. MESSAGE URIリストサービスにおける手順 MESSAGE URIリストサービスはURIリストを含むMESSAGEリクエストを受信し、 UACに対して202 (Accepted)で応答する。 MESSAGEに対する応答のステータスコードでは、MESSAGE URIリストサー ビスによって生成されたMESSAGEがリスト内のURIへ正常に配信されたか どうかに関する情報はわからない点に注意。つまり、202 (Accepted)と は、MESSAGE URIリストサービスがMESSAGEを受信したこと、およびリス ト内のURIに同様のMESSAGEの送信を試みることを意味する。インスタン トメッセージの配信ステータスに関してクライアントに通知するメカニ ズムを設計することは、本文書の対象外である。 MESSAGE URIリストサービスは階層的リストも、XCAPルートURIに対する参 照でエントリを含めるリストも使用しないため、MESSAGE URIリストサー バーは、その範囲を超える情報を含むURIリストを受信した場合、その余計 な情報をすべて破棄してもよい[MAY]。 MESSAGEリクエストに、「?」メカニズム(RFC 3261 [RFC3261]のセクション 19.1.1参照)を使用するURIを含むRequest-URIがあり、そのURIに追加のボ ディを含む特殊な"body" hnameが含まれる場合、MESSAGE URIリストサー バーは、"body"パラメータのコンテンツを破棄してもよい[MAY]。 Garcia-Martin & Camarillo Standards Track [Page 7] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 7.1. 対象受信者の決定 MESSAGE URIリストサービスはURIリストを含むMESSAGEリクエストを受信し た場合、ボディに含まれるURIリストを調べて対象受信者のリストを決定す る。 RFC 5363 [RFC5363]のセクション4.1では、URIリストに重複するURIが見つ かった場合について論じている。重複するリクエストを回避するために、 MESSAGE URIリストサービスはRFC 5363 [RFC5363]に規定されている動作を 考慮して、同じ受信者に重複するリクエストが送信されることを回避しな ければならない[MUST]。 7.2. 送信MESSAGEリクエストの作成 MESSAGE URIリストサービスは、送信MESSAGEリクエストのUACとして動作す るため、RFC 3428 [RFC3428]のセクション4に記載されている手順に従って、 MESSAGE URIリストサービスは、対象受信者のそれぞれについて新しい MESSAGEリクエストを作成する。 さらに、RFC 5363 [RFC5363]のセクション5.3には、送信リクエストを作成 する際のその他の一般的な指針が示されている。本文書では、以下の手順 も規定する。 o MESSAGE URIリストサービスには、受信MESSAGEリクエストに含まれる Fromヘッダーフィールドと同じ値のFromヘッダーフィールドを含めなけ ればならない[MUST]。その際、受信MESSAGEリクエストで表現されてい るプライバシ要件(RFC 3323 [RFC3323]とRFC 3325 [RFC3325]を参照)に 従う。 これは"tag"パラメータには適用されないことに注意。 送信者のFromヘッダーフィールドをコピーできなかった場合、許容 できないセキュリティエラーやプライバシーエラーが発生する。ま た、この要件の目的は、同じ物理ノードで実行されているその他の サービスの要件と矛盾することではない点にも注意が必要である。 具体的には、プライバシサービス(RFC 3323 [RFC3323]参照)は MESSAGE URIリストサービスと共存できるが、この場合、MESSAGE URIリストサービスよりもプライバシサービスの方に優先権がある。 o MESSAGE URIリストサービスは、対象受信者のURIに設定した新しいTo ヘッダーフィールド値を生成すべきである[SHOULD]。RFC 3261 [RFC3261]セクション8.1.1.1の手順に従うと、この値は送信MESSAGEリ クエストのRequest-URIと等しいはずである。 MESSAGE URIリストサービスはユーザーエージェントクライアントと して動作する。 したがって、受信者のURIを使用してToヘッダーフィールドを設定す べきである。 Garcia-Martin & Camarillo Standards Track [Page 8] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 o MESSAGE URIリストサービスは、新しいCall-IDヘッダーフィールド値を 作成すべきである[SHOULD]。 Call-IDヘッダーフィールドには、送信者が非公開にすることを希望 するアドレス情報が含まれる可能性がある。MESSAGE URIリストサー ビスの両側で同じCall-IDを維持する必要はなく、またMESSAGE URI リストサービスはユーザーエージェントクライアントとして動作す るため、通常のSIPの手順に従ってCall-IDヘッダーフィールド値を 作成することが推奨される。 o P-Asserted-Identityヘッダーフィールドが受信MESSAGEリクエストにあ り、RFC 3325 [RFC3325]の規定に従って信頼関係のある送信元からその リクエストを受信し、また送信MESSAGEリクエストの最初のホップも信 頼できる場合、MESSAGE URIリストサービスは、送信MESSAGEリクエスト に同じ受信値を指定したP-Asserted-Identityヘッダーフィールドを含 めなければならない[MUST]。ただし、送信MESSAGEリクエストの最初の ホップを信頼できず、受信MESSAGEリクエストに'none'以外の値の Privacyヘッダーフィールドが含まれていた場合、MESSAGE URIリスト サービスは送信MESSAGEリクエストにP-Asserted-Identityヘッダー フィールドを含めてはならない[MUST NOT]。 o MESSAGE URIリストサービスが(たとえば、RFC 2617 [RFC2617]に従って HTTPダイジェスト認証スキームを使用したり、RFC 3851 [RFC3851]に 従ってS/MIMEを使用して)ユーザーのIDをアサートできる場合で、かつ サービスがその認証スキームをSIP URIまたはSIPS URIにマッピングで きるメカニズムを実装していて受信MESSAGEリクエストに表現されてい るプライバシ要件に従う場合(RFC 3323 [RFC3323]参照)、MESSAGE URI リストサービスは、ユーザーのアサート済みURIの値を指定した P-Asserted-Identityヘッダーを挿入してもよい[MAY]。 o 受信MESSAGEリクエストにAuthorizationまたはProxy-Authorizationヘッ ダーフィールドが含まれ、その領域がMESSAGE URIリストサーバーの領 域に設定されている場合、MESSAGE URIリストサービスはそれを送信 MESSAGEリクエストにコピーすべきではない[SHOULD NOT]。それ以外の 場合(つまり、受信MESSAGEリクエストのAuthorizationまたは Proxy-Authorizationヘッダーフィールドに異なる領域が含まれる場合)、 MESSAGE URIリストサービスは送信MESSAGEリクエストの対応するヘッ ダーフィールドに値をコピーしなければならない[MUST]。 o MESSAGE URIリストサービスは、送信MESSAGEリクエストのCSeqヘッダー フィールド[RFC3261]用に別のカウントを作成すべきである[SHOULD]。 o MESSAGE URIリストサービスは、送信MESSAGEリクエストのMax-Forward ヘッダーフィールドの値を初期化すべきである[SHOULD]。 Garcia-Martin & Camarillo Standards Track [Page 9] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 o MESSAGE URIリストサービスは、Viaヘッダーフィールドに自身の値を含 めなければならない[MUST]。 7.3. 送信MESSAGEリクエストのボディの構築 各送信MESSAGEリクエストのボディを作成するとき、MESSAGE URIリスト サービスは関連する受信MESSAGEリクエストのボディを維持し、送信 MESSAGEリクエストにコピーする。以下のガイドラインは、一般的なボディ 処理の例外事項である。 o MESSAGE URIリストサービスが受信したMESSAGEリクエストには、MESSAGE URIリストサービスのパブリックキーで暗号化したセキュリティボディ (たとえば、S/MIME、RFC 3851 [RFC3851])を1つまたは複数含めること ができる。これらのボディは、送信MESSAGEリクエストの受信者(受信者 は復号化する機能を持たない)ではなくURIリストサービスから読み取ら れると考えられる。したがって、MESSAGE URIリストサービスは、 MESSAGE URIリストサービス宛てのセキュリティボディ(RFC 3851 [RFC3851]の暗号化ボディに従うS/MIMEなど)を、送信MESSAGEリクエス トにコピーしてはならない[MUST NOT]。これには、URIリストサービス のパブリックキーで暗号化したボディが含まれる。 o 通常、受信MESSAGEリクエストには、recipient-listボディ、または受信 者の実際のリストに対する参照(RFC 5363 [RFC5363]参照)が含まれる。 このURIリストに、"to"または"cc"の値に設定した'copyControl'属性で タグを付けられたリソースが含まれる場合、URIリストサービスは、各 送信MESSAGEリクエストにURIリストを含めるべきである[SHOULD]。この リストは、RFC 4826 [RFC4826]に規定されているリソースリストドキュ メント形式、およびRFC 5364 [RFC5364]に規定されているcopyControl 拡張に従って書式を設定すべきである[SHOULD]。MESSAGE URIリスト サービスは、'anonymize'、'count'、および'copyControl'の各属性の 処理に関して、RFC 5364 [RFC5364]に規定されている手順に従わなけれ ばならない[MUST]。 o MESSAGE URIリストサービスが送信MESSAGEリクエストにURIリストを含め る場合、RFC 2183 [RFC2183]に従って値を'recipient- list-history' に設定したContent-Dispositionヘッダーフィールドを含め、さらにRFC 3204 [RFC3204]に従って"optional"に設定した"handling"パラメータを 含めなければならない[MUST]。 o MESSAGE URIリストサービスが送信MESSAGEリクエストにURIリストを含め る場合、S/MIME (RFC 3851) [RFC3851]を使用して受信者のパブリック キーでURIリストを暗号化すべきである[SHOULD]。 Garcia-Martin & Camarillo Standards Track [Page 10] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 o MESSAGE URIリストサービスは、受信MESSAGEリクエストのその他のメッ セージボディ(たとえば、テキストメッセージ、イメージなど)すべてを 送信MESSAGEリクエストにコピーすべきである[SHOULD]。 o 1つのボディしか残っていない場合、MESSAGE URIリストサービスは送 信MESSAGEリクエストのmultipart/mixedラッパーを削除しなければなら ない[MUST]。 URIリストに含まれる特定のURIに相当するその他のMESSAGEリクエストは、 RFC 3261のセクション19.1.5「Forming Requests from a URI (URIからの リクエストの構築)」の規則に従って作成しなければならない[MUST]。特に、 RFC 3261のセクション19.1.5には以下のように記載されている。 「実装では、URIのすべてのヘッダーまたはボディ部の存在について、 それらをメッセージに含める希望として扱い、コンポーネントごとにそ のリクエストを尊重することを選択すべきである[SHOULD]」 SIPでは、"method"パラメータをURIに付加することを許可している。した がって、XMLリソースリストの要素の'uri'属性に"method"パラメー タを含めることは正規の方法である。MESSAGE URIリストサービスは、リス ト内のURIが示す"method"パラメータに関係なく、MESSAGEリクエストのみ を生成しなければならない[MUST]。事実上、MESSAGE URIリストサービスは、 URIリストに含まれる各URIの"method"パラメータを無視しなければならな い[MUST]。 8. UASにおける手順 MESSAGE URIリストサービスからMESSAGEリクエストを受信するUAS (本仕様 では対象受信者UASとも呼ばれる)は、RFC 3428 [RFC3428]のセクション7の 規定に従って動作する。 UASが本仕様をサポートし、MESSAGEリクエストにRFC 2183 [RFC2183]に 従って'recipient-list-history'に設定されたContent-Dispositionヘッ ダーフィールドが指定されたボディが含まれる場合、UASはMESSAGEリクエ ストの他の対象受信者のSIP Addresses-of-Record (AOR)を決定することが できる。これによって、ユーザーは、送信者とURIリストに含まれる他の受 信者に対して応答リクエスト(たとえば、MESSAGE、INVITEなど)を作成する ことができる。 Garcia-Martin & Camarillo Standards Track [Page 11] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 9. 例 図1は操作例である。SIP UAC発行者がMESSAGEリクエストを送信する。 MESSAGE URIリストサービスが202 (Accepted)で応答し、MESSAGEリクエス トを各対象受信者に送信する。 +--------+ +---------+ +--------+ +--------+ +--------+ |SIP UAC | | MESSAGE | |intended| |intended| |intended| | issuer | | URI-list| | recip. | | recip. | | recip. | | | | service | | 1 | | 2 | | n | +--------+ +---------+ +--------+ +--------+ +--------+ | | | | | | F1 MESSAGE | | | | | ---------------->| | | | | F2 202 Accepted | | | | |<---------------- | F3 MESSAGE | | | | | ------------->| | | | | F4 MESSAGE | | | | | ------------------------>| | | | F5 MESSAGE | | | | | ----------------------------------->| | | F6 200 OK | | | | |<------------- | | | | | F7 200 OK | | | | |<------------------------ | | | | F8 200 OK | | | | |<----------------------------------- | | | | | | | | | | | | | | | | 図1: 操作例 MESSAGEリクエストF1 (図2参照)には、2つのボディから構成される multipart/mixedボディが含まれる。インスタントメッセージペイロードを 含むmultipart/mixedボディと、受信者リストを含む application/resource-lists+xmlボディである。 Garcia-Martin & Camarillo Standards Track [Page 12] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 MESSAGE sip:list-service.example.com SIP/2.0 Via: SIP/2.0/TCP uac.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: MESSAGE URI-list service From: Alice ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 1 MESSAGE Require: recipient-list-message Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 501 --boundary1 Content-Type: text/plain Hello World! --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list --boundary1-- 図2: MESSAGE URIリストサーバーが受信するMESSAGEリクエスト MESSAGEリクエストF3、F4、およびF5は性質が似ている。これらすべての MESSAGEリクエストには、他の2つのボディから構成されるmultipart/mixed ボディが含まれる。インスタントメッセージペイロードを含む multipart/mixedボディと、受信者リストを含む application/resource-lists+xmlボディである。MESSAGEリクエストF3、F4、 およびF5のapplication/ resource-lists+xmlボディは、text/plain body Garcia-Martin & Camarillo Standards Track [Page 13] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 とは異なり、受信MESSAGEリクエストF1に含まれる application/resource-lists+xmlボディとは等値ではない。この理由は、 URIリストサービスが'anonymize'属性でタグを付けられたURIを匿名化し、 "bcc" 'copyControl'でタグが付けられてURIを削除したためである。 さらに、これらのボディのContent-Dispositionは異なる。 図3はMESSAGEリクエストF3の一例である。 MESSAGE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP list-service.example.com ;branch=z9hG4bKhjhs8as34sc Max-Forwards: 70 To: From: Alice ;tag=210342 Call-ID: 39s02sdsl20d9sj2l CSeq: 1 MESSAGE Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 501 --boundary1 Content-Type: text/plain Hello World! --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional --boundary1-- 図3: MESSAGE URIリストサーバーが送信するMESSAGEリクエスト Garcia-Martin & Camarillo Standards Track [Page 14] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 10. セキュリティの考慮事項 RFC 5363 [RFC5363]では、SIP URIリストサービスに関連する問題について 論じている。 MESSAGE URIリストサービスの実装は、RFC 5363 [RFC5363]のセキュリティ 関連の規則に従わなければならない[MUST]。この規則には、クライアント のオプトインリストおよび必須の認証と認可が含まれる。 インスタントメッセージのコンテンツを非公開にする必要がある場合、 ユーザーエージェントクライアントはRFC 3851 [RFC3851]に従ってS/MIME を使用し、サードパーティがその情報を表示できないようにすべきである [SHOULD]。この場合、ユーザーエージェントクライアントは、コンテンツ の暗号化キーでインスタントメッセージボディを暗号化すべきである [SHOULD]。また、UACは、リストの受信者ごとに、受信者のパブリックキー を使用してコンテンツの暗号化キーを暗号化し、それをMESSAGEリクエスト に添付すべきである[SHOULD]。 11. IANA条項 本文書は、SIPオプションタグ'recipient-list-message'を定義する。 以下の行が「SIP Parameter Registry」の「Option Tags」セクションに追 加された。 +------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | recipient-list-message | The body contains a list of | [RFC5365] | | | URIs that indicates the | | | | recipients of the SIP | | | | MESSAGE request | | +------------------------+------------------------------+-----------+ 表1: SIPの'recipient-list-message'オプションタグの登録 12. 謝辞 Duncan Millsは1対nのMESSAGEを持つ概念についてサポートしてくださった。 Ben Campbell、Paul Kyzivat、Cullen Jennings、Jonathan Rosenberg、 Dean Willis、Keith Drageからは参考になるコメントをいただいた。 Garcia-Martin & Camarillo Standards Track [Page 15] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 13. 参考文献 13.1. 規範となる参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [RFC3261] 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. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007. [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services", RFC 5363, October 2008. Garcia-Martin & Camarillo Standards Track [Page 16] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008. 13.2. 有益な参考文献 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. 著者の連絡先 Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain EMail: miguel.a.garcia@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Garcia-Martin & Camarillo Standards Track [Page 17] RFC 5365 SIP Multiple-Recipient MESSAGE Requests October 2008 完全な著作権表記 Copyright (C) The IETF Trust (2008). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イ ンターネット協会、IETF TSUST、およびIETFは、この情報がいかなる権利 も侵害していないという保証、商用利用および特定目的への適合性への保 証を含め、また、これらだけに限らずすべての保証について、明示的もし くは暗黙的の保証は行われない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、 知的所有権または他の諸権利の有効性または範囲に関して、またはこのよ うな権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関し て、何ら見解を持たない。このような権利を確認する独自の取り組みを 行ったことも示さない。RFC文書の権利に関する手続きの情報は、BCP 78お よびBCP 79に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実 装者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果 については、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取 得可能である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性 がある、すべての著作権、特許または特許アプリケーション、あるいは他 の所有権について、すべての関連団体に対して配慮するよう依頼している。 情報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2009年 ----------------------------------------------------------------------- Garcia-Martin & Camarillo Standards Track [Page 18]