TOC 
Network Working GroupH. Schulzrinne
Internet-DraftColumbia U.
Expires: August 30, 2004March 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.



Table of Contents

1.  Introduction
2.  Terminology and Conventions
3.  Description
4.  Using the Indicator
5.  Example
6.  XML Schema Definitions
7.  Security Considerations
8.  IANA Considerations
    8.1  Content-Type Registration for 'application/sip-iscomposing+xml'
    8.2  URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:sip-iscomposing'
9.  Acknowledgements
§.  Normative References
§.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

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 PIDFSugano, H. and S. Fujimoto, Presence Information Data Format (PIDF), May 2003.[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]Rosenberg, J., Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP), February 2004..



 TOC 

2. Terminology and Conventions

This memo makes use of the vocabulary defined in the IMPP Model document [RFC2778]Day, M., Rosenberg, J. and H. Sugano, A Model for Presence and Instant Messaging, February 2000.. 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 2119Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.[RFC2119].



 TOC 

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]Atkins, D. and G. Klyne, Common Presence and Instant Messaging: Message Format, January 2003..

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.



 TOC 

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.



 TOC 

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>


 TOC 

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>


 TOC 

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.



 TOC 

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
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 3023Murata, M., St. Laurent, S. and D. Kohn, XML Media Types, January 2001.[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 3023Murata, M., St. Laurent, S. and D. Kohn, XML Media Types, January 2001.[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:
 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


 TOC 

9. Acknowledgements

Ben Campbell, Jonathan Rosenberg and Xiaotao Wu provided helpful comments.



 TOC 

10. References



 TOC 

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 (HTML, XML).
[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.


 TOC 

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


 TOC 

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


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment