TOC |
|
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 (C) The Internet Society (2004). All Rights Reserved.
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.
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 |
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 |
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 |
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 |
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 |
<?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 |
<?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 |
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 |
- 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.
- 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 |
Ben Campbell, Jonathan Rosenberg and Xiaotao Wu provided helpful comments.
TOC |
TOC |
[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 |
[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 |
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 |
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.
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 (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.
Funding for the RFC Editor function is currently provided by the Internet Society.