Network Working Group                                     H. Schulzrinne
Request for Comments: 3994                                   Columbia U.
Category: Standards Track                                   January 2005
        
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对话期间了解对方是否正在撰写消息是有用的;e、 例如,键入或录制音频消息。此文档定义了一个新的状态消息内容类型和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
        
   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. 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)是基于消息的:用户通过键入、讲话或录制视频剪辑等方式编写消息。然后将此邮件发送给一个或多个收件人。与电子邮件不同,即时消息通常是对话式的,因此对方正在等待回复。如果没有响应,即时消息会话中的参与者可能会错误地认为通信伙伴已经离开,或者轮到她再次键入,从而导致两条消息“在线路上交叉”。

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

为了避免这种不确定性,许多商业即时消息系统的特点是,一旦一方开始键入消息,就会发送“正在键入”指示。在本文档中,我们描述了此指示的通用版本,称为isComposing状态消息。如第3节所述,状态消息以与消息本身相同的方式传递给即时消息接收者。isComposing状态消息可以宣布任何媒体类型的合成,而不仅仅是文本。对于

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模式的实例,并标记为application/im iscomposing+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]中的要求。

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模型文件[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.

本文件讨论了两种消息;即,即时消息(IM)在参与即时消息传递会话的两个或多个用户之间传送实际内容,以及本文档中描述的向会话中的其他参与者指示当前撰写状态的状态消息。对于这两种消息类型,我们使用术语“内容消息”和“状态消息”。

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.

我们将即时消息系统的用户建模为处于几种状态之一,在本文档中仅限于“空闲”和“活动”。默认情况下,用户在开始编写消息之前和发送消息之后都处于“空闲”状态。

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".

只有主动撰写内容消息的即时消息用户代理才能生成指示当前状态的状态消息。当用户开始撰写内容消息(实际即时消息)时,状态变为“活动”,并且包含指示“活动”的<state>元素的isComposing status消息被发送给正在撰写的内容消息的接收者。只要用户继续生成即时消息内容,用户就会保持“活动”状态。

There are two sender timers: the active-state refresh interval, and the idle time-out interval.

有两个发送方计时器:活动状态刷新间隔和空闲超时间隔。

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.

如果在空闲阈值到期之前发送内容消息,则不需要“空闲”状态指示。因此,在大多数情况下,每个内容消息只生成一条状态消息。在任何情况下,消息速率限制为每刷新阈值间隔一条状态消息。

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.
                             +-------------+
        
                      +-------------+
                      |+-----------+|
                      ||           ||
               +------>|   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。发送方状态图

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秒。在三种情况下,接收器的状态从“活动”转换为“空闲”:

1. A status message with status "idle" is received. 2. A content message is received. 3. The refresh interval expires.

1. 收到状态为“idle”的状态消息。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    +------+
                           |             |
                           |             |
                           +-------------+
        
                           +-------------+
                           |+-----------+|
                           ||           ||
                    +------>|   idle    |<------+
                    |      ||           ||      |
                    |      |+-----------+|      |
                    |      +------+------+      |
                    |             |             |
       "idle" recd. |             |"active" msg.| refresh timeout
   or content recd. |             |             | or 120s
                    |             |             |
                    |      +------V------+      |
                    |      |             |      |
                    |      |             |      |
                    |      |             |      |
                    +------+   active    +------+
                           |             |
                           |             |
                           +-------------+
        

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>元素组成,其中一个必需的<state>元素指示编写器状态;i、 例如,空闲或活动。此外,还有三个可选元素:<lastactive>,表示上次活动的时间<contenttype>,正在创建的消息的类型;和<refresh>,在该时间间隔之后,接收器可以期望作曲家进行更新。详情见下一节。

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.

状态消息包含其他可选元素,以提供有关合成活动的更多详细信息。其中任何一个都可能出现在“活动”和“空闲”状态消息中。

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.

在会话模式消息流中发送状态消息至少有三个好处。首先,它确保与正在编写的实际内容消息进行适当的排序和同步。在保证按顺序传递消息的消息传递系统中,由于消息跨两个传递机制重新排序,这种方法避免了在实际消息被传递后在接收器处出现活动指示。

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页面模式仅限于一条未确认的消息,因此不太可能出现无序传递,尽管在涉及代理的情况下仍然可能出现这种情况。

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 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>
        
   <?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>
        
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文档,它必须格式正确且有效。isComposing文档必须基于XML 1.0,并且必须使用UTF-8进行编码。本规范使用XML名称空间来标识isComposing文档。为此目的定义的元素的名称空间URI是使用名称空间标识符“ietf”的URN。这个骨灰盒是:

      urn:ietf:params:xml:ns:im-iscomposing
        
      urn:ietf:params:xml:ns:im-iscomposing
        
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 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>
        
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指示。本文档没有规定实现如何检测消息是否响应页面模式下的早期消息,但已用时间或用户界面行为可以用作提示。

8. IANA Considerations
8. IANA考虑
8.1. Content-Type Registration for 'application/im-iscomposing+xml'
8.1. “应用程序/im 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.

致:ietf-types@iana.org主题:注册MIME媒体类型应用程序/im iscomposing+xml MIME媒体类型名称:应用程序MIME子类型名称:im iscomposing+xml必需参数:(无)可选参数:字符集;指示封闭XML的字符编码。默认值为UTF-8。编码注意事项:使用XML,它可以使用8位字符,具体取决于所使用的字符编码。参见RFC 3023[4],第3.2节。安全注意事项:此内容类型旨在承载有关当前用户活动的信息,这些信息可能被视为私人信息。应采取适当的预防措施来限制该信息的披露。互操作性注意事项:此内容类型为合成活动信息的交换提供了通用格式。已发布规范:RFC 3994使用此媒体类型的应用程序:即时消息系统。其他信息:无联系人和电子邮件地址以获取更多信息:Henning Schulzrinne,hgs@cs.columbia.edu预期用途:有限使用作者/变更控制者:本规范是IETF简单工作组的工作项,具有邮件列表地址simple@ietf.org. 其他信息:此媒体类型是application/xml RFC 3023[4]的一种专门化,其中描述的许多注意事项也适用于application/im iscomposing+xml。

8.2.  URN Sub-Namespace Registration for
      'urn:ietf:params:xml:ns:im-iscomposing'
        
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 Description:这是RFC 3994定义的xml元素的xml命名空间,用于描述即时消息客户端使用应用程序/im iscomposing+xml内容类型进行的合成活动。注册人联系人:IETF,简单工作组,simple@ietf.org,Henning Schulzrinne,hgs@cs.columbia.eduXML:

    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-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
        
8.3. Schema Registration
8.3. 模式注册

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组合注册人联系人:ietf,简单工作组(simple@ietf.org),亨宁·舒尔兹林内(hgs@cs.columbia.edu).

The XML for this schema can be found as the sole content of Section 6.1.

此模式的XML可作为第6.1节的唯一内容找到。

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.

本·坎贝尔、米格尔·加西亚、斯科特·霍伦贝克、克里斯蒂安·詹森、卡伦·詹宁斯、希沙姆·哈塔比尔、埃里森·曼金、阿基·尼米、乔纳森·罗森伯格和吴晓涛提供了有益的评论。

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.

[1] Day,M.,Rosenberg,J.,和H.Sugano,“状态和即时信息模型”,RFC 27782000年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媒体类型”,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月。

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] Sugano,H.,Fujimoto,S.,Klyne,G.,Batman,A.,Carr,W.,和J.Peterson,“状态信息数据格式(PIDF)”,RFC 38632004年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号

   Phone: +1 212 939 7004
   EMail: hgs@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~hgs
        
   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).

版权所有(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.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

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秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/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的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。