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]