Internet Engineering Task Force
Internet Draft Wu/Schulzrinne
Columbia University
wu-cpl-presence-01.txt
March 28, 2003
Expires: September 2003
Call Processing Language Extensions for Presence Information Handling
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 in this
document are designed to add capabilities to describe services for
presence information handling. The extensions can work with the other
presence information handling filters for more elaborate rules. The
definition of the extensions is based on the XML Schema for CPL.
Wu/Schulzrinne [Page 1]
Internet Draft CPL-Presence March 28, 2003
1 Introduction
People are using presence information extensively in their daily
life, such as using instant messenger to check the online status of
friends. In IETF, the IMPP and SIMPLE working group are working on
the model and message formats for presence and instant message
services.
However, there is no standard way to define services for automatic
presence information handling, such as automatically making an
outbound call to a friend when the friend gets online. System
developers can certainly use languages like C/C++, or Java to
implement such services, but this kind of implementation will be
platform and language dependent and usually un-readable to non-
programmers.
One advantage of eXtensible Markup Laugnage (XML) is its independence
of platform and underlying programming languages. In addition, the
tag of XML has semantic meanings and it makes the XML script readable
to non-programmers. These advantages make XML a suitable language
for telecommunication service creation. Call Processing Language
(CPL) [1] [2] is one of the XML based telecommunication service
creation languages. The current CPL specification focuses on the
server side call handling. It does not support presence information
handling.
We choose to extend CPL to support presence information handling
instead of creating a new XML based language for two reasons. First,
many existing CPL components, such as time-switch and string-switch,
can be re-used for presence information handling. Second, CPL has
already defined commands for call handling which will be used for
presence information handling.
We choose to define the CPL extensions for presence information
handling based on the XML Schema for CPL [2] instead of XML DTD in
the original CPL definition [1]. XML Schema is much easier to extend
compared with XML DTD. In addition, XML Schema provides many
predefined data types and has better data type checking mechanism.
The CPL extensions for presence can work together with the policy
rules in a presence system. Compared with only using policy rules for
presence information filtering, 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.
The CPL extensions for presence are not tied to any particular
presence protocol; they are anticipated to be compliant with the
presence and instant messaging model [3] [4] defined in IETF IMPP
Wu/Schulzrinne [Page 2]
Internet Draft CPL-Presence March 28, 2003
working group and SIP extensions for presence [9].
1.1 Conventions of This Document
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] 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
The extensions can automate the presence information
handling in four ways. Users can use CPL scripts to
automatically accept or reject subscriptions; users can use
CPL scripts to automatically fetch the remote parties
status before making an outgoing call; users can use CPL
scripts to automatically invoke call actions for incoming
notifications; users can use CPL scripts to automatically
send outgoing notifications.
We consider presence information as a special case of general event
notification, with the event package defined as 'presence' and with
only two event values, OPEN and CLOSED. Thus, we define CPL
extensions for general event handling and have the CPL extensions for
presence information handling based on the general event handling.
The general event handling extensions define two new triggers, namely
'subscription' and 'notification', used to handle incoming or
outgoing subscription and notification requests respectively. A new
switch named event-switch is defined so the presentity or watcher can
base on the events to make decisions. Several new actions are
defined to handle incoming subscriptions. these actions include
'approve', 'defer' and 'deny', used to make decisions on incoming
subscription. The other new actions are 'subscribe', used to send a
subscription; 'fetch' used to get the presentity status only once;
'notify', used to send a notification; 'unsubscribe', used to
unsubscribe from the presentity;
Wu/Schulzrinne [Page 3]
Internet Draft CPL-Presence March 28, 2003
The 'poll' action can be achieved by using the time-switch
and the 'fetch' action
3 Namespace of CPL extensions for presence
The namespace URIs for elements defined by this specification are
URNs [6], using the namespace identifier 'ietf' defined by [7] and
extended by [8].
The URN for general event handling is:
urn:ietf:params:xml:ns:cpl:event
The URN for presence information handling is:
urn:ietf:params:xml:ns:cpl:presence
4 New triggers
4.1 New triggers in the general event handling extensions
Two triggers are defined in the extensions. One is 'subscription' and
the other is 'notification'. 'subscription' is for handling incoming
or outgoing SUBSCRIBE requests; 'notification' is for handling
incoming or outgoing NOTIFY requests. The new triggers are defined as
the substitutionGroup of the abstract element 'trigger' defined in
the CPL schema. The XML schema fragment for the two triggers is as
below:
Wu/Schulzrinne [Page 4]
Internet Draft CPL-Presence March 28, 2003
There is one child element of the SubscriptionType, CPL:Node. With
this child element, the subscription and notification trigger can
contain all the switches and actions defined in the CPL and the CPL
extensions.
There are two attributes for each trigger. 'direction' defines
whether the request is incoming or outgoing. 'package' defines what
events are expected for subscription or notification. For presence
information handling, the package has a fixed value 'presence'.
Note: In Common Profile for Presence specification [4],
there are 'watcher', 'target' and 'duration' attributes for
subscription and notification. These attributes are
provided in the 'event' element of the 'event-switch'
(Section 5) for defining the choices a CPL script can make.
Note: We noticed that in a SIP implementation, if the
presence user agent co-located with the the registrar, the
registration may invoke outgoing notification. We may need
to add 'registration' as another trigger 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.
4.2 New triggers in the presence information handling extensions
The triggers in the presence information handling extensions are
inherited from the triggers in the general event handling extensions,
with the package attribute using a fixed value 'presence'. The XML
schema fragment for the triggers is as below:
Wu/Schulzrinne [Page 5]
Internet Draft CPL-Presence March 28, 2003
5 Event switch
5.1 event-switch in the general event handling extensions
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 watcher; the watcher
performs different operations based on the events notified by the
presentity. The event-switch is defined as a substitutionGroup of
the abstract element 'switch' in the CPL schema. The XML Schema
fragment of the event-swtich is defined as below:
Wu/Schulzrinne [Page 6]
Internet Draft CPL-Presence March 28, 2003
The event handling is more than on-line and off-line indicator. Some
presence systems support more presence indicators such as 'away' and
'idle'. In Presence Event Package for the Session Initiation
Protocol (SIP) [9], event package is introduced to distinguish event
types. Thus, an event consists of at least two parts, namely
package-name, and event-name. Different events may have different
parameters such as the length of the idle period. However, the
parameters are not common to all the events and will not be included
in the EventType in general event handling extensions.
5.2 presence-switch in the presence information handling extensions
The presence-switch in presence information handling is inherited
from the event-switch defined in general event handling with adding
three attributes in the EventType. In addition, presence-switch
provides some limitations to the 'package' and 'is' attributes. The
XML Schema fragment of the presence-switch is as below:
Wu/Schulzrinne [Page 7]
Internet Draft CPL-Presence March 28, 2003
In the schema, the package attribute in EventType has fixed value as
'presence'. The 'is' attribute has only two values, namely 'OPEN' and
'CLOSED', consistent with the status defined in RFC2778 [3]. Three
new attributes are defined. The 'watcher' attribute checks who's
watching the event; the 'target' attribute checks who's sending the
event; the 'duration' attribute defines the maximum number of seconds
a subscription can be active. The 'watcher', 'target' and 'duration'
attributes match the 'watcher', 'target' and 'duration' attributes
defined in Common Profile for Presence specification [4].
5.3 Usage of event-switch with SIP for presence
For SIP extensions for presence [9], both the SUBSCRIBE and the
Wu/Schulzrinne [Page 8]
Internet Draft CPL-Presence March 28, 2003
NOTIFY request have an Event header. The Event header contains the
package information.
5.4 Usage of event-switch with CPIM
For CPIM, it is only for presence information. So, the package should
always be 'presence'.
6 group-of attribute for the address element in address-switch
The content in this section needs further discussion.
In a user's addressbook, he may put different contacts in
different groups. Different groups may require different
event handling policy. As the following script shows, the
user can define a blacklist, if the subscription is from
the people in the blacklist, the subscription will be
automatically rejected.
7 Additional non-URL sources for location lookup
The content in this section needs further discussion
In the original CPL specification, The only non-URL source
defined is registration, which specifies all the locations
registered with the server. We add two additional non-URL
sources that can be searched by the location lookup, namely
'watchers', which specifies all the addresses that have
subscribed to the PA; 'presentities', which specifies the
addresses which the PA has successfully subscribed to.
8 New signaling operations
The presence information generally invokes new operations beyond
those defined in original CPL specification. For example, a
notification can invoke an outgoing call, a registration can invoke a
notification. In addition, the presence agent can automatically
approve, reject or defer a subscription.
Wu/Schulzrinne [Page 9]
Internet Draft CPL-Presence March 28, 2003
The actions we defined for presence information handling are:
subscribe, fetch, unsubscribe, notify, approve, defer and deny.
8.1 subscribe action
The 'subscribe' action causes the server to send a subscription to
the specified set of locations. It is defined as a substitutionGroup
of the abstract element CPL:action in the CPL schema. The XML schema
fragment is as below:
Wu/Schulzrinne [Page 10]
Internet Draft CPL-Presence March 28, 2003
The subscribe operation contains four sub-elements, corresponding to
different responses to the subscription.
"success" defines additional actions should be performed if the
subscription succeeds.
"noanswer" defindes additional actions should be performed if
there is no answer for the subscription.
"failure" defindes additional actions should be performed if the
subscription failed.
"redirection" defindes additional actions should be performed if
the subscription will be redirected to some other places.
There is an xs:any element in the subscribe operation. The
element can be used to host additional information for an
outgoing subscription, such as the event list defined in
[10].
There are six attributes for the subscription action. 'package' and
'event' define what is the event the watcher is interested in.
'duration' defines how long the subscription can be active; 'rate'
defines the rate at which notifications are allowed to be generated
by a single notifier. [11] [12] 'timeout' and 'ordering' are the same
as those defined in the 'proxy' action in CPL specification. The
default timeout value is 20 seconds.
8.2 fetch action
The fetch action causes the watcher to send a subscription for one
time status notification. So, in 'fetch' action, there is no duration
and rate attribute. The XML schema fragment of 'fetch' action is as
below:
Wu/Schulzrinne [Page 11]
Internet Draft CPL-Presence March 28, 2003
Both SIP extensions for presence and CPIM set duration as 0 in a
subscription for fetch action.
8.3 notify action
The notify operation causes the presentity to send a notification to
the specified set of locations. It is defined as a substitutionGroup
of the abstract element CPL:action in the CPL schema. The XML schema
fragment is as below:
Wu/Schulzrinne [Page 12]
Internet Draft CPL-Presence March 28, 2003
The notify operation contains four sub-elements and three attributes.
They are the same as those defined in the subscribe action.
For presence event notification, there could be more
informaion than on-line or off-line indication. For
example, there could be location information, current
status (busy, in meeting) in the notification. Different
people may see different notifications. So, we may add
another attribute in the notify action, named 'class',
indicating what kind of notifications should be sent. The
detailed information of the 'class' can be defined in a
policy file. For example, we define a policy as:
Wu/Schulzrinne [Page 13]
Internet Draft CPL-Presence March 28, 2003
If the attribute 'class' is family, the outgoing
notification will contain location and status information;
only location information for friends class and only status
information for coworkers class.
The class attribute can also be used in the 'approve' action
described in the next section to indicate what kind of notifications
will be sent.
8.4 approve action
The approve operation causes the presentity to allow the watcher
watching the events specified in the subscription. It is defined as
a substitutionGroup of the abstract element CPL:action in the CPL
schema. The XML schema fragment is as below:
Wu/Schulzrinne [Page 14]
Internet Draft CPL-Presence March 28, 2003
The Approve operation immediately terminates the execution of the CPL
script, There are two attributes for approve action. Attribute
'duration' 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. Attribute 'rate' defines the
notification rate.
8.5 defer action
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 XML schema fragment of the defer action is as below:
8.6 reject action
Reject causes the presence agent to reject a subscription. The XML
fragment of the reject action is as below:
There are two attributes for the 'reject' action. 'status' indicates
the status code being used in the response; 'reason' indicates the
Wu/Schulzrinne [Page 15]
Internet Draft CPL-Presence March 28, 2003
reason of the rejection.
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 can be as below
sip:abc@example.com
sip:xyz@foo.edu
sip:anonymous@hacker.org
The policy file has the advantage of the simple format and
being easy to combine multiple files into one single file.
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.
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 end systems.
9 Examples
9.1 Automatic outgoing call on incoming online notification
The following script provides automatic outgoing call service on a
presence agent.
Wu/Schulzrinne [Page 16]
Internet Draft CPL-Presence March 28, 2003
9.2 Selected notification
The following script provides fine-grained distinctions in
registration propagation. When the user alice@examples.com registers
to the registrar, a notification will be sent to the subscribers that
can speak English.
Wu/Schulzrinne [Page 17]
Internet Draft CPL-Presence March 28, 2003
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
11 Normative References
[1] J. Lennox and H. Schulzrinne, "CPL: a language for user control
of Internet telephony services," internet draft, Internet Engineering
Task Force, Nov. 2001. Work in progress.
[2] X. Wu, H. Schulzrinne, and J. Lennox, "An extensible markup
language schema for call processing language (CPL)," internet draft,
Internet Engineering Task Force, Mar. 2003. Work in progress.
[3] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," RFC 2778, Internet Engineering Task Force, Feb.
2000.
[4] D. H. Crocker and J. L. Peterson, "Common profile for presence
(CPP)," internet draft, Internet Engineering Task Force, Mar. 2003.
Work in progress.
[5] S. Bradner, "Key words for use in rfcs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[6] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
Force, May 1997.
Wu/Schulzrinne [Page 18]
Internet Draft CPL-Presence March 28, 2003
[7] R. Moats, "A URN namespace for IETF documents," RFC 2648,
Internet Engineering Task Force, Aug. 1999.
[8] M. Mealling, "The IETF XML registry," internet draft, Internet
Engineering Task Force, July 2002. Work in progress.
12 Informative References
[9] J. Rosenberg, "A presence event package for the session
initiation protocol (SIP)," internet draft, Internet Engineering Task
Force, Jan. 2003. Work in progress.
[10] A. B. Roach, J. Rosenberg, and B. Campbell, "A session
initiation protocol (SIP) event notification extension for
collections," internet draft, Internet Engineering Task Force, Feb.
2003. Work in progress.
[11] A. Niemi, "Requirements for limiting the rate of event
notifications," internet draft, Internet Engineering Task Force, Mar.
2003. Work in progress.
[12] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.
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 assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
Wu/Schulzrinne [Page 19]
Internet Draft CPL-Presence March 28, 2003
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 [Page 20]
Table of Contents
1 Introduction ........................................ 2
1.1 Conventions of This Document ........................ 3
2 Overview of the Extensions .......................... 3
3 Namespace of CPL extensions for presence ............ 4
4 New triggers ........................................ 4
4.1 New triggers in the general event handling
extensions ..................................................... 4
4.2 New triggers in the presence information handling
extensions ..................................................... 5
5 Event switch ........................................ 6
5.1 event-switch in the general event handling
extensions ..................................................... 6
5.2 presence-switch in the presence information
handling extensions ............................................ 7
5.3 Usage of event-switch with SIP for presence ......... 8
5.4 Usage of event-switch with CPIM ..................... 9
6 group-of attribute for the address element in
address-switch ................................................. 9
7 Additional non-URL sources for location lookup ...... 9
8 New signaling operations ............................ 9
8.1 subscribe action .................................... 10
8.2 fetch action ........................................ 11
8.3 notify action ....................................... 12
8.4 approve action ...................................... 14
8.5 defer action ........................................ 15
8.6 reject action ....................................... 15
9 Examples ............................................ 16
9.1 Automatic outgoing call on incoming online
notification ................................................... 16
9.2 Selected notification ............................... 17
10 Authors' Addresses .................................. 18
11 Normative References ................................ 18
12 Informative References .............................. 19
Wu/Schulzrinne [Page 1]