Network Working Group B. Campbell, Ed. Request for Comments: 3428 J. Rosenberg Category: Standards Track dynamicsoft H. Schulzrinne Columbia University C. Huitema D. Gurle Microsoft Corporation December 2002 インスタントメッセージのためのセッション開始プロトコル(SIP)拡張 Session Initiation Protocol (SIP) Extension for Instant Messaging 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。 この文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 インスタントメッセージング(IM)とは、ほぼリアルタイムでユーザー間のメ ッセージ送信を行うことである。これらのメッセージは、要求事項ではない が、通常、短い。IMは会話モードで使用されることが多い。すなわち、メッ セージの送受信はインタラクティブな会話を維持するのに十分なほど迅速に 行われる。 本文書はMESSAGEメソッド、すなわちインスタントメッセージの転送 (transfer)を可能にするセッション開始プロトコル(SIP)への拡張を提案する ものである。MESSAGEリクエストはSIPの拡張なので、そのプロトコルのすべて のリクエストルーティングおよびセキュリティ機能を引き継いでいる。 MESSAGEリクエストは、コンテンツをMIMEボディとして運ぶことを要求する。 MESSAGEリクエストは、それ自体でSIPダイアログを開始しない。通常の使用で は、ページャーのメッセージと同様に、インスタントメッセージは独立してい る。MESSAGEリクエストは、他の何らかのSIPリクエストによって開始されたダ イアログのコンテキスト中で送信されるかもしれない。 Campbell, et. al. Standards Track [Page 1] RFC 3428 SIP Message Extension December 2002 述語規則 この文書では、次のキーワードはBCP 14、RFC2119(参考文献[6])に記述されて いるとおりに解釈され、SIPに準拠した実装のための要求レベルを示す。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、 「MAY」、および「OPTIONAL」 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 適用範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 操作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. UACの処理. . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. インスタントメッセージURIの用法 . . . . . . . . . . . . . . 6 6. プロキシの処理 . . . . . . . . . . . . . . . . . . . . . . . 6 7. UASの処理. . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. 輻輳制御 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. メソッドの定義 . . . . . . . . . . . . . . . . . . . . . . . 9 10. メッセージの例 . . . . . . . . . . . . . . . . . . . . . . . 11 11. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . 13 11.1 アウトバウンド認証 . . . . . . . . . . . . . . . . . . . . . 13 11.2 SIPS URI . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.3 エンドツーエンドの防御 . . . . . . . . . . . . . . . . . . . 14 11.4 リプレイ防止 . . . . . . . . . . . . . . . . . . . . . . . . 14 11.5 message/cpimボディの使用 . . . . . . . . . . . . . . . . . . 15 12. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. 貢献してくれた人々 . . . . . . . . . . . . . . . . . . . . . 15 14. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . 16 16. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . . 16 17. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 17 18. 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . 18 1. はじめに インスタントメッセージング(IM)は、ほぼリアルタイムで参加者間でコンテン ツを交換することと定義される。通常、コンテンツは短いテキスト形式のメッ セージであるが、そうである必要はない。通常、交換されるメッセージは保存 されないが、これに関してもそうである必要はない。通常の使い方では、IM は、やりとりされる多数の小さなメッセージから構成される、短時間の生の会 話としてグループ化されるという点において、Eメールと異なる。 サービスとしてのインスタントメッセージングは、イントラネットとIPネット ワークに長い間存在している。初期の実装としては、UNIXの会話アプリケーシ ョン(zephyr、参考文献[11])とIRCがある。より最近では、IMは、プレゼンスと Campbell, et. al. Standards Track [Page 2] RFC 3428 SIP Message Extension December 2002 バディリストを組み合わせたサービスとして使用されている。つまり、友人が オンラインになったときに、ユーザーがそのことを知り、その友人にインスタ ントメッセージを送るオプションがあるということである。これを実現するプ ロトコルはすべて独自であり、相互運用性を大きく阻害している。 インスタントメッセージング、プレゼンス、およびセッション指向のコミュニ ケーションが統合されたものは非常に強力である。セッション開始プロトコル (SIP)(参考文献[1])は、プレゼンスアプリケーションとセッション指向コミュ ニケーションアプリケーションに対しては有用なメカニズムを提供するが、イ ンスタントメッセージに対しては提供しない。 本文書では、MESSAGEメソッドという、SIPの拡張メソッドを提案する。 MESSAGEリクエストは、通常、リクエストボディでインスタントメッセージの コンテンツを伝える。 RFC 2778(参考文献[3])とRFC 2779(参考文献[6])が、プレゼンスとインスタン トメッセージングプロトコルに対するモデルと要求を提示している。MESSAGE メソッドの実装は、その適用範囲に関して、RFC 2779におけるインスタントメ ッセージングに関するすべての要件に対応することになっている[SHALL]。 2. 適用範囲 本文書では、双方向ページャーや、SMSが可能なハンドセットのメッセージに 類似したメタファーを用いて、インスタントメッセージを送るためのMESSAGE メソッドの用法を述べる。つまり、メッセージ間に明白な関連性がないとい うことである。各IMは独立している。どのような形であれ「会話」という感 覚は、クライアントユーザーインターフェース内あるいはユーザーの想像の 中にだけ存在する。これを、明確な開始と終了とともに明らかな会話が存在 する「セッション」モデルと対比する。SIP環境において、IMセッションは、 INVITEトランザクションで開始され、BYEトランザクションで終了する、メデ ィアセッションであろう。 各モデルにはそれぞれ意義がある。最近のほとんどのIMクライアントは、双 方のユーザーにエクスペリエンスを提示する。ユーザーは、contactにIMを送 ったり、1人以上のcontactを会話に参加させるために招待したりすることが できる。ユーザーが少量の短いIMを1人(もしくは少数の)受信者に送ろうとす るときは、ページャーモデルが理にかなっている。セッションモデルは、長 時間の会話、チャットグループへの参加、会話をSIPによって開始された他の 何らかのセッションに関連付ける必要がある場合、などのときに理にかなっ ている。 本文書では、ページャーモデルのみを扱う。セッションモデルの意義も同様 に認識しているが、ここでは定義しない。そのようなソリューションは、本 文書で行った作業以上のさらなる作業を必要とする。SIMPLEワークグループ が、別文書でIMセッションを扱うことを現在計画している。 Campbell, et. al. Standards Track [Page 3] RFC 3428 SIP Message Extension December 2002 ダイアログを開始し、そのダイアログのコンテキスト内でMESSAGEリクエスト を送信することで、IMのセッションをシミュレートするという誘惑にかられ るかもしれない。このアプローチは、MESSAGEリクエストがおそらく間違いな く、シグナリングではなくメディアを運ぶにもかかわらず、MESSAGEリクエス トが他のすべてのSIPリクエストと同じネットワークパスを通ることを要求す るので、IMセッションに対する適切なソリューションではない。IMアプリケ ーションは、通常、大容量であり、セッション中のIM容量は更に大きいと予 想される。このことは、輻輳制御がないトランスポート上で送信され、一部 のホップがUDP上でMESSAGEリクエストを転送する(forward)ことを防ぐ明確なSIP のメカニズムがない場合に、おそらく輻輳問題を引き起こす。 さらに、既存のダイアログ上で送信されるMESSAGEリクエストは、SIPの性質に より、そのダイアログ内で送信される他のすべてのリクエストと同じ送信先に 送信されなければならない[MUST]。これは、IMエンドポイントとシグナリング エンドポイントのあいだのいかなる分離も防ぐ。これは、インスタントメッセ ージングのセッションモデルにおいては、受け入れられない制限である。 ダイアログのコンテキスト内でMESSAGEリクエストを送信する、正当な理由が あるかもしれない、ということを著者は認識している。例えば、ボイスセッシ ョン中の1人の参加者が、他の参加者にIMを送りたいと思い、そのIMをセッシ ョンに関連付けるかもしれない。しかし、実装は、MESSAGEリクエストを互い に関連付けることを主目的としてダイアログを生成するべきではない [SHOULD NOT]。 この記述は、IMからなるメディアセッションを開始するためにSIPを使用する ことを、他のすべてのセッションと同様に、禁止しないことに注意すること。 実際には、IMセッションのためのソリューションが、そのメタファーを使用 することを期待している。読者は、SIPダイアログとメディアセッションのコ ンセプトを混同しないようにするべきである。 3. 操作概要 1人のユーザーが別のユーザーにインスタントメッセージを送ろうとすると き、送信側は、本文書で定義されている新規MESSAGEメソッドを使って、SIPリ クエストを形成し発行する。このリクエストのRequest-URIは、通常、インス タントメッセージの受信者の「Address-of-Record」であるが、クライアント が受信者の場所に関する最新情報を持っている場合には、デバイスのアドレス でもよい。例えば、クライアントは、指定されたAddress-of-Recordに対する 最新のデバイスのcontactを提供する、プレゼンスシステムと一体となってい るかもしれない。リクエストのボディは、配送されるメッセージを含む。この ボディは、message/cpim を含め、どのようなMIMEタイプでもよい(参考文献 [7])。message/cpim形式は別のインスタントメッセージプロトコルによりサポ ートされることが考えられるため、異なるIMプロトコルを利用している、さも なければmessage/cpimボディタイプをサポートしているエンドポイントは、ゲ ートウェイまたは他の中継媒体によるコンテンツの修正なしに、メッセージを Campbell, et. al. Standards Track [Page 4] RFC 3428 SIP Message Extension December 2002 やり取りすることが可能であるべきである。このことは、異なるIMプロトコル を利用するエンドポイント間のエンドツーエンドのセキュリティを可能にする のに役立つ。 リクエストは、送信先に到達する前に、様々なトランスポートを使用するSIP プロキシの組をトラバースするかもしれない。各ホップの送信先は、Common Profile for Instant Messaging (CPIM) (参考文献[8])およびSIP仕様中で詳 細に述べられている、アドレス解決のルールを使用して位置が特定される。ト ラバースする間に、それぞれのプロキシは、有効なルーティング情報に基づい てrequest URIを書き換えるかもしれない。 リクエストに対する暫定応答と最終応答は、他のどのようなSIPリクエストと も同様に、送信側に返される。通常、200 OK応答がリクエストの最終的な受 信者のユーザーエージェントによって生成される。これは、ユーザーエージ ェントがメッセージを受諾したということで、ユーザーが見たのではないと いうことに注意する必要がある。 MESSAGEリクエストはダイアログを確立しない。 4. UACの処理 本文書中で特に明記しない限り、MESSAGEリクエストとそれに関連する応答 は、SIP仕様のセクション8.1のルールに従って構築される(参考文献[1])。 MESSAGEメソッドをサポートするすべてのUACは、text/plainタイプのボディを 持つMESSAGEリクエストを送信することに備えなければならない[MUST]。それ らはmessage/cpimタイプのボディを送信してもよい(参考文献[7])。 MESSAGEリクエストはダイアログを開始しない。ユーザーエージェントは、 MESSAGEリクエストにContactヘッダーフィールドを挿入してはならない [MUST NOT]。 UACはMESSAGEリクエストを既存のダイアログに関連付けてもよい[MAY]。 MESSAGEリクエストがダイアログ内で送信された場合、それは、そのダイアロ グに関連付けられているすべてのメディアセッション(1つまたは複数)に「関 連付け」られる。 UACがMESSAGEリクエストに対して200 OK応答を受信する場合、メッセージが最 終目的地に配送されたと思ってもよい。受信者が実際にそのインスタントメッ セージを読んだと思ってはならない[MUST NOT]。UACが202 Accepted応答を受 信する場合、メッセージは、ゲートウェイ、保管と転送(forward)を行うサー バー(store and forward server)、あるいは最終的にメッセージを配送するか もしれない他の何らかのサービスまで配送された。この場合、UACはメッセー ジが最終目的地まで配送されたと思ってはならない[MUST NOT]。202 Accepted で応答されたメッセージに対する配送確認が要求される場合、その 確認は他の何らかのメカニズムを利用して配送されなければならない(これ は、本仕様の適用範囲外である)。 Campbell, et. al. Standards Track [Page 5] RFC 3428 SIP Message Extension December 2002 ダウンストリームのプロキシはMESSAGEリクエストをフォークするかもしれな いということに注意すること。これが起こると、フォークを行うプロキシは、 たとえ複数の最終応答を受信するとしても、1つの最終応答をアップストリー ムに転送する(forward)だろう。UACが、フォークが起こったかどうかを検知す る方法はないだろう。したがって、UACは、与えられた最終応答が、リクエス トを受信した唯一のUASを表すと思ってはならない[MUST NOT]。例えば、フォ ークの複数のブランチが、2xx応答を生成したのかもしれない。UACがその中の 1つの応答だけしか見ることができないとしても、実際にはリクエストは2つめ のデバイスにも受信されている。 UACは、メッセージのコンテンツの有効性を制限するためにExpiresヘッダーフ ィールドを追加することができる[MAY]。UACが、値がゼロではないExpiresヘ ッダーフィールドを追加する場合は、メッセージが送信される時間を含んだ Dateヘッダーフィールドも追加するべきである[SHOULD]。 5. インスタントメッセージURIの用法 インスタントインボックスは、通常、「im:user@domain」形式のインスタント メッセージURI(参考文献[8])で参照される。IM URIは抽象的なものであり、最 終的には、具体的なプロトコル依存のURIに変換される。 UAがインスタントメッセージのアドレスとしてIM URIを渡された場合、それを SIP URIに解決して、その結果得られるURIをMESSAGEリクエストを送信する前 にその中のRequest-URIに置くべきである[SHOULD]。UAがIM URIを解決できな い場合、そのIM URIをRequest-URI中に置いてもよく[MAY]、そのため、プロキ シやゲートウェイのようなダウンストリームのデバイスに解決を委託すること になる。可能な限り早い段階でこの変換を行うことは、im: 名前空間を理解し ないSIPプロキシがリクエストを通常どおりルートすることを可能にする。 MESSAGEリクエストは、FromおよびToヘッダーフィールドの形で、送信者およ び意図する受信者の論理的な識別子も含む。これらの識別子はSIPまたは SIPS URIを含むべきである[SHOULD]が、リクエスト構築時にSIP URIが未知の 場合はIM URIを含んでもよい[MAY]。 Record-RouteおよびRouteヘッダーフィールドはIM URIを含んではならない [MUST NOT]。これらのヘッダーフィールドは、SIPのルールに従って、具体的 なSIPまたはSIPS URIを含む(参考文献[1])。 6. プロキシの処理 プロキシはMESSAGEリクエストを、SIP(参考文献[1])のルールに従ってルート する。MESSAGEリクエストはフォークしてもよい[MAY]ということに注意する必 要がある。MESSAGEリクエストのフォークは、ユーザーがいるかもしれないい くつかのターミナルにメッセージを配送することを可能にする。MESSAGEリク エストをフォークするプロキシは、非INVITEリクエストをフォークするための Campbell, et. al. Standards Track [Page 6] RFC 3428 SIP Message Extension December 2002 通常のSIPのルールに従う。特に、フォークによって複数の配送に成功したと しても、フォークを行うプロキシはアップストリームに唯1つの最終応答を転 送する(forward)。 7. UASの処理 MESSAGEリクエストを受信するUASは、SIPのルールに従ってそれを処理する(参 考文献[1])。 MESSAGEリクエストを受け取るUASは、直ちに最終応答(final response)で応答 しなければならない。しかしながら、200 OKで応答する前あるいはあとに、ユ ーザーに対してUASがメッセージを表示する義務はないことに注意する必要が ある。すなわち、200 OK応答は、ユーザーがメッセージを読んだということを 必ずしも意味しない。 MESSAGEリクエストに対する2xx応答はボディを含んではならない[MUST NOT]。 UASは2xx応答にContactヘッダーフィールドを挿入してはならない[MUST NOT]。 メッセージを保存しその後転送する(forward)、あるいはSIP以外のドメインに 転送する(forward)、実のところメッセージ中継機であるUASは、メッセージが 受け入れられたことを示す202応答(Accepted)(参考文献[5])を返すべきである [SHOULD]。メッセージは受け入れられてもエンドツーエンドの配送は保証され ていない。 4xxあるいは5xx応答は、メッセージがうまく配送されなかったことを示す。 6xx応答は、うまく配送されたが拒否されたことを意味する。 MESSAGEメソッドをサポートするUASは、ボディタイプ「text/plain」の受信と 提供をする用意ができていなければならないが[MUST]、またボディタイプ 「message/cpim」の受信と提供をサポートしてもよい[MAY](参考文献[7])。 MESSAGEリクエストは、有効期限時間が経過している場合は、期限切れになっ たと考えられる。有効期限時間は、Expiresヘッダーフィールドが存在してい ればそれを調べることにより割り出せる。Expiresヘッダーフィールドを持た ないMESSAGEリクエストは期限切れにならない。Expiresヘッダーフィールドを 含むMESSAGEリクエストがDateヘッダーフィールドも含む場合、UASはExpires ヘッダーフィールド値をDateヘッダー値からのデルタタイムとして解釈するべ きである[SHOULD]。リクエストがDateヘッダーフィールドを含まない場合、 UASはExpiresヘッダー値を、UASがリクエストを受信した時間からのデルタタ イムとして解釈するべきである[SHOULD]。 UASがユーザーにメッセージを提示することができる前にMESSAGEが期限切れに なる場合、UASはそのメッセージをローカルポリシーに従って処理するべきで ある[SHOULD]。このポリシーは、メッセージが表示されずに削除される、 Campbell, et. al. Standards Track [Page 7] RFC 3428 SIP Message Extension December 2002 メッセージがユーザーに表示されたままにする、あるいは、何らかの別のポリ シーを呼び出す、ことを意味することがあり得る。メッセージが表示された場 合、UASはメッセージが期限切れになったことをユーザーに明確に示すべきで ある[SHOULD]。 UASがメッセージ中継媒体として動作しており、メッセージを期限切れ前に配 送できない場合は、ローカルポリシーに基づいて動作を選択する。この動作に は、配送されないメッセージを削除すること、そのまま配送すること、期限切 れになったメッセージのログを取ること、あるいは他のすべてのローカルポリ シー、が含まれる。 8. 輻輳制御 既存のIMサービスは、非常に多く利用されている。また、MESSAGEリクエスト は、ペイロードでIMの形でメディアを運ぶという点で他の種類のSIPリクエス トとは異なる。従来のSIPペイロードは、メディア自体ではなくメディアに関 するシグナリング情報を運ぶ。SIPインフラストラクチャが呼シグナリングと インスタントメッセージで共有されるようになったとき、IMのトラフィックが 呼シグナリングのトラフィックを邪魔する可能性がある。一般的な輻輳制御 は、個々のメソッドではなく、SIP仕様のレベルで扱われるべき問題である。 しかし、MESSAGEのトラフィックパターンはおそらく他の多くのメソッドと異 なるので、MESSAGEで特別に考慮することは理にかなっている。 可能であればいつでも、MESSAGEリクエストはTCPやSCTPのようなエンドツーエ ンドの輻輳制御を実装したトランスポート上で送信されるべきである [SHOULD]。しかしながら、SIPはダウンストリームのホップがUDP上でリクエス トを送信することを防ぐメカニズムを提供しない。特定のサイズを超えるリク エストに対してTCPを使用するという要求でさえ、受信者によって無効にされ 得る。従って、UACが輻輳制御されたトランスポートを使用することは十分で はない。 メディアセッション外のMESSAGEリクエストのサイズは、メッセージがどのホ ップにおいても輻輳制御されていないリンクをトラバースしない、あるいは、 メッセージサイズが途中通過するUASで最低のMTU値よりも少なくとも200バイ ト小さい、という確かな知識をUACが持っているのでなければ、1300バイトを 超えてはならない[MUST NOT]より大きなペイロードは、メディアセッション の一部として、あるいは、ある種の間接的なコンテンツ参照(content- indirection)を使用して、送信できる。 本文書執筆の時点では、普通のネットワークアーキテクチャの外で、あ るいは1つの管理ドメインによって完全に制御されているネットワークで、 UACがそのような知識を得るためのメカニズムはない。しかし、各ホップ で輻輳制御を確実にするメカニズムが将来作られた場合、本仕様に変更 を加えることなしに、MESSAGEクライアントはサイズ制限を緩和できる。 著者はそのようなメカニズムが近い将来作られることを期待する。 Campbell, et. al. Standards Track [Page 8] RFC 3428 SIP Message Extension December 2002 ネクストホップのSIPデバイスへのパスMTUに基づいて、1300バイト制 限を設けることについての議論が行われた。パスMTUよりも200バイト少 ない制限を選択するか、あるいはデバイスがパスMTUを知らない場合は 1300バイトを選択することで、SIP仕様はまさにそれを行っている。トラ ンスポートの決定はホップごとに行われる。しかしながら、この制限の 目的は、アップストリームのプロキシがUDP上で大きなコンテンツを含む MESSAGEリクエストを送信しないことを保証することである。わずかな場 合を除き、MESSAGEクライアントはネクストホップの先のアップストリー ムデバイスのMTUを知っていることはまずないので、MTUに基づく制限は あまり有用ではない。 UACは、あるURIに対してペンディング中の以前のダイアログ外トランザクショ ンがある場合は、そのURIに対してダイアログ外の新規MESSAGEトランザクショ ンを開始してはならない[MUST NOT]。同様に、UACは、ダイアログ内で重複 MESSAGEトランザクションを開始するべきではなく[SHOULD NOT]、そのダイア ログのroute setがすべてのホップにおいて輻輳制御されたトランスポートを 使用しているのでなければそれを行ってはならない[MUST NOT]。 重複MESSAGEリクエストの禁止は、ある程度、輻輳が起こっても安全な動 作を提供する。リクエストとそれに対応する応答は、UACとUASのあいだ のすべてのパスを通過しなければならない。このために要求される時間 はネットワークが混雑すると増加する。これは、新規MESSAGEリクエスト を同じ送信先に送ることを遅らせる、適応メカニズムを提供する。 ページャーモデルのMESSAGEリクエストに対しては暫定応答が許可されるべき でないということが提案されている。しかしながら、多くのプロキシサーバ ーはMESSAGEメソッドを知らないだろうから、MESSAGEに対して特別な扱いを 求めることは不可能である。従って、MESSAGEリクエストは、SIP仕様に述べ られているように、他のすべての非INVITEメソッドと同じ暫定応答処理を受 ける。 9. メソッドの定義 Tこの仕様は新しいSIPメソッドMESSAGEを定義する。このメソッドのBNF表記は 以下のようである。 MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGEは大文字 他のすべてのメソッドと同様、MESSAGEメソッドの名称は大文字小文字を区別 する。 表1と表2は、MESSAGEリクエストと応答に使用されるヘッダーフィールドを定 義するための新たな列を追加した、SIP(参考文献[1])の表2と表3の拡張であ る。 Campbell, et. al. Standards Track [Page 9] RFC 3428 SIP Message Extension December 2002 Header Field where proxy MESSAGE __________________________________________ Accept R - Accept 2xx - Accept 415 m* Accept-Encoding R - Accept-Encoding 2xx - Accept-Encoding 415 m* Accept-Language R - Accept-Language 2xx - Accept-Language 415 m* Alert-Info R - Alert-Info 180 - Allow R o Allow 2xx o Allow r o Allow 405 m Authentication-Info 2xx o Authorization R o Call-ID c r m Call-Info ar o Contact R - Contact 1xx - Contact 2xx - Contact 3xx o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length ar t Content-Type * CSeq c r m Date a o Error-Info 300-699 a o Expires o From c r m In-Reply-To R o Max-Forwards R amr m Organization ar o 表1:ヘッダーフィールドのまとめ(A〜O) Campbell, et. al. Standards Track [Page 10] RFC 3428 SIP Message Extension December 2002 Header Field where proxy MESSAGE __________________________________________ Priority R ar o Proxy-Authenticate 407 ar m Proxy-Authenticate 401 ar o Proxy-Authorization R dr o Proxy-Require R ar o Record-Route ar - Reply-To o Require ar c Retry-After 404,413,480,486 o 500,503 o 600,603 o Route R adr o Server r o Subject R o Timestamp o To c(1) r m Unsupported 420 o User-Agent o Via R amr m Via rc dr m Warning r o WWW-Authenticate 401 ar m WWW-Authenticate 407 ar o (1): 可能であればタグを追加したうえでコピーされる 表2:ヘッダーフィールドのまとめ(P〜Z) MESSAGEリクエストは、コンテンツを特定するための標準的なMIMEヘッダーフ ィールドを用いて、ボディを含んでもよい[MAY]。 10. メッセージの例 表1にメッセージフローの例を示した。メッセージフローは、1つのプロキシ を経由して、同じdomainドメインにいるUser 1からUser 2へ送られた、最初 のIMを示している。 Campbell, et. al. Standards Track [Page 11] RFC 3428 SIP Message Extension December 2002 | F1 MESSAGE | | |--------------------> | F2 MESSAGE | | | ----------------------->| | | | | | F3 200 OK | | | <-----------------------| | F4 200 OK | | |<-------------------- | | | | | | | | | | | User 1 Proxy User 2 図1:メッセージフローの例 メッセージF1は以下のようである。 MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. User 1はdomain.comのサーバーにこのメッセージを転送する(forward)。プロ キシはこのリクエストを受信し、それがdomain.comのサーバーであることを認 識する。それはデータベース(登録によって構築された)中でUser 2をルックア ップし、sip:user2@domain.comからsip:user2@user2pc.domain.comへのバイン ディングを見つける。それはリクエストをUser 2に転送する(forward)。最終 的なメッセージF2は以下のようになる。 MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 Max-Forwards: 69 From: sip:user1@domain.com;tag=49394 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Campbell, et. al. Standards Track [Page 12] RFC 3428 SIP Message Extension December 2002 Watson, come here. メッセージがUser 2に受信され、表示され、応答F3が生成されて、プロキシ に送られる。 SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds; received=192.0.2.1 Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse; received=1.2.3.4 From: sip:user1@domain.com;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0 ほとんどのフィールドは、応答で単純に返されるということに注意すること。 プロキシはこの応答を受け取り、先頭のViaを取り去り、次のVia中のアドレス user1pc.domain.comに結果としてのメッセージF4を転送する(forward)。 SIP/2.0 200 OK Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 From: sip:user1@domain.com;;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0 11. セキュリティの考慮 通常の使用では、ほとんどのSIPリクエストはコミュニケーションセッション を確立して修正するために使用される。参加者間の実際のコミュニケーション は、SIPリクエストではなくメディアセッションで行われる。MESSAGEメソッド はこの前提を変更する。MESSAGEリクエストは通常、ペイロードで参加者間の 実際のコミュニケーションを伝える。これは、MESSAGEリクエストが他の多く のSIPリクエストに比べてセキュリティに対するより多くの必要性があること を示す。特に、MESSAGEリクエストをサポートするUAは、エンドツーエンドの 認証、ボディの完全性、およびボディの機密性メカニズムをサポートしなけれ ばならない[MUST]。 11.1 アウトバウンド認証 ローカルプロキシがアウトバウンドメッセージの伝送に使用されるときは、 RFC 3261で規定されるように、プロキシ認証が推奨される[RECOMMENDED]。こ れは発信元のアイデンティティーを確認するのに便利で、発信元のネットワー クでのスプーフィングやスパミングを防止する。 Campbell, et. al. Standards Track [Page 13] RFC 3428 SIP Message Extension December 2002 11.2 SIPS URI SIPS URIメカニズム(参考文献[1])は、すべてのホップが安全なコネクション 上で起こらなければならないことを明言する。これは、ある程度の完全性とプ ライバシー保護を提供する。しかしながら、これはユーザーに、リクエストパ ス中の各プロキシが正常に動作する(すなわち、各プロキシがSIPS URIをルー ティングするためのルールを破らない)と信じることを要求する。また、暗号 化されていないすべてのボディは、プロキシに完全に露出される。 さらに、フォークを行うプロキシがあると、別のエンドポイントにそのUACに ついての知識なしにMESSAGEリクエストが配送されることが可能になる。ホッ プバイホップの防御のみが使用されている場合、ユーザーはチェーン中のすべ てのプロキシが未認可の送信先にリクエストをフォークしないことを信頼しな ければならない。 11.3 エンドツーエンドの防御 目標が、上述の懸念事項の改善である場合、MESSAGEボディはS/MIMEで安全に されなければならない[MUST]。将来に規定され、MESSAGEメソッドで運ばれる ことになるボディが、エンドツーエンドのセキュリティを提供するための別の 手段を持つ場合、その仕様は使用法について記述しなければならない[MUST]。 SIP MESSAGEエンドポイントは、暗号化(CMS EnvelopeData)およびS/MIME署名 (CMS SignedData)に対応しなければならない[MUST]。 S/MIMEアルゴリズムはRFC 3369(参考文献 [4])で規定されている。AES(参考文 献[10])アルゴリズムが優先されるべきであるが、これはAESが多くのプラット フォームの性能に対し最適なためである。しかし、本文書の執筆時点では、こ れに関するIETFの仕様はいまだに不完全である。 11.4 リプレイ防止 古いSIPリクエストの再実行(replay)を防止するために、すべての署名済み MESSAGEリクエスト/応答は、メッセージ署名で保護されたDateヘッダーフィー ルドを含まなければならない[MUST]。過去数分より古い日時、あるいは今より 数分以上あとの日時を持つどのようなメッセージも、そのメッセージが繰り返 し同じソースから到着する(この場合、応答を送信せずにそのメッセージを廃 棄してもよい[MAY])のでなければ、400(Incorrect Date or Time)メッセージ で返答するべきである[SHOULD]。明白なことだが、このreplay攻撃防止メカニ ズムは、クロックを持たないデバイスでは動作しない。 古いDateヘッダーフィールドがノーマルである場合があるということに注意す ること。例えば、受信者がオフラインのあいだ、MESSAGEリクエストがstore and forwardサーバーに保管されていたのかもしれない。受信者が戻ってきた とき、そのサーバーがメッセージを転送した(forward)のかもしれない。メッ セージの最終的な受信は、それがオリジナルに送信された時間の後に起こり得 る。 Campbell, et. al. Standards Track [Page 14] RFC 3428 SIP Message Extension December 2002 UASが、(おそらくTLSコネクション上で)既知のstore and forwardサーバーか ら来たことを確認できる古いメッセージを受信する場合、通常どおりそのメッ セージを受け入れることは理にかなっている。また、オフラインのすぐ後に1 つ以上のメッセージが到着する場合、UASはそのメッセージを受け入れてもよ い[MAY]が、メッセージがreplayされた危険性があることをユーザーに警告す るべきである[SHOULD]。 11.5 message/cpimボディの使用 message/cpim形式(参考文献[7])は、S/MIMEに対して、メッセージペイロード 自体の保護に加えてメタデータの保護も可能にする。多くの場合において、こ のメタデータは余分なSIPヘッダーフィールドを持つ。それでもmessage/cpim は、メタデータの保護がプロトコルのバウンダリ全体に及ぶことができるとい う価値を加える。例えば、署名されたmessage/cpimボディは、たとえメッセー ジがゲートウェイを超えてSIPヘッダーフィールドを理解しない別のCPIM準拠 のインスタントメッセージサービスに行ったとしても、message/cpimのFromヘ ッダーフィールドを使用した送信者認証を提供することができる。 12. IANA条項 本仕様は、以下の情報で、 http://www.iana.org/assignments/sip-parameters/Method レジストリに、MESSAGEメソッドを登録する。 MESSAGE [RFC3428] 13. 貢献してくれた人々 以下の人々がこの著作に対して重要な貢献をしてくれた。 Bernard Aboba Microsoft Steve Donovan dynamicsoft Jonathan Lennox Columbia University Dave Oran Cisco Robert Sparks dynamicsoft Dean Willis dynamicsoft 14. 謝辞 SIPのためのIMのコンセプトに賛同をいただき、この著作をサポートしてくれ たことに対して、また、有益なコメントと見識に対して、下記の人々に感謝し たい。 Jon Peterson NeuStar Sean Olson Microsoft Adam Roach dynamicsoft Billy Biggs University of Waterloo Campbell, et. al. Standards Track [Page 15] RFC 3428 SIP Message Extension December 2002 Stuart Barkley UUNet Mauricio Arango SUN Richard Shockey NeuStar Jorgen Bjorker Hotsip Henry Sinnreich MCI Worldcom Ronald Akers Motorola Torrey Searle Indigo Software Rohan Mahy Cisco Christian Groves Ericsson Allison Mankin ISI Tan Ya-Ching Siemens 15. 規範となる参考文献 [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] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Bradner, S., "Keywords for Use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 16. 有益な参考文献 [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", Work in Progress. [8] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Address Resolution for Instant Messaging and Presence", Work in Progress. [9] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and Callee Capabilities", Work in Progress. [10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", Work in Progress. Campbell, et. al. Standards Track [Page 16] RFC 3428 SIP Message Extension December 2002 [11] DellaFera, C., Eichin, M., French, R., Jedlinski, D., Kohl, J. and W. Sommerfeld, "The Zephyr notification service", in USENIX Winter Conference (Dallas, Texas), Feb. 1988. 17. 著者の連絡先 Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: bcampbell@dynamicsoft.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: schulzrinne@cs.columbia.edu Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: huitema@microsoft.com David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: dgurle@microsoft.com Campbell, et. al. Standards Track [Page 17] RFC 3428 SIP Message Extension December 2002 18. 完全な著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2005年 --------------------------------------------------------------------------- Campbell, et. al. Standards Track [Page 18]