Internet Engineering Task Force IPTEL WG
Internet Draft Lennox/Schulzrinne
ietf-iptel-cpl-00.txt Columbia University
February 26, 1999
Expires: September 1999
CPL: A Language for User Control of Internet Telephony Services
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".
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. It is designed to
be implementable on either network servers or user agent servers. It
is meant to be simple, extensible, easily edited by graphical
clients, and independent of operating system or signalling protocol.
It is suitable for running on a server where users may not be allowed
to execute arbitrary programs, as it has no variables, loops, or
ability to run external programs.
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 Call Processing Language (CPL) is a language that can be used to
Lennox/Schulzrinne [Page 1]
Internet Draft CPL February 26, 1999
describe and control Internet telephony services. It is not tied to
any particular signalling architecture or protocol; it is anticipated
that it will be used with both SIP [1] and H.323 [2].
The CPL is powerful enough to describe a large number of services and
features, but it is limited in power so that it can run safely in
Internet telephony servers. The intention is to make it impossible
for users to do anything more complex (and dangerous) than describing
Internet telephony services. The language is not Turing-complete, and
provides no way to write a loop or a function.
The CPL is also designed to be easily created and edited by graphical
tools. It is based on XML [3], so parsing it is easy and many
parsers for it are publicly available. The structure of the language
maps closely to its behavior, so an editor can understand any valid
script, even ones written by hand. The language is also designed so
that a server can easily confirm scripts' validity at the time they
are delivered to it, rather that discovering them while a call is
being processed.
Implementations of the CPL are expected to take place both in
Internet telephony servers and in advanced clients; both can usefully
process and direct users' calls. In the former case, a mechanism will
be needed to transport scripts between clients and servers; this
document does not describe such a mechanism, but related documents
will.
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 [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, and are not
essential to the specification of the language.
2 Structure of CPL scripts
2.1 Abstract structure
Lennox/Schulzrinne [Page 2]
Internet Draft CPL February 26, 1999
Abstractly, a CPL script is described by a collection of nodes, which
describe actions that can be performed or choices which can be made.
A node may have several parameters, which specify the precise
behavior of the node; they usually also have outputs, which depend on
the result of the condition or action.
For a graphical representation of a CPL script, see figure 1. Nodes
and outputs can be thought of informally as boxes and arrows; the CPL
is designed so that it can be conveniently edited graphically using
this representation. Nodes are arranged in a directed acyclic graph,
starting at a single root node; outputs of nodes are connected to
additional nodes. When a CPL script is run, the action or condition
described by the root node is performed; based on the result of that
node, the server follows one of the node's outputs, and that action
or condition is performed; this process continues until a node with
no specified outputs is reached. Because the graph is acyclic, this
will occur after a bounded and predictable number of nodes are
visited.
If an output to a node is not specified, it indicates that the CPL
server should perform a node- or protocol-specific action. Some nodes
have specific default actions associated with them; for others, the
default action is implicit in the underlying signalling protocol, or
can be configured by the administrator of the server.
_________________ ___________________ _______
Call --->| String-switch | | location | | proxy |---------\
| field: from | ->| url: sip:jones@ |--->| | busy |
|-----------------| / | example.com | | |---------|
| match: |/ |___________________| | | timeout |
| *@example.com | |_______|---------|
|-----------------| failure |
| otherwise | ____________________________________________/
| |\ / ____________________ __________
|_________________| \| | location | | redirect |
->| url: sip:jones@ |--->| |
| voicemail. | |__________|
| example.com |
| merge: clear |
|____________________|
Figure 1: Sample CPL Script: Graphical Version
Lennox/Schulzrinne [Page 3]
Internet Draft CPL February 26, 1999
2.2 XML Structure
Syntactically, CPL scripts are represented by XML documents. XML is
thoroughly specified by [3], and implementors of this specification
should be familiar with that document, but as a brief overview, XML
consists of a hierarchical structure of tags; each tag can have a
number of attributes. It is visually and structurally very similar to
HTML [5], as both languages are simplifications of the earlier and
larger standard SGML [6].
See figure 2 for the XML document corresponding to the graphical
representation of a CPL script in figure 1. Both nodes and outputs in
the CPL are represented by XML tags; parameters are represented by
XML tag attributes. Typically, node tags contain output tags, and
vice-versa (with one exception; see section 4.1).
The connection between the output of a node and another node is
represented by enclosing the tag representing the pointed-to node
inside the tag for the outer node's output. Convergence (several
outputs pointing to a single node) is represented by links, discussed
further in section 7. The top-level node is enclosed in the special
tag call; this is therefore the outermost tag of the XML.
A complete Document Type Declaration for the CPL is provided in
Appendix A. The remainder of the main sections of this document
describe the semantics of the CPL; for its syntax, please see the
appendix.
3 Switches
Switches represent choices the CPL script can make, based on either
attributes of the original call request or items independent of the
call.
All switches are arranged as a list of conditions that can match a
variable, each with one output pointing to the next node to execute
if that condition is matched. The conditions specified are tried in
the order they are presented in the script; the output corresponding
to the first node to match is taken. Switches also have an optional
otherwise output, following all the other outputs, that matches if no
previous node matched. If a switch does not have an otherwise
output, and no condition matched, the server should take a default
action, just as for any other un-attached node output, as discussed
in section 2.1.
The variable to match is specified in the initial switch tag, as a
field parameter. What variables are legal depends on which switch
Lennox/Schulzrinne [Page 4]
Internet Draft CPL February 26, 1999
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<string-switch field="from">
<string matches="*@example.com">
<location url="sip:jones@example.com">
<proxy>
<busy> <link ref="voicemail" /> </busy>
<noanswer> <link ref="voicemail" /> </noanswer>
<failure> <link ref="voicemail" /> </failure>
</proxy>
</location>
</string>
<otherwise>
<location url="sip:jones@voicemail.example.com"
merge="clear" id="voicemail">
<redirect />
</location>
</otherwise>
</string-switch>
</call>
Figure 2: Sample CPL Script: XML Version
type is specified; some variables are optional, and CPL servers MAY
define additional variables for each switch type. Because some
variables may not be supported by a server, CPL servers SHOULD
verify, at the time a script is submitted, that they support all the
variables specified in the script.
3.1 String Switch
String-switch is a condition which allows string matching on a string
variable. The node tag is named string-switch, and takes one
argument, field, as discussed above. The output tags are named
string, and take one mandatory and one optional argument. The
mandatory argument's name is one of is, contains, or matches,
indicating exact string match, substring match, or glob match of the
variable respectively.
The optional argument of string output tags is comparator, which
allows for internationalization of string matching. Strings to be
matched are always considered as strings of UTF-8 characters. CPL
servers MUST support the two comparators i;octet, indicating literal
Lennox/Schulzrinne [Page 5]
Internet Draft CPL February 26, 1999
comparison of UTF-8 octets, and i;ascii-casemap, which indicates that
alphabetic characters in the US-ASCII range should have their upper
and lower cases compared the same. If no comparitor is specified,
i;ascii-casemap is assumed. Comparators are defined by ACAP [7]; for
more information, see that specification. CPL servers SHOULD verify
at script submission time that all requested comparators are
supported by the server.
The naming scheme of comparators is as defined by ACAP; the
motivation of the "i;" prefix of the comparators is
unclear, but it seems to be some sort of namespace for
future use.
Question: should comparator be an attribute of the whole
string-switch as opposed to an attribute of each
comparison? There are arguments for either behavior.
All CPL servers MUST define the fields to and from for string
matching, containing URIs referring to the called and calling
addresses, respectively. CPL servers which run on SIP SHOULD also
define request-uri, subject, organization, priority, containing the
contents of the equivalent SIP headers, if present, and also
display-to, and display-from, containing the display names
corresponding to the called and calling addresses. CPL servers which
run on H.323 SHOULD define XXX.
Question: what are the appropriate string fields for H.323?
In this example, action1 is performed if the URL representation of
the caller's address exactly matches "sip:lennox@cs.columbia.edu,"
action2 is performed for any string which matches any user at any
host in the cs.columbia.edu domain, and action3 is taken in all other
cases.
<string-switch field="from">
<string is="sip:lennox@cs.columbia.edu">
-action1-
</string>
<string matches="*@*cs.columbia.edu">
-action2-
</string>
<otherwise>
-action3-
</otherwise>
Lennox/Schulzrinne [Page 6]
Internet Draft CPL February 26, 1999
</string-match>
3.2 Time Switch
Time-switch is a condition which allows matching on the time and/or
date the triggering call was placed. Times are matched in the
server's time zone. The node tag is named time-switch, and takes no
arguments; the output tags are named time.
Note: while it would be nice to allow clients to specify
their own time zone, there doesn't currently appear to be
any standard registry of time zone names, and we don't want
to have to define one just for the CPL. Leveraging off of
the iCalendar standard [8] would be nice, but their time
zone specification seems excessively heavyweight -- it
defines time zone rules explicitly (and very verbosely) in
its own syntax. Just specifying time zones as UTC offsets
would be possible, but this doesn't cover daylight-savings
time rules. Thus, we currently ignore the problem.
The time outputs can take the following optional arguments: year,
month, date, day, and timeofday. Each argument is syntactically
expressed as a list of numeric ranges. Ranges are delimited as
value-value; lists elements are separated by commas. Months are
specified in the range 1-12; date as 1-31, day as 0-6 (where 0 is
Sunday), and times of day as 24-hour times in the range 0000-2359;
years are unlimited in range, though only positive values are
allowed.
An output node matches if the time the triggering call was placed
falls within one of the ranges in all of the specified arguments.
The following examples show sample time nodes, and descriptions of
the corresponding time periods they indicate:
<time month="12" date="25" year="1999">
December 25th, 1999, all day
<time month="5" date="4">
May 4th, every year, all day
<time day="1-5" timeofday="0900-1700">
9 AM -- 5 PM, Monday through Friday, every week
<time timeofday="1310-1425,1440-1555,1610-1725" day="2,4">
Lennox/Schulzrinne [Page 7]
Internet Draft CPL February 26, 1999
1:10 -- 2:25 PM, 2:40 -- 3:55 PM, and 4:10 -- 5:25 PM, Tuesdays
and Thursdays, every week
<time date="1-7" day="1">
The first Monday of every month, all day
If more complicated time ranges need to be specified, they SHOULD be
broken down into component ranges specifiable in this syntax, and
their outputs connected the outputs to the same subsequent node with
links (see section 7).
3.3 Other Switches
Question: how should we switch based on media? We need a
syntax for this. We could just switch on media type as a
MIME type; the problem is that you may have several media
types defined. Other important attributes of media include
required bandwidth (numeric) and source address (IPv4
address, usually, but IPv6 in the future) -- do we need
switch types for these?
4 Locations
A number of CPL actions (defined in section 5) need to have locations
specified. An executing CPL always has some set of locations
specified; CPLs use location nodes to add or clear locations from the
set.
By default, location nodes add to the current set of locations.
Alternately, they can re-initialize the set, clearing it before
adding additional nodes. This is specified with the argument merge,
which can take two possible values, merge and clear. Its default
value is merge.
4.1 Basic Location
Basic location nodes (which have the tag name location) specify a
location literally, as a URL. They take a single argument, url; the
desired location is given as an argument. Only one location may be
specified per location node; multiple locations may be specified by
cascading these nodes.
Basic location nodes have only one possible output, since there is no
way that they can fail. (If a basic location node specifies a
location which isn't supported by the underlying signalling protocol,
the script server SHOULD detect this and report it to the user at the
time the script is submitted.) Therefore, its XML representation does
Lennox/Schulzrinne [Page 8]
Internet Draft CPL February 26, 1999
not have explicit output nodes; the <location> tag directly contains
another node tag.
4.2 Location Lookup
Locations can also be looked up through external means, through the
use of the lookup tag. The location to look up the result can be
specified either as a url, or as another source. External URLs, are
specified with the attribute url, and should refer to an external
source which returns the application/url media type. Other sources
are specified with the attribute source. The only source currently
defined is registration, which specifies all the locations currently
registered with the server, using SIP REGISTER or H.323 RAS messages.
A lookup tag MUST specify exactly one of url or source.
Lookup also has an optional attribute, timeout, which specifies the
time in seconds the script is willing to wait for the lookup to be
performed. Lookup has three outputs: success, notfound, and failure.
Notfound is taken if the lookup process succeeded but did not find
any locations; failure is taken if the lookup failed for some reason,
including that specified timeout was exceeded. If failure is not
specified, the action corresponding to notfound is taken; if notfound
is not specified, the success output is taken, but the current
location set is not modified. The success output must be given.
Clients SHOULD specify the three outputs success, notfound, and
failure in that order, so their script complies with the DTD given in
Appendix A, but servers SHOULD accept them in any order.
5 Signalling Actions
Signalling action nodes cause signalling events in the underlying
signalling protocol.
5.1 Proxy
Proxy causes the triggering call to be forwarded on to the currently
specified set of locations. The server chooses the "best" response to
the call attempt, as defined by the protocol or its configuration
rules. If the call attempt was successful, CPL execution terminates;
otherwise, one of the three outputs busy, noanswer, or failure is
taken.
Note: future extension of the CPL to allow in-call or end-
of-call actions will require success outputs to be added as
well.
Lennox/Schulzrinne [Page 9]
Internet Draft CPL February 26, 1999
Question: What other outputs are needed? Redirect? More
varieties of failure?
If no locations are specified at the time the proxy command is
executed, the server SHOULD attempt to proxy the call to its standard
set of addresses for the user, or inform the caller that the caller
is unavailable.
Proxy has one argument: timeout, which specifies the time, in
seconds, to wait for the call to be completed or rejected, after
which time the call attempt is terminated and the noanswer branch is
taken.
Question: Do we want to be able to specify timeouts in
other units, notably "number of rings"?
5.2 Redirect
Redirect causes the server to direct the calling party to attempt to
place its call to the currently specified set of locations. This
immediately terminates execution of the CPL script, so this node has
no outputs. This node also has no arguments other than the standard
Link ID target (see section 7).
5.3 Response
Response causes the server to reject the call attempt. This
immediately terminates execution of the CPL script, so this node has
no outputs.
This node has two arguments in addition to the standard Link ID (see
section 7): status and reason. The status argument is required, and
can take one of the values busy, notfound, reject, and error.
Servers which implement SIP MAY also allow a numeric argument here
corresponding to a SIP status in the 4xx, 5xx, or 6xx range, but
scripts SHOULD NOT use them if they wish to be portable.
The reason argument optionally allows the script to specify a reason
for the rejection. CPL servers MAY ignore the reason, but ones that
implement SIP SHOULD send them in the SIP reason phrase.
The CPL does not define any way to send intermediate responses to
call attempts. Servers SHOULD send them automatically, as
appropriate.
Note: we need more named statuses.
Lennox/Schulzrinne [Page 10]
Internet Draft CPL February 26, 1999
Question: Success and redirection are also responses.
Should this node be called "failure" or "reject" instead?
6 Other Actions
In addition to the signalling actions, the CPL defines several
actions which do not affect the telephony signalling protocol.
6.1 Notify
The Notify node causes the server to notify a user of the status of
the CPL script through some non-telephony means; for instance,
sending electronic mail, or delivering an instant message. It takes
two arguments: a required URL indicating the means and address to
contact (attribute url), and optionally a comment to be included in
that message (attribute comment). The server sends the message
containing the content to the given url; it SHOULD also include other
status information about the state of the call and the CPL script at
the time of the notification. Servers SHOULD check the specified
address at script submission time to ensure that they understand the
specified URL scheme.
This node has two outputs, success and failure. The success branch is
mandatory; if no failure branch is specified, the success branch is
taken. The outputs SHOULD be specified in the order given.
Question: is this too general? Notification is a very broad
concept. Would simply having a "Mailto" tag be cleaner?
6.2 Log
The Log node causes the server to log information about the call to
non-volatile storage. It takes two arguments, both optional: name,
which specifies the name of the log, and comment, which gives a
comment about the information being logged. Servers SHOULD also
include other information in the log, such as the time of the logged
event, information that triggered the call to be logged, and so
forth. Logs are specific to the owner of the script which log event.
This specification does not define how users may retrieve their logs
from the server.
This node has two outputs, success and failure. The success branch is
mandatory; if no failure branch is specified, the success branch is
taken. The outputs SHOULD be specified in the order given.
7 Links
Lennox/Schulzrinne [Page 11]
Internet Draft CPL February 26, 1999
XML syntax defines a tree. Because the general structure of the CPL
is instead intended to be a directed acyclic graph, we provide the
link structure to allow several node outputs to connect to a single
node.
Every XML tag which represents a node has an optional argument id,
which can be any XML id. (The id attribute is a standard XML
attribute, defined in section 3.3.1 of the XML specification.) Any
output which normally contains a node can, instead, contain a link
tag with a ref attribute specifying the ID of some other node.
Every link ref MUST refer to a link ID specified in the same CPL
script. No external links are permitted.
If any subsequent version ever defines external linkages,
it will use a different tag, perhaps XLINK [9].
When the CPL server initially processes the script, it MUST verify
that no link refers to a node that is its parent in the tree; i.e.,
it MUST verify that the directed graph created by the tree and the
links is acyclic. If it is not, the server SHOULD treat this error
in the same manner as any other syntax error in a script. (This
verification is algorithmically simply a matter of verifying that a
depth-first search of the directed graph contains no back edges; see,
for instance, [10], Lemma 23.10. It can typically be done
simultaneously with the resolution of links.)
If cycles were allowed in the graph, it would introduce the
possibility of non-terminating CPL scripts, a possibility
our requirements specifically excluded.
CPL servers MAY use link IDs to identify nodes for other purposes,
for instance to report errors or to provide real-time debugging or
flow information. Thus, scripts SHOULD provide IDs for every node for
which they are interested in such information, even if no link
connects to that node.
8 Examples
8.1 Example: Call Redirect Unconditional
The script in figure 3 is a simple script which redirects all calls
to a single fixed location.
8.2 Example: Call Forward Busy/No Answer
Lennox/Schulzrinne [Page 12]
Internet Draft CPL February 26, 1999
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<location url="sip:smith@phone.example.com">
<redirect />
</location>
</call>
Figure 3: Example Script: Call Redirect Unconditional
The script in figure 4 illustrates some more complex behavior. We see
an initial proxy attempt to one address, with further actions if that
fails. We also see how several outputs can point to the same node,
through the use of the link tag.
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<location url="sip:jones@jonespc.example.com">
<proxy timeout="8s">
<busy>
<location url="sip:jones@voicemail.example.com" merge="clear"
id="voicemail" >
<proxy />
</location>
</busy>
<noanswer>
<link ref="voicemail" />
</noanswer>
</proxy>
</location>
</call>
Figure 4: Example Script: Call Forward Busy/No Answer
8.3 Example: Call Screening
The script in figure 5 illustrates string switches and call
rejection, in the form of a call screening script. Note also that
Lennox/Schulzrinne [Page 13]
Internet Draft CPL February 26, 1999
because the string-switch lacks an otherwise clause, if the initial
pattern did not match, the script does not define any action. The
server therefore proceeds with its default action, which would
presumably be to contact the user.
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<string-switch field="from">
<string matches="anonymous@*">
<response status="reject"
reason="I don't accept anonymous calls" />
</string>
</string-switch>
</call>
Figure 5: Example Script: Call Screening
8.4 Example: Time-of-day Routing
Figure 6 illustrates time-based conditions.
8.5 Example: Non-call Actions
Figure 7 illustrates non-call actions; in particular, alerting a user
by electronic mail if the lookup server failed. The primary reason
for the Notify node is to allow this sort of out-of-band notification
of error conditions, as the user might otherwise be unaware of any
problem.
8.6 Example: A Complex Example
Finally, figure 8 is a complex example which shows the sort of
sophisticated behavior which can be achieved by combining CPL nodes.
In this case, the user attempts to have his calls reach his desk; if
he does not answer within a small amount of time, calls from his boss
are forwarded to his celphone, and all other calls are directed to
voicemail.
9 Security Considerations
Lennox/Schulzrinne [Page 14]
Internet Draft CPL February 26, 1999
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<time-switch>
<time day="1-5" timeofday="0900-1700">
<lookup source="registration">
<success>
<proxy />
</success>
</lookup>
</time>
<otherwise>
<location url="sip:jones@voicemail.example.com">
<proxy />
</location>
</otherwise>
</time-switch>
</call>
Figure 6: Example Script: Time-of-day Routing
The CPL is designed to allow services to be specified in a manner
which prevents potentially hostile or mis-configured scripts from
launching security attacks, including denial-of-service attacks.
Because script runtime is strictly bounded by acyclicity, and because
the number of possible script actions are strictly limited, scripts
should not be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by
which scripts are transmitted from a client to a server MUST be
strongly authenticated. Such a method is not specified in this
document.
Script servers SHOULD allow server administrators to control the
details of what CPL actions are permitted.
10 Acknowledgments
We would like to thank Tom La Porta and Jonathan Rosenberg for their
contributions and suggestions.
We drew a good deal of inspiration, notably the language's lack of
Turing-completeness and the syntax of string matching, from the
specification of Sieve [11], a language for user filtering of
Lennox/Schulzrinne [Page 15]
Internet Draft CPL February 26, 1999
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<lookup url="http://www.example.com/cgi-bin/locate.cgi?user=jones"
timeout="8s">
<success>
<proxy />
</success>
<failure>
<notify url="mailto:jones@example.com"
comment="The lookup server failed">
<success>
<response status="error" />
</success>
</notify>
</failure>
</lookup>
</call>
Figure 7: Example Script: Non-call Actions
electronic mail messages.
A The XML DTD for CPL
This section includes a full DTD describing the XML syntax of the
CPL. Every script submitted to a CPL server SHOULD comply with this
DTD; however, CPL servers SHOULD allow minor variations from it,
particularly in the ordering of output branches of nodes. Note that
compliance with this DTD is not a sufficient condition for
correctness of a CPL script, as many of the conditions described
above are not expressible in DTD syntax.
Lennox/Schulzrinne [Page 16]
Internet Draft CPL February 26, 1999
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<call>
<location url="sip:jones@phone.example.com">
<proxy timeout="8s">
<busy>
<location url="sip:jones@voicemail.example.com" merge="clear">
<redirect />
</location>
</busy>
<noanswer>
<string-switch field="from">
<string matches="boss@*example.com">
<location url="phone:+19175551212" merge="clear">
<proxy />
</location>
</string>
<otherwise>
<location url="sip:jones@voicemail.example.com" merge="clear">
<redirect />
</location>
</otherwise>
</string-switch>
</noanswer>
</proxy>
</location>
</call>
Figure 8: Example Script: A Complex Example
<?xml version="1.0" encoding="US-ASCII" ?>
<!--
Initial draft DTD for CPL, corresponding to
draft-ietf-iptel-cpl-00.
-->
<!-- Define types of nodes -->
<!-- Switch nodes -->
<!ENTITY % Switch 'string-switch|time-switch' >
<!-- Location nodes -->
<!ENTITY % Location 'location|lookup' >
Lennox/Schulzrinne [Page 17]
Internet Draft CPL February 26, 1999
<!-- Signalling action nodes -->
<!ENTITY % SignallingAction 'proxy|redirect|response' >
<!-- Other actions -->
<!ENTITY % OtherAction 'notify|log' >
<!-- Nodes are one of the above four categories, or a link.
This entity (macro) describes the contents of an output. -->
<!ENTITY % Node '%Location;|%Switch;|%SignallingAction;|
%OtherAction;|link' >
<!-- Nodes can have link IDs. Since this is an attribute of every
node, we need to define it early. -->
<!ENTITY % Link-ID 'id ID #IMPLIED'>
<!-- Switches: choices a CPL script can make. -->
<!-- All switches contain an 'otherwise' node. -->
<!ELEMENT otherwise ( %Node; ) >
<!-- String-switch makes choices based on strings. -->
<!ELEMENT string-switch ( string+, otherwise? ) >
<!ATTLIST string-switch
field CDATA #REQUIRED
%Link-ID;
>
<!ELEMENT string ( %Node; ) >
<!ATTLIST string
is CDATA #IMPLIED
contains CDATA #IMPLIED
matches CDATA #IMPLIED
comparator CDATA "i;ascii-casemap"
>
<!-- Time-switch makes choices based on the current time. -->
<!ELEMENT time-switch ( time+, otherwise? ) >
<!ATTLIST time-switch
%Link-ID;
>
<!ELEMENT time ( %Node; ) >
<!ATTLIST time
year CDATA #IMPLIED
Lennox/Schulzrinne [Page 18]
Internet Draft CPL February 26, 1999
month CDATA #IMPLIED
date CDATA #IMPLIED
day CDATA #IMPLIED
timeofday CDATA #IMPLIED
>
<!-- Locations: ways to specify the location a subsequent action
(proxy, redirect) will attempt to contact. -->
<!ENTITY % Merge 'merge (merge|clear) "merge"' >
<!ELEMENT location ( %Node; ) >
<!ATTLIST location
url CDATA #REQUIRED
%Merge;
%Link-ID;
>
<!-- Sources of location lookups that aren't URIs. -->
<!ENTITY % Sources '(registration)' >
<!ELEMENT lookup ( success,notfound?,failure? ) >
<!ATTLIST lookup
url CDATA #IMPLIED
source %Sources; #IMPLIED
timeout CDATA #IMPLIED
%Merge;
%Link-ID;
>
<!ELEMENT success ( %Node; ) >
<!ELEMENT notfound ( %Node; ) >
<!ELEMENT failure ( %Node; ) >
<!-- Signalling Actions: call-signalling actions the script can
take. -->
<!ELEMENT proxy ( busy?,noanswer?,failure? ) >
<!ATTLIST proxy
timeout CDATA #IMPLIED
%Link-ID;
>
<!ELEMENT busy ( %Node; ) >
<!ELEMENT noanswer ( %Node; ) >
<!-- "failure" repeats from lookup above. XXX? -->
<!ELEMENT redirect EMPTY >
Lennox/Schulzrinne [Page 19]
Internet Draft CPL February 26, 1999
<!ATTLIST redirect
%Link-ID;
>
<!-- Statuses we can return -->
<!ELEMENT response EMPTY >
<!ATTLIST response
status CDATA #REQUIRED
reason CDATA #IMPLIED
%Link-ID;
>
<!-- Non-signalling actions: actions that don't affect the call -->
<!ELEMENT notify ( success,failure? ) >
<!ATTLIST notify
url CDATA #REQUIRED
comment CDATA #IMPLIED
%Link-ID;
>
<!ELEMENT log ( success,failure? ) >
<!ATTLIST log
name CDATA #IMPLIED
comment CDATA #IMPLIED
%Link-ID;
>
<!-- Links to other nodes. -->
<!ELEMENT link EMPTY >
<!ATTLIST link
ref IDREF #REQUIRED
>
<!-- The top-level element of the script. -->
<!ELEMENT call ( %Node; ) >
B Authors' Addresses
Jonathan Lennox
Dept. of Computer Science
Lennox/Schulzrinne [Page 20]
Internet Draft CPL February 26, 1999
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
C Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Internet Draft, Internet Engineering
Task Force, Jan. 1999. Work in progress.
[2] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-guaranteed
quality of service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[3] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup
language (XML) 1.0," W3C Recommendation 10-February-1998, World Wide
Web Consortium (W3C), Feb. 1998. http://www.w3.org/TR/REC-xml.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," BC 2119, Internet Engineering Task Force, Mar. 1997.
[5] D. Raggett, A. L. Hors, and I. Jacobs, "HTML 4.0 specification,"
W3C Recommendation revised on 24-Apr-1998, World Wide Web Consortium
(W3C), Apr. 1998. http://www.w3.org/TR/REC-html40/.
[6] ISO (International Organization for Standardization),
"Information processing -- text and office systems -- standard
generalized markup language (SGML)," ISO Standard ISO 8879:1986(E),
International Organization for Standardization, Geneva, Oct. 1986.
[7] J. Myers and C. Newman, "ACAP -- application configuration access
protocol," Request for Comments (Proposed Standard) 2244, Internet
Engineering Task Force, Dec. 1997.
[8] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
core object specification (icalendar)," Request for Comments
(Proposed Standard) 2445, Internet Engineering Task Force, Nov. 1998.
Lennox/Schulzrinne [Page 21]
Internet Draft CPL February 26, 1999
[9] E. Maler and S. DeRose, "XML linking language (XLink)," Working
Draft 3-March-1998, World Wide Web Consortium (W3C), Mar. 1998.
http://www.w3.org/TR/WD-xlink.
[10] T. H. Cormen, C. E. Leiserson, and R. L. Rivest, Introduction to
Algorithms New York: McGraw-Hill, 1990.
[11] T. Showalter, "Sieve: A mail filtering language," Internet
Draft, Internet Engineering Task Force, Jan. 1999. Work in progress.
Full Copyright Statement
Copyright (c) The Internet Society (1999). 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.
Table of Contents
1 Introduction ........................................ 1
1.1 Conventions Of This Document ........................ 2
Lennox/Schulzrinne [Page 22]
Internet Draft CPL February 26, 1999
2 Structure of CPL scripts ............................ 2
2.1 Abstract structure .................................. 2
2.2 XML Structure ....................................... 4
3 Switches ............................................ 4
3.1 String Switch ....................................... 5
3.2 Time Switch ......................................... 7
3.3 Other Switches ...................................... 8
4 Locations ........................................... 8
4.1 Basic Location ...................................... 8
4.2 Location Lookup ..................................... 9
5 Signalling Actions .................................. 9
5.1 Proxy ............................................... 9
5.2 Redirect ............................................ 10
5.3 Response ............................................ 10
6 Other Actions ....................................... 11
6.1 Notify .............................................. 11
6.2 Log ................................................. 11
7 Links ............................................... 11
8 Examples ............................................ 12
8.1 Example: Call Redirect Unconditional ................ 12
8.2 Example: Call Forward Busy/No Answer ................ 12
8.3 Example: Call Screening ............................. 13
8.4 Example: Time-of-day Routing ........................ 14
8.5 Example: Non-call Actions ........................... 14
8.6 Example: A Complex Example .......................... 14
9 Security Considerations ............................. 14
10 Acknowledgments ..................................... 15
A The XML DTD for CPL ................................. 16
B Authors' Addresses .................................. 20
C Bibliography ........................................ 21
Lennox/Schulzrinne [Page 23]
