Internet Engineering Task Force                                 IPTEL WG
Internet Draft                                        Lennox/Schulzrinne
draft-ietf-iptel-cpl-05.txt
draft-ietf-iptel-cpl-06.txt                          Columbia University
November 21, 2001
January 15, 2002
Expires: May, July, 2002

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

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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   The Call Processing Language (CPL) 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.

                           Table of Contents

   1          Introduction

   The ........................................    4
   1.1        Conventions of This Document ........................    4
   2          Structure of CPL Scripts ............................    4
   2.1        High-level Structure ................................    5
   2.2        Abstract Structure of a Call Processing Action ......    5
   2.3        Location Model ......................................    6
   2.4        XML Structure .......................................    6
   3          Document Information ................................    7
   3.1        CPL Document Identifiers for XML ....................    7
   3.2        MIME Registration ...................................    8
   4          Script Structure: Overview ..........................    9
   5          Switches ............................................   10
   5.1        Address Switches ....................................   11
   5.1.1      Usage of "address-switch" with SIP ..................   13
   5.2        String Switches .....................................   14
   5.2.1      Usage of "string-switch" with SIP ...................   15
   5.3        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 Switches ...................................   15
   5.3.1      Usage of "language-switch" with both SIP [1] .................   16
   5.4        Time Switches .......................................   16
   5.4.1      iCalendar differences and H.323 [2].

   The CPL is powerful enough to describe a large number implementation issues .....   22
   5.5        Priority Switches ...................................   23
   5.5.1      Usage 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 loops or 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 "priority-switch" with SIP .................   24
   6          Location Modifiers ..................................   24
   6.1        Explicit Location ...................................   25
   6.1.1      Usage 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 "location" with SIP ........................   26
   6.2        Location Lookup .....................................   26
   6.2.1      Usage of the "lookup" with SIP ..........................   28
   6.3        Location Removal ....................................   28
   6.3.1      Usage of "remove-location" with SIP .................   29
   7          Signalling Operations ...............................   29
   7.1        Proxy ...............................................   29
   7.1.1      Usage of "proxy" with SIP ...........................   32
   7.2        Redirect ............................................   32
   7.2.1      Usage of "redirect" with SIP ........................   32
   7.3        Reject ..............................................   33
   7.3.1      Usage of "reject" with SIP ..........................   33
   8          Non-signalling Operations ...........................   34
   8.1        Mail ................................................   34
   8.1.1      Suggested Content of Mailed Information .............   35
   8.2        Log .................................................   35
   9          Subactions ..........................................   36
   10         Ancillary Information ...............................   37
   11         Default Behavior ....................................   38
   12         CPL are expected to take place both in
   Internet telephony servers Extensions ......................................   39
   13         Examples ............................................   40
   13.1       Example: Call Redirect Unconditional ................   40
   13.2       Example: Call Forward Busy/No Answer ................   40
   13.3       Example: Call Forward: Redirect and in advanced clients; both can usefully
   process Default .........   40
   13.4       Example: Call Screening .............................   42
   13.5       Example: Priority and direct users' calls. This document primarily addresses
   the usage in servers. 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 RFC 2824, "Call Processing Language Framework and Requirements"
   [4].

1.1 Conventions of This Document

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and
   indicate requirement levels Routing ..............   42
   13.6       Example: Outgoing Call Screening ....................   42
   13.7       Example: Time-of-day Routing ........................   43
   13.8       Example: Location Filtering .........................   44
   13.9       Example: Non-signalling Operations ..................   44
   13.10      Example: Hypothetical Extensions ....................   45
   13.11      Example: A Complex Example ..........................   45
   14         Security Considerations .............................   48
   15         IANA Considerations .................................   49
   16         Acknowledgments .....................................   49
   A          An Algorithm for compliant Resolving Time Switches ............   49
   B          Suggested Usage of CPL implementations.

        Some paragraphs are indented, like this; they give
        motivations with H.323 ...................   51
   B.1        Usage of design choices, or questions for future
        discussion in the development "address-switch" with H.323 ................   51
   B.2        Usage of the CPL, and are not
        essential to the specification "string-switch" with H.323 .................   53
   B.3        Usage of the language.

2 Structure "language-switch" with H.323 ...............   53
   B.4        Usage of CPL Scripts

2.1 High-level Structure

   A CPL script consists "priority-switch" with H.323 ...............   53
   B.5        Usage of two types "location" with H.323 ......................   53
   B.6        Usage of information: ancillary
   information about the script, and call processing actions.

   A call processing action is a structured tree that describes the
   operations and decisions a telephony signalling server performs on a
   call set-up event. There are two types of call processing actions:
   top-level actions and subactions. 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 "lookup" with H.323 ........................   53
   B.7        Usage of the script. Subactions are actions which can be
   called from other actions. "remove-location" with H.323 ...............   54
   C          The XML DTD for CPL forbids subactions .................................   54
   D          Changes from being
   called recursively:  see Section 9.

   Ancillary information is information which Earlier Versions .......................   60
   D.1        Changes from Draft -05 ..............................   60
   D.2        Changes from Draft -04 ..............................   61
   D.3        Changes from Draft -03 ..............................   62
   D.4        Changes from Draft -02 ..............................   62
   D.5        Changes from Draft -01 ..............................   63
   D.6        Changes from Draft -00 ..............................   65
   E          Authors' Addresses ..................................   66
   F          Bibliography ........................................   66

1 Introduction

   The Call Processing Language (CPL) is necessary for a server language that can be used to correctly process a script, but which does not directly
   describe and control Internet telephony services. It is not tied to
   any operations particular signalling architecture or decisions. Currently, no ancillary information is
   defined, but the section protocol; it is reserved for use by extensions.

2.2 Abstract Structure of a Call Processing Action

   Abstractly, a call processing action anticipated
   that it will be used with both SIP [1] and H.323 [2].

   The CPL is described by powerful enough to describe a collection large number of
   nodes, which describe operations that can be performed or decisions
   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 decision or action.

   For a graphical representation of a CPL action, see Figure 1.  Nodes
   and outputs can be thought of informally as boxes services and arrows; the CPL
   features, but it is designed limited in power so that actions it can be conveniently edited graphically
   using this representation. Nodes are arranged run safely in a tree, starting at
   a single root node; outputs of nodes are connected
   Internet telephony servers. The intention is to additional
   nodes. When an action make it impossible
   for users to do anything more complex (and dangerous) than describing
   Internet telephony services. The language is run, the action not Turing-complete, and
   provides no way to write loops or decision described recursion.

   The CPL is also designed to be easily created and edited by the
   action's top-level node graphical
   tools.  It is performed; based on the result XML [3], so parsing it is easy and many
   parsers for it are publicly available. The structure of that
   node, 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 follows one of the node's outputs, and can easily confirm scripts' validity at the
   subsequent node it points time they
   are delivered to is performed; this process continues
   until it, rather that discovering them while a node with no specified outputs call is reached.  Because the graph
   is acyclic, this will occur after a bounded and predictable number
   being processed.

   Implementations of
   nodes the CPL are visited.

   If an output expected to a node take place both in
   Internet telephony servers and in advanced clients; both can usefully
   process and direct users' calls. This document primarily addresses
   the usage in servers. A mechanism will be needed to transport scripts
   between clients and servers; this document does not point to another node, it indicates
   that the CPL server should perform describe such a node- or protocol-specific
   action. Some nodes have specific default behavior associated with
   them;
   mechanism, but related documents will.

   The framework and requirements for others, the default behavior is implicit CPL architecture are described
   in RFC 2824, "Call Processing Language Framework and Requirements"
   [4].

1.1 Conventions of This Document

   In this document, the underlying
   signalling protocol, or can key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be configured by interpreted as described in RFC 2119 [5] and
   indicate requirement levels for compliant CPL implementations.

        Some paragraphs are indented, like this; they give
        motivations of design choices, or questions for future
        discussion in the administrator development of the
   server. For further details 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
   operations and decisions a telephony signalling server performs on this, see Section 11.

          _________________      ___________________      ________  busy
         | Address-switch  |    | location          |    | proxy  |--------\
Call --->|  field: origin  |  ->|   url: sip:jones@ |--->|timeout:| timeout|
         |  subfield: host | /  |     example.com   |    |  10s   |--------|
         |-----------------|/   |___________________|    |        | failure|
         | subdomain-of:   |                             |________|--------|
         |   example.com   |                                               |
         |-----------------|  _____________________________________________/
         | otherwise       | /..........................................
         |                 |\|. Voicemail                              .
         |_________________| \.  ____________________                  .
                              ->| location           |     __________  .
                              . |   url: sip:jones@  |	  | redirect | .
                              . |        voicemail.  |--->|          | .
                              . |        example.com |	  |__________| .
                              . |____________________|                 .
                              ..........................................

   Figure 1: Sample CPL Action: Graphical Version

2.3 Location Model

   For flexibility, one piece a
   call set-up event. There are two types of information necessary for call processing actions:
   top-level actions and subactions. Top-level actions are actions that
   are triggered by signalling events that arrive at the function
   of a CPL is not given as node parameters: server. Two
   top-level action names are defined: "incoming", the set of locations to
   which action performed
   when a call arrives whose destination is to be directed. Instead, this set of locations is
   stored as an implicit global variable throughout the execution owner of a
   processing action (and its subactions). This allows locations to be
   retrieved from external sources, filtered, and so forth, without
   requiring general language support for such operations (which could
   harm the simplicity script; and tractability of understanding the language).
   The specific operations which add, retrieve, or filter location sets
   are given in Section 6.

   For
   "outgoing", the incoming top-level action performed when a call processing action, the location set arrives whose originator
   is initialized to the empty set. For owner of the outgoing action, it script. Subactions are actions which can be
   called from other actions. The CPL forbids subactions from being
   called recursively:  see Section 9.

   Ancillary information is
   initialized information which is necessary for a server
   to correctly process a script, but which does not directly describe
   any operations or decisions. Currently, no ancillary information is
   defined, but the destination address of the call.

2.4 XML Structure
   Syntactically, CPL scripts are represented by XML documents. XML section is
   thoroughly specified reserved for use by [3], and implementors extensions.

2.2 Abstract Structure of this specification
   should be familiar with that document, but as a brief overview, XML
   consists of Call Processing Action

   Abstractly, a hierarchical structure call processing action is described by a collection of tags; each tag
   nodes, which describe operations that can be performed or decisions
   which can be made. A node may have a
   number of attributes. It is visually and structurally very similar to
   HTML [6], as both languages are simplifications several parameters, which specify
   the precise behavior of the earlier and
   larger standard SGML [7].

   See Figure 2 for node; they usually also have outputs,
   which depend on the XML document corresponding to result of the decision or action.

   For a graphical representation of the a CPL script in action, see Figure 1. Both nodes  Nodes
   and outputs
   in can be thought of informally as boxes and arrows; the CPL
   is designed so that actions can be conveniently edited graphically
   using this representation. Nodes are represented by XML tags; parameters arranged in a tree, starting at
   a single root node; outputs of nodes are represented connected to additional
   nodes. When an action is run, the action or decision described by
   XML tag attributes. Typically, node tags contain output tags, and
   vice-versa (with a few exceptions: see Sections 6.1, 6.3, 8.1, and
   8.2).

   The connection between the output of a node and another
   action's top-level node is
   represented by enclosing the tag representing performed; based on the pointed-to node
   inside result of that
   node, the tag for server follows one of the outer node's output. Convergence (several
   outputs pointing outputs, and the
   subsequent node it points to a single node) is represented by subactions,
   discussed further in Section 9.

   The higher-level structure of performed; this process continues
   until a CPL script node with no specified outputs is represented by tags
   corresponding to each piece of ancillary information, subactions, and
   top-level actions, in order. This higher-level information reached.  Because the graph
   is all
   enclosed in acyclic, this will occur after a special tag "cpl", the outermost tag bounded and predictable number of
   nodes are visited.

   If an output to a node does not point to another node, it indicates
   that the XML
   document.

   A complete Document Type Declaration CPL server should perform a node- or protocol-specific
   action. Some nodes have specific default behavior associated with
   them; for others, the CPL default behavior is provided implicit in
   Appendix C. The remainder of the main sections of this document
   describe underlying
   signalling protocol, or can be configured by the semantics administrator of the CPL, while giving its syntax
   informally.
   server. For the formal syntax, please further details on this, see the appendix.

3 Document Information

   This section gives information describing how CPL scripts are
   identified.

3.1 CPL Document Identifiers for XML

   A CPL script list which appears as a top-level XML document is
   identified with the formal public identifier "-//IETF//DTD RFCxxxx
   CPL 1.0//EN".

   A CPL embedded as a fragment within another XML document is
   identified with the XML namespace identifier "http://www.rfc-
   editor.org/rfc/rfcxxxx.txt".

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "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 timeout="10">
               <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> Section 11.

          _________________      ___________________      ________  busy
         | Address-switch  |    | location          |    | proxy  |--------\
Call --->|  field: origin  |  ->|   url: sip:jones@ |--->|timeout:| timeout|
         |  subfield: host | /  |     example.com   |    |  10s   |--------|
         |-----------------|/   |___________________|    |        | failure|
         | subdomain-of:   |                             |________|--------|
         |   example.com   |                                               |
         |-----------------|  _____________________________________________/
         | otherwise       | /..........................................
         |                 |\|. Voicemail                              .
         |_________________| \.  ____________________                  .
                              ->| location           |     __________  .
                              . |   url: sip:jones@  |	  | redirect | .
                              . |        voicemail.  |--->|          | .
                              . |        example.com |	  |__________| .
                              . |____________________|                 .
                              ..........................................

   Figure 2: 1: Sample CPL Script: XML Action: Graphical Version

        [Note to RFC editor: please replace "xxxx" above with the
        number

2.3 Location Model

   For flexibility, one piece of this RFC.]

        Note that information necessary for the URIs specifying XML namespaces are only
        globally unique names; they do not have to reference any
        particular actual object.  The URI function
   of a canonical source of
        this specification meets CPL is not given as node parameters: the requirement set of being globally
        unique, and locations to
   which a call is also useful to document the format.

3.2 MIME Registration

   As an XML type, CPL's MIME registration conforms with "XML Media
   Types," RFC 3023 [8].

        MIME media type name: application

        MIME subtype name: cpl+xml

        Mandatory parameters: none

        Optional parameters: charset
             As for application/xml in RFC 3023.

        Encoding considerations: As for application/xml in RFC 3023.

        Security considerations: See Section 14, and Section 10 of RFC
             3023.

        Interoperability considerations: Different CPL servers may use
             incompatible address types. However, all potential
             interoperability issues should be resolvable at the time a
             script is uploaded; there should be no interoperability
             issues which cannot be detected until runtime.

        Published specification: This document.

        Applications which use this media type: None publicly released
             at directed. Instead, this time, as far set of locations is
   stored as an implicit global variable throughout the authors are aware.

        Additional information:

             Magic number: None

             File extension: .cpl or .xml

             Macintosh file type code: "TEXT"

        Person execution of a
   processing action (and its subactions). This allows locations to be
   retrieved from external sources, filtered, and e-mail address so forth, without
   requiring general language support for further information:
             Jonathan Lennox <lennox@cs.columbia.edu>
             Henning Schulzrinne <hgs@cs.columbia.edu>

        Intended usage: COMMON

        Author/Change Controller: The IETF.

4 Script Structure: Overview

   As mentioned, a CPL script consists of ancillary information,
   subactions, such operations (which could
   harm the simplicity and top-level actions. The full syntax tractability of understanding the "cpl" node
   is language).
   The specific operations which add, retrieve, or filter location sets
   are given in Figure 3.

           Tag:  "cpl"
    Parameters:  None
      Sub-tags:  "ancillary"  See Section 10
                 "subaction"  See Section 9
                 "outgoing"   Top-level actions to take on this user's
                              outgoing calls
                 "incoming"   Top-level actions to take on this user's
                              incoming calls

   Figure 3: Syntax of 6.

   For the incoming top-level "cpl" tag

   Call call processing actions, both top-level actions and sub-actions,
   consist of a tree of nodes and outputs. Nodes and outputs are both
   described by XML tags. There are four categories of CPL nodes:
   switches, which represent choices a CPL script can make; location
   modifiers, which add or remove locations from action, the location set;
   signalling operations, which cause signalling events in set
   is initialized to the
   underlying protocol; and non-signalling operations, which trigger
   behavior which does not effect empty set. For the underlying protocol.

5 Switches

   Switches represent choices a CPL script can make, based on either
   attributes of outgoing action, it is
   initialized to the original call request or items independent destination address of the call.

   All switches

2.4 XML Structure
   Syntactically, CPL scripts are arranged represented by XML documents. XML is
   thoroughly specified by [3], and implementors of this specification
   should be familiar with that document, but as a list brief overview, XML
   consists of conditions that a hierarchical structure of tags; each tag can match have a
   variable. Each condition corresponds
   number of attributes. It is visually and structurally very similar to a node output;
   HTML [6], as both languages are simplifications of the output
   points to earlier and
   larger standard SGML [7].

   See Figure 2 for the next node XML document corresponding to execute if the condition was true.  The
   conditions are tried in graphical
   representation of the order they are presented CPL script in Figure 1. Both nodes and outputs
   in the script;
   the output corresponding to the first node to match is taken.

   There CPL are two special switch outputs that apply to every switch type.
   The represented by XML tags; parameters are represented by
   XML tag attributes. Typically, node tags contain output "not-present", which MAY occur anywhere in tags, and
   vice-versa (with a few exceptions: see Sections 6.1, 6.3, 8.1, and
   8.2).

   The connection between the list output of
   outputs, a node and another node is true if
   represented by enclosing the variable tag representing the switch was to match was not
   present in pointed-to node
   inside the original call setup request. (In this document, this
   is sometimes described by saying that tag for the information outer node's output. Convergence (several
   outputs pointing to a single node) is "absent".) represented by subactions,
   discussed further in Section 9.

   The output "otherwise", which MUST be the last output specified if it higher-level structure of a CPL script is present, matches if no other condition matched.

   If no condition matches represented by tags
   corresponding to each piece of ancillary information, subactions, and no "otherwise" output was present
   top-level actions, in order. This higher-level information is all
   enclosed in a special tag "cpl", the
   script, outermost tag of the default script behavior is taken. See Section 11 XML
   document.

   A complete Document Type Declaration for more
   information on this.

5.1 Address Switches
   Address switches allow a the CPL script to make decisions based on one is provided in
   Appendix C. The remainder of the addresses present in main sections of this document
   describe the original call request. They semantics of the CPL, while giving its syntax
   informally. For the formal syntax, please see the appendix.

3 Document Information

   This section gives information describing how CPL scripts are
   summarized in Figure 4.

         Node:  "address-switch"
      Outputs:  "address"         Specific addresses to match
   Parameters:  "field"           "origin", "destination", or "original-destination"
                "subfield"        "address-type", "user", "host", "port", "tel", or "display"
                                  (also: "password" and "alias-type")

       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 the "address-switch" node

   Address switches have two node parameters: "field", and "subfield".
   The mandatory "field" parameter allows the
   identified.

3.1 CPL Document Identifiers for XML

   A CPL script to specify list which
   address appears as a top-level XML document is to be considered for
   identified with the switch: either formal public identifier "-//IETF//DTD RFCxxxx
   CPL 1.0//EN".

   A CPL embedded as a fragment within another XML document is
   identified with the call's origin
   address (field "origin"), its current destination address (field
   "destination"), or its original destination (field "original-
   destination"), XML namespace identifier "http://www.rfc-
   editor.org/rfc/rfcxxxx.txt".

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "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 timeout="10">
               <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

        [Note to RFC editor: please replace "xxxx" above with the destination
        number of this RFC.]

        Note that the call had before URIs specifying XML namespaces are only
        globally unique names; they do not have to reference any earlier
   forwarding was invoked. Servers MAY define additional field values.
        particular actual object.  The optional "subfield" specifies what part URI of the address a canonical source of
        this specification meets the requirement of being globally
        unique, and is also useful to be
   considered. The possible subfield values are: "address-type", "user",
   "host", "port", "tel", and "display".  Additional subfield values MAY
   be defined document the format.

3.2 MIME Registration

   As an XML type, CPL's MIME registration conforms with "XML Media
   Types," RFC 3023 [8].

        MIME media type name: application

        MIME subtype name: cpl+xml

        Mandatory parameters: none

        Optional parameters: charset
             As for protocol-specific values. (The subfield "password" is
   defined application/xml in RFC 3023.

        Encoding considerations: As for SIP application/xml in RFC 3023.

        Security considerations: See Section 5.1.1; 14, and Section 10 of RFC
             3023.

        Interoperability considerations: Different CPL servers may use
             incompatible address types. However, all potential
             interoperability issues should be resolvable at the subfield "alias-type" time a
             script is
   defined for H.323 in Appendix B.1.)  If uploaded; there should be no subfield is specified, the
   "entire" address is matched; the precise meaning of interoperability
             issues which cannot be detected until runtime.

        Published specification: This document.

        Applications which use this is defined
   for each underlying signalling protocol. Servers MAY define
   additional subfield values.

   The subfields are defined media type: None publicly released
             at this time, as far as follows:

        address-type This indicates the type of the underlying address;
             i.e., the URI scheme, if the address can be represented by
             a URI. The types specifically discussed by this document authors are "sip", "tel", aware.

        Additional information:

             Magic number: None

             File extension: .cpl or .xml

             Macintosh file type code: "TEXT"

        Person and "h323". The e-mail address type is not
             case-sensitive. It has a value for all defined address
             types.

        user This subfield further information:
             Jonathan Lennox <lennox@cs.columbia.edu>
             Henning Schulzrinne <hgs@cs.columbia.edu>

        Intended usage: COMMON

        Author/Change Controller: The IETF.

4 Script Structure: Overview

   As mentioned, a CPL script consists of the address indicates, for e-mail style
             addresses, the user part ancillary information,
   subactions, and top-level actions. The full syntax of the address. For telephone
             number style address, it includes the subscriber number.
             This subfield "cpl" node
   is case-sensitive; it may be absent.

        host This subfield given in Figure 3.

           Tag:  "cpl"
    Parameters:  None
      Sub-tags:  "ancillary"  See Section 10
                 "subaction"  See Section 9
                 "outgoing"   Top-level actions to take on this user's
                              outgoing calls
                 "incoming"   Top-level actions to take on this user's
                              incoming calls

   Figure 3: Syntax of the address indicates the Internet host
             name top-level "cpl" tag

   Call processing actions, both top-level actions and sub-actions,
   consist of a tree of nodes and outputs. Nodes and outputs are both
   described by XML tags. There are four categories of CPL nodes:
   switches, which represent choices a CPL script can make; location
   modifiers, which add or IP address corresponding to remove locations from the address, location set;
   signalling operations, which cause signalling events in host
             name, IPv4, or IPv6 [9] textual representation format.
             Host names are compared as strings. IP addresses are
             compared numerically.  (In particular, the presence
   underlying protocol; and non-signalling operations, which trigger
   behavior which does not effect the underlying protocol.

5 Switches

   Switches represent choices a CPL script can make, based on either
   attributes of the original call request or
             location items independent of an IPv6 :: omitted-zero-bits block is not
             significant for matching purposes.)  Host names the
   call.

   All switches are never
             equal arranged as a list of conditions that can match a
   variable. Each condition corresponds to IP addresses -- no DNS resolution is performed.
             IPv4 addresses are never equal a node output; the output
   points to IPv6 addresses, even if the IPv6 address is a v4-in-v6 embedding.

             For host names only, subdomain matching is supported with next node to execute if the "subdomain-of" match operator. condition was true.  The "subdomain-of"
             operator ignores leading dots
   conditions are tried in the hostname or order they are presented in the script;
   the output corresponding to the first node to match
             pattern, if any.  This subfield is not case sensitive, and
             may be absent.

        port This subfield indicates taken.

   There are two special switch outputs that apply to every switch type.
   The output "not-present", which MAY occur anywhere in the TCP or UDP port number list of
   outputs, is true if the
             address, numerically variable the switch was to match was not
   present in decimal format. It the original call setup request. (In this document, this
   is not case
             sensitive, as it sometimes described by saying that the information is "absent".)
   The output "otherwise", which MUST only contain decimal digits. Leading
             zeros are ignored. This subfield may be absent; however,
             for address types with default ports, an absent port
             matches the default port number.

        tel This subfield indicates a telephone subscriber number, last output specified if
             the address contains such a number. It it
   is not case
             sensitive (the telephone numbers may contain the symbols
             `A' `B' `C' and `D'), present, matches if no other condition matched.

   If no condition matches and may be absent. It may be matched
             using the "subdomain-of" match operator.  Punctuation and
             separator characters in telephone numbers are discarded.

        display This subfield indicates a "display name" or user-visible
             name corresponding to an address. It is a Unicode string,
             and is matched using the case-insensitive algorithm
             described no "otherwise" output was present in Section 5.2. The "contains" operator may be
             applied to it. It may be absent.

   For any completely unknown subfield, the server MAY reject
   script, the default script
   at the time it behavior is submitted with taken. See Section 11 for more
   information on this.

   Switches MAY contain no outputs. They MAY contain only an indication of the problem; if "otherwise"
   output.

        Such switches are not particularly useful, but might be
        created by tools which automatically generate CPL scripts.

5.1 Address Switches

   Address switches allow a CPL script with an unknown subfield is executed, the server MUST consider
   the "not-present" output to be the valid one.

   The "address" output tag may take exactly make decisions based on one of three possible
   parameters, indicating the kind of matching allowed.

        is An output with this match operator is followed if
   the
             subfield being matched addresses present in the original call request. They are
   summarized in Figure 4.

         Node:  "address-switch" exactly
             matches the argument of the operator. It may be used for
             any subfield, or for the entire address if no subfield was
             specified.

        subdomain-of This
      Outputs:  "address"         Specific addresses to match operator applies only for the subfields
             "host"
   Parameters:  "field"           "origin", "destination",
                                  or "original-destination"
                "subfield"        "address-type", "user", "host", "port",
                                  "tel", or "display"
                                  (also: "password" and "tel". In the former case, it matches if the
             hostname being matched is a subdomain of the domain given
             in the argument of the "alias-type")

       Output:  "address"
   Parameters:  "is"              exact match operator; thus, subdomain-
             of="example.com" would
                "contains"        substring 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 (for "display" only)
                "subdomain-of"    sub-domain match exactly. In the case of the (for "host", "tel" subfield, the
             output matches if the telephone number being matched has a
             prefix that matches the argument of the match operator;
             subdomain-of="1212555" would match the telephone number "1
             212 555 1212."

        contains This match operator applies only for the subfield
             "display". The output matches if the display name being
             matched contains the argument only)

   Figure 4: Syntax of the match as a substring.

5.1.1 Usage of "address-switch" with SIP

   For SIP, node

   Address switches have two node parameters: "field", and "subfield".
   The mandatory "field" parameter allows the "origin" address corresponds script to the specify which
   address in the
   "From" header; "destination" corresponds is to be considered for the "Request-URI"; and
   "original-destination" corresponds to switch: either the "To" header.

   The "display" subfield of an call's origin
   address is the display-name part of (field "origin"), its current destination address (field
   "destination"), or its original destination (field "original-
   destination"), the
   address, if it is present. Because of SIP's syntax, destination the "destination"
   address call had before any earlier
   forwarding was invoked. Servers MAY define additional field will never have a "display" subfield. values.

   The "address-type" subfield optional "subfield" specifies what part of an address is the URI scheme of that
   address. Other address fields depend on that "address-type".

   For sip URLs, the is to be
   considered. The possible subfield values are: "address-type", "user",
   "host", "port", "tel", and "port" subfields correspond to
   the "user," "host," and "port" elements of the URI syntax. The "tel" "display".  Additional subfield is defined to values MAY
   be the "user" part of the URI, with visual
   separators stripped, if and only if the "user=phone" parameter is
   given to the URI. An additional subfield, defined for protocol-specific values. (The subfield "password" is
   defined to
   correspond to for SIP in Section 5.1.1; the "password" element of subfield "alias-type" is
   defined for H.323 in Appendix B.1.)  If no subfield is specified, the SIP URI, and
   "entire" address is case-
   sensitive. However, use matched; the precise meaning of this field is NOT RECOMMENDED defined
   for general
   security reasons.

   For tel URLs, the "tel" and "user" each underlying signalling protocol. Servers MAY define
   additional subfield values.

   The subfields are defined as follows:

        address-type This indicates the subscriber name;
   in type of the former case, visual separators are stripped. The "host" and
   "port" subfields are both not present.

   For h323 URLs, subfields MAY be set according to underlying address;
             i.e., the scheme described
   in Appendix B.

   For other URI schemes, only scheme, if the "address-type" subfield is defined address can be represented by
             a URI. The types specifically discussed by this specification; servers MAY set other pre-defined subfields, or
   MAY support additional subfields.

   If no subfield document
             are "sip", "tel", and "h323". The address type is specified not
             case-sensitive. It has a value for addresses in SIP messages, all defined address
             types.

        user This subfield of the string
   matched is address indicates, for e-mail style
             addresses, the URI user part of the address. For "is" matches, standard
   SIP URI matching rules are used; for "contains" matches, telephone
             number style address, it includes the URI is
   used verbatim.

5.2 String Switches

   String switches allow a CPL script subscriber number.
             This subfield is case-sensitive; it may be absent.

        host This subfield of the address indicates the Internet host
             name or IP address corresponding to make decisions based on free-
   form strings present the address, in a call request. They host
             name, IPv4, or IPv6 [9] textual representation format.
             Host names are summarized in Figure
   5.

         Node:  "string-switch"
      Outputs:  "string"         Specific string to match
   Parameters:  "field"          "subject", "organization", "user-agent", compared as strings. IP addresses are
             compared numerically.  (In particular, the presence or "display"

       Output:  "string"
   Parameters:  "is"             exact match
                "contains"       substring match

   Figure 5: Syntax
             location of the "string-switch" node

   String switches have one node parameter: "field". The mandatory
   "field" parameter specifies which string an IPv6 :: omitted-zero-bits block is not
             significant for matching purposes.)  Host names are never
             equal to be matched.

   String switches IP addresses -- no DNS resolution is performed.
             IPv4 addresses are dependent on never equal to IPv6 addresses, even if
             the call signalling protocol being
   used.

   Five fields are defined, listed below. The value of each of these
   fields, except as specified, IPv6 address is a free-form Unicode string v4-in-v6 embedding.

             For host names only, subdomain matching is supported with no
   other structure defined.

        "subject" The subject of
             the call.

        "organization" "subdomain-of" match operator. The organization of the originator of "subdomain-of"
             operator ignores leading dots in the call.

        "user-agent" The name of hostname or match
             pattern, if any. This subfield is not case sensitive, and
             may be absent.

        port This subfield indicates the program TCP or device with which UDP port number of the
             call request was made.

        "display" Free-form text associated
             address, numerically in decimal format. It is not case
             sensitive, as it MUST only contain decimal digits. Leading
             zeros are ignored. This subfield may be absent; however,
             for address types with default ports, an absent port
             matches the call, intended to
             be displayed to default port number.

        tel This subfield indicates a telephone subscriber number, if
             the recipient, with no other semantics
             defined by address contains such a number. It is not case
             sensitive (the telephone numbers may contain the signalling protocol.

   Strings are symbols
             `A' `B' `C' and `D'), and may be absent. It may be matched as case-insensitive Unicode strings, in
             using the
   following manner. First, strings "subdomain-of" match operator.  Punctuation and
             separator characters in telephone numbers are canonicalized discarded.

        display This subfield indicates a "display name" or user-visible
             name corresponding to the
   "Compatibility Composition" (KC) form, as specified in an address. It is a Unicode
   Technical Report 15 [10]. Then, strings are compared string,
             and is matched using locale-
   insensitive caseless mapping, as specified the case-insensitive algorithm
             described in Unicode Technical
   Report 21 [11].

        Code Section 5.2. The "contains" operator may be
             applied to perform it. It may be absent.

   For any completely unknown subfield, the first step, in Java and Perl, is
        available; see server MAY reject the links from Annex E script
   at the time it is submitted with an indication of UTR 15 [10]. The
        case-insensitive string comparison in the Java standard
        class libraries already performs problem; if a
   script with an unknown subfield is executed, the second step; other
        Unicode-aware libraries should server MUST consider
   the "not-present" output to be similar. the valid one.

   The "address" output tags of string matching are named "string", and have a
   mandatory argument, tag may take exactly one of "is" or "contains", three possible
   parameters, indicating whole-
   string match or substring match, respectively.

5.2.1 Usage the kind of "string-switch" matching allowed.

        is An output with SIP

   For SIP, this match operator is followed if the fields "subject", "organization", and "user-agent"
   correspond to
             subfield being matched in the SIP header fields with "address-switch" exactly
             matches the same name. These are argument of the operator. It may be used verbatim as they appear in for
             any subfield, or for the message.

   The field "display" is not used, entire address if no subfield was
             specified.

        subdomain-of This match operator applies only for the subfields
             "host" and "tel". In the former case, it matches if the
             hostname being matched is never present.

5.3 Language Switches

   Language switches allow a CPL script to make decisions based on subdomain of the
   languages domain given
             in which the originator argument of the call wishes to communicate.
   They are summarized in Figure 6.

   Language switches take no parameters.

   The "language" outputs take one parameter, "matches". The value of
   one of these parameters is a language-tag, as defined in RFC 3066
   [12]. The caller match operator; thus, subdomain-
             of="example.com" would match the hostnames "example.com",
             "research.example.com", and
             "zaphod.sales.internal.example.com". IP addresses may have specified a set of language-ranges, also be
             given as
   defined in RFC 3066. The CPL server checks each language-tag
         Node:  "language-switch"
      Outputs:  "language"         Specific string arguments to this operator; however, they only
             match
   Parameters:  None

       Output:  "language"
   Parameters:  "matches"          Match if exactly. In the given language matches a
                                   language-range case of the call.

   Figure 6: Syntax of "tel" subfield, the "language-switch" node

   specified by the script against the language-ranges specified in the
   request.

   See RFC 3066 for the details of how language-ranges match language-
   tags.  Briefly, a language-range
             output matches a language-tag if it exactly
   equals the tag, or if it exactly equals telephone number being matched has a
             prefix that matches the argument of the tag such that match operator;
             subdomain-of="1212555" would match the first character following telephone number "1
             212 555 1212."

        contains This match operator applies only for the prefix is "-". subfield
             "display". The special language-range "*" is ignored for output matches if the purpose display name being
             matched contains the argument of
   matching.  Languages with the match as a "q" value of 0 are also ignored.

   This switch MAY be not-present.

5.3.1 substring.

5.1.1 Usage of "language-switch" "address-switch" with SIP

   The language-ranges for the "language-switch" switch are obtained
   from

   For SIP, the SIP "Accept-Language" header field. The switch is not-
   present if "origin" address corresponds to the initial SIP request did not contain this header field.

        Note that because of CPL's first-match semantics address in
        switches, "q" values other than 0 of the "Accept-Language"
        header fields are ignored.

5.4 Time Switches

   Time switches allow a CPL script
   "From" header; "destination" corresponds to make decisions based on the time
   and/or date "Request-URI"; and
   "original-destination" corresponds to the script is being executed. They are summarized in
   Figure 7.

   Time switches are independent "To" header.

   The "display" subfield of an address is the underlying signalling protocol.

   Time switches are based closely on the specification display-name part of recurring
   intervals the
   address, if it is present. Because of time in SIP's syntax, the Internet Calendaring and Scheduling Core
         Node:  "time-switch"
      Outputs:  "time"         Specific time to match
   Parameters:  "tzid"         RFC 2445 Time Zone Identifier
                "tzurl"        RFC 2445 Time Zone URL

       Output:  "time"
   Parameters:  "dtstart"      Start of interval (RFC 2445 DATE-TIME)
                "dtend"        End of interval (RFC 2445 DATE-TIME)
                "duration"     Length of interval (RFC 2445 DURATION)
                "freq"         Frequency of recurrence (one of "secondly",
                               "minutely", "hourly", "daily",
                               "weekly", "monthly", or "yearly")
                "interval"     How often the recurrence repeats
                "until"        Bound of recurrence (RFC 2445 DATE-TIME)
                "count"        Number of occurences of recurrence
                "bysecond"     List of seconds within "destination"
   address field will never have a minute
                "byminute"     List "display" subfield.

   The "address-type" subfield of minutes within an hour
                "byhour"       List of hours of the day
                "byday"        List of days of address is the week
                "bymonthday"   List of days URI scheme of that
   address. Other address fields depend on that "address-type".

   For sip URLs, the month
                "byyearday"    List of days of "user", "host", and "port" subfields correspond to
   the year
                "byweekno"     List of weeks "user," "host," and "port" elements of the year
                "bymonth"      List of months of URI syntax. The "tel"
   subfield is defined to be the year
                "wkst"         First day "user" part of the workweek
                "bysetpos"     List of values within set of events specified

   Figure 7: Syntax of URI, with visual
   separators stripped, if and only if the "time-switch" node

   Object Specification (iCalendar COS), RFC 2445 [13].

        This allows CPLs to be generated automatically from
        calendar books. It also allows us "user=phone" parameter is
   given to re-use the extensive
        existing work specifying time intervals.

   If future standards-track documents are published that obsolete RFC
   2445, any changes or clarifications those documents make URI. An additional subfield, "password" is defined to
   recurrence handling apply
   correspond to CPL time-switches as well.

   An algorithm to whether an instant falls within a given recurrence the "password" element of the SIP URI, and is
   given case-
   sensitive. 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 Appendix A. the former case, visual separators are stripped. The "time-switch" tag takes two optional parameters, "tzid" "host" and
   "tzurl", both of which
   "port" subfields are defined both not present.

   For h323 URLs, subfields MAY be set according to the scheme described
   in RFC 2445 (Sections 4.8.3.1 and
   4.8.3.5 respectively). The TZID is Appendix B.

   For other URI schemes, only the identifying label by which a
   time zone definition "address-type" subfield is referenced. defined by
   this specification; servers MAY set other pre-defined subfields, or
   MAY support additional subfields.

   If it begins with a forward slash
   (solidus), it references a to-be-defined global time zone registry;
   otherwise it no subfield is locally-defined at the server. The TZURL gives a
   network location from which an up-to-date VTIMEZONE definition specified for addresses in SIP messages, the timezone can be retrieved.

   While TZID labels that do not begin with a forward slash are locally
   defined, it string
   matched is RECOMMENDED that servers support at least the naming
   scheme used by Olson Time Zone database [14]. Examples URI part of timezone
   databases that use the Olson scheme are the zoneinfo files on most
   Unix-like systems, and the address. For "is" matches, standard Java TimeZone class.

   Servers SHOULD resolve TZID and TZURL references to time zone
   definitions at the time
   SIP URI matching rules are used; for "contains" matches, the script URI is uploaded.
   used verbatim.

5.2 String Switches

   String switches allow a CPL script to make decisions based on free-
   form strings present in a call request. They MAY periodically
   refresh these resolutions are summarized in Figure
   5.

         Node:  "string-switch"
      Outputs:  "string"         Specific string to obtain the most up-to-date definition match
   Parameters:  "field"          "subject", "organization", "user-agent",
                                 or "display"

       Output:  "string"
   Parameters:  "is"             exact match
                "contains"       substring match

   Figure 5: Syntax of
   a time zone. If a TZURL becomes invalid, servers SHOULD remember the
   most recent valid data retrieved from the URL.

   If a script is uploaded with a "tzid" and "tzurl" "string-switch" node

   String switches have one node parameter: "field". The mandatory
   "field" parameter specifies which the CPL
   server does not recognize or cannot resolve, it SHOULD diagnose and
   reject this at script upload time. If neither "tzid" nor "tzurl" are
   present, all non-UTC times within this time switch should string is to be
   interpreted as matched.

   String switches are dependent on the call signalling protocol being "floating" times, i.e. that they
   used.

   Five fields are specified
   in defined, listed below. The value of each of these
   fields, except as specified, is a free-form Unicode string with no
   other structure defined.

        "subject" The subject of the local timezone call.

        "organization" The organization of the CPL server.

        Because originator of daylight-savings-time changes over the course call.

        "user-agent" The name of
        a year, it is necessary to specify time switches in a given
        timezone. UTC offsets are not sufficient, the program or a time-of-day
        routing rule device with which held between 9 am and 5 pm in the
        eastern United States would start holding between 8 am and
        4 pm at
             call request was made.

        "display" Free-form text associated with the end of October.

   Authors of CPL servers should call, intended to
             be careful displayed to handle correctly the
   intervals when local time is discontinuous, at recipient, with no other semantics
             defined by the beginning or end
   of daylight-savings time. Note especially that some times may occur
   more than once when clocks signalling protocol.

   Strings are set back. The algorithm matched as case-insensitive Unicode strings, in Appendix A
   is believed the
   following manner. First, strings are canonicalized to handle this correctly.

   Time nodes specify a list of periods during which their output should
   be taken. They have two required parameters: "dtstart", which
   specifies the beginning of
   "Compatibility Composition" (KC) form, as specified in Unicode
   Technical Report 15 [10]. Then, strings are compared using locale-
   insensitive caseless mapping, as specified in Unicode Technical
   Report 21 [11].

        Code to perform the first period step, in Java and Perl, is
        available; see the links from Annex E of UTR 15 [10]. The
        case-insensitive string comparison in the list, 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 exactly have a
   mandatory argument, one of "dtend" "is" or "duration", which specify the ending time "contains", indicating whole-
   string match or the
   duration substring match, respectively.

5.2.1 Usage of "string-switch" with SIP

   For SIP, the period, respectively. The "dtstart" fields "subject", "organization", and "dtend"
   parameters "user-agent"
   correspond to the SIP header fields with the same name. These are formatted as iCalendar COS DATE-TIME values,
   used verbatim as
   specified in Section 4.3.5 of RFC 2445 [13]. Because time zones are
   specified they appear in the top-level "time-switch" tag, only forms 1 or 2
   (floating or UTC times) can be used. message.

   The "duration" parameter field "display" is
   given as an iCalendar COS DURATION parameter, as specified not used, and is never present.

5.3 Language Switches

   Language switches allow a CPL script to make decisions based on the
   languages in section
   4.3.6 of RFC 2445. Both which the DATE-TIME and originator of the DURATION syntaxes call wishes to communicate.

   They are
   subsets of summarized in Figure 6.

         Node:  "language-switch"
      Outputs:  "language"         Specific string to match
   Parameters:  None

       Output:  "language"
   Parameters:  "matches"          Match if the corresponding syntaxes from ISO 8601 [15].

   For given language matches a recurring interval,
                                   language-range of the "duration" parameter MUST be small
   enough such that subsequent intervals do not overlap.

   For non-recurring intervals, durations call.

   Figure 6: Syntax of any positive length are
   permitted. Zero-length and negative-length durations are not allowed.

   If the "language-switch" node

   Language switches take no other parameters.

   The "language" outputs take one parameter, "matches". The value of
   one of these parameters are specified, is a time node indicates only language-tag, as defined in RFC 3066
   [12]. The caller may have specified a
   single period set of time. More complicated sets periods intervals are
   constructed language-ranges, also as recurrences. A recurrence is
   defined in RFC 3066. The CPL server checks each language-tag
   specified by including the "freq" parameter, which indicates script against the type of recurrence rule. No
   parameters other than "dtstart", "dtend", and "duration" SHOULD be language-ranges specified unless "freq" is present, though CPL servers SHOULD accept
   scripts with such parameters present, and ignore in the other
   parameters.

   The "freq" parameter takes one of
   request.

   See RFC 3066 for the following values:  "secondly",
   to specify repeating periods based on an interval of a second or
   more; "minutely", to specify repeating periods based on an interval
   of a minute or more; "hourly", to specify repeating periods based on
   an interval of an hour or more;

   "daily", to specify repeating periods based on an interval details of how language-ranges match language-
   tags.  Briefly, a day
   or more; "weekly", to specify repeating periods based on an interval
   of language-range matches a week language-tag if it exactly
   equals the tag, or more; "monthly", to specify repeating periods based on
   an interval of if it exactly equals a month or more; and "yearly", to specify repeating
   periods based on an interval prefix of a year or more. These values are not
   case-sensitive.

   The "interval" parameter contains a positive integer representing how
   often the recurrence rule repeats. The default value is "1", meaning
   every day for a "daily" rule, every week for a "weekly" rule, every
   month for a "monthly" rule and every year for a "yearly" rule.

   The "until" parameter defines an iCalendar COS DATE or DATE-TIME
   value which bounds tag such that
   the recurrence rule in an inclusive manner. If first character following the
   value specified by "until" prefix is synchronized with "-".

   If the caller specified
   recurrence, this date or date-time becomes the last instance of the
   recurrence. If specified as a date-time value, then special language-range "*", it MUST be
   specified in an UTC time format. If not present, and the "count"
   parameter is not also present, ignored
   for the recurrence is considered to repeat
   forever.

   The "count" parameter defines purpose of matching.  Languages with a "q" value of 0 are
   also ignored.

   This switch MAY be not-present.

5.3.1 Usage of "language-switch" with SIP

   The language-ranges for the number "language-switch" switch are obtained
   from the SIP "Accept-Language" header field. The switch is not-
   present if the initial SIP request did not contain this header field.

        Note that because of occurrences at which CPL's first-match semantics in
        switches, "q" values other than 0 of the "Accept-Language"
        header fields are ignored.

5.4 Time Switches
   Time switches allow a CPL script to
   range-bound make decisions based on the recurrence. The "dtstart" parameter counts as time
   and/or date the
   first occurrence. The "until" and "count" parameters MUST NOT occur script is being executed. They are summarized in
   Figure 7.

   Time switches are independent of the same underlying signalling protocol.

         Node:  "time-switch"
      Outputs:  "time" output.

   The         Specific time to match
   Parameters:  "tzid"         RFC 2445 Time Zone Identifier
                "tzurl"        RFC 2445 Time Zone URL

       Output:  "time"
   Parameters:  "dtstart"      Start of interval (RFC 2445 DATE-TIME)
                "dtend"        End of interval (RFC 2445 DATE-TIME)
                "duration"     Length of interval (RFC 2445 DURATION)
                "freq"         Frequency of recurrence (one of "secondly",
                               "minutely", "hourly", "daily",
                               "weekly", "monthly", or "yearly")
                "interval"     How often the recurrence repeats
                "until"        Bound of recurrence (RFC 2445 DATE-TIME)
                "count"        Number of occurrences of recurrence
                "bysecond" parameter specifies a comma-separated list     List of seconds within a minute. Valid values are 0 to 59. The minute
                "byminute" parameter
   specifies a comma-separated list     List of minutes within an hour. Valid
   values are 0 to 59. The hour
                "byhour" parameter specifies a comma-
   separated list       List of hours of the day. Valid values are 0 to 23.

   The day
                "byday" parameter specifies a comma-separated list        List of days of the
   week. "MO" indicates Monday; "TU" indicates Tuesday; "WE" indicates
   Wednesday; "TH" indicates Thursday; "FR" indicates Friday; "SA"
   indicates Saturday; "SU" indicates Sunday. These values are not
   case-sensitive.

   Each "byday" value can also be preceded by a positive (+n) or
   negative (-n) integer. If present, this indicates the nth occurrence
   of the specific day within the "monthly" or "yearly" recurrence. For
   example, within a "monthly" rule, +1MO (or simply 1MO) represents the
   first Monday within the month, whereas -1MO represents the last
   Monday week
                "bymonthday"   List of the month. If an integer modifier is not present, it means
   all days of this type within the specified frequency. For example,
   within a "monthly" rule, MO represents all Mondays within the month.

   The "bymonthday" parameter specifies a comma-separated list month
                "byyearday"    List of days of the month. Valid values are 1 to 31 or -31 to -1. For example, -10
   represents year
                "byweekno"     List of weeks of the tenth to year
                "bymonth"      List of months of the last year
                "wkst"         First day of the month.

   The "byyearday" parameter specifies a comma-separated list work week
                "bysetpos"     List of days values within set of events specified

   Figure 7: Syntax of the year. Valid values "time-switch" node

   Time switches are 1 to 366 or -366 to -1. For example, -1
   represents based closely on the last day specification of recurring
   intervals of time in the year (December 31st) Internet Calendaring and -306
   represents the 306th Scheduling Core
   Object Specification (iCalendar COS), RFC 2445 [13].

        This allows CPL scripts to be generated automatically from
        calendar books. It also allows us to re-use the last day of the year (March 1st).

   The "byweekno" parameter specifies a comma-separated list of ordinals extensive
        existing work specifying weeks of the year. Valid values time intervals.

   If future standards-track documents are 1 to 53 published that update or -53 to -1.
   This corresponds
   obsolete RFC 2445, any changes or clarifications those documents make
   to weeks according recurrence handling apply to week numbering as defined in
   ISO 8601 [15]. A week is defined CPL time-switches as a seven day period, starting on
   the day of the week defined well.

   An algorithm to be the week start (see "wkst"). Week
   number one of the calendar year whether an instant falls within a given recurrence is the first week
   given in Appendix A.

   The "time-switch" tag takes two optional parameters, "tzid" and
   "tzurl", both of which contains at
   least four (4) days are defined in that calendar year. This parameter RFC 2445 (Sections 4.8.3.1 and
   4.8.3.5 respectively). The TZID is only
   valid for "yearly" rules. For example, 3 represents the third week of the year.

        Note: Assuming identifying label by which a Monday week start, week 53 can only occur
        when Thursday
   time zone definition is January 1 or if referenced. If it is begins with a leap year and
        Wednesday is January 1.

   The "bymonth" parameter specifies forward slash
   (solidus), it references a comma-separated list of months of to-be-defined global time zone registry;
   otherwise it is locally-defined at the year. Valid values are 1 to 12. server. The "wkst" parameter specifies the day on TZURL gives a
   network location from which an up-to-date VTIMEZONE definition for
   the workweek starts.
   Valid values timezone can be retrieved.

   While TZID labels that do not begin with a forward slash are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This is
   significant when a "weekly" recurrence has an interval greater than
   1, and a "byday" parameter is specified. This is also significant in
   a "yearly" recurrence when a "byweekno" parameter is specified. The
   default value locally
   defined, it is "MO", following ISO 8601 [15].

   The "bysetpos" parameter specifies a comma-separated list of values
   which corresponds to the nth occurrence within RECOMMENDED that servers support at least the set of events
   specified naming
   scheme used by Olson Time Zone database [14]. Examples of timezone
   databases that use the rule. Valid values Olson scheme are 1 the zoneinfo files on most
   Unix-like systems, and the standard Java TimeZone class.

   Servers SHOULD resolve TZID and TZURL references to 366 or -366 time zone
   definitions at the time the script is uploaded. They MAY periodically
   refresh these resolutions to -1. It
   MUST only be used in conjunction with another byxxx parameter. For
   example "the last work day obtain the most up-to-date definition of
   a time zone. If a TZURL becomes invalid, servers SHOULD remember the month" could be represented as:

     <time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR"
           bysetpos="-1">

   Each "bysetpos" value can include
   most recent valid data retrieved from the URL.

   If a positive (+n) script is uploaded with a "tzid" and "tzurl" which the CPL
   server does not recognize or negative (-n)
   integer. cannot resolve, it SHOULD diagnose and
   reject this at script upload time. If neither "tzid" nor "tzurl" are
   present, all non-UTC times within this indicates time switch should be
   interpreted as being "floating" times, i.e. that they are specified
   in the nth occurrence local timezone of the
   specific occurrence within the set CPL server.

        Because of events specified by the rule.

   If byxxx parameter values are found which are beyond daylight-savings-time changes over the available
   scope (ie, bymonthday="30" course of
        a year, it is necessary to specify time switches in February), they a given
        timezone. UTC offsets are simply ignored.

   Byxxx parameters modify the recurrence in some manner. Byxxx rule
   parts for not sufficient, or a period of time time-of-day
        routing rule which is the same or greater than held between 9 am and 5 pm in the
   frequency generally reduce or limit
        eastern United States would start holding between 8 am and
        4 pm at the number end of occurrences October.

   Authors of CPL servers should be careful to handle correctly the
   recurrence generated. For example, freq="daily" bymonth="1" reduces
   intervals when local time is discontinuous, at the number beginning or end
   of recurrence instances from all days (if the "bymonth"
   parameter daylight-savings time. Note especially that some times may occur
   more than once when clocks are set back. The algorithm in Appendix A
   is not present) believed to all days in January. Byxxx parameters
   for handle this correctly.

   Time nodes specify a period list of time less than periods during which their output should
   be taken. They have two required parameters: "dtstart", which
   specifies the frequency generally increase or
   expand beginning of the number first period of occurrences the list, and exactly
   one of "dtend" or "duration", which specify the recurrence. For example,
   freq="yearly" bymonth="1,2" increases ending time or the number
   duration of days within the
   yearly recurrence set from 1 (if "bymonth" parameter is not present)
   to 2.

   If multiple Byxxx parameters are specified, then after evaluating the
   specified "freq" period, respectively. The "dtstart" and "interval" parameters, the Byxxx "dtend"
   parameters are
   applied to the current set formatted as iCalendar COS DATE-TIME values, as
   specified in Section 4.3.5 of evaluated occurrences RFC 2445 [13]. Because time zones are
   specified in the following
   order:  "bymonth", "byweekno", "byyearday", "bymonthday", "byday",
   "byhour", "byminute", "bysecond" and "bysetpos"; then "count" and
   "until" are evaluated.

   Here top-level "time-switch" tag, only forms 1 or 2
   (floating or UTC times) can be used. The "duration" parameter is
   given as an example of evaluating multiple Byxxx parameters.

     <time dtstart="19970105T083000" duration="10M"
           freq="yearly" interval="2" bymonth="1" byday="SU" byhour="8,9"
           byminute="30">

   First, the interval="2" would be applied to freq="YEARLY" to arrive
   at "every other year." Then, bymonth="1" would be applied to arrive
   at "every January, every other year." Then, byday="SU" would be
   applied to arrive at "every Sunday in January, every other year."
   Then, byhour="8,9" would be applied to arrive at "every Sunday in
   January at 8 AM and 9 AM, every other year." Then, byminute="30"
   would be applied to arrive at "every Sunday iCalendar COS DURATION parameter, as specified in January at 8:30 AM and
   9:30 AM, every other year." Then section
   4.3.6 of RFC 2445. Both the second is derived from "dtstart"
   to end up in "every Sunday in January from 8:30:00 AM to 8:40:00 AM,
   and from DATE-TIME and 9:30:00 AM to 9:40:00 AM, every other year." Similarly,
   if the "byminute", "byhour", "byday", "bymonthday" or "bymonth"
   parameter were missing, DURATION syntaxes are
   subsets of the appropriate minute, hour, day or month
   would have been retrieved corresponding syntaxes from ISO 8601 [15].

   For a recurring interval, the "dtstart" parameter.

   The iCalendar COS RDATE, EXRULE "duration" parameter MUST be small
   enough such that subsequent intervals do not overlap.  For non-
   recurring intervals, durations of any positive length are permitted.
   Zero-length and EXDATE recurrence rules negative-length durations are not
   specifically mapped to components allowed.

   If no other parameters are specified, a time node indicates only a
   single period of time. More complicated sets periods intervals are
   constructed as recurrences. A recurrence is specified by including
   the time-switch node. Equivalent
   functionality to "freq" parameter, which indicates the exception rules can type of recurrence rule. No
   parameters other than "dtstart", "dtend", and "duration" SHOULD be attained by using
   specified unless "freq" is present, though CPL servers SHOULD accept
   scripts with such parameters present, and ignore the
   ordering other
   parameters.

   The "freq" parameter takes one of switch rules to exclude times using earlier rules;
   equivalent functionality to the additional-date RDATE rules can be
   attained by using "sub" nodes (see Section 9) to link multiple
   outputs following values:  "secondly",
   to the same subsequent node.

   The "not-present" output is never true for specify repeating periods based on an interval of a time switch. However, it
   MAY be included, second or
   more; "minutely", to allow switch processing specify repeating periods based on an interval
   of a minute or more; "hourly", to be more regular.

5.4.1 iCalendar differences and implementation issues

   (This sub-sub-section is non-normative.)

   The specification specify repeating periods based on
   an interval of recurring events in this section is identical
   (except for syntax and formatting issues) an hour or more; "daily", to that specify repeating periods
   based on an interval of RFC 2445 [13],
   with only one additional restriction. That one restriction is that
   consecutive instances of recurrence intervals may not overlap.

   It was a matter of some debate, during the design of the CPL, whether
   the entire iCalendar COS recurrence specification should be included
   in CPL, day or whether only a subset should be included. It was
   eventually decided that compatibility between the two protocols was
   of primary importance. This imposes some additional implementation
   issues more; "weekly", to specify repeating
   periods based on implementors an interval of CPL servers.

   It does not appear to be possible to determine, in constant time,
   whether a given instant week or more; "monthly", to specify
   repeating periods based on an interval of time falls within one a month or more; and
   "yearly", to specify repeating periods based on an interval of the intervals
   defined by a full iCalendar COS recurrence. The primary concerns year
   or more. These values are
   as follows:

        o not case-sensitive.

   The "count" "interval" parameter cannot be checked in constant running
          time, since it requires that the server enumerate all
          recurrences from "dtstart" to the present time, in order to
          determine whether contains a positive integer representing how
   often the current recurrence satisfies the
          parameter. However, rule repeats. The default value is "1", meaning
   every day for a server can expand "daily" rule, every week for a "count" paramter
          once, off-line, to determime the date of the last recurrence.
          This date can then be treated as "weekly" rule, every
   month for a virtual "monthly" rule and every year for a "yearly" rule.

   The "until" parameter
          for the server's internal processing.

        o Similarly, defines an iCalendar COS DATE or DATE-TIME
   value which bounds the "bysetpos" parameter requires that recurrence rule in an inclusive manner. If the server
          enumerate all instances of
   value specified by "until" is synchronized with the currence from specified
   recurrence, this date or date-time becomes the start last instance of the
          current recurrence set until the present time. This requires
          somewhat more complex pre-processing, but generally, a single
          recurrence with
   recurrence. If specified as a "bysetpos" parameter can date-time value, then it MUST be split up into
          several recurrences without them.

        o Finally, constant running time of
   specified in an UTC time switches format. If not present, and the "count"
   parameter is not also requires
          that a candidate starting time for a present, the recurrence can be
          established quickly and uniquely, is considered to check whether it
          satisfies repeat
   forever.

   The "count" parameter defines the other restrictions. This requires that a
          recurrence's duration not be longer than its repetition
          interval, so that a given instant cannot fall within several
          consecutive potential repetitions number of occurrences at which to
   range-bound the recurrence. The
          restriction that consecutive intervals not overlap partially
          satisfies this condition, but does not fully ensure it. Again,
          to some extent pre-processing can help resolve this. "dtstart" parameter counts as the
   first occurrence. The algorithm given in Appendix A runs in constant time after these
   pre-processing steps.

   Servers ought to check that recurrence rules do not create any absurd
   run-time or memory requirements, "until" and reject those that do, just as
   they ought to check that CPL scripts "count" parameters MUST NOT occur
   in general are not absurdly
   large.

5.5 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 8. They same "time" output.

   The "bysecond" parameter specifies a comma-separated list of seconds
   within a minute. Valid values are dependent on the underlying signalling protocol.

         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 0 to specified

   Figure 8: Syntax 59. The "byminute" parameter
   specifies a comma-separated list of the "priority-switch" node

   Priority switches take no parameters. minutes within an hour. Valid
   values are 0 to 59. The "priority" tags take one "byhour" parameter specifies a comma-
   separated list of hours of the three parameters "greater",
   "less", and "equal". The day. Valid values of these tags are one 0 to 23.

   The "byday" parameter specifies a comma-separated list of days of the
   following priorities: in decreasing order, "emergency", "urgent",
   "normal", and "non-urgent".
   week. "MO" indicates Monday; "TU" indicates Tuesday; "WE" indicates
   Wednesday; "TH" indicates Thursday; "FR" indicates Friday; "SA"
   indicates Saturday; "SU" indicates Sunday. These values are matched in not
   case-sensitive.

   Each "byday" value can also be preceded by a case-
   insensitive manner. Outputs with the "less" parameter are taken if positive (+n) or
   negative (-n) integer. If present, this indicates the priority nth occurrence
   of the call is less than the priority given in specific day within the
   argument; and so forth.

   If no priority header is specified in "monthly" or "yearly" recurrence. For
   example, within a message, "monthly" rule, +1MO (or simply 1MO) represents the priority is
   considered to be "normal". If an unknown priority is specified in
   first Monday within the
   call, it is considered to be equivalent to "normal" for month, whereas -1MO represents the purposes last
   Monday of "greater" and "less" comparisons, but it the month. If an integer modifier is compared literally for
   "equal" comparisons.

   Since every message has not present, it means
   all days of this type within the specified frequency. For example,
   within a priority, "monthly" rule, MO represents all Mondays within the "not-present" output is never
   true for month.

   The "bymonthday" parameter specifies a priority switch. However, it MAY be included, comma-separated list of days
   of the month. Valid values are 1 to allow
   switch processing 31 or -31 to be more regular.

5.5.1 Usage -1. For example, -10
   represents the tenth to the last day of "priority-switch" with SIP the month.

   The priority of "byyearday" parameter specifies a SIP message corresponds comma-separated list of days of
   the year. Valid values are 1 to 366 or -366 to -1. For example, -1
   represents the "Priority" header in last day of the initial "INVITE" message.

6 Location Modifiers

   The abstract location model year (December 31st) and -306
   represents the 306th to the last day of the CPL is described in Section 2.3. year (March 1st).

   The behavior "byweekno" parameter specifies a comma-separated list of several ordinals
   specifying weeks of the signalling operations (defined year. Valid values are 1 to 53 or -53 to -1.
   This corresponds to weeks according to week numbering as defined in
   Section 7)
   ISO 8601 [15]. A week is dependent defined as a seven day period, starting on
   the current location set specified.
   Location nodes add or remove locations from the location set.

   There are three types day 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.

6.1 Explicit Location

   Explicit location nodes specify a location literally. Their syntax is
   described in Figure 9.

   Explicit location nodes are dependent on the underlying signalling
   protocol.

           Node:  "location"
        Outputs:  None        (next node follows directly)
      Next node:  Any node
     Parameters:  "url"       URL of address to add to location set
                  "priority"  Priority of this location (0.0-1.0)
                  "clear"     Whether week defined to clear the location set before adding be the new value

   Figure 9: Syntax week start (see "wkst"). Week
   number one of the "location" node

   Explicit location nodes have three node parameters. The mandatory
   "url" parameter's value calendar year 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.

   The optional "priority" first week which contains at
   least four (4) days in that calendar year. This parameter specifies a priority is only
   valid for "yearly" rules. For example, 3 represents the
   location.  Its value third week of
   the year.

        Note: Assuming a Monday week start, week 53 can only occur
        when Thursday is January 1 or if it is a floating-point number between 0.0 leap year and 1.0.
   If it
        Wednesday is not specified, the server SHOULD assume January 1.

   The "bymonth" parameter specifies a default priority comma-separated list of 1.0. months of
   the year. Valid values are 1 to 12.

   The optional "clear" "wkst" parameter specifies whether the location
   set should be cleared before adding the new location to it. Its value
   can be "yes" or "no", with "no" as day on which the default.

   Basic location nodes have only one possible result, since there work week starts.
   Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This is no
   way that they can fail. (If
   significant when a basic location node "weekly" recurrence has an interval greater than
   1, and a "byday" parameter is specified. This is also significant in
   a "yearly" recurrence when a "byweekno" parameter is specified. The
   default value is "MO", following ISO 8601 [15].

   The "bysetpos" parameter specifies a
   location comma-separated list of values
   which isn't supported by corresponds to the underlying signalling protocol, nth occurrence within the script server SHOULD detect this and report it set of events
   specified by the rule. Valid values are 1 to 366 or -366 to -1. It
   MUST only be used in conjunction with another byxxx parameter. For
   example "the last work day of the user at month" could be represented as:

     <time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR"
           bysetpos="-1">

   Each "bysetpos" value can include a positive (+n) or negative (-n)
   integer. If present, this indicates the
   time nth occurrence of the script is submitted.) Therefore, their XML representations
   do not have explicit output tags;
   specific occurrence within the <location> tag directly
   contains another node.

6.1.1 Usage set of "location" with SIP
   All SIP locations events specified by the rule.

   If byxxx parameter values are represented as URLs, so found which are beyond the locations specified available
   scope (ie, bymonthday="30" in "location" tags February), they are interpreted directly.

6.2 Location Lookup

   Locations can also be specified up through external means, through simply ignored.

   Byxxx parameters modify the use of location lookups. The syntax of these tags is given recurrence in
   Figure 10.

   Location lookup some manner. Byxxx rule
   parts for a period of time which is dependent on the underlying signalling protocol.

            Node:  "lookup"
         Outputs:  "success"   Next node if lookup was successful
                   "notfound"  Next node if lookup found no addresses
                   "failure"   Next node if lookup failed
      Parameters:  "source"    Source of same or greater than the lookup
                   "timeout"   Time to try before giving up on
   frequency generally reduce or limit the lookup
                   "use"       Caller preferences fields to use
                   "ignore"    Caller preferences fields to ignore
                   "clear"     Whether to clear number of occurrences of the location set before adding
   recurrence generated. For example, freq="daily" bymonth="1" reduces
   the new values

          Output:  "success"
      Parameters:  none

          Output:  "notfound"
      Parameters:  none

          Output:  "failure"
      Parameters:  none

   Figure 10: Syntax number of recurrence instances from all days (if the "lookup" node

   Location lookup nodes have one mandatory parameter, and four optional
   parameters. The mandatory "bymonth"
   parameter is "source", the source not present) to all days in January. Byxxx parameters
   for a period of time less than the
   lookup. This can either be a URI, frequency generally increase or a non-URI value. If
   expand the value number of occurrences of
   "source" is a URI, it indicates a location which the CPL server can
   query to obtain an object with the text/uri-list media type (see recurrence. For example,
   freq="yearly" bymonth="1,2" increases the
   IANA registration number of this type, which also appears in RFC 2483 [16]).
   The query is performed verbatim, with no additional information (such
   as URI parameters) added.  The server adds days within the locations contained in
   this object
   yearly recurrence set from 1 (if "bymonth" parameter is not present)
   to 2.

   If multiple Byxxx parameters are specified, then after evaluating the location set.

   CPL servers MAY refuse to allow URI-based sources for location
   queries for some or all URI schemes. In this case, they SHOULD reject
   specified "freq" and "interval" parameters, the script at script upload time.

        There has been discussion of having CPL servers add URI Byxxx parameters are
   applied to the location request, so that (for instance)
        CGI scripts could be used to resolve them. However, the
        consensus was that this should be a CPL extension, not a
        part current set of evaluated occurrences in the base specification.

   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 following
   order:  "bymonth", "byweekno", "byyearday", "bymonthday", "byday",
   "byhour", "byminute", "bysecond" and "bysetpos"; then "count" and
   "until" are evaluated.

   Here is "registration", which specifies
   all the locations currently registered with the server.

   The "lookup" node also has four optional parameters. The "timeout"
   parameter specifies the time, as a positive integer number an example of
   seconds, evaluating multiple Byxxx parameters.

     <time dtstart="19970105T083000" duration="10M"
           freq="yearly" interval="2" bymonth="1" byday="SU" byhour="8,9"
           byminute="30">

   First, the script is willing interval="2" would be applied to wait for the lookup freq="YEARLY" to arrive
   at "every other year." Then, bymonth="1" would be
   performed. If this is not specified, its default value is 30. The
   "clear" parameter specifies whether the location set should applied to arrive
   at "every January, every other year." Then, byday="SU" would be
   cleared before the new locations are added.

   The
   applied to arrive at "every Sunday in January, every other two optional parameters affect the interworking of year."
   Then, byhour="8,9" would be applied to arrive at "every Sunday in
   January at 8 AM and 9 AM, every other year." Then, byminute="30"
   would be applied to arrive at "every Sunday in January at 8:30 AM and
   9:30 AM, every other year." Then the CPL
   script with caller preferences second is derived from "dtstart"
   to end up in "every Sunday in January from 8:30:00 AM to 8:40:00 AM,
   and caller capabilities.  By default,
   a CPL server SHOULD invoke from and 9:30:00 AM to 9:40:00 AM, every other year." Similarly,
   if the appropriate caller preferences
   filtering of "byminute", "byhour", "byday", "bymonthday" or "bymonth"
   parameter were missing, the underlying signalling protocol, if appropriate minute, hour, day or month
   would have been retrieved from the corresponding
   information is available. "dtstart" parameter.

   The two parameters "use" iCalendar COS RDATE, EXRULE and "ignore" allow EXDATE recurrence rules are not
   specifically mapped to components of the script time-switch node. Equivalent
   functionality to modify how the script applies caller preferences
   filtering. The specific meaning of exception rules can be attained by using the values
   ordering of these parameters is
   signalling-protocol dependent; see switch rules to exclude times using earlier rules;
   equivalent functionality to the additional-date RDATE rules can be
   attained by using "sub" nodes (see Section 6.2.1 9) to link multiple
   outputs to the same subsequent node.

   The "not-present" output is never true for SIP a time switch. However, it
   MAY be included, to allow switch processing to be more regular.

5.4.1 iCalendar differences and Appendix
   B.6 for H.323.

   Lookup has three outputs: "success", "notfound", and "failure".
   Notfound implementation issues

   (This sub-sub-section is taken if the lookup process succeeded but did not find
   any locations; failure non-normative.)

   The specification of recurring events in this section is taken if the lookup failed identical
   (except for some reason,
   including syntax and formatting issues) to that specified timeout was exceeded. If a given output of RFC 2445 [13],
   with only one additional restriction. That one restriction is that
   consecutive instances of recurrence intervals may not present, script execution terminates and overlap.

   It was a matter of some debate, during the default behavior is
   performed.

   Clients SHOULD specify design of the three outputs "success", "notfound", and
   "failure" CPL, whether
   the entire iCalendar COS recurrence specification should be included
   in CPL, or whether only a subset should be included. It was
   eventually decided that order, so their script complies with compatibility between the DTD given
   in Appendix C, but servers MAY accept them in any order.

6.2.1 Usage two protocols was
   of "lookup" with SIP

   Caller preferences for SIP are defined primary importance. This imposes some additional implementation
   issues on implementors of CPL servers.

   It does not appear to be possible to determine, in "SIP Caller Preferences and
   Callee Capabilities" [17]. By default, constant time,
   whether a CPL server SHOULD honor any
   "Accept-Contact" and "Reject-Contact" headers given instant of time falls within one of the original call
   request, intervals
   defined by a full iCalendar COS recurrence. The primary concerns are
   as specified follows:

        o The "count" parameter cannot be checked in constant running
          time, since it requires that document. The two parameters "use" and
   "ignore" allow the script server enumerate all
          recurrences from "dtstart" to modify the data input present time, in order to
          determine whether the caller
   preferences algorithm. These parameters both take as their arguments
   comma-separated lists of caller preferences parameters. If "use" is
   given, current recurrence satisfies the
          parameter. However, a server applies the caller preferences resolution algorithm
   only can expand a "count" parameter
          once, off-line, to those preference parameters given in determine the "use" parameter, and
   ignores all others; if date of the "ignore" last recurrence.
          This date can then be treated as a virtual "until" parameter is given,
          for the server
   ignores server's internal processing.

        o Similarly, the specified parameters, and uses "bysetpos" parameter requires that the server
          enumerate all instances of the others. Only one occurrence from the start of "use" and "ignore"
          the current recurrence set until the present time. This
          requires somewhat more complex pre-processing, but generally,
          a single recurrence with a "bysetpos" parameter can be specified.

   The addr-spec part split
          up into several recurrences without them.

        o Finally, constant running time of the caller preferences is always applied, time switches also requires
          that a candidate starting time for a recurrence can be
          established quickly and uniquely, to check whether it
          satisfies the script cannot modify it.

   If other restrictions. This requires that a SIP server does
          recurrence's duration not support caller preferences and callee
   capabilities, if be longer than its repetition
          interval, so that a given instant cannot fall within several
          consecutive potential repetitions of the call request does recurrence. The
          restriction that consecutive intervals not contain any preferences,
   or if the callee's registrations do overlap partially
          satisfies this condition, but does not contain any capabilities, the
   "use" and "ignore" parameters are ignored.

6.3 Location Removal fully ensure it. Again,
          to some extent pre-processing can help resolve this.

   The algorithm given in Appendix A runs in constant time after these
   pre-processing steps.

   Servers ought to check that recurrence rules do not create any absurd
   run-time or memory requirements, and reject those that do, just as
   they ought to check that CPL scripts in general are not absurdly
   large.

5.5 Priority Switches
   Priority switches allow a CPL script can also remove locations from the location set, through to make decisions based on the use of
   priority specified for the "remove-location" node. The syntax of this node is
   defined original call. They are summarized in
   Figure 11.

   The meaning of this node is 8. They are dependent on the underlying signalling protocol.

         Node:  "remove-location"  "priority-switch"
      Outputs:  "priority"         Specific priority to match
   Parameters:  None               (next node follows directly)
    Next node:  Any node

       Output:  "priority"
   Parameters:  "location"         Location to remove
                "param"            Caller preference parameters  "less"             Match if priority is less than specified
                "greater"          Match if priority is greater than specified
                "equal"            Match if priority is equal to apply
                "value"            Value of caller preference parameters specified

   Figure 11: 8: Syntax of the "remove-location" node

   A "remove-location" "priority-switch" node removes locations from

   Priority switches take no parameters.

   The "priority" tags take one of the three parameters "greater",
   "less", and "equal". The values of these tags are one of the location set. It
   is primarily useful
   following priorities: in decreasing order, "emergency", "urgent",
   "normal", and "non-urgent". These values are matched in a "lookup" node.  An example case-
   insensitive manner. Outputs with the "less" parameter are taken if
   the priority of this the call is less than the priority given in Section 13.8.

   The "remove-location" node has three optional parameters. The
   parameter "location" gives the URL (or
   argument; and so forth.

   If no priority header is specified in a signalling-protocol-
   dependent URL pattern) of location or locations to be removed from message, the set. If this parameter priority is not given, all locations, subject
   considered to
   the constraints of the other parameters, are removed from the set. be "normal". If param and value are present, their values are comma-separated
   lists of caller preferences parameters and corresponding values,
   respectively. The nth entry in the param list matches the nth entry an unknown priority is specified in the value list. There MUST
   call, it is considered to be equivalent to "normal" for the same number of parameters as
   values specified.  The meaning purposes
   of these parameters "greater" and "less" comparisons, but it is signalling-
   protocol dependent.

   The "remove-location" node compared literally for
   "equal" comparisons.

   Since every message has no explicit output tags. In the XML
   syntax, the XML "remove-location" tag directly encloses a priority, the next
   node's tag.

6.3.1 "not-present" output is never
   true for a priority switch. However, it MAY be included, to allow
   switch processing to be more regular.

5.5.1 Usage of "remove-location" "priority-switch" with SIP

   For SIP-based CPL servers, the "remove-location" node has the same
   effect on the location set as

   The priority of a "Reject-Contact" SIP message corresponds to the "Priority" header in caller
   preferences [17].
   the initial "INVITE" message.

6 Location Modifiers

   The value abstract location model of the "location" parameter is treated as
   though it were the addr-spec field of a Reject-Contact header; thus,
   an absent header CPL is equivalent to an addr-spec of "*" described in that
   specification. Section 2.3.
   The "param" and "value" parameters are treated as
   though they appeared in the params field behavior of several of a Reject-Location header,
   as "; param=value" for each one.

   If the CPL server does not support caller preferences and callee
   capabilities, or if signalling operations (defined in
   Section 7) is dependent on the callee did not supply any preferences, current location set specified.
   Location nodes add or remove locations from the
   "param" and "value" parameters location set.

   There are ignored.

7 Signalling Operations

   Signalling operation three types of location nodes cause signalling events in defined. Explicit locations
   add literally-specified locations to the underlying
   signalling protocol. Three signalling operations are defined:
   "proxy," "redirect," current location set;
   location lookups obtain locations from some outside source; and "reject."

7.1 Proxy

   Proxy causes
   location filters remove locations from the triggering call to be forwarded set, based on to the currently some
   specified set of locations. The criteria.

6.1 Explicit Location

   Explicit location nodes specify a location literally. Their syntax of the proxy node is given
   described in Figure 12.

   The specific signalling events invoked by the "proxy" node 9.

   Explicit location nodes are
   signalling-protocol-dependent, though dependent on the general concept should
   apply to any underlying signalling
   protocol.

   After a proxy operation 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.

         Node:  "proxy"  "location"
      Outputs:  "busy"         Next  None        (next node if call attempt returned "busy"
                "noanswer" follows directly)
    Next node:  Any node if call attempt was not answered
   Parameters:  "url"       URL of address to add to location set
                "priority"  Priority of this location (0.0-1.0)
                "clear"     Whether to clear the location set before timeout
                "redirection"  Next node if call attempt was redirected
                "failure"      Next node if call attempt failed
                "default"      Default next node for unspecified outputs
   Parameters:  "timeout"      Time to try before giving up on the call attempt
                "recurse"      Whether to recursively look up redirections
                "ordering"     What order to try adding
                            the location set in.

       Output:  "busy"
   Parameters:  none

       Output:  "noanswer"
   Parameters:  none

       Output:  "redirection"
   Parameters:  none

       Output:  "failure"
   Parameters:  none

       Output:  "default"
   Parameters:  none new value

   Figure 12: 9: Syntax of the "proxy" "location" node

   If

   Explicit location nodes have three node parameters. The mandatory
   "url" parameter's value is the call attempt was successful, CPL execution terminates and URL of the
   server proceeds to its default behavior (normally, address to allow the call add to be set up).  Otherwise, the next node corresponding to
   location set.  Only one of the
   "proxy" node's outputs is taken. address may be specified per location node;
   multiple locations may be specified by cascading these nodes.

   The "busy" output is followed if the
   call was busy; "noanswer" is followed if the call was not answered
   before the "timeout" optional "priority" parameter expired; "redirection" is followed if specifies a priority for the call was redirected; and "failure"
   location.  Its value is followed if the call setup
   failed for any other reason. a floating-point number between 0.0 and 1.0.
   If one of the conditions above it is true, but the corresponding output
   was not specified, the "default" output server SHOULD assume a default priority
   of 1.0. The optional "clear" parameter specifies whether the "proxy" node is
   followed instead. If there is also no "default" node specified, CPL
   execution terminates and location
   set should be cleared before adding the server returns to its default behavior
   (normally, to forward the best response upstream to the originator).

        Note: CPL extensions to allow in-call or end-of-call
        operations will require an additional output, such as
        "success", new location to it. Its value
   can be added.

   If no locations were present in the set, "yes" or if "no", with "no" as the default.

   Basic location nodes have only locations in
   the set were locations to one possible result, 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 cannot proxy a call (for
   example, "http" URLs), SHOULD detect this and report it to the "failure" output user at the
   time the script is taken.

   Proxy has three optional parameters. The "timeout" parameter
   specifies submitted.) Therefore, their XML representations
   do not have explicit output tags; the time, as a positive integer number <location> tag directly
   contains another node.

6.1.1 Usage of seconds, to wait
   for "location" with SIP

   All SIP locations are represented as URLs, so the call to locations specified
   in "location" tags are interpreted directly.

6.2 Location Lookup

   Locations can also be completed or rejected; after this time has
   elapsed, the call attempt is terminated and specified up through external means, through
   the "noanswer" branch use of location lookups. The syntax of these tags is
   taken. If this parameter given in
   Figure 10.

   Location lookup is not specified, dependent on the default value is 20
   seconds underlying signalling protocol.

         Node:  "lookup"
      Outputs:  "success"   Next node if the "proxy" lookup was successful
                "notfound"  Next node has a "noanswer" or "default" output
   specified; otherwise if lookup found no addresses
                "failure"   Next node if lookup failed
   Parameters:  "source"    Source of the server SHOULD allow lookup
                "timeout"   Time to try before giving up on the call lookup
                "use"       Caller preferences fields to ring for a
   reasonably long period use
                "ignore"    Caller preferences fields to ignore
                "clear"     Whether to clear the location set before adding
                            the new values

       Output:  "success"
   Parameters:  none

       Output:  "notfound"
   Parameters:  none

       Output:  "failure"
   Parameters:  none

   Figure 10: Syntax of time (to the maximum extent that server
   policy allows).

   The second "lookup" node

   Location lookup nodes have one mandatory parameter, and four optional
   parameters. The mandatory parameter is "recurse", which can take two
   values, "yes" or "no". This specifies whether "source", the server should
   automatically attempt to place further call attempts to telephony
   addresses in redirection responses that were returned from source of the
   initial server. Note that if
   lookup. This can either be a URI, or a non-URI value. If the value of "recurse"
   "source" is "yes", a URI, it indicates a location which the
   "redirection" output CPL server can
   query to obtain an object with the script is never taken. In this case this
   output SHOULD NOT be present. The default value text/uri-list media type (see the
   IANA registration of this parameter is
   "yes". type, which also appears in RFC 2483 [16]).

   The third optional parameter query is "ordering". This can have three
   possible values: "parallel", "sequential", and "first-only".  This
   parameter specifies in what order performed verbatim, with no additional information (such
   as URI parameters) added.  The server adds the locations of contained in
   this object to the location set
   should be tried. Parallel asks that they all be tried simultaneously;
   sequential asks that set.

   CPL servers MAY refuse to allow URI-based sources for location
   queries for some or all URI schemes. In this case, they SHOULD reject
   the one with script at script upload time.

        There has been discussion of having CPL servers add URI
        parameters to the highest priority location request, so that (for instance)
        CGI scripts could be tried
   first, the one with used to resolve them. However, the next-highest priority second, and so forth,
   until one succeeds or
        consensus was that this should be a CPL extension, not a
        part of the set is exhausted. First-only instructs base specification.

   Non-URL sources indicate a source not specified by a URL which the
   server can query for addresses to add to try only the highest-priority address in the set, and then
   follow one of the outputs. location set. The priority of locations in a set only
   non-URL source currently defined is
   determined by server policy, though CPL servers SHOULD honor "registration", which specifies
   all the
   "priority" parameter of locations currently registered with the "location" tag. server.

   The default value of this "lookup" node also has four optional parameters. The "timeout"
   parameter is "parallel".

   Once specifies the time, as a proxy operation completes, if control positive integer number of
   seconds, the script is passed on willing to other
   nodes, all locations which have been used are cleared from wait for the
   location set. That is, lookup to be
   performed. If this is not specified, its default value is 30. The
   "clear" parameter specifies whether the location set is emptied of proxyable should be
   cleared before the new locations if are added.

   The other two optional parameters affect the "ordering" was "parallel" or "sequential"; interworking of the
   highest-priority item in CPL
   script with caller preferences and caller capabilities.  By default,
   a CPL server SHOULD invoke the set is removed from appropriate caller preferences
   filtering of the set underlying signalling protocol, if
   "ordering" was "first-only". (In all cases, non-proxyable locations
   such as "http" URIs remain.) In the case of a "redirection" output, corresponding
   information is available. The two parameters "use" and "ignore" allow
   the new addresses script to which modify how the call was redirected are then added to script applies caller preferences
   filtering. The specific meaning of the location set.

7.1.1 Usage values of "proxy" with these parameters is
   signalling-protocol dependent; see Section 6.2.1 for SIP

   For SIP, and Appendix
   B.6 for H.323.

   Lookup has three outputs: "success", "notfound", and "failure".
   Notfound is taken if the best response to 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 a "proxy" node given output is determined by
   not present, script execution terminates and the
   algorithm of default behavior is
   performed.

   Clients SHOULD specify the SIP specification. The node's three outputs correspond to
   the following events:

        "busy" A 486 or 600 response was "success", "notfound", and
   "failure" in that order, so their script complies with the best response received to DTD given
   in Appendix C, but servers MAY accept them in any order.

6.2.1 Usage of "lookup" with SIP

   Caller preferences for SIP are defined in "SIP Caller Preferences and
   Callee Capabilities" [17]. By default, a CPL server SHOULD honor any
   "Accept-Contact" and "Reject-Contact" headers of the original call request.

        "redirection" A 3xx response was
   request, as specified in that document. The two parameters "use" and
   "ignore" allow the best response received script to modify the call request.

        "failure" Any other 4xx, 5xx, or 6xx response was the best
             response received data input to the call request.

        "no-answer" No final response was received to caller
   preferences algorithm. These parameters both take as their arguments
   comma-separated lists of caller preferences parameters. If "use" is
   given, the call request
             before server applies the timeout expired.

   SIP servers SHOULD honor caller preferences resolution algorithm
   only to those preference parameters given in the "q" "use" parameter, and
   ignores all others; if the "ignore" parameter of SIP registrations is given, the server
   ignores the specified parameters, and uses all the output others. Only one
   of "use" and "ignore" can be specified.

   The addr-spec part of the caller preferences lookup algorithm when
   determining location priority.

7.2 Redirect

   Redirect causes is always applied, and
   the script cannot modify it.

   If a SIP server to direct does not support caller preferences and callee
   capabilities, if the calling party to attempt to
   place its call to request does not contain any preferences,
   or if the currently specified set callee's registrations do not contain any capabilities, the
   "use" and "ignore" parameters are ignored.

6.3 Location Removal

   A CPL script can also remove locations from the location set, through
   the use of locations. the "remove-location" node. The syntax of this node is specified
   defined in Figure 13. 11.

   The specific behavior the redirect meaning of this node invokes is dependent on the underlying signalling protocol involved, though its semantics are
   generally applicable.
   protocol.

         Node:  "redirect"  "remove-location"
      Outputs:  None         (no               (next node may follow) follows directly)
    Next node:  None  Any node
   Parameters:  "permanent"  Whether the redirection should be
                                 considered permanent

   Figure 13: Syntax of the "redirect" node

   Redirect immediately terminates execution  "location"         Location to remove
                "param"            Caller preference parameters to apply
                "value"            Value of caller preference parameters

   Figure 11: Syntax of the CPL script, so this "remove-location" node has no outputs and no next node.  It has one parameter,
   "permanent", which specifies whether

   A "remove-location" node removes locations from the result returned should
   indicate that this location set. It
   is primarily useful following a permanent redirection. "lookup" node.  An example of this is
   given in Section 13.8.

   The value "remove-location" node has three optional parameters. The
   parameter "location" gives the URL (or a signalling-protocol-
   dependent URL pattern) of location or locations to be removed from
   the set. If this parameter is either "yes" or "no" not given, all locations, subject to
   the constraints of the other parameters, are removed from the set.

   If param and its default value is "no."

7.2.1 Usage are present, their values are comma-separated
   lists of "redirect" with SIP caller preferences parameters and corresponding values,
   respectively. The SIP server SHOULD send a 3xx class response to a call request
   upon executing a "redirect" tag. If "permanent" was "yes", nth entry in the server
   SHOULD send param list matches the response "301 Moved permanently"; otherwise it SHOULD
   send "302 Moved temporarily".

7.3 Reject

   Reject nodes cause nth entry
   in the server to reject value list. There MUST be the call attempt. Their
   syntax is given in Figure 14. same number of parameters as
   values specified.  The specific behavior they invoke meaning of these parameters is
   dependent on the underlying signalling signalling-
   protocol involved, though
   their semantics are generally applicable.

                    Node:  "reject"
                 Outputs:  None      (no node may follow)
               Next node:  None
              Parameters:  "status"  Status code to return
                           "reason"  Reason phrase to return

   Figure 14: Syntax of the "reject" node

   This immediately terminates execution of the CPL script, so this dependent.

   The "remove-location" node has no outputs and no next node.

   This node has two arguments: "status" and "reason". The "status"
   argument is required, and can take one of explicit output tags. In the values "busy",
   "notfound", "reject", and "error", or a signalling-protocol-defined
   status.

   The "reason" argument optionally allows XML
   syntax, the script to specify a
   reason for XML "remove-location" tag directly encloses the rejection.

7.3.1 next
   node's tag.

6.3.1 Usage of "reject" "remove-location" with SIP

   Servers which implement SIP SHOULD also allow

   For SIP-based CPL servers, the "status" field to
   be a numeric argument corresponding to a SIP status in "remove-location" node has the 4xx, 5xx,
   or 6xx range.

   They SHOULD send same
   effect on the "reason" parameter location set as a "Reject-Contact" header in the SIP reason phrase.

   A suggested mapping caller
   preferences [17]. The value of the named statuses "location" parameter is treated as follows. Servers MAY
   use a different mapping,
   though similar semantics SHOULD be
   preserved.

        "busy": 486 Busy Here

        "notfound": 404 Not Found

        "reject": 603 Decline

        "error": 500 Internal Server Error

8 Non-signalling Operations

   In addition it were the addr-spec field of a Reject-Contact header; thus,
   an absent header is equivalent to an addr-spec of "*" in that
   specification. The "param" and "value" parameters are treated as
   though they appeared in the signalling operations, params field of a Reject-Location header,
   as "; param=value" for each one.

   If the CPL defines several
   operations which do server does not affect support caller preferences and are not dependent on the telephony callee
   capabilities, or if the callee did not supply any preferences, the
   "param" and "value" parameters are ignored.

7 Signalling Operations

   Signalling operation nodes cause signalling events in the underlying
   signalling protocol.

8.1 Mail

   The mail node Three signalling operations are defined:
   "proxy," "redirect," and "reject."

7.1 Proxy

   Proxy causes the server triggering call to be forwarded on to notify a user of the status currently
   specified set of the
   CPL script through electronic mail. Its locations. The syntax of the proxy node is given in
   Figure 15. 12.

   The specific signalling events invoked by the "proxy" node are
   signalling-protocol-dependent, though the general concept should
   apply to any signalling protocol.

         Node:  "mail"  "proxy"
      Outputs:  None      (next  "busy"         Next node follows directly) if call attempt returned "busy"
                "noanswer"     Next node:  Any node if call attempt was not answered
                               before timeout
                "redirection"  Next node if call attempt was redirected
                "failure"      Next node if call attempt failed
                "default"      Default next node for unspecified outputs
   Parameters:  "url"     Mailto url  "timeout"      Time to which try before giving up on the mail should be sent 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:  "redirection"
   Parameters:  none

       Output:  "failure"
   Parameters:  none

       Output:  "default"
   Parameters:  none

   Figure 15: 12: Syntax of the "mail" node

   The "mail" "proxy" node takes one argument:

   After a mailto URL giving the address,
   and any additional desired parameters, of proxy operation has completed, the mail to be sent.  The CPL server sends the message containing chooses the content
   "best" response to the given url; it
   SHOULD also include other status information about the original call
   request and attempt, as defined by the CPL script at signalling
   protocol or the time of server's administrative configuration rules.

   If the notification.

        Using a full mailto URL rather than just an e-mail address
        allows additional e-mail headers call attempt was successful, CPL execution terminates and the
   server proceeds to its default behavior (normally, to allow the call
   to be specified, such as
        <mail
        url="mailto:jones@example.com?subject=lookup%20failed" />.

   Mail nodes have only set up).  Otherwise, the next node corresponding to one possible result, since failure of e-mail
   delivery cannot reliably be known in real-time. Therefore, its XML
   representation does not have the
   "proxy" node's outputs is taken. The "busy" output tags: is followed if the <mail> tag directly
   contains another node tag.

   Note that
   call was busy; "noanswer" is followed if the syntax of XML requires that ampersand characters, "&",
   which are used as parameter separators in "mailto" URLs, be quoted as
   "&amp;" inside call was not answered
   before the "timeout" parameter values (see Section C.12 of [3]).

8.1.1 Suggested Content of Mailed Information

   This section presents suggested guidelines for expired; "redirection" is followed if
   the mail sent as a
   result of call was redirected; and "failure" is followed if the "mail" node, call setup
   failed for requests triggered by SIP. The message
   mailed (triggered by any protocol) SHOULD contain all this
   information, but servers MAY elect to use a different format.

        1. other reason.

   If one of the "mailto" URI did conditions above is true, but the corresponding output
   was not specify a subject header, specified, the
             subject "default" output of the e-mail "proxy" node is "[CPL]"
   followed by the subject
             header of the SIP request. instead. If the URI specified a subject
             header, it there is used instead.

        2.   The "From" field of the e-mail is set to a also no "default" node specified, CPL
   execution terminates and the server
             configured address, overriding any "From" field in returns to its default behavior
   (normally, to forward the
             "mailto" URI.

        3.   Any "Reply-To" header in best response upstream to the URI is honored. If none is
             given, then originator).

        Note: CPL extensions to allow in-call or end-of-call
        operations will require an e-mail-ized version of the origin field of additional output, such as
        "success", to be added.

   If no locations were present in the request is used, set, or if possible (e.g., a SIP "From" header
             with a sip: URI would be converted to an e-mail address by
             stripping the URI scheme).

        4.   If only locations in
   the "mailto" URI specifies set were locations to which the server cannot proxy a body, it is used. If none
             was specified, call (for
   example, "http" URLs), the body SHOULD contain at least "failure" output is taken.

   Proxy has three optional parameters. The "timeout" parameter
   specifies the
             identity time, as a positive integer number of seconds, to wait
   for the caller (both the caller's display name and
             address), the date and call to be completed or rejected; after this time of day, has
   elapsed, the call subject, attempt is terminated and
             if available, the call priority.

   The server SHOULD honor "noanswer" branch is
   taken. If this parameter is not specified, the user's requested languages, and send default value is 20
   seconds if the
   mail notification using an appropriate language and character set.

8.2 Log

   The Log "proxy" node causes has a "noanswer" or "default" output
   specified; otherwise the server SHOULD allow the call to log information about ring for a
   reasonably long period of time (to the call to
   non-volatile storage. Its syntax maximum extent that server
   policy allows).

   The second optional parameter is specified in Figure 16.

   Log takes two arguments, both optional: "name", "recurse", which can take two
   values, "yes" or "no". This specifies whether the
   name of the log, and "comment", which gives a comment about the
   information being logged. Servers SHOULD also include other
   information server should
   automatically attempt to place further call attempts to telephony
   addresses in redirection responses that were returned from the log, such as
   initial server. Note that if the time value of "recurse" is "yes", the logged event,
   information that triggered the call
   "redirection" output to the script is never taken. In this case this
   output SHOULD NOT be logged, present. The default value of this parameter is
   "yes".

   The third optional parameter is "ordering". This can have three
   possible values: "parallel", "sequential", and so forth. Logs
               Node:  "log"
            Outputs:  None       (next node follows directly)
          Next node:  Any node
         Parameters:  "name"     Name "first-only".  This
   parameter specifies in what order the locations of the log file to use
                      "comment"  Comment to location set
   should be placed in log file

   Figure 16: Syntax of tried. Parallel asks that they all be tried simultaneously;
   sequential asks that the "log" node

   are specific to one with the owner of highest priority be tried
   first, the script which logged one with the event. If next-highest priority second, and so forth,
   until one succeeds or the "name" parameter set is not given, exhausted. First-only instructs the event is logged
   server to a standard,
   server-defined log file for try only the script owner. This specification does
   not define how users may retrieve their logs from highest-priority address in the server. set, and then
   follow one of the outputs.  The name priority of locations in a log set is
   determined by server policy, though CPL servers SHOULD honor the
   "priority" parameter of the "location" tag. The default value of this
   parameter is "parallel".

   Once a logical name only, and does not necessarily
   correspond to any physical file proxy operation completes, if control is passed on to other
   nodes, all locations which have been used are cleared from the server. The interpretation
   location set. That is, the location set is emptied of proxyable
   locations if the log file name "ordering" was "parallel" or "sequential"; the
   highest-priority item in the set is server defined, removed from the set if
   "ordering" was "first-only". (In all cases, non-proxyable locations
   such as is "http" URIs remain.) In the case of a mechanism "redirection" output,
   the new addresses to which the call was redirected are then added to
   the location set.

7.1.1 Usage of "proxy" with SIP

   For SIP, the best response to access
   these logs.  The CPL server SHOULD NOT directly map log names
   uninterpreted onto local file names, for security reasons, lest a
   security-critical file be overwritten. "proxy" node is determined by the
   algorithm of the SIP specification. The node's outputs correspond to
   the following events:

        "busy" A correctly operating CPL server SHOULD NOT ever allow 486 or 600 response was the "log"
   event best response received to fail. As such, log nodes can have only one possible result,
   and their XML representation does not have explicit output tags.
             the call request.

        "redirection" A
   CPL <log> tag directly contains another node tag.

9 Subactions

   XML syntax defines a tree. To allow more general 3xx response was the best response received to
             the call flow diagrams,
   and request.

        "failure" Any other 4xx, 5xx, or 6xx response was the best
             response received 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 17.

   Subactions are defined through "subaction" tags. These tags are
   placed in the CPL after any ancillary information (see Section 10)
   but call request.

        "no-answer" No final response was received to the call request
             before any top-level tags. They take one argument: "id", a token
   indicating a script-chosen name for the subaction. The "id" value for
   every "subaction" tag in a script MUST be unique within that script.

   Subactions are called from "sub" tags. The "sub" tag is a "pseudo-
   node": it can be used anyplace in a CPL action that a true node could
   be used. It takes one parameter, "ref", timeout expired.

   SIP servers SHOULD honor the name "q" parameter of SIP registrations and
   the subaction to
   be called. The "sub" tag contains no outputs output of the caller preferences lookup algorithm when
   determining location priority.

7.2 Redirect

   Redirect causes the server to direct the calling party to attempt to
   place its own; control
   instead passes call to the subaction.

               Tag:  "subaction"
           Subtags:  Any node
        Parameters:  "id"              Name currently specified set of locations. The
   syntax of this subaction

       Pseudo-node:  "sub"
           Outputs:  None node is specified in XML tree
        Parameters:  "ref"             Name of subaction to execute Figure 17: Syntax of subactions and "sub" pseudo-nodes

   References to subactions MUST refer to subactions defined before the
   current action. A "sub" tag MUST NOT refer to the action which it
   appears in, or to any action defined later in the CPL script. Top-
   level actions cannot be called from "sub" tags, or through any other
   means. Script servers MUST verify at the time 13.

   The specific behavior the script is submitted
   that no "sub" redirect node refers to any subaction which invokes is not dependent on the
   underlying signalling protocol involved, though its proper
   predecessor.

        Allowing only back-references of subs forbids any sort semantics are
   generally applicable.

   Redirect immediately terminates execution of
        recursion. Recursion would introduce the 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 script, so this
   node has no outputs and no next node.  It has one parameter,
   "permanent", which specifies whether the same CPL
   script. No external links are permitted.

   Subaction IDs are case sensitive.

        If any subsequent version or extension defines external
        linkages, it result returned should probably use
   indicate that this is a different tag, perhaps
        XLink [18]. Ensuring termination in the presence permanent redirection. The value of
        external links this
   parameter is a difficult problem.

10 Ancillary Information

   No ancillary information either "yes" or "no" and its default value is defined in the base CPL specification. If
   ancillary information, not part "no."

7.2.1 Usage of any operation, is found "redirect" with SIP

   The SIP server SHOULD send a 3xx class response to be
   necessary for a CPL extension, it SHOULD be placed within this tag.

   The (trivial) definition call request
             Node:  "redirect"
          Outputs:  None         (no node may follow)
        Next node:  None
       Parameters:  "permanent"  Whether the redirection should be
                                 considered permanent

   Figure 13: Syntax of the ancillary information tag "redirect" node

   upon executing a "redirect" tag. If "permanent" was "yes", the server
   SHOULD send the response "301 Moved permanently"; otherwise it SHOULD
   send "302 Moved temporarily".

7.3 Reject

   Reject nodes cause the server to reject the call attempt. Their
   syntax is given in Figure 18.

        It 14.  The specific behavior they invoke is
   dependent on the underlying signalling protocol involved, though
   their semantics are generally applicable.

                    Node:  "reject"
                 Outputs:  None      (no node may be useful follow)
               Next node:  None
              Parameters:  "status"  Status code to include timezone definitions inside CPL
        scripts directly, rather than referencing them externally
        with "tzid" and "tzurl" parameters. If it is, an extension
        could be defined return
                           "reason"  Reason phrase to include them here.

                               Tag:  "ancillary"
                        Parameters:  None
                           Subtags:  None return

   Figure 18: 14: Syntax of the "ancillary" tag

11 Default Behavior

   When a CPL "reject" node reaches an unspecified output, either because

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

   This node has two arguments: "status" and "reason". The "status"
   argument is not present, or because required, and can take one of the tag is present but does not
   contain values "busy",
   "notfound", "reject", and "error", or a node, the CPL server's behavior is dependent on signalling-protocol-defined
   status.

   The "reason" argument optionally allows the current
   state of script execution. This section gives to specify a
   reason for the operations that
   should be taken in each case.

        no location modifications or signalling operations performed,
             location set empty: Look up the user's location through
             whatever mechanism rejection.

7.3.1 Usage of "reject" with SIP

   Servers which implement SIP SHOULD also allow the server would use if no CPL script
             were "status" field to
   be a numeric argument corresponding to a SIP status in effect. Proxy, redirect, the 4xx, 5xx,
   or 6xx range.

   They SHOULD send a rejection
             message, using whatever policy the server would use "reason" parameter in the
             absence SIP reason phrase.

   A suggested mapping of a CPL script.

        no location modifications or signalling operations performed,
             location set non-empty: (This can only happen for outgoing
             calls.) Proxy the call named statuses is as follows. Servers MAY
   use a different mapping, though similar semantics SHOULD be
   preserved.

        "busy": 486 Busy Here

        "notfound": 404 Not Found

        "reject": 603 Decline

        "error": 500 Internal Server Error

8 Non-signalling Operations

   In addition to the addresses in the location
             set.

        location modifications performed, no signalling operations:
             Proxy or redirect the call, whichever is the server's
             standard policy, to operations, the addresses in CPL defines several
   operations which do not affect and are not dependent on the current location
             set. If telephony
   signalling protocol.

8.1 Mail

   The mail node causes the location set is empty, return "notfound"
             rejection.

        noanswer output of proxy, no timeout given: (This is server to notify a special
             case.)  If user of the "noanswer" output status of a proxy node the
   CPL script through electronic mail. Its syntax is
             unspecified, and no timeout parameter was given in Figure 15.

          Node:  "mail"
       Outputs:  None      (next node follows directly)
     Next node:  Any node
    Parameters:  "url"     Mailto url to which the
             proxy node, the call mail should be allowed to ring for the
             maximum length sent

   Figure 15: Syntax of time allowed by the server (or the
             request, if the request specified "mail" node

   The "mail" node takes one argument: a timeout).

        proxy operation previously taken: Return whatever mailto URL giving the "best"
             response is address,
   and any additional desired parameters, of all accumulated responses to the call mail to
             this point, according be sent.  The
   server sends the message containing the content to the rules of given url; it
   SHOULD also include other status information about the original call
   request and the underlying
             signalling protocol.

12 CPL Extensions

   Servers MAY support additional CPL features beyond those listed in
   this document. Some of script at the extensions which have been suggested are a
   means time of querying how a call has been authenticated; richer control
   over H.323 addressing; end-system or administrator-specific features;
   regular-expression matching for strings and addresses; mid-call or
   end-of-call controls; and the parts notification.

        Using a full mailto URL rather than just an e-mail address
        allows additional e-mail headers to be specified, such as
        <mail
        url="mailto:jones@example.com?subject=lookup%20failed" />.

   Mail nodes have only one possible result, since failure of iCalendar COS recurrence rules
   omitted from time switches.

   CPL extensions are indicated by e-mail
   delivery cannot reliably be known in real-time. Therefore, its XML namespaces [19]. Every extension
   MUST
   representation does not have an appropriate XML namespace assigned to it. All output tags: the <mail> tag directly
   contains another node tag.

   Note that the syntax of XML tags
   and attributes requires that ampersand characters, "&",
   which are part of the extension MUST be appropriately
   qualified so used as to place them within that namespace.

   Tags or attributes parameter separators in "mailto" URLs, be quoted as
   "&amp;" inside parameter values (see Section C.12 of [3]).

8.1.1 Suggested Content of Mailed Information

   This section presents suggested guidelines for the mail sent as a CPL script which are in
   result of the global namespace
   (i.e., not associated with "mail" node, for requests triggered by SIP. The message
   mailed (triggered by any namespace) are equivalent protocol) SHOULD contain all this
   information, but servers MAY elect to tags and
   attributes in use a different format.

        1.   If the CPL namespace "http://www.rfc-
   editor.org/rfc/rfcxxxx.txt".

   A CPL server MUST reject any script which contains "mailto" URI did not specify a reference to subject header, the
             subject of the e-mail is "[CPL]" followed by the subject
             header of the SIP request. If the URI specified a
   namespace which subject
             header, it does not understand. It MUST reject any script
   which contains an extension tag or attribute which is not qualified used instead.

        2.   The "From" field of the e-mail is set to be in an appropriate namespace.

   A a CPL script SHOULD NOT specify server
             configured address, overriding any namespaces it does not use. For
   compatibility "From" field in the
             "mailto" URI.

        3.   Any "Reply-To" header in the URI is honored. If none is
             given, then an e-mail-ized version of the origin field of
             the request is used, if possible (e.g., a SIP "From" header
             with non-namespace-aware parsers, a CPL script SHOULD
   NOT specify sip: URI would be converted to an e-mail address by
             stripping the base CPL namespace for URI scheme).

        4.   If the "mailto" URI specifies a script which does not use
   any extensions.

        A syntax such as

        <extension-switch>
          <extension has="http://www.example.com/foo">
             [extended things]
          </extension>
          <otherwise>
             [non-extended things]
          </otherwise>
        </extension-switch> body, it is used. If none
             was suggested as an alternate way specified, the body SHOULD contain at least the
             identity of handling extensions.

        This would allow scripts to be uploaded to a server without
        requiring a script author to somehow determine which
        extensions a the caller (both the caller's display name and
             address), the date and time of day, the call subject, and
             if available, the call priority.

   The server supports. However, experience
        developing other SHOULD honor the user's requested languages, notably Sieve [20], was that
        this added excessive complexity to languages. and send the
   mail notification using an appropriate language and character set.

8.2 Log

   The
        "extension-switch" tag could, Log node causes the server to log information about the call to
   non-volatile storage. Its syntax is specified in Figure 16.

               Node:  "log"
            Outputs:  None       (next node follows directly)
          Next node:  Any node
         Parameters:  "name"     Name of course, itself the log file to use
                      "comment"  Comment to be defined placed in log file

   Figure 16: Syntax of the "log" node

   Log takes two arguments, both optional: "name", which specifies the
   name of the log, and "comment", which gives a CPL extension.

        It is unfortunately true that XML DTDs, comment about the
   information being logged. Servers SHOULD also include other
   information in the log, such as the CPL DTD
        given in Appendix C, time of the logged event,
   information that triggered the call to be logged, and so forth. Logs
   are not powerful enough specific to encompass
        namespaces, since the base XML specification (which defines
        DTDs) predates owner of the XML namespace specification. XML schemas
        [21] are a work in progress to define a namespace-aware
        method for validating XML documents, as well as improving
        upon DTDs' expressive power in many other ways.

13 Examples

13.1 Example: Call Redirect Unconditional

   The script in Figure 19 is a simple script which redirects all calls logged the event. If
   the "name" parameter is not given, the event is logged to a single fixed location.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

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

   Figure 19: Example Script: Call Redirect Unconditional

13.2 Example: Call Forward Busy/No Answer

   The standard,
   server-defined log file for the script in Figure 20 illustrates some more complex behavior. We
   see an initial proxy attempt to one address, with further operations
   if that fails. We also see owner. This specification does
   not define how several outputs take the same action
   subtree, through users may retrieve their logs from the use of subactions.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

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

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

   Figure 20: Example Script: Call Forward Busy/No Answer

13.3 Example: Call Forward: Redirect and Default

   The script in Figure 21 illustrates further proxy behavior. server.

   The
   server initially tries to proxy to name of a single address. If this attempt log is redirected, a new redirection is generated using the locations
   returned. In all other failure cases for the proxy node, a default
   operation -- forwarding to voicemail -- is performed.

13.4 Example: Call Screening

   The script in Figure 22 illustrates address switches logical name only, and call
   rejection, in the form of a call screening script. Note also that
   because the address-switch lacks an "otherwise" clause, if the
   initial pattern did not match, the script does not define any
   operations. The server therefore proceeds with its default behavior,
   which would presumably be necessarily
   correspond to contact the user.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <location url="sip:jones@jonespc.example.com">
          <proxy>
            <redirection>
              <redirect />
            </redirection>
            <default>
              <location url="sip:jones@voicemail.example.com" >
                 <proxy />
              </location>
            </default>
          </proxy>
       </location>
     </incoming>
   </cpl>

   Figure 21: Example Script: Call Forward: Redirect and Default

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "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

13.5 Example: Priority and Language Routing

   The script in Figure 23 illustrates service selection based any physical file on a
   call's priority value and language settings. If the call request had
   a priority server. The interpretation of "urgent" or higher, the default script behavior is
   performed.  Otherwise, the language field is checked for
   the language
   "es" (Spanish). If it log file name is present, the call server defined, as is proxied to a Spanish-
   speaking operator; other calls are proxied mechanism to an English-speaking
   operator.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx access
   these logs.  The CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <priority-switch>
         <priority greater="urgent" />
         <otherwise>
           <language-switch>
             <language matches="es">
               <location url="sip:spanish@operator.example.com">
                 <proxy />
               </location>
             </language>
             <otherwise>
               <location url="sip:english@operator.example.com">
                 <proxy />
               </location>
             </otherwise>
           </language-switch>
         </otherwise>
       </priority-switch>
     </incoming>
   </cpl>

   Figure 23: Example Script: Priority server SHOULD NOT directly map log names
   uninterpreted onto local file names, for security reasons, lest a
   security-critical file be overwritten.

   A correctly operating CPL server SHOULD NOT ever allow the "log"
   event to fail. As such, log nodes can have only one possible result,
   and Language Routing

13.6 Example: Outgoing Call Screening

   The their XML representation does not have explicit output tags. A
   CPL <log> tag directly contains another node tag.

9 Subactions

   XML syntax defines a 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 24 illustrates a script filtering outgoing
   calls, 17.

   Subactions are defined through "subaction" tags. These tags are
   placed in the form of CPL after any ancillary information (see Section 10)
   but before any top-level tags. They take one argument: "id", a token
   indicating a script-chosen name for the subaction. The "id" value for
   every "subaction" tag in a script which prevent 1-900 (premium) calls
   from being placed. This script also illustrates subdomain matching.

13.7 Example: Time-of-day Routing MUST be unique within that script.

               Tag:  "subaction"
           Subtags:  Any node
        Parameters:  "id"              Name of this subaction

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

   Figure 25 illustrates time-based conditions 17: Syntax of subactions and timezones.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <outgoing>
       <address-switch field="original-destination" subfield="tel">
         <address subdomain-of="1900">
           <reject status="reject"
                   reason="Not allowed to make 1-900 calls." />
         </address>
       </address-switch>
     </outgoing>
   </cpl>

   Figure 24: Example Script: Outgoing Call Screening

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx "sub" pseudo-nodes

   Subactions are called from "sub" tags. The "sub" tag is a "pseudo-
   node": it can be used anyplace in a CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <time-switch tzid="America/New_York"
           tzurl="http://zones.example.com/tz/America/New_York">
         <time dtstart="20000703T090000" duration="PT8H"
               freq="weekly" byday="MO,TU,WE,TH,FR">
           <lookup source="registration">
             <success>
               <proxy />
             </success>
           </lookup>
         </time>
         <otherwise>
           <location url="sip:jones@voicemail.example.com">
             <proxy />
           </location>
         </otherwise>
       </time-switch>
     </incoming>
   </cpl>

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

13.8 Example: Location Filtering

   Figure 26 illustrates filtering operations on the location set. In
   this example, we assume action that version 0.9beta2 of a true node could
   be used. It takes one parameter, "ref", the "Inadequate
   Software SIP User Agent" mis-implements some features, and so we must
   work around its problems. We assume, first, that name of the value subaction to
   be called. The "sub" tag contains no outputs of its
   "feature" parameter in caller preferences is known own; control
   instead passes to be unreliable,
   so we ignore it; we also know that it cannot talk successfully the subaction.

   References to one
   particular mobile device we may have registered, so we remove that
   location from subactions MUST refer to subactions defined before the location set. Once these two operations have been
   completed, call setup is allowed
   current action. A "sub" tag MUST NOT refer to proceed normally.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx the action which it
   appears in, or to any action defined later in the CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <string-switch field="user-agent">
         <string is="Inadequate Software SIP User Agent/0.9beta2">
           <lookup source="registration" ignore="feature">
              <success>
                <remove-location location="sip:me@mobile.provider.net">
                  <proxy />
                </remove-location>
              </success>
           </lookup>
         </string>
       </string-switch>
     </incoming>
   </cpl>

   Figure 26: Example Script: Location Filtering

13.9 Example: Non-signalling Operations

   Figure 27 illustrates non-signalling operations; in particular,
   alerting a user by electronic mail if script. Top-
   level actions cannot be called from "sub" tags, or through any other
   means. Script servers MUST verify at the lookup server failed. The
   primary motivation for having time the "mail" node script is submitted
   that no "sub" node refers to allow this sort any subaction which is not its proper
   predecessor.

        Allowing only back-references of out-of-band notification subs forbids any sort of error conditions, as
        recursion. Recursion would introduce the user might
   otherwise be unaware possibility of any problem.

13.10 Example: Hypothetical Extensions
   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "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 27: Example Script: Non-signalling Operations

   The example in Figure 28 shows a hypothetical extension which
   implements distinctive ringing. The XML namespace
   "http://www.example.com/distinctive-ring" specifies a new node named
   "ring".

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx
        non-terminating or non-decidable CPL 1.0//EN" "cpl.dtd">

   <cpl xmlns="http://www.rfc-editor.org/rfc/rfcXXXX.txt"
        xmlns:dr="http://www.example.com/distinctive-ring">
     <incoming>
       <address-switch field="origin">
         <address is="sip:boss@example.com">
            <dr:ring ringstyle="warble" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 28: Example Script: Hypothetical Distinctive-Ringing Extension
   The example in Figure 29 implements scripts, a hypothetical new attribute for
   address switches, possibility
        our requirements specifically excluded.

   Every sub MUST refer to allow regular-expression matches. It defines a
   new attribute "regex" for subaction ID defined within the standard "address" node. In this
   example, the global namespace is not specified.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx same CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <address-switch field="origin" subfield="user"
           xmlns:re="http://www.example.com/regex">
         <address re:regex="(.*.smith|.*.jones)">
            <reject status="reject"
                    reason="I don't want to talk to Smiths
   script. No external links are permitted.

   Subaction IDs are case sensitive.

        If any subsequent version or Joneses" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 29: Example Script: Hypothetical Regular-Expression Extension

13.11 Example: A Complex Example

   Finally, Figure 30 is extension defines external
        linkages, it should probably use a complex example which shows different tag, perhaps
        XLink [18]. Ensuring termination in the sort presence of
   sophisticated behavior which can be achieved by combining CPL nodes.
   In this case, the user attempts to have his calls reach his desk; if
   he does not answer within
        external links is a small amount of time, calls from his boss
   are forwarded to his mobile phone, and all other calls are directed
   to voicemail.  If the call setup failed, no operation difficult problem.

10 Ancillary Information

   No ancillary information is specified,
   so defined in the server's default behavior is performed.

14 Security Considerations

   The base CPL specification. If
   ancillary information, not part of any operation, is designed to allow services found to be specified in
   necessary for 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 CPL extension, it SHOULD be placed within this tag.

   The (trivial) definition of possible script operations are strictly limited,
   scripts should not the ancillary information tag is given in
   Figure 18.

        It may be able useful to inflict damage upon a include timezone definitions inside CPL server.

   Because scripts can direct users' telephone calls, the method by
   which
        scripts are transmitted from a client to a server MUST directly, rather than referencing them externally
        with "tzid" and "tzurl" parameters. If it is, an extension
        could be
   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

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

     <incoming>
       <location url="sip:jones@phone.example.com">
         <proxy timeout="8">
           <busy>
             <sub ref="voicemail" />
           </busy>
           <noanswer>
             <address-switch field="origin">
               <address is="sip:boss@example.com">
                 <location url="tel:+19175551212">
                   <proxy />
                 </location>
               </address>
               <otherwise>
                 <sub ref="voicemail" />
               </otherwise>
             </address-switch>
           </noanswer>
         </proxy>
       </location>
     </incoming>
   </cpl> defined to include them here.

                               Tag:  "ancillary"
                        Parameters:  None
                           Subtags:  None

   Figure 30: Example Script: A Complex Example

   strongly authenticated. Such 18: Syntax of the "ancillary" tag

11 Default Behavior

   When a method CPL node reaches an unspecified output, either because the
   output tag is not specified in this
   document.

   Script servers SHOULD allow server administrators to control the
   details of what CPL operations are permitted.

15 IANA Considerations

   This document registers present, or because the MIME type application/cpl+xml. See
   Section 3.2.

16 Acknowledgments

   This document was reviewed and commented upon by IETF IP Telephony
   Working Group. We specifically acknowledge tag is present but does not
   contain a node, the following people for
   their help:

   The outgoing call screening script was written by Kenny Hom.

   Paul E. Jones contributed greatly to CPL server's behavior is dependent on the mappings of H.323 addresses.

   The text current
   state of the time-switch script execution. This section was gives the operations that
   should be taken (lightly modified) from
   RFC 2445 [13], by Frank Dawson and Derik Stenerson.

   We drew a good deal of inspiration, notably the language's lack of
   Turing-completeness and in each case.

        no location modifications or signalling operations performed,
             location set empty: Look up the syntax of string matching, from user's location through
             whatever mechanism the
   specification of Sieve [20], a language for user filtering of
   electronic mail messages.

   Thomas F. La Porta and Jonathan Rosenberg had many useful
   discussions, contributions, and suggestions.

   Richard Gumpertz performed server would use if no CPL script
             were in effect. Proxy, redirect, or send a very useful last-minute technical and
   editorial review of rejection
             message, using whatever policy the specification.

A An Algorithm for Resolving Time Switches

   The following algorithm determines whether a given instant falls
   within a repetition server would use in the
             absence of a "time-switch" recurrence. If the pre-
   processing described in Section 5.4.1 has been done, it operates in
   constant time.  Open-source Java code implementing this algorithm is
   available on CPL script.

        no location modifications or signalling operations performed,
             location set non-empty: (This can only happen for outgoing
             calls.) Proxy the world wide web at
   <http://www.cs.columbia.edu/~lennox/Cal-Code/>

   This algorithm is believed call to be correct, but this section is non-
   normative. Section 5.4, and RFC 2445 [13], are the definitive
   definitions of recurrences.

        1.   Compute addresses in the time of location
             set.

        location modifications performed, no signalling operations:
             Proxy or redirect the call, in whichever is the timezone of server's
             standard policy, to the time
             switch.

        2.   If addresses in the call time is earlier than "dtstart", fail NOMATCH.

        3. current location
             set. If the call time location set is less than "duration" after dtstart,
             succeed MATCH.

        4.   Determine the smallest unit specified in a "byxxx" rule or
             by the "freq." Call this the Minimum Unit. Determine the
             previous instant (before the call time) when all the time
             units smaller than the minimum unit are the same as those empty, return "notfound"
             rejection.

        noanswer output of "dtstart." If the minimum unit proxy, no timeout given: (This is a second, this time is
             the same as the instant. special
             case.)  If the minimum unit is "noanswer" output of a minute or
             an hour, the minutes or the minutes proxy node is
             unspecified, and hours,
             respectively, must be no timeout parameter was given to the same as "dtstart". For all other
             minimum units,
             proxy node, the time-of-day must call should be allowed to ring for the same as
             "dtstart."  If the minimum unit is a week,
             maximum length of time allowed by the day-of-the-
             week must be server (or the same as "dtstart." If
             request, if the minimum unit is request specified a month, the day-of-the-month must be the same as
             "dtstart." If timeout).

        proxy operation previously taken: Return whatever the minimum unit "best"
             response is a year, the month and
             day-of-month must both be of all accumulated responses to the same as "dtstart." (Note that call to
             this means it may be necessary point, according to roll back more than one
             minimum unit -- if the minimum unit is a month, then some
             months do not rules of the underlying
             signalling protocol.

12 CPL Extensions

   Servers MAY support additional CPL features beyond those listed in
   this document. Some of the extensions which have been suggested are a 31st (or 30th or 29th) day; if the
             minimum unit is a year, then some years do not have a
             February 29th. In the Gregorian calendar, it is never
             necessary to roll back more than two months if the minimum
             unit is
   means of querying how a month, call has been authenticated; richer control
   over H.323 addressing; end-system or eight years if the minimum unit is a
             year. Between 1904 administrator-specific features;
   regular-expression matching for strings and 2096, it is never necessary to roll
             back more than four years -- the eight-year rollback can
             only occur when the Gregorian calendar "skips" a leap year.

             Call this instant the Candidate Start Time.

        5.   If the time between the candidate start time addresses; mid-call or
   end-of-call controls; and the call
             time is more than the duration, fail NOMATCH.

        6.   If the candidate start time is later than the "until"
             parameter parts of the iCalendar COS recurrence (or the virtual "until"
             computed off-line rules
   omitted from "count") , fail NOMATCH.

        7.   Call the unit of the "freq" parameter of the recurrence the
             Frequency Unit. Determine the frequency unit enclosing the
             Candidate Start Time, time switches.

   CPL extensions are indicated by XML namespaces [19]. Every extension
   MUST have an appropriate XML namespace assigned to it. All XML tags
   and attributes that enclosing "dtstart".
             Calculate the number of frequency units that have passed
             between these two times. If this is not a multiple are part of the
             "interval" parameter, fail NOMATCH.

        8.   For every "byxxx" rule, confirm extension MUST be appropriately
   qualified so as to place them within that namespace.

   Tags or attributes in a CPL script which are in the candidate start
             time matches one of the options specified by that "byxxx"
             rule. If so, succeed MATCH.

        9.   Calculate a previous candidate start time. Repeat until the
             difference between the candidate start time global namespace
   (i.e., not associated with any namespace) are equivalent to tags and
   attributes in the call
             time is more than the duration. If no candidate start time
             has been validated, fail NOMATCH.

B Suggested Usage of CPL with H.323
   This appendix gives a suggested usage of namespace "http://www.rfc-
   editor.org/rfc/rfcxxxx.txt".

   A CPL with H.323 [2].  Study
   Group 16 of the ITU, server MUST reject any script which developed H.323, is proposing contains a reference to work on
   official CPL mappings for that protocol. This section a
   namespace which it does not understand. It MUST reject any script
   which contains an extension tag or attribute which is therefore not normative.

B.1 Usage of "address-switch" with H.323

   Address switches are specified in Section 5.1. This section specifies
   the mapping between H.323 messages and the fields and subfields of
   address-switches

   For H.323, the "origin" address corresponds qualified
   to the alias addresses be in an appropriate namespace.

   A CPL script SHOULD NOT specify any namespaces it does not use. For
   compatibility with non-namespace-aware parsers, a CPL script SHOULD
   NOT specify the "sourceAddress" field of the "Setup-UUIE" user-user information
   element, and to the Q.931 [22] information element "Calling party
   number." If both fields are present, or if multiple aliases addresses base CPL namespace for "sourceAddress" are present, which one has priority is a matter
   of local server policy; the server SHOULD script which does not use the same resolution
   any extensions.

        A syntax such as
   it would use for routing decisions in this case. Similarly, the
   "destination" address corresponds to the alias addresses
        <extension-switch>
          <extension has="http://www.example.com/foo">
             [extended things]
          </extension>
          <otherwise>
             [non-extended things]
          </otherwise>
        </extension-switch>

        was suggested as an alternate way of the
   "destinationAddress" field, and handling extensions.
        This would allow scripts to the Q.931 information element
   "Called party number."

   The "original-destination" address corresponds be uploaded to the "Redirecting
   number" Q.931 information element, if it is present; otherwise it is
   the same as the "destination" address. a server without
        requiring a script author to somehow determine which
        extensions a server supports. However, experience
        developing other languages, notably Sieve [20], was that
        this added excessive complexity to languages. The mapping of H.323 addresses into subfields depends on the type
        "extension-switch" tag could, of
   the alias address. An additional subfield type, "alias-type", is course, itself be defined for H.323 servers, corresponding to the type of
        in a CPL extension.

        It is unfortunately true that XML DTDs, such as the address.
   Possible values CPL DTD
        given in Appendix C, are "dialedDigits", "h323-ID", "url-ID",
   "transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE".
   If future versions of not powerful enough to encompass
        namespaces, since the H.323 base XML specification define additional types
   of alias addresses, those names MAY also be used.

   In versions of H.323 prior (which defines
        DTDs) predates the XML namespace specification. XML schemas
        [21] are a work in progress to version 4, "dialedDigits" was known define a namespace-aware
        method for validating XML documents, as
   "e164". The two names SHOULD be treated well as synonyms. improving
        upon DTDs' expressive power in many other ways.

13 Examples

13.1 Example: Call Redirect Unconditional

   The value of the "address-type" subfield for H.323 messages is "h323"
   unless the alias type is "url-ID" and the URL scheme is something
   other than h323; script in this case the address-type Figure 19 is the URL scheme, as
   specified a simple script which redirects all calls
   to a single fixed location.

13.2 Example: Call Forward Busy/No Answer

   The script in Section 5.1.1 for SIP.

   An H.323-aware CPL server SHOULD map the address subfields from the
   primary alias used for routing. It MAY also map subfields from other
   aliases, Figure 20 illustrates some more complex behavior. We
   see an initial proxy attempt to one address, with further operations
   if subfields in the primary address are not present.

   The following mappings are used for H.323 alias types:

        dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and
             "user" subfields are the string of digits, as is the
             "entire-address" form. The "host" and "port" subfields are
             not present.

        url-ID: that fails. We also see how several outputs take the same mappings are used as for SIP, in Section 5.1.1.

        h323-ID: the "user" field is action
   subtree, through the string use of characters, as is the
             "entire-address" form. All other subfields are not present.

        email-ID: the "user" subactions.

13.3 Example: Call Forward: Redirect and "host" subfields are set to the
             corresponding parts of the e-mail address. Default

   The "port" and
             "tel" subfields are not present. script in Figure 21 illustrates further proxy behavior.  The "entire-address" form
             corresponds
   server initially tries to the entire e-mail address.

        transportID: if the TransportAddress is of type "ipAddress,"
             "ipSourceRoute," or "ip6Address," the "host" subfield is
             set proxy to the "ip" element of the sequence, translated into
             the standard IPv4 or IPv6 textual representation, and the
             "port" subfield a single address. If this attempt
   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

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

   Figure 19: Example Script: Call Redirect Unconditional

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

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

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

   Figure 20: Example Script: Call Forward Busy/No Answer

   is set to redirected, a new redirection is generated using the "port" element of locations
   returned. In all other failure cases for the
             sequence represented in decimal. The "tel" and "user"
             fields are not present. The "entire-address" form proxy node, a default
   operation -- forwarding to voicemail -- is not
             defined. performed.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <location url="sip:jones@jonespc.example.com">
          <proxy>
            <redirection>
              <redirect />
            </redirection>
            <default>
              <location url="sip:jones@voicemail.example.com" >
                 <proxy />
              </location>
            </default>
          </proxy>
       </location>
     </incoming>
   </cpl>

   Figure 21: Example Script: Call Forward: Redirect and Default

13.4 Example: Call Screening

   The representation script in Figure 22 illustrates address switches and mapping call
   rejection, in the form of transport
             addresses is a call screening script. Note also that
   because the address-switch lacks an "otherwise" clause, if the
   initial pattern did not defined for non-IP addresses.

   H.323 version 4 [23] and match, the Internet-Draft draft-levin-iptel-h323-
   url-scheme-00 [24] script does not define a "h323" URI scheme.  This appendix defines
   a mapping for these URIs onto the CPL "address-switch" subfields, as
   given in Section 5.1.  Neither of these documents has yet been
   formally published in a final form, so this appendix is non-
   normative.

   For h323 URIs, the the "user", "host", and "port" subfields are set
   to the corresponding parts of the H.323 URL. The "tel" subfield is
   not present. any
   operations. The "entire-address" form corresponds server therefore proceeds with its default behavior,
   which would presumably be to contact the entire URI.

   This mapping MAY be used both for h323 URIs in an h323 "url-ID"
   address alias, user.

13.5 Example: Priority and for h323 URIs Language Routing

   The script in SIP messages.

B.2 Usage Figure 23 illustrates service selection based on a
   call's priority value and language settings. If the call request had
   a priority of "string-switch" with H.323

   For H.323, "urgent" or higher, the "string-switch" node (see Section 5.2) default script behavior is used as
   follows. The field "display" corresponds to the Q.931 information
   element of
   performed.  Otherwise, the same name, copied verbatim. The fields "subject",
   "organization", and "user-agent" are not used and are never present.

        The "display" IE language field is conventionally used checked for Caller-ID
        purposes, so arguably it should be mapped to the "display"
        subfield of an "address-match" with the field "originator".
        However, since a) language
   "es" (Spanish). If it is a message-level information
        element, not an address-level one, and b) the Q.931
        specification [22] says only that "[t]he purpose of present, the
        Display information element call is proxied to supply display
        information that may be displayed by the user," it seems to
        be more appropriate to allow it to be matched in a
        "string-switch" instead.

B.3 Usage of "language-switch" with H.323

   The language-ranges for the "language-switch" switch are obtained
   from the H.323 UUIE "language". The switch is not-present if the
   initial message did not contain this UUIE.

B.4 Usage of "priority-switch" with H.323

   All H.323 messages Spanish-
   speaking operator; other calls are considered proxied to have priority "normal" for the
   purpose of a priority switch (see Section 5.5).

B.5 Usage of "location" with H.323

   Locations in explicit location nodes (Section 6.1) are specified as
   URLs. Therefore, all locations added an English-speaking
   operator.

13.6 Example: Outgoing Call Screening
   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "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

   The script in this manner are interpreted
   as being of alias type "url-ID" Figure 24 illustrates a script filtering outgoing
   calls, in H.323.

   Specifications the form of other H.323 address alias types will require a script which prevent 1-900 (premium) calls
   from being placed. This script also illustrates subdomain matching.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL
   extension (see Section 12).

B.6 Usage of "lookup" with H.323

   For location lookup nodes (Section 6.2), the "registration" lookup
   source corresponds 1.0//EN" "cpl.dtd">

   <cpl>
     <outgoing>
       <address-switch field="original-destination" subfield="tel">
         <address subdomain-of="1900">
           <reject status="reject"
                   reason="Not allowed to the locations registered with the server using
   "RAS" messages.

   As H.323 currently has no counterpart of SIP caller preferences and
   callee capabilities, the "use" make 1-900 calls." />
         </address>
       </address-switch>
     </outgoing>
   </cpl>

   Figure 24: Example Script: Outgoing Call Screening

13.7 Example: Time-of-day Routing

   Figure 25 illustrates time-based conditions and "ignore" parameters of timezones.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <priority-switch>
         <priority greater="urgent" />
         <otherwise>
           <language-switch>
             <language matches="es">
               <location url="sip:spanish@operator.example.com">
                 <proxy />
               </location>
             </language>
             <otherwise>
               <location url="sip:english@operator.example.com">
                 <proxy />
               </location>
             </otherwise>
           </language-switch>
         </otherwise>
       </priority-switch>
     </incoming>
   </cpl>

   Figure 23: Example Script: Priority and Language Routing

13.8 Example: Location Filtering

   Figure 26 illustrates filtering operations on the
   "lookup" node are ignored.

B.7 Usage of "remove-location" with H.323

   For location removal nodes (Section 6.3), only literal URLs can be
   removed. No URL patterns are defined.

   As H.323 currently has no counterpart set. In
   this example, we assume that version 0.9beta2 of the "Inadequate
   Software SIP caller preferences User Agent" mis-implements some features, and
   callee capabilities, so we must
   work around its problems. We assume, first, that the "param" and "value" parameters value of its
   "feature" parameter in caller preferences is known to be unreliable,
   so we ignore it; we also know that it cannot talk successfully to one
   particular mobile device we may have registered, so we remove that
   location from the
   "remove-location" node are ignored.

C The XML DTD for CPL

   This section includes location set. Once these two operations have been
   completed, call setup is allowed to proceed normally.

13.9 Example: Non-signalling Operations

   Figure 27 illustrates non-signalling operations; in particular,
   alerting a full DTD describing user by electronic mail if the XML syntax of lookup server failed. The
   primary motivation for having the
   CPL.  Every script submitted "mail" node is to a CPL server SHOULD comply with allow this
   DTD.  However, sort
   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL servers MAY allow minor variations from it,
   particularly in the ordering 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <time-switch tzid="America/New_York"
           tzurl="http://zones.example.com/tz/America/New_York">
         <time dtstart="20000703T090000" duration="PT8H"
               freq="weekly" byday="MO,TU,WE,TH,FR">
           <lookup source="registration">
             <success>
               <proxy />
             </success>
           </lookup>
         </time>
         <otherwise>
           <location url="sip:jones@voicemail.example.com">
             <proxy />
           </location>
         </otherwise>
       </time-switch>
     </incoming>
   </cpl>

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

   of out-of-band notification of error conditions, as the outputs user might
   otherwise be unaware of nodes. Note that
   compliance with this DTD is not any problem.

13.10 Example: Hypothetical Extensions

   The example in Figure 28 shows a sufficient condition hypothetical extension which
   implements distinctive ringing. The XML namespace
   "http://www.example.com/distinctive-ring" specifies a new node named
   "ring".

   The example in Figure 29 implements a hypothetical new attribute for
   correctness of
   address switches, to allow regular-expression matches. It defines a CPL script, as many of
   new attribute "regex" for the conditions described in standard "address" node. In this specification are
   example, the global namespace is not expressible in DTD syntax. specified.

13.11 Example: A Complex Example
   <?xml version="1.0" encoding="US-ASCII" ?>

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

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

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

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

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

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

   <!-- Nodes are one of the above four categories, or a 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;|%Sub;)?' >

   <!-- Switches: choices a
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL script can make. -->

   <!-- All switches 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <string-switch field="user-agent">
         <string is="Inadequate Software SIP User Agent/0.9beta2">
           <lookup source="registration" ignore="feature">
              <success>
                <remove-location location="sip:me@mobile.provider.net">
                  <proxy />
                </remove-location>
              </success>
           </lookup>
         </string>
       </string-switch>
     </incoming>
   </cpl>

   Figure 26: Example Script: Location Filtering

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "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 27: Example Script: Non-signalling Operations
   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl xmlns="http://www.rfc-editor.org/rfc/rfcXXXX.txt"
        xmlns:dr="http://www.example.com/distinctive-ring">
     <incoming>
       <address-switch field="origin">
         <address is="sip:boss@example.com">
            <dr:ring ringstyle="warble" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 28: Example Script: Hypothetical Distinctive-Ringing Extension

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <address-switch field="origin" subfield="user"
           xmlns:re="http://www.example.com/regex">
         <address re:regex="(.*.smith|.*.jones)">
            <reject status="reject"
                    reason="I don't want to talk to Smiths or Joneses" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 29: Example Script: Hypothetical Regular-Expression Extension

   Finally, Figure 30 is a complex example which shows the sort of
   sophisticated behavior which can be achieved by combining CPL nodes.
   In this case, the user attempts to have an 'otherwise' output. -->
   <!ELEMENT otherwise ( %Node; ) >

   <!-- his calls reach his desk; if
   he does not answer within a small amount of time, calls from his boss
   are forwarded to his mobile phone, and all other calls are directed
   to voicemail.  If the call setup failed, no operation is specified,
   so the server's default behavior is performed.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

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

     <incoming>
       <location url="sip:jones@phone.example.com">
         <proxy timeout="8">
           <busy>
             <sub ref="voicemail" />
           </busy>
           <noanswer>
             <address-switch field="origin">
               <address is="sip:boss@example.com">
                 <location url="tel:+19175551212">
                   <proxy />
                 </location>
               </address>
               <otherwise>
                 <sub ref="voicemail" />
               </otherwise>
             </address-switch>
           </noanswer>
         </proxy>
       </location>
     </incoming>
   </cpl>

   Figure 30: Example Script: A Complex Example

14 Security 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 operations 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 operations are permitted.

15 IANA Considerations

   This document registers the MIME type application/cpl+xml. See
   Section 3.2.

16 Acknowledgments

   This document was reviewed and commented upon by IETF IP Telephony
   Working Group. We specifically acknowledge the following people for
   their help:

   The outgoing call screening script was written by Kenny Hom.

   Paul E. Jones contributed greatly to the mappings of H.323 addresses.

   The text of the time-switch section was taken (lightly modified) from
   RFC 2445 [13], by Frank Dawson and Derik Stenerson.

   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 [20], a language for user filtering of
   electronic mail messages.

   Thomas F. La Porta and Jonathan Rosenberg had many useful
   discussions, contributions, and suggestions.

   Richard Gumpertz performed a very useful last-minute technical and
   editorial review of the specification.

A An Algorithm for Resolving Time Switches

   The following algorithm determines whether a given instant falls
   within a repetition of a "time-switch" recurrence. If the pre-
   processing described in Section 5.4.1 has been done, it operates in
   constant time. Open-source Java code implementing this algorithm is
   available on the world wide web at
   <http://www.cs.columbia.edu/~lennox/Cal-Code/>

   This algorithm is believed to be correct, but this section is non-
   normative. Section 5.4, and RFC 2445 [13], are the definitive
   definitions of recurrences.

        1.   Compute the time of the call, in the timezone of the time
             switch.

        2.   If the call time is earlier than "dtstart", fail NOMATCH.

        3.   If the call time is less than "duration" after dtstart,
             succeed MATCH.

        4.   Determine the smallest unit specified in a "byxxx" rule or
             by the "freq." Call this the Minimum Unit. Determine the
             previous instant (before or equal to the call time) when
             all the time units smaller than the minimum unit are the
             same as those of "dtstart." If the minimum unit is a
             second, this time is the same as the instant. If the
             minimum unit is a minute or an hour, the minutes or the
             minutes and hours, respectively, must be the same as
             "dtstart". For all other minimum units, the time-of-day
             must be the same as "dtstart." If the minimum unit is a
             week, the day-of-the-week must be the same as "dtstart." If
             the minimum unit is a month, the day-of-the-month must be
             the same as "dtstart." If the minimum unit is a year, the
             month and day-of-month must both be the same as "dtstart."
             (Note that this means it may be necessary to roll back more
             than one minimum unit -- if the minimum unit is a month,
             then some months do not have a 31st (or 30th or 29th) day;
             if the minimum unit is a year, then some years do not have
             a February 29th. In the Gregorian calendar, it is never
             necessary to roll back more than two months if the minimum
             unit is a month, or eight years if the minimum unit is a
             year. Between 1904 and 2096, it is never necessary to roll
             back more than four years -- the eight-year rollback can
             only occur when the Gregorian calendar "skips" a leap year.

             Call this instant the Candidate Start Time.

        5.   If the time between the candidate start time and the call
             time is more than the duration, fail NOMATCH.

        6.   If the candidate start time is later than the "until"
             parameter of the recurrence (or the virtual "until"
             computed off-line from "count"), fail NOMATCH.

        7.   Call the unit of the "freq" parameter of the recurrence the
             Frequency Unit. Determine the frequency unit enclosing the
             Candidate Start Time, and that enclosing "dtstart".
             Calculate the number of frequency units that have passed
             between these two times. If this is not a multiple of the
             "interval" parameter, fail NOMATCH.

        8.   For every "byxxx" rule, confirm that the candidate start
             time matches one of the options specified by that "byxxx"
             rule. If so, succeed MATCH.

        9.   Calculate a previous candidate start time. Repeat until the
             difference between the candidate start time and the call
             time is more than the duration. If no candidate start time
             has been validated, fail NOMATCH.

B Suggested Usage of CPL with H.323

   This appendix gives a suggested usage of CPL with H.323 [2].  Study
   Group 16 of the ITU, which developed H.323, is proposing to work on
   official CPL mappings for that protocol. This section is therefore
   not normative.

B.1 Usage of "address-switch" with H.323

   Address switches are specified in Section 5.1. This section specifies
   the mapping between H.323 messages and the fields and subfields of
   address-switches

   For H.323, the "origin" address corresponds to the alias addresses in
   the "sourceAddress" field of the "Setup-UUIE" user-user information
   element, and to the Q.931 [22] information element "Calling party
   number." If both fields are present, or if multiple aliases addresses
   for "sourceAddress" are present, which one has priority is a matter
   of local server policy; the server SHOULD use the same resolution as
   it would use for routing decisions in this case. Similarly, the
   "destination" address corresponds to the alias addresses of the
   "destinationAddress" field, and to the Q.931 information element
   "Called party number."

   The "original-destination" address corresponds to the "Redirecting
   number" Q.931 information element, if it is present; otherwise it is
   the same as the "destination" address.

   The mapping of H.323 addresses into subfields depends on the type of
   the alias address. An additional subfield type, "alias-type", is
   defined for H.323 servers, corresponding to the type of the address.
   Possible values are "dialedDigits", "h323-ID", "url-ID",
   "transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE".
   If future versions of the H.323 specification define additional types
   of alias addresses, those names MAY also be used.

   In versions of H.323 prior to version 4, "dialedDigits" was known as
   "e164". The two names SHOULD be treated as synonyms.

   The value of the "address-type" subfield for H.323 messages is "h323"
   unless the alias type is "url-ID" and the URL scheme is something
   other than h323; in this case the address-type is the URL scheme, as
   specified in Section 5.1.1 for SIP.

   An H.323-aware CPL server SHOULD map the address subfields from the
   primary alias used for routing. It MAY also map subfields from other
   aliases, if subfields in the primary address are not present.

   The following mappings are used for H.323 alias types:

        dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and
             "user" subfields are the string of digits, as is the
             "entire-address" form. The "host" and "port" subfields are
             not present.

        url-ID: the same mappings are used as for SIP, in Section 5.1.1.

        h323-ID: the "user" field is the string of characters, as is the
             "entire-address" form. All other subfields are not present.

        email-ID: the "user" and "host" subfields are set to the
             corresponding parts of the e-mail address. The "port" and
             "tel" subfields are not present. The "entire-address" form
             corresponds to the entire e-mail address.

        transportID: if the TransportAddress is of type "ipAddress,"
             "ipSourceRoute," or "ip6Address," the "host" subfield is
             set to the "ip" element of the sequence, translated into
             the standard IPv4 or IPv6 textual representation, and the
             "port" subfield is set to the "port" element of the
             sequence represented in decimal. The "tel" and "user"
             fields are not present. The "entire-address" form is not
             defined. The representation and mapping of transport
             addresses is not defined for non-IP addresses.

   H.323 version 4 [2] defines an "h323" URI scheme.  This appendix
   defines a mapping for these URIs onto the CPL "address-switch"
   subfields, as given in Section 5.1.  This definition is also
   available as RFC YYYY [23], which is an excerpt from the H.323
   specification. [Note to RFC Editor: "RFC YYYY" indicates the
   publication as an RFC of draft-levin-iptel-h323-url-scheme-04, which
   is currently in the RFC Editor's Queue.]

   For h323 URIs, the the "user", "host", and "port" subfields are set
   to the corresponding parts of the H.323 URL. The "tel" subfield is
   not present. The "entire-address" form corresponds to the entire URI.

   This mapping MAY be used both for h323 URIs in an h323 "url-ID"
   address alias, and for h323 URIs in SIP messages.

B.2 Usage of "string-switch" with H.323

   For H.323, the "string-switch" node (see Section 5.2) is used as
   follows. The field "display" corresponds to the Q.931 information
   element of the same name, copied verbatim. The fields "subject",
   "organization", and "user-agent" are not used and are never present.

        The "display" IE is conventionally used for Caller-ID
        purposes, so arguably it should be mapped to the "display"
        subfield of an "address-match" with the field "originator".
        However, since a) it is a message-level information
        element, not an address-level one, and b) the Q.931
        specification [22] says only that "[t]he purpose of the
        Display information element is to supply display
        information that may be displayed by the user," it seems to
        be more appropriate to allow it to be matched in a
        "string-switch" instead.

B.3 Usage of "language-switch" with H.323

   The language-ranges for the "language-switch" switch are obtained
   from the H.323 UUIE "language". The switch is not-present if the
   initial message did not contain this UUIE.

B.4 Usage of "priority-switch" with H.323

   All switches can H.323 messages are considered to have priority "normal" for the
   purpose of a 'not-present' output. -->
   <!ELEMENT not-present ( %Node; ) >

   <!-- Address-switch makes choices based on addresses. -->
   <!ELEMENT address-switch ( (address|not-present)*, otherwise? ) >
   <!-- <not-present> must appear at most once -->
   <!ATTLIST address-switch
      field         CDATA    #REQUIRED
      subfield      CDATA    #IMPLIED
   >
   <!ELEMENT address ( %Node; ) >

   <!ATTLIST priority switch (see Section 5.5).

B.5 Usage of "location" with H.323

   Locations in explicit location nodes (Section 6.1) are specified as
   URLs. Therefore, all locations added in this manner are interpreted
   as being of alias type "url-ID" in H.323.

   Specifications of other H.323 address
      is            CDATA    #IMPLIED
      contains      CDATA    #IMPLIED
      subdomain-of  CDATA    #IMPLIED
   > <!-- Exactly one alias types will require a CPL
   extension (see Section 12).

B.6 Usage of these three attributes must appear -->

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

   <!ELEMENT string-switch ( (string|not-present)*, otherwise? ) >
   <!-- <not-present> must appear at most once -->
   <!ATTLIST string-switch
      field         CDATA    #REQUIRED
   >

   <!ELEMENT string ( %Node; ) >
   <!ATTLIST string
      is            CDATA    #IMPLIED
      contains      CDATA    #IMPLIED
   >  <!-- Exactly one "lookup" with H.323

   For location lookup nodes (Section 6.2), the "registration" lookup
   source corresponds to the locations registered with the server using
   "RAS" messages.

   As H.323 currently has no counterpart of these two attributes must appear -->

   <!-- Language-switch makes choices based on SIP caller preferences and
   callee capabilities, the originator's preferred
        languages. -->

   <!ELEMENT language-switch ( (language|not-present)*, otherwise? ) >
   <!-- <not-present> must appear at most once -->

   <!ELEMENT language ( %Node; ) >
   <!ATTLIST language
      matches      CDATA     #REQUIRED
   >

   <!-- Time-switch makes choices based on "use" and "ignore" parameters of the current time. -->

   <!ELEMENT time-switch ( (time|not-present)*, otherwise? ) >
   <!ATTLIST time-switch
      tzid          CDATA    #IMPLIED
      tzurl         CDATA    #IMPLIED
   >

   <!ELEMENT time ( %Node; ) >

   <!-- Exactly one
   "lookup" node are ignored.

B.7 Usage of "remove-location" with H.323

   For location removal nodes (Section 6.3), only literal URLs can be
   removed. No URL patterns are defined.

   As H.323 currently has no counterpart of SIP caller preferences and
   callee capabilities, the two attributes "dtend" "param" and "duration"
        must occur. -->
   <!-- The value "value" parameters of "freq" is (daily|weekly|monthly|yearly).  It is
           case-insensitive, so it is not given as the
   "remove-location" node are ignored.

C The XML DTD for CPL

   This section includes a full DTD switch. -->
   <!-- None describing the XML syntax of the attributes following freq are meaningful unless freq
            appears. -->
   <!-- The value
   CPL.  Every script submitted to a CPL server SHOULD comply with this
   DTD.  However, CPL servers MAY allow minor variations from it,
   particularly in the ordering of "wkst" is (MO|TU|WE|TH|FR|SA|SU).  It is
           case-insensitive, so it the outputs of nodes. Note that
   compliance with this DTD is not given as a sufficient condition for
   correctness of a CPL script, as many of the conditions described in
   this specification are not expressible in DTD switch. syntax.

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

   <!-- Nodes. -->
   <!ATTLIST time
      dtstart       CDATA  #REQUIRED
      dtend         CDATA  #IMPLIED
      duration      CDATA  #IMPLIED
      freq          CDATA  #IMPLIED
      until         CDATA  #IMPLIED
      interval      CDATA  "1"
      byday         CDATA  #IMPLIED
      bymonthday    CDATA  #IMPLIED
      byyearday     CDATA  #IMPLIED
      byweekno      CDATA  #IMPLIED
      bymonth       CDATA  #IMPLIED
      wkst          CDATA  "MO"
   >
   <!-- Priority-switch makes choices based on message priority. Switch nodes -->

   <!ELEMENT priority-switch ( (priority|not-present)*, otherwise? )
   <!ENTITY % Switch 'address-switch|string-switch|language-switch|
                      time-switch|priority-switch' >

   <!-- <not-present> must appear at most once Location nodes -->
   <!ENTITY % PriorityVal '(emergency|urgent|normal|non-urgent)' Location 'location|lookup|remove-location' >

   <!ELEMENT priority ( %Node; )

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

   <!-- Exactly one of these three attributes must appear Other actions -->
   <!ATTLIST priority
      less          %PriorityVal;  #IMPLIED
      greater       %PriorityVal;  #IMPLIED
      equal         CDATA          #IMPLIED
   <!ENTITY % OtherAction 'mail|log' >

   <!-- Locations: ways to specify the location a subsequent action
        (proxy, redirect) will attempt Links to contact. subactions -->
   <!ENTITY % Clear  'clear (yes|no) "no"' >

   <!ELEMENT location ( %Node; ) >
   <!ATTLIST location
      url           CDATA    #REQUIRED
      priority      CDATA    #IMPLIED
      %Clear; Sub 'sub' >

   <!-- priority is in Nodes are one of the range  0.0 - 1.0.  Its default value SHOULD
         be 1.0 -->

   <!ELEMENT lookup ( success?,notfound?,failure? ) >
   <!ATTLIST lookup
     source         CDATA     #REQUIRED
     timeout        CDATA     "30"
     use            CDATA     #IMPLIED
     ignore         CDATA     #IMPLIED
     %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 above four categories, or a 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;|%Sub;)?' >

   <!-- Signalling Actions: call-signalling actions the Switches: choices a CPL script can
        take. make. -->

   <!ELEMENT proxy ( busy?,noanswer?,redirection?,failure?,default? ) >

   <!-- The default value of timeout is "20" if the <noanswer> output
        exists. All switches can have an 'otherwise' output. -->
   <!ATTLIST proxy
      timeout       CDATA    #IMPLIED
      recurse       (yes|no) "yes"
      ordering      (parallel|sequential|first-only) "parallel"
   >

   <!ELEMENT busy ( %Node; ) >
   <!ELEMENT noanswer ( %Node; ) >
   <!ELEMENT redirection otherwise ( %Node; ) >

   <!-- "failure" repeats from lookup, above. All switches can have a 'not-present' output. -->
   <!ELEMENT default not-present ( %Node; ) >

   <!ELEMENT redirect EMPTY >
   <!ATTLIST redirect
      permanent     (yes|no) "no"
   >

   <!-- Statuses we can return Address-switch makes choices based on addresses. -->
   <!ELEMENT reject EMPTY address-switch ( address*, (not-present, address*)?,
                              otherwise? ) >
   <!-- The value of "status" is (busy|notfound|reject|error), or a SIP
        4xx-6xx status. <not-present> must appear at most once -->
   <!ATTLIST reject
      status address-switch
      field         CDATA    #REQUIRED
      reason
      subfield      CDATA    #IMPLIED
   >

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

   <!ELEMENT mail address ( %Node; ) >

   <!ATTLIST mail
      url address
      is            CDATA    #REQUIRED
   >

   <!ELEMENT log ( %Node; ) >
   <!ATTLIST log
      name    #IMPLIED
      contains      CDATA    #IMPLIED
      comment
      subdomain-of  CDATA    #IMPLIED
   > <!-- Calls to subactions. -->

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

   <!-- Ancillary data Exactly one of these three attributes must appear -->

   <!ENTITY % Ancillary 'ancillary?' >

   <!ELEMENT ancillary EMPTY >

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

   <!ENTITY % Subactions 'subaction*' >

   <!ELEMENT subaction string-switch ( %Node; )>
   <!ATTLIST subaction
      id            ID       #REQUIRED string*, (not-present, string*)?,
                             otherwise? ) >
   <!-- Top-level actions -->

   <!ENTITY % TopLevelActions 'outgoing?,incoming?' <not-present> must appear at most once -->
   <!ATTLIST string-switch
      field         CDATA    #REQUIRED
   >

   <!ELEMENT outgoing ( %Node; )>

   <!ELEMENT incoming string ( %Node; )> ) >
   <!ATTLIST string
      is            CDATA    #IMPLIED
      contains      CDATA    #IMPLIED
   >  <!-- The top-level element Exactly one of these two attributes must appear -->

   <!-- Language-switch makes choices based on the script. originator's preferred
        languages. -->

   <!ELEMENT cpl language-switch ( %Ancillary;,%Subactions;,%TopLevelActions; language*, (not-present, language*)?,
                               otherwise? ) >

D Changes from Earlier Versions

        [Note to RFC Editor: please remove this appendix before
        publication as an RFC.]

D.1 Changes from Draft -04

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

        o Broke out
   <!-- <not-present> must appear at most once -->

   <!ELEMENT language switches into their own switch node.

        o Restored the full iCalendar COS recurrence specification.
          Added text describing the consequences of this for
          implementors, and expanded somewhat ( %Node; ) >
   <!ATTLIST language
      matches      CDATA     #REQUIRED
   >

   <!-- Time-switch makes choices based on the recurrence
          algorithm.

        o Clarified when time zones are resolved.

        o Spelled out "iCalendar" rather than abbreviating it "iCal."

        o Clarified some points about host and port matching.

        o Whole-address matching in SIP uses the standard SIP URL-match
          rules.

        o Specified that proxy and lookup timeouts are positive integer
          number of seconds.

        o Specified that "subaction" "id" parameters must be unique.

        o Corrected example scripts' namespace and DTD references
          indicating older drafts of this document.

        o Deleted an unused subaction from the "Call Forward: Redirect
          and Default" example script.

        o Made empty switches legal in the DTD.

        o Made the legal values for the "proxy" "ordering" parameter
          explicit in the DTD.

        o Made the "success" output current time. -->

   <!ELEMENT time-switch ( time*, (not-present, time*)?, otherwise? ) >
   <!ATTLIST time-switch
      tzid          CDATA    #IMPLIED
      tzurl         CDATA    #IMPLIED
   >

   <!ELEMENT time ( %Node; ) >

   <!-- Exactly one of "lookup" optional in the DTD. two attributes "dtend" and "duration"
        must occur. -->
   <!-- The value of "freq" is (daily|weekly|monthly|yearly).  It
          can trigger is
           case-insensitive, so it is not given as a default action, just like anything else.

        o Clarified that DTD switch. -->
   <!-- None of the time-switch resolution algorithm attributes following freq are meaningful unless freq
            appears. -->
   <!-- The value of "wkst" is non-
          normative.

        o Updated references to previously-unpublished RFCs, now
          published.

        o Thanked Richard Gumpertz.

D.2 Changes from Draft -03

        o Removed an obsolete reference (MO|TU|WE|TH|FR|SA|SU).  It is
           case-insensitive, so it is not given as a DTD switch. -->
   <!ATTLIST time
      dtstart       CDATA  #REQUIRED
      dtend         CDATA  #IMPLIED
      duration      CDATA  #IMPLIED
      freq          CDATA  #IMPLIED
      until         CDATA  #IMPLIED
      count         CDATA  #IMPLIED
      interval      CDATA  "1"
      bysecond      CDATA  #IMPLIED
      byminute      CDATA  #IMPLIED
      byhour        CDATA  #IMPLIED
      byday         CDATA  #IMPLIED
      bymonthday    CDATA  #IMPLIED
      byyearday     CDATA  #IMPLIED
      byweekno      CDATA  #IMPLIED
      bymonth       CDATA  #IMPLIED
      wkst          CDATA  "MO"
      bysetpos      CDATA  #IMPLIED
   >

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

   <!ELEMENT priority-switch ( priority*, (not-present, priority*)?,
                               otherwise? ) >
   <!-- <not-present> must appear at most once -->

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

   <!ELEMENT priority ( %Node; ) >

   <!-- Exactly one of these three attributes must appear -->
   <!ATTLIST priority
      less          %PriorityVal;  #IMPLIED
      greater       %PriorityVal;  #IMPLIED
      equal         CDATA          #IMPLIED
   >

   <!-- Locations: ways to specify the location a usage in examples which
          wasn't actually used anywhere.

        o Added forward references subsequent action
        (proxy, redirect) will attempt to "remove-location", "mail" and
          "log", as well as "location", contact. -->

   <!ENTITY % Clear  'clear (yes|no) "no"' >
   <!ELEMENT location ( %Node; ) >
   <!ATTLIST location
      url           CDATA    #REQUIRED
      priority      CDATA    #IMPLIED
      %Clear;
   >
   <!-- priority is in the XML syntax as examples of
          nodes that don't have explicit output tags.

        o Made range  0.0 - 1.0.  Its default value SHOULD
         be 1.0 -->

   <!ELEMENT lookup ( success?,notfound?,failure? ) >
   <!ATTLIST lookup
     source         CDATA     #REQUIRED
     timeout        CDATA     "30"
     use            CDATA     #IMPLIED
     ignore         CDATA     #IMPLIED
     %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 usage of some terminology more consistent: "output"
          vs. "next node"; "action" vs. "operation" vs. "behavior";
          "sub-actions" and "subactions"; "other operations" and "non-
          call operations" and "non-signalling operations"; "meta-
          information" and "ancillary information."

        o The "tel" subfield of addresses which come from sip URIs
          should have its visual separators stripped.

        o script can
        take. -->

   <!ELEMENT proxy ( busy?,noanswer?,redirection?,failure?,default? ) >

   <!-- The default value of timeout is "20" if the "priority" <noanswer> output
        exists. -->
   <!ATTLIST proxy
      timeout       CDATA    #IMPLIED
      recurse       (yes|no) "yes"
      ordering      (parallel|sequential|first-only) "parallel"
   >

   <!ELEMENT busy ( %Node; ) >
   <!ELEMENT noanswer ( %Node; ) >
   <!ELEMENT redirection ( %Node; ) >
   <!-- "failure" repeats from lookup, above. -->
   <!ELEMENT default ( %Node; ) >
   <!ELEMENT redirect EMPTY >
   <!ATTLIST redirect
      permanent     (yes|no) "no"
   >

   <!-- Statuses we can return -->

   <!ELEMENT reject EMPTY >
   <!-- The value of the "location"
          node "status" is 1.0.

        o Corrected the media type of a set of URIs to text/uri-list,
          and added (busy|notfound|reject|error), or a reference to it.

        o Added some wording clarifying how URI-based lookup queries
          work.

        o Corrected SIP
        4xx-6xx status. -->
   <!ATTLIST reject
      status        CDATA    #REQUIRED
      reason        CDATA    #IMPLIED
   >

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

   <!ELEMENT mail ( %Node; ) >
   <!ATTLIST mail
      url           CDATA    #REQUIRED
   >

   <!ELEMENT log ( %Node; ) >
   <!ATTLIST log
      name          CDATA    #IMPLIED
      comment       CDATA    #IMPLIED
   >

   <!-- Calls to subactions. -->

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

   <!-- Ancillary data -->

   <!ENTITY % Ancillary 'ancillary?' >

   <!ELEMENT ancillary EMPTY >

   <!-- Subactions -->

   <!ENTITY % Subactions 'subaction*' >
   <!ELEMENT subaction ( %Node; )>
   <!ATTLIST subaction
      id            ID       #REQUIRED
   >

   <!-- Top-level actions -->

   <!ENTITY % TopLevelActions 'outgoing?,incoming?' >

   <!ELEMENT outgoing ( %Node; )>

   <!ELEMENT incoming ( %Node; )>

   <!-- The top-level element of "duration" parameter in the examples.

        o Performed some pre-RFC textual cleanups (e.g. removing the
          reference script. -->

   <!ELEMENT cpl  ( %Ancillary;,%Subactions;,%TopLevelActions; ) >

D Changes from Earlier Versions

        [Note to the Internet-Draft URL RFC Editor: please remove this appendix before
        publication as an RFC.]

D.1 Changes from the XML namespace
          identifier).

        o Re-worded text Draft -05

   The changebars in the description Postscript and PDF versions of the Ancillary tag which
          implied this document
   indicate significant changes from this version.

        o Clarified that information could switch nodes are allowed to be placed in that node in degenerate --
          they can have no outputs, and they can have only an
          "otherwise" output.

        o Clarified the
          base CPL specification. (non-) usage of the special language-range "*".

        o Clarified that the tag is for use by
          extensions only. Candidate Start Time can be equal to the
          call time.

        o Expunged some references Modified the DTD to sub-daily recurrences which had
          accidentally been left in require that the text. "not-present" output
          appear only once.

        o Added DTD entries for the "time-switch" attributes re-added in
          draft -05.

        o Updated bibliography the reference to refer ISO 8601 to the latest versions of the
          cited documents. cite 8601:2000.

        o Fixed a number of typographical Updated all H.323 references to cite H.323v4.

        o Corrected some spelling errors.

D.3

D.2 Changes from Draft -02 -04

        o Reduced time-switches from Broke out language switches into their own switch node.

        o Restored the full iCal iCalendar COS recurrence to an iCal
          subset. Added an appendix giving an algorithm to resolve
          time-switches.

        o specification.
          Added text describing the extension mechanism.

        o Made explicit how each node is dependent on protocol handling.
          Separated out protocol-specific information -- for SIP in
          subsections consequences of the main text, this for H.323 in a non-normative
          appendix.
          implementors, and expanded somewhat on the recurrence
          algorithm.

        o Clarified some address mapping rules for H.323. when time zones are resolved.

        o Corrected the name of the "Redirecting number" in Q.931. Spelled out "iCalendar" rather than abbreviating it "iCal."

        o Clarified that address some points about host and port matching.

        o Whole-address matching on in SIP uses the "password" subfield is
          case-sensitive. standard SIP URL-match
          rules.

        o Added a recommendation Specified that TZID labels follow the usage proxy and lookup timeouts are positive integer
          number of seconds.

        o Specified that "subaction" "id" parameters must be unique.

        o Corrected example scripts' namespace and DTD references
          indicating older drafts of this document.

        o Deleted an unused subaction from the Olson database. "Call Forward: Redirect
          and Default" example script.

        o Added Made empty switches legal in the "priority" parameter to "location" nodes. DTD.

        o Added Made the "default" output to legal values for the "proxy" node. "ordering" parameter
          explicit in the DTD.

        o Made the meaning "success" output of "lookup" optional in the "proxy" node's outputs explicit.

        o Added suggested content for the e-mail generated by "mail"
          nodes. DTD. It
          can trigger a default action, just like anything else.

        o Pointed out Clarified that "&" must be escaped in XML (this the time-switch resolution algorithm is relevant
          for "mailto" URIs).

        o Pointed out that log names are logical names, and should not
          be interpreted as verbatim filenames.

        o Added some examples. non-
          normative.

        o Clarified some wording. Updated references to previously-unpublished RFCs, now
          published.

        o Fixed some typographical errors.

D.4 Thanked Richard Gumpertz.

D.3 Changes from Draft -01 -03

        o Completely re-wrote changes Removed an obsolete reference to time switches: they are now
          based on iCal rather than on crontab. a usage in examples which
          wasn't actually used anywhere.

        o Timezone Added forward references are now defined within time switches
          rather than to "remove-location", "mail" and
          "log", as well as "location", in the ancillary section. The ancillary section is
          now empty, but still defined for future use. To facilitate
          this, an XML syntax as examples of
          nodes that don't have explicit "ancillary" tag was added. output tags.

        o Added XML document type identifiers (the public identifier and Made the namespace), usage of some terminology more consistent: "output"
          vs. "next node"; "action" vs. "operation" vs. "behavior";
          "sub-actions" and "subactions"; "other operations" and "non-
          call operations" and "non-signalling operations"; "meta-
          information" and MIME registration information.

        o Clarified that the "not-present" output can appear anywhere in
          a switch. "ancillary information."

        o Re-wrote H.323 address mappings. Added the "alias-type" The "tel" subfield for H.323 addresses. of addresses which come from sip URIs
          should have its visual separators stripped.

        o Added The default value of the "language" and "display" string switch fields. "priority" value of the "location"
          node is 1.0.

        o Clarified why useless "not-present" outputs can appear in time Corrected the media type of a set of URIs to text/uri-list,
          and priority switches. added a reference to it.

        o Added some wording clarifying how URI-based lookup queries
          work.

        o Corrected the "clear" syntax of "duration" parameter to "location" and "lookup" nodes.
          (It had been in the DTD previously, but not in the text.) examples.

        o Weakened support for non-validating scripts from SHOULD to
          MAY, Performed some pre-RFC textual cleanups (e.g. removing the
          reference to allow the use of validating Internet-Draft URL from the XML parsers.

        o Added "redirection" output of "proxy" nodes. namespace
          identifier).

        o Clarified some aspects of how proxy nodes handle Re-worded text in the location
          set.

        o Added "permanent" parameter description of "redirect" nodes.

        o Add example script for outgoing call screening (from Kenny
          Hom)

        o Updated example scripts to use the public identifier.

        o Add omitted Ancillary tag to example script for call forward busy/no
          answer

        o Clarified which
          implied that information could be placed in introduction that this document mainly deals with
          servers. node in the
          base CPL specification. Clarified that the tag is for use by
          extensions only.

        o Updated reference Expunged some references to RFC 2824 now that it has sub-daily recurrences which had
          accidentally been published. left in the text.

        o Added explanatory text Updated bibliography to the introduction refer to types the latest versions of nodes.

        o Numerous minor clarifications and wording changes. the
          cited documents.

        o Fixed copy-and-paste errors, typos.

D.5 a number of typographical errors.

D.4 Changes from Draft -00 -02
        o Reduced time-switches from the full iCal recurrence to an iCal
          subset. Added high-level structure; script doesn't just start at a
          first action. an appendix giving an algorithm to resolve
          time-switches.

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

        o Added informal syntax specifications for Made explicit how each tag so people
          don't have to try to understand a DTD to figure node is dependent on protocol handling.
          Separated out the
          syntax.

        o Added subactions, replacing the old "link" tags. Links were
          far too reminiscent protocol-specific information -- for SIP in
          subsections of gotos the main text, for everyone's taste.

        o Added ancillary information section, and timezone support.

        o Added not-present switch output. H.323 in a non-normative
          appendix.

        o Added Clarified some 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" mapping rules for proxy.

        o Renamed "response" to "reject".

        o Changed "notify" to "mail", and simplified it. H.323.

        o Simplified "log", eliminating its "failure" output. Corrected the name of the "Redirecting number" in Q.931.

        o Clarified that address matching on the "password" subfield is
          case-sensitive.

        o Added description a recommendation that TZID labels follow the usage of default actions at various times during
          script processing.
          the Olson database.

        o Updated examples for these changes. Added the "priority" parameter to "location" nodes.

        o Updated DTD Added the "default" output to reflect new syntax.

E 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

F Bibliography
   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [2] International Telecommunication Union, "Packet based multimedia
   communication systems," Recommendation H.323, Telecommunication
   Standardization Sector the "proxy" node.

        o Made the meaning of ITU, Geneva, Switzerland, Feb. 1998.

   [3] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup
   language (XML) 1.0 (second edition)," W3C Recommendation REC-xml-
   20001006, World Wide Web Consortium (W3C), Oct. 2000.  Available at
   http://www.w3.org/XML/.

   [4] J. Lennox and H. Schulzrinne, "Call processing language framework
   and requirements," Request for Comments 2824, Internet Engineering
   Task Force, May 2000.

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

   [6] D. Raggett, A. Le Hors, and I. Jacobs, "HTML 4.01 specification,"
   W3C Recommendation REC-html401-19991224, World Wide Web Consortium
   (W3C), Dec.  1999.  Available at http://www.w3.org/TR/html4/.

   [7] ISO (International Organization the "proxy" node's outputs explicit.

        o Added suggested content for Standardization),
   "Information processing -- text and office systems -- standard
   generalized markup language (SGML)," ISO Standard ISO 8879:1986(E),
   International Organization the e-mail generated by "mail"
          nodes.

        o Pointed out that "&" must be escaped in XML (this is relevant
          for Standardization, Geneva, Switzerland,
   Oct. 1986.

   [8] M. Murata, S. S. Laurent, "mailto" URIs).

        o Pointed out that log names are logical names, and D. Kohn, "XML media types," Request should not
          be interpreted as verbatim filenames.

        o Added some examples.

        o Clarified some wording.

        o Fixed some typographical errors.

D.5 Changes from Draft -01

        o Completely re-wrote changes to time switches: they are now
          based on iCal rather than on crontab.

        o Timezone references are now defined within time switches
          rather than in the ancillary section. The ancillary section is
          now empty, but still defined for Comments 3023, Internet Engineering Task Force, Jan. 2001.

   [9] R. Hinden future use. To facilitate
          this, an explicit "ancillary" tag was added.

        o Added XML document type identifiers (the public identifier and S. Deering, "IP version 6 addressing architecture,"
   Request for Comments 2373, Internet Engineering Task Force, July
   1998.

   [10] M. Davis
          the namespace), and M. Duerst, "Unicode normalization forms," Unicode
   Technical Report 15, Unicode Consortium, Aug. 2000.  Revision 19;
   part of Unicode 3.0.1. Available at
   http://www.unicode.org/unicode/reports/tr15/.

   [11] M. Davis, "Case mappings," Unicode Technical Report 21, Unicode
   Consortium, Oct. 2000.  Revision 4.3. Available at
   http://www.unicode.org/unicode/reports/tr21/.

   [12] H. Alvestrand, "Tags MIME registration information.

        o Clarified that the "not-present" output can appear anywhere in
          a switch.

        o Re-wrote H.323 address mappings. Added the "alias-type"
          subfield for H.323 addresses.

        o Added the identification "language" and "display" string switch fields.

        o Clarified why useless "not-present" outputs can appear in time
          and priority switches.

        o Added the "clear" parameter to "location" and "lookup" nodes.
          (It had been in the DTD previously, but not in the text.)

        o Weakened support for non-validating scripts from SHOULD to
          MAY, to allow the use of languages,"
   Request validating XML parsers.

        o Added "redirection" output of "proxy" nodes.

        o Clarified some aspects of how proxy nodes handle the location
          set.

        o Added "permanent" parameter of "redirect" nodes.

        o Add example script for Comments 3066, Internet Engineering Task Force, Jan.
   2001.

   [13] F. Dawson and D. Stenerson, "Internet calendaring outgoing call screening (from Kenny
          Hom)

        o Updated example scripts to use the public identifier.

        o Add omitted tag to example script for call forward busy/no
          answer

        o Clarified in introduction that this document mainly deals with
          servers.

        o Updated reference to RFC 2824 now that it has been published.

        o Added explanatory text to the introduction to types of nodes.

        o Numerous minor clarifications and scheduling
   core object specification (icalendar)," Request wording changes.

        o Fixed copy-and-paste errors, typos.

D.6 Changes from Draft -00

        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 Comments 2445,
   Internet Engineering Task Force, Nov. 1998.

   [14] P. Eggert, "Sources 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 time zone everyone's taste.

        o Added ancillary information section, and daylight saving time
   data." Available at http://www.twinsun.com/tz/tz-link.htm.

   [15] ISO (International Organization for Standardization), "Data
   elements 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 interchange formats -- information interchange --
   representation "source" parameters of dates "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 times," ISO Standard ISO 8601:1988(E),
   International Organization "ordering" parameters to "proxy".

        o Added default value of "timeout" for Standardization, Geneva, Switzerland,
   June 1986.

   [16] M. Mealling proxy.

        o Renamed "response" to "reject".

        o Changed "notify" to "mail", and R. Daniel, "URI resolution services necessary
   for URN resolution," Request 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 Comments 2483, Internet Engineering
   Task Force, Jan. 1999.

   [17] H. these changes.

        o Updated DTD to reflect new syntax.

E 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 and J. Rosenberg, "SIP caller preferences and
   callee capabilities," Internet Draft, Internet Engineering Task
   Force, Nov. 2000.  Work in progress.

   [18] S. DeRose,
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: schulzrinne@cs.columbia.edu

F Bibliography

   [1] M. Handley, H. Schulzrinne, E. Maler, D. Orchard, and B. Trafford, "XML linking
   language (XLink) version 1.0," W3C Candidate Recommendation CR-
   xlink-20000703, World Wide Web Consortium (W3C), July 2000.
   Available at http://www.w3.org/TR/xlink/.

   [19] T. Bray, D. Hollander, Schooler, and A. Layman, "Namespaces in XML," W3C
   Recommendation REC-xml-names-19900114, World Wide Web Consortium
   (W3C), Jan. 1999.  Available at http://www.w3.org/TR/REC-xml-names/.

   [20] T. Showalter, "Sieve: A mail filtering language," J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 3028, 2543, Internet
   Engineering Task Force, Jan. 2001.

   [21] D. C. Fallside, "XML schema part 0: Primer," W3C Candidate
   Recommendation CR-xmlschema-0-20001024, World Wide Web Consortium
   (W3C), Oct. 2000.  Available at http://www.w3.org/TR/xmlschema-0/.

   [22] International Telecommunication Union, "Digital subscriber
   signalling system no. 1 (dss 1) - isdn user-network interface layer 3
   specification for basic call control," Recommendation Q.931,
   Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993.

   [23] 1999.

   [2] International Telecommunication Union, "Packet based multimedia
   communication systems," Recommendation H.323, Telecommunication
   Standardization Sector of ITU, Geneva, Switzerland, Nov. 2000.

   [24] O. Levin, "H.323 URL scheme definition," Internet Draft,
   Internet Engineering Task Force, Nov. 2001.  Work in progress.

   Full Copyright Statement

   Copyright (c) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice

   [3] T. Bray, J. Paoli, and this paragraph are
   included on all such copies C. M. Sperberg-McQueen, "Extensible markup
   language (XML) 1.0 (second edition)," W3C Recommendation REC-xml-
   20001006, World Wide Web Consortium (W3C), Oct. 2000.  Available at
   http://www.w3.org/XML/.

   [4] J. Lennox 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 H. Schulzrinne, "Call processing language framework
   and requirements," Request for the purpose of
   developing Comments 2824, Internet standards in which case the procedures Engineering
   Task Force, May 2000.

   [5] S. Bradner, "Key words for
   copyrights defined use in the Internet Standards process must be
   followed, or as required RFCs to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the indicate requirement
   levels," Request for Comments 2119, Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis Engineering Task Force,
   Mar. 1997.

   [6] D. Raggett, A. Le Hors, 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 ........................................    2
   1.1        Conventions of This Document ........................    2
   2          Structure of CPL Scripts ............................    2
   2.1        High-level Structure ................................    3
   2.2        Abstract Structure of a Call Processing Action ......    3
   2.3        Location Model ......................................    4
   2.4        XML Structure .......................................    4
   3          Document Information ................................    5
   3.1        CPL Document Identifiers I. Jacobs, "HTML 4.01 specification,"
   W3C Recommendation REC-html401-19991224, World Wide Web Consortium
   (W3C), Dec.  1999.  Available at http://www.w3.org/TR/html4/.

   [7] ISO (International Organization for XML ....................    5
   3.2        MIME Registration ...................................    6
   4          Script Structure: Overview ..........................    7
   5          Switches ............................................    8
   5.1        Address Switches ....................................    8
   5.1.1      Usage of "address-switch" with SIP ..................   11
   5.2        String Switches .....................................   12
   5.2.1      Usage of "string-switch" with SIP ...................   13
   5.3        Language Switches ...................................   13
   5.3.1      Usage of "language-switch" with SIP .................   14
   5.4        Time Switches .......................................   14
   5.4.1      iCalendar differences Standardization),
   "Information processing -- text and implementation issues .....   20
   5.5        Priority Switches ...................................   21
   5.5.1      Usage of "priority-switch" with SIP .................   22 office systems -- standard
   generalized markup language (SGML)," ISO Standard ISO 8879:1986(E),
   International Organization for Standardization, Geneva, Switzerland,
   Oct. 1986.

   [8] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request
   for Comments 3023, Internet Engineering Task Force, Jan. 2001.

   [9] R. Hinden and S. Deering, "IP version 6          Location Modifiers ..................................   22
   6.1        Explicit Location ...................................   23
   6.1.1      Usage of "location" with SIP ........................   23
   6.2        Location Lookup .....................................   24
   6.2.1      Usage of "lookup" with SIP ..........................   25
   6.3        Location Removal ....................................   26
   6.3.1      Usage of "remove-location" with SIP .................   27
   7          Signalling Operations ...............................   27
   7.1        Proxy ...............................................   27
   7.1.1      Usage of "proxy" with SIP ...........................   30
   7.2        Redirect ............................................   30
   7.2.1      Usage addressing architecture,"
   Request for Comments 2373, Internet Engineering Task Force, July
   1998.

   [10] M. Davis and M. Duerst, "Unicode normalization forms," Unicode
   Technical Report 15, Unicode Consortium, Aug. 2000.  Revision 19;
   part of "redirect" with SIP ........................   31
   7.3        Reject ..............................................   31
   7.3.1      Usage Unicode 3.0.1. Available at
   http://www.unicode.org/unicode/reports/tr15/.

   [11] M. Davis, "Case mappings," Unicode Technical Report 21, Unicode
   Consortium, Oct. 2000.  Revision 4.3. Available at
   http://www.unicode.org/unicode/reports/tr21/.

   [12] H. Alvestrand, "Tags for the identification of "reject" with SIP ..........................   31
   8          Non-signalling Operations ...........................   32
   8.1        Mail ................................................   32
   8.1.1      Suggested Content languages,"
   Request for Comments 3066, Internet Engineering Task Force, Jan.
   2001.

   [13] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
   core object specification (icalendar)," Request for Comments 2445,
   Internet Engineering Task Force, Nov. 1998.

   [14] P. Eggert, "Sources for time zone and daylight saving time
   data." Available at http://www.twinsun.com/tz/tz-link.htm.

   [15] ISO (International Organization for Standardization), "Data
   elements and interchange formats -- information interchange --
   representation of Mailed Information .............   33
   8.2        Log .................................................   33
   9          Subactions ..........................................   34
   10         Ancillary Information ...............................   35
   11         Default Behavior ....................................   36
   12         CPL Extensions ......................................   37
   13         Examples ............................................   38
   13.1       Example: Call Redirect Unconditional ................   38
   13.2       Example: Call Forward Busy/No Answer ................   38
   13.3       Example: Call Forward: Redirect dates and Default .........   39
   13.4       Example: Call Screening .............................   39
   13.5       Example: Priority times," ISO Standard ISO 8601:2000(E),
   International Organization for Standardization, Geneva, Switzerland,
   Dec. 2000.

   [16] M. Mealling and R. Daniel, "URI resolution services necessary
   for URN resolution," Request for Comments 2483, Internet Engineering
   Task Force, Jan. 1999.

   [17] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
   callee capabilities," Internet Draft, Internet Engineering Task
   Force, Nov. 2001.  Work in progress.

   [18] S. DeRose, E. Maler, D. Orchard, and B. Trafford, "XML linking
   language (XLink) version 1.0," W3C Candidate Recommendation CR-
   xlink-20000703, World Wide Web Consortium (W3C), July 2000.
   Available at http://www.w3.org/TR/xlink/.

   [19] T. Bray, D. Hollander, and Language Routing ..............   40
   13.6       Example: Outgoing Call Screening ....................   41
   13.7       Example: Time-of-day Routing ........................   41
   13.8       Example: Location Filtering .........................   43
   13.9       Example: Non-signalling Operations ..................   43
   13.10      Example: Hypothetical Extensions ....................   43
   13.11      Example: A Complex Example ..........................   45
   14         Security Considerations .............................   45
   15         IANA Considerations .................................   46
   16         Acknowledgments .....................................   47 A. Layman, "Namespaces in XML," W3C
   Recommendation REC-xml-names-19900114, World Wide Web Consortium
   (W3C), Jan. 1999.  Available at http://www.w3.org/TR/REC-xml-names/.

   [20] T. Showalter, "Sieve: A          An Algorithm mail filtering language," Request for Resolving Time Switches ............   47
   B          Suggested Usage of CPL with H.323 ...................   48
   B.1        Usage of "address-switch" with H.323 ................   49
   B.2        Usage of "string-switch" with H.323 .................   50
   B.3        Usage of "language-switch" with H.323 ...............   51
   B.4        Usage
   Comments 3028, Internet Engineering Task Force, Jan. 2001.

   [21] D. C. Fallside, "XML schema part 0: Primer," W3C Candidate
   Recommendation CR-xmlschema-0-20001024, World Wide Web Consortium
   (W3C), Oct. 2000.  Available at http://www.w3.org/TR/xmlschema-0/.

   [22] International Telecommunication Union, "Digital subscriber
   signalling system no. 1 (dss 1) - isdn user-network interface layer 3
   specification for basic call control," Recommendation Q.931,
   Telecommunication Standardization Sector of "priority-switch" with H.323 ...............   51
   B.5        Usage ITU, Geneva, Switzerland,
   Mar. 1993.

   [23] O. Levin, "H.323 URL scheme definition," Internet Draft,
   Internet Engineering Task Force, Nov. 2001.  Work in progress.

   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of "location" with H.323 ......................   51
   B.6        Usage 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 "lookup" with H.323 ........................   51
   B.7        Usage 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 "remove-location" with H.323 ...............   51
   C          The XML DTD
   developing Internet standards in which case the procedures for CPL .................................   52
   D          Changes from Earlier Versions .......................   58
   D.1        Changes from Draft -04 ..............................   58
   D.2        Changes from Draft -03 ..............................   59
   D.3        Changes from Draft -02 ..............................   60
   D.4        Changes from Draft -01 ..............................   61
   D.5        Changes from Draft -00 ..............................   62
   E          Authors' Addresses ..................................   63
   F          Bibliography ........................................   63
   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.