Network Working Group H. Schulzrinne Request for Comments: 3994 Columbia U. Category: Standards Track January 2005 インスタントメッセージのメッセージ作成の表示 Indication of Message Composition for Instant Messaging 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定するものであり、改善のための議論や提案を依頼す るものである。標準化の段階や、プロトコルの位置付けについては、最新版 の"Internet Official Protocol Standards" (STD 1)を参照されたい。この 文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2005). 概要 インスタントメッセージ(IM)システムでは、IM対話時に相手側がメッセージ を作成中であるかどうか(たとえば、メッセージの入力や音声メッセージの 記録など)がわかると便利である。本文書は、作成するメッセージに関する 情報を伝達する、新規のステータスメッセージのコンテンツタイプとXML名 前空間を定義する。このステータスメッセージは、テキスト、音声、ビデオ など、任意のタイプのメッセージが作成されていることを示す。ステータス メッセージは、インスタントメッセージ自体と同様の方法で、インスタント メッセージの受信側に配信される。 Schulzrinne Standards Track [Page 1] RFC 3994 isComposing January 2005 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語と規約 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. メッセージコンポーザの動作 . . . . . . . . . . . . . . . 4 3.3. ステータスメッセージ受信側の動作 . . . . . . . . . . . . 5 3.4. メッセージのコンテンツ . . . . . . . . . . . . . . . . . 6 3.5. 追加のステータス情報: . . . . . . . . . . . . . . . . . 6 4. ステータスメッセージの使用 . . . . . . . . . . . . . . . . . . 7 5. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. XMLドキュメントの書式 . . . . . . . . . . . . . . . . . . . . 8 6.1. XMLスキーマ . . . . . . . . . . . . . . . . . . . . . . 9 7. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 9 8. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. 「application/im-iscomposing+xml」の コンテンツタイプ登録 . . . . . . . . . . . . . . . . . . 10 8.2. 「urn:ietf:params:xml:ns:im-iscomposing」の URN下位名前空間登録 . . . . . . . . . . . . . . . . . . 11 8.3. スキーマ登録 . . . . . . . . . . . . . . . . . . . . . . 11 9. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 12 10.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 12 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 13 1. はじめに 定義では、インスタントメッセージ(IM)はメッセージベースである。ユー ザーがメッセージを作成する方法は、たとえば、入力、発声、ビデオクリッ プの録画などである。このメッセージは1人以上の受信者に送信される。 電子メールとは異なり、インスタントメッセージは対話的なので、相手側の 応答を待機する場合が多い。応答がない場合、インスタントメッセージの対 話に参加しているユーザーは、対話相手が席を外したか、自分が入力する順 番であると勘違いして、2つのメッセージを送信してしまう可能性がある。 このような不確実性を回避するために、多くの商用インスタントメッセージ システムには、相手側がメッセージを入力しているときに直ちに「入力中」 と表示する機能がある。本文書では、この表示を一般化したバージョンであ るisComposingというステータスメッセージについて説明する。 詳細についてはセクション3で説明するが、ステータスメッセージはメッセー ジ自体と同じ方法でインスタントメッセージ受信者に配信される。 isComposingステータスメッセージは、テキストだけでなく、任意のメディ アタイプの作成について宣言することができる。たとえば、音声やビデオク Schulzrinne Standards Track [Page 2] RFC 3994 isComposing January 2005 リップの記録中である場合に使用することもできる。さらに、将来的には他 のインスタントメッセージユーザーのステータスを伝達できるように拡張さ れる可能性がある。以降、このようなメッセージを簡潔に「ステータスメッ セージ」と呼ぶ。 ステータスメッセージはXMLの形で記述され(XMLスキーマのインスタンスは セクション6で定義)、application/im-iscomposing+xmlコンテンツタイプと 呼ばれる。 このステータスメッセージは、無音抑制の双方向音声対話で伝送される雑 音(comfort noise)パケットと似ている部分があると考えることができる。 PIDF [6]など、プレゼンスのイベントと拡張も考慮されたが、多数の短 所がある。いずれも明示的で定期的なサブスクリプションが必要なため、 オーバーヘッドが増える。ページモードの配信では、適切なユーザー エージェントとメッセージ群にサブスクライブすることは容易ではない 場合もある。複数のインスタントメッセージシステムを解釈する場合、 帯域内のメッセージベースの仕組みを利用すると容易になる。 本文書に記載している仕組みは、[7]の要件を満たすことが目的である。 2. 用語と規約 本文書は、IMPPモデル文書[1]で定義されている語彙を利用している。本文 書にある<クローズド>(CLOSED)、<インスタントメッセージ>(INSTANT MESSAGE)、<オープン>(OPEN)、<プレゼンスサービス>(PRESENCE SERVICE)、 <プレゼンティティ>(PRESENTITY)、<ウォッチャー>(WATCHER、および<ウォッ チャーユーザーエージェント>(WATCHER USER AGENT)などの語の用法は、RFC 2778で定義されているものと同じである。本文書では、キーワード 「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119[2]のBCP 14に記載 されるとおりに解釈されるべきである。 本文書は、2種類のメッセージについて議論する。つまり、インスタントメッ セージ対話に参加する2人以上のユーザー間で実際のコンテンツを伝達する インスタントメッセージ(IM)、および本文書で説明するステータスメッセー ジである。ステータスメッセージは、現在の作成ステータスを対話に参加す る相手に示す。この2種類のメッセージを本文書では「コンテンツメッセー ジ」と「ステータスメッセージ」と呼ぶ。 3. 説明 3.1. 概要 本文書では、インスタントメッセージシステムのユーザーを「アイドル」 と「アクティブ」という2つの状態のいずれかに限定したモデルを使用する。 メッセージの作成開始前、メッセージの送信後のどちらも、デフォルトで ユーザーは「アイドル」状態にある。 Schulzrinne Standards Track [Page 3] RFC 3994 isComposing January 2005 3.2. メッセージコンポーザの動作 インスタントメッセージのユーザーエージェントがコンテンツメッセージを 作成中の場合にのみ、現在の状態を示すステータスメッセージが生成され る。ユーザーがコンテンツメッセージ(実際のインスタントメッセージ)の作 成を開始すると、状態は「アクティブ」になり、「アクティブ」を示す 要素を含んだisComposingステータスメッセージが、作成中のコンテ ンツメッセージの受信者に送信される。ユーザーがインスタントメッセージ のコンテンツを作成し続けている限り、ユーザーの状態は「アクティブ」の ままである。 送信側タイマーには2つある。アクティブ状態の更新間隔とアイドルのタイ ムアウト間隔である。 アクティブ状態の更新間隔は、メッセージの作成者が「アクティブ」状態の 間に「アクティブ」状態のメッセージが送信される頻度を示す。この更新間 隔は作成側ユーザーが選択し、ステータスメッセージの要素に整数 の秒数で示される。isComposingメッセージの送信ごとにタイマーがリセット される。間隔は60秒以上にすべきではない[SHOULD]。メッセージコンポーザ は、アクティブ状態の更新メッセージをまったく送信しなくてもよい[MAY]。 送信しない場合、更新間隔を省略する。その結果、受信者は120秒後にアイド ルになると仮定する(ほとんどの場合、コンテンツメッセージはそのときに 送信される)。「アイドル」状態には更新メッセージは送信されない。 アクティブ状態の交信メカニズムでは、コンテンツメッセージが完了す る前にユーザーがログオフした場合、またはアプリケーションがクラッ シュする場合について処理している。 アイドルのタイムアウトに設定した間隔よりも長い間、ユーザーがメッセー ジの作成を停止した場合、状態は「アイドル」に移行し、「アイドル」の ステータスメッセージが送信される。ユーザーが「アイドル」状態時にメッ セージの作成を開始すると、状態は「アクティブ」に移行し、対応するス テータスメッセージが送信される。ユーザーが設定しない場合、アイドルの タイムアウト値は15秒というデフォルト値にすべきである[SHOULD]。 アイドルのしきい値が期限切れになる前にコンテンツメッセージが送信され る場合、「アイドル」状態の表示は不要である。そのため、ほとんどの場 合、各コンテンツメッセージに付き生成されるステータスメッセージは1つ のみである。どの場合でも、メッセージレートは1つの更新しきい値間隔に つき1つのステータスメッセージに限定される。 Schulzrinne Standards Track [Page 4] RFC 3994 isComposing January 2005 図1に状態の遷移を示す。 +-------------+ |+-----------+| || || +------>| idle |<--------+ | || || | | |+-----------+| | | +------+------+ | content | | | idle timeout msg. sent | | composing | w/o activity ----------- | | ------------- | ------------------ -- | | "active" msg. | "idle" status msg. | | | | +------V------+ | | | | | | | | | | | | | +------+ active +--------+ | | | |------+ +------^------+ | refresh timeout | | -------------------- | | "active" status msg. +-------------+ 図1: 送信側の状態図 3.3. ステータスメッセージ受信側の動作 ステータスメッセージの受信者は、ステータスメッセージを使用してコンテ ンツメッセージ送信者の状態を判断する。最新の「アクティブ」ステータス メッセージに値が含まれる場合、更新のタイムアウトはその値に 設定される。含まれない場合、タイムアウトは120秒である。以下に示す3つ の条件で、受信側の状態は「アクティブ」から「アイドル」に移行する。 1. ステータスが「アイドル」のステータスメッセージを受信する。 2. コンテンツメッセージを受信する。 3. 更新間隔が期限切れになる。 受信者は、更新間隔に関係なく、「アクティブ」な状態の複数の連続す るisComposingメッセージを処理できなければならない[MUST]。 Schulzrinne Standards Track [Page 5] RFC 3994 isComposing January 2005 図2に状態の遷移を示す。 +-------------+ |+-----------+| || || +------>| idle |<------+ | || || | | |+-----------+| | | +------+------+ | | | | "idle" recd. | |"active" msg.| refresh timeout or content recd. | | | or 120s | | | | +------V------+ | | | | | | | | | | | | | +------+ active +------+ | | | | +-------------+ 図2: 受信側の状態図 3.4. メッセージのコンテンツ 前述の議論をまとめるために、メッセージコンテンツについて簡単に説明 する。本文書は規範ではない。規範のメッセージフォーマットについては スキーマ(セクション6)を参照のこと。 メッセージは要素と、コンポーザの状態(アイドルまたはアク ティブ)を示す必須の要素から構成される。 さらに、3つのオプション要素がある。最後にアクティブだった時間を示す 、作成されたメッセージの種類を示す、コンポー ザから受信者が更新した後の時間間隔を示すである。詳細につ いて、以下のセクションで説明する。 3.5. 追加のステータス情報: ステータスメッセージには、作成処理の詳細について指定する追加のオプ ション要素が含まれる。いずれの要素も、「アクティブ」および「アイド ル」の状態メッセージの両方に出現する。 Schulzrinne Standards Track [Page 6] RFC 3994 isComposing January 2005 オプションの要素には、ユーザーが最後にないようを追加また は編集したときの絶対時間を記述する。 オプションの要素は、メッセージ端末が現在作成しているメ ディアの種類を示す。「audio」や「text」などの単なるメディアタイプ、 または「text/html」などのメディアタイプおよびサブタイプのいずれかが 含まれる。ユーザーにとっては、実際のコンテンツメッセージに含まれるコ ンテンツを示す内容の保証ではないが、ヒントとして理解される。人間の受 信者は、可能性の高いメッセージ形式に対して備えることができる。 メッセージ作成についてさらに記述するために、XMLスキーマまたは可能な 状態名のセットを将来的な文書で拡張される可能性がある。 本仕様を拡張なしで実装するステータスメッセージの受信者は、「アイド ル」と「アクティブ」以外の状態トークンを「アイドル」と扱わなければな らない[MUST]。追加の要素では、独自の名前空間を使用しなければならな い[MUST]。また、受信者がその拡張を安全に無視できるように設計しなけれ ばならない[MUST]。 本文書で定義された名前空間に要素を追加することは許可されていない。 isComposingステータスメッセージは、CPIMメッセージ[3]で伝達してもよ い[MAY]。 カンファレンスサーバーがメッセージをリレーする場合、CPIMメッセー ジは元のコンポーザのIDを維持するため、このようなラッパーが特に有 効である。 4. ステータスメッセージの使用 isComposingステータスメッセージは、ページモードまたはセッションモー ドのいずれかに使用することができるが、セッションモードの方が自然に適 合する。セッションモードでは、ステータスメッセージはメッセージスト リームの一部として送信される。セッションモードの使用は、そのストリー ム内の他のメディアタイプと同様に、セッションモードプロトコルに関する 詳細と共にネゴシエートされる。 セッションモードのメッセージングストリーム内でステータスメッセージを 送信する方法には少なくとも3つの利点がある。第1に、適切な順序を保ち、 実際に作成されたコンテンツメッセージと同期を取ることができる。メッ セージの配信順を保証するメッセージングシステムでは、このアプローチに よって、2つの配信メカニズム間のメッセージ順序変更のために、実際のメッ セージが配信された後に受信者側にアクティブと表示されることを防ぐ。 第2に、エンドツーエンドのセキュリティをメッセージに適用することがで きる。 第3に、セッションネゴシエーションメカニズムを使用して、いつでもオン/ オフを切り替えることができ、さらに同時に1方向での使用をネゴシエート することもできる。 Schulzrinne Standards Track [Page 7] RFC 3994 isComposing January 2005 ページモードでの使用方法も単純である。ステータスメッセージは、ページ モードメッセージのボディとして伝達される。SIPベースのIMでは、ステー タスの表示を含むMESSAGEリクエストへの応答として受信者が415ステータ スコード(Unsupported Media Type)を返した場合、コンポーザはステータス メッセージの送信を中止しなければならない[MUST]。 送信者は、作成中の実際のコンテンツが到達する前に、ステータスメッセー ジが配信されるように確保することはできない。ただし、SIPページモード は、1つの未承認メッセージに制限されるため、配信順序が変わる可能性は 低いが、プロキシが関与する場合は可能性がある。 5. 例 active text/plain 90 idle 2003-01-27T10:43:00Z audio 6. XMLドキュメントの書式 isComposingドキュメントは、XMLドキュメントとして、整形済みでなければ ならず[MUST]、また有効であるべき[SHOULD]である。isComposingドキュメ ントは、XML 1.0に基づかなければならず[MUST]、UTF-8を使用してエンコー ドされなければならない[MUST]。本仕様は、isComposingドキュメントを識別 するためにXML名前空間を利用する。この用途で定義される要素用の名前空 間URIはURNであり、名前空間識別子「ietf」を使用している。このURNを以 下に示す。 urn:ietf:params:xml:ns:im-iscomposing Schulzrinne Standards Track [Page 8] RFC 3994 isComposing January 2005 6.1. XMLスキーマ 7. セキュリティの考慮事項 isComposingの表示によって、メッセージを作成するエンティティの動作につ いて詳細なビューが実現するため、元のメッセージ受信者のみがisComposing の表示を受信するように、特に慎重な機密保護を行う価値がある。 IMプロトコル自体を使用してステータスメッセージが伝達されるため、基礎 となるIMプロトコルのセキュリティの考慮事項がすべてisComposingステー タスメッセージにも適用される。 実際の対話が通信ユーザー間で確立する前に、isComposingステータスメッ セージの送信時に、考えられるプライバシ問題がある。ユーザーが後で メッセージを破棄するときにも、ステータスメッセージが送信される場合が ある。ページモードでのisComposingの表示は、以前のメッセージへの返信 としてメッセージが作成されるときにのみ送信することが推奨される [RECOMMENDED]。本文書は、メッセージがページモードで以前のメッセージ への応答だが時間が経過しているか、ユーザーインターフェースの動作をヒ ントとして使用するかを実装が検出する方法については説明しない。 Schulzrinne Standards Track [Page 9] RFC 3994 isComposing January 2005 8. IANA条項 8.1. 「application/im-iscomposing+xml」のコンテンツタイプ登録 宛先: ietf-types@iana.org 件名: MIMEメディアタイプ「application/im-iscomposing+xml」の登録 MIMEメディアタイプ名: application MIMEサブタイプ名: im-iscomposing+xml 必須のパラメータ: なし オプションのパラメータ: 文字セットは囲まれるXMLの文字エンコードを示 す。デフォルトはUTF-8。 エンコーディングの考慮事項: 使用される文字エンコーディングに応じて、 8-bit文字を採用できるXMLを使用すること。RFC 3023[4]のセクション 3.2を参照のこと。 セキュリティの考慮事項: このコンテンツタイプは、現在のユーザー動作に 関する情報(プライベート情報と考えることができる)を伝達するために 設計されている。この情報の公開には、あらかじめ適切な注意を払って 制限を適用すべきである。 相互運用性の考慮事項: このコンテンツタイプは、作成動作情報を交換する 共通形式として機能する。 公開されている仕様: RFC 3994 このメディアタイプを使用するアプリケーション: インスタントメッセージ システム。 補足情報: なし より詳しい情報についての連絡先窓口とe-mailアドレス: Henning Schulzrinne (hgs@cs.columbia.edu) 意図される用法: 限定された使用法 作者/変更の管理者: 本仕様は、IETFのSIMPLEワーキンググループの研究項 目であり、メーリングリストのアドレスはである。 その他の情報: このメディアタイプは、application/xml (RFC 3023 [4])を 専門化したものであり、RFC 3023に記載されている多くの事項は、 application/im-iscomposing+xmlにも適用される。 Schulzrinne Standards Track [Page 10] RFC 3994 isComposing January 2005 8.2. 「urn:ietf:params:xml:ns:im-iscomposing」のURN下位名前空間登録 URI: urn:ietf:params:xml:ns:im-iscomposing 説明: これはRFC 3994で定義されたXML要素のXML名前空間であり、インスタ ントメッセージクライアントはapplication/im-iscomposing+xmlコンテ ンツタイプを使用して作成動作を記述することができる。 登録の連絡先: SIMPLEワーキンググループ(simple@ietf.org)、Henning Schulzrinne (hgs@cs.columbia.edu) XML: BEGIN Is-composing Indication for Instant Messaging

Namespace for SIMPLE iscomposing extension

urn:ietf:params:xml:ns:im-composing

See RFC3994.

END 8.3. スキーマ登録 このセクションでは、[5]の手順に従って、新規のXMLスキーマを登録する。 URI: urn:ietf:params:xml:schema:im-composing 登録の連絡先: SIMPLEワーキンググループ(simple@ietf.org)、Henning Schulzrinne (hgs@cs.columbia.edu) このスキーマのXMLは、セクション6.1の主な内容として説明されている。 9. 謝辞 Ben Campbell、Miguel Garcia、Scott Hollenbeck、Christian Jansson、 Cullen Jennings、Hisham Khartabil、Allison Mankin、Aki Niemi、 Jonathan Rosenberg、Xiaotao Wuの各氏から有益なコメントをいただいた。 Schulzrinne Standards Track [Page 11] RFC 3994 isComposing January 2005 10. 参考文献 10.1. 規範となる参考文献 [1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 10.2. 有益な参考文献 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [7] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", Work in Progress, February 2004. 著者の連絡先 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Schulzrinne Standards Track [Page 12] RFC 3994 isComposing January 2005 完全な著作権表示 Copyright (C) The Internet Society (2005). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関するIETFの手続きの情報は、BCP 78および BCP 79に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 については、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2006年 ----------------------------------------------------------------------- Schulzrinne Standards Track [Page 13]