Internet DRAFT - draft-coulombe-message-adaptation-requirements
draft-coulombe-message-adaptation-requirements
Network Working Group S.Coulombe, P.Pessi,
INTERNET-DRAFT J.Costa-Requena
<draft-coulombe-message-adaptation- Nokia
requirements-00>
Expires: April 2003 October 2002
Requirements for message adaptation in the context of SIP Instant
Messaging and Presence applications
draft-coulombe-message-adaptation-requirements-00
Status of this memo
This document is an Internet-Draft and is subject to 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 to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Some SIP instant messages (IM) and presence notifications may be too
large for a receiving user agent or may contain media types or
extensions not supported by the receiving User-Agents. This may
create serious interoperability problems in the future. This document
defines requirements for a SIP message adaptation framework providing
means to express the User-Agent capabilities and User preferences to
enable adaptation of SIP messages to meet the recipient's needs.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 1]
INTERNET-DRAFTdraft-coulombe-message-adaptation-requirements-00 October
2002
Table of Contents
1. Terminology.....................................................2
2. Introduction....................................................2
3. Examples and Use cases..........................................3
3.1 Instant Messaging............................................3
3.2 Presence.....................................................4
4. Requirements....................................................5
5. References......................................................6
6. Author's Address................................................7
7. Expiration Date.................................................7
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
2. Introduction
In the SIP Extensions for Instant Messaging framework [2], a user
composes a message (which may be composed of different media types)
and sends it to a recipient or a group of recipients using the SIP
MESSAGE method. This message is typically generated without
considering the recipients' user agent or terminal capabilities.
Although in some cases some information about the recipients'
capabilities could be obtained by sending a SIP OPTIONS request to
the recipients prior to composing the instant message, this would be
cumbersome for the sender, especially if the number of recipients
grows large or it contains some anonymous users, as it is case in the
chat rooms today. Indeed, users usually want to create messages
without having to care about the recipients' terminal capabilities.
They expect nevertheless that their messages will reach their
destinations and will be handled properly by the recipients'
terminal. Also, recipients may do not want to disclose what kind of
terminal they currently use, as it might reveal their identity or
current whereabouts to the prospective senders.
The users of adaptation service can use, for example, the caller
preferences to indicate their preferences on message adaptation. The
caller preferences can be used to indicate when an intermediate is
required to adapt the message to be received, or if the sent message
may be adapted.
In presence services based on SIP Extensions for Presence [3],
supported media types can be learned from the Accept header in the
SIP SUBSCRIBE message. However this information may not be
sufficient. For instance, the media type does not identify the
extensions used in the presence document. As in the case of IM,
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 2]
INTERNET-DRAFTdraft-coulombe-message-adaptation-requirements-00 October
2002
information about the maximum message size which can be sent to the
recipient or subscriber is missing from the SIP headers.
This situation is typically not a problem for the short text messages
mostly used today. But the situation may become problematic if the
messages become larger and composed of rich media components (images,
audiovisual clips, etc.). The emergence of mobile terminals will also
make this requirement more challenging, due to the wide diversity of
terminal characteristics: display size and resolution, available
memory, formats supported, etc. As stated, the received message may
be too large for the recipient's terminal memory [4]. The mobile
terminal may also not support certain media types or may support them
only under certain conditions (e.g. the resolution of a JPEG [5]
image may need to be under a certain limit).
To ensure interoperability and best user experience, it is proposed
that the messages be adapted to the capabilities of the recipients'
terminals. For that to be possible, we need to define a multimedia
adaptation framework for SIP messages. Such a framework would enable
either adaptation directly by sender, or in an intermediate SIP
server or a SIP-server-controlled server (e.g., a transcoding
device). The use of intermediaries, while making it harder to provide
end-to-end security, enhances the sender's experience of the service
because he doesn't have to worry about the recipients' terminal
capabilities. It also enhances the recipient's experience because he
can receive a message suited for the capabilities of his terminal,
not a message downgraded to the level of lowest common denominator.
3. Examples and Use cases
This section presents some examples and use cases for SIP message
adaptation. They are provided to illustrate the benefits and should
not limit the scope or applicability of such message adaptation
mechanisms.
3.1 Instant Messaging
A user composes a SIP instant message to a single user. He often
doesn't have knowledge of the recipient's terminal capabilities and
he doesn't want to care about them. He sends the message and often
expects that it will reach the recipient and be handled properly by
the recipient's terminal.
Under such circumstance, it would useful if a SIP server (e.g. a
proxy) could adapt the message to meet the recipient's terminal
capabilities (or make request to another server to perform message
adaptation). The message adaptation operations could include:
1. Content indirection: some parts of message content parts can be
stored in an intermediate server while only a URI is forwarded
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 3]
INTERNET-DRAFTdraft-coulombe-message-adaptation-requirements-00 October
2002
to the recipient. This can help to reduce the overall message
size.
2. Format conversion: conversion to a media content format
supported by the terminal. For instance, GIF images [6] could be
converted to JPEG if not supported by the recipient's terminal.
This category includes conversion of layout formats (e.g. XHTML
to WML) and conversion of modality (e.g. speech to text).
3. Media characteristics adaptation: This involves any modification
of the media characteristics, including resolution reduction of
images for small displays, reducing the quality of JPEG images
or the number of colors in GIF images, changing the sampling
rate or number or channels of audio files.
4. Presentation or layout adaptation: this involves making the
content presentation suitable for the recipient's terminal
display characteristics. Although the presentation is mostly a
terminal implementation issue, some changes to the layout
component of a message may be required when changes are made to
media components (e.g. format conversion, resolution reduction
of images).
5. Message size adaptation: reducing the overall message size by
reducing the size of the media parts it contains, using content
indirection [4] or removing some parts in the worst case. Media
size reduction can be achieved through media characteristics or
format conversion. For instance, JPEG images can be reduced in
size by reducing their quality factor. This can often be done
without significant reduction in the perceived quality. The
conditions leading to media size reduction versus content
indirection or deletion could be controlled by the recipient's
preferences and capabilities. The mechanisms of [7] could be
extended to serve that purpose.
Note that when using SIP Instant Messaging, SDP cannot be used for
media negotiation as it is done for media sessions.
3.2 Presence
In the presence application, the presence server usually have
knowledge of the subscriber's supported media types through the
Accept header of the SIP SUBSCRIBE message. This would allow it to
directly create basic notification messages that are suitable for the
subscriber's terminal.
However more precise information about the characteristics and
extensions of the supported formats, such as the maximum supported
size, may be required. An intermediary adaptation service may be used
if, for instance, the presence server does not support advanced
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 4]
INTERNET-DRAFTdraft-coulombe-message-adaptation-requirements-00 October
2002
features found in subscriber's terminal, like delta notifications or
notification filtering.
Message adaptation operations similar to those described in the
previous sub-section may be used.
4. Requirements
REQ-1. An adaptation framework must be defined for SIP Instant
Messaging and Presence applications. This framework SHOULD define
the mechanisms required to support SIP message adaptation without
specifying or mandating the exact transformations to be performed
on the messages themselves. Such mechanisms include terminal
capability / user preferences negotiation [7], adaptation /
transcoding request protocol, etc.
REQ-2. It MUST be possible to adapt (or generate in the case of
Presence application) SIP messages automatically in a SIP
server/proxy to meet the recipient's terminal capabilities.
REQ-3. It SHOULD be possible to adapt (or generate in the case of
Presence application) SIP messages automatically in a SIP
server/proxy to meet the recipient's preferences.
REQ-4. A terminal capability exchange mechanism to provide the SIP
message adaptation server/proxy with the recipient's terminal
capabilities MUST be supported.
REQ-5. An exchange mechanism to provide the SIP message adaptation
server/proxy with the recipient's preferences SHOULD be supported.
REQ-6. It should be possible to store/cache the terminal
capabilities and recipient's preferences in a SIP server/proxy to
improve efficiency compared to a scenario of querying them for
each new incoming message.
REQ-7. It MUST be possible to provide to a SIP proxy/server the
capabilities of the terminal associated with each contact address
a user possesses.
REQ-8. It MUST be possible for SIP proxy/server to request other
servers to perform the adaptation of the message or of some parts
of the message. This would relieve the SIP proxy/server of some
heavy processing operations (e.g. video clip adaptation). A
specific protocol between SIP proxy/server and adaptation
(transcoding) entities MUST be used for that purpose.
REQ-9. The SIP message adaptation server/proxy MUST ensure that the
adapted message contents meets the message size limitations of the
recipients.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 5]
INTERNET-DRAFTdraft-coulombe-message-adaptation-requirements-00 October
2002
REQ-10. The SIP message adaptation server/proxy SHOULD be able to use
content indirection mechanisms [4] to reduce the message size
either based on recipient's preferences or if the message can't be
reduced to meet the terminal capabilities without deleting or
drastically reducing the component quality. If content indirection
method is used, the server/proxy MUST provide in the adapted
message a reference for each content part on which that method was
applied and ensure they are accessible an appropriate length of
time.
REQ-11. The SIP message adaptation server/proxy or SIP server-proxy-
controlled server SHOULD include in the adapted message some data
to inform the recipient that the received message differs from the
original one.
REQ-12. The SIP message adaptation server/proxy or SIP server-proxy-
controlled server MUST provide alternative access to the original
message contents if the original message contents were secured
using S/MIME or other security protocols.
5. References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997.
[2] J. Rosenberg et al., "SIP Extensions for Instant Messaging",
draft-rosenberg-impp-im-01," (work in progress), February, 2001,
http://www.ietf.org/html.charters/simple-charter.html.
[3] J. Rosenberg et al., "SIP Extensions for Presence, draft-
rosenberg-impp-presence-01.txt," (work in progress), March,
2001, http://www.ietf.org/html.charters/simple-charter.html.
[4] S. Olson, "Requirements for Content Indirection in Session
Initiation Protocol (SIP) Messages," Internet Draft draft-ietf-
sipping-content-indirect-02, September 2002.
[5] "Digital compression and coding of continuous-tone still
images," ISO/IEC IS 10918-3, ITU-T Recommendation T.84, 1990
(JPEG specification).
[6] "Graphics Interchange Format, version 89a," Programming
Reference, CompuServe, Inc., 1990. URL:
http://256.com/gray/docs/gifspecs.
[7] H. Schulzrinne, J. Rosenberg, "Session Initiation Protocol (SIP)
Caller Preferences and Callee Capabilities," Internet Draft
draft-ietf-sip-callerprefs-06.txt, July 2002.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 6]
INTERNET-DRAFTdraft-coulombe-message-adaptation-requirements-00 October
2002
6. Author's Address
Stephane Coulombe
Nokia Research Center
6000, Connection Drive, M2-700
Irving, Texas, 75063
USA
E-mail: Stephane.Coulombe@nokia.com
Pekka Pessi
Nokia Research Center
Itamerenkatu 11-13
00180 Helsinki
Finland
E-mail: Pekka.Pessi@nokia.com
Jose Costa-Requena
Nokia Mobile Phones
Valimotie 9,
00380 Helsinki
Finland
E-mail: Jose.Costa-Requena@nokia.com
7. Expiration Date
This memo is filed as <draft-coulombe-message-adaptation-
requirements-00> and expires in April 2003.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 7]
