RFC3994 日本語訳
3994 Indication of Message Composition for Instant Messaging. H.Schulzrinne. January 2005. (Format: TXT=27472 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne Request for Comments: 3994 Columbia U. Category: Standards Track January 2005
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3994年のコロンビアU.カテゴリ: 標準化過程2005年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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名前空間を定義します。 ステータスメッセージはテキスト、声、またはビデオを含むどんなタイプに関するメッセージの構成も示すことができます。 インスタントメッセージ自体と同じ方法でインスタントメッセージング受取人にステータスメッセージを送ります。
Schulzrinne Standards Track [Page 1] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[1ページ]。
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
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。 'アプリケーション/のためのコンテントタイプ登録、不-、-iscomposing+xml'.108.2。 'つぼ:ietf:params:xml:ナノ秒の間のつぼのサブ名前空間登録: 不-'.118.3をiscomposingします。 図式登録. . . . . . . . . . . . . . . . . . 11 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1。 引用規格. . . . . . . . . . . . . . . . . . 12 10.2。 有益な参照. . . . . . . . . . . . . . . . . 12作者のアドレスの.12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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
この不確実性、多くの商業インスタントメッセージングシステム機能を避ける、「-、タイプ、」 1回のパーティーがメッセージをタイプし始めるとすぐに、指示は発信しました。 本書では、私たちはisComposingステータスメッセージと呼ばれるこの指示の一般化されたバージョンについて説明します。 セクション3でさらに詳細に説明されるように、メッセージ自体のように同じ方法でインスタントメッセージ受取人にステータスメッセージを送ります。 isComposingステータスメッセージはテキストだけではなく、どんなメディアタイプの構成も発表できます。 for
Schulzrinne Standards Track [Page 2] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[2ページ]。
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.
例、だれかがオーディオかビデオクリップを記録しているなら、それは使用されるかもしれません。 さらに、将来他のインスタントメッセージングユーザ州を運ぶのは拡張できます。 以下では、私たちが簡潔さへの「ステータスメッセージ」というこれらのメッセージを呼ぶつもりです。
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として運ばれて、アプリケーション/としてラベルされる、不-、-+ xml内容をiscomposingして、タイプしてください。
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]で要件を満たすためにここで目的について説明しました。
2. Terminology and Conventions
2. 用語とコンベンション
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 Modelドキュメント[1]で定義されたボキャブラリーを利用します。 このメモでは、CLOSEDや、INSTANT MESSAGEや、オープンや、PRESENCE SERVICEや、PRESENTITYや、WATCHERや、WATCHER USER AGENTなどの用語はそこに定義される同じ意味と共に使用されます。 キーワードが解釈しなければならない、BCP14(RFC2119[2])で説明されるように本書ではNOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりません。
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種類のメッセージについて議論します。 インスタントメッセージングの会話に従事している2人以上のユーザの間に実際の内容を伝えるインスタントメッセージ(IM)、およびステータスメッセージは、すなわち、どれが会話して状態を構成する電流を他の関係者に示すかと本書では説明しました。 私たちはこれらの2つのメッセージタイプに用語「満足しているメッセージ」と「ステータスメッセージ」を使用します。
3. Description
3. 記述
3.1. Overview
3.1. 概観
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.
私たちはいくつかの州の1つにあって、「怠ける」ために本書では制限されていて「アクティブ」であるとしてインスタントメッセージングシステムのユーザをモデル化します。 デフォルトで、メッセージを作成し始める前と「活動していません、な」状態と、それを送った後に、ユーザはいます。
Schulzrinne Standards Track [Page 3] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[3ページ]。
3.2. Message Composer Behavior
3.2. メッセージ作曲家の振舞い
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メッセージの各伝達はタイマをリセットします。 間隔SHOULD、いいえ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.
構成された時間間隔以上で構成されるユーザ停止、アイドルタイムアウトであるなら、状態は「怠ける」ために移行します、そして、「活動していません、な」ステータスメッセージを送ります。 ユーザが再び「活動していません、な」状態では、状態が「アクティブに」移行して、対応するステータスメッセージを送る間、構成し始めるなら。 別の方法でユーザによって構成されない場合、アイドルタイムアウトSHOULDには、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つのステータスメッセージに制限される、敷居間隔をリフレッシュしてください。
Schulzrinne Standards Track [Page 4] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[4ページ]。
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.
+-------------+
+-------------+ |+-----------+| || || +------>| 怠けてください。| <、-、-、-、-、-、-、--+ | || || | | |+-----------+| | | +------+------+ | 内容| | | タイムアウトmsgを空費してください、発信| | 構成します。| 活動なしで----------- | | ------------- | ------------------ -- | | 「アクティブな」msg。 | 「活動していません、な」状態msg。 | | | | +------V------+ | | | | | | | | | | | | | +------+ アクティブな+--------+ | | | |------+ +------^------+ | タイムアウトをリフレッシュしてください。| | -------------------- | | 「アクティブな」状態msg。 +-------------+
Figure 1. Sender State Diagram
図1。 送付者州のダイヤグラム
3.3. Status Message Receiver Behavior
3.3. ステータスメッセージ受信機の振舞い
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秒です。 受信機の状態は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.
にかかわらず、受信機が「アクティブな」状態と共に複数の連続したisComposingメッセージを扱うことができなければならない、間隔をリフレッシュしてください。
Schulzrinne Standards Track [Page 5] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[5ページ]。
The state transitions are shown in Figure 2.
状態遷移は図2に示されます。
+-------------+
|+-----------+|
|| ||
+------>| idle |<------+
| || || |
| |+-----------+| |
| +------+------+ |
| | |
"idle" recd. | |"active" msg.| refresh timeout
or content recd. | | | or 120s
| | |
| +------V------+ |
| | | |
| | | |
| | | |
+------+ active +------+
| |
| |
+-------------+
+-------------+ |+-----------+| || || +------>| 怠けてください。| <、-、-、-、-、--+ | || || | | |+-----------+| | | +------+------+ | | | | 「活動していません、な」recd。 | |「アクティブな」msg| タイムアウトか内容recdをリフレッシュしてください。 | | | または、120| | | | +------V------+ | | | | | | | | | | | | | +------+ アクティブな+------+ | | | | +-------------+
Figure 2. Receiver State Diagram
図2。 受信機州のダイヤグラム
3.4. Message Content
3.4. メッセージ内容
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>、作成されるメッセージのタイプ。 そして、<は>、受信機が作曲家からアップデートを予想できる時間間隔をリフレッシュします。 詳細は以下のセクションに述べられます。
3.5. Additional Status Information
3.5. 追加状態情報
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.
ステータスメッセージは構成活動に関する詳細を提供する追加随意的な要素を含んでいます。 これらのいずれもともに「アクティブで」「活動していません、な」州のメッセージに現れることができます。
Schulzrinne Standards Track [Page 6] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[6ページ]。
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メッセージがオリジナルの作曲家のアイデンティティを維持するのでメッセージが会議サーバによってリレーされるなら、そのような包装紙は特に役に立ちます。
4. Using the Status Message
4. ステータスメッセージを使用します。
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.
第二に、終わりから終わりへのセキュリティをメッセージに適用できます。 三番目に、いつでも、断続的にそれをターンして、一度にただ一つの指示に基づく使用を交渉するのさえセッション交渉メカニズムを使用できます。
Schulzrinne Standards Track [Page 7] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[7ページ]。
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では、作曲家は、受信機が状態指示を含むMESSAGE要求に対応して415ステータスコード(サポートされないメディアType)を返したならステータスメッセージを伝えるのをやめなければなりません。
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つの不承認のメッセージに制限されます、非常に故障しているので、プロキシがかかわるなら、配送は、ありそうもなくて、それにしても、まだ可能です。
5. Examples
5. 例
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><isComposing xmlns=「つぼ:ietf:params:xml:ナノ秒: 不-iscomposing」はxmlnsされます: xsiが" http://www.w3.org/2001/XMLSchema-instance "xsi: schemaLocation=と等しい、「つぼ:ietf:params:xml:ナノ秒: 不-構成iscomposing.xsd、「><州の>能動態</州の><contenttype>テキスト/明瞭な</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><isComposing xmlns=「つぼ:ietf:params:xml:ナノ秒: 不-iscomposing」はxmlnsされます: xsiが" http://www.w3.org/2001/XMLSchema-instance "xsi: schemaLocation=と等しい、「つぼ:ietf:params:xml:ナノ秒: 不-構成iscomposing.xsd「><州の>の活動していない</州の><lastactive>2003-01-27T10:43:00Z</lastactiveの>の<のcontenttypeの>のオーディオの</contenttype></isComposing>」
6. XML Document Format
6. XMLドキュメント・フォーマット
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ドキュメントとSHOULDです。有効であってください。isComposingドキュメントをXML1.0に基礎づけなければならなくて、UTF-8を使用することによって、コード化しなければなりません。 この仕様は、isComposingドキュメントを特定するのにXML名前空間を利用します。 このために定義された要素のための名前空間URIは'ietf'という名前空間識別子を使用するURNです。 このURNは以下の通りです。
urn:ietf:params:xml:ns:im-iscomposing
つぼ:ietf:params:xml:ナノ秒: 不-iscomposing
Schulzrinne Standards Track [Page 8] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[8ページ]。
6.1. XML Schema
6.1. XML図式
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><xs: 図式targetNamespace=elementFormDefault=が「資格を与えた」「つぼ:ietf:params:xml:ナノ秒: 不-iscomposing」attributeFormDefaultは「資格のない」xmlnsと等しいです: xsが" http://www.w3.org/2001/XMLSchema "xmlns: tns=と等しい、「つぼ:ietf:params:xml:ナノ秒: 不-iscomposingして、「><xs: 要素名前=「「><xs: complexType><xs: 系列><xs: 要素は=を命名する」というisComposing状態」タイプは「xs: ストリング」/><xsと等しいです」; 要素..名前..タイプ..0インチ..要素..名前..タイプ..ストリング..0インチ..要素..名前..リフレッシュ..タイプ..0インチ..名前空間..手緩い..0インチ..限りない..系列..要素..図式
7. Security Considerations
7. セキュリティ問題
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指摘を送るのは、RECOMMENDEDです。 実現が、メッセージがページモードによる以前のものに対応しているかをどう検出するかをこのドキュメントは処方しませんが、経過時間かユーザーインタフェースの振舞いがヒントとして費やされるかもしれません。
Schulzrinne Standards Track [Page 9] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[9ページ]。
8. IANA Considerations
8. IANA問題
8.1. Content-Type Registration for 'application/im-iscomposing+xml'
8.1. 'アプリケーション/のためのコンテントタイプ登録、不-、-+をiscomposingするのがxmlされる、'
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 Subject: MIMEメディアの登録がアプリケーション/をタイプする、不-、-iscomposing+xml MIMEメディアは名前をタイプします: アプリケーションMIME「副-タイプ」は以下を命名します。 不-、-、iscomposing+xml Requiredパラメタ: (なにも) 任意のパラメタ: charset。 同封のXMLのキャラクタコード化を示します。 デフォルトはUTF-8です。 問題をコード化します: キャラクタコード化であることによるXML(8ビットのキャラクタを雇うことができる)が使用した用途。 RFC3023[4]、セクション3.2を見てください。 セキュリティ問題: この満足しているタイプは、個人情報であると考えられるかもしれない現在のユーザ活動の情報を運ぶように設計されています。 適切な注意は、この情報の公開を制限するために採用されるべきです。 相互運用性問題: この満足しているタイプは構成活動情報の交換のための一般的な形式を提供します。 広められた仕様: このメディアタイプを使用するRFC3994Applications: インスタントメッセージングシステム追加情報: 詳細のために連絡しないPersonのどれかとどんなEメールアドレスも: ヘニングSchulzrinne、 hgs@cs.columbia.edu Intended用法: 株式会社USE Author/変化コントローラ: この仕様はメーリングリストアドレス simple@ietf.org があるIETF SIMPLEワーキンググループの仕事項目です。 他の情報: このメディアタイプがアプリケーション/xml RFC3023[4]のa専門化であり、また、そこで説明された問題の多くがアプリケーション/に適用される、不-、-+をiscomposingするのはxmlされます。
Schulzrinne Standards Track [Page 10] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[10ページ]。
8.2. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:im-iscomposing'
8.2. 'つぼ:ietf:params:xml:ナノ秒: 不-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: つぼ:ietf:params:xml:ナノ秒: 不-iscomposing記述: これがアプリケーション/を使用することでインスタントメッセージングクライアントによる構成活動について説明するためにRFC3994によって定義されたXML要素のためのXML名前空間である、不-、-+ xml内容をiscomposingして、タイプしてください。 記入者接触: 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バージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 「><html xmlns=「 http://www.w3.org/1999/xhtml の「><ヘッド><メタhttp-equiv=」満足しているタイプ」」; 内容が等しい、「テキスト/html;、charset=iso8859、1インチ、Instant Messaging</タイトル></ヘッド><のための>Isを構成している/><タイトルIndicationはSIMPLE iscomposing拡大</h1><h2>つぼのために><h1>Namespaceを具体化させます:、」; ietf:params:xml: ナノ秒:、不-、-構成</h2><p>See<aが=をhrefする、「発行されたRFC「>RFC3994</a>」のURL; </p></ボディー></html>エンド
8.3. Schema Registration
8.3. 図式登録
This section registers a new XML schema per the procedures in [5].
このセクションは[5]に1手順あたり1つの新しい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: つぼ:ietf:params:xml:図式: 不-構成Registrant Contact: 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.
セクション6.1の唯一の内容としてこの図式のためのXMLを見つけることができます。
9. Acknowledgements
9. 承認
Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson, Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi, Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.
ベン・キャンベル、ミゲル・ガルシア、スコットHollenbeck、クリスチャンのヤンソン、Cullenジョニングス、Hisham Khartabil、アリソン・マンキン、アキNiemi、ジョナサン・ローゼンバーグ、およびXiaotaoウーは役に立つコメントを提供しました。
Schulzrinne Standards Track [Page 11] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[11ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[1] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.
[3]Klyne、G.、およびD.アトキンス、「一般的な存在とインスタントメッセージング(CPIM):」 「メッセージ・フォーマット」、RFC3862、2004年8月。
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[4] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[5] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
10.2. Informative References
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.
[6] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[7] Rosenberg, J., "Advanced Instant Messaging Requirements for the
Session Initiation Protocol (SIP)", Work in Progress, February
2004.
[7] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための高度なインスタントメッセージング要件」が進歩、2004年2月に働いています。
Author's Address
作者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
以下に電話をしてください。 +1 7004年の212 939メール: hgs@cs.columbia.edu ユリ: http://www.cs.columbia.edu/~hgs
Schulzrinne Standards Track [Page 12] RFC 3994 isComposing January 2005
Schulzrinne規格はisComposing2005年1月にRFC3994を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne Standards Track [Page 13]
Schulzrinne標準化過程[13ページ]
一覧
スポンサーリンク
