Internet Engineering Task Force IPTEL WG Internet Draft Wu/Lennox/Schulzrinne ietf-iptel-cpl-presence-00.txt Columbia University April 24, 2001 Expires: October 2001 CPL extensions for presence 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. The original CPL specification focuses on call handling on network servers. The extensions of CPL in this document are designed to add capabilities to describe presence related services. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. 1 Introduction The current CPL [1] specification focuses on the server side call Wu/Lennox/Schulzrinne [Page 1] Internet Draft CPL April 24, 2001 handling. It does not provide functionalities to describe presence related services. To do that, we can either create a new language or extend the CPL. Extending the CPL is a better choice for two reasons. First, many existing CPL components can be re-used. Second, the presence information handling is closely related to the call handling. For example, a notification can trigger an outgoing call to the presentity. The CPL extensions for presence are not tied to any particular presence protocol; they are anticipated to be compliant with CPIM [2] and SIP extensions for presence [3]. 1.1 Conventions Of This Document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant CPL implementations. In examples, non-XML strings such as -action1- , -action2- , and so forth, are sometimes used. These represent further parts of the script which are not relevant to the example in question. Some paragraphs are indented, like this; they give motivations of design choices, or questions for future discussion in the development of the CPL extensions, and are not essential to the specification of the language. 2 Overview of the extensions In this section, we provide an overview of the extensions. When a subscription or a notification arrives at or is sent out from a presence agent, some operations can be invoked. The operations can be accepting, deferring or denying the subscription; they can also be making an outgoing call to the presentity based on the notification. We defined three kinds of extensions. First, two top level actions are added to indicate the type of the message, namely "subscription" and "notification". Second, five new operations are defined. They are "approve", "defer", "call", "subscribe", and "notify". Third, in a presence system, the subscription and notification are all related to the events that occurred in the presentity. We, therefore, add a new switch -- "event-switch" to provide the description of the events. 3 Namespace of CPL extensions for presence The namespace of the CPL extensions for presence will be Wu/Lennox/Schulzrinne [Page 2] Internet Draft CPL April 24, 2001 "http://www.rfc-editor.org/rfc/rfcxxxx.txt" and will be declared as xmlns:presence. Figure 1 shows the example of using namespace declaration of CPL extensions for presence.
Figure 1: Namespace declaration of CPL extensions for presence 4 New top-level actions Two new top-level actions are defined for presence related services: subscription, the action performed when a subscription message is received or sent out; and notification, the action performed when a notification message is received or sent out. The original two top- level actions, 'incoming' and 'outgoing', become the sub-tags of subscription and notification to indicate the direction of the message. If 'incoming' or 'outgoing' are used as the top-level actions, it defines the actions for call handling so as to be compatible with the original CPL specification. The syntax of the extended CPL node is given in Figure 2. Note: We may need to add 'registration' as another new top-level action for handling registrations, particularly third-party registrations. An incoming registration from the presentity can trigger a notification to the subscribers. For longer-term, we may need to worry about more fine-grained distinctions in registration propagation. For example, a change in availability of my cell phone may Wu/Lennox/Schulzrinne [Page 3] Internet Draft CPL April 24, 2001 Tag: cpl Parameters: None Sub-tags: ancillary See CPL Section 10 subaction See CPL Section 9 outgoing Actions to take on this user's outgoing messages If used as top-level actions, it defines actions to take on this user's outgoing calls. incoming Actions to take on this user's incoming messages If used as top-level actions, it defines actions to take on this user's incoming calls. presence:subscription Top-level actions to take on subscriptions presence:notification Top-level actions to take on notifications Figure 2: Syntax of the top-level tag for CPL extensions for presence trigger notifications only to a select subset of the users. 5 Event switch The subscriptions and the notifications are all related to the events that occurred in the presentity. The presence agent makes different decisions based on the events subscribed by the subscriber; the watcher performs different operations based on the events notified by the presentity. For handling events, the event-switch is defined as Figure 3 Node: event-switch Outputs: event specific event to match Parameters: none Output: event Parameters: package-name package name to match event-name event name to match parameters parameters to match Figure 3: Syntax of event-switch node In some presence systems, presence is not limited to "on-line" and "off-line" indicator, but has broader meanings. For example, in a Wu/Lennox/Schulzrinne [Page 4] Internet Draft CPL April 24, 2001 Internet Personal Appliance Control (IPAC) system, 'on' or 'off' status of a lamp can be a presence event. For different kinds of presentities, the same event may have different meanings. In SIP extensions for presence draft, event package is introduced to distinguish event types. In addition, some events may have parameters such as the length of the idle period. Thus, an event consists of three parts, namely package-name, event-name and event parameters. The event output tag may take none, one, two or all of the possible parameters. package-name: This match operator applies to the package-name of the event. If no package-name has been defined, by default, the package-name is "presence". event-name: This match operator applies to the event-name of the event. If no event name has been defined, the event output tag will be applied to all the events in the matched package. (If no package-name operator applied, the event output tag will be applied to all the events in the "presence" package.) parameters: This match operator applies to the parameters of an event. The event-name MUST be defined for the parameters. 5.1 Usage of event-switch with SIP extensions for presence For SIP extensions for presence [3], in both the subscriptions and the notifications, the Event header contains the package-name. For the subscription, the event-name is not provided. For the notification, the event-name and the parameters are in the message content of the notification. 5.2 Usage of event-switch with CPIM For CPIM, the package name is not provided. By default, we consider the package-name as "presence". The event-name and the parameters are not in the subscription but in the content of the notification. 6 New signaling operations The presence information generally triggers some operations beyond proxy, redirect and reject, which are defined in the original CPL specification. For example, a notification can trigger an outgoing call, a registration can invoke a notification. The original CPL specification does not define the call and the notify operations. In addition, the presence agent can automatically approve, deny or defer a subscription. The original CPL specification does not define the Wu/Lennox/Schulzrinne [Page 5] Internet Draft CPL April 24, 2001 approve and defer operation. (The reject operation is considered equivalent to the deny operation.) The additional operations we added are: call, subscribe, notify, approve and defer. 6.1 Call Call operation causes the server to place an outgoing call to the currently specified set of locations. The syntax of the call node is given in Figure 4 Node: call Outputs: success Next node if call attempt returned "success" busy Next node if call attempt returned "busy" noanswer Next node if call attempt was not answered before timeout redirection Next node if call attempt was redirected failure Next node if call attempt failed default Default next node for unspecified outputs Parameters: timeout Time to try before giving up on the call attempt recurse Whether to recursively look up redirections ordering What order to try the location set in. refer The URL that the called party should contact. Output: success Parameters: none Output: busy Parameters: none Output: noanswer Parameters: none Output: redirection Parameters: none Output: failure Parameters: none Output: default Parameters: none Figure 4: Syntax of call node Wu/Lennox/Schulzrinne [Page 6] Internet Draft CPL April 24, 2001 Output "success" defines the next node if the call attempt returns success. The other outputs have the same meaning as those in the proxy operation. Parameter "refer" can take a URL as its value. The URL is sent with the call request to ask the called party to contact the referred URL. For the presence agent that is not co-located with the user agent server, this parameter MUST be provided. For SIP [5], if "refer" parameter is provided, the REFER [6] method is used to place the outgoing call. The other parameters have the same meaning as those in the proxy operation. Note: should we provide parameters to specify the media related information? 6.2 Notify Notify operation causes the server to send a notification to the specified set of locations. The syntax of the notify node is given in Figure 5 The outputs and the parameters have the same meaning as those in the call operation. 6.3 Subscribe Subscribe operation causes the server to send a subscription to the specified set of locations. The syntax of the subscribe node is given in Figure 6 The outputs and the parameters have the same meaning as those in the call operation. 6.4 Approve Approve causes the presence agent to send a response for approving the subscription and to keep the subscription information for further notification. The syntax of this node is shown in Figure 7 Approve immediately terminates the execution of the CPL script, so Wu/Lennox/Schulzrinne [Page 7] Internet Draft CPL April 24, 2001 Node: notify Outputs: success Next node if notification returned "success" noanswer Next node if notification was not answered before timeout redirection Next node if notification was redirected failure Next node if notification failed default Default next node for unspecified outputs Parameters: timeout Time to try before giving up on the call attempt recurse Whether to recursively look up redirections ordering What order to try the location set in. Output: success Parameters: none Output: noanswer Parameters: none Output: redirection Parameters: none Output: failure Parameters: none Output: default Parameters: none Figure 5: Syntax of notify node this node has no output and no next node. There is one parameter for this node, duration, which defines the time period the presence agent can send notifications. If duration is zero-valued, only one notification is invoked. If duration is not specified, the duration value SHOULD be set as that specified in the subscription. For SIP extensions for presence, it is the value in the Expires header. For CPIM, it is the value in the duration parameter. 6.5 Defer Defer causes the presence agent to ask for the authorization of the presentity at a later time. The syntax of this node is given in Figure 8 7 Examples Wu/Lennox/Schulzrinne [Page 8] Internet Draft CPL April 24, 2001 Node: subscribe Outputs: approve Next node if the subscription is approved pending Next node if the subscription is pending deny Next node if the subscription is denied noanswer Next node if subscription was not answered before timeout default Default next node for unspecified outputs Parameters: timeout Time to try before giving up on the subscription attempt recurse Whether to recursively look up redirections ordering What order to try the location set in. Output: approve Parameters: none Output: defer Parameters: none Output: deny Parameters: none Output: noanswer Parameters: none Output: default Parameters: none Figure 6: Syntax of subscribe node Node: approve Outputs: None Next node: None Parameters: duration Defines the duration of the subscription Figure 7: Syntax of the approve node 7.1 Automatic callback The script in Figure 9 is a script that provides automatic callback service on a presence agent. Wu/Lennox/Schulzrinne [Page 9] Internet Draft CPL April 24, 2001 Node: pending Outputs: None Next node: None Parameters: None Figure 8: Syntax of the defer node
Figure 9: Example script: Automatic callback 7.2 Conference setup The script in Figure 10 is a script that provides conference setup service on a presence agent. In Figure 10, if the presence agent finds that abc@123.com, xyz@example.com and foo@foo.com are all available, the presence agent will invite them to join a conference. If we use SIP to do the conference setup, three REFER requests will be sent out. Wu/Lennox/Schulzrinne [Page 10] Internet Draft CPL April 24, 2001 Figure 10: Example script: Conference setup Note: We used a new switch 'check-switch' to check the availability of three user agents since CPL itself cannot keep track of the status of the entities. Check-switch uses the external function to do the checking. Using external functions may bring potential security issues. Check-switch has two outputs, 'true' and 'false', which indicate whether the checking successes or not. 7.3 Selected notification The script in Figure 11 is a script that provides fine-grained distinctions in registration propagation. When the user's cell phone registers to the registrar, a notification will be sent to selected subscribers. Note: We used a new top-level action 'registration'. The motivation for adding this new top-level action is in Section 4 8 The XML DTD of the CPL extensions for presence Wu/Lennox/Schulzrinne [Page 11] Internet Draft CPL April 24, 2001
Figure 11: Example script: Selected notification The XML DTD of the CPL extensions for presence follows the XML DTD of CPL with some modifications on new top-level actions, new switches and new operations. One of the big modifications is to add new top- level actions. Because we want to make the extensions be compatible with the original CPL specification, the 'incoming' and 'outgoing' can be top-level actions as well as sub-tags for the subscription and the notification. Thus, we added a new entity 'SubLevelActions' for 'incoming' and 'outgoing' when they are used as the sub-tags for the subscription and the notification. We avoid repeating the parts that are the same as those in XML DTD for CPL in this document. Only the modified definitions and the new added definitions are listed here. Wu/Lennox/Schulzrinne [Page 12] Internet Draft CPL April 24, 2001 The switch nodes are modified to: The new added event-switch is defined as: The signaling nodes are modified to The new added signaling nodes are defined as: Wu/Lennox/Schulzrinne [Page 13] Internet Draft CPL April 24, 2001 The new added SubLevelActions are defined as: The TopLevelActions are modified to: 9 Authors' Addresses Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 Wu/Lennox/Schulzrinne [Page 14] Internet Draft CPL April 24, 2001 USA electronic mail: xiaotaow@cs.columbia.edu Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: lennox@cs.columbia.edu Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu 10 Bibliography [1] J. Lennox and H. Schulzrinne, "CPL: a language for user control of internet telephony services," Internet Draft, Internet Engineering Task Force, July 2000. Work in progress. [2] D. Crocker et al. , "A common profile for instant messaging (CPIM)," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. [3] J. Rosenberg, "SIP extensions for presence," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [4] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [6] R. Sparks, "SIP call control," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. Full Copyright Statement Copyright (c) The Internet Society (2001). All Rights Reserved. Wu/Lennox/Schulzrinne [Page 15] Internet Draft CPL April 24, 2001 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents 1 Introduction ........................................ 1 1.1 Conventions Of This Document ........................ 2 2 Overview of the extensions .......................... 2 3 Namespace of CPL extensions for presence ............ 2 4 New top-level actions ............................... 3 5 Event switch ........................................ 4 5.1 Usage of event-switch with SIP extensions for presence ....................................................... 5 5.2 Usage of event-switch with CPIM ..................... 5 6 New signaling operations ............................ 5 6.1 Call ................................................ 6 6.2 Notify .............................................. 7 6.3 Subscribe ........................................... 7 6.4 Approve ............................................. 7 6.5 Defer ............................................... 8 7 Examples ............................................ 8 7.1 Automatic callback .................................. 9 Wu/Lennox/Schulzrinne [Page 16] Internet Draft CPL April 24, 2001 7.2 Conference setup .................................... 10 7.3 Selected notification ............................... 11 8 The XML DTD of the CPL extensions for presence ...... 11 9 Authors' Addresses .................................. 14 10 Bibliography ........................................ 15 Wu/Lennox/Schulzrinne [Page 17]