Internet Draft Takashi Nishigaya Document: draft-nishigaya-sip-ccpp-00.txt Masanobu Yuhara Fujitsu Expiration Date: January, 2001 July 14, 2000 CC/PP exchange protocol based on SIP 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www. ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes a SIP extension for CC/PP (Composite Capability/Preference Profiles) exchange. CC/PPex, proposed by W3C, is only usable for client-pull service like HTTP. It is not suitable for server initiated push services. Since traditional SIP already has a method to convey the limited terminal capabilities for multimedia calls, SIP naturally extends to support CC/PP. This extension allows various types of push services to know the terminal capabilities before delivering the contents to the push clients. This is accomplished by introducing some additional headers in the REGISTER/OPTIONS message that carry the same information as CC/PPex does. Table of Contents 1 Introduction 2 Why use SIP as a CC/PP exchange protocol? 3 New SIP headers 3.1 Profile header 3.2 Profile-Diff header 3.3 Profile-Warning header 4 Message processing rules 4.1 Example of SIP server configuration 4.2 REGISTER 4.3 OPTIONS Nishigaya and Yuhara [Page 1] CCPP exchange protocol based on SIP July 14, 2000 5 Compatibility with SIP/2.0 5.1 CC/PP-aware client and traditional server 5.2 Traditional client and CC/PP-aware server 6 Relation to CC/PPex 7 Examples 7.1 Registration 7.2 CCPP retrieval 8 References 9 Authors' Addresses Nishigaya and Yuhara [Page 2] CCPP exchange protocol based on SIP July 14, 2000 1 Introduction When you design a server that provides services to various kinds of terminals, you sometimes want to present the information differently depending on the terminal capabilities and user preferences. It is especially true when you have to support the emerging web-phone terminals as well as ordinal PCs. The web-phone terminals have limited capabilities (e.g. small display size) and often support only a subset or a different set of content types (e.g. Compact HTML [1] for i-Mode terminals or WML [2] for WAP terminals, instead of the standard HTML). Moreover, some web-phone users may prefer to receive large pictures but most of them don't. The server needs to know the information on the terminal capabilities and user preferences so that it can appropriately tailor the presentation. The Composite Capability/Preference Profiles or CC/PP [3] is a working proposal in the W3C consortium that tries to provide a framework for such information. The framework consists of the CC/PP representation format and its transport protocols. In general, there are the pull services that are initiated by clients, and the push services that are initiated by servers. For the pull services, W3C is considering to utilize the HTTP extension mechanism (RFC 2774 [4]) and provide an extension for the CC/PP exchange (called CC/PPex [5]). We expect CC/PPex will be standardized for pull services, so we do not discuss it in this memo. As for the push services, however, CC/PPex cannot be used. It is because (1) the push protocol may not be based on HTTP, and (2) the push server may need to know the CC/PP information before it can contact the terminals in order to select an appropriate terminal from several terminals or to tailor the contents. Therefore, in this memo we will discuss a CC/PP transport protocol for the push services. When we consider a CC/PP transport for the push services, we have to take account of the frequency of the CC/PP changes and the frequency of push requests. In some cases, the push requests occur more rapidly than the CC/PP changes. In other cases, the CC/PP changes occur more rapidly than the push requests. The CC/PP transport protocol must perform efficiently in both cases. This document proposes to extend the Session Initiation Protocol (SIP) [6] so that it can transport the CC/PP information for the push services. The SIP protocol was originally designed for creating, modifying, and terminating the multimedia sessions for Internet telephones, conferences, etc. As we will describe in the next section, SIP is ideal for a CC/PP transport. If the push requests occur more rapidly than the CC/PP changes (we expect this is the normal case), the client can register its CC/PP information to a SIP registrar using a SIP REGISTER message and let the push initiator (or a push proxy server) to use the registered information repeatedly, thereby reducing the communication cost to the client, which is often high for the web-phones' wireless links. If the CC/PP Nishigaya and Yuhara [Page 3] CCPP exchange protocol based on SIP July 14, 2000 changes occur more rapidly than the push requests, the clients do not register the information, rather a SIP proxy server beside the registrar queries the client on demand using the SIP OPTIONS messages. The proposed changes to the SIP protocol include the introduction of three new header fields and new message processing rules. 2 Why use SIP as a CC/PP exchange protocol? We have chosen the SIP as the baseline for CC/PP exchange protocol, because it has the following advantages: CC/PP update and query: In order for push service to use CC/PP description, user agents must proactively update CC/PP repository which is accessible by push service. Otherwise, the push proxy or initiator must query CC/PP to the target user agent on demand. Both cases are realized by extending the existing SIP message functions. 1) The SIP registrar server accepts the REGISTER message to link/unlink the relationship between user and his/her user devices. The registrar server is also useful to gather CC/PP of user and his/her user agent by including the CC/PP description in the REGISTER message. 2) For querying CC/PP of a user or a user agent, the OPTIONS method is applicable for this purpose. The traditional SIP user agent, proxy and registrar accept the OPTION method and response the limited capability information about multimedia communications. It can be easily extended to support CC/PP metadata. Less impact on traditional SIP: The SIP message syntax is very close to HTTP/1.1 message syntax. CC/PPex, a CC/PP exchange protocol for pull services, is based on HTTP/1.1. Therefore, it is straightforward for us to incorporate CC/PPex specifications into SIP. SIP becoming major for VoIP: 3GPP has adopted SIP for the future All- IP network. We could expect various types of mobile phones with different capabilities use SIP for session control or content delivery. CC/PP over SIP is considered as one of good solutions for CC/PP exchange in the heterogeneous All-IP network. SIP extension for push: SIP extensions for push service, like presence information delivery [7] and instant messaging [8], are proposed. It is natural that both of push content delivery and CC/PP exchange are based on the same protocol SIP. It also helps to share the software components in the small devices with the limited resources. 3 New SIP headers Nishigaya and Yuhara [Page 4] CCPP exchange protocol based on SIP July 14, 2000 This section describes three new SIP headers: "Profile", "Profile- Diff" and "Profile-Warning." Note that these headers are the same as those defined in W3C NOTE of CC/PPex. The semantics and grammar of these headers are also the same. 3.1 Profile header The Profile header appears in a REGISTER request and is used to convey the list of references which address CC/PP descriptions. For a complete description, see section 5.2.1 of CC/PPex [5]. 3.2 Profile-Diff header The Profile-Diff header appears in a REGISTER request and is used to convey CC/PP description, if the Profile header contains one or more digests of the Profile-Diff header. For a complete description, see section 5.2.2 of CC/PPex [5]. 3.3 Profile-Warning header The Profile-Warning header appears in a REGISTER response and is used to let the user agent know whether the registrar succeeded to retrieve the CC/PP description or not. CC/PP-aware registrars must include the Profile-Warning header in the REGISTER response. For a complete description, see section 5.2.3 of CC/PPex [5]. 4 Message processing rules This section describes an example of a SIP server configuration and the usage of REGISTER and OPTIONS message for CC/PP exchange. The REGISTER message is used for uploading the CC/PP to the SIP server prior to the actual references. The OPTIONS message is used for on- demand query of CC/PP description. These two messages are already defined in SIP (RFC 2534 [6]), but the functions are extended. 4.1 Example of SIP server configuration A SIP server generally consists of registrar server, location service, CC/PP vendor default repository and CC/PP cache repository. The CC/PP exchange protocol using REGISTER message is shown in Fig. 1. The registrar server accepts the REGISTER (Section 4.2) request (step 1), contacts the location service to relate the end system address with the user address (step 2). If the REGISTER request contains Profile, the registrar server retrieves the default description from CC/PP vendor default repository and may merge it with the Profile-Diff header value (step 3). The resultant CC/PP description of the user agent obtained in step 3 may be cached in CC/PP cache repository for further references(step 4). Nishigaya and Yuhara [Page 5] CCPP exchange protocol based on SIP July 14, 2000 +----------+ +--------+ | CC/PP| |location| | vendor| |service | | default| | | |repository| | | +----------+ +--------+ ^: ^ ::defauls : 2: 3: get:: ......... reg. tk@eden, 1: REGISTER :: : tk@fujitsu.com eden tk@fujitsu.com :v : +-----+ tk@eden +---------+ +-----------+ |user |===============>|registrar|.........> |CC/PP cache| |agent|<---------------|server | 4: reg. |server | +-----+ 5: 200 OK +---------+ CC/PP +-----------+ ====> SIP request ----> SIP response ....> non-SIP protocols Figure 1: Example of CC/PP uploading The location service, the CC/PP vendor defaults repository and CC/PP cache repository may be co-located or separated with the registrar server. They may use other protocols, such as, LDAP (RFC 1777[9]), SQL or any platform dependent protocols at step 2, 3 and 4. The manner in which the registrar server interacts with them is beyond the scope of this document. The example of content negotiation for push service is shown in Fig. 2. Generally, there are two types of push destinations, user (person) or user agent (communication device). In order to create a tailored push content, push service needs to know the capabilities and the preferences of user or user agent, depending on the destination address. Our proposal supports both cases of the CC/PP retrieval. When the push proxy or the initiator decides to deliver a push message, it sends the OPTIONS (Section 4.3) request to the registrar server in order to obtain the CC/PP of the target user or user agent (step 1). The registrar server contacts the CC/PP cache repository or forwards the OPTIONS request to obtain the CC/PP description (step 2). The push proxy or the initiator examines the obtained CC/PP description of the user or its user agent and the content feature of the push message, prepares and delivers the tailored content for the selected user agent (step 3). Optionally, step 1 and 2 may be replaced by step 1' and 2', i.e., the push proxy or the initiator may directly access the location service, the CC/PP cache, or user agent to obtain the CC/PP description. Nishigaya and Yuhara [Page 6] CCPP exchange protocol based on SIP July 14, 2000 +----------+ +--------+ | CC/PP| |location| | vendor| |service | | default| | |<.................. |repository| | |..................: +----------+ +--------+ :: (tk@eden) :: :: 2: get :: +---------+ tk@eden +-----------+ :: |registrar|---------->|CC/PP cache| :: |server |<----------|server | :: +---------+ CC/PP +-----------+ :: ^ " :^ :: " | CC/PP ::(1': :: " +----+ +.......+: get) :: 1: OPTIONS +====+ | :+.......+ :: tk@fujitsu.com " | :: .................: " | :: :................. eden " v v: v: (2': tk@fujitsu +-----+ +---------------+ .com) |user |<.........................| push proxy | |agent| 3: push a tailored | or initiator | +-----+ content +---------------+ ====> SIP request ----> SIP response ....> non-SIP protocols Figure 1: Example of CC/PP query 4.2 REGISTER A user agent may use the REGISTER method to register the CC/PP description with a SIP server, in addition to the traditional function of registration of the address listed in the To header or the Contact header. In order to register the CC/PP description to the CC/PP cache repository, the REGISTER request must include the Profile header (Section 3.1). But Profile-Diff header may be omitted in the case that there is no change from the default settings specified in the Profile header or that the user agent is not allowed to change the defaults. The REGISTER request for CC/PP registration may include Contact header. If the REGISTER request includes both of the Profile header and the Contact header, the CC/PP description specified in the Profile/Profile-Diff header is associated with the address of Contact header field. If the REGISTER request includes the Profile Nishigaya and Yuhara [Page 7] CCPP exchange protocol based on SIP July 14, 2000 header but doesn't include a Contact header, the CC/PP description of the Profile/Profile-Diff header is associated with the address of the To header field. The latter case is useful for registering user preferences that are independent of user devices and that are applicable to any type of user agents. The registrar server must return the result of retrieval or registration of the CC/PP description in the Profile-Warning header in the REGISTER response. The registration of location service and the retrieval/registration of the CC/PP description may be performed in parallel. In this case, the registrar server must keep the state representing these two activities, because the REGISTER response must include both of these results. When the preferences of the user agent has been changed, the user agent may send the REGISTER request with the Profile-Diff header to the registrar server, independent of the timing of renewal of the Contact address. The expiration of CC/PP cache is synchronized with the validation period of the Contact address. It is controlled by Expires header (See section 6.20 of RFC 2543 [6]). When the registration of the Contact address is expired, the associated CC/PP cache is also deleted from the CC/PP cache repository. 4.3 OPTIONS The OPTIONS method is used to retrieve the CC/PP description of user or user agent on demand, in addition to the traditional function of querying the user agent's capabilities about multimedia communications. In order to distinguish the query of CC/PP description from the traditional query, the server must check the media type of the Accept header. If the Accept header field indicates "text/xml" and if the server supports the CC/PP extension of this draft, the server responds the XML formatted CC/PP description. If the Accept header field is "application/sdp" or no Accept header exists in the OPTIONS request, the server must behave like a traditional server, i.e., respond with user agent capabilities in the SDP format. The To header field of the OPTIONS request in the CC/PP query can be a user address or a user agent address. If the To header field is a user address, the registrar server responds with the possible set of CC/PP descriptions associated with that user. In order to archive it, the registrar may consult with the CC/PP cache repository or send the OPTIONS request to all the associated user agents registered in the location service. This extension for CC/PP query must be supported by registrar and user agent. Nishigaya and Yuhara [Page 8] CCPP exchange protocol based on SIP July 14, 2000 Open issue: Is it a bad idea to use the media type of the Accept header for distinction between the call-related capability and the whole capability of user agent? Should another method be assigned for CC/PP query? Or, will the future SDP include the CC/PP information so that no such distinction is necessary? 5 Compatibility with SIP/2.0 The servers and clients which have the CC/PP extension can communicate with that of SIP/2.0 without interfering with the traditional functions. This section describes the compatibility issues with the traditional SIP. 5.1 CC/PP-aware client and traditional server In the case of the CC/PP-aware client and the traditional server, the client can detect that the server doesn't support CC/PP extension by the fact that the REGISTER response doesn't contain a Profile-Warning header or the server returns 5xx responses (Server Errors). If the client is configured to send a local SIP proxy server and the proxy returns a 502 response (Bad Gateways), the client should try to directly contact the registrar server. 5.2 Traditional client and CC/PP-aware server The CC/PP-aware registrar server must implement the minimum requirement of the traditional SIP registrar (RFC 2543). When the client sends a REGISTER request without a Profile header, the registrar server must behave like a traditional registrar, i.e., the server should not include a Profile-Warning header in the REGISTER response. 6 Relation to CC/PPex The CC/PP exchange protocol based on SIP extension isn't intended to replace the CC/PPex protocol based on HTTP/1.1. CC/PPex is still an effective protocol for web services, but it is not suitable for push service. Our proposal enables the CC/PP exchange for push service. These two protocols are complementary. If both of these protocol is used for push and pull services, the CC/PP cache repository is shared by a SIP registrar server and a HTTP proxy or server. This helps to reduce the time to resolve the CC/PP metadata for HTTP service. 7 Examples This section shows the examples of CC/PP exchange. One example is in the registration process. Another is an on-demand query. 7.1 Registration A user at host eden.fujitsu.com registers its address and its CC/PP Nishigaya and Yuhara [Page 9] CCPP exchange protocol based on SIP July 14, 2000 description on start-up, via multicast, with the local SIP server named fujitsu.com. In the example, the user agent on eden specifies the CC/PP change that the sound capability is on. C->S REGISTER sip:fujitsu.com SIP/2.0 Via: SIP/2.0/UDP eden.fujitsu.com From: sip:takashi@eden.fujitsu.com To: sip:takashi@eden.fujitsu.com Call-ID: 70710@eden.fujitsu.com CSeq: 1 REGISTER Contact: Expires: 7200 Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" Profile-Diff-1: Or, if the Profile-Diff header is too long and the SIP server restricts the length of headers, the user agent may be allowed to include the changes of the default CC/PP description in the message body. C->S REGISTER sip:fujitsu.com SIP/2.0 Via: SIP/2.0/UDP eden.fujitsu.com From: sip:takashi@eden.fujitsu.com To: sip:takashi@eden.fujitsu.com Call-ID: 70710@eden.fujitsu.com CSeq: 1 REGISTER Contact: Expires: 7200 Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw", "1-uKhJE/AEeeMzFSejsYshHg==" Content-Type: text/xml Content-Length: 258 The SIP server responses the result of the registration with the Profile-Warning header. S->C Nishigaya and Yuhara [Page 10] CCPP exchange protocol based on SIP July 14, 2000 SIP/2.0 200 OK Via: SIP/2.0/UDP sip.fujitsu.com From: sip:takashi@eden.fujitsu.com To: sip:takashi@eden.fujitsu.com Call-ID: 70710@eden.fujitsu.com CSeq: 1 REGISTER Profile-Warning: 200 OK 7.2 CCPP retrieval A push initiator can use an OPTIONS request to obtain the capabilities and preferences of an push target user takashi. The SIP server responds the CC/PP description of user takashi, if he grants the permission to the push initiator. C->S OPTIONS sip:takashi@fujitsu.com SIP/2.0 From: Push Initiator To: Nishigaya Call-ID: 6378@host.service.com CSeq: 1 OPTIONS Accept: text/xml S->C SIP/2.0 200 OK From: Nishigaya To: Push Initiator Call-ID: 6378@host.service.com Content-Type: text/xml Content-Length: 258 .... 8 References [1] "Compact HTML for Small Information Appliances" Tomihisa Kamada, ACCESS W3C Note February 1998 [2] "Wireless Markup Language Specification" WAP Forum [3] "Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation" Franklin Reynolds, Nokia Research W3C Note Nishigaya and Yuhara [Page 11] CCPP exchange protocol based on SIP July 14, 2000 June 1999 [4] RFC 2774, "An HTTP Extension Framework" Henrik Frystyk Nielsen, Paul J. Leach, Microsoft Corporation Scott Lawrence, Agranat Systems, Inc. February 2000 [5] "CC/PP exchange protocol based on HTTP Extension Framework" Hidetaka Ohto, W3C/Panasonic Johan Hjelm, W3C/Ericsson W3C Note June 1999 [6] RFC 2543, "SIP: Session Initiation Protocol" Mark Handley, ACIRI Henning Schulzrinne, Columbia University Eve Schooler, California Institute of Technology Jonathan Rosenberg, Bell Laboratories March 1999 [7] "SIP Extensions for Presence" Jonathan Rosenberg, Dean Willis, Robert Sparks, Ben Campbell, dynamicsoft Henning Schulzrinne, Jonathan Lennox, Columbia University Bernard Aboba, Christian Huitema, David Gurle, Microsoft Dave Oran, Cisco Internet Draft June 2000 [8] "SIP Extensions for Instant Messaging" Jonathan Rosenberg, Dean Willis, Robert Sparks, Ben Campbell, dynamicsoft Henning Schulzrinne, Jonathan Lennox, Columbia University Bernard Aboba, Christian Huitema, David Gurle, Microsoft Dave Oran, Cisco Internet Draft June 2000 [9] RFC 1777, "Lightweight Directory Access Protocol" Wengyik Yeong, PSI Inc. Tim Howes, University of Michigan Steve Kille, ISODE Consortium March 1995 9 Authors' Addresses Takashi Nishigaya Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku Kawasaki 211-8588 Japan email: takashi@flab.fujitsu.co.jp Nishigaya and Yuhara [Page 12] CCPP exchange protocol based on SIP July 14, 2000 Masanobu Yuhara Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku Kawasaki 211-8588 Japan email: yuhara@flab.fujitsu.co.jp Nishigaya and Yuhara [Page 13]