diff options
Diffstat (limited to 'doc/rfc/rfc3880.txt')
| -rw-r--r-- | doc/rfc/rfc3880.txt | 4147 |
1 files changed, 4147 insertions, 0 deletions
diff --git a/doc/rfc/rfc3880.txt b/doc/rfc/rfc3880.txt new file mode 100644 index 0000000..e61c700 --- /dev/null +++ b/doc/rfc/rfc3880.txt @@ -0,0 +1,4147 @@ + + + + + + +Network Working Group J. Lennox +Request for Comments: 3880 X. Wu +Category: Standards Track H. Schulzrinne + Columbia University + October 2004 + + + Call Processing Language (CPL): + A Language for User Control of Internet Telephony Services + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines the Call Processing Language (CPL), a language + to describe and control Internet telephony services. It is designed + to be implementable on either network servers or user agents. 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. + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 1] + +RFC 3880 CPL October 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions of This Document. . . . . . . . . . . . . . 4 + 2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4 + 2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4 + 2.2. Abstract Structure of a Call Processing Action. . . . . 5 + 2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6 + 2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6 + 3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7 + 4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. Usage of "address-switch" with SIP. . . . . . . 11 + 4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12 + 4.2.1. Usage of "string-switch" with SIP . . . . . . . 13 + 4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14 + 4.3.1. Usage of "language-switch" with SIP . . . . . . 14 + 4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15 + 4.4.1. iCalendar differences and implementation + issues. . . . . . . . . . . . . . . . . . . . . 20 + 4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21 + 4.5.1. Usage of "priority-switch" with SIP . . . . . . 22 + 5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22 + 5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23 + 5.1.1. Usage of "location" with SIP. . . . . . . . . . 23 + 5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24 + 5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25 + 5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25 + 5.3.1. Usage of "remove-location" with SIP . . . . . . 26 + 6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26 + 6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29 + 6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30 + 6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30 + 6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30 + 7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31 + 7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 7.1.1. Suggested Content of Mailed Information . . . . 32 + 7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34 + 10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35 + 11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35 + 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37 + 12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38 + 12.3. Example: Call Forward: Redirect and Default . . . . . . 39 + + + +Lennox, et al. Standards Track [Page 2] + +RFC 3880 CPL October 2004 + + + 12.4. Example: Call Screening . . . . . . . . . . . . . . . . 40 + 12.5. Example: Priority and Language Routing. . . . . . . . . 41 + 12.6. Example: Outgoing Call Screening. . . . . . . . . . . . 42 + 12.7. Example: Time-of-day Routing. . . . . . . . . . . . . . 43 + 12.8. Example: Location Filtering . . . . . . . . . . . . . . 44 + 12.9. Example: Non-signalling Operations. . . . . . . . . . . 45 + 12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46 + 12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48 + 13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49 + 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49 + 14.1. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49 + 14.2. Schema registration . . . . . . . . . . . . . . . . . . 50 + 14.3. MIME Registration . . . . . . . . . . . . . . . . . . . 50 + 15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51 + A. An Algorithm for Resolving Time Switches . . . . . . . . . . . 52 + B. Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53 + B.1. Usage of "address-switch" with H.323. . . . . . . . . . 53 + B.2. Usage of "string-switch" with H.323 . . . . . . . . . . 55 + B.3. Usage of "language-switch" with H.323 . . . . . . . . . 55 + B.4. Usage of "priority-switch" with H.323 . . . . . . . . . 55 + B.5. Usage of "location" with H.323. . . . . . . . . . . . . 56 + B.6. Usage of "lookup" with H.323. . . . . . . . . . . . . . 56 + B.7. Usage of "remove-location" with H.323 . . . . . . . . . 56 + C. The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56 + Normative References . . . . . . . . . . . . . . . . . . . . . . . 70 + Informative References . . . . . . . . . . . . . . . . . . . . . . 71 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74 + +1. Introduction + + The Call Processing Language (CPL) is a language that can be used to + describe and control Internet telephony services. It is not tied to + any particular signalling architecture or protocol; it is anticipated + that it will be used with both the Session Initiation Protocol (SIP) + [1] and H.323 [16]. + + CPL is powerful enough to describe a large number of services and + features, but it is limited in power so that it can run safely in + Internet telephony servers. The intention is to make it impossible + for users to do anything more complex (and dangerous) than describe + Internet telephony services. The language is not Turing-complete, + and provides no way to write loops or recursion. + + CPL is also designed to be easily created and edited by graphical + tools. It is based on the Extensible Markup Language (XML) [2], so + parsing it is easy and many parsers for it are publicly available. + + + +Lennox, et al. Standards Track [Page 3] + +RFC 3880 CPL October 2004 + + + The structure of the language maps closely to its behavior, so an + editor can understand any valid script, even ones written by hand. + The language is also designed so that a server can easily confirm the + validity of a script when the server receives it, rather than + discovering problems while a call is being processed. + + Implementations of CPL are expected to 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 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" + [17]. + +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 BCP 14, RFC 2119 + [3] and indicate requirement levels for compliant CPL + implementations. + + Some paragraphs are indented, like this; they give motivations of + design choices, advice to implementors, or thoughts on future + development of or extensions to CPL. They are not essential to + the specification of the language, and are non-normative. + +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 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 actions are defined: "incoming", the action performed when + a call arrives whose destination is the owner of the script, and + "outgoing", the action performed when a call arrives whose originator + is the owner of the script. + + + + + +Lennox, et al. Standards Track [Page 4] + +RFC 3880 CPL October 2004 + + + Subactions are actions which can be called from other actions. CPL + forbids subactions from being called recursively: see Section 8. + + Ancillary information is 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 section is reserved for use by extensions. + +2.2. Abstract Structure of a Call Processing Action + + Abstractly, a call processing action is described by a collection of + nodes that describe operations that can be performed or decisions + that 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 and arrows; CPL is + designed so that actions can be conveniently edited graphically using + this representation. Nodes are arranged in a tree, starting at a + single root node; outputs of nodes are connected to additional nodes. + When an action is run, the action or decision described by the + action's top-level node is performed; based on the result of that + node, the server follows one of the node's outputs, and the + subsequent node it points to is performed; this process continues + until a node with no specified outputs is reached. Because the graph + is acyclic, this will occur after a bounded and predictable number of + nodes are visited. + + If an output to a node does not point to another node, it indicates + that the CPL server should perform a node- or protocol-specific + action. Some nodes have specific default behavior associated with + them; for others, the default behavior is implicit in the underlying + signalling protocol, or can be configured by the administrator of the + server. For further details on this, see Section 10. + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 5] + +RFC 3880 CPL October 2004 + + + _________________ ___________________ ________ 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 of information necessary for CPL is not + given as node parameters: the set of locations to which a call is to + be directed. Instead, this set of locations is stored as an implicit + global variable throughout the execution of a processing action (and + its 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 and + tractability of understanding the language). The specific operations + which add, retrieve, or filter location sets are given in Section 5. + + For the incoming top-level call processing action, the location set + is initialized to the empty set. For the outgoing action, it is + initialized to the destination address of the call. + +2.4. XML Structure + + Syntactically, CPL scripts are represented by XML documents. XML is + thoroughly specified by the XML specification [2], and implementors + of this specification should be familiar with that document. + However, as a brief overview, XML consists of a hierarchical + structure of tags; each tag can have a number of attributes. It is + visually and structurally very similar to HTML [18], as both + languages are simplifications of the earlier and larger standard SGML + [19]. + + + + + +Lennox, et al. Standards Track [Page 6] + +RFC 3880 CPL October 2004 + + + See Figure 2 for the XML document corresponding to the graphical + representation of the CPL script in Figure 1. Both nodes and outputs + in CPL are represented by XML tags; parameters are represented by XML + tag attributes. Typically, node tags contain output tags, and vice- + versa (with a few exceptions: see Sections 5.1, 5.3, 7.1, and 7.2). + + The connection between the output of a node and another node is + represented by enclosing the tag representing the pointed-to node + inside the tag for the outer node's output. Convergence (several + outputs pointing to a single node) is represented by subactions, + discussed further in Section 8. + + The higher-level structure of a CPL script is represented by tags + corresponding to each piece of ancillary information, subactions, and + top-level actions, in order. This higher-level information is all + enclosed in a special tag "cpl", the outermost tag of the XML + document. + + A complete XML Schema for CPL is provided in Appendix C. The + remainder of the main sections of this document describe the + semantics of CPL, while giving its syntax informally. For the formal + syntax, please see the appendix. + +3. Script Structure: Overview + + As mentioned, a CPL script consists of ancillary information, + subactions, and top-level actions. The full syntax of the "cpl" node + is given in Figure 3. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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> + + + +Lennox, et al. Standards Track [Page 7] + +RFC 3880 CPL October 2004 + + + </address> + <otherwise> + <sub ref="voicemail" /> + </otherwise> + </address-switch> + </incoming> + </cpl> + + Figure 2: Sample CPL Script: XML Version + + Tag: "cpl" + Parameters: None + Sub-tags: "ancillary" See Section 9 + "subaction" See Section 8 + "outgoing" Top-level actions to take on this user's + outgoing calls + "incoming" Top-level actions to take on this user's + incoming calls + + Figure 3: Syntax of the top-level "cpl" tag + + Call processing actions, both top-level actions and subactions, + 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 the location set, + signalling operations, which cause signalling events in the + underlying protocol, and non-signalling operations, which trigger + behavior which does not effect the underlying protocol. + +4. Switches + + Switches represent choices a CPL script can make, based on either + attributes of the original call request or items independent of the + call. + + All switches are arranged as a list of conditions that can match a + variable. Each condition corresponds to a node output; the output + points to the next node that should be executed if the condition is + true. The conditions are tried in the order they are presented in + the script; the output corresponding to the first node to match is + taken. + + There are two special switch outputs that apply to every switch type. + The output "not-present", which MAY occur anywhere in the list of + outputs, is true if the variable the switch was to match was not + present in the original call setup request. (In this document, this + is sometimes described by saying that the information is "absent".) + + + +Lennox, et al. Standards Track [Page 8] + +RFC 3880 CPL October 2004 + + + The output "otherwise", which MUST be the last output specified if it + is present, matches if no other condition matched. + + If no condition matches and no "otherwise" output was present in the + script, the default script behavior is taken. See Section 10 for + more information on this. + + Switches MAY contain no outputs. They MAY only contain an + "otherwise" output. + + Such switches are not particularly useful, but might be created by + tools which automatically generate CPL scripts. + +4.1. Address Switches + + Address switches allow a CPL script to make decisions based on one of + the addresses present in the original call request. They 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") + + Figure 4: Syntax of the "address-switch" node + + Address switches have two node parameters: "field" and "subfield". + The mandatory "field" parameter allows the script to specify which + address is to be considered for the switch: either the call's origin + address (field "origin"), its current destination address (field + "destination"), or its original destination (field "original- + destination"), the destination the call had before any earlier + forwarding was invoked. Servers MAY define additional field values. + + The optional "subfield" specifies which part of the address is to be + considered. The possible subfield values are: "address-type", + "user", "host", "port", "tel", and "display". Additional subfield + values MAY be defined for protocol-specific values. (The subfield + "password" is defined for SIP in Section 4.1.1; the subfield "alias- + type" is defined for H.323 in Appendix B.1.) If no subfield is + + + +Lennox, et al. Standards Track [Page 9] + +RFC 3880 CPL October 2004 + + + specified, the "entire" address is matched; the precise meaning of + this is defined for each underlying signalling protocol. Servers MAY + define additional subfield values. + + The subfields are defined as follows: + + address-type: This indicates the type of the underlying address, + i.e., the URI scheme, if the address can be represented by a + URI. The types specifically discussed by this document are + "sip", "tel", and "h323". The address type is not case- + sensitive. It has a value for all defined address types. + + user: This subfield of the address indicates, for e-mail style + addresses, the user part of the address. For a telephone + number style address, it includes the 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 the address, in host + name, IPv4, or IPv6 [4] textual representation format. Host + names are compared as strings. IP addresses are compared + numerically. (In particular, the presence or location of an + IPv6 :: omitted-zero-bits block is not significant for + matching purposes.) Host names are never equal to IP + addresses -- no DNS resolution is performed. IPv4 addresses + are never equal to IPv6 addresses, even if the IPv6 address + is a v4-in-v6 embedding. This subfield is not case + sensitive, and may be absent. + + For host names only, subdomain matching is supported with + the "subdomain-of" match operator. The "subdomain-of" + operator ignores leading dots in the hostname or match + pattern, if any. + + port: This subfield indicates the TCP or UDP port number of the + address, numerically, in decimal format. It is not case + sensitive, as it MUST only contain decimal digits. Leading + zeros are ignored. + + tel: This subfield indicates a telephone subscriber number, if + the address contains such a number. It is not case + sensitive (telephone numbers may contain the symbols 'A', + 'B', 'C', or 'D'), and may be absent. It may be matched + using the "subdomain-of" match operator. Punctuation and + separator characters in telephone numbers are discarded. + + + + + + +Lennox, et al. Standards Track [Page 10] + +RFC 3880 CPL October 2004 + + + 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 in Section 4.2. The "contains" operator may be + applied to it. It may be absent. + + For any completely unknown subfield, the server MAY reject the script + at the time it is submitted with an indication of the problem; if a + 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 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 in the "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 match operator applies only for the subfields + "host" 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 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 be + given as arguments to this operator; however, they only + match exactly. In the case of the "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 of the match as a substring. + +4.1.1. Usage of "address-switch" with SIP + + For SIP, the "origin" address corresponds to the address in the + "From" header, "destination" corresponds to the "Request-URI", and + "original-destination" corresponds to the "To" header. + + The "display" subfield of an address is the display-name part of the + address, if it is present. Because of SIP's syntax, the + "destination" address field will never have a "display" subfield. + + + + +Lennox, et al. Standards Track [Page 11] + +RFC 3880 CPL October 2004 + + + The "address-type" subfield of an address is the URI scheme of that + address. Other address fields depend on that "address-type". + + For SIP URIs, the "user", "host", and "port" subfields correspond to + the "user," "host," and "port" elements of the URI syntax. (Note + that, following the definitions of RFC 3261 [1], a SIP URI which does + not specify a port is not the same as an explicit port 5060; the + former is indicated by an absent port subfield.) The "tel" subfield + is defined to be the "user" part of the URI, with visual separators + stripped, if the "user=phone" parameter is given to the URI, or if + the server is otherwise configured to recognize the user part as a + telephone number. An additional subfield, "password", is defined to + correspond to the "password" element of the SIP URI, and is 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 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 the scheme described + in Appendix B. + + For other URI schemes, only the "address-type" subfield is defined by + this specification; servers MAY set other pre-defined subfields, or + MAY support additional subfields. + + If no subfield is specified for addresses in SIP messages, the string + matched is the URI part of the address. For "is" matches, standard + SIP URI matching rules are used; for "contains" matches, the URI is + used verbatim. + +4.2. String Switches + + String switches allow a CPL script to make decisions based on free- + form strings present in a call request. They are summarized in + Figure 5. + + Node: "string-switch" + Outputs: "string" Specific string to match + Parameters: "field" "subject", "organization", + "user-agent", or "display" + + Output: "string" + Parameters: "is" Exact match + "contains" Substring match + + Figure 5: Syntax of the "string-switch" node + + + +Lennox, et al. Standards Track [Page 12] + +RFC 3880 CPL October 2004 + + + String switches have one node parameter: "field". The mandatory + "field" parameter specifies which string is to be matched. + + String switches are dependent on the call signalling protocol being + used. + + Four fields are defined and listed below. The value of each of these + fields is a free-form Unicode string with no other structure defined. + + subject: The subject of the call. + + organization: The organization of the originator of the call. + + user-agent: The name of the program or device with which the call + request was made. + + display: Free-form text associated with the call, intended to be + displayed to the recipient, with no other semantics defined + by the signalling protocol. + + Strings are matched as case-insensitive Unicode strings, in the + following manner. First, strings are canonicalized to the + "Compatibility Composition" (KC) form, as specified in Unicode + Standard Annex #15 [5]. Then, strings are compared using locale- + insensitive caseless mapping, as specified in Unicode Standard Annex + #21 [6]. + + Code to perform the first step, in Java and Perl, is available; + see the links from Annex 5 of UAX 15 [5]. The case-insensitive + string comparison in the Java standard class libraries already + performs the second step; other Unicode-aware libraries should be + similar. + + The output tag of string matching is named "string", and has a + mandatory argument, one of "is" or "contains", indicating whole- + string match or substring match, respectively. + +4.2.1. Usage of "string-switch" with SIP + + For SIP, the fields "subject", "organization", and "user-agent" + correspond to the SIP header fields with the same name. These are + used verbatim as they appear in the message. + + The field "display" is not used, and is never present. + + + + + + + +Lennox, et al. Standards Track [Page 13] + +RFC 3880 CPL October 2004 + + +4.3. Language Switches + + Language switches allow a CPL script to make decisions based on the + languages in which the originator of the call wishes to communicate. + They are summarized in Figure 6. + + Node: "language-switch" + Outputs: "language" Specific string to match + Parameters: None + + Output: "language" + Parameters: "matches" Match if the given language + matches a language-range of the + call. + + Figure 6: Syntax of the "language-switch" node + + Language switches take no parameters. + + The "language" output takes one parameter, "matches". The value of + the parameter is a language-tag, as defined in RFC 3066 [7]. The + caller may have specified a set of language-ranges, also as defined + in RFC 3066. The CPL server checks each language-tag 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 matches a language-tag if it exactly + equals the tag, or if it exactly equals a prefix of the tag such that + the first character following the prefix is "-". + + If the caller specified the special language-range "*", it is ignored + for the purpose of matching. Languages with a "q" value of 0 are + also ignored. + + This switch MAY be not-present. + +4.3.1. Usage of "language-switch" with SIP + + The language-ranges for the "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 CPL's first-match semantics in switches, "q" + values other than 0 of the "Accept-Language" header fields are + ignored. + + + + + + +Lennox, et al. Standards Track [Page 14] + +RFC 3880 CPL October 2004 + + +4.4. Time Switches + + Time switches allow a CPL script to make decisions based on the time + and/or date the script is being executed. They are summarized in + Figure 7. + + Time switches are independent of the underlying signalling protocol. + + 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 ("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" List of seconds within a minute + "byminute" List of minutes within an hour + "byhour" List of hours of the day + "byday" List of days of the week + "bymonthday" List of days of the month + "byyearday" List of days of the year + "byweekno" List of weeks of the year + "bymonth" List of months of the year + "wkst" First day of the work week + "bysetpos" List of values within + set of events specified + + Figure 7: Syntax of the "time-switch" node + + Time switches are based closely on the specification of recurring + intervals of time in the Internet Calendaring and Scheduling Core + Object Specification (iCalendar COS), RFC 2445 [8]. + + This allows CPL scripts to be generated automatically from + calendar books. It also allows us to re-use the extensive + existing work specifying time intervals. + + If future standards-track documents are published that update or + obsolete RFC 2445, any changes or clarifications those documents make + to recurrence handling apply to CPL time-switches as well. + + + +Lennox, et al. Standards Track [Page 15] + +RFC 3880 CPL October 2004 + + + An algorithm to determine whether an instant falls within a given + recurrence is given in Appendix A. + + The "time-switch" tag takes two optional parameters, "tzid" and + "tzurl", both of which are defined in RFC 2445 (Sections 4.8.3.1 and + 4.8.3.5 respectively). The "tzid" is the identifying label by which + a time zone definition is referenced. If it begins with a forward + slash (solidus), it references a to-be-defined global time zone + registry; otherwise it is locally-defined at the server. The "tzurl" + gives a network location from which an up-to-date VTIMEZONE + definition for the timezone can be retrieved. + + While "tzid" labels that do not begin with a forward slash are + locally defined, it is RECOMMENDED that servers support at least the + naming scheme used by the Olson Time Zone database [9]. Examples of + timezone databases that use the Olson scheme are the zoneinfo files + on most Unix-like systems, and the standard Java TimeZone class. + + Servers SHOULD resolve "tzid" and "tzurl" references to time zone + definitions at the time the script is uploaded. They MAY + periodically refresh these resolutions to obtain the most up-to-date + definition 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" 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 be + interpreted as being "floating" times, i.e., that they are specified + in the local timezone of the CPL server. + + Because of daylight-savings-time changes over the course of a + year, it is necessary to specify time switches in a given + timezone. UTC offsets are not sufficient, or a time-of-day + routing rule which held between 9 am and 5 pm in the eastern + United States would start holding between 8 am and 4 pm at the end + of October. + + Authors of CPL servers should be careful to handle correctly the + intervals when local time is discontinuous, at the beginning or end + of daylight-savings time. Note especially that some times may occur + more than once when clocks are set back. The algorithm in Appendix A + is believed 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 the first period of the list, and exactly + one of "dtend" or "duration", which specify the ending time or the + + + +Lennox, et al. Standards Track [Page 16] + +RFC 3880 CPL October 2004 + + + duration of the period, respectively. The "dtstart" and "dtend" + parameters are formatted as iCalendar COS DATE-TIME values, as + specified in Section 4.3.5 of RFC 2445 [8]. Because time zones are + specified in the top-level "time-switch" tag, only forms 1 or 2 + (floating or UTC times) can be used. The "duration" parameter is + given as an iCalendar COS DURATION parameter, as specified in section + 4.3.6 of RFC 2445. Both the DATE-TIME and the DURATION syntaxes are + subsets of the corresponding syntaxes from ISO 8601 [20]. + + For a recurring interval, the "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 negative-length durations are not allowed. + + If no other parameters are specified, a time node indicates only a + single period of time. More complicated sets of period intervals are + constructed as recurrences. A recurrence is specified by including + the "freq" parameter, which indicates the type of recurrence rule. + Parameters other than "dtstart", "dtend", and "duration" SHOULD NOT + be specified unless "freq" is present, though CPL servers SHOULD + accept scripts with such parameters present, and ignore the other + parameters. + + The "freq" parameter takes one of 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 of a day or more, "weekly", to specify repeating + periods based on an interval of a week or more, "monthly", to specify + repeating periods based on an interval of a month or more, and + "yearly", to specify repeating periods based on an interval 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 second for a "secondly" rule, every minute for a "minutely" + rule, every hour for an "hourly" rule, 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 the recurrence rule in an inclusive manner. If + the value specified by "until" is synchronized with the specified + recurrence, this date or date-time becomes the last instance of the + recurrence. If specified as a date-time value, then it MUST be + + + + + +Lennox, et al. Standards Track [Page 17] + +RFC 3880 CPL October 2004 + + + specified in UTC time format. If not present, and the "count" + parameter is not also present, the recurrence is considered to repeat + forever. + + The "count" parameter defines the number of occurrences at which to + range-bound the recurrence. The "dtstart" parameter counts as the + first occurrence. The "until" and "count" parameters MUST NOT occur + in the same "time" output. + + The "bysecond" parameter specifies a comma-separated list of seconds + within a minute. Valid values are 0 to 59. The "byminute" parameter + specifies a comma-separated list of minutes within an hour. Valid + values are 0 to 59. The "byhour" parameter specifies a comma- + separated list of hours of the day. Valid values are 0 to 23. + + The "byday" parameter specifies a comma-separated list of days of the + week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates + Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA" + indicates Saturday, and "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 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 of days + of the month. Valid values are 1 to 31 or -31 to -1. For example, + -10 represents the tenth to the last day of the month. + + The "byyearday" parameter specifies a comma-separated list of days of + the year. Valid values are 1 to 366 or -366 to -1. For example, -1 + represents the last day of the year (December 31st) and -306 + represents the 306th to the last day of the year (March 1st). + + The "byweekno" parameter specifies a comma-separated list of ordinals + specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. + This corresponds to weeks according to week numbering as defined in + ISO 8601 [20]. A week is defined as a seven day period, starting on + the day of the week defined to be the week start (see "wkst"). Week + number one of the calendar year is the first week which contains at + least four (4) days in that calendar year. This parameter is only + valid for "yearly" rules. For example, 3 represents the third week + of the year. + + + +Lennox, et al. Standards Track [Page 18] + +RFC 3880 CPL October 2004 + + + Note: Assuming a Monday week start, week 53 can only occur when + January 1 is a Thursday or, for leap years, if January 1 is a + Wednesday. + + The "bymonth" parameter specifies a comma-separated list of months of + the year. Valid values are 1 to 12. + + The "wkst" parameter specifies the day on which the work week starts. + Valid values 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 is "MO", following ISO 8601 [20]. + + The "bysetpos" parameter specifies a comma-separated list of values + which corresponds to the nth occurrence within the 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 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 nth occurrence of the + specific occurrence within the set of events specified by the rule. + + If byxxx parameter values are found which are beyond the available + scope (i.e., bymonthday="30" in February), they are simply ignored. + + Byxxx parameters modify the recurrence in some manner. Byxxx rule + parts for a period of time which is the same or greater than the + frequency generally reduce or limit the number of occurrences of the + recurrence generated. For example, freq="daily" bymonth="1" reduces + the number of recurrence instances from all days (if the "bymonth" + parameter is not present) to all days in January. Byxxx parameters + for a period of time less than the frequency generally increase or + expand the number of occurrences of the recurrence. For example, + freq="yearly" bymonth="1,2" increases the number 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" and "interval" parameters, the Byxxx parameters are + applied to the current set of evaluated occurrences in the following + order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday", + "byhour", "byminute", "bysecond", and "bysetpos"; then "count" and + "until" are evaluated. + + + +Lennox, et al. Standards Track [Page 19] + +RFC 3880 CPL October 2004 + + + Here is 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 in January at 8:30 AM and + 9:30 AM, every other year." Then 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 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, the appropriate minute, hour, day, + or month would have been retrieved from the "dtstart" parameter. + + The iCalendar COS RDATE, EXRULE, and EXDATE recurrence rules are not + specifically mapped to components of the time-switch node. + Equivalent functionality to the exception rules can be attained by + using the ordering 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 8) to link multiple + outputs to the same subsequent node. + + The "not-present" output is never true for a time switch. However, + it MAY be included to allow switch processing to be more regular. + +4.4.1. iCalendar Differences and Implementation Issues + + (This sub-sub-section is non-normative.) + + The specification of recurring events in this section is identical + (except for syntax and formatting issues) to that of RFC 2445 [8], + 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 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 compatibility between the two protocols was of primary + importance. This imposes some additional implementation issues on + implementors of CPL servers. + + + + + +Lennox, et al. Standards Track [Page 20] + +RFC 3880 CPL October 2004 + + + It does not appear to be possible to determine, in constant time, + whether a given instant of time falls within one of the intervals + defined by a full iCalendar COS recurrence. The primary concerns are + as follows: + + o The "count" 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 the current recurrence satisfies the + parameter. However, a server can expand a "count" parameter + once, off-line, to determine the date of the last recurrence. + This date can then be treated as a virtual "until" parameter + for the server's internal processing. + + o Similarly, the "bysetpos" parameter requires that the server + enumerate all instances of the occurrence from the start of 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 split up into + several recurrences without them. + + o Finally, constant running time of time switches also requires + that a candidate starting time for a recurrence can be + established quickly and uniquely, to check whether it satisfies + 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 of 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. + + 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. + +4.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 are dependent on the underlying signalling protocol. + + + + + + +Lennox, et al. Standards Track [Page 21] + +RFC 3880 CPL October 2004 + + + Node: "priority-switch" + Outputs: "priority" Specific priority to match + Parameters: None + + Output: "priority" + Parameters: "less" Match if priority is less + than that specified + "greater" Match if priority is greater + than that specified + "equal" Match if priority is equal + to that specified + + Figure 8: Syntax of the "priority-switch" node + + Priority switches take no parameters. + + The "priority" tag takes one of the three parameters "greater", + "less", or "equal". The values of these parameters are one of the + following priorities: in decreasing order, "emergency", "urgent", + "normal", and "non-urgent". These values are matched in a case- + insensitive manner. Outputs with the "less" parameter are taken if + the priority of the call is less than the priority given in the + argument, and so forth. + + If no priority is specified in a message, the priority is considered + to be "normal". If an unknown priority is specified in the call, it + is considered to be equivalent to "normal" for the purposes of + "greater" and "less" comparisons, but it is compared literally for + "equal" comparisons. + + Since every message has a priority, the "not-present" output is never + true for a priority switch. However, it MAY be included, to allow + switch processing to be more regular. + +4.5.1. Usage of "priority-switch" with SIP + + The priority of a SIP message corresponds to the "Priority" header in + the initial "INVITE" message. + +5. Location Modifiers + + The abstract location model of CPL is described in Section 2.3. The + behavior of several of the signalling operations (defined in Section + 6) is dependent on the current location set specified. Location + nodes add or remove locations from the location set. + + + + + + +Lennox, et al. Standards Track [Page 22] + +RFC 3880 CPL October 2004 + + + There are three types of location nodes defined. Explicit locations + add literally-specified locations to the current location set, + location lookups obtain locations from some outside source, and + location filters remove locations from the set, based on some + specified criteria. + +5.1. Explicit Location + + Explicit location nodes specify a location literally. Their syntax + is described in Figure 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 to clear the location set before + adding the new value + + Figure 9: Syntax of the "location" node + + Explicit location nodes have three node parameters. The mandatory + "url" parameter's value is the URL of the address to add to the + location set. Only one address may be specified per location node; + multiple locations may be specified by cascading these nodes. + + The optional "priority" parameter specifies a priority for the + location. Its value is a floating-point number between 0.0 and 1.0. + If it is not specified, the server SHOULD assume a default priority + of 1.0. The optional "clear" 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 the default. + + Basic location nodes have only 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 SHOULD detect this and report it to the user at the + time the script is submitted.) Therefore, their XML representations + do not have explicit output tags; the <location> tag directly + contains another node. + +5.1.1. Usage of "location" with SIP + + All SIP locations are represented as URLs, so the locations specified + in "location" tags are interpreted directly. + + + +Lennox, et al. Standards Track [Page 23] + +RFC 3880 CPL October 2004 + + +5.2. Location Lookup + + Locations can also be specified up through external means, through + the use of location lookups. The syntax of these tags is given in + Figure 10. + + Location lookup 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 the lookup + "timeout" Time to try before giving up on the lookup + "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 the "lookup" node + + Location lookup nodes have one mandatory parameter and two optional + parameters. The mandatory parameter is "source", the source of the + lookup. This can either be a URI, or a non-URI value. If the value + 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 + the IANA registration of this type, which also appears in RFC 2483 + [10]). The query is performed verbatim, with no additional + information (such as URI parameters) added. The server adds the + locations contained in this object to 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 the script at script upload time. + + There has been discussion of having CPL servers add URI parameters + 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 of the base specification. + + + + + +Lennox, et al. Standards Track [Page 24] + +RFC 3880 CPL October 2004 + + + Non-URL sources indicate a source not specified by a URL which the + server can query for addresses to add to the location set. The only + non-URL source currently defined is "registration", which specifies + all the locations currently registered with the server. + + The "lookup" node also has two optional parameters. The "timeout" + parameter specifies the time, as a positive integer number of + seconds, the script is willing to wait for the lookup to be + performed. If this is not specified, its default value is 30. The + "clear" parameter specifies whether the location set should be + cleared before the new locations are added. + + Lookup has three outputs: "success", "notfound", and "failure". + Notfound is taken if the lookup process succeeded but did not find + any locations; failure is taken if the lookup failed for some reason, + including that the specified timeout was exceeded. If a given output + is not present, script execution terminates and the default behavior + is performed. + +5.2.1. Usage of "lookup" with SIP + + For SIP, the "registration" lookup source corresponds to the + locations registered with the server using "REGISTER" messages. + +5.3. Location Removal + + A CPL script can also remove locations from the location set, through + the use of the "remove-location" node. The syntax of this node is + defined in Figure 11. + + The meaning of this node is dependent on the underlying signalling + Protocol. + + Node: "remove-location" + Outputs: None (Next node follows directly) + Next node: Any node + Parameters: "location" Location to remove + + Figure 11: Syntax of the "remove-location" node + + A "remove-location" node removes locations from the location set. It + is primarily useful following a "lookup" node. An example of this is + given in Section 12.8. + + The "remove-location" node has one optional parameter. The parameter + "location" gives the URI of a location to be removed from the set, in + a signalling-protocol-dependent manner. If this parameter is not + given, all locations are removed from the set. + + + +Lennox, et al. Standards Track [Page 25] + +RFC 3880 CPL October 2004 + + + The "remove-location" node has no explicit output tags. In the XML + syntax, the XML "remove-location" tag directly encloses the next + node's tag. + +5.3.1. Usage of "remove-location" with SIP + + The location specified in the "location" parameter of the "remove- + location" node is matched against the location set using the standard + rules for SIP URI matching (as are used, e.g., to match Contact + addresses when refreshing registrations). + +6. Signalling Operations + + Signalling operation nodes cause signalling events in the underlying + signalling protocol. Three signalling operations are defined: + "proxy," "redirect," and "reject." + +6.1. Proxy + + Proxy causes the triggering call to be forwarded on to the currently + specified set of locations. The syntax of the proxy node is given in + Figure 12. + + The specific signalling events invoked by the "proxy" node are + signalling-protocol-dependent, though the general concept should + apply to any signalling protocol. + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 26] + +RFC 3880 CPL October 2004 + + + Node: "proxy" + Outputs: "busy" Next node if call attempt returned "busy" + "noanswer" Next 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: "timeout" Time to try before giving up on the + call attempt + "recurse" Whether to recursively look up + redirections + "ordering" What order to try the location set in. + + Output: "busy" + Parameters: none + + Output: "noanswer" + Parameters: none + + Output: "redirection" + Parameters: none + + Output: "failure" + Parameters: none + + Output: "default" + Parameters: none + + Figure 12: Syntax of the "proxy" node + + 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. + + If the call attempt was successful, CPL execution terminates and the + server proceeds to its default behavior (normally, to allow the call + to be set up). Otherwise, the next node corresponding to one of the + "proxy" node's outputs is taken. The "busy" output is followed if + the call was busy, "noanswer" is followed if the call was not + answered before the "timeout" parameter expired, "redirection" is + followed if the call was redirected, and "failure" is followed if the + call setup failed for any other reason. + + If one of the conditions above is true, but the corresponding output + was not specified, the "default" output of the "proxy" node is + followed instead. If there is also no "default" node specified, CPL + execution terminates and the server returns to its default behavior + (normally, to forward the best response upstream to the originator). + + + +Lennox, et al. Standards Track [Page 27] + +RFC 3880 CPL October 2004 + + + Note: CPL extensions to allow in-call or end-of-call operations + will require an additional output, such as "success", to be added. + + If no locations were present in the set, or if the only locations in + the set were locations to which the server cannot proxy a call (for + example, "http" URLs), the "failure" output is taken. + + Proxy has three optional parameters. The "timeout" parameter + specifies the time, as a positive integer number of seconds, to wait + for the call to be completed or rejected; after this time has + elapsed, the call attempt is terminated and the "noanswer" branch is + taken. If this parameter is not specified, the default value is 20 + seconds if the "proxy" node has a "noanswer" or "default" output + specified; otherwise the server SHOULD allow the call to ring for a + reasonably long period of time (to the maximum extent that server + policy allows). + + The second optional parameter is "recurse", which can take two + values, "yes" or "no". This specifies whether the server should + automatically attempt to place further call attempts to telephony + addresses in redirection responses that were returned from the + initial server. Note that if the value of "recurse" is "yes", the + "redirection" output to the script is never taken. In this case this + output SHOULD NOT be present. The default value of this parameter is + "yes". + + The third optional parameter is "ordering". This can have three + possible values: "parallel", "sequential", and "first-only". This + parameter specifies in what order the locations of the location set + should be tried. Parallel asks that they all be tried + simultaneously; sequential asks that the one with the highest + priority be tried first, the one with the next-highest priority + second, and so forth, until one succeeds or the set is exhausted. + First-only instructs the server to try only the highest-priority + address in the set, and then follow one of the outputs. The priority + of locations in a 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 proxy operation completes, if control is passed on to other + nodes, all locations which have been used are cleared from the + location set. That is, the location set is emptied of proxyable + locations if the "ordering" was "parallel" or "sequential"; the + highest-priority item in the set is removed from the set if + "ordering" was "first-only". (In all cases, non-proxyable locations + such as "http" URIs remain.) In the case of a "redirection" output, + the new addresses to which the call was redirected are then added to + the location set. + + + +Lennox, et al. Standards Track [Page 28] + +RFC 3880 CPL October 2004 + + +6.1.1. Usage of "proxy" with SIP + + For SIP, the best response to a "proxy" node is determined by the + algorithm of the SIP specification. The node's outputs correspond to + the following events: + + busy: A 486 or 600 response was the best response received for the + call request. + + redirection: A 3xx response was the best response received for the + call request. + + failure: Any other 4xx, 5xx, or 6xx response was the best response + received for the call request. + + no-answer: No final response was received for the call request + before the timeout expired. + + SIP servers SHOULD honor the "q" parameter of SIP registrations when + determining location priority. + +6.2. Redirect + + Redirect causes the server to direct the calling party to attempt to + place its call to the currently specified set of locations. The + syntax of this node is specified in Figure 13. + + The specific behavior the redirect node invokes is dependent on the + underlying signalling protocol involved, though its semantics are + generally applicable. + + 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 "redirect" node + + Redirect immediately terminates execution of the CPL script, so this + node has no outputs and no next node. It has one parameter, + "permanent", which specifies whether the result returned should + indicate that this is a permanent redirection. The value of this + parameter is either "yes" or "no" and its default value is "no." + + + + + + + +Lennox, et al. Standards Track [Page 29] + +RFC 3880 CPL October 2004 + + +6.2.1. Usage of "redirect" with SIP + + The SIP server SHOULD send a 3xx class response to a call request + 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). + +6.3. Reject + + Reject nodes cause the server to reject the call attempt. Their + syntax is given in Figure 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 follow) + Next node: None + Parameters: "status" Status code to return + "reason" Reason phrase to return + + Figure 14: Syntax of the "reject" node + + A reject node immediately terminates the execution of a CPL script, + so this 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 the values "busy", + "notfound", "reject", "error", or a signalling-protocol-defined + status. + + The "reason" argument optionally allows the script to specify a + reason for the rejection. + +6.3.1. Usage of "reject" with SIP + + Servers which implement SIP SHOULD also allow the "status" field to + be a numeric argument corresponding to a SIP status in the 4xx, 5xx, + or 6xx range. + + They SHOULD send the "reason" parameter in the SIP reason phrase. + + A suggested mapping of the 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 + + + +Lennox, et al. Standards Track [Page 30] + +RFC 3880 CPL October 2004 + + + "reject": 603 Decline + + "error": 500 Internal Server Error + +7. Non-signalling Operations + + In addition to the signalling operations, CPL defines several + operations which do not affect and are not dependent on the telephony + signalling protocol. + +7.1. Mail + + The mail node causes the server to notify a user of the status of the + CPL script through electronic mail. Its syntax is given in Figure + 15. + + Node: "mail" + Outputs: None (Next node follows directly) + Next node: Any node + Parameters: "url" Mailto url to which the mail should be sent + + Figure 15: Syntax of the "mail" node + + The "mail" node takes one argument: a "mailto" URL giving the + address, and any additional desired parameters, of the mail to be + sent. The server sends the message containing the content to the + given url; it SHOULD also include other status information about the + original call request and the CPL script at the time of the + 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" />. + + A mail node has only one possible result, since failure of e-mail + delivery cannot reliably be known in real time. Therefore, its XML + representation does not have output tags: the <mail> tag directly + contains another node tag. + + Note that the syntax of XML requires that ampersand characters, "&", + which are used as parameter separators in "mailto" URLs, be quoted as + "&" inside parameter values (see Section C.12 of the XML + specification [2]). + + + + + + + + +Lennox, et al. Standards Track [Page 31] + +RFC 3880 CPL October 2004 + + +7.1.1. Suggested Content of Mailed Information + + This section presents suggested guidelines for the mail sent as a + result of the "mail" node, 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. If the "mailto" URI did not specify a subject header, the + subject of the e-mail is "[CPL]", followed by the subject + header of the SIP request. If the URI specified a subject + header, it is used instead. + + 2. The "From" field of the e-mail is set to a CPL server + configured address, overriding any "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 a sip: URI + would be converted to an e-mail address by stripping the URI + scheme). + + 4. If the "mailto" URI specifies a body, it is used. If none was + specified, the body SHOULD contain at least the identity of 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 SHOULD honor the user's requested languages, and send the + mail notification using an appropriate language and character set. + +7.2. Log + + The 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 the log file to use + "comment" Comment to be 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 comment about the + information being logged. Servers SHOULD also include other + information in the log, such as the time of the logged event, + + + +Lennox, et al. Standards Track [Page 32] + +RFC 3880 CPL October 2004 + + + information that triggered the call to be logged, and so forth. Logs + are specific to the owner of the script which logged the event. If + the "name" parameter is not given, the event is logged to a standard, + server-defined log file for the script owner. This specification + does not define how users may retrieve their logs from the server. + + The name of a log is a logical name only, and does not necessarily + correspond to any physical file on the server. The interpretation of + the log file name is server defined, as is a mechanism 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. + + 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 their XML representation does not have explicit output tags. A + CPL <log> tag directly contains another node tag. + +8. 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 17. + + 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 17: Syntax of subactions and "sub" pseudo-nodes + + Subactions are defined through "subaction" tags. These tags are + placed in the CPL script after any ancillary information (see Section + 9), 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 MUST be unique within + that script. + + Subactions are called from "sub" tags. The "sub" tag is a "pseudo- + node", and can be used anyplace in a CPL action that a true node + could be used. It takes one parameter, "ref", the name of the + subaction to be called. The "sub" tag contains no outputs of its + own, instead control passes to the subaction. + + + +Lennox, et al. Standards Track [Page 33] + +RFC 3880 CPL October 2004 + + + References to subactions MUST refer to subactions defined before the + current action. A "sub" tag MUST NOT refer to the action 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 the script is submitted that + no "sub" node refers to any subaction that is not its proper + predecessor. + + Allowing only back-references of subs forbids any sort 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 the same CPL + script. No external links are permitted. + + Subaction IDs are case sensitive. + + If any subsequent version or extension defines external linkages, + it should probably use a different tag, perhaps XLink [21]. + Ensuring termination in the presence of external links is a + difficult problem. + +9. Ancillary Information + + No ancillary information is defined in the base CPL specification. + If ancillary information, not part of any operation, is found to be + necessary for a CPL extension, it SHOULD be placed within this tag. + + The (trivial) definition of the ancillary information tag is given in + Figure 18. + + It may be useful 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 to include them here. + + Tag: "ancillary" + Parameters: None + Subtags: None + + Figure 18: Syntax of the "ancillary" tag + + + + + + + + + +Lennox, et al. Standards Track [Page 34] + +RFC 3880 CPL October 2004 + + +10. Default Behavior + + When a CPL node reaches an unspecified output, either because the + output tag is not present, or because the tag is present but does not + contain a node, the CPL server's behavior is dependent on the current + state of script execution. This section gives 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 the server would use if no CPL script were + in effect. Proxy, redirect, or send a rejection message, + using whatever policy the server would use in the absence 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 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 the addresses in the current location set. If the + location set is empty, return a "notfound" rejection. + + noanswer output of proxy, no timeout given: (This is a special + case.) If the "noanswer" output of a proxy node is + unspecified, and no timeout parameter was given to the proxy + node, the call should be allowed to ring for the maximum + length of time allowed by the server (or the request, if the + request specified a timeout). + + proxy operation previously taken: Return whatever the "best" + response is of all accumulated responses to the call to this + point, according to the rules of the underlying signalling + protocol. + +11. CPL Extensions + + Servers MAY support additional CPL features beyond those listed in + this document. Some of the extensions which have been suggested are + a means 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, and mid-call + or end-of-call controls. + + CPL extensions are indicated by XML namespaces [11]. Every extension + MUST have an appropriate XML namespace assigned to it. The XML + namespace of the extension MUST be different from the XML namespace + + + +Lennox, et al. Standards Track [Page 35] + +RFC 3880 CPL October 2004 + + + defined in Section 14. The extension MUST NOT change the syntax or + semantics of the CPL schema defined in this document. All XML tags + and attributes that are part of the extension MUST be appropriately + qualified so as to place them within that namespace. + + Tags or attributes in a CPL script which are in the global namespace + (i.e., not associated with any namespace) are equivalent to tags and + attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl". + + A CPL script SHOULD NOT specify any namespaces it does not use. For + compatibility with non-namespace-aware parsers, a CPL script MAY omit + the base CPL namespace for a script which does not use any + extensions. + + A CPL server MUST reject any script containing a reference to a + namespace it does not understand. It MUST reject any script + containing an extension tag or attribute that is not qualified to be + in an appropriate namespace. + + A syntax such as + + <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 handling extensions. This + would allow scripts to be uploaded to a server without requiring a + script author to somehow determine which extensions a server + supports. However, experience developing other languages, notably + Sieve [22], was that this added excessive complexity to languages. + The "extension-switch" tag could, of course, itself be defined in + a CPL extension. + + In the XML schema of CPL, we introduce three abstract elements, + namely 'toplevelaction', 'switch', and 'action', which accordingly + have the abstract type 'TopLevelActionType', 'SwitchType', and + 'ActionType'. Any top-level action in a CPL extension MUST be + defined as the substitutionGroup of the abstract 'toplevelaction' + element, and have the type extended from the 'TopLevelActionType'. + Any switch in a CPL extension MUST be defined as the + substitutionGroup of the abstract 'switch' element, and have the type + + + + + +Lennox, et al. Standards Track [Page 36] + +RFC 3880 CPL October 2004 + + + extended from the 'SwitchType'. Any action in a CPL extension MUST + be defined as the substitutionGroup of the abstract 'action' element, + and have the type extended from the 'ActionType'. + +12. Examples + +12.1. Example: Call Redirect Unconditional + + The script in Figure 19 is a simple script that redirects all calls + to a single fixed location. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <incoming> + <location url="sip:smith@phone.example.com"> + <redirect/> + </location> + </incoming> + </cpl> + + Figure 19: Example Script: Call Redirect Unconditional + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 37] + +RFC 3880 CPL October 2004 + + +12.2. Example: Call Forward Busy/No Answer + + 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 how several outputs take the same action + subtree, through the use of subactions. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 38] + +RFC 3880 CPL October 2004 + + +12.3. Example: Call Forward: Redirect and Default + + The script in Figure 21 illustrates further proxy behavior. The + server initially tries to proxy to a single address. If this attempt + 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. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 39] + +RFC 3880 CPL October 2004 + + +12.4. Example: Call Screening + + The script in Figure 22 illustrates address switches 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 does not match, the script does not define any + operations. The server therefore proceeds with its default behavior, + which would presumably be to contact the user. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <incoming> + <address-switch field="origin" subfield="user"> + <address is="anonymous"> + <reject status="reject" reason="I reject anonymous calls"/> + </address> + </address-switch> + </incoming> + </cpl> + + Figure 22: Example Script: Call Screening + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 40] + +RFC 3880 CPL October 2004 + + +12.5. Example: Priority and Language Routing + + The script in Figure 23 illustrates service selection based on a + call's priority value and language settings. If the call request had + a priority of "urgent" or higher, the default script behavior is + performed. Otherwise, the language field is checked for the language + "es" (Spanish). If it is present, the call is proxied to a Spanish- + speaking operator; other calls are proxied to an English-speaking + operator. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 41] + +RFC 3880 CPL October 2004 + + +12.6. Example: Outgoing Call Screening + + The script in Figure 24 illustrates a script filtering outgoing + calls, in the form of a script which prevent 1-900 (premium) calls + from being placed. This script also illustrates subdomain matching. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 42] + +RFC 3880 CPL October 2004 + + +12.7. Example: Time-of-day Routing + + Figure 25 illustrates time-based conditions and timezones. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 43] + +RFC 3880 CPL October 2004 + + +12.8. Example: Location Filtering + + Figure 26 illustrates filtering operations on the location set. In + this example, we assume that version 0.9beta2 of the "Inadequate + Software SIP User Agent" mis-implements some features, and so we must + work around its problems. We know that it cannot talk successfully + to one particular mobile device we may have registered, so we remove + that location from the location set. Once this operation has been + completed, call setup is allowed to proceed normally. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <incoming> + <string-switch field="user-agent"> + <string is="Inadequate Software SIP User Agent/0.9beta2"> + <lookup source="registration"> + <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 + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 44] + +RFC 3880 CPL October 2004 + + +12.9. Example: Non-signalling Operations + + Figure 27 illustrates non-signalling operations; in particular, + alerting a user by electronic mail if the lookup server failed. The + primary motivation for having the "mail" node is to allow this sort + of out-of-band notification of error conditions, as the user might + otherwise be unaware of any problem. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <incoming> + <lookup + source="http://www.example.com/cgi-bin/locate.cgi?user=mary" + timeout="8"> + <success> + <proxy/> + </success> + <failure> + <mail url="mailto:mary@example.com?subject=Lookup%20failed"/> + </failure> + </lookup> + </incoming> + </cpl> + + Figure 27: Example Script: Non-signalling Operations + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 45] + +RFC 3880 CPL October 2004 + + +12.10. Example: Hypothetical Extensions + + The example in Figure 28 shows a hypothetical extension that + implements distinctive ringing. The XML namespace + "http://www.example.com/distinctive-ring" specifies a new node named + "ring". + + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema targetNamespace="http://www.example.com/distinctive-ring" + xmlns="http://www.example.com/distinctive-ring" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:CPL="urn:ietf:params:xml:ns:cpl" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + <xs:import namespace="urn:ietf:params:xml:ns:cpl" + schemaLocation="cpl.xsd"/> + <xs:complexType name="DRingAction"> + <xs:complexContent> + <xs:extension base="CPL:ActionType"> + <xs:attribute name="ringstyle" type="xs:string" + use="optional"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="ring" type="DRingAction" + substitutionGroup="CPL:action"/> + </xs:schema> + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:dr="http://www.example.com/distinctive-ring" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd + http://www.example.com/distinctive-ring distinctive-ring.xsd"> + <incoming> + <address-switch field="origin"> + <address is="sip:boss@example.com"> + <dr:ring ringstyle="warble"/> + </address> + </address-switch> + </incoming> + </cpl> + + Figure 28: Example Schema and Script: Hypothetical + Distinctive-Ringing Extension + + + + + +Lennox, et al. Standards Track [Page 46] + +RFC 3880 CPL October 2004 + + + The example in Figure 29 implements a hypothetical new attribute for + address switches, to allow regular-expression matches. It defines a + new attribute "regex" for the standard "address" node. + + <?xml version="1.0" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 47] + +RFC 3880 CPL October 2004 + + +12.11. Example: A Complex Example + + Finally, Figure 30 is a complex example which shows the sort of + sophisticated behavior that can be achieved by combining CPL nodes. + In this case, the user attempts to have his calls reach his desk; if + he does not answer within a small amount of time, calls from his boss + are forwarded to his 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" encoding="UTF-8"?> + <cpl xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> + <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 + + + + + + + + +Lennox, et al. Standards Track [Page 48] + +RFC 3880 CPL October 2004 + + +13. Security Considerations + + 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. + +14. IANA Considerations + + This document registers a new MIME type, application/cpl+xml, and a + new URN per RFC 2141 [12], RFC 2648 [13], and RFC 3688 [14]. + + The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the + version of CPL in this document and will not change. Any CPL + enhancements MUST be made by extensions and MUST have different + namespaces. + +14.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl + + URI: urn:ietf:params:xml:ns:cpl + + Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu> + Xiaotao Wu <xiaotaow@cs.columbia.edu> + Henning Schulzrinne <hgs@cs.columbia.edu> + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Call Processing Language Namespace</title> + </head> + <body> + + + +Lennox, et al. Standards Track [Page 49] + +RFC 3880 CPL October 2004 + + + <h1>Namespace for Call Processing Language</h1> + <h2>urn:ietf:params:xml:ns:cpl</h2> + <p><a href="ftp://ftp.rfc-editor.org/in-notes/rfc3880.txt"> + RFC3880</a>.</p> + </body> + </html> + END + +14.2. Schema registration + + This specification registers XML Schema for CPL, as per the + guidelines in [14]. + + URI: urn:ietf:params:xml:schema:cpl + + Registrant contact: + Jonathan Lennox <lennox@cs.columbia.edu> + Xiaotao Wu <xiaotaow@cs.columbia.edu> + Henning Schulzrinne <hgs@cs.columbia.edu> + + XML: The XML can be found in Appendix C. + +14.3. MIME Registration + + As an XML type, CPL's MIME registration conforms with "XML Media + Types," RFC 3023 [15]. + + 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 13, 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. + + + +Lennox, et al. Standards Track [Page 50] + +RFC 3880 CPL October 2004 + + + Applications which use this media type: SIP proxy servers and + other telephony servers, and client software to control + their behavior. + + Additional information: + + Magic number: None + + File extension: .cpl or .xml + + Macintosh file type code: "TEXT" + + Person and e-mail address for further information: + Jonathan Lennox <lennox@cs.columbia.edu> + Xiaotao Wu <xiaotaow@cs.columbia.edu> + Henning Schulzrinne <hgs@cs.columbia.edu> + + Intended usage: COMMON + + Author/Change Controller: The IETF. + +15. Acknowledgments + + This document was reviewed and commented upon by the 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 [8], 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 [22], 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. + + + + + + + +Lennox, et al. Standards Track [Page 51] + +RFC 3880 CPL October 2004 + + +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 4.4.1 has been done, it operates in + constant time. Open-source Java code implementing this algorithm is + available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the + world wide web. + + This algorithm is believed to be correct, but this section is non- + normative. Section 4.4, and RFC 2445 [8], 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. + + + + + +Lennox, et al. Standards Track [Page 52] + +RFC 3880 CPL October 2004 + + + 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 [16]. 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 4.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 [23] information element "Calling party + number." If both fields are present, or if multiple alias 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." + + + + + +Lennox, et al. Standards Track [Page 53] + +RFC 3880 CPL October 2004 + + + 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 4.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 4.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 + + + +Lennox, et al. Standards Track [Page 54] + +RFC 3880 CPL October 2004 + + + representation and mapping of transport addresses is not + defined for non-IP addresses. + + H.323 [16] defines an "h323" URI scheme. This appendix defines a + mapping for these URIs onto the CPL "address-switch" subfields, as + given in Section 4.1. This definition is also available as RFC 3508 + [24], which is an excerpt from the H.323 specification. + + For h323 URIs, 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 4.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 [23] 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 H.323 messages are considered to have priority "normal" for the + purpose of a priority switch (see Section 4.5). + + + + + + + + + +Lennox, et al. Standards Track [Page 55] + +RFC 3880 CPL October 2004 + + +B.5. Usage of "location" with H.323 + + Locations in explicit location nodes (Section 5.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 alias types will require a CPL + extension (see Section 11). + +B.6. Usage of "lookup" with H.323 + + For location lookup nodes (Section 5.2), the "registration" lookup + source corresponds to the locations registered with the server using + "RAS" messages. + +B.7. Usage of "remove-location" with H.323 + + Location removal nodes (Section 5.3) remove addresses with the alias + type "url-ID" using verbatim string matching on the URLs. If a "tel" + URL is specified as the location, matching addresses (ignoring visual + separators) with the alias types "dialedDigits" ("e164"), + "partyNumber", "mobileUIM", or "Q.931IE" are also removed. No + mechanism is provided to remove other alias types. + +C. The XML Schema for CPL + + This section includes a full XML Schema describing the XML syntax of + CPL. Every script submitted to a CPL server SHOULD comply with this + XML Schema. When parsing scripts comply with the CPL DTD in earlier + documents, the DOCTYPE lines in the scripts should be ignored. Note + that compliance with this schema is not a sufficient condition for + correctness of a CPL script, as many of the conditions described in + this specification are not expressible in schema syntax. Figure 31 + shows the structure of the schema. 'incoming' and 'outgoing' are + defined as the substitutionGroup of the 'toplevelaction'. All the + switches are defined as the substitutionGroup of the 'switch' + element. All the actions are defined as the substitutionGroup of the + 'action' element. + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 56] + +RFC 3880 CPL October 2004 + + + +---------+ +------+ +--address + +-+ancillary| |switch|** +--------------+ | +-not-present + | +---------+ +---+--+ **|address-switch+-+-+-address + | | * +--------------+ +--otherwise + | +---------+ +----+ | * +--language + +-+subaction+-+Node| | * +---------------+ | +-not-present + | +---------+ +----+ | **|language-switch|-+-+-language + | | * +---------------+ +--otherwise + | | * +--priority + | | * +---------------+ | +-not-present + | | **|priority-switch|-+-+-priority + | | * +---------------+ +--otherwise + | | * +--string + cpl-+ | * +-------------+ | +-not-present + | | **|string-switch|-+ +-string + | | * +-------------+ +--otherwise + | | * +--time + | +--------------+ +-+--+ * +-----------+ | +-not-present + +-+toplevelaction+-+Node| *|time-switch|-+-+-time + +-----*--------+ +-+--+ +-----------+ +--otherwise + * | +--------+ +----+ + * | **|location+-|Node| + * | +--------+ * +--------+ +----+ + * +--------+ |-+modifier|** +------+ +-success-Node + **|incoming| | +--------+ *-|lookup+-+-notfound-Node + * +--------+ | * +------+ +-failure-Node + * | +---+ * +---------------+ +----+ + * +--------+ +-+Sub+-sub **|remove-location+-+Node| + *|outgoing| | +---+ +---------------+ +----+ + +--------+ | +---+ + | **|log+-Node + | * +---+ + | * +----+ + | +------+ **|mail+-Node + +-+action|** +----+ +-busy-Node + ---- contains +------+ * +-----+ | + **|proxy+----+-noanswer-Node + **** substitutes * +-----+ | + * +--------+ +-failure-Node + **|redirect| | + * +--------+ +-redirection-Node + * +------+ | + *|reject| +-default-Node + +------+ + + Figure 31: The structure of the XML schema for CPL + + + + + +Lennox, et al. Standards Track [Page 57] + +RFC 3880 CPL October 2004 + + + BEGIN + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl" + xmlns="urn:ietf:params:xml:ns:cpl" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + <xs:complexType name="TopLevelActionType" abstract="true"> + <xs:group ref="Node"/> + </xs:complexType> + <xs:element name="toplevelaction" type="TopLevelActionType"/> + <xs:complexType name="ActionType" abstract="true"/> + <xs:element name="action" type="ActionType"/> + <xs:complexType name="SwitchType" abstract="true"/> + <xs:element name="switch" type="SwitchType"/> + <xs:complexType name="ModifierType" abstract="true"/> + <xs:element name="modifier" type="ModifierType"/> + <xs:element name="location" type="LocationType" + substitutionGroup="modifier"/> + <xs:element name="lookup" type="LookupType" + substitutionGroup="modifier"/> + <xs:element name="remove-location" type="RemoveLocationType" + substitutionGroup="modifier"/> + <xs:element name="sub" type="SubAction"/> + <xs:group name="Node"> + <xs:choice> + <xs:element ref="switch" minOccurs="0" maxOccurs="1"/> + <xs:element ref="modifier" minOccurs="0" maxOccurs="1"/> + <xs:element ref="sub" minOccurs="0" maxOccurs="1"/> + <xs:element ref="action" minOccurs="0" maxOccurs="1"/> + </xs:choice> + </xs:group> + <xs:complexType name="OtherwiseAction"> + <xs:group ref="Node"/> + </xs:complexType> + <xs:complexType name="NotPresentAction"> + <xs:group ref="Node"/> + </xs:complexType> + <xs:simpleType name="YesNoType"> + <xs:restriction base="xs:NMTOKEN"> + <xs:enumeration value="yes"/> + <xs:enumeration value="no"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType name="StatusType"> + <xs:union> + <xs:simpleType> + <xs:restriction base="xs:NMTOKEN"> + + + +Lennox, et al. Standards Track [Page 58] + +RFC 3880 CPL October 2004 + + + <xs:enumeration value="busy"/> + <xs:enumeration value="notfound"/> + <xs:enumeration value="reject"/> + <xs:enumeration value="error"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType> + <xs:restriction base="xs:string"/> + </xs:simpleType> + </xs:union> + </xs:simpleType> + <xs:simpleType name="OrderingType"> + <xs:restriction base="xs:NMTOKEN"> + <xs:enumeration value="parallel"/> + <xs:enumeration value="sequential"/> + <xs:enumeration value="first-only"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType name="AddressFieldType"> + <xs:union> + <xs:simpleType> + <xs:restriction base="xs:NMTOKEN"> + <xs:enumeration value="origin"/> + <xs:enumeration value="destination"/> + <xs:enumeration value="original-destination"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType> + <xs:restriction base="xs:string"/> + </xs:simpleType> + </xs:union> + </xs:simpleType> + <xs:simpleType name="AddressSubfieldType"> + <xs:union> + <xs:simpleType> + <xs:restriction base="xs:NMTOKEN"> + <xs:enumeration value="address-type"/> + <xs:enumeration value="user"/> + <xs:enumeration value="host"/> + <xs:enumeration value="port"/> + <xs:enumeration value="tel"/> + <xs:enumeration value="display"/> + <xs:enumeration value="password"/> + <xs:enumeration value="alias-type"/> + </xs:restriction> + </xs:simpleType> + + + + + +Lennox, et al. Standards Track [Page 59] + +RFC 3880 CPL October 2004 + + + <xs:simpleType> + <xs:restriction base="xs:string"/> + </xs:simpleType> + </xs:union> + </xs:simpleType> + <xs:complexType name="AddressType"> + <xs:annotation> + <xs:documentation>Exactly one of the three attributes must + appear</xs:documentation> + </xs:annotation> + <xs:group ref="Node"/> + <xs:attribute name="is" type="xs:string" use="optional"/> + <xs:attribute name="contains" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>for "display" only</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="subdomain-of" type="xs:string" + use="optional"> + <xs:annotation> + <xs:documentation>for "host", "tel" only</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + <xs:complexType name="AddressSwitchType"> + <xs:complexContent> + <xs:extension base="SwitchType"> + <xs:sequence> + <xs:element name="address" type="AddressType" minOccurs="0" + maxOccurs="unbounded"/> + <xs:sequence minOccurs="0"> + <xs:element name="not-present" type="NotPresentAction"/> + <xs:element name="address" type="AddressType" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:element name="otherwise" type="OtherwiseAction" + minOccurs="0"/> + </xs:sequence> + <xs:attribute name="field" type="AddressFieldType" + use="required"/> + <xs:attribute name="subfield" type="AddressSubfieldType" + use="optional"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="address-switch" type="AddressSwitchType" + substitutionGroup="switch"/> + + + +Lennox, et al. Standards Track [Page 60] + +RFC 3880 CPL October 2004 + + + <xs:simpleType name="StringFieldType"> + <xs:restriction base="xs:NMTOKEN"> + <xs:enumeration value="subject"/> + <xs:enumeration value="organization"/> + <xs:enumeration value="user-agent"/> + <xs:enumeration value="display"/> + </xs:restriction> + </xs:simpleType> + <xs:complexType name="StringType"> + <xs:group ref="Node"/> + <xs:attribute name="is" type="xs:string" use="optional"/> + <xs:attribute name="contains" type="xs:string" use="optional"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + <xs:complexType name="StringSwitchType"> + <xs:complexContent> + <xs:extension base="SwitchType"> + <xs:sequence> + <xs:element name="string" type="StringType" minOccurs="0" + maxOccurs="unbounded"/> + <xs:sequence minOccurs="0"> + <xs:element name="not-present" type="NotPresentAction"/> + <xs:element name="string" type="StringType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + <xs:element name="otherwise" type="OtherwiseAction" + minOccurs="0"/> + </xs:sequence> + <xs:attribute name="field" type="StringFieldType" + use="required"> + <xs:annotation> + <xs:documentation>Strings are matched as case-insensitive + Unicode strings.</xs:documentation> + </xs:annotation> + </xs:attribute> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="string-switch" type="StringSwitchType" + substitutionGroup="switch"/> + <xs:complexType name="LanguageType"> + <xs:group ref="Node"/> + <xs:attribute name="matches" type="xs:string" use="required"> + <xs:annotation> + <xs:documentation>The value of one of these parameters is a + language-tag, as defined in RFC + 3066.</xs:documentation> + </xs:annotation> + + + +Lennox, et al. Standards Track [Page 61] + +RFC 3880 CPL October 2004 + + + </xs:attribute> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + <xs:complexType name="LanguageSwitchType"> + <xs:complexContent> + <xs:extension base="SwitchType"> + <xs:sequence> + <xs:element name="language" type="LanguageType" + minOccurs="0" maxOccurs="unbounded"/> + <xs:sequence minOccurs="0"> + <xs:element name="not-present" type="NotPresentAction"/> + <xs:element name="language" type="LanguageType" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:element name="otherwise" type="OtherwiseAction" + minOccurs="0"/> + </xs:sequence> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="language-switch" type="LanguageSwitchType" + substitutionGroup="switch"/> + <xs:simpleType name="FreqType"> + <xs:restriction base="xs:NMTOKEN"> + <xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/> + <xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/> + <xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/> + <xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/> + <xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/> + <xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/> + <xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType name="YearDayType"> + <xs:union> + <xs:simpleType> + <xs:restriction base="xs:integer"> + <xs:minInclusive value="-366"/> + <xs:maxInclusive value="-1"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType> + <xs:restriction base="xs:integer"> + <xs:minInclusive value="1"/> + <xs:maxExclusive value="366"/> + </xs:restriction> + </xs:simpleType> + </xs:union> + + + +Lennox, et al. Standards Track [Page 62] + +RFC 3880 CPL October 2004 + + + </xs:simpleType> + <xs:simpleType name="DayType"> + <xs:restriction base="xs:NMTOKEN"> + <xs:pattern value="[m|M][o|O]"/> + <xs:pattern value="[t|T][u|U]"/> + <xs:pattern value="[w|W][e|E]"/> + <xs:pattern value="[t|T][h|H]"/> + <xs:pattern value="[f|F][r|R]"/> + <xs:pattern value="[s|S][a|A]"/> + <xs:pattern value="[s|S][u|U]"/> + </xs:restriction> + </xs:simpleType> + <xs:complexType name="TimeType"> + <xs:annotation> + <xs:documentation>Exactly one of the two attributes "dtend" and + "duration" must occur. None of the attributes following + freq are meaningful unless freq appears. + </xs:documentation> + </xs:annotation> + <xs:group ref="Node"/> + <xs:attribute name="dtstart" type="xs:string" use="required"> + <xs:annotation> + <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="dtend" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="duration" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>RFC 2445 DURATION</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="freq" type="FreqType" use="optional"/> + <xs:attribute name="interval" type="xs:positiveInteger" + default="1"/> + <xs:attribute name="until" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="count" type="xs:positiveInteger" + use="optional"/> + <xs:attribute name="bysecond" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of seconds within a + + + +Lennox, et al. Standards Track [Page 63] + +RFC 3880 CPL October 2004 + + + minute. Valid values are 0 to 59.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="byminute" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of minutes within an + hour. Valid values are 0 to 59.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="byhour" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of hours of the day. + Valid values are 0 to 23.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="byday" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of days of the week. + Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and + "SU". These values are not case-sensitive. Each can be + preceded by a positive (+n) or negative (-n) + integer.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="bymonthday" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of days of the month. + Valid values are 1 to 31 or -31 to + -1.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="byyearday" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of days of the year. + Valid values are 1 to 366 or -366 to + -1.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="byweekno" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of ordinals specifying + weeks of the year. Valid values are 1 to 53 or -53 to + -1.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="bymonth" type="xs:string" use="optional"> + <xs:annotation> + <xs:documentation>Comma-separated list of months of the year. + + + +Lennox, et al. Standards Track [Page 64] + +RFC 3880 CPL October 2004 + + + Valid values are 1 to 12.</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:attribute name="wkst" type="DayType" default="MO"/> + <xs:attribute name="bysetpos" type="YearDayType"/> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + <xs:simpleType name="TZIDType"> + <xs:restriction base="xs:string"/> + </xs:simpleType> + <xs:simpleType name="TZURLType"> + <xs:restriction base="xs:anyURI"/> + </xs:simpleType> + <xs:complexType name="TimeSwitchType"> + <xs:complexContent> + <xs:extension base="SwitchType"> + <xs:sequence> + <xs:element name="time" type="TimeType" minOccurs="0" + maxOccurs="unbounded"/> + <xs:sequence minOccurs="0"> + <xs:element name="not-present" type="NotPresentAction"/> + <xs:element name="time" type="TimeType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + <xs:element name="otherwise" type="OtherwiseAction" + minOccurs="0"/> + </xs:sequence> + <xs:attribute name="tzid" type="TZIDType"/> + <xs:attribute name="tzurl" type="TZURLType"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="time-switch" type="TimeSwitchType" + substitutionGroup="switch"/> + <xs:simpleType name="PriorityValues"> + <xs:restriction base="xs:NMTOKEN"> + <xs:pattern + value="[e|E][m|M][e|E][r|R][g|G][e|E][n|N][c|C][y|Y]"/> + <xs:pattern value="[u|U][r|R][g|G][e|E][n|N][t|T]"/> + <xs:pattern value="[n|N][o|O][r|R][m|M][a|A][l|L]"/> + <xs:pattern + value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/> + </xs:restriction> + </xs:simpleType> + <xs:complexType name="PriorityType"> + <xs:annotation> + <xs:documentation>Exactly one of the three attributes must + appear </xs:documentation> + + + +Lennox, et al. Standards Track [Page 65] + +RFC 3880 CPL October 2004 + + + </xs:annotation> + <xs:group ref="Node"/> + <xs:attribute name="less" type="PriorityValues"/> + <xs:attribute name="greater" type="PriorityValues"/> + <xs:attribute name="equal" type="xs:string"> + <xs:annotation> + <xs:documentation>case-insensitive</xs:documentation> + </xs:annotation> + </xs:attribute> + <xs:anyAttribute namespace="##any" processContents="lax"/> + </xs:complexType> + <xs:complexType name="PrioritySwitchType"> + <xs:complexContent> + <xs:extension base="SwitchType"> + <xs:sequence> + <xs:element name="priority" type="PriorityType" + minOccurs="0" maxOccurs="unbounded"/> + <xs:sequence minOccurs="0"> + <xs:element name="not-present" type="NotPresentAction"/> + <xs:element name="priority" type="PriorityType" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:element name="otherwise" type="OtherwiseAction" + minOccurs="0"/> + </xs:sequence> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="priority-switch" type="PrioritySwitchType" + substitutionGroup="switch"/> + <xs:simpleType name="LocationPriorityType"> + <xs:restriction base="xs:float"> + <xs:minInclusive value="0.0"/> + <xs:maxInclusive value="1.0"/> + </xs:restriction> + </xs:simpleType> + <xs:complexType name="LocationType"> + <xs:complexContent> + <xs:extension base="ModifierType"> + <xs:group ref="Node"/> + <xs:attribute name="url" type="xs:anyURI" use="required"/> + <xs:attribute name="priority" type="LocationPriorityType" + use="optional" default="1.0"/> + <xs:attribute name="clear" type="YesNoType" default="no"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:complexType name="LookupType"> + + + +Lennox, et al. Standards Track [Page 66] + +RFC 3880 CPL October 2004 + + + <xs:complexContent> + <xs:extension base="ModifierType"> + <xs:all> + <xs:element name="success" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + <xs:element name="notfound" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + <xs:element name="failure" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + </xs:all> + <xs:attribute name="source" type="xs:string" + use="required"/> + <xs:attribute name="timeout" type="xs:positiveInteger" + default="30"/> + <xs:attribute name="clear" type="YesNoType" default="no"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:complexType name="RemoveLocationType"> + <xs:complexContent> + <xs:extension base="ModifierType"> + <xs:group ref="Node"/> + <xs:attribute name="location" type="xs:string" + use="optional"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:complexType name="LogAction"> + <xs:complexContent> + <xs:extension base="ActionType"> + <xs:group ref="Node"/> + <xs:attribute name="name" type="xs:string" use="optional"/> + <xs:attribute name="comment" type="xs:string" + use="optional"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="log" type="LogAction" + substitutionGroup="action"/> + + + +Lennox, et al. Standards Track [Page 67] + +RFC 3880 CPL October 2004 + + + <xs:complexType name="IncomingType"> + <xs:complexContent> + <xs:extension base="TopLevelActionType"/> + </xs:complexContent> + </xs:complexType> + <xs:element name="incoming" type="IncomingType" + substitutionGroup="toplevelaction"/> + <xs:complexType name="OutgoingType"> + <xs:complexContent> + <xs:extension base="TopLevelActionType"/> + </xs:complexContent> + </xs:complexType> + <xs:element name="outgoing" type="OutgoingType" + substitutionGroup="toplevelaction"/> + <xs:complexType name="ProxyAction"> + <xs:complexContent> + <xs:extension base="ActionType"> + <xs:all> + <xs:element name="busy" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + <xs:element name="noanswer" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + <xs:element name="failure" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + <xs:element name="redirection" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + <xs:element name="default" minOccurs="0"> + <xs:complexType> + <xs:group ref="Node"/> + </xs:complexType> + </xs:element> + </xs:all> + <xs:attribute name="timeout" type="xs:positiveInteger" + use="optional" default="20"/> + <xs:attribute name="recurse" type="YesNoType" + use="optional" default="yes"/> + + + +Lennox, et al. Standards Track [Page 68] + +RFC 3880 CPL October 2004 + + + <xs:attribute name="ordering" type="OrderingType" + use="optional" default="parallel"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="proxy" type="ProxyAction" + substitutionGroup="action"/> + <xs:complexType name="RedirectAction"> + <xs:complexContent> + <xs:extension base="ActionType"> + <xs:attribute name="permanent" type="YesNoType" + default="no"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="redirect" type="RedirectAction" + substitutionGroup="action"/> + <xs:complexType name="RejectAction"> + <xs:complexContent> + <xs:extension base="ActionType"> + <xs:attribute name="status" type="StatusType" + use="required"/> + <xs:attribute name="reason" type="xs:string" + use="optional"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="reject" type="RejectAction" + substitutionGroup="action"/> + <xs:complexType name="MailAction"> + <xs:complexContent> + <xs:extension base="ActionType"> + <xs:group ref="Node"/> + <xs:attribute name="url" type="xs:anyURI" use="required"/> + </xs:extension> + </xs:complexContent> + </xs:complexType> + <xs:element name="mail" type="MailAction" + substitutionGroup="action"/> + <xs:complexType name="SubAction"> + <xs:attribute name="ref" type="xs:string" use="required"/> + </xs:complexType> + <xs:complexType name="AncillaryType"/> + <xs:complexType name="SubactionType"> + <xs:group ref="Node"/> + <xs:attribute name="id" use="required"/> + </xs:complexType> + <xs:complexType name="CPLType"> + + + +Lennox, et al. Standards Track [Page 69] + +RFC 3880 CPL October 2004 + + + <xs:sequence> + <xs:element name="ancillary" type="AncillaryType" minOccurs="0" + maxOccurs="1"/> + <xs:element name="subaction" type="SubactionType" minOccurs="0" + maxOccurs="unbounded"/> + <xs:element ref="toplevelaction" minOccurs="0" + maxOccurs="unbounded"> + <xs:annotation> + <xs:documentation>Any toplevel action MUST NOT appear more + than once.</xs:documentation> + </xs:annotation> + </xs:element> + </xs:sequence> + </xs:complexType> + <xs:element name="cpl" type="CPLType"/> + </xs:schema> + END + +Normative References + + [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [2] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. + Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", + W3C Recommendation REC-xml-20040204, World Wide Web Consortium + (W3C), February 2004. Available at http://www.w3.org/XML/. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [5] Davis, M. F. and M. Duerst, "Unicode Normalization Forms", + Unicode Standard Annex #15, Unicode Consortium, April 2003. + Revision 23; part of Unicode 4.0.0. Available at + http://www.unicode.org/unicode/reports/tr15/. + + [6] Davis, M. F., "Case Mappings", Unicode Standard Annex #21, + Unicode Consortium, March 2001. Revision 5; part of Unicode + 3.2.0. Available at + http://www.unicode.org/unicode/reports/tr21/. + + [7] Alvestrand, H., "Tags for the Identification of Languages", BCP + 47, RFC 3066, January 2001. + + + + +Lennox, et al. Standards Track [Page 70] + +RFC 3880 CPL October 2004 + + + [8] Dawson, F. and D. Stenerson, "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", RFC 2445, + November 1998. + + [9] Eggert, P., "Sources for Time Zone and Daylight Saving Time + Data". Available at http://www.twinsun.com/tz/tz-link.htm. + + [10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary + for URN Resolution", RFC 2483, January 1999. + + [11] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C + Recommendation REC-xml-names-19990114, World Wide Web Consortium + (W3C), January 1999. Available at http://www.w3.org/TR/REC- + xml-names/. + + [12] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, + August 1999. + + [14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January + 2004. + + [15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC + 3023, January 2001. + +Informative References + + [16] International Telecommunication Union, "Packet-based multimedia + communication systems", Recommendation H.323, Telecommunication + Standardization Sector of ITU, Geneva, Switzerland, July 2003. + + [17] Lennox, J. and H. Schulzrinne, "Call Processing Language + Framework and Requirements", RFC 2824, May 2000. + + [18] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 + Specification", W3C Recommendation REC-html401-19991224, World + Wide Web Consortium (W3C), December 1999. Available at + http://www.w3.org/TR/html4/. + + [19] ISO (International Organization for Standardization), + "Information processing -- Text and office systems -- Standard + Generalized Markup Language (SGML)", ISO Standard ISO + 8879:1986(E), International Organization for Standardization, + Geneva, Switzerland, October 1986. + + + + + + +Lennox, et al. Standards Track [Page 71] + +RFC 3880 CPL October 2004 + + + [20] ISO (International Organization for Standardization), "Data + elements and interchange formats -- Information interchange -- + Representation of dates and times", ISO Standard ISO + 8601:2000(E), International Organization for Standardization, + Geneva, Switzerland, December 2000. + + [21] DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML + Linking Language (XLink) Version 1.0", W3C Recommendation REC- + xlink-20010627, World Wide Web Consortium (W3C), June 2001. + Available at http://www.w3.org/TR/xlink/. + + [22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, + January 2001. + + [23] 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, International Telecommunication Union, Geneva, + Switzerland, March 1993. + + [24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme + Registration", RFC 3508, April 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 72] + +RFC 3880 CPL October 2004 + + +Authors' Addresses + + Jonathan Lennox + Dept. of Computer Science + Columbia University + 1214 Amsterdam Avenue, MC 0401 + New York, NY 10027 + USA + + EMail: lennox@cs.columbia.edu + + + Xiaotao Wu + Dept. of Computer Science + Columbia University + 1214 Amsterdam Avenue, MC 0401 + New York, NY 10027 + USA + + EMail: xiaotaow@cs.columbia.edu + + + Henning Schulzrinne + Dept. of Computer Science + Columbia University + 1214 Amsterdam Avenue, MC 0401 + New York, NY 10027 + USA + + EMail: schulzrinne@cs.columbia.edu + + + + + + + + + + + + + + + + + + + + + +Lennox, et al. Standards Track [Page 73] + +RFC 3880 CPL October 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Lennox, et al. Standards Track [Page 74] + |