📄 rfc3994 indication of message composition for instant messaging.txt
字号:
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.
Copyright Notice
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.
Schulzrinne Standards Track [Page 1]
RFC 3994 isComposing January 2005
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
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".
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
Schulzrinne Standards Track [Page 2]
RFC 3994 isComposing January 2005
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.
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.
The mechanism described here aims to satisfy the requirements in [7].
2. Terminology and Conventions
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].
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.
3. Description
3.1. Overview
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.
Schulzrinne Standards Track [Page 3]
RFC 3994 isComposing January 2005
3.2. Message Composer Behavior
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".
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.
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.
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.
Schulzrinne Standards Track [Page 4]
RFC 3994 isComposing January 2005
The state transitions are shown in Figure 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
3.3. Status Message Receiver Behavior
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:
1. A status message with status "idle" is received.
2. A content message is received.
3. The refresh interval expires.
Receivers MUST be able to handle multiple consecutive isComposing
messages with "active" state, regardless of the refresh interval.
Schulzrinne Standards Track [Page 5]
RFC 3994 isComposing January 2005
The state transitions are shown in Figure 2.
+-------------+
|+-----------+|
|| ||
+------>| idle |<------+
| || || |
| |+-----------+| |
| +------+------+ |
| | |
"idle" recd. | |"active" msg.| refresh timeout
or content recd. | | | or 120s
| | |
| +------V------+ |
| | | |
| | | |
| | | |
+------+ active +------+
| |
| |
+-------------+
Figure 2. Receiver State Diagram
3.4. Message Content
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.
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.
3.5. Additional Status Information
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
The optional <lastactive> element describes the absolute time when
the user last added or edited content.
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.
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.
The isComposing status message MAY be carried in CPIM messages [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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -