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]