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
<draft-koskelainen-imtpext-00.txt>
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