Network Working Group S.Coulombe, P.Pessi, INTERNET-DRAFT J.Costa-Requena 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 and expires in April 2003. Coulombe, Pessi, Costa-RequenaExpires: April 2003 [Page 14]