Network Working Group H. Schulzrinne
Request for Comments: 3994 Columbia U.
Category: Standards Track January 2005
Indication of Message Composition for Instant Messaging
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves.
インスタントメッセージング（IM）システムでは、相手がメッセージを作成しているかどうかをIMの会話中に知っておくと便利です。例えば、入力または音声メッセージを記録します。この文書では、構成されているメッセージについての情報を伝える新しいステータスメッセージのコンテンツタイプとXML名前空間を定義します。ステータスメッセージは、テキスト、音声、またはビデオを含む任意のタイプのメッセージ、の組成を示すことができます。ステータスメッセージは、インスタントメッセージ自体と同様にインスタントメッセージング受信者に配信されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Message Composer Behavior . . . . . . . . . . . . . . . 4
3.3. Status Message Receiver Behavior . . . . . . . . . . . . 5
3.4. Message Content . . . . . . . . . . . . . . . . . . . . 6
3.5. Additional Status Information . . . . . . . . . . . . . 6
4. Using the Status Message . . . . . . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. XML Document Format . . . . . . . . . . . . . . . . . . . . . 8
6.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Content-Type Registration for
'application/im-iscomposing+xml' . . . . . . . . . . . . 10
8.2. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:im-iscomposing' . . . . . . . . 11
8.3. Schema Registration . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
By definition, instant messaging (IM) is message based: A user composes a message by, for example, typing, speaking, or recording a video clip. This message is then sent to one or more recipients. Unlike email, instant messaging is often conversational, so the other party is waiting for a response. If no response is forthcoming, a participant in an instant messaging conversation may erroneously assume either that the communication partner has left or that it is her turn to type again, leading to two messages "crossing on the wire".
ユーザは、例えば、話す、又はビデオクリップの記録、入力によってメッセージを構成：定義により、インスタントメッセージング（IM）は、メッセージベースです。このメッセージは、1人のまたは複数の受信者に送信されます。電子メールとは異なり、インスタントメッセージングは、しばしば会話なので、相手が応答を待っています。応答が迫っていない場合は、インスタントメッセージングの会話の中で参加者が誤っていずれかの通信相手が残っているか、二つのメッセージ「ワイヤ上の交差点」につながる、再び入力するために彼女のターンであるとことを仮定してもよいです。
To avoid this uncertainty, a number of commercial instant messaging systems feature an "is-typing" indication sent as soon as one party starts typing a message. In this document, we describe a generalized version of this indication, called the isComposing status message. As described in Section 3 in more detail, a status message is delivered to the instant message recipient in the same manner as are the messages themselves. The isComposing status messages can announce the composition of any media type, not just text. For example, it might be used if somebody is recording an audio or video clip. In addition, it can be extended to convey other instant messaging user states in the future. Below, we will call these messages "status messages" for brevity.
この不確実性を回避するために、商用のインスタントメッセージングシステムの数は、一方の当事者がメッセージを入力し始めるとすぐに送信される「あるタイピング」の表示を備えています。この文書では、我々はこの表示の一般的なバージョンを記述し、isComposingステータスメッセージと呼ばれます。より詳細には、セクション3で説明したようにメッセージ自体であるように、ステータスメッセージは、同様にインスタントメッセージの受信者に配信されます。 isComposingステータスメッセージは、任意のメディアタイプだけでなく、テキストの構図を発表することができます。誰かが、オーディオやビデオクリップを記録している場合たとえば、それが使用される可能性があります。また、将来的には他のインスタントメッセージングユーザーの状態を伝えるために拡張することができます。以下では、簡潔にするため、これらのメッセージ「ステータスメッセージ」と呼びます。
The status messages are carried as XML, as instances of the XML schema defined in Section 6, and labeled as an application/im-iscomposing+xml content type.
ステータスメッセージは、アプリケーション/ IM-iscomposing + XMLコンテンツタイプとしてXMLスキーマのインスタンスはセクション6で定義されるように、XMLとして運ばれ、標識されています。
These status messages can be considered somewhat analogous to the comfort noise packets that are transmitted in silence-suppressed interactive voice conversations.
これらのステータスメッセージが無音抑圧インタラクティブ音声会話で送信されるコンフォートノイズパケットに幾分類似したと考えることができます。
Events and extensions to presence, such as PIDF [6], were also considered but have a number of disadvantages. They add more overhead, as an explicit and periodic subscription is required. For page-mode delivery, subscribing to the right user agent and set of messages may not be easy. An in-band, message-based mechanism is also easier to translate across heterogeneous instant messaging systems.
このようPIDFとして存在するイベントや拡張は、[6]、また考えられますが、多くの欠点を持っていました。明示的および定期的なサブスクリプションが必要とされるように彼らは、より多くのオーバーヘッドを追加します。ページモードの送達のために、メッセージの右のユーザエージェントとセットに加入することは容易ではないかもしれません。インバンド、メッセージベースのメカニズムは、異種のインスタント・メッセージング・システム間で変換する方が簡単です。
The mechanism described here aims to satisfy the requirements in [7].
ここで説明するメカニズムは、[7]で要件を満たすことを目指しています。
This memo makes use of the vocabulary defined in the IMPP Model document [1]. In this memo, terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT are used with the same meaning defined therein. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
このメモはIMPPモデル文書[1]で定義された語彙を使用しています。このメモでは、そのようなCLOSED、インスタントメッセージなどの用語は、OPEN、プレゼンスサービス、PRESENTITYウォッチャ、及びウォッチャーユーザーエージェントは、その中に定義したのと同じ意味で使用されています。キーワード必要があり、必須、、、はならないSHOULD NOTこの文書でもよく、推奨、およびオプションのMUSTはBCP 14、RFC 2119に記載されているように[2]に解釈されるべきです。
This document discusses two kinds of messages; namely, the instant message (IM) conveying actual content between two or more users engaged in an instant messaging conversation, and the status message, described in this document, which indicates the current composing status to the other participants in a conversation. We use the terms "content message" and "status message" for these two message types.
この文書では、2種類のメッセージについて説明します。すなわち、会話の他の参加者に現在の作曲の状態を示し、この文書に記載されたインスタントメッセージ会話に従事して複数のユーザ間の実際のコンテンツを搬送するインスタントメッセージ（IM）、およびステータスメッセージ。我々は、これら2つのメッセージタイプのための「コンテンツメッセージ」と「ステータスメッセージ」という用語を使用します。
We model the user of an instant messaging system as being in one of several states, in this document limited to "idle" and "active". By default, the user is in "idle" state, both before starting to compose a message and after sending it.
私たちは、「アイドル」と「アクティブ」に限られ、この文書では、いくつかの州の一つであるとインスタント・メッセージング・システムのユーザーをモデル化します。デフォルトでは、ユーザーがメッセージを作成するために開始する前に、それを送信した後に、両方の、「アイドル」状態になっています。
Only the instant messaging user agent actively composing a content message generates status messages indicating the current state. When the user starts composing a content message (the actual instant message), the state becomes "active", and an isComposing status message containing a <state> element indicating "active" is sent to the recipient of the content message being composed. As long as the user continues to produce instant message content, the user remains in state "active".
積極的にコンテンツメッセージを構成する唯一のインスタント・メッセージング・ユーザエージェントは現在の状態を示すステータスメッセージを生成します。ユーザがコンテンツメッセージ（実際のインスタントメッセージ）を構成開始すると、状態は「アクティブ」になり、<状態>要素を含むisComposingステータスメッセージは、「アクティブ」を示す構成されているコンテンツ・メッセージの受信者に送信されます。限り、ユーザはインスタントメッセージの内容を生成し続けるように、ユーザは、「アクティブ」状態に留まります。
There are two sender timers: the active-state refresh interval, and the idle time-out interval.
アクティブ状態のリフレッシュ間隔、およびアイドルタイムアウト間隔：2つの送信者のタイマーがあります。
The active-state refresh interval determines how often "active" state messages are sent while the composer remains in "active" state. The interval is chosen by the composing user and indicated in the <refresh> element in the status message, expressed in integer seconds. Each transmission of the isComposing message resets the timer. The interval SHOULD be no shorter than 60 seconds. A message composer MAY decide not to send active-state refresh messages at all. This is indicated by omitting the refresh interval; this will cause the receiver to assume that it has gone idle after 120 seconds. (In most cases, the content message will have been sent by then.) No refresh messages are sent in "idle" state.
アクティブ状態のリフレッシュ間隔は、作曲は「アクティブ」状態のまま「アクティブ」状態メッセージが送信される頻度を決定します。間隔を構成するユーザが選択し、ステータスメッセージ内の<リフレッシュ>要素で示され、整数秒で表さ。 isComposingメッセージの各送信は、タイマーをリセットします。間隔は60秒よりも短くてはなりません。メッセージ作曲はすべてのアクティブステートリフレッシュメッセージを送信しないことを決定してもよいです。これは、リフレッシュ間隔を省略して示されています。これは、受信機は、それが120秒後にアイドル状態になったことを前提とします。 （ほとんどの場合、コンテンツメッセージはその後で送信されています。）いいえリフレッシュメッセージは「アイドル」状態で送信されません。
The active-state refresh mechanism deals with the case in which the user logs off or the application crashes before the content message is completed.
コンテンツ・メッセージが完了する前にユーザーがログオフするか、アプリケーションがクラッシュした場合にアクティブ状態リフレッシュ機構を扱います。
If the user stops composing for more than a configured time interval, the idle timeout, the state transitions to "idle", and an "idle" status message is sent. If the user starts composing again while in "idle" state, the state transitions to "active", and the corresponding status message is sent. Unless otherwise configured by the user, the idle timeout SHOULD have a default value of 15 seconds.
ユーザは、設定された時間間隔、アイドルタイムアウトより長く構成を停止した場合、状態遷移は「アイドル」、および「アイドル」ステータスメッセージが送信されます。ユーザが「アイドル」状態で、状態遷移を「アクティブ」しながら、再び合成を開始し、対応するステータスメッセージが送信される場合。そうでない場合は、ユーザによって構成されていない限り、アイドルタイムアウトは15秒のデフォルト値を持つ必要があります。
If a content message is sent before the idle threshold expires, no "idle" state indication is needed. Thus, in most cases, only one status message is generated for each content message. In any event, the message rate is limited to one status message per refresh threshold interval.
アイドルしきい値の期限が切れる前に、コンテンツ・メッセージが送信される場合、「アイドル」状態表示は必要ありません。したがって、ほとんどの場合、唯一の状態メッセージは、各コンテンツメッセージのために生成されます。いずれにして、メッセージレートは、リフレッシュ閾値間隔ごとにステータスメッセージに限定されます。
The state transitions are shown in Figure 1.
状態遷移は図1に示されています。
+-------------+
|+-----------+|
|| ||
+------>| idle |<--------+
| || || |
| |+-----------+| |
| +------+------+ |
content | | | idle timeout
msg. sent | | composing | w/o activity
----------- | | ------------- | ------------------
-- | | "active" msg. | "idle" status msg.
| | |
| +------V------+ |
| | | |
| | | |
| | | |
+------+ active +--------+
| |
| |------+
+------^------+ | refresh timeout
| | --------------------
| | "active" status msg.
+-------------+
Figure 1. Sender State Diagram
図1.送信者の状態図
The status message receiver uses the status messages to determine the state of the content message sender. If the most recent "active" status message contained a <refresh> value, the refresh time-out is set to that value; otherwise, it is 120 seconds. The state at the receiver transitions from "active" to "idle" under three conditions:
ステータスメッセージ受信機は、コンテンツメッセージ送信者の状態を決定するために、ステータスメッセージを使用します。最新の「アクティブ」ステータスメッセージは、<リフレッシュ>の値が含まれていた場合、リフレッシュのタイムアウトは、その値に設定されています。それ以外の場合は、120秒です。三つの条件の下で「アイドル」から「アクティブ」から受信遷移の状態：
1. A status message with status "idle" is received. 2. A content message is received. 3. The refresh interval expires.
ステータス「IDLE」を有する1ステータスメッセージが受信されます。 2.コンテンツ・メッセージが受信されます。 3.リフレッシュ間隔が期限切れになります。
Receivers MUST be able to handle multiple consecutive isComposing messages with "active" state, regardless of the refresh interval.
レシーバは関係なく、リフレッシュ間隔の、「アクティブ」状態で複数の連続isComposingメッセージを処理できなければなりません。
The state transitions are shown in Figure 2.
状態遷移は、図2に示されています。
+-------------+
|+-----------+|
|| ||
+------>| idle |<------+
| || || |
| |+-----------+| |
| +------+------+ |
| | |
"idle" recd. | |"active" msg.| refresh timeout
or content recd. | | | or 120s
| | |
| +------V------+ |
| | | |
| | | |
| | | |
+------+ active +------+
| |
| |
+-------------+
Figure 2. Receiver State Diagram
図2.レシーバの状態図
We briefly describe the message content to summarize the discussion above. This description is non-normative. The schema (Section 6) should be consulted for the normative message format.
私たちは、簡単に上記の議論を要約するメッセージの内容を説明します。この説明は、非規範的です。スキーマ（第6節）は、規範的メッセージフォーマットのために相談すべきです。
The message consists of an <isComposing> element, with a mandatory <state> element indicating the composer state; i.e., idle or active. In addition, there are three optional elements: <lastactive>, indicating the time of last activity; <contenttype>, the type of message being created; and <refresh>, the time interval after which the receiver can expect an update from the composer. Details are given in the following section.
メッセージは、作曲状態を示す必須<状態>要素と<isComposing>要素で構成され、すなわち、アイドル状態またはアクティブ。また、3つのオプションの要素があります。<lastactive>、最後の活動時間を示します。 <たContentType>、メッセージのタイプが作成されます。そして<リフレッシュ>、受信機は、作曲から更新を期待することができた後の時間間隔。詳細は次のセクションに記載されています。
The status message contains additional optional elements to provide further details on the composition activity. Any of these can appear in both "active" and "idle" state messages.
ステータスメッセージは、組成物の活性に関するさらなる詳細を提供するために、追加オプション要素を含みます。これらはいずれも、両方の「アクティブ」と「アイドル」状態のメッセージに表示することができます。
The optional <lastactive> element describes the absolute time when the user last added or edited content.
オプションの<lastactive>要素は、ユーザが最後に追加またはコンテンツを編集した絶対時間を記載しています。
The optional <contenttype> element indicates the type of medium in which the messaging terminal is currently composing. It can contain either just a MIME media type, such as "audio" or "text", or a media type and subtype, such as "text/html". It is best understood as a hint to the user, not a guarantee, that the actual content message will indeed contain only the content indicated. It allows the human recipient to be prepared for the likely message format.
オプションの<たContentType>要素は、メッセージング端末が現在構成される媒体の種類を示します。それは、このような「text / html」など「オーディオ」または「テキスト」、またはメディアタイプとサブタイプ、など、どちらかだけのMIMEメディアタイプを含めることができます。最高の実際のコンテンツメッセージが実際にコンテンツのみが示されている含まれていること、ユーザーではなく、保証へのヒントとして理解されています。それは人間の受信者はおそらくメッセージ・フォーマットのために準備することができます。
To further describe message composition, the XML schema or the set of allowable state names can be extended in future documents. Recipients of status messages implementing this specification without extensions MUST treat state tokens other than "idle" and "active" as "idle". Additional elements MUST use their own namespaces and MUST be designed so that receivers can safely ignore such extensions. Adding elements to the namespace defined in this document is not permitted.
さらにメッセージ構成を説明するために、XMLスキーマまたは許容状態名のセットは、将来の文書に拡張することができます。拡張子なしでこの仕様を実装するステータスメッセージの受信者は、「アイドル」として「アイドル」と「アクティブ」以外の状態トークンを扱わなければなりません。追加要素は、独自の名前空間を使用しなければならなくて、受信機が安全に、このような拡張を無視することができるように設計されなければなりません。この文書で定義された名前空間に要素を追加することは許可されていません。
The isComposing status message MAY be carried in CPIM messages [3].
isComposingステータスメッセージはCPIMメッセージで実施することができる[3]。
Such a wrapper is particularly useful if messages are relayed by a conference server since the CPIM message maintains the identity of the original composer.
CPIMメッセージがオリジナルの作曲のアイデンティティを維持するので、メッセージが会議サーバによって中継される場合、このようなラッパーは特に便利です。
The isComposing status message can be used with either page mode or session mode, although session mode is a more natural fit. In session mode, the status message is sent as part of the messaging stream. Its usage is negotiated just like any other media type in that stream, with details depending on the session mode protocol.
セッションモードは、より自然なフィット感ですがisComposingステータスメッセージは、ページモードまたはセッションモードのいずれかで使用することができます。セッションモードでは、ステータスメッセージは、メッセージング・ストリームの一部として送信されます。その使用は、セッションモードのプロトコルに応じて詳細を、ちょうどそのストリーム内の他のメディアタイプと同様に交渉されています。
Sending the status messages within the session-mode messaging stream has at least three benefits. First, it ensures proper ordering and synchronization with the actual content messages being composed. In messaging systems that guarantee in-order delivery of messages, this approach avoids having an active indication appear at the receiver after the actual message has been delivered, due to message reordering across two delivery mechanisms.
セッションモードメッセージングストリーム内のステータスメッセージを送信すると、少なくとも3つの利点があります。まず、それは実際の内容のメッセージが構成されているとの適切な順序との同期を保証します。メッセージの順序配信を保証するメッセージング・システムでは、このアプローチは、実際のメッセージによる2つの配信メカニズムを横切って並べ替えメッセージに、送達された後に活性指示が受信機に現れる必要がなくなり。
Secondly, end-to-end security can be applied to the messages. Thirdly, session negotiation mechanisms can be used to turn it on and off at any time, and even to negotiate its use in a single direction at a time.
第二に、エンドツーエンドのセキュリティは、メッセージに適用することができます。第三に、セッションネゴシエーションメカニズムは、いつでもオンとオフ、それを回すために、さらには一度に一つの方向での使用を交渉するために使用することができます。
Usage with page mode is also straightforward: The status message is carried as the body of a page mode message. In SIP-based IM, The composer MUST cease transmitting status messages if the receiver returned a 415 status code (Unsupported Media Type) in response to a MESSAGE request containing the status indication.
ページモードでの使用方法も簡単です：ステータスメッセージは、ページモードメッセージのボディとして実施されます。受信機は状態表示を含むメッセージの要求に応じて、415のステータスコード（サポートされていないメディアタイプ）を返した場合、SIPベースのIMに、作曲は、ステータスメッセージを送信することを中止しなければなりません。
The sender cannot be assured that the status message is delivered before the actual content being composed arrives. However, SIP page mode is limited to one unacknowledged message, so out-of-order delivery is unlikely, albeit still possible if proxies are involved.
送信者が構成されている実際のコンテンツが到着する前に、ステータスメッセージが配信されることを保証することはできません。しかし、SIPのページモードは、プロキシが関与している場合は配信がまだ可能いえ、ほとんどありませんので、アウト・オブ・オーダー、1つの未確認のメッセージに限定されています。
<?xml version="1.0" encoding="UTF-8"?> <isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing iscomposing.xsd"> <state>active</state> <contenttype>text/plain</contenttype> <refresh>90</refresh> </isComposing>
<？xml version = "1.0" エンコード= "UTF-8"？> <isComposingのxmlns = "壷：IETF：のparams：XML：NS：IM-iscomposing" のxmlns：XSI = "http://www.w3.org / 2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：IM-構成iscomposing.xsd"> <状態>アクティブ</状態> <たContentType> text / plainの</ ContentTypeが> <リフレッシュ> 90 </リフレッシュ> </ isComposing>
<?xml version="1.0" encoding="UTF-8"?> <isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing iscomposing.xsd"> <state>idle</state> <lastactive>2003-01-27T10:43:00Z</lastactive> <contenttype>audio</contenttype> </isComposing>
<？xml version = "1.0" エンコード= "UTF-8"？> <isComposingのxmlns = "壷：IETF：のparams：XML：NS：IM-iscomposing" のxmlns：XSI = "http://www.w3.org / 2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：IM-構成iscomposing.xsd"> <状態>アイドル</状態> <lastactive> 2003-01-27T10：43：00Z </ lastactive> <ContentTypeを>オーディオ</ ContentTypeを> </ isComposing>
An isComposing document is an XML document that MUST be well formed and SHOULD be valid. isComposing documents MUST be based on XML 1.0 and MUST be encoded by using UTF-8. This specification makes use of XML namespaces for identifying isComposing documents. The namespace URI for elements defined for this purpose is a URN using the namespace identifier 'ietf'. This URN is:
isComposing文書がうまく形成されなければならないと有効である必要があり、XML文書です。 isComposing文書は、XML 1.0に基づいていなければならないとUTF-8を使用してエンコードする必要があります。この仕様はisComposing文書を識別するためのXML名前空間を使用しています。この目的のために定義された要素の名前空間URIは、名前空間識別子「IETF」を使用してURNです。このURNは以下のとおりです。
urn:ietf:params:xml:ns:im-iscomposing
URN：IETF：のparams：XML：NS：IM-iscomposing
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:im-iscomposing" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing"> <xs:element name="isComposing"> <xs:complexType> <xs:sequence> <xs:element name="state" type="xs:string"/> <xs:element name="lastactive" type="xs:dateTime" minOccurs="0"/> <xs:element name="contenttype" type="xs:string" minOccurs="0"/> <xs:element name="refresh" type="xs:positiveInteger" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：IM-iscomposing" のelementFormDefault = "資格" attributeFormDefault = "非修飾" のxmlnsを： XS = "http://www.w3.org/2001/XMLSchema" のxmlns：TNS = "壷：IETF：のparams：XML：NS：IM-iscomposing"> <XS：要素名= "isComposing"> <XS： complexType> <XS：配列> <XS：要素名= "状態" タイプ= "XS：文字列" /> <XS：要素名= "lastactive" タイプ= "XS：dateTimeの" minOccurs属性= "0" /> <XS ：要素名= "ContentTypeを" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "リフレッシュ" タイプ= "XS：POSITIVEINTEGER" のminOccurs = "0" /> <XS：任意の名前空間= "##他の" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素> </ XS：スキーマ>
The isComposing indication provides a fine-grained view of the activity of the entity composing and thus deserves particularly careful confidentiality protection so that only the intended recipient of the message will receive the isComposing indication.
isComposing指示は、構成エンティティの活性のきめ細かなビューを提供し、メッセージの唯一の意図された受信者がisComposing指示を受信するように、従って特に注意機密保護に値します。
Since the status messages are carried by using the IM protocol itself, all security considerations of the underlying IM protocol also apply to the isComposing status messages.
ステータスメッセージは、IMプロトコル自体を使用して実施されているので、基本的なIMプロトコルのすべてのセキュリティの考慮もisComposingステータスメッセージに適用されます。
There are potential privacy issues in sending isComposing status messages before an actual conversation has been established between the communicating users. A status message may be sent even if the user later abandons the message. It is RECOMMENDED that isComposing indications in page mode are only sent when a message is being composed as a reply to an earlier message. This document does not prescribe how an implementation detects whether a message is in response to an earlier one in page mode, but elapsed time or user interface behavior might be used as hints.
実際の会話が通信し、ユーザー間で確立される前にisComposingのステータスメッセージを送信するの潜在的なプライバシーの問題があります。ステータスメッセージは、ユーザが後でメッセージを破棄する場合でも送信することができます。メッセージが以前のメッセージへの返信として構成されているときに、ページモードでisComposing表示がのみ送信することをお勧めします。この文書では、実装は、メッセージがページモードでは、以前の1に対応しているが、経過時間やユーザーインターフェースの動作がヒントとして使用されるかもしれないかどうかを検出する方法を規定していません。
To: ietf-types@iana.org Subject: Registration of MIME media type application/ im-iscomposing+xml MIME media type name: application MIME subtype name: im-iscomposing+xml Required parameters: (none) Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [4], section 3.2. Security considerations: This content type is designed to carry information about current user activity, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. Interoperability considerations: This content type provides a common format for exchange of composition activity information. Published specification: RFC 3994 Applications which use this media type: Instant messaging systems. Additional information: none Person & email address to contact for further information: Henning Schulzrinne, hgs@cs.columbia.edu Intended usage: LIMITED USE Author/Change controller: This specification is a work item of the IETF SIMPLE working group, with the mailing list address simple@ietf.org. Other information: This media type is a specialization of application/xml RFC 3023 [4], and many of the considerations described there also apply to application/im-iscomposing+xml.
To：ietf-types@iana.org件名：アプリケーションMIMEサブタイプ名：IM-iscomposing + xmlの必須パラメータ：（なし）オプションのパラメータ：MIMEメディアタイプapplication / IM-iscomposing + xmlのMIMEメディアタイプ名の登録文字セット。囲まれたXMLの文字エンコーディングを示します。デフォルトはUTF-8です。エンコードの考慮事項：使用される文字エンコーディングに応じて、8ビット文字を採用することができるXMLを使用しています。 RFC 3023 [4]、セクション3.2を参照。セキュリティの考慮事項：このコンテンツの種類は、個人情報と見なすことができる現在のユーザの活動に関する情報を運ぶために設計されています。適切な予防措置は、この情報の開示を制限するために採用されるべきです。相互運用性に関する考慮事項：このコンテンツタイプは、組成物の活性情報を交換するための共通フォーマットを提供します。公開された仕様：インスタントメッセージングシステム：このメディアタイプを使用するRFC 3994個のアプリケーション。追加情報：なし人とEメールアドレスは、詳細のために連絡する：ヘニングSchulzrinneと、hgs@cs.columbia.eduが意図している用法：限定された使用者/変更コントローラ：この仕様は郵送で、IETF SIMPLEワーキンググループの作業項目ですリストアドレスsimple@ietf.org。その他の情報：このメディアタイプは、アプリケーション/ XMLのRFC 3023の特殊化である[4]、及び考察の多くは、アプリケーション/ IM-iscomposing + XMLに存在適用します。
8.2. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:im-iscomposing'
8.2. '：IETF：のparams：XML：NS：IM-iscomposing壷' のURNサブ名前空間の登録
URI: urn:ietf:params:xml:ns:im-iscomposing Description: This is the XML namespace for XML elements defined by RFC 3994 to describe composition activity by an instant messaging client using the application/im-iscomposing+xml content type. Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, Henning Schulzrinne, hgs@cs.columbia.edu XML:
URI：URN：IETF：paramsは：XMLは：NS：IM-iscomposing説明：これは、アプリケーション/ IM-iscomposing + XMLコンテンツタイプを使用してインスタントメッセージングクライアントによって組成活動を記述するためにRFC 3994によって定義されたXML要素のXML名前空間です。登録者連絡先：IETF、SIMPLEワーキンググループ、simple@ietf.org、ヘニングSchulzrinneと、hgs@cs.columbia.edu XML：
BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Is-composing Indication for Instant Messaging</title> </head> <body> <h1>Namespace for SIMPLE iscomposing extension</h1> <h2>urn:ietf:params:xml:ns:im-composing</h2> <p>See <a href="[URL of published RFC]">RFC3994</a>.</p> </body> </html> END
BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml- basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <META HTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" SIMPLE iscomposing拡張のためのインスタントメッセージング</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URNのための/> <タイトル>-構成されています表示：IETF：のparams：XML： NS：IM-構成</ H2> <P>公表RFC]"> RFC3994 </a>での<a href="[URLを参照してください。</ P> </ body> </ html>このEND
This section registers a new XML schema per the procedures in [5].
このセクションでは、[5]における手順に従って新しいXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:im-composing Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Henning Schulzrinne (hgs@cs.columbia.edu).
URI：URN：IETF：のparams：XML：スキーマ：IM-構成する登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ヘニングSchulzrinneと（hgs@cs.columbia.edu）。
The XML for this schema can be found as the sole content of Section 6.1.
このスキーマのためのXMLは、セクション6.1の唯一の内容として求めることができます。
Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson, Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi, Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.
ベン・キャンベル、ミゲル・ガルシア、スコットホレンベック、クリスチャン・ヤンソン、カレン・ジェニングス、ヒシャムKhartabil、アリソンマンキン、アキニエミ、ジョナサン・ローゼンバーグ、およびXiaotao呉は役に立つコメントを提供しました。
[1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[1]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[3] Klyne、G.、およびD.アトキンス、 "一般的なプレゼンスとインスタントメッセージング（CPIM）：メッセージの形式"、RFC 3862、2004年8月。
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[5] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[6]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[7] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", Work in Progress, February 2004.
[7]ローゼンバーグ、J.、「セッション開始プロトコル（SIP）のための高度なインスタントメッセージング要件」、進歩、2004年2月に作業。
Author's Address
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
電話：+1 212 939 7004 Eメール：hgs@cs.columbia.edu URI：http://www.cs.columbia.edu/~hgs
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。