[要約] RFC 3994は、インスタントメッセージングのメッセージ構成の指示を示しており、メッセージの形式や構造を定義しています。このRFCの目的は、異なるインスタントメッセージングプロトコル間でのメッセージの互換性を確保することです。
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).
Copyright（c）The Internet Society（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人以上の受信者に送信されます。電子メールとは異なり、インスタントメッセージングは多くの場合会話型であるため、相手は応答を待っています。応答がない場合、インスタントメッセージングの会話の参加者は、コミュニケーションパートナーが去ったこと、または再びタイプするターンであると誤って想定し、2つのメッセージを「ワイヤーで交差する」と想定しています。
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.
この不確実性を回避するために、多くの商業的なインスタントメッセージングシステムは、1つの当事者がメッセージの入力を開始するとすぐに送信された「IS-Typing」表示を特徴としています。このドキュメントでは、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.
ステータスメッセージは、XMLスキーマのインスタンスがセクション6で定義されており、XMLコンテンツタイプのアプリケーション/IMを同意するものとしてラベル付けされているように、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]で定義されている語彙を使用しています。このメモでは、クローズド、インスタントメッセージ、オープン、プレゼンスサービス、プレゼンティ、ウォッチャー、ウォッチャーユーザーエージェントなどの用語が、そこで定義されている同じ意味で使用されます。キーワードは、このドキュメントでは、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人以上のユーザーの間で実際のコンテンツを伝えることと、このドキュメントで説明されているステータスメッセージで、会話の他の参加者への現在の構成ステータスを示します。これら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".
コンテンツメッセージを積極的に構成するインスタントメッセージングユーザーエージェントのみが、現在の状態を示すステータスメッセージを生成します。ユーザーがコンテンツメッセージ（実際のインスタントメッセージ）の構成を開始すると、状態は「アクティブ」になり、「アクティブ」を示す<state>要素を含むインサムポジションメッセージが構成されているコンテンツメッセージの受信者に送信されます。ユーザーがインスタントメッセージコンテンツを作成し続ける限り、ユーザーは状態の「アクティブ」にとどまります。
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.
アクティブ状態の更新間隔は、作曲家が「アクティブ」状態にとどまる間、「アクティブ」状態メッセージが送信される頻度を決定します。間隔は、構成ユーザーによって選択され、整数秒で表現されたステータスメッセージの<refresh>要素に示されています。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.
アイドルしきい値が切れる前にコンテンツメッセージが送信された場合、「アイドル」状態の兆候は必要ありません。したがって、ほとんどの場合、コンテンツメッセージごとに1つのステータスメッセージのみが生成されます。いずれにせよ、メッセージレートは、更新しきい値間隔ごとに1つのステータスメッセージに制限されます。
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:
ステータスメッセージレシーバーは、ステータスメッセージを使用して、コンテンツメッセージ送信者の状態を決定します。最新の「アクティブな」ステータスメッセージに<Reshok>値が含まれている場合、更新タイムアウトはその値に設定されます。それ以外の場合は、120秒です。受信者の状態は、3つの条件で「アクティブ」から「アイドル」に移行します。
1. A status message with status "idle" is received. 2. A content message is received. 3. The refresh interval expires.
1. ステータス「アイドル」のステータスメッセージが受信されます。2.コンテンツメッセージが受信されます。3.更新間隔の有効期限が切れます。
Receivers MUST be able to handle multiple consecutive isComposing messages with "active" state, regardless of the refresh interval.
レシーバーは、更新間隔に関係なく、「アクティブな」状態で複数の連続したISECTISEメッセージを処理できる必要があります。
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>要素で構成され、作曲家状態を示す必須<state>要素があります。つまり、アイドルまたはアクティブ。さらに、3つのオプション要素があります。<lastActive>、最後のアクティビティの時間を示します。<contentType>、作成されるメッセージのタイプ。<refrish>、その後の時間間隔では、受信者が作曲家からの更新を期待できます。詳細については、次のセクションに記載されています。
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>要素は、メッセージング端子が現在構成されているメディアのタイプを示します。「オーディオ」や「テキスト」などのMIMEメディアタイプ、または「テキスト/HTML」などのメディアタイプとサブタイプのいずれかを含めることができます。実際のコンテンツメッセージには、示されているコンテンツのみが実際に含まれることは、保証ではなく、ユーザーにとってのヒントとして最もよく理解されています。これにより、人間の受信者が可能性のあるメッセージ形式に備えることができます。
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メッセージが元の作曲家のIDを維持するため、会議サーバーによってメッセージが中継される場合に特に役立ちます。
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.
ページモードでの使用も簡単です。ステータスメッセージは、ページモードメッセージの本文として実行されます。SIPベースのIMでは、受信者がステータス表示を含むメッセージ要求に応じて415ステータスコード（サポートされていないメディアタイプ）を返した場合、作曲家はステータスメッセージの送信を停止する必要があります。
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" 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>
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:
同意文書は、適切に形成されている必要があり、有効でなければならないXMLドキュメントです。ISComposingドキュメントはXML 1.0に基づいている必要があり、UTF-8を使用してエンコードする必要があります。この仕様では、XMLネームスペースを使用して、ISCOMPOSINGドキュメントを識別します。この目的のために定義された要素の名前空間URIは、名前空間識別子「IETF」を使用したURNです。このurnは次のとおりです。
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>
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.
同意の適応症は、エンティティ構成のアクティビティの細粒の見解を提供するため、メッセージの意図された受信者のみがIS複合表示を受け取るように、特に慎重な機密保護に値します。
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プロトコルのすべてのセキュリティ上の考慮事項は、ISコンポーティングステータスメッセージにも適用されます。
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.
コミュニケーションユーザー間で実際の会話が確立される前に、ステータスメッセージをコンパシングする潜在的なプライバシーの問題があります。ユーザーが後でメッセージを放棄しても、ステータスメッセージが送信される場合があります。ページモードでの適応症の表示は、メッセージが以前のメッセージへの返信として構成されている場合にのみ送信されることをお勧めします。このドキュメントでは、実装がメッセージが以前のページモードに応答しているかどうかをどのように検出するかを規定していませんが、経過時間またはユーザーインターフェイスの動作をヒントとして使用する可能性があります。
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.
宛先：ietf-types@iana.org件名：MIMEメディアタイプアプリケーションの登録/ IM-isComposing XML MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：IM-ISCOMPOSING XML必須パラメーター：（なし）オプションパラメーター：charset;囲まれたXMLの文字エンコードを示します。デフォルトはUTF-8です。考慮事項のエンコーディング：使用する文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。RFC 3023 [4]、セクション3.2を参照してください。セキュリティ上の考慮事項：このコンテンツタイプは、個人情報と見なされる可能性のある現在のユーザーアクティビティに関する情報を伝達するように設計されています。この情報の開示を制限するために、適切な注意事項を採用する必要があります。相互運用性の考慮事項：このコンテンツタイプは、組成活動情報の交換に共通の形式を提供します。公開された仕様：このメディアタイプを使用するRFC 3994アプリケーション：インスタントメッセージングシステム。追加情報：なし人とメールアドレス連絡先詳細情報：Henning Schulzrinne、hgs@cs.columbia.edu意図的使用：著者/変更コントローラーが制限されている：この仕様は、郵送されるIETFシンプルワーキンググループの作業項目です。リストアドレスsimple@ietf.org。その他の情報：このメディアタイプは、アプリケーション/XML RFC 3023 [4]の専門化であり、そこに記載されている考慮事項の多くは、アプリケーション/IM等等分のXMLにも適用されます。
8.2. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:im-iscomposing'
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説明：これは、rfc 3994で定義されたXML要素のXML名空間です。登録者の連絡先：IETF、Simple Working Group、simple@itf.org、Henning 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
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：schema：im-composing登録者の連絡先：ietf、simpleワーキンググループ、（simple@ietf.org）、Henning 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.
ベン・キャンベル、ミゲル・ガルシア、スコット・ホレンベック、クリスチャン・ジャンソン、カレン・ジェニングス、ヒシャム・ハルタビル、アリソン・マンキン、アキ・ニエミ、ジョナサン・ローゼンバーグ、Xiaotao Wuは有益なコメントを提供しました。
[1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[1] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[3] Klyne、G。およびD. Atkins、「共通の存在とインスタントメッセージング（CPIM）：メッセージ形式」、RFC 3862、2004年8月。
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[7] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", Work in Progress, February 2004.
[7] Rosenberg、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コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。