Internet Engineering Task Force Internet Draft Wu/Schulzrinne/Lennox/Rosenberg draft-wu-cpl-presence-00.txt Columbia University/DynamicSoft June 1, 2001 Expires: November 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) 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. 1 Introduction The current CPL [1] specification focuses on the server side call handling. It does not support presence related services. We can either create a new language or extend CPL to provide such support. Extending CPL is a better choice for two reasons. First, many existing CPL components can be re-used. Second, the presence information can influence call handling which has been defined in the Wu/Schulzrinne/Lennox/Rosenberg [Page 1] Internet Draft CPL-Presence June 1, 2001 current CPL specification. 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 We define four kinds of extensions. First, two sub-level actions are added to indicate the type of the message, namely "subscription" and "notification". Second, four new operations are defined. They are "approve", "defer", "subscribe", and "notify". Third, in a presence system, the subscription and notification are all related to the events that occur in the presentity. We, therefore, add a new switch, "event-switch", to provide the description of the events. Fourth, we add three new non-URL sources for the location lookup. 3 Namespace of CPL extensions for presence The namespace of the CPL extensions for presence will be "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. 4 New sub-level actions We still keep 'incoming' and 'outgoing' as the top-level actions. We create a new kind of actions named sub-level actions to hold the CPL extensions. The sub-level action defines a lower-level tag of the top-level action. We add two sub-level actions for CPL extensions Wu/Schulzrinne/Lennox/Rosenberg [Page 2] Internet Draft CPL-Presence June 1, 2001
Figure 1: Namespace declaration of CPL extensions for presence for presence, namely presence:subscription, the action performed when a subscription message is received or sent out, and presence:notification, the action performed when a notification message is received or sent out. The sub-level action tag can be ommited to refer to 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. Tag: cpl Parameters: None Sub-tags: ancillary See CPL Section 10 subaction See CPL Section 9 presence:subscription Sub-level actions to take on subscriptions presence:notification Sub-level actions to take on notifications outgoing Top-level actions to take on outgoing calls incoming Top-level actions to take on incoming calls Figure 2: Syntax of the extended CPL node Wu/Schulzrinne/Lennox/Rosenberg [Page 3] Internet Draft CPL-Presence June 1, 2001 Note: We may need to add 'registration' as another sub- level action for handling registrations, particularly third-party registrations. An incoming registration from the presentity can trigger a notification to the subscribers. We may need to worry about more fine-grained distinctions in registration propagation. For example, a change in availability of my cell phone may trigger notifications only to a selected 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 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 [3], 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 Wu/Schulzrinne/Lennox/Rosenberg [Page 4] Internet Draft CPL-Presence June 1, 2001 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 default package-name "presence" will be used.) 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 for presence For SIP extensions for presence, both the SUBSCRIBE and the NOTIFY request have an Event header. The Event header contains the package- name information. In the current SIP for presence draft, there is no event-name information in the Event header. However, in the content of a NOTIFY message, the event-name information and parameters for the events are presented in the XML format. 5.2 Usage of event-switch with CPIM For CPIM, the package name is not provided. The default package-name "presence" is considered. The event-name and the parameters are not in the subscription but in the content of the notification. 6 Additional non-URL sources for location lookup In the original CPL specification, The only non-URL source defined is registration, which specifies all the locations registered with the server. We add three additional non-URL sources that can be searched by the location lookup, namely 'subscribers', which specifies all the addresses that have subscribed to this PA; 'notifiers', which specifies the addresses which this PA has successfully subscribed to; 'addressbook', which is the local addressbook of the PA. 7 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 notify operations. In addition, the presence agent can automatically approve, reject or defer a subscription. The original CPL specification does not define the approve and defer operation. (The reject operation is considered equivalent to the deny operation, which has already been defined in the original CPL specification.) Wu/Schulzrinne/Lennox/Rosenberg [Page 5] Internet Draft CPL-Presence June 1, 2001 The additional operations we added are: subscribe, notify, approve and defer. 7.1 Subscribe The 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 4 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 4: Syntax of subscribe node The outputs and the parameters have the same meaning as those in the call operation. 7.2 Notify The Notify operation causes the server to send a notification to the Wu/Schulzrinne/Lennox/Rosenberg [Page 6] Internet Draft CPL-Presence June 1, 2001 specified set of locations. The syntax of the notify node is given in Figure 5 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 The outputs and the parameters have the same meaning as those in the call operation. 7.3 Approve The Approve operation causes the presence agent to send a response for approving the subscription. The syntax of this node is shown in Figure 6 The Approve operation immediately terminates the execution of the CPL script, so this node has no output and no next node. There is one parameter for this node, duration, which defines the time period the Wu/Schulzrinne/Lennox/Rosenberg [Page 7] Internet Draft CPL-Presence June 1, 2001 Node: approve Outputs: None Next node: None Parameters: duration Defines the duration of the subscription Figure 6: Syntax of the approve node 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. 7.4 Defer Defer causes the presence agent to ask for the authorization of the presentity at a later time due to the unavailability of the presentity. The syntax of this node is given in Figure 7 Node: defer Outputs: None Next node: None Parameters: None Figure 7: Syntax of the defer node Note: In a presence system, whether to approve, defer or reject a subscription will base on three inputs, namely the interact directly from the presentity (the user), the policy file on the PA and the CPL scripts (the CPL scripts can be on either the PA or the presentity). The policy file's format can be as Figure 8. The policy file has the advantage of the simple format and being easy to combine multiple files into one single file. It is generally impossible and not appropriate to combine multiple CPL scripts. However, using CPL to handle the presence related services can provide more elaborate rules such as approve/defer/reject the subscription based on the time- switch. It is desirable to define a mechanism to combine three inputs together. When a subscription arrives at a Wu/Schulzrinne/Lennox/Rosenberg [Page 8] Internet Draft CPL-Presence June 1, 2001 PA, the PA SHOULD first check the policy file. If it is defined in the policy file to reject the subscription, a rejection response SHOULD be sent back without going further to consult the CPL scripts and the user. If the policy file does not define how to handle the subscription or the policy file defines to approve/defer the subscription, the PA SHOULD invoke the CPL scripts to find out an appropriate action for the subscription. In this way, some conditionally approvance can be handled. The PA SHOULD follow the action defined in the CPL scripts to handle the subscription. If the action for the subscription is not defined in the CPL scripts, the PA SHOULD do the default action based on the output from the policy file or to ask the presentity (the user) for the action to perform. sip:abc@example.com sip:xyz@foo.edu sip:anonymous@hacker.org Figure 8: Policy file Note: An event can initiate an outgoing call such as send a REFER or INVITE messages to some SIP entities to establish a meeting. The 'call' action is complicated and out of the scope of the presence extensions for CPL so that we won't describe it here. Instead, it should be defined in the CPL extensions for the user agent. 8 Examples 8.1 Automatic callback The script in Figure 9 is a script that provides automatic callback service on a presence agent. 8.2 Selected notification Wu/Schulzrinne/Lennox/Rosenberg [Page 9] Internet Draft CPL-Presence June 1, 2001
Figure 9: Example script: Automatic callback The script in Figure 10 is a script that provides fine-grained distinctions in registration propagation. When the user abc@example.com registers to the registrar, a notification will be sent to the subscribers that can speak English. 9 The XML DTD of the CPL extensions for presence The XML DTD of the CPL extensions for presence follows the XML DTD of CPL with some modifications on the sub-level actions, new switches and new operations. 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/Schulzrinne/Lennox/Rosenberg [Page 10] Internet Draft CPL-Presence June 1, 2001
Figure 10: Example script: Selected notification 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: The new added SubActions are defined as: The TopLevelActions are modified to: Wu/Schulzrinne/Lennox/Rosenberg [Page 12] Internet Draft CPL-Presence June 1, 2001 10 Authors' Addresses Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: xiaotaow@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 Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA electronic mail: lennox@cs.columbia.edu Jonathan Rosenberg DynamicSoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 USA electronic mail: jdrosen@dynamicsoft.com 11 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 Wu/Schulzrinne/Lennox/Rosenberg [Page 13] Internet Draft CPL-Presence June 1, 2001 (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. 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. Wu/Schulzrinne/Lennox/Rosenberg [Page 14] Internet Draft CPL-Presence June 1, 2001 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 sub-level actions ............................... 2 5 Event switch ........................................ 4 5.1 Usage of event-switch with SIP for presence ......... 5 5.2 Usage of event-switch with CPIM ..................... 5 6 Additional non-URL sources for location lookup ...... 5 7 New signaling operations ............................ 5 7.1 Subscribe ........................................... 6 7.2 Notify .............................................. 6 7.3 Approve ............................................. 7 7.4 Defer ............................................... 8 8 Examples ............................................ 9 8.1 Automatic callback .................................. 9 8.2 Selected notification ............................... 9 9 The XML DTD of the CPL extensions for presence ...... 10 10 Authors' Addresses .................................. 13 11 Bibliography ........................................ 13 Wu/Schulzrinne/Lennox/Rosenberg [Page 15]