SIP WG C. Jennings Internet-Draft Cisco Systems Expires: December 28, 2003 June 29, 2003 SIP Support for Application Initiation draft-jennings-sip-app-info-01 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. This Internet-Draft will expire on December 28, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes SIP extensions to allow network elements to request a UA to initiate a scripted application that is associated with a dialog. It provides a mechanism for the network elements to find out a UA's ability to fetch and execute scripts. This work is being discussed on the sip@ietf.org mailing list. Jennings Expires December 28, 2003 [Page 1] Internet-Draft SIP Application Information June 2003 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. User Agent Server Behavior . . . . . . . . . . . . . . . . . . 5 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 The App-Info Header . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1 Registration of App-Info Header . . . . . . . . . . . . . . . 8 8.2 Registration of Option Tag . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 Normative References . . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Jennings Expires December 28, 2003 [Page 2] Internet-Draft SIP Application Information June 2003 1. Conventions A "script" refers to some markup, program, or script that the UA can fetch and execute. 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 [2]. 2. Introduction The Session Initiation Protocol (SIP) [1] provides the ability for users to initiate, manage, and terminate communications sessions. Frequently, these sessions will involve a SIP application. A SIP application is defined as a program running on a SIP-based element (such as a proxy or user agent) that provides some value-added function to a user or system administrator. Examples of SIP applications include pre-paid calling card calls, conferencing, and presence-based [4] call routing. In order for most applications to properly function, they need input from the user to guide their operation. For example, a pre-paid calling card application requires the user to input their calling card number, their PIN code, and the destination number they wish to reach. The process by which a user provides input to an application is referred to as "application interaction". A set of high level requirements on a system for application interaction are described in [9]. To meet these requirements, a framework has been developed[11]. In this framework, applications can instantiate user interface classes on client devices, for the purposes of interacting with the user. Each class can represent different components of the the user interface in a single application. These user interface components are described using markup languages, such as VoiceXML and KPML [10]. The framework also defines a set of requirements for SIP extensions that allow for an application to discover the capabilities of the user device for supporting markup languages, for placing user interface components on the device, and for terminating the component. This document proposes a specific SIP extension that fulfills those requirements. This extension is the App-Info header. 3. Overview The main mechanism of this draft is a new header field, called App-Info, that provides the UA with the URL of a script to execute. A network element can add this header field. The App-Info header field can occur in most SIP messages, including INVITE and MESSSAGE Jennings Expires December 28, 2003 [Page 3] Internet-Draft SIP Application Information June 2003 messages, as well as in reliable provisional responses. This draft also defines an option tag for use in the supported header field to allow a UA to indicate support for this mechanism. Options tags are also used to indicate which types of markup are supported. The Caller Preferences mechanism is used to indicate the types of markup that the UA can process. An example App-Info header field is: App-Info: "Call Timer" ; id=app4323!sub4+svr56.provider.net This indicates that the UA should fetch and execute the script found at http://mediasvr.provider.net/calltimer.vxml. A key part of the header field value is an application id that consists of an application instance and an application class separated by a "!". In the example above, the instance is "app4323" and the class is "sub4+src56.provider.net". The combination of these two MUST make a globally unique identifier. There may be multiple user interface components running on a UA that are part of the same application instance, and therefore, share the same instance identifier. The instance identifier can be used to correlate the applications. An application might want to authorize the execution of the markup based only on the class name so that this authorization can be cached and used the next time a different instance of this same application is used. If authorization is cached or shared, note the warnings in the Security Consideration section. The UA may use the display name for presentation purposes and for help in managing focus, but it has no other meaning. The formal syntax for the App-info header field is presented in Section 6. This approach also uses the Supported and Accept header fields as well as the schemes mechanism from the caller prefs draft [7]. For example: Supported: markup Accept: multipart/mixed, application/vxml, text/html Contact: sip:1.2.3.4;schemes="http,cid,file" This indicates that the UA can accept markup as defined in this draft. In particular the UA can accept VoiceXML and HTML markup and is capable fetching scripts from using a http, cid, or file scheme. The cid scheme[8] fetches the content from an inline body in the same message. Jennings Expires December 28, 2003 [Page 4] Internet-Draft SIP Application Information June 2003 4. User Agent Server Behavior When a UAC sends a message it MUST include in the Supported header the markup option tag. It MUST also put the markups or scripts that it can process in the Accept header field and indicate the schemes it can support in the Contact header. When a UA receives a message that contains an App-Info header field, it must process each header field value and decide what to do with it. There are three cases: creating a new application, updating an existing application, and stopping a script that has been previously started. In the case when the application identifier does not match any of the scripts that are currently running, a new application instance is created. The UA associates the application identifier with the dialog it was received on. The script is fetched. After fetching the script, execution starts in a context associated with the dialog. If the application identifier matches the identifier for a previously fetched script, and the App-Info header field URL value does not match the previous header field URL value for this script, then the script is fetched and then used to replace the existing script. If the application identifier matches an existing script and the URL in the App-Info header field value is empty, then the existing script is terminated. If the URL has not changed, this header field value is ignored. The UA fetches the script by using the URI found in the URI portion of the App-Info header field value. A UA which supports the App-Info header field MUST support fetching scripts from multipart MIME bodies using the cid scheme and SHOULD support the http[12] scheme. When a dialog ends, all the applications associated with it SHOULD be immediately terminated. A UA may add the App-Info header field to initiate an application on the other UA in the dialog. The UA SHOULD NOT request services that the other UA has not indicated it supports. The App-Info header follows the general http scripting model for reporting errors - that is to say that the UA fetching the markup and executing it does not report errors to the application server. Part of the problem is that there is no easy way to report errors when fetching some markup fails, or when the markup can not be interpreted, or when the markup is terminated. There is no guarantee that the system will get any stimulus from the markup even if there are no errors. This means the application must be written in a way Jennings Expires December 28, 2003 [Page 5] Internet-Draft SIP Application Information June 2003 that detects when the application is not getting input and deals with this situation appropriately. For many web applications this has turned out to be fairly easy to do. 5. Proxy Behavior Proxies MAY add header field values to the App-Info header field but they SHOULD NOT delete or modify any existing header field values that they did not originally add. App-Info header fields MAY be added to reliable provisional response. The proxy SHOULD NOT request services that the UA has not indicated it supports. 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. 6.1 The App-Info Header App-Info = "App-Info" HCOLON app *(COMMA app) app = [ display-name ] LAQUOT [absolute-uri] RAQUOT *(SEMI app-param) app-param = app-id-param / app-name-param / generic-param app-id-param = "id" EQUAL app-id-value app-id-value = app-instance-id "!" app-class-id app-instance-id = app-token app-class-id = app-token app-token = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "'" / "`" / "~" ) ; this is a token with no "!" app-name-param = "app-name" EQUAL gen-value This document adds the following entry to Table 2 of RFC-3261 [1]. Note that App-Info is only valid in something that is in a dialog or forms a dialog. Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- App-Info adr - - - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o o o - In addition it would be listed as an optional header for the MESSAGE message so this document adds the following line to Table 1 in RFC-3428 [6]. Jennings Expires December 28, 2003 [Page 6] Internet-Draft SIP Application Information June 2003 Header Field where proxy MESSAGE __________________________________________ App-Info o 7. Security Considerations This document describes a mechanism that allows non trusted parties to request that a UA execute an arbitrary script. This mechanism should only be used to initiate scripts that are in scripting languages intended for situations in which scripts from non trusted parties are expected. HTML is a good example of a markup language that is considered safe to render content that is not trusted. A scripting language that allowed scripts that automatically caused the UA to hang up and then dial a toll service phone number would certainly not be appropriate for this mechanism. The scripting language should not be able to access information on the UA that is not associated with the dialog, such as the user's address book. The mechanism in this document does not address the secure transport, authorization, and integrity of the markup, but there are multiple mechanisms to ensure that the markup came from the correct party and that the markup has not been tampered with. If the script is fetched using https, both the identity of the party providing the markup and the integrity of the markup can be secured. Alternatively, if the script is transferred using the cid scheme, S/MIME can be used to sign the markup. Proxies are allowed to insert App-Info headers so the App-Info headers can not be secured using an end to end mechanism. Using the sips URL in the SIP messages does provide some assurances that, as long as the user trusts all the proxies that the call traversed, the user can be sure that no rogue markup has been requested. When some markup has been requested, the UA should require authorization to run it. It is possible to authenticate the party that sent the markup using https or S/MIME signing of cid markup. Authorization SHOULD be obtained for each different class of markup but the UA MAY reuse the authorization for two different instances of the same application class. When authorization is cached or used for different instances of the same class, the system MUST ensure that all the markup sharing the authorization came from the same entity. For example, if the system authorizes a class named doSomething that was received from a source which could authenticate (using something line https or smime) as good.example.com, the system should not trust a class called doSomething received from evil.example.com. Jennings Expires December 28, 2003 [Page 7] Internet-Draft SIP Application Information June 2003 8. IANA Considerations {NOTE to IANA: Please replace XXXX with the rfc number of this specification} 8.1 Registration of App-Info Header This document defines a new header field, "App-Info". As recommended by RFC-3261 [1] these headers fields should be registered by the IANA in the SIP header registry, using the RFC number of this document as its reference. Name of Header: App-Info Short form: none Registrant: Cullen Jennings fluffy@cisco.com Normative description: Section 6.1 of RFC XXXX. 8.2 Registration of Option Tag This specification registers a new option tag called markup. The required information for this registration, as specified in RFC-3261 [1], is: Name: markup Description: This option tag is for fetching scripts into a UA. When present in a Supported header field, it indicates that the UA can supports the mechanism in RFC XXXX. Registrant: Cullen Jennings fluffy@cisco.com 9. Acknowledgements Eric Burger, Robert Fairlie-Cuninghame, Jonathan Rosenberg, and I were the members of the Application Stimulus Signaling Design Team. All members of the team contributed significantly to this work. In addition, thanks to Bert Culpepper. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Jennings Expires December 28, 2003 [Page 8] Internet-Draft SIP Application Information June 2003 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [7] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences and Callee Capabilities for the Session Initiation Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in progress), March 2003. [8] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2111, March 1997. Informative References [9] Culpepper, B. and R. Fairlie-Cuninghame, "Session Initiation Protocol Based Application Interaction Requirements", draft-culpepper-sipping-app-interact-reqs-03 (work in progress), March 2003. [10] Burger, E., "Keypad Markup Language (KPML)", draft-burger-sipping-kpml-02 (work in progress), June 2003. [11] Rosenberg, J., "A Framework and Requirements for Application Interaction in SIP", draft-rosenberg-sipping-app-interaction-framework-01 (work in progress), June 2003. [12] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Jennings Expires December 28, 2003 [Page 9] Internet-Draft SIP Application Information June 2003 Author's Address Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA Phone: +1 408 527-9132 EMail: fluffy@cisco.com Jennings Expires December 28, 2003 [Page 10] Internet-Draft SIP Application Information June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Jennings Expires December 28, 2003 [Page 11] Internet-Draft SIP Application Information June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jennings Expires December 28, 2003 [Page 12]