Internet DRAFT - draft-coulombe-message-adaptation-framework
draft-coulombe-message-adaptation-framework
Network Working Group S.Coulombe, P.Pessi,
INTERNET-DRAFT J.Costa-Requena
<draft-coulombe-message-adaptation- Nokia
framework-00>
Expires: April 2003 October 2002
A framework for message adaptation in the context of SIP Instant
Messaging and Presence applications
draft-coulombe-message-adaptation-framework-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
This Internet-Draft presents a message adaptation framework that
addresses the requirements presented in the document draft-coulombe-
message-adaptation-requirements-00. This document focuses mostly on
the issue of terminal capability exchange and the overall message
adaptation and delivery process.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 1]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
Table of Contents
1. Terminology.....................................................2
2. Introduction....................................................2
3. Proposed SIP message adaptation framework.......................3
3.1 The overall adaptation framework.............................3
3.1.1 General adaptation framework.............................3
3.1.2 Special case of Presence.................................4
3.1.3 Using Content Indirection................................4
3.1.4 Special case: CPI not part of registration data..........5
3.2 Capability Exchange..........................................6
3.2.1.1 Capability exchange method using Caller Preferences
and Callee Capabilities..............................7
3.2.1.2 Capability exchange method using header extensions...9
3.2.2 Capability descriptors..................................10
4. Security consideration.........................................11
5. Future work....................................................11
5.1 Capability and user Preference Information exchange.........11
5.2 Adaptation protocol.........................................12
5.3 Usage of content indirection in adaptation..................12
5.4 Usability issues............................................12
.....................12
7. References.....................................................12
8. Author's Address...............................................13
9. Expiration Date................................................14
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
The requirement document [5] identified the need for a content
adaptation framework in the scope of SIP Instant Messaging and
Presence applications.
This document proposes such a framework and addresses the important
issue of terminal capability exchange. The requirement of defining an
adaptation/transcoding protocol is left for future work since it is
more important to define the right adaptation framework first.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 2]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
3. Proposed SIP message adaptation framework
This section proposes an adaptation framework for SIP Instant
Messaging and Presence applications.
3.1 The overall adaptation framework
3.1.1 General adaptation framework
The proposed message adaptation framework is illustrated in Figure 1.
First, when a terminal registers to its SIP registrar, it provides its
Capabilities and the user's Preferences Information (CPI) using an
agreed method such as SIP header extension (described below), Caller
Preferences and Callee Capabilities [6], etc. Details of how the
information can be exchanged is provided in sub-section 3.2.
User 1 User 2
1:REGISTER (with CPI) *******************
----------------------->* Home SIP *
* proxy/registrar * 2:MESSAGE (original msg)
* *<------------------------
4:MESSAGE (adapted msg) * 3:Adapt message *
<-----------------------* *
*******************
Figure 1: Adaptation framework for SIP messages.
The registrar stores the received CPI along with the usual
registration data (e.g. contact address). Note that storing the
registration data is an operation already handled by registrars.
Extending their functionality to store CPI in addition should be
trivial although it requires more storage capacity.
Later, when a SIP message arrives to the recipient's home SIP proxy
(step 2 in Figure 1), the SIP proxy uses the registration data
gathered by the SIP registrar (often the proxy and registrar are the
same entity or at least share common registration database) to learn
about the present contact address along with the associated
preferences and terminal capabilities. The messages of interest here
can be Instant Messages (MESSAGE method), Notifications (NOTIFY
method) or any other request messages that contain message body which
the proxy can adapt.
The SIP proxy then adapts the message to meet the terminal's
capabilities and user's preferences (step 3 in Figure 1). It
alternatively can request another server to perform the message
adaptation. The adaptation process may lead to the usage of content
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 3]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
indirection techniques [4] if the resulting message would be too
large for the terminal at an acceptable quality.
The adaptation operations can include the operations described in
more details in [5]:
1. Content Indirection (see section 3.1.3).
2. Format conversion.
3. Media characteristics adaptation.
4. Presentation or layout adaptation.
5. Message size adaptation.
Finally the adapted SIP message is sent to the recipient's terminal
(step 4 in Figure 1).
3.1.2 Special case of Presence
In the case of presence application, the notification message can be
adapted in the recipient's SIP proxy as presented previously.
However, it is often better if the presence server generates
appropriate content in the first place and sends it. To enable that,
the terminal CPI can also be negotiated with the presence server
during the subscription request (SUBSCRIBE) using the same mechanisms
suggested in section 3.2. The presence server will then create
notifications that suit the destination CPI as well as some user
preferences. The process is illustrated in Figure 2.
User 1 User 2
1:SUBSCRIBE (with CPI) ********************
----------------------->* SIP *
* presence server * 2: (publish)
* *<-------------
4:NOTIFY (message) * 3:Create message *
<-----------------------* based on CPI *
********************
Figure 2: Adaptation framework extension for presence.
3.1.3 Using Content Indirection
The SIP proxy/registrar can decide to use the content indirection if
it either can decide from recipient's preferences (e.g. [6]) that
recipient is not willing to directly receive the message contents, if
the recipient's preferences are not known, or if there are multiple
user agents possibly receiving the message (in that case it is more
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 4]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
efficient to send only links to the content and adapting only when
the content is requested than adapting the message for each possible
receiving terminal).
The process is illustrated in the Figure 3. The SIP proxy server
receives a new message (step 2). The server decides that it is not
able to perform content adaptation or even the adapted contents
cannot be sent using SIP. The original contents are stored in the
server (step 3) then a link to the contents is sent to the
recipient(s) (step 4). The need for CPI can be indicated here, too.
When a recipient decides to obtain the message contents, it includes
its CPI in the HTTP GET request (step 5). The server then performs
the adaptation (step 6) then includes the adapted contents in the
response to the GET (step 7).
1:REGISTER *******************
----------------------->* SIP *
* proxy/registrar * 2:MESSAGE (original msg)
* *<------------------------
4:MESSAGE (indirect). * 3:Store contents*
<-----------------------* *
* *
5:GET (indirect-uri) * *
----------------------->* *
(with CPI) * *
* *
7:response(adapted msg) * 6:Adapt contents*
<-----------------------* *
*******************
Figure 3: Using content indirection with content adaptation.
The adaptation is performed when the recipient fetches the message
contents using the indirection URI. The recipient can include its CPI
in the fetch request.
The adaptation can be combined with content indirection. If a message
contains an audio clip, an image and a SMIL description, the audio
clip and image can be stored in the server and the SMIL description
would be adapted to include only URLs to the clip and image.
Note that the contents may be stored in a different server from the
SIP proxy/registrar. More details about content indirection usage and
interaction with a Content Storage Server can be found in [12].
3.1.4 Special case: CPI not part of registration data
If for any reason, the terminal CPI is not part of the registration
data, it could be queried using the OPTIONS method.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 5]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
The process would be as illustrated in Figure 4. The SIP proxy
receives a new message (step 2). It tries to get CPI from the
registrar but it is not available (e.g. it was not received or stored
in step 1). It then sends an OPTIONS request to the recipient's
terminal which responds with its CPI (steps 3.1 and 3.2). The SIP
proxy uses it to adapt the message (step 4). It finally sends the
adapted message to the recipient (step 5).
User 1 User 2
1:REGISTER *******************
----------------------->* SIP *
* proxy/registrar * 2:MESSAGE (original msg)
* *<------------------------
3.1:OPTIONS REQ. * *
<-----------------------* *
* *
3.2:OPTIONS RESP. (CPI) * *
----------------------->* *
* *
5:MESSAGE (adapted msg) * 4:Adapt message *
<-----------------------* *
*******************
Figure 4: Usage of OPTIONS method to obtain CPI.
In the presence application, the OPTIONS method can be used similarly
by the presence server to obtain the CPI if not provided during the
subscription request.
This manner of obtaining CPI is less preferred because it requires
the proxy to query the terminal every time a new message is
delivered. For that reason, the CPI information should be cached in
order to avoid further requests for obtaining the CPI data from the
terminal.
Alternatively, if the registration or subscription request doesn't
contain CPI, the registrar could query them using the OPTIONS method.
It would then store them just as if they were obtained from the
registration or subscription.
3.2 Capability Exchange
As described in the previous sections, capability exchange is
provided during registration or subscription. An advantage is that
the CPI is stored in the server and doesn't need to be queried each
time a new message arrives. The terminal needs to update CPI only
when it changes (similarly to the contact address that needs to be
updated only when changed).
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 6]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
We propose a simple solution for capability exchange. The solution
introduces new feature tags in the Caller Preferences and Callee
Capabilities [6][9] to provide more detailed information about the
CPI. It also extends the existing SIP headers [7][8]. The solution is
such that the same CPI can be expressed in the Caller Preferences and
Callee Capabilities or alternatively in the SIP headers.
New feature tags and MIME header extensions are required to support
message adaptation. For instance, with mobile terminals, it is not
enough to specify which formats are supported but also the
limitations of the characteristics they may possess (e.g. jpeg image
format is supported only if the resolution doesn't exceed 160x120
pixels).
One first important characteristic of mobile terminals is the maximum
message body size they can handle. This could be expressed with a new
feature "length" tag. The length could also apply to specific MIME
types as their support could also be limited.
Another important characteristic of mobile terminals is the maximum
resolution of visual media types (such as images or video) that they
can handle. This may be related to the display resolution but more
often not. Often, the maximum resolution that can be handled exceeds
the display resolution.
The framework allows more characteristics to be added following the
registration procedure of [10].
3.2.1.1 Capability exchange method using Caller Preferences and Callee
Capabilities
We present in this sub-section how the proposed descriptors are used
in the context of Caller Preferences and Callee Capabilities [6]
which is based on [9].
The limit on the message size for a terminal is represented as
follows [6]:
( & (encoding="identity") (length<=32768) )
This specifies that the maximum message body size can't exceed
32kilobytes. This would include the total size of all the body parts
of the message without headers. Thus a terminal should reserve some
memory for the headers since their length can't be known and depend
on the message transmission (e.g. adding route in SIP).
The terminal message size limit requires the registration of two
media feature tags: encoding and length. The encoding media feature
tag corresponds to the Accept-Encoding header of SIP messages.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 7]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
Since some MIME types may also be limited in size, a length parameter
can be associated with a media type as follows:
( & (type="image/jpeg") (length<=32768) );q=0.8
This specifies that jpeg images can't exceed 32 kilobytes. Note that
the "type" media feature tag is already registered.
Two proposed media tags called "media-pix-x" and "media-pix-y"
provide information about the maximum (or minimum) horizontal and
vertical resolutions supported by the terminal for visual media. It
could apply to a specific MIME type or for a whole media category
(e.g. images). For instance:
(| (& (type="image/jpeg")(media-pix-x<=640)(media-pix-y<=480));q=0.9
(& (type="image/gif") (media-pix-x<=160)(media-pix-y<=120));q=1))
is used to specify that the terminal can support JPEG images no
larger than 640x480 and GIF no larger than 160x120. On the other
hand:
(& (type="image/*")(media-pix-x<=640)(media-pix-y<=480));q=0.7
means that all images are acceptable as long as they don't exceed
640x480 pixels. However in typical mobile terminals, it is more
likely that the supported image formats and their specific
characteristic restrictions will be listed explicitly. Note that
"pix-x" and "pix-y" are registered media tags representing display
resolution [11]. "Media-pix-x" and "media-pix-y" complement them by
presenting the maximum resolution handled for different media types.
Different quality values represent different capability preferences
similarly to [7][8]. For instance,
(|(& (type="image/gif")(media-pix-x<=640)(media-pix-y<=480));q=0.5
(& (type="image/gif") (media-pix-x<160)(media-pix-y<120));q=1))
means that GIF images of resolution smaller than 160x120 pixels are
preferred but GIF images of resolution up to 640x480 are still
supported by the terminal. This preference may be expressed by a
terminal having a small display resolution with low memory.
This information can be mapped to SIP contact parameters as
illustrated in [9]. However, the document only maps equality
comparisons (e.g. type= image/gif"). We propose to introduce "max+"
to represent "<=", "max-" to represent "<", "min+" to represent ">="
and "min-" to represent ">". For instance, the last example would map
to:
;type="image/gif";q=0.5;media-pix-x=max+640;media-pix-y=max+480
;type="image/gif";q=1;media-pix-x=max-160;media-pix-y=max-120
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 8]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
3.2.1.2 Capability exchange method using header extensions
We now present how the CPI can be represented as MIME header
extensions of SIP headers. We are using the same mapping for the
feature comparison operators (<,<=,>,>=) as described above. We
present here the same examples provided in the previous sub-section
but using the proposed header extension method. Limiting the size of
messages to 32kilobytes would be represented as:
Accept-Encoding: identity;length=max+32768
To specify that jpeg images can't exceed 32 kilobytes, we use:
Accept: image/jpeg; q=0.8;length=max+32768
Note that a Max-Size header was introduced in [12]. It describes the
whole message size limit including all SIP headers while we are
describing here a size limit that applies to the message body only
and to specific media types within the message (e.g. image/jpeg). The
size limit in [12] can also be used to provide size limitations
related to numerous transport mechanisms.
To specify that the terminal can support JPEG images no larger than
640x480 and GIF no larger than 160x120, we use:
Accept: image/jpeg ;q=0.9;media-pix-x=max+640;media-pix-y=max+480,
image/gif;q=1;media-pix-x=max+160;media-pix-y=max+120
On the other hand:
Accept: image/*;q=.7;media-pix-x=max+640;media-pix-y=max+480
means that all images are acceptable as long as they don't exceed
640x480 pixels.
The following means that GIF images of resolution smaller than
160x120 pixels are preferred but GIF images of resolution up to
640x480 are still supported by the terminal.
Accept: image/gif;q=0.5; media-pix-x=max+640;media-pix-y=max+480,
image/gif;q=1; media-pix-x=max-160;media-pix-y=max-120
Rules must however be followed in case of conflicts. For instance,
the following should be interpreted as all images are acceptable as
long as they don't exceed 640x480 pixels except for GIF that must be
below 160x120.
Accept: image/*;q=0.7; media-pix-x=max+640;media-pix-y=max+480,
image/gif;q=0.7; media-pix-x=max+160;media-pix-y=max+120
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 9]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
The capabilities associated with a more specific type (e.g.
image/gif) override more generic types (e.g. image/*) when the
same quality value is used.
When a capability header extension is not provided, the assumption is
that there is no limitation with respect to this capability.
We present now a more complex example taking into account the
concepts presented so far. The following represents, using the first
method, that messages must be no larger than 32kilobytes, that jpeg
is preferred but the resolution can't exceed 640x480 pixels and the
size must be smaller than 16 kilobytes, and that GIF images can't
exceed 160x120 pixels and their size must be smaller than 16
kilobytes:
(& ((encoding="identity") (length<=32768))
(| (& (type="image/jpeg")(media-pix-x<=640)
(media-pix-y<=480) (length<16384));q=0.9
(& (type="image/gif") (media-pix-x<=160)
(media-pix-y<=120) (length<16384));q=0.8 ))
The same example using the second method is represented as:
Accept-Encoding: identity;length=max+32768
Accept:image/jpeg;q=.9;media-pix-x=max+640;media-pix-y=max+480;
length=max-16384, image/gif;q=.8;media-pix-x=max+160;
media-pix-y=max+120;length=max-16384
In summary, the proposed exchange solution provides CPI in the
headers of the SIP message or as Caller Preferences and Callee
Capabilities during the registration (REGISTER method) or the
subscription (SUBSCRIBE method). The registrar or presence server is
responsible for extracting the relevant CPI and store it. It can be
used later for message adaptation. The method is extensible and
provides a way to express mathematical comparisons.
3.2.2 Capability descriptors
For content adaptation, the following headers are relevant [7]:
1. User-Agent: contains information about the client user agent (e.g.
Nokia7650/1.0(05.00)).
2. Accept: list of supported MIME types.
3. Accept-Encoding: list of acceptable content coding.
4. Accept-Charset: list of acceptable content charsets.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 10]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
The capability descriptors (media tags or header extensions) proposed
are:
1. length: maximum size of the entity specified. It could apply to
the whole message or to specific MIME types.
2. media-pix-x: horizontal resolution of visual media (e.g. image or
video). It could apply to all images or video or to specific MIME
types.
3. media-pix-y: vertical resolution of visual media (e.g. image or
video). It could apply to all images or video or to specific MIME
types.
More descriptors can be added as needed since the proposed method is
extensible. Such descriptions can include the number of channels or
sampling rate of audio formats or the frame rate in video formats.
The descriptors should be registered to IANA following the procedure
of [10].
4. Security consideration
The proposed adaptation framework assumes that components which may
require adaptation are not encrypted (e.g. using S/MIME). Otherwise,
unless the recipient's proxy/registrar is trusted (e.g. by providing
encryption/decryption keys in the registration), media component
adaptation can't be performed. However if the message components are
encrypted individually, content indirection can still be used in
order to reduce the overall message and allowing the recipient to
receive the components individually.
5. Future work
This document proposes an adaptation framework for SIP Instant
Messaging and Presence applications which could be extended to other
non-session-based applications. Once accepted, this framework needs
to be defined in more details to address the requirements of [5]. The
following items need to be addressed.
5.1 Capability and user Preference Information exchange
The terminal capability exchange method needs to be defined. This
includes defining the set of relevant descriptors and the CPI
vocabulary to use. This document presents only some initial
suggestions. The aspect of user preferences should also be addressed.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 11]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
5.2 Adaptation protocol
SIP proxies are meant to handle call process and perform light
signaling operations but certainly not to perform CPU-intensive
operations such as those often required in media transcoding. In
order to move the adaptation burden away from the SIP proxies, a
protocol should be defined to request message adaptation from
adaptation / transcoding servers. More detailed requirements of such
protocol needs to be established and solutions found.
5.3 Usage of content indirection in adaptation
The usage of content indirection [4] needs to be clarified in the
scope of SIP message adaptation. Indeed this mechanism may be needed
to avoid dropping media components in a message. The combination of
content indirection and content adaptation should also be clarified.
For instance, how to decide if we should reduce the size of a part to
reduce the size of the overall message or rather use content
indirection to achieve that goal? Should we be able to use both
mechanisms in the same message or should we decide which of the two
methods is more appropriate for a given message. It could be that the
proxy first attempts to perform content adaptation and if it fails
then uses content indirection as a fallback. The user may also
provide some rules on how the proxy should make the decision based on
his preferences.
5.4 Usability issues
There are usability issues associated with message adaptation. One of
them is the fact that if the received message is different from the
original one, the user should be informed. Also, it is possible that
a sender doesn't want its message or parts of it to be modified. The
usability issues with content indirection and receiving the OPTIONS
query to find out about terminal capabilities should be considered.
These issues and others should be addressed.
6. Intellectual Property Right Considerations
On IPR related issues, Nokia refers to its statement on patent
licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA.
7. 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.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 12]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
[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] S. Coulombe, "Requirements for message adaptation in the context
of SIP Instant Messaging and Presence applications," Internet
Draft draft-coulombe-message-adaptation-requirements-00, October
2002.
[6] H. Schulzrinne, J. Rosenberg, "Session Initiation Protocol (SIP)
Caller Preferences and Callee Capabilities," Internet Draft
draft-ietf-sip-callerprefs-06.txt, July 2002.
[7] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[8] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1," RFC 2616, June 1999.
[9] G. Klyne, "A syntax for describing media feature sets," RFC
2533, Internet Engineering Task Force, Mar. 1999.
[10] K. Holtman, A. Mutz, and T. Hardie, "Media Feature Tag
Registration Procedure," BCP 31, RFC 2506, March 1999.
[11] L. Masinter, K. Holtman, A. Mutz, and D. Wing, "Media Features
for Display, Print, and Fax," RFC 2534, March 1999.
[12] H. Khartabil, "Congestion safety and Content Indirection,"
Internet Draft draft-khartabil-sip-congestionsafe-ci-00, July
2002.
8. 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
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 13]
INTERNET-DRAFTdraft-coulombe-message-adaptation-framework-00October 2002
E-mail: Pekka.Pessi@nokia.com
Jose Costa-Requena
Nokia Mobile Phones
Valimotie 9,
00380 Helsinki
Finland
E-mail: Jose.Costa-Requena@nokia.com
9. Expiration Date
This memo is filed as <draft-coulombe-message-adaptation-framework-
00> and expires in April 2003.
Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 14]
