GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3994

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.

4. Using the Status Message

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

Schulzrinne Standards Track [Page 7] RFC 3994 isComposing January 2005

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

5. Examples

 <?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>

6. XML Document Format

 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:
    urn:ietf:params:xml:ns:im-iscomposing

Schulzrinne Standards Track [Page 8] RFC 3994 isComposing January 2005

6.1. XML 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

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

Schulzrinne Standards Track [Page 9] RFC 3994 isComposing January 2005

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

Schulzrinne Standards Track [Page 10] RFC 3994 isComposing January 2005

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:
  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

 This section registers a new XML schema per the procedures in [5].
 URI: urn:ietf:params:xml:schema:im-composing
 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
    Henning Schulzrinne (hgs@cs.columbia.edu).
 The XML for this schema can be found as the sole content of Section
 6.1.

9. Acknowledgements

 Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson,
 Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi,
 Jonathan Rosenberg, and Xiaotao Wu provided helpful comments.

Schulzrinne Standards Track [Page 11] RFC 3994 isComposing January 2005

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]  Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
      (CPIM): Message Format", RFC 3862, August 2004.
 [4]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC
      3023, January 2001.
 [5]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
      2004.

10.2. Informative References

 [6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
      J. Peterson, "Presence Information Data Format (PIDF)", RFC
      3863, August 2004.
 [7]  Rosenberg, J., "Advanced Instant Messaging Requirements for the
      Session Initiation Protocol  (SIP)", 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 Standards Track [Page 12] RFC 3994 isComposing January 2005

Full Copyright Statement

 Copyright (C) The Internet Society (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.
 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.
 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.

Acknowledgement

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

Schulzrinne Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3994.txt · Last modified: 2005/01/31 17:18 (external edit)