Network Working Group H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 30, 2004 March 2004
is-composing Indication for Instant Messaging Using the Session
Initiation Protocol (SIP)
draft-ietf-simple-iscomposing-00
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 August 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
In instant messaging systems, it is useful to know that the other
party is composing a message, e.g., typing. This document defines a
new content type and XML namespace that conveys information about a
message being composed. The message could be of any type, including
text, voice or video.
Schulzrinne Expires August 30, 2004 [Page 1]
Internet-Draft iscomposing March 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using the Indicator . . . . . . . . . . . . . . . . . . . . . 5
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8.1 Content-Type Registration for
'application/sip-iscomposing+xml' . . . . . . . . . . . . 6
8.2 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:sip-iscomposing' . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 8
10.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Schulzrinne Expires August 30, 2004 [Page 2]
Internet-Draft iscomposing March 2004
1. Introduction
By definition, instant messaging is message-based, i.e., a user
composes a message by typing, speaking or recording a video clip.
This message is then sent. Unlike email, instant messaging is often
conversational, so that the other party is waiting for a response.
If no response is forthcoming, an IM session participant may
erroneously assume that either the communication partner has left or
that it is her turn to type again, leading to messaging "crossing on
the wire".
To avoid this uncertainty, a number of commercial instant messaging
systems feature an "is-typing" indication that is set as soon as one
party starts typing a message. In this document, we describe a
generalized version of this indication. A status message is
delivered to the IM recipient in the same manner as the messages
themselves. The is-composing 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 IM user states in the future.
This indication 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
[I-D.ietf-impp-cpim-pidf], 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
gateway into non-SIP systems.
The mechanism described here aims to satisfy the requirements in
[I-D.rosenberg-simple-messaging-requirements].
2. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN,
PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the
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
XX, RFC 2119 [RFC2119].
Schulzrinne Expires August 30, 2004 [Page 3]
Internet-Draft iscomposing March 2004
3. Description
We model user behavior as states, initially limited to Idle and
Active. When the user first starts composing, the state becomes
Active and an isComposing message containing a <state> element
indicating "active" is sent. As long as the user produces message
content, the user remains in state Active. The composing user MAY
specify a time-out interval measured in seconds, using the <timeout>
element, after which the isComposing message is resent to refresh the
state. The refresh period SHOULD be no shorter than 60 seconds. If
the <timeout> element is omitted, the receiver should assume that no
refresh messages will be sent. Receivers MUST be able to handle
multiple isComposing messages with "active" state regardless of the
refresh interval.
The refresh mechanism deals with the case that the user logs off
or the application crashes before the 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" message
is sent. When the user starts composing again while in Idle state,
the state transitions to Active, with the corresponding message.
The idle timeout SHOULD be ten seconds.
If an instant message is sent before the idle threshold expires, no
idle state indication is needed. Thus, in most cases, only one
message is needed. The message rate is limited to one message per
idle threshold interval.
The optional <lastactivity> element describes the absolute time when
the user last added or edited content.
The optional <contenttype> element indicates what type of media the
IM 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".
The XML schema can be extended in the future. Recipients of messages
implementing this specification MUST treat state tokens other than
"idle" and "active" as "idle".
The isComposing indicator MAY be carried in CPIM messages
[I-D.ietf-impp-cpim-msgfmt].
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.
Schulzrinne Expires August 30, 2004 [Page 4]
Internet-Draft iscomposing March 2004
4. Using the Indicator
The is-composing indicator can be used with either SIP page mode or
session mode, although it is a more natural fit with session mode.
In session mode, the indicator is sent as part of the messaging
stream. Its usage is negotiated just like support for any other media
type in a stream is negotiated, i.e., through SDP. Sending the
indicators within the messaging stream has many benefits. First, it
ensures proper sequencing and synchronization with the actual
messages being composed. 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 the page mode is also straightforward. The indicator would
be 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 indicator gets delivered before the actual content being
composed.
5. Example
<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:sip-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:sip-iscomposing"
<state>idle</state>
<contenttype>audio</contenttype>
<lastactivity>2003-01-27T10:43:00Z</lastactivity>
</isComposing>
Schulzrinne Expires August 30, 2004 [Page 5]
Internet-Draft iscomposing March 2004
6. XML Schema Definitions
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:sip-iscomposing"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:sip-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="tns:string"
minOccurs="1"/>
<xs:element name="lastactive" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="contenttype" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="timeout" type="xs:positiveInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:element>
</xs:schema>
7. Security Considerations
The is-composing 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 is-composing indication.
8. IANA Considerations
8.1 Content-Type Registration for 'application/sip-iscomposing+xml'
To: ietf-types@iana.org
Subject: Registration of MIME media type application/
sip-iscomposing+xml
MIME media type name: application
Schulzrinne Expires August 30, 2004 [Page 6]
Internet-Draft iscomposing March 2004
MIME subtype name: sip-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 [RFC3023],
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 [RFC3023], and many of the considerations
described there also apply to application/sip-iscomposing+xml.
8.2 URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:sip-iscomposing'
URI: urn:ietf:params:xml:ns:sip-iscomposing
Description: This is the XML namespace for XML elements defined by
RFCXXXX to describe composition activity by SIP-based instant
message client using the application/sip-iscomposing+xml content
type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu
XML:
Schulzrinne Expires August 30, 2004 [Page 7]
Internet-Draft iscomposing March 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
Using the Session Initiation Protocol (SIP)</title>
</head>
<body>
<h1>Namespace for SIMPLE iscomposing extension</h1>
<h2>application/sip-iscomposing+xml</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX</a>.</p>
</body>
</html>
END
9. Acknowledgements
Ben Campbell, Jonathan Rosenberg and Xiaotao Wu provided helpful
comments.
10. References
10.1 Normative References
[I-D.ietf-impp-cpim-msgfmt]
Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2778] Day, M., Rosenberg, J. and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
10.2 Informative References
[I-D.ietf-impp-cpim-pidf]
Sugano, H. and S. Fujimoto, "Presence Information Data
Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in
Schulzrinne Expires August 30, 2004 [Page 8]
Internet-Draft iscomposing March 2004
progress), May 2003.
[I-D.rosenberg-simple-messaging-requirements]
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 7005
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Schulzrinne Expires August 30, 2004 [Page 9]
Internet-Draft iscomposing March 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 August 30, 2004 [Page 10]
