Internet Engineering Task Force                                 IPTEL WG
Internet Draft                                        Lennox/Schulzrinne
ietf-iptel-cpl-00.txt
draft-ietf-iptel-cpl-01.txt                          Columbia University
February 26, 1999
March 10, 2000
Expires: September 1999 2000

    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

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories, see Directories can be accessed at
     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
   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 loops or a function. recursion.

   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.

   The framework and requirements for the CPL architecture are described
   in the document "Call Processing Language Framework and
   Requirements," which will be an Informational RFC; it is currently
   available as the Internet-Draft draft-ietf-iptel-cpl-framework-02
   [4].

1.1 Conventions Of This Document 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] [5] and
   indicate requirement levels for compliant CPL implementations.

   In examples, non-XML strings such as -action1- , -action2- , -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 High-level structure

   A CPL script consists of two types of information: ancillary
   information about the script, and call processing actions.

   A call processing action is a structured tree that describes the
   decisions and actions a telephony signalling server performs on a
   call set-up event.  There are two types of call processing actions:
   top-level actions are actions that are triggered by signalling events
   that arrive at the server.  Two top-level action names are defined:
   incoming, the action performed when a call arrives whose destination
   is the owner of the script; and outgoing, the action performed when a
   call arrives whose originator is the owner of the script. Sub-actions
   are actions which can be called from other actions. The CPL forbids
   sub-actions from being called recursively: see section 8.

        Note: The names "action," "sub-action," and "top-level
        action" are probably not ideal. Suggestions for better
        names for these concepts are welcomed.

   Ancillary information is information which is necessary for a server
   to correctly process a script, but which does not directly describe
   any actions. Currently, the only type of ancillary information
   defined is timezone definitions; see section 9.

2.2 Abstract structure of a call processing action

   Abstractly, a CPL script call processing action 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, action, see figure 1.  Nodes
   and outputs can be thought of informally as boxes and arrows; the CPL
   is designed so that it actions can be conveniently edited graphically
   using this representation. Nodes are arranged in a directed acyclic graph, tree, starting at
   a single root node; outputs of nodes are connected to additional
   nodes. When a CPL script an action is run, the action or condition described by
   the root top-level 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. For further
   details on this, see section 10.

          _________________      ___________________      _______
Call --->| String-switch      ________  busy
         | Address-switch  |    | location          |    | proxy |---------\
         |  |--------\
Call --->|  field: from origin  |  ->|   url: sip:jones@ |--->| |--->|timeout:| timeout|
         | busy  subfield: host |
         |-----------------| /  |     example.com   |    |       |---------|
         | match:          |/  10s   |--------|
         |-----------------|/   |___________________|    |        | timeout failure|
         | subaddress-of:  |   *@example.com                             |________|--------|
         |                             |_______|---------|
         |-----------------|                                       failure   example.com   |                                               |
         |-----------------|  _____________________________________________/
         | otherwise       |   ____________________________________________/ /..........................................
         |                 |\ /  ____________________ 	   __________                 |\|. Voicemail                              .
         |_________________| \| | \.  ____________________                  .
                              ->| location           |     __________  .
                              . | redirect |
                              ->|   url: sip:jones@  |--->|  |	  | redirect | .
                              . |        voicemail.  |--->|          |	  |__________| .
                              . |        example.com |
                                |   merge: clear     |	  |__________| .
                              . |____________________|                 .
                              ..........................................

   Figure 1: Sample CPL Script: Action: Graphical Version

2.2

2.3 Location model

   For flexibility, one piece of information necessary for the function
   of a CPL is not given as node parameters: the set of locations to
   which a call is to be directed. Instead, this set of locations is
   stored as an implicit global variable throughout the execution of a
   processing action (and its sub-actions). This allows locations to be
   retrieved from external sources, filtered, and so forth, without
   requiring general language support for such actions (which could harm
   the simplicity and tractability of understanding the language). The
   specific actions which add, retrieve, or filter location sets are
   given in section 5.

   For the incoming top-level processing action, the location set is
   initialized to the empty set. For the outgoing action, it is
   initialized to the destination address of the call.

2.4 XML Structure 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], [6], as both languages are simplifications of the earlier and
   larger standard SGML [6]. [7].

   See figure 2 for the XML document corresponding to the graphical
   representation of a the 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). 2.3).

   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, sub-actions,
   discussed further in section 7. 8.

   The higher-level structure of a CPL script is represented by tags
   corresponding to each piece of meta-information, sub-actions, and
   top-level node actions, in order. This higher-level information is all
   enclosed in the a special tag call; this is therefore cpl, the outermost tag of the XML. XML document.

   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 CPL, while giving its syntax
   informally.  For the formal syntax, please see the appendix.

3 Script structure: overview

   As mentioned, a CPL script consists of ancillary information,
   subactions, and top-level actions. The full syntax of the cpl node is
   given in figure 3.

   Call processing actions, both top-level actions and sub-actions,
   <?xml version="1.0" ?>
   <!DOCTYPE cpl SYSTEM "cpl.dtd">

   <cpl>
     <subaction id="voicemail">
       <location url="sip:jones@voicemail.example.com">
         <redirect />
       </location>
     </subaction>

     <incoming>
       <address-switch field="origin" subfield="host">
         <address subdomain-of="example.com">
           <location url="sip:jones@example.com">
             <proxy>
               <busy> <sub ref="voicemail" /> </busy>
               <noanswer> <sub ref="voicemail" /> </noanswer>
               <failure> <sub ref="voicemail" /> </failure>
             </proxy>
           </location>
         </address>
         <otherwise>
           <sub ref="voicemail" />
         </otherwise>
       </address-switch>
     </incoming>
   </cpl>

   Figure 2: Sample CPL Script: XML Version

   consist of nodes and outputs. Nodes and outputs are both described by
   XML tags. There are four categories of CPL nodes: switches , location
   modifiers , signalling actions , and non-signalling actions.

4 Switches

   Switches represent choices the a 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
   variable. Each condition corresponds to a node output; the output pointing
   points to the next node to execute if that the condition is matched. was true.  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

         Node:  cpl
   Parameters:  none
      Outputs:  timezone   See section 9
                subaction  See section 8
                outgoing   Top-level actions to take on this user's outgoing calls
                incoming   Top-level actions to take on this user's incoming calls

       Output:  outgoing
   Parameters:  none

       Output:  incoming
   Parameters:  none

   Figure 3: Syntax of the other outputs, top-level cpl tag

   There are two special switch outputs that apply to every switch type.
   The output not-present is true if the variable the switch was to
   match was not present in the original call. The output otherwise,
   which MUST be the last output specified, matches if no
   previous node other
   condition matched.

   If a switch does not have an otherwise
   output, and no condition matched, matches and no otherwise output was present in the
   script, the server should take a default
   action, just as for any other un-attached node output, as discussed
   in script action is taken. See section 2.1.

   The variable 10 for more
   information on this.

4.1 Address switches

   Address switches allow a CPL script to match is specified make decisions based on one of
   the addresses present in the initial switch tag, as a
   field parameter. What variables are legal depends on which switch
   <?xml version="1.0" ?>
   <!DOCTYPE original 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 request. They are optional,
   summarized in figure 4.

   Address switches have two node parameters: field, 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 subfield.  The
   mandatory field parameter allows the time a script to specify which address
   is submitted, that they support all to be considered for the
   variables specified in switch: either 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, call's origin address
   (field "origin"), its current destination address (field
   "destination"), or glob match of its original destination (field "original-
   destination"), the
   variable respectively. destination the call had before any earlier
   forwarding was invoked. Servers MAY define additional subfield
   values.

   The optional argument subfield specifies what part of string output tags the address is comparator, which
   allows for internationalization of string matching. Strings to be
   matched
   considered. The possible subfield values are: address-type, user,
   host, port, tel, and display.  Additional subfield values MAY be
   defined: two additional ones, password and asn1 are always considered as strings defined
         Node:  address-switch
      Outputs:  address         Specific addresses to match
   Parameters:  field           origin, destination, or original-destination
                subfield        address-type, user, host, port, tel, display,
                                password, or asn1

       Output:  address
   Parameters:  is              exact match
                contains        substring match (for display only)
                subdomain-of    sub-domain match (for host, tel only)

   Figure 4: Syntax of UTF-8 characters. CPL
   servers MUST support the two comparators i;octet, indicating literal
   comparison of UTF-8 octets, address-switch node

   specifically for SIP and i;ascii-casemap, which indicates that
   alphabetic characters H.323 respectively, in the US-ASCII range should have their upper sections 4.1.1 and lower cases compared the same.
   4.1.2 below. If no comparitor subfield is specified,
   i;ascii-casemap the "entire" address is
   matched; the precise meaning of this 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 each underlying
   signalling protocol.

   The subfields are
   supported defined as follows:

        address-type This indicates the type of the underlying address;
             i.e., the URI scheme, if the address can be represented by
             the server. URI. The naming scheme of comparators is as defined types specifically discussed by ACAP; this document
             are sip, tel, and h323. The address type is not case-
             sensitive; it is always present if the
        motivation address is present.

        user This subfield of the "i;" prefix address indicates, for e-mail style
             addresses, the user part of the comparators address. For telephone
             number style address, it includes the subscriber number.
             This subfield is
        unclear, but case-sensitive; it seems to be some sort of namespace for
        future use.

        Question: should comparator may be an attribute not present.

        host This subfield of the whole
        string-switch as opposed address indicates the Internet host
             name or IP address corresponding 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 address, in host
             name, IPv4, or IPv6 format. For host names only, subdomain
             matching is supported with the called subdomain-of match operator.
             It is not case sensitive, and calling
   addresses, respectively. CPL servers which run on SIP SHOULD also
   define request-uri, subject, organization, priority, containing may be not present.

        port This subfield indicates the
   contents TCP or UDP port number of the equivalent SIP headers,
             address, numerically in decimal format. It is not case
             sensitive, as it MUST only contain decimal digits. It may
             be not present; however, for address types with default
             ports, an absent port matches the default port number.

        tel This subfield indicates a telephone subscriber number, if present,
             the address contains such a number. It is not case
             sensitive (the telephone numbers may contain the symbols
             `A' `B' `C' and also
   display-to, `D'), and display-from, containing may be not present. It may be
             matched using the subdomain-of match operator.  Punctuation
             and separator characters in telephone numbers are
             discarded.

        display names This subfield indicates a "display name" or user-visible
             name corresponding to the called an address. It is a Unicode string,
             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 matched using the caller's address exactly matches "sip:lennox@cs.columbia.edu,"
   action2 is performed for any string which matches case-insensitive algorithm
             described in section 4.2. The contains operator may be
             applied to it. It may be not present.

   For any user completely unknown subfield, the server MAY reject the script
   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>
   </string-match>

3.2 Time Switch

   Time-switch time it is submitted with an indication of the problem; if a condition which allows matching on
   script with an unknown subfield is executed, the time and/or
   date server MUST consider
   the triggering call was placed. Times are matched in not-present output to be the
   server's time zone. valid one.

   The node tag is named time-switch, and takes no
   arguments; the address 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 tag may take exactly one just for of three possible
   parameters, indicating the CPL.  Leveraging off kind of matching allowed.

        is An output with this match operator is followed if the iCalendar standard [8] would be nice, but their time
        zone specification seems excessively heavyweight -- it
        defines time zone rules explicitly (and very verbosely)
             subfield being matched in
        its own syntax. Just specifying time zones as UTC offsets
        would the address-switch exactly
             matches the argument of the operator. It may be possible, but this doesn't cover daylight-savings
        time rules. Thus, we currently ignore used for
             any subfield, or for the problem.

   The time outputs can take entire address if no subfield was
             specified.

        subdomain-of This match operator applies only for the following optional arguments:  year,
   month, date, day, subfields
             host and timeofday. Each argument tel. In the former case, it matches if the
             hostname being matched is syntactically
   expressed as a list subdomain of numeric ranges. Ranges are delimited as
   value-value; lists elements are separated by commas. Months are
   specified the domain given
             in the range 1-12; date as 1-31, day as 0-6 (where 0 is
   Sunday), and times argument of day as 24-hour times in the range 0000-2359;
   years are unlimited in range, though match operator; thus,
             match="example.com" would match the hostnames
             "example.com", "research.example.com", and
             "zaphod.sales.internal.example.com". IP addresses may be
             given as arguments to this operator; however, they only positive values are
   allowed.

   An
             match exactly. In the case of the tel subfield, the output node
             matches if the time telephone number being matched has a prefix
             that matches the triggering call was placed
   falls within one argument of the ranges in all of match operator;
             match="1212555" would match the specified arguments. telephone number "1 212 555
             1212."

        contains This match operator applies only for the subfield
             display. The following examples show sample time nodes, output matches if the display name being
             matched contains the argument of the match as a substring.

4.1.1 Address switch mapping for SIP

   For SIP, the origin address corresponds to the address in the From
   header; destination corresponds to the Request-URI; and descriptions original-
   destination corresponds to the To header.

   The display subfield of an address is 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">
        1:10 -- 2:25 PM, 2:40 -- 3:55 PM, display-name part of the
   address, if it is present. Because of SIP's syntax, the destination
   address field will never have a display subfield.

   The address-type subfield of an address is the URI scheme of that
   address. Other address fields depend on that address-type.

   For sip URLs, the user, host, and 4:10 -- 5:25 PM, Tuesdays port subfields correspond to the
   "user," "host," and Thursdays, every week

   <time date="1-7" day="1"> "port" elements of the URI syntax. The first Monday tel
   subfield is defined to be the "user" part of the URI if and only if
   the "user=phone" parameter is given to the URI. An additional
   subfield, password is defined to correspond to the "password" element
   of the SIP URI; however, use of this field is NOT RECOMMENDED for
   general security reasons.

   For tel URLs, the tel and user subfields are the subscriber name; in
   the former case, "noise" characters are stripped. the host and port
   subfields are both not present.

   For other URI schemes, only the address-type subfield is defined by
   this specification; servers MAY set others of the pre-defined
   subfields, or MAY support additional subfields.

   If no subfield is specified for addresses in SIP messages, the string
   matched is the URI part of the address, with all parameters stripped.

4.1.2 Address switch mapping for H.323

   For H.323, the origin address corresponds to the address in the
   sourceAddress field; both destination and original-destination
   correspond to the destinationAddress field, as H.323 has no
   indication of original destination.

   For all addresses in H.323 messages, the value of the address-type
   field is h323. The tel tag is set to the AliasAddress, if its type is
   e164. The user tag is set to h323-ID; host is set to
   transportID/TransportAddress/ipAddress, translated to a dotted-quad;
   port is set to transportID/TransportAddress/ipAddress/port. The
   display tag is not present. An additional subfield, asn1, is defined
   as the textually-encoded ASN.1 of the address. The matching if no
   subfield is specified is undefined at this time.

        TODO: Have this looked over by an H.323 expert for
        accuracy/completeness. Once an h323 URL scheme is defined,
        it should be used for the whole-address matching.

4.2 String switches

   String switches allow a CPL script to make decisions based on free-
   form Unicode strings present in a call request. They are summarized
   in figure 5.

           Node:  string-switch
        Outputs:  string         Specific string to match
     Parameters:  field          subject, organization, or user-agent

         Output:  string
     Parameters:  is             exact match
                  contains       substring match

   Figure 5: Syntax of the string-switch node

   String switches have one node parameter: field. The mandatory field
   parameter specifies which string is to be matched. Currently three
   fields are defined: subject, indicating the subject of the call;
   organization, indicating the originator's organization; and user-
   agent, indicating the program or device with which the call request
   was made. All these fields correspond to SIP strings.

        TODO: Need H.323 free-form strings. "Data"?

   Strings are matched as case-insensitive Unicode strings, in the
   following manner. First, strings are canonicalized to the
   "Compatibility Composition" (KC) form, as specified in Unicode
   Technical Report 15 [8]. Then, strings are compared using locale-
   insensitive caseless mapping, as specified in Unicode Technical
   Report 21 [9].

        Code to perform the first step, in Java and Perl, is
        available; see the links from Annex E of UTR 15 [8]. The
        case-insensitive string comparison in the Java standard
        class libraries already performs the second step; other
        Unicode-aware libraries should be similar.

   The output tags of string matching are named string, and have a
   mandatory argument, one of is or contains, indicating whole-string
   match or substring match, respectively.

4.3 Time switches

   Time switches allow a CPL script to make decisions based the time
   and/or date the script is being executed. They are summarized in
   figure 6.

            Node:  time-switch
         Outputs:  time         Specific time to match
      Parameters:  timezone     local, utc, or other (see section 9)

          Output:  time
      Parameters:  year         Years to match
                   month        Months to match
                   date         Days of month to match
                   weekday      Days of week to match
                   timeofday    Times of day to match

   Figure 6: Syntax of the time-switch node

   Time switches take one optional parameter, timezone, which specifies
   the time zone in which matching is to take place. Two values of this
   are predefined: local indicates the time zone in which the server is
   located, and utc indicates Universal Coordinated Time. Timezones may
   also be specified in the ancillary information; see section 9.

   The time outputs can take the following optional parameters:  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 specified the ranges in each of the specified
   parameters.

   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">
             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
   subactions (see section 8).

   The not-present output is never true for a time switch.

        Note: XML schemas [10] define their own "time instant" and
        "time duration" syntax. Would it be better to base this
        syntax on that? It doesn't seem to be quite as powerful.

        Note: the question of whether the week should start at
        Sunday or Monday, and of whether numbering starts at 0 or
        1, was a matter of some dispute. In the absence of any
        convincing argument in favor of any one proposal, the
        current choice (Sunday is 0) was chosen semi-arbitrarily,
        because it corresponds to the tm_wday field of C's struct
        tm.

        Note: the way of specifying "first Monday of month" and
        "last Monday of month" is awfully hackish. Would it be
        worthwhile to add a week parameter, which could optionally
        be negative to count from the end of the month?

4.4 Priority switches

   Priority switches allow a CPL script to make decisions based on the
   priority specified for the original call. They are summarized in
   figure 7.

   Priority switches take no parameters.

         Node:  priority-switch
      Outputs:  priority         Specific priority to match
   Parameters:  none

       Output:  priority
   Parameters:  less             Match if priority is less than specified
                greater          Match if priority is greater than specified
                equal            Match if priority is equal to specified

   Figure 7: Syntax of the priority-switch node

   The priority tags take one of the three parameters greater, less, and
   equal. The values of these tags are the priorities specified in SIP
   [1]: in decreasing order, emergency, urgent, normal, and non-urgent.
   These values are matched in a case-insensitive manner. Outputs with
   the less parameter are taken if the priority of the message is less
   than the priority given in the argument; and so forth.

   If no priority header is specified in a message, the priority is
   considered to be normal. If an unknown priority is given, the
   priority is considered to be equivalent to normal for the purposes of
   greater and less comparisons, but it is compared literally for equal
   comparisons.

   Since every message has a priority, the not-present output is never
   true for a priority switch.

5 Location modifiers

   The abstract location model of the CPL is described in section 2.3.
   The behavior of several of the signalling actions (defined in section
   6) is dependent on the current location set specified. Location nodes
   add to or remove locations from the location set.

   There are three types of location nodes defined. Explicit locations
   add literally-specified locations to the current location set;
   location lookups obtain locations from some outside source; and
   location filters remove locations from the set, based on some
   specified criteria.

5.1 Explicit location

   Explicit location nodes specify a location literally. Their syntax is
   described in figure 8.

             Node:  location
          Outputs:  any node
       Parameters:  url       URL of address to add to location set

   Figure 8: Syntax of the location node

   Explicit location nodes have one node parameter: url, whose value is
   the URL of the address to add to the location set. Only one address
   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
   not have explicit output nodes; the <location> tag directly contains
   another node tag.

5.2 Location lookup

   Locations can also be specified up through external means, through
   the use of location lookups. The syntax of these tags is given in
   figure 9.

   Location lookup nodes have one mandatory parameter, and three
   optional parameters. The mandatory parameter is source, the source of
   the lookup. This can either be a URL, or a non-URL value. If the
   value of source is a URL, it indicates a location which returns the
   application/url media type. The server adds the locations returned by
   the URL to the location set.

   Non-URL sources indicate a source not specified by a URL which the
   server can query for addresses to add to the location set.  The only
   non-URL source currently defined is registration, which specifies all
   the locations currently registered with the server, using SIP
   REGISTER or H.323 RAS messages.

   The lookup node also has an three optional parameters. The timeout
   parameter which specifies the time, in seconds, the script is willing
   to wait for the lookup to be performed.  If this is not specified,
   its default value is 30.

           Node:  lookup
        Outputs:  success   Action if lookup was successful
                  notfound  Action if lookup found no addresses
                  failure   Action if lookup failed
     Parameters:  source    Source of the lookup
                  timeout   Time to try before giving up on the lookup
                  use       Caller preferences fields to use
                  ignore    Caller preferences fields to ignore

         Output:  success
     Parameters:  none

         Output:  notfound
     Parameters:  none

         Output:  failure
     Parameters:  none

   Figure 9: Syntax of the lookup node

   The other two optional parameters affect the interworking of the CPL
   script with caller preferences and caller capabilities. These are
   defined in the Internet-Draft "SIP Caller Preferences and Callee
   Capabilities" [11]. By default, a CPL server SHOULD invoke caller
   preferences filtering when performing a lookup action.  The two
   parameters use and ignore allow the script to modify how the script
   applies caller preferences filtering. The use and ignore parameters
   both take as their arguments comma-separated lists of caller
   preferences parameters. If use is given, the server applies the
   caller preferences resolution algorithm only to those preference
   parameters given in the use parameter, and ignores all others; if the
   ignore parameter is given, the server ignores the specified
   parameters, and uses all the others. Only one of use and ignore can
   be specified. The addr-spec part of the caller preferences is always
   applied, and the script cannot modify it.

        Note: this is very SIP-specific. Does H.323 have a similar
        endpoint-capabilities and requested-capabilities mechanism?

        TODO: Add examples. This is confusing.

   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 included.

   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.3 Location filtering

   A CPL script can also filter addresses out of the address set,
   through the use of a mechanism very similar to caller preferences:
   the remove-location node. The syntax of these nodes is defined in
   figure 10.

          Node:  remove-location
       Outputs:  any node
    Parameters:  param            Caller preference parameter to apply
                 value            Value of caller preference parameter
                 location         Caller preference location to apply

   Figure 10: Syntax of the remove-location node

   A remove-location node has the same effect on the location set as a
   Reject-Contact header in caller preferences [11]. The value of the
   location parameter is treated as though it were the addr-spec field
   of a Reject-Contact header; an absent header is equivalent to an
   addr-spec of every month, all day "*" in that specification. If more complicated time ranges need to param and value are
   present, their values are comma-separated lists of caller preferences
   parameters and corresponding values, respectively. There MUST be specified, the
   same number of parameters as values specified. These are treated, for
   location filtering purposes, as though they SHOULD appeared in the params
   field of a Reject-Location header, as "; param=value" for each one.

        Note: do we want to be
   broken down into component ranges specifiable able to switch based on whether
        there are any locations left in the set after a lookup?

        Note: this syntax, is also very SIP-specific. Does H.323 have a
        similar endpoint-capabilities mechanism?
        TODO: Add examples. This is also confusing.

6 Signalling actions

   Signalling action nodes cause signalling events in the underlying
   signalling protocol. Three signalling actions are defined: "proxy,"
   "redirect," and
   their outputs connected "reject."

6.1 Proxy

   Proxy causes the outputs triggering call to be forwarded on to the same subsequent currently
   specified set of locations. The syntax of the proxy node with
   links (see section 7).

3.3 Other Switches

        Question: how should we switch based is given in
   figure 11.

         Node:  lookup
      Outputs:  busy      Action if call attempt returned "busy"
                noanswer  Action if call attempt was not answered before timeout
                failure   Action if call attempt failed
   Parameters:  timeout   Time to try before giving up on media? We need the call attempt
                recurse   Whether to recursively look up redirections
                ordering  What order to try the location set in.

       Output:  busy
   Parameters:  none

       Output:  noanswer
   Parameters:  none

       Output:  failure
   Parameters:  none

   Figure 11: Syntax of the proxy node

   After a
        syntax for this. We could just switch on media type proxy action has completed, the CPL server chooses the "best"
   response to the call attempt, as defined by the signalling protocol
   or the server's administrative configuration rules.

   If the call attempt was successful, or if a
        MIME type; redirection response was
   the "best" response and recurse was not specified, CPL execution
   terminates and the problem best response is that you may have several media
        types defined. Other important attributes forwarded back upstream to the
   originator.  Otherwise, one 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 three outputs busy, noanswer, or
   failure is taken.

        Note: future extension of the CPL to allow in-call or end-
        of-call actions (defined in section 5) need will require success outputs to have locations
   specified. An executing CPL always has some set of locations
   specified; CPLs use be added.

        Question: should an explicit redirection output be added
        for the case when recurse was false? How should it interact
        with the location nodes set?

   Proxy has three optional parameters. The timeout parameter specifies
   the time, in seconds, to add or clear locations from wait for the
   set.

   By default, location nodes add call to be completed or
   rejected; after this time has elapsed, the current set of locations.
   Alternately, they can re-initialize call attempt is terminated
   and the set, clearing it before
   adding additional nodes. This noanswer branch is specified with taken.  If this parameter is not
   specified, 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 20 seconds if the tag name location) specify a
   location literally, as a URL. They take proxy node has a single argument, url;
   no-answer output specified; otherwise the
   desired location is given as server SHOULD allow the
   call to ring for 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 arbitrarily long period of time.

        Question: is no
   way that they can fail. (If 20 seconds a basic location node specifies good value? How should such a
   location
        value be chosen?

   The second optional parameter is recurse, which isn't supported by the underlying signalling protocol, can take two values,
   yes or no. This specifies whether the script server SHOULD detect this and report it should automatically
   attempt to place further call attempts to telephony addresses in
   redirection responses that were returned from the user at the
   time the script initial server.

   The third optional parameter is submitted.) Therefore, its XML representation does
   not have explicit output nodes; the <location> tag directly contains
   another node tag.

4.2 Location Lookup

   Locations ordering. This can also be looked up through external means, through have three
   possible values: parallel, sequential, and first-only.  This
   parameter specifies in what order the
   use locations of the lookup tag. The location to look up set
   should be tried. Parallel asks that they all be tried simultaneously;
   sequential asks that the result can first one be
   specified either as a url, or as another source. External URLs, are
   specified with tried first, the attribute url, second second,
   and should refer so forth, until one succeeds or the set is exhausted; first-only
   instructs the server to an external
   source which returns try only the application/url media type. Other sources
   are specified with first address in the attribute source. set, and
   then follow one of the outputs. The only source currently
   defined default value of this parameter
   is registration, which specifies parallel.

   Once a proxy action completes, if control is passed on to other
   actions, all the locations currently
   registered with which have been used are cleared from the server, using SIP REGISTER or H.323 RAS messages.
   A lookup tag MUST specify exactly one of url
   location set. That is, the location set is emptied if ordering was
   parallel or source.

   Lookup also has an optional attribute, timeout, which specifies sequential; the
   time first item in seconds the script set is willing removed from the
   set if ordering was first-only.

   For the proper actions when outputs are unspecified, see section 10.

6.2 Redirect

   Redirect causes the server to direct the calling party to attempt to
   place its call to wait for the lookup to be
   performed. Lookup has three outputs: success, notfound, and failure.
   Notfound currently specified set of locations. The
   syntax of this node is taken if specified in figure 12.

                                Node:  redirect
                             Outputs:  none
                          Parameters:  none

   Figure 12: Syntax of the lookup process succeeded but did not find
   any locations; failure is taken if redirect node

   Redirect immediately terminates execution of the lookup failed for CPL script, so this
   node has no outputs. It also takes no arguments.

        Question: should there be some reason,
   including that specified timeout was exceeded. If failure is not
   specified, way of distinguishing
        between "moved temporarily" and "moved permanently" (SIP
        301 and 302) redirections?

6.3 Reject

   Reject nodes cause the action corresponding server to notfound is taken; if notfound
   is not specified, reject the success output call attempt. Their
   syntax is taken, but given in figure 13.

                     Node:  reject
                  Outputs:  none
               Parameters:  status  Status code to return
                            reason  Reason phrase to return

   Figure 13: Syntax of the current
   location set is not modified. reject node

   This immediately terminates execution of the CPL script, so this node
   has no outputs.

   This node has two arguments: status and reason. The success output must be given.

   Clients SHOULD specify status argument
   is required, and can take one of the three outputs success, values busy, notfound, reject,
   and
   failure error. Servers which implement SIP MAY also allow a numeric
   argument corresponding to a SIP status in that order, so their script complies with the DTD given in
   Appendix A, 4xx, 5xx, or 6xx range,
   but servers scripts SHOULD accept NOT use 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 if they wish to be forwarded on to the currently
   specified set of locations. portable.

   The server chooses reason argument optionally allows the "best" response script to specify a reason
   for the call attempt, as defined by the protocol or its configuration
   rules. If the call attempt was successful, rejection. CPL execution terminates;
   otherwise, one of servers MAY ignore the three outputs busy, noanswer, or failure is
   taken.

        Note: future extension of reason, but ones that
   implement SIP SHOULD send them in the CPL to allow in-call or end-
        of-call SIP reason phrase.

7 Other actions will require success outputs
   In addition to be added as
        well.

        Question: What other outputs are needed? Redirect? More
        varieties of failure?

   If no locations are specified at the time signalling actions, the proxy command is
   executed, CPL defines several
   actions which do not affect the server SHOULD attempt to proxy telephony signalling protocol.

7.1 Mail

   The mail node causes the call server to its standard
   set notify a user of addresses for the user, or inform the caller that status of the caller
   CPL script through electronic mail. Its syntax is unavailable.

   Proxy has one argument: timeout, which specifies the time, given in
   seconds, figure 14.

          Node:  mail
       Outputs:  any node
    Parameters:  url       Mailto url to wait for which the call to mail should be completed or rejected, after
   which time sent

   Figure 14: Syntax of the call attempt is terminated mail node

   The mail node takes one argument: a mailto URL giving the address,
   and any additional desired parameters, of the noanswer branch is
   taken.

        Question: Do we want mail to be able sent.  The
   server sends the message containing the content to specify timeouts in the given url; it
   SHOULD also include other units, notably "number of rings"?

5.2 Redirect

   Redirect causes status information about the server to direct state of the calling party to attempt to
   place its
   call to and the currently specified set CPL script at the time of locations. This
   immediately terminates execution the notification.

   Mail nodes have only one output, since failure of e-mail delivery
   cannot reliably be known in real-time. Therefore, its XML
   representation does not have explicit output nodes: the CPL script, so this node has
   no outputs. This <mail> tag
   directly contains another node also has no arguments other tag.

        Using a full mailto URL rather than the standard
   Link ID target (see section 7).

5.3 Response

   Response just an e-mail address
        allows additional e-mail headers to be specified, such as
        <mail
        url="mailto:jones@example.com;subject=lookup%20failed" />.

7.2 Log

   The Log node causes the server to reject log information about 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
   non-volatile storage. Its syntax is required, and
   can take one specified in figure 15.

   Log takes two arguments, both optional: name, which specifies the
   name of the values busy, notfound, reject, log, and error.
   Servers comment, which implement SIP MAY also allow a numeric argument here
   corresponding to gives a SIP status in comment about the 4xx, 5xx, or 6xx range, but
   scripts
   information being logged. Servers SHOULD NOT use them if they wish to be portable.

   The reason argument optionally allows also include other
   information in the script to specify a reason
   for log, such as the rejection. CPL servers MAY ignore time of the reason, but ones logged event,
   information that
   implement SIP SHOULD send them in triggered 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.

        Question: Success to be logged, and redirection so forth. Logs
   are also responses.
        Should this specific to the owner of the script which log event.  If the name
   parameter is not given, the event is logged to a standard, server-
                Node:  log
             Outputs:  any node be called "failure" or "reject" instead?

6 Other Actions

   In addition
          Parameters:  name      Name of the log file to use
                       comment   Comment to be placed in log file

   Figure 15: Syntax of the signalling actions, log node

   defined logfile for the CPL defines several
   actions which do script owner.  This specification does not affect the telephony signalling protocol.

6.1 Notify

   The Notify node causes
   define how users may retrieve their logs from the server.

   A correctly operating CPL server SHOULD NOT ever allow the log event
   to notify fail. As such, log nodes have only one output, and their XML
   representation does not have explicit output nodes. A CPL <log> tag
   directly contains another node tag.

8 Subactions

   XML syntax defines a user tree. To allow more general call flow diagrams,
   and to allow script re-use and modularity, we define subactions.

   Two tags are defined for subactions: subaction definitions and
   subaction references. Their syntax is given in figure 16.

               Tag:  subaction
           Subtags:  any node
        Parameters:  id                Name of the status this subaction

       Pseudo-node:  sub
           Outputs:  none in XML tree
        Parameters:  ref               Name of subaction to execute

   Figure 16: Syntax of subactions and sub pseudo-nodes

   Subactions are defined through subaction tags. These tags are placed
   in the CPL script through some non-telephony means; for instance,
   sending electronic mail, or delivering an instant message. It takes
   two arguments: after any ancillary information (see section 9) but before
   any top-level tags. They take one argument: id, a required URL token indicating a
   script-chosen name for the means and address to
   contact (attribute url), and optionally subaction.

   Subactions are called from sub tags. The sub tag is a comment to "pseudo-node":
   it can be included used anyplace in a CPL action that message (attribute comment). The server sends a true node could be
   used. It takes one parameter, ref, the message
   containing name of the content subaction to be
   called. The sub tag contains no outputs of its own; control instead
   passes to the given url; it SHOULD also include other
   status information about subaction.

   References to subactions MUST refer to subactions defined before the state of
   current action. A sub tag MUST NOT refer to the call and action which it
   appears in, or to any action defined later in the CPL script script. Top-
   level actions cannot be called from sub tags, or through any other
   means. Script servers MUST verify 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 submitted
   that 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 sub node causes the server to log information about the call refers to
   non-volatile storage. It takes two arguments, both optional: name, any sub-action which specifies is not its proper
   predecessor.

        Allowing only back-references of subs forbids any sort of
        recursion. Recursion would introduce the name possibility of
        non-terminating or non-decidable CPL scripts, a possibility
        our requirements specifically excluded.

   Every sub MUST refer to a subaction ID defined within the log, and comment, which gives same CPL
   script. No external links are permitted.

        If any subsequent version ever defines external linkages,
        it will use a
   comment about different tag, perhaps XLink [12]. Ensuring
        termination in the presence of external links is a
        difficult problem.

9 Ancillary information being logged. Servers SHOULD also
   include other

   Only one sort of ancillary information is currently defined for CPL
   scripts:  timezone information. The syntax of timezone specifications
   is given in figure 17.

   Timezone specifications consist, conceptually, of three parts: the log, such as
   name of the timezone, as used by time of switches in the logged
   event, information that triggered script; the call to be logged, GMT
   offset and so
   forth. Logs are specific to the owner abbreviation of each offset used in 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 timezone; and failure. the
   instants at which each offset takes effect.

   The success branch is
   mandatory; if no failure branch name of the timezone is specified, given by the success branch name parameter to the
   timezone tag. This is
   taken. The outputs SHOULD be specified the name which time-switch tags can specify in
   their timezone parameter.

   The timezone tag must contain at least one instance of the order given.

7 Links
   XML syntax defines a tree. Because standard
   tag, which has mandatory arguments offset, giving the general structure zone's offset
   in minutes from UTC, and abbr, giving the standard abbreviation of
   the CPL timezone. If more than one time offset is instead intended to be in use in a directed acyclic graph, we provide the
   link structure to allow several node outputs to connect to timezone
   during a single
   node.

   Every XML year, the timezone tag contains another tag, daylight, which represents a node
   takes the same parameters as standard; and each of standard and
          Tag:  timezone
   Parameters:  name       Name of this timezone
      Outputs:  standard   Specification of standard time
                daylight   Specification of daylight (summer) time

          Tag:  standard
   Parameters:  offset     UTC offset during standard time
                abbr       abbreviation of this timezone
                year       year that this timezone transition occurs
                month      month that this timezone transition occurs
                date       day of month that this timezone transition occurs
                weekday    weekday that this timezone transition occurs
                timeofday  time of day that this timezone transition occurs

          Tag:  daylight
   Parameters:  ...        same as for standard

   Figure 17: Syntax of the timezone tag

   daylight has an optional argument id,
   which can be any XML id. (The id attribute is parameters, using the same syntax as time-switch tags
   (section 4.3, specifying a standard XML
   attribute, defined set of instants when the time zone rule
   takes effect, in section 3.3.1 the local time of the XML specification.) Any
   output which normally contains a node can, instead, other offset.

   Currently only two classes of offsets are supported. A timezone rule
   MAY contain several definitions each of standard and daylight if, for
   instance, different rules are in effect for different years.

   Figure 18 shows the timezone specification for most of the eastern
   United States.

   <timezone name="US/Eastern">
     <standard offset="-0500" abbr="EST" month="10" date="25-31"
           day="0" timeofday="0200" />
     <!-- 2 AM, last Sunday in October -->
     <daylight offset="-0400" abbr="EDT" month="4" date="1-7"
           day="0" timeofday="0200" />
     <!-- 2 AM, first Sunday in April -->
   </timezone>

   Figure 18: Timezone rule for the eastern United States.

   Figure 19 shows a link
   tag with a ref attribute simpler timezone rule for the state of Arizona,
   United States; most of Arizona does not observe daylight savings
   time.

   <timezone name="US/Arizona">
     <standard offset="-0700" abbr="MST" />
   </timezone>

   Figure 19: Timezone rule for Arizona, United States.

        Note: the syntax for specifying the ID first or last weekday
        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 month is very clumsy. A proper week parameter might be
        a different tag, perhaps XLINK [9]. good thing to add.

10 Default actions

   When the a CPL server initially processes action reaches an unspecified output, the script, action it MUST verify
   that no link refers to a node that takes
   is its parent in the tree; i.e.,
   it MUST verify that dependent on the directed graph created by current state of script execution. This section
   gives the tree and actions that should be taken in each case.

        no location or signalling actions performed, location set empty:
             Look up the
   links is acyclic.  If it is not, user's location through whatever mechanism the
             server SHOULD treat this error would use if no CPL script were in effect. Proxy,
             redirect, or send a rejection message, using whatever
             policy the same manner as any other syntax error server would use in the absence of a CPL script.

        no location or signalling actions performed, location set non-
             empty:  (This
   verification is algorithmically simply a matter of verifying that a
   depth-first search of can only happen for outgoing calls.) Proxy
             the directed graph contains call to the addresses in the location set.

        location actions performed, no back edges; see,
   for instance, [10], Lemma 23.10. It can typically be done
   simultaneously with signalling actions: Proxy or
             redirect the resolution of links.)

        If cycles were allowed call, whichever is the server's standard
             policy, to the addresses in the graph, it would introduce current location set. If
             the
        possibility location set is empty, return notfound rejection.

        noanswer output of non-terminating CPL scripts, proxy, no timeout given: (This is a possibility
        our requirements specifically excluded.

   CPL servers MAY use link IDs to identify nodes for other purposes,
   for instance special
             case.)  If the noanswer output of a proxy node is
             unspecified, and no timeout parameter was given to report errors or the
             proxy node, the call should be allowed to provide real-time debugging or
   flow information. Thus, scripts SHOULD provide IDs for every node ring for
   which they are interested in such information, even the
             maximum length of time allowed by the server (or the
             request, if no link
   connects the request specified a timeout).

        proxy action previously taken: Return whatever the "best"
             response is of all accumulated responses to that node.

8 the call to
             this point, according to the rules of the underlying
             signalling protocol.

11 Examples

8.1

        TODO: these examples don't illustrate many of the new
        features added to the CPL in draft -01. Add these.

11.1 Example: Call Redirect Unconditional

   The script in figure 3 20 is a simple script which redirects all calls
   to a single fixed location.

8.2 Example: Call Forward Busy/No Answer

   <?xml version="1.0" ?>
   <!DOCTYPE call cpl SYSTEM "cpl.dtd">

   <call>

   <cpl>
     <incoming>
       <location url="sip:smith@phone.example.com">
        <redirect />
       </location>
   </call>
     </incoming>
   </cpl>

   Figure 3: 20: Example Script: Call Redirect Unconditional

11.2 Example: Call Forward Busy/No Answer

   The script in figure 4 21 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 take the same node, action,
   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 subactions.

11.3 Example: Call Screening

   The script in figure 5 22 illustrates string address switches and call
   rejection, in the form of a call screening script. Note also that
   because the string-switch address-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 cpl SYSTEM "cpl.dtd">

   <call>
     <string-switch field="from">
       <string matches="anonymous@*">
          <response status="reject"
                    reason="I don't accept anonymous calls"

   <cpl>
     <subaction id="voicemail">
       <location url="sip:jones@voicemail.example.com" >
         <proxy />
       </location>
     </subaction>

     <incoming>
       <location url="sip:jones@jonespc.example.com">
          <proxy timeout="8s">
            <busy>
            </busy>
            <noanswer>
              <sub ref="voicemail" />
       </string>
     </string-switch>
   </call>
            </noanswer>
          </proxy>
       </location>
     </incoming>
   </cpl>

   Figure 5: 21: Example Script: Call Screening

8.4 Forward Busy/No Answer

   presumably be to contact the user.

11.4 Example: Time-of-day Routing

   Figure 6 23 illustrates time-based conditions.

8.5 conditions and timezones.

11.5 Example: Non-call Actions

   Figure 7 24 illustrates non-call actions; in particular, alerting a
   user by electronic mail if the lookup server failed. The primary
   reason for the Notify mail 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

11.6 Example: A Complex Example

   Finally, figure 8 25 is a complex example which shows the sort of
   <?xml version="1.0" ?>
   <!DOCTYPE cpl SYSTEM "cpl.dtd">

   <cpl>
     <incoming>
       <address-switch field="origin" subfield="user">
         <address is="anonymous">
            <reject status="reject"
                    reason="I don't accept anonymous calls" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 22: Example Script: Call Screening

   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

12 Security Considerations
   <?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 considerations

   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

13 Acknowledgments

   We would like to thank Tom La Porta and Jonathan Rosenberg for their
   contributions and suggestions.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl SYSTEM "cpl.dtd">

   <cpl>
     <timezone name="US/Eastern">
       <standard offset="-0500" abbr="EST" month="10" date="25-31"
             day="0" timeofday="0200" />
       <!-- 2 AM, last Sunday in October -->
       <daylight offset="-0400" abbr="EDT" month="4" date="1-7"
             day="0" timeofday="0200" />
       <!-- 2 AM, first Sunday in April -->
     </timezone>

     <incoming>
       <time-switch timezone="US/Eastern">
         <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>
     </incoming>
   </cpl>

   Figure 23: Example Script: Time-of-day Routing

   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], [13], a language for user filtering of
   <?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
   <?xml version="1.0" ?>
   <!DOCTYPE cpl SYSTEM "cpl.dtd">

   <cpl>
     <incoming>
       <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones"
               timeout="8">
         <success>
           <proxy />
         </success>
         <failure>
           <mail url="mailto:jones@example.com;subject=lookup%20failed" />
         </failure>
       </lookup>
     </incoming>
   </cpl>

   Figure 24: Example Script: Non-call Actions

   correctness of a CPL script, as many of the conditions described
   above are not expressible in DTD syntax.

   <?xml version="1.0" ?>
   <!DOCTYPE call cpl SYSTEM "cpl.dtd">

   <call>

   <cpl>
     <subaction id="voicemail">
       <location url="sip:jones@voicemail.example.com">
         <redirect />
       </location>
     </subaction>

     <incoming>
       <location url="sip:jones@phone.example.com">
         <proxy timeout="8s">
           <busy>
           <location url="sip:jones@voicemail.example.com" merge="clear">
             <redirect
             <sub ref="voicemail" />
           </location>
           </busy>
           <noanswer>
           <string-switch field="from">
             <string matches="boss@*example.com">
             <address-switch field="origin">
               <address contains="boss@example.com">
                 <location url="phone:+19175551212" merge="clear"> url="tel:+19175551212">
                   <proxy />
                 </location>
             </string>
               </address>
               <otherwise>
               <location url="sip:jones@voicemail.example.com" merge="clear">
                 <redirect
                 <sub ref="voicemail" />
               </location>
               </otherwise>
           </string-switch>
             </address-switch>
           </noanswer>
         </proxy>
       </location>
   </call>
     </incoming>
   </cpl>

   Figure 8: 25: Example Script: A Complex Example

   <?xml version="1.0" encoding="US-ASCII" ?>

   <!--
       Initial draft
       Draft DTD for CPL, corresponding to
       draft-ietf-iptel-cpl-00.
       draft-ietf-iptel-cpl-01.
   -->

   <!-- Define types Top-level tags of nodes the CPL -->
   <!-- Ancillary information -->
   <!ENTITY % Ancillary 'timezone' >

   <!-- Subactions -->
   <!ENTITY % Subactions 'subaction' >

   <!-- Top-level actions -->
   <!ENTITY % TopLevelAction 'incoming|outgoing' >

   <!-- Nodes. -->
   <!-- Switch nodes -->
   <!ENTITY % Switch 'string-switch|time-switch' 'address-switch|string-switch|time-switch|
                      priority-switch' >

   <!-- Location nodes -->
   <!ENTITY % Location 'location|lookup' 'location|lookup|remove-location' >

   <!-- Signalling action nodes -->
   <!ENTITY % SignallingAction 'proxy|redirect|response' 'proxy|redirect|reject' >

   <!-- Other actions -->
   <!ENTITY % OtherAction 'notify|log' 'mail|log' >

   <!-- Links to subactions -->
   <!ENTITY % Sub 'sub' >

   <!-- Nodes are one of the above four categories, or a link. subaction.
        This entity (macro) describes the contents of an output.
        Note that a node can be empty, implying default action. -->
   <!ENTITY % Node     '%Location;|%Switch;|%SignallingAction;|
                        %OtherAction;|link'     '(%Location;|%Switch;|%SignallingAction;|
                        %OtherAction;|%Sub;)?' >

   <!-- 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 can have an 'otherwise' node. output. -->
   <!ELEMENT otherwise ( %Node; ) >

   <!-- All switches can have a 'not-present' output. -->
   <!ELEMENT not-present ( %Node; ) >

   <!-- Address-switch makes choices based on addresses. -->
   <!ELEMENT address-switch ( (address|not-present)+, otherwise? ) >
   <!ATTLIST address-switch
      field         CDATA    #REQUIRED
      subfield      CDATA    #IMPLIED
   >
   <!ELEMENT address ( %Node; ) >
   <!ATTLIST address
      is            CDATA    #IMPLIED
      contains      CDATA    #IMPLIED
      subdomain-of  CDATA    #IMPLIED
   >

   <!-- String-switch makes choices based on strings. -->

   <!ELEMENT string-switch ( string+, (string|not-present)+, 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+, (time|not-present)+, otherwise? ) >
   <!ATTLIST time-switch
      %Link-ID;
      timezone      CDATA    #IMPLIED
   >

   <!ELEMENT time ( %Node; ) >
   <!ATTLIST time
      year          CDATA  #IMPLIED
      month         CDATA  #IMPLIED
      date          CDATA  #IMPLIED
      day           CDATA  #IMPLIED
      timeofday     CDATA  #IMPLIED
   >

   <!-- Priority-switch makes choices based on message priority. -->

   <!ELEMENT priority-switch ( (priority|not-present)+, otherwise? ) >

   <!ENTITY % PriorityVal '(emergency|urgent|normal|non-urgent)' >

   <!ELEMENT priority ( %Node; ) >
   <!ATTLIST priority
      less          %PriorityVal;  #IMPLIED
      greater       %PriorityVal;  #IMPLIED
      equal         CDATA          #IMPLIED
   >

   <!-- Locations: ways to specify the location a subsequent action
        (proxy, redirect) will attempt to contact. -->

   <!ENTITY % Merge  'merge (merge|clear) "merge"' Clear  'clear (yes|no) "no"' >

   <!ELEMENT location ( %Node; ) >
   <!ATTLIST location
      url           CDATA    #REQUIRED
      %Merge;
      %Link-ID;
   >

   <!-- Sources of location lookups that aren't URIs. -->
   <!ENTITY % Sources '(registration)'
      %Clear;
   >

   <!ELEMENT lookup ( success,notfound?,failure? ) >
   <!ATTLIST lookup
     url     CDATA     #IMPLIED
     source  %Sources;         CDATA     #REQUIRED
     timeout        CDATA     "30"
     use            CDATA     #IMPLIED
     timeout
     ignore         CDATA     #IMPLIED
     %Merge;
     %Link-ID;
     %Clear;
   >

   <!ELEMENT success  ( %Node; ) >
   <!ELEMENT notfound ( %Node; ) >
   <!ELEMENT failure ( %Node; ) >

   <!ELEMENT remove-location ( %Node; ) >
   <!ATTLIST remove-location
      param         CDATA    #IMPLIED
      value         CDATA    #IMPLIED
      location      CDATA    #IMPLIED
   >

   <!-- Signalling Actions: call-signalling actions the script can
        take. -->

   <!ELEMENT proxy ( busy?,noanswer?,failure? ) >
   <!ATTLIST proxy
      timeout       CDATA   #IMPLIED
      %Link-ID;    "20"
      recurse       (yes|no) "yes"
      ordering      CDATA    "parallel"
   >

   <!ELEMENT busy ( %Node; ) >
   <!ELEMENT noanswer ( %Node; ) >
   <!-- "failure" repeats from lookup above.  XXX? -->

   <!ELEMENT redirect EMPTY >
   <!ATTLIST redirect
      %Link-ID;
   >

   <!-- Statuses we can return -->

   <!ELEMENT response reject EMPTY >
   <!ATTLIST response reject
      status        CDATA    #REQUIRED
      reason        CDATA    #IMPLIED
      %Link-ID;
   >

   <!-- Non-signalling actions: actions that don't affect the call -->

   <!ELEMENT notify mail ( success,failure? %Node; ) >
   <!ATTLIST notify mail
      url           CDATA    #REQUIRED
      comment CDATA    #IMPLIED
      %Link-ID;
   >

   <!ELEMENT log ( success,failure? ) >
   <!ATTLIST log
      name          CDATA    #IMPLIED
      comment       CDATA    #IMPLIED
      %Link-ID;
   >

   <!-- Links Calls to other nodes. subactions. -->

   <!ELEMENT link sub EMPTY >
   <!ATTLIST link sub
      ref           IDREF    #REQUIRED
   >

   <!-- Ancillary data -->
   <!-- Timezone information -->
   <!ELEMENT timezone ( standard,daylight? ) >
   <!ATTLIST timezone
      name          CDATA    #REQUIRED
   >

   <!ENTITY % ZoneParams
      abbr          CDATA  #REQUIRED
      year          CDATA  #IMPLIED
      month         CDATA  #IMPLIED
      date          CDATA  #IMPLIED
      day           CDATA  #IMPLIED
      timeofday     CDATA  #IMPLIED' >

   <!ELEMENT standard EMPTY>
   <!ATTLIST standard
     %ZoneParams;
   >

   <!ELEMENT daylight EMPTY>
   <!ATTLIST daylight
     %ZoneParams;
   >

   <!-- Top-level action nodes -->
   <!ELEMENT subaction ( %Node; )>
   <!ATTLIST subaction
      id            ID       #REQUIRED
   >

   <!ELEMENT outgoing ( %Node; )>

   <!ELEMENT incoming ( %Node; )>

   <!-- The top-level element of the script. -->

   <!ELEMENT call cpl  ( %Node; timezone*,subaction*,outgoing?,incoming? ) >

B TODO

   See also the TODO notes in in motivation comments scattered
   throughout the document.

        o Investigate XML Schemas as an alternative to DTDs: they may be
          more flexible and/or powerful.

        o Determine proper system and public identifiers for the DTD.

        o Register application/cpl as a MIME media type.

C Changes from earlier versions

C.1 Changes from draft -00

   The changebars in the Postscript and PDF versions of this document
   indicate significant changes from this version.

        o Added high-level structure; script doesn't just start at a
          first action.

        o Added a section giving a high-level explanation of the
          location model.

        o Added informal syntax specifications for each tag so people
          don't have to try to understand a DTD to figure out the
          syntax.

        o Added subactions, replacing the old link tags. Links were far
          too reminiscent of gotos for everyone's taste.

        o Added ancillary information section, and timezone support.

        o Added not-present switch output.

        o Added address switches.

        o Made case-insensitive string matching locale-independent.

        o Added priority switch.

        o Deleted "Other switches" section. None seem to be needed.

        o Unified url and source parameters of lookup.

        o Added caller prefs to lookup.

        o Added location filtering.

        o Eliminated "clear" parameter of location setting. Instead,
          proxy "eats" locations it has used.

        o Added recurse and ordering parameters to proxy.

        o Added default value of timeout for proxy.

        o Renamed response to reject.

        o Changed notify to mail, and simplified it.

        o Simplified log, eliminating its failure output.

        o Added description of default actions at various times during
          script processing.

        o Updated examples for these changes.

        o Updated DTD to reflect new syntax.

D Authors' Addresses

   Jonathan Lennox
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: lennox@cs.columbia.edu

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: schulzrinne@cs.columbia.edu

C

E Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Internet Draft, Request for Comments (Proposed
   Standard) 2543, Internet Engineering Task Force, Jan. Mar. 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," "Packet based multimedia
   communication systems," Recommendation H.323, Telecommunication
   Standardization Sector of ITU, Geneva, Switzerland, May 1996. Feb. 1998.

   [3] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup
   language (XML) 1.0," W3C Recommendation 10-February-1998, REC-xml-19980210, World Wide
   Web Consortium (W3C), Feb. 1998.  Available at
   http://www.w3.org/TR/REC-xml.

   [4] J. Lennox and H. Schulzrinne, "Call processing language framework
   and requirements," Internet Draft, Internet Engineering Task Force,
   July 1999.  Work in progress.

   [5] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," BC Request for Comments (Best Current Practice) 2119, Internet
   Engineering Task Force, Mar. 1997.

   [5]

   [6] D. Raggett, A. L. Hors, and I. Jacobs, "HTML 4.0 specification,"
   W3C Recommendation revised on 24-Apr-1998, REC-html40-19980424, World Wide Web Consortium
   (W3C), Apr.  1998.  Available at http://www.w3.org/TR/REC-html40/.

   [6]

   [7] 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, Switzerland,
   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 M. Davis and M. Dust, "Unicode normalization forms," Unicode
   Technical Report 15, Unicode Consortium, Nov. 1999.  Revision 18.0.
   Available at http://www.unicode.org/unicode/reports/tr15/.

   [9] M. Davis, "Case mapping," Unicode Technical Report 21, Unicode
   Consortium, Nov. 1999.  Revision 3.0. Available at
   http://www.unicode.org/unicode/reports/tr21/.

   [10] D. Stenerson, "Internet calendaring and scheduling
   core object specification (icalendar)," Request for Comments
   (Proposed Standard) 2445, C. Fallside, "XML schema part 0: Primer," Working Draft WD-
   xmlschema-0-20000225, World Wide Web Consortium (W3C), Feb. 2000.
   Available at http://www.w3.org/TR/xmlschema-0/.

   [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
   callee capabilities," Internet Draft, Internet Engineering Task
   Force, Nov. 1998.

   [9] E. Maler and Mar. 2000.  Work in progress.

   [12] S. DeRose, E. Maler, D. Orchard, and B. Trafford, "XML linking
   language (XLink)," Working Draft 3-March-1998, WD-xlink-20000221, 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] Feb. 2000.  Available at
   http://www.w3.org/TR/xlink/.

   [13] T. Showalter, "Sieve: A mail filtering language," Internet
   Draft, Internet Engineering Task Force, Jan. Mar. 1999.  Work in progress.

   Full Copyright Statement

   Copyright (c) The Internet Society (1999). (2000). 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 of this document ........................    2
   2          Structure of CPL scripts ............................    2    3
   2.1        Abstract        High-level structure ..................................    2 ................................    3
   2.2        Abstract structure of a call processing action ......    3
   2.3        Location model ......................................    4
   2.4        XML Structure structure .......................................    4    5
   3          Script structure: overview ..........................    5
   4          Switches ............................................    4
   3.1    6
   4.1        Address switches ....................................    7
   4.1.1      Address switch mapping for SIP ......................    9
   4.1.2      Address switch mapping for H.323 ....................   10
   4.2        String Switch switches .....................................   11
   4.3        Time switches .......................................   12
   4.4        Priority switches ...................................   13
   5
   3.2        Time Switch .........................................    7
   3.3        Other Switches ......................................    8
   4          Locations ...........................................    8
   4.1        Basic          Location ......................................    8
   4.2 modifiers ..................................   14
   5.1        Explicit location ...................................   14
   5.2        Location Lookup lookup .....................................    9
   5   15
   5.3        Location filtering ..................................   17
   6          Signalling Actions actions ..................................    9
   5.1   18
   6.1        Proxy ...............................................    9
   5.2   18
   6.2        Redirect ............................................   10
   5.3        Response ............................................   10
   6   19
   6.3        Reject ..............................................   20
   7          Other Actions actions .......................................   11
   6.1        Notify ..............................................   11
   6.2   20
   7.1        Mail ................................................   21
   7.2        Log .................................................   11
   7          Links ...............................................   11   21
   8          Subactions ..........................................   22
   9          Ancillary information ...............................   23
   10         Default actions .....................................   25
   11         Examples ............................................   12
   8.1   26
   11.1       Example: Call Redirect Unconditional ................   12
   8.2   26
   11.2       Example: Call Forward Busy/No Answer ................   12
   8.3   26
   11.3       Example: Call Screening .............................   13
   8.4   26
   11.4       Example: Time-of-day Routing ........................   14
   8.5   27
   11.5       Example: Non-call Actions ...........................   14
   8.6   27
   11.6       Example: A Complex Example ..........................   14
   9   27
   12         Security Considerations considerations .............................   14
   10   28
   13         Acknowledgments .....................................   15   28
   A          The XML DTD for CPL .................................   16   29
   B          TODO ................................................   36
   C          Changes from earlier versions .......................   36
   C.1        Changes from draft -00 ..............................   36
   D          Authors' Addresses ..................................   20
   C   38
   E          Bibliography ........................................   21   38