Internet Engineering Task Force Petri Koskelainen, Nokia INTERNET-DRAFT Henning Schulzrinne, Columbia U. January, 2002 Expires: June, 2002 IMTP Extensions for Message Threading and Message Identification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract The IMTP specification defines a session-based IM transport as well as the message format for it. However, it does not support message threads or discussion topics which are useful in applications such as multi-party chat. This document defines extensions to IMTP which allow applications to utilize threads and sub-threads within an IMTP message session. Also, the extensions enable message identification. 1 Introduction Two models of IM operation are under discussion, the "paging" mode of operation and the session mode. For the latter, the IM transport protocol (IMTP) [3] has been defined. IMTP is almost identical to SIP [1]. In fact, IMTP borrows all of its headers from SIP. However, IMTP has some limitations. For example, it does not support message threading or identification [4]. Both are very useful in applications such as multi-party chat. This document defines IMTP extensions to support threading and message identifications by adding three new headers to IMTP. It can be argued that these extensions should be in the payload rather in the protocol level. However, having them in the protocol level enables the usage of pure ASCII messaging and eliminates the need to define additional payload formats. Also, it applies to the whole IM, not just a part of it in the case of multipart message. 2 Requirements New requirements in addition to those presented in [3] are defined here with more focus on application needs. The main new requirement is the ability to support messaging threads and sub-threads. For example, in multi-party chat there are often several discussion threads (or chat topics) going on. It should be possible to be able to differentiate the threads. Typically, they have different topics and some kind of identifier is required so that the user interface can present them accordingly. See [4] for more detailed description of message threading. Secondary requirement is the ability to identify every instant message. 3 Extensions We define following new IMTP headers: Subject, Message-ID and References. Thread identification is provided by utilizing both Message-id and References headers. In theory, it could be achieved by just one header (such as thread-id). However, this approach does not enable sub-threading so it is better to use two headers for it. The syntax is expressed in ABNF like in SIP [1]. Subject This header is borrowed directly from SIP. Message-ID This is a new header. It is generated for each new IMTP message inside a session. This is similar to the NNTP message-id [5]. It allows message threading and also, it creates unique identifier for an instant message so it can be identified or referenced afterwards. The Message-ID header is always kept as is. For example, the chat server does not rewrite it when it constructs new instant message from incoming instant message. Syntax: messageid = token [ATSIGN token] Message-ID = "Message-ID" HCOLON messageid Example: Message-ID: xyz123456789@130.230.6.7 References This is a new header. The References header enumerates the message-id that this IMTP message references (or replies). It has only one value unlike in NNTP which allows several values. This keeps the message size small while still allowing threading and sub-threading. Syntax: References = "References" HCOLON messageid Example: References: xyz123456789@130.230.6.7 4 Usage with SDP Since this is an extension to IMTP it is not clear whether other parties support the extensions. SDP [2] includes only the information that IMTP is used. However, it is not necessary to know about these extensions in advance since they are optional features. Clients are free to include these headers and utilize them if they are available in the IMs. Otherwise, clients just silently ignore the headers they do not understand. 5 Examples Each member has a direct connection with the chat server and new Request-URIs have been agreed on. The following IMTP messages are exchanged. 200 OK's not included. (examples between userA and the server) An IM sent by UserA to the server: MESSAGE sip:abcdefg@1.2.3.4 IMTP/1.0 From: sip:userA@domain1.com To: sip:chat-group@server.com Call-ID: kkjjhhggffddaa@1.1.1.1 CSeq: 777 MESSAGE Via: SIP/2.0/TCP 1.1.1.1 Message-ID: abcqwerty@1.1.1.1 Subject: New Movie Content-Type: text/plain Content-Length: ... Did you see the new trailer for Attack of the Clones? An IM sent by the server to userA, originally from UserB: MESSAGE sip:gfedcba@1.1.1.1 IMTP/1.0 From: sip:userB@domain2.com To: sip:chat-group@server.com Call-ID: kkjjhhggffddaa@1.1.1.1 CSeq: 111 MESSAGE Via: SIP/2.0/TCP 1.2.3.4 Message-ID: zxcvb@2.3.4.5 Subject: Re: New Movie References: abcqwerty@1.1.1.1 Content-Type: text/plain Content-Length: ... Yes I did!! An IM sent by the server to userA, originally from userC: MESSAGE sip:gfedcba@1.1.1.1 IMTP/1.0 To: sip:chat-group@server.com From: sip:userC@domain3.com Call-ID: kkjjhhggffddaa@1.1.1.1 CSeq: 112 MESSAGE Via: SIP/2.0/TCP 1.2.3.4 Message-ID: poiuytrew@6.7.8.9 References: abcqwerty@1.1.1.1 Subject: Re: New Movie Content-Type: text/plain Content-Length: ... I saw it, too. 6 Usability in Paging Mode These headers can also be used in paging mode. For example, if an important paging mode instant message is sent it may be useful to label it with unique id (the Message-ID) so it can be referenced afterwards ("I sent the information Dec 12, 2000 in an instant message XYZ"). References header can also be used in paging mode since basic SIP entities can safely ignore it. It may have some added value such as if it is a reply to some previous paging IM it may reference to it and UI is able to show it accordingly. It is also useful for VoIP calls. For example, in an INVITE request there may be a reference to a specific instant message hinting that the call relates to (the topic of) that instant message. However, paging mode (SIP) extensions are beyond the topic of this draft. This draft defines only the IMTP extensions. 7 Authors' Addresses Petri Koskelainen Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: petkos@cs.columbia.edu electronic mail: petri.koskelainen@nokia.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu 8 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. [3] J. Rosenberg et al, "A Proposal for IM Transport", Internet-draft, draft-rosenberg-simple-im-transport-00.txt (work in progress), Nov 2001. [4] P. Koskelainen, H. Schulzrinne, "Group Messaging in SIP", Internet-draft, draft-koskelainen-sip-group-00.txt, (work in progress), July 2001. [5] M. Horton, "Standard for Interchange of USENET Messages", Request for Comments 850, Internet Engineering Task Force, June 1983