[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-schulzrinne-simple-iscomposing) 00 01 02 03 RFC 3994

Network Working Group                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: February 8, 2005                                August 10, 2004


        Indication of Message Composition for Instant Messaging
                    draft-ietf-simple-iscomposing-03

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 February 8, 2005.

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 February 8, 2005                [Page 1]

Internet-Draft                iscomposing                    August 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 . . . . . . . . . . . . .  6
     3.4   Message Content  . . . . . . . . . . . . . . . . . . . . .  7
     3.5   Additional Status Information  . . . . . . . . . . . . . .  7
   4.  Using the Status Message . . . . . . . . . . . . . . . . . . .  8
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  XML Document Format  . . . . . . . . . . . . . . . . . . . . .  9
     6.1   XML Schema . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   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 . . . . . . . . . . . . . . . . . . . . . . . 12
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 12
   10.2  Informative References . . . . . . . . . . . . . . . . . . . 12
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14
























Schulzrinne             Expires February 8, 2005                [Page 2]

Internet-Draft                iscomposing                    August 2004


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 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 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
   the messages themselves.  The isComposing status 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. 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 [7], 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 [8].

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



Schulzrinne             Expires February 8, 2005                [Page 3]

Internet-Draft                iscomposing                    August 2004


   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
   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 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.
   It indicates that 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.





Schulzrinne             Expires February 8, 2005                [Page 4]

Internet-Draft                iscomposing                    August 2004


      The active-state 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
   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.

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



   Sender state diagram



Schulzrinne             Expires February 8, 2005                [Page 5]

Internet-Draft                iscomposing                    August 2004


                                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:

   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





Schulzrinne             Expires February 8, 2005                [Page 6]

Internet-Draft                iscomposing                    August 2004


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. All of these can appear
   in both "active" and "idle" state messages.

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

   In order 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 such 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.






Schulzrinne             Expires February 8, 2005                [Page 7]

Internet-Draft                iscomposing                    August 2004


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
   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 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, session 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.  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 gets delivered
   before the actual content being composed arrives.  However, SIP page
   mode is limited to one unacknowledged message, so that 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>








Schulzrinne             Expires February 8, 2005                [Page 8]

Internet-Draft                iscomposing                    August 2004


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

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>






Schulzrinne             Expires February 8, 2005                [Page 9]

Internet-Draft                iscomposing                    August 2004


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.

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






Schulzrinne             Expires February 8, 2005               [Page 10]

Internet-Draft                iscomposing                    August 2004


   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:

    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]">RFCXXXX</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






Schulzrinne             Expires February 8, 2005               [Page 11]

Internet-Draft                iscomposing                    August 2004


   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.

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.

   [5]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
        2004.

   [6]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

10.2  Informative References

   [7]  Sugano, H. and S. Fujimoto, "Presence Information Data Format
        (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
        2003.

   [8]  Rosenberg, J., "Advanced Instant Messaging Requirements for the
        Session Initiation Protocol  (SIP)",
        draft-rosenberg-simple-messaging-requirements-01 (work in
        progress), February 2004.






Schulzrinne             Expires February 8, 2005               [Page 12]

Internet-Draft                iscomposing                    August 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 February 8, 2005               [Page 13]

Internet-Draft                iscomposing                    August 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 February 8, 2005               [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/