One document matched: draft-ietf-simple-iscomposing-01.txt
Differences from draft-ietf-simple-iscomposing-00.txt
Network Working Group H. Schulzrinne
Internet-Draft Columbia U.
Expires: November 13, 2004 May 15, 2004
Indication of Message Composition for Instant Messaging
draft-ietf-simple-iscomposing-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
In instant messaging (IM) systems, it is useful to know during an IM
conversation that 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 Expires November 13, 2004 [Page 1]
Internet-Draft iscomposing May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Message Composer Behavior . . . . . . . . . . . . . . . . 4
3.3 Status Message Receiver Behavior . . . . . . . . . . . . . 5
3.4 Additional Status Information . . . . . . . . . . . . . . 6
4. Using the Status Message . . . . . . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 8
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' . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
10.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Schulzrinne Expires November 13, 2004 [Page 2]
Internet-Draft iscomposing May 2004
1. Introduction
By definition, instant messaging (IM) is message-based, i.e., a user
composes a message by 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 that the other party is
waiting for a response. If no response is forthcoming, a participant
in an instant messaging conversation may erroneously assume that
either 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 that is sent as soon as one
party starts typing a message. In this document, we describe a
generalized version of this indication, called isComposing. As
described in Section 3 in more detail, a status message is delivered
to the instant message recipient in the same manner as the messages
themselves. The isComposing 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.
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 [5], were also
considered, but have a number of disadvantages. They add more
overhead, since 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 [6].
2. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [1]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in this memo are
used in the same meaning as 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
Schulzrinne Expires November 13, 2004 [Page 3]
Internet-Draft iscomposing May 2004
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, that 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 draft 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
Only the instant messaging user agent actively composing a content
message generates status messages indicating the current state. When
the user first starts composing an 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 timeouts, the refresh time-out interval and the
idle time-out interval. The composing user MAY specify a refresh
time-out interval measured in seconds, using the <timeout> element in
the status message, after which the isComposing status message is
resent to refresh the state. The refresh period SHOULD be no shorter
than 60 seconds. A message composer MAY decide not to send refresh
messages at all and thus indicate no 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.)
The refresh mechanism deals with the case that 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. When the user starts composing again while
in "idle" state, the state transitions to "active", with the
corresponding status message being sent. Unless otherwise configured
Schulzrinne Expires November 13, 2004 [Page 4]
Internet-Draft iscomposing May 2004
by the user, the idle timeout SHOULD have a default value of fifteen
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.
The state transitions are shown in Figure 1.
+-------------+
|+-----------+|
|| ||
+------>| idle |<------+
| || || |
| |+-----------+| |
| +------+------+ |
| | | idle timeout
content msg. sent| |composing | w/o activity
-----------------| |-------------| ------------------
-- | |"active" msg.| "idle" status msg.
| +------V------+ |
| | | |
| | | |
| | | |
+------+ active +------+
| |
| |
+-------------+
Sender state diagram
Figure 1
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; it is 120 seconds otherwise. The state at the
receiver transitions from "active" to "idle" under three conditions:
Schulzrinne Expires November 13, 2004 [Page 5]
Internet-Draft iscomposing May 2004
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.
The state transitions are shown in Figure 2.
+-------------+
|+-----------+|
|| ||
+------>| idle |<------+
| || || |
| |+-----------+| |
| +------+------+ |
| | |
"idle" recd. | |"active" msg.| refresh timeout
or content recd. | | | or 120s
| | |
| +------V------+ |
| | | |
| | | |
| | | |
+------+ active +------+
| |
| |
+-------------+
Receiver state diagram
Figure 2
3.4 Additional Status Information
The status message contains additional optional elements to provide
further details on the composition activity.
The optional <lastactive> element describes the absolute time when
the user last added or edited content.
The optional <contenttype> element indicates what type of media the
messaging terminal is currently composing. It can contain either
just a MIME media type, such as "audio" or "text", or a media type
Schulzrinne Expires November 13, 2004 [Page 6]
Internet-Draft iscomposing May 2004
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.
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".
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.
4. Using the Status Message
The isComposing status message can be used with either page mode or
session mode, although it is a more natural fit with session mode.
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 a
stream is negotiated, i.e., through SDP. Sending the status messages
within the messaging stream has several 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 that message reordering
across two delivery mechanisms has an active indication appear at the
receiver after the actual message has been delivered.
Secondly, end-to-end security can be applied to the messages.
Thirdly, SDP negotiation mechanisms can be used to turn it on and off
at any time, and even negotiate its use in a single direction at a
time.
Usage with page mode is also straightforward. There, the status
message is carried as the body of a page mode message.
Unfortunately, there is no way to negotiate its usage, turn it on or
off, or even be sure that the status message gets delivered before
the actual content being composed arrives. (However, in SIP, page
mode is limited to one unacknowledged message, so that out-of-order
delivery is unlikely, albeit still possible if proxies are involved.)
Schulzrinne Expires November 13, 2004 [Page 7]
Internet-Draft iscomposing May 2004
5. Examples
<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
<state>active</state>
<contenttype>text/plain</contenttype>
<timeout>90</timeout>
<lastactivity>2003-01-27T10:43:00Z</lastactivity>
</isComposing>
<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
<state>idle</state>
<contenttype>audio</contenttype>
<lastactivity>2003-01-27T10:43:00Z</lastactivity>
</isComposing>
6. XML Schema Definition
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 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:
urn:ietf:params:xml:ns:im-iscomposing
Schulzrinne Expires November 13, 2004 [Page 8]
Internet-Draft iscomposing May 2004
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:im-iscomposing"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="isComposing">
<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:element>
</xs:schema>
7. Security Considerations
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
destination of the message will receive the isComposing indication.
Since the status messages are carried using the IM protocol itself,
all security considerations of the underlying IM protocol apply also
to the isComposing status messages.
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 in page mode whether a
message is in response to an earlier one, but elapsed time or user
interface behavior might be used as hints.
Schulzrinne Expires November 13, 2004 [Page 9]
Internet-Draft iscomposing May 2004
8. IANA Considerations
8.1 Content-Type Registration for 'application/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: XXXX (this document)
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 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.
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
RFCXXXX 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:
Schulzrinne Expires November 13, 2004 [Page 10]
Internet-Draft iscomposing May 2004
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>application/im-iscomposing+xml</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX</a>.</p>
</body>
</html>
END
9. Acknowledgements
Niemi Aki, Ben Campbell, Miguel Garcia, Christian Jansson, Cullen
Jennings, Hisham Khartabil, Jonathan Rosenberg and Xiaotao Wu
provided helpful comments.
10. References
10.1 Normative References
[1] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging:
Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
progress), January 2003.
[4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
10.2 Informative References
[5] Sugano, H. and S. Fujimoto, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
2003.
Schulzrinne Expires November 13, 2004 [Page 11]
Internet-Draft iscomposing May 2004
[6] Rosenberg, J., "Advanced Instant Messaging Requirements for the
Session Initiation Protocol (SIP)",
draft-rosenberg-simple-messaging-requirements-01 (work in
progress), February 2004.
Author's Address
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Schulzrinne Expires November 13, 2004 [Page 12]
Internet-Draft iscomposing May 2004
Intellectual Property Statement
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.
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.
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne Expires November 13, 2004 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-22 22:43:40 |