idnits 2.17.1 draft-ietf-iptel-cpl-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 366: '...t-present, which MAY occur anywhere in...' RFC 2119 keyword, line 369: '... which MUST be the last output speci...' RFC 2119 keyword, line 401: '...invoked. Servers MAY define additional...' RFC 2119 keyword, line 405: '...ay. Additional subfield values MAY be...' RFC 2119 keyword, line 410: '...otocol. Servers MAY define additional...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 391 has weird spacing: '...main-of sub...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2000) is 8658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 2013 looks like a reference -- Missing reference section? '2' on line 2017 looks like a reference -- Missing reference section? '3' on line 2021 looks like a reference -- Missing reference section? '4' on line 2026 looks like a reference -- Missing reference section? '5' on line 2030 looks like a reference -- Missing reference section? '6' on line 2034 looks like a reference -- Missing reference section? '7' on line 2038 looks like a reference -- Missing reference section? '8' on line 2044 looks like a reference -- Missing reference section? '9' on line 2048 looks like a reference -- Missing reference section? '10' on line 2052 looks like a reference -- Missing reference section? '11' on line 2057 looks like a reference -- Missing reference section? '12' on line 2063 looks like a reference -- Missing reference section? '13' on line 2067 looks like a reference -- Missing reference section? '14' on line 2071 looks like a reference -- Missing reference section? '15' on line 2075 looks like a reference -- Missing reference section? 'ISO 8601' on line 804 looks like a reference -- Missing reference section? '16' on line 2079 looks like a reference -- Missing reference section? '17' on line 2083 looks like a reference -- Missing reference section? '18' on line 2088 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IPTEL WG 3 Internet Draft Lennox/Schulzrinne 4 draft-ietf-iptel-cpl-02.txt Columbia University 5 July 14, 2000 6 Expires: January, 2001 8 CPL: A Language for User Control of Internet Telephony Services 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Call Processing Language (CPL) is a language that can be used to 34 describe and control Internet telephony services. It is designed to 35 be implementable on either network servers or user agent servers. It 36 is meant to be simple, extensible, easily edited by graphical 37 clients, and independent of operating system or signalling protocol. 38 It is suitable for running on a server where users may not be allowed 39 to execute arbitrary programs, as it has no variables, loops, or 40 ability to run external programs. 42 This document is a product of the IP Telephony (IPTEL) working group 43 of the Internet Engineering Task Force. Comments are solicited and 44 should be addressed to the working group's mailing list at 45 iptel@lists.research.bell-labs.com and/or the authors. 47 1 Introduction 49 The Call Processing Language (CPL) is a language that can be used to 50 describe and control Internet telephony services. It is not tied to 51 any particular signalling architecture or protocol; it is anticipated 52 that it will be used with both SIP [1] and H.323 [2]. 54 The CPL is powerful enough to describe a large number of services and 55 features, but it is limited in power so that it can run safely in 56 Internet telephony servers. The intention is to make it impossible 57 for users to do anything more complex (and dangerous) than describing 58 Internet telephony services. The language is not Turing-complete, and 59 provides no way to write loops or recursion. 61 The CPL is also designed to be easily created and edited by graphical 62 tools. It is based on XML [3], so parsing it is easy and many 63 parsers for it are publicly available. The structure of the language 64 maps closely to its behavior, so an editor can understand any valid 65 script, even ones written by hand. The language is also designed so 66 that a server can easily confirm scripts' validity at the time they 67 are delivered to it, rather that discovering them while a call is 68 being processed. 70 Implementations of the CPL are expected to take place both in 71 Internet telephony servers and in advanced clients; both can usefully 72 process and direct users' calls. This document primarily addresses 73 the usage in servers. A mechanism will be needed to transport scripts 74 between clients and servers; this document does not describe such a 75 mechanism, but related documents will. 77 The framework and requirements for the CPL architecture are described 78 in RFC 2824, "Call Processing Language Framework and Requirements." 79 [4]. 81 1.1 Conventions of this document 83 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 84 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 85 and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and 86 indicate requirement levels for compliant CPL implementations. 88 In examples, non-XML strings such as -action1, -action2, and so 89 forth, are sometimes used. These represent further parts of the 90 script which are not relevant to the example in question. 92 Some paragraphs are indented, like this; they give 93 motivations of design choices, or questions for future 94 discussion in the development of the CPL, and are not 95 essential to the specification of the language. 97 2 Structure of CPL scripts 99 2.1 High-level structure 101 A CPL script consists of two types of information: ancillary 102 information about the script, and call processing actions. 104 A call processing action is a structured tree that describes the 105 decisions and actions a telephony signalling server performs on a 106 call set-up event. There are two types of call processing actions: 107 top-level actions are actions that are triggered by signalling events 108 that arrive at the server. Two top-level action names are defined: 109 incoming, the action performed when a call arrives whose destination 110 is the owner of the script; and outgoing, the action performed when a 111 call arrives whose originator is the owner of the script. Sub-actions 112 are actions which can be called from other actions. The CPL forbids 113 sub-actions from being called recursively: see section 9. 115 Note: The names "action," "sub-action," and "top-level 116 action" are probably not ideal. Suggestions for better 117 names for these concepts are welcomed. 119 Ancillary information is information which is necessary for a server 120 to correctly process a script, but which does not directly describe 121 any actions. Currently, no ancillary information is defined, but the 122 section is reserved for future extensions. 124 2.2 Abstract structure of a call processing action 126 Abstractly, a call processing action is described by a collection of 127 nodes, which describe actions that can be performed or choices which 128 can be made. A node may have several parameters, which specify the 129 precise behavior of the node; they usually also have outputs, which 130 depend on the result of the condition or action. 132 For a graphical representation of a CPL action, see figure 1. Nodes 133 and outputs can be thought of informally as boxes and arrows; the CPL 134 is designed so that actions can be conveniently edited graphically 135 using this representation. Nodes are arranged in a tree, starting at 136 a single root node; outputs of nodes are connected to additional 137 nodes. When an action is run, the action or condition described by 138 the top-level node is performed; based on the result of that node, 139 the server follows one of the node's outputs, and that action or 140 condition is performed; this process continues until a node with no 141 specified outputs is reached. Because the graph is acyclic, this 142 will occur after a bounded and predictable number of nodes are 143 visited. 145 If an output to a node is not specified, it indicates that the CPL 146 server should perform a node- or protocol-specific action. Some nodes 147 have specific default actions associated with them; for others, the 148 default action is implicit in the underlying signalling protocol, or 149 can be configured by the administrator of the server. For further 150 details on this, see section 11. 152 _________________ ___________________ ________ busy 153 | Address-switch | | location | | proxy |--------\ 154 Call --->| field: origin | ->| url: sip:jones@ |--->|timeout:| timeout| 155 | subfield: host | / | example.com | | 10s |--------| 156 |-----------------|/ |___________________| | | failure| 157 | subdomain-of: | |________|--------| 158 | example.com | | 159 |-----------------| _____________________________________________/ 160 | otherwise | /.......................................... 161 | |\|. Voicemail . 162 |_________________| \. ____________________ . 163 ->| location | __________ . 164 . | url: sip:jones@ | | redirect | . 165 . | voicemail. |--->| | . 166 . | example.com | |__________| . 167 . |____________________| . 168 .......................................... 170 Figure 1: Sample CPL Action: Graphical Version 172 2.3 Location model 174 For flexibility, one piece of information necessary for the function 175 of a CPL is not given as node parameters: the set of locations to 176 which a call is to be directed. Instead, this set of locations is 177 stored as an implicit global variable throughout the execution of a 178 processing action (and its sub-actions). This allows locations to be 179 retrieved from external sources, filtered, and so forth, without 180 requiring general language support for such actions (which could harm 181 the simplicity and tractability of understanding the language). The 182 specific actions which add, retrieve, or filter location sets are 183 given in section 6. 185 For the incoming top-level processing action, the location set is 186 initialized to the empty set. For the outgoing action, it is 187 initialized to the destination address of the call. 189 2.4 XML structure 191 Syntactically, CPL scripts are represented by XML documents. XML is 192 thoroughly specified by [3], and implementors of this specification 193 should be familiar with that document, but as a brief overview, XML 194 consists of a hierarchical structure of tags; each tag can have a 195 number of attributes. It is visually and structurally very similar to 196 HTML [6], as both languages are simplifications of the earlier and 197 larger standard SGML [7]. 199 See figure 2 for the XML document corresponding to the graphical 200 representation of the CPL script in figure 1. Both nodes and outputs 201 in the CPL are represented by XML tags; parameters are represented by 202 XML tag attributes. Typically, node tags contain output tags, and 203 vice-versa (with one exception; see section 2.3). 205 The connection between the output of a node and another node is 206 represented by enclosing the tag representing the pointed-to node 207 inside the tag for the outer node's output. Convergence (several 208 outputs pointing to a single node) is represented by sub-actions, 209 discussed further in section 9. 211 The higher-level structure of a CPL script is represented by tags 212 corresponding to each piece of meta-information, sub-actions, and 213 top-level actions, in order. This higher-level information is all 214 enclosed in a special tag cpl, the outermost tag of the XML document. 216 A complete Document Type Declaration for the CPL is provided in 217 Appendix A. The remainder of the main sections of this document 218 describe the semantics of the CPL, while giving its syntax 219 informally. For the formal syntax, please see the appendix. 221 3 Document information 223 This section gives meta-information about CPL scripts. 225 3.1 CPL Document Identifiers for XML 227 A CPL script list which appears as a top-level XML document is 228 identified with the formal public identifier "-//IETF//DTD RFCxxxx 229 CPL 1.0//EN". If this document is published as an RFC, "xxxx" will be 230 replaced by the RFC number. 232 233 235 236 237 238 239 240 242 243 244
245 246 247 248 249 250 251 252
253 254 255 256
257
258
260 Figure 2: Sample CPL Script: XML Version 262 An CPL embedded as a fragment within another XML document is 263 identified with the XML namespace identifier 264 "http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-02.txt". 265 If this document is published as an RFC, the namespace identifier 266 will be "http://www.rfc-editor.org/rfc/rfcxxxx.txt", where xxxx is 267 the RFC number. 269 Note that the URIs specifying XML namespaces are only 270 globally unique names; they do not have to reference any 271 particular actual object. The URI of a canonical source of 272 this specification meets the requirement of being globally 273 unique, and is also useful to document the format. 275 3.2 MIME Registration 276 As an XML type, CPL's MIME registration conforms with "XML Media 277 Types" [8] as well as RFC 2048 [9]. 279 MIME media type name: application 281 MIME subtype name: cpl+xml 283 Mandatory parameters: none 285 Optional parameters: charset 286 As for application/xml in "XML Media Types." 288 Encoding considerations: As for application/xml in "XML Media 289 Types." 291 Security considerations: See section 13, and section 10 of "XML 292 Media Types." 294 Interoperability considerations: Different CPL servers may use 295 incompatible address types. However, all potential 296 interoperability issues should be resolvable at the time a 297 script is uploaded; there should be no interoperability 298 issues which cannot be detetected until runtime. 300 Published specification: This document. 302 Applications which use this media type: None publically released 303 at this time, as far as the authors are aware. 305 Additional information: 307 Magic number: None 309 File extension: .cpl or .xml 311 Macintosh file type code: "TEXT" 313 Person and e-mail address for further information: 314 Jonathan Lennox 315 Henning Schulzrinne 317 Intended usage: COMMON 319 Author/Change Controller: The IETF. 321 4 Script structure: overview 323 As mentioned, a CPL script consists of ancillary information, 324 subactions, and top-level actions. The full syntax of the cpl node is 325 given in figure 3. 327 Tag: cpl 328 Parameters: none 329 Sub-tags: ancillary See section 10 330 subaction See section 9 331 outgoing Top-level actions to take on this user's 332 outgoing calls 333 incoming Top-level actions to take on this user's 334 incoming calls 336 Output: outgoing 337 Parameters: none 339 Output: incoming 340 Parameters: none 342 Figure 3: Syntax of the top-level cpl tag 344 Call processing actions, both top-level actions and sub-actions, 345 consist of nodes and outputs. Nodes and outputs are both described by 346 XML tags. There are four categories of CPL nodes: switches , which 347 represent choices a CPL script can make; location modifiers , which 348 add or remove locations from the location set; signalling actions , 349 which cause signalling events in the underlying protocol; and non- 350 signalling actions, which take an action but do not effect the 351 underlying protocol. 353 5 Switches 355 Switches represent choices a CPL script can make, based on either 356 attributes of the original call request or items independent of the 357 call. 359 All switches are arranged as a list of conditions that can match a 360 variable. Each condition corresponds to a node output; the output 361 points to the next node to execute if the condition was true. The 362 conditions are tried in the order they are presented in the script; 363 the output corresponding to the first node to match is taken. 365 There are two special switch outputs that apply to every switch type. 366 The output not-present, which MAY occur anywhere in the list of 367 outputs, is true if the variable the switch was to match was not 368 present in the original call setup request. The output otherwise, 369 which MUST be the last output specified if it is present, matches if 370 no other condition matched. 372 If no condition matches and no otherwise output was present in the 373 script, the default script action is taken. See section 11 for more 374 information on this. 376 5.1 Address switches 378 Address switches allow a CPL script to make decisions based on one of 379 the addresses present in the original call request. They are 380 summarized in figure 4. 382 Node: address-switch 383 Outputs: address Specific addresses to match 384 Parameters: field origin, destination, or original-destination 385 subfield address-type, user, host, port, tel, display, 386 password, or alias-type 388 Output: address 389 Parameters: is exact match 390 contains substring match (for display only) 391 subdomain-of sub-domain match (for host, tel only) 393 Figure 4: Syntax of the address-switch node 395 Address switches have two node parameters: field, and subfield. The 396 mandatory field parameter allows the script to specify which address 397 is to be considered for the switch: either the call's origin address 398 (field "origin"), its current destination address (field 399 "destination"), or its original destination (field "original- 400 destination"), the destination the call had before any earlier 401 forwarding was invoked. Servers MAY define additional field values. 403 The optional subfield specifies what part of the address is to be 404 considered. The possible subfield values are: address-type, user, 405 host, port, tel, and display. Additional subfield values MAY be 406 defined: two additional ones, password and asn1 are defined 407 specifically for SIP and H.323 respectively, in sections 5.1.1 and 408 5.1.2 below. If no subfield is specified, the "entire" address is 409 matched; the precise meaning of this is defined for each underlying 410 signalling protocol. Servers MAY define additional subfield values. 412 The subfields are defined as follows: 414 address-type This indicates the type of the underlying address; 415 i.e., the URI scheme, if the address can be represented by 416 a URI. The types specifically discussed by this document 417 are sip, tel, and h323. The address type is not case- 418 sensitive. It has a value for all defined address types. 420 user This subfield of the address indicates, for e-mail style 421 addresses, the user part of the address. For telephone 422 number style address, it includes the subscriber number. 423 This subfield is case-sensitive; it may be not present. 425 host This subfield of the address indicates the Internet host 426 name or IP address corresponding to the address, in host 427 name, IPv4, or IPv6 format. For host names only, subdomain 428 matching is supported with the subdomain-of match operator. 429 It is not case sensitive, and may be not present. 431 port This subfield indicates the TCP or UDP port number of the 432 address, numerically in decimal format. It is not case 433 sensitive, as it MUST only contain decimal digits. It may 434 be not present; however, for address types with default 435 ports, an absent port matches the default port number. 437 tel This subfield indicates a telephone subscriber number, if 438 the address contains such a number. It is not case 439 sensitive (the telephone numbers may contain the symbols 440 `A' `B' `C' and `D'), and might not be present. It may be 441 matched using the subdomain-of match operator. Punctuation 442 and separator characters in telephone numbers are 443 discarded. 445 display This subfield indicates a "display name" or user-visible 446 name corresponding to an address. It is a Unicode string, 447 and is matched using the case-insensitive algorithm 448 described in section 5.2. The contains operator may be 449 applied to it. It may be not present. 451 For any completely unknown subfield, the server MAY reject the script 452 at the time it is submitted with an indication of the problem; if a 453 script with an unknown subfield is executed, the server MUST consider 454 the not-present output to be the valid one. 456 The address output tag may take exactly one of three possible 457 parameters, indicating the kind of matching allowed. 459 is An output with this match operator is followed if the 460 subfield being matched in the address-switch exactly 461 matches the argument of the operator. It may be used for 462 any subfield, or for the entire address if no subfield was 463 specified. 465 subdomain-of This match operator applies only for the subfields 466 host and tel. In the former case, it matches if the 467 hostname being matched is a subdomain of the domain given 468 in the argument of the match operator; thus, subdomain- 469 of="example.com" would match the hostnames "example.com", 470 "research.example.com", and 471 "zaphod.sales.internal.example.com". IP addresses may be 472 given as arguments to this operator; however, they only 473 match exactly. In the case of the tel subfield, the output 474 matches if the telephone number being matched has a prefix 475 that matches the argument of the match operator; 476 subdomain-of="1212555" would match the telephone number "1 477 212 555 1212." 479 contains This match operator applies only for the subfield 480 display. The output matches if the display name being 481 matched contains the argument of the match as a substring. 483 5.1.1 Address switch mapping for SIP 485 For SIP, the origin address corresponds to the address in the From 486 header; destination corresponds to the Request-URI; and original- 487 destination corresponds to the To header. 489 The display subfield of an address is the display-name part of the 490 address, if it is present. Because of SIP's syntax, the destination 491 address field will never have a display subfield. 493 The address-type subfield of an address is the URI scheme of that 494 address. Other address fields depend on that address-type. 496 For sip URLs, the user, host, and port subfields correspond to the 497 "user," "host," and "port" elements of the URI syntax. The tel 498 subfield is defined to be the "user" part of the URI if and only if 499 the "user=phone" parameter is given to the URI. An additional 500 subfield, password is defined to correspond to the "password" element 501 of the SIP URI; however, use of this field is NOT RECOMMENDED for 502 general security reasons. 504 For tel URLs, the tel and user subfields are the subscriber name; in 505 the former case, visual separators are stripped. The host and port 506 subfields are both not present. 508 For h323 URLs, the subfields are set as in section 5.1.2 below. 510 For other URI schemes, only the address-type subfield is defined by 511 this specification; servers MAY set other pre-defined subfields, or 512 MAY support additional subfields. 514 If no subfield is specified for addresses in SIP messages, the string 515 matched is the URI part of the address. For "sip" URLs, all 516 parameters are stripped; for other URLs, the URL is used verbatim. 518 5.1.2 Address switch mapping for H.323 520 For H.323, the origin address corresponds to the primary alias 521 address in the sourceAddress field of the Setup-UUIE user-user 522 information element, and to the Q.931 information element 523 callingPartyNumber. If both fields are present, which one has 524 priority is a matter of local server policy; the server SHOULD use 525 the same resolution as it would use for routing decisions in this 526 case. Similarly, the destination address corresponds to the primary 527 alias address of the destinationAddress field, and to the Q.931 528 information element calledPartyNumber. 530 This discussion is based on H.323 version 4 [10], which is expected 531 to be approved in November 2000. 533 The original-destination address corresponds to the redirectedNumber 534 Q.931 information element, if it is present; otherwise it is the same 535 as the destination address. 537 The mapping of H.323 addresses into subfields depends on the type of 538 the alias address. An additional subfield type, alias-type, is 539 defined for H.323 servers, corresponding to the type of the address. 540 Possible values are dialedDigits, h323-ID, url-ID, transportID, 541 email-ID, partyNumber, mobileUIM, and Q.931IE. If future versions of 542 the H.323 specification define additional types of alias addresses, 543 those names MAY also be used. 545 In versions of H.323 prior to version 4, dialedDigits was known as 546 e164. The new name should be used. 548 The value of the address-type subfield for H.323 messages is "h323" 549 unless the alias type is url-ID and the URL scheme is something other 550 than h323; in this case the address-type is the URL scheme, as 551 specified above for SIP. 553 If an alias address of type h323-ID is present anywhere among the 554 sequence of aliases, the first such h323-ID alias address is used for 555 the display subfield of the address. The values of all other 556 subfields depend only on the first alias address in the sequence. 558 The following mappings are used for H.323 alias types: 560 dialedDigits, partyNumber, mobileUIM, and Q.931IE: the tel and 561 user subfields are the string of digits, as is the 562 "entire-address" form. The host and port subfields are not 563 present. 565 url-ID with a "h323" URI: the user, host, and port subfields are 566 set to the corresponding parts of the H.323 URL. The tel 567 subfield is not present. The "entire-address" form 568 corresponds to the entire URI. 570 url-ID with other URI schemes: the same mapping is used as for 571 SIP, above. 573 email-ID: the user and host subfields are set to the 574 corresponding parts of the e-mail address. The port and tel 575 subfields are not present. The "entire-address" form 576 corresponds to the entire e-mail address. 578 transportID: if the TransportAddress is of type "ipAddress," 579 "ipSourceRoute," or "ip6Address," the host subfield is set 580 to the "ip" element of the sequence, translated into the 581 standard IPv4 or IPv6 textual representation, and the port 582 subfield is set to the "port" element of the sequence 583 represented in decimal. The tel and user fields are not 584 present. The "entire-address" form is not defined. The 585 representation and mapping of transport addresses is not 586 defined for non-IP addresses. 588 5.2 String switches 590 String switches allow a CPL script to make decisions based on free- 591 form Unicode strings present in a call request. They are summarized 592 in figure 5. 594 String switches have one node parameter: field. The mandatory field 595 parameter specifies which string is to be matched. 597 Currently five fields are defined. Three fields are currently 598 applicable only to SIP, one is currently applicable only to H.323, 599 and one is applicable to both. 601 The three fields which are applicable only to SIP are: subject, 602 indicating the subject of the call; organization, indicating the 603 Node: string-switch 604 Outputs: string Specific string to match 605 Parameters: field subject, organization, user-agent, 606 language, or display 608 Output: string 609 Parameters: is exact match 610 contains substring match 612 Figure 5: Syntax of the string-switch node 614 originator's organization; and user-agent, indicating the program or 615 device with which the call request was made. All these fields 616 correspond to the contents of the SIP header fields with the same 617 names. 619 The field applicable only to H.323 is display, which corresponds to 620 the Q.931 information element of the same name. 622 This is conventionally used for Caller-ID purposes, so 623 arguably it should be mapped to the display subfield of an 624 address-match with the field originator. However, since a) 625 it is a message-level information element, not an address- 626 level one, and b) the Q.931 specification [11] says only 627 that "[t]he purpose of the Display information element is 628 to supply display information that may be displayed by the 629 user," it seems to be more appropriate to match it as a 630 string instead. 632 The field appropriate both to SIP and H.323 is language. This field 633 contains a list of RFC 1766 [12] language tags, separated by commas, 634 corresponding to the SIP Accept-Language header and the H.323 635 language UUIE. 637 Note that matching based on contains is likely to be much 638 more useful than matching based on is, for this field. 640 Strings are matched as case-insensitive Unicode strings, in the 641 following manner. First, strings are canonicalized to the 642 "Compatibility Composition" (KC) form, as specified in Unicode 643 Technical Report 15 [13]. Then, strings are compared using locale- 644 insensitive caseless mapping, as specified in Unicode Technical 645 Report 21 [14]. 647 Code to perform the first step, in Java and Perl, is 648 available; see the links from Annex E of UTR 15 [13]. The 649 case-insensitive string comparison in the Java standard 650 class libraries already performs the second step; other 651 Unicode-aware libraries should be similar. 653 The output tags of string matching are named string, and have a 654 mandatory argument, one of is or contains, indicating whole-string 655 match or substring match, respectively. 657 5.3 Time switches 659 Time switches allow a CPL script to make decisions based the time 660 and/or date the script is being executed. They are summarized in 661 figure 6. 663 Node: time-switch 664 Outputs: time Specific time to match 665 Parameters: tzid RFC 2445 Time Zone Identifier 666 tzurl RFC 2445 Time Zone URL 668 Output: time 669 Parameters: dtstart Start of interval (RFC 2445 DATE-TIME) 670 dtend End of interval (RFC 2445 DATE-TIME) 671 duration Length of interval (RFC 2445 DURATION) 672 freq Frequency of recurrence (one of "secondly", 673 "minutely", "hourly", "daily", "weekly", 674 "monthly", or "yearly") 675 interval How often the recurrence repeats 676 until Bound of recurrence (RFC 2445 DATE-TIME) 677 count Number of occurences of recurrence 678 bysecond List of seconds within a minute 679 byminute List of minutes within an hour 680 byhour List of hours of the day 681 byday List of days of the week 682 bymonthday List of days of the month 683 byyearday List of days of the year 684 byweekno List of weeks of the year 685 bymonth List of months of the year 686 wkst First day of week 687 bysetpos List of values within set of events specified 689 Figure 6: Syntax of the time-switch node 690 Time switches are based closely on the specification of recurring 691 intervals of time from the Internet Calendaring and Scheduling Core 692 Object Specification (iCal COS), RFC 2445 [15]. 694 This allows CPLs to be generated automatically from 695 calendar books. It also allows us to re-use the extensive 696 existing work specifying time intervals. 698 The time-switch tag takes two optional parameters, tzid and tzurl, 699 both of which are defined in RFC 2445 (sections 4.8.3.1 and 4.8.3.5 700 respectively). The TZID is the identifying label by which a time zone 701 definition is referenced. If it begins with a forward slash 702 (solidus), it references a to-be-defined global time zone registry; 703 otherwise it is locally-defined at the server. The TZURL gives a 704 network location from which an up-to-date VTIMEZONE definition for 705 the timezone can be retrieved. 707 If a script is uploaded with a tzid and tzurl which the CPL server 708 does not recognize or cannot resolve, it SHOULD diagnose and reject 709 this at script upload time. If neither tzid nor tzurl are present, 710 all non-UTC times within this time switch should be interpreted as 711 being "floating" times, i.e. that they are specified in the local 712 timezone of the CPL server. 714 Because of daylight-savings-time changes over the course of 715 a year, it is necessary to specify time switches in a given 716 timezone. UTC offsets are not sufficient, or a time-of-day 717 routing rule which held between 9 am and 5 pm in the 718 eastern United States would start holding between 8 am and 719 4 pm at the end of October. 721 Authors of CPL servers should be careful to handle correctly the 722 intervals when local time is discontinuous, at the beginning or end 723 of daylight-savings time. 725 Time nodes specify a list of periods during which their output should 726 be taken. They have two required parameters: dtstart, which specifies 727 the beginning of the first period of the list, and exactly one of 728 dtend or duration, which specify the ending time or the duration of 729 the period, respectively. The dtstart and dtend parameters are 730 formatted as iCal COS DATE-TIME values, as specified in section 4.3.5 731 of RFC 2445. The duration parameter is given as an iCal COS DURATION 732 parameter, as specified in section 4.3.6 of RFC 2445. 734 If no other parameters are specified, a time node indicates only a 735 single period of time. More complicated sets periods intervals are 736 constructed as recurrences. A recurrence is specified by including 737 the freq parameter, which indicates the type of recurrence rule. No 738 parameters other than dtstart, dtend, and duration SHOULD be 739 specified unless freq is present. 741 The freq parameter takes one of the following values: secondly, to 742 specify repeating periods based on an interval of a second or more; 743 minutely, to specify repeating periods based on an interval of a 744 minute or more; hourly, to specify repeating periods based on an 745 interval of an hour or more; daily, to specify repeating periods 746 based on an interval of a day or more; weekly, to specify repeating 747 periods based on an interval of a week or more; monthly, to specify 748 repeating periods based on an interval of a month or more; and 749 yearly, to specify repeating periods based on an interval of a year 750 or more. These values are not case-sensitive. 752 The interval parameter contains a positive integer representing how 753 often the recurrence rule repeats. The default value is "1", meaning 754 every second for a secondly rule, or every minute for a minutely 755 rule, every hour for an hourly rule, every day for a daily rule, 756 every week for a weekly rule, every month for a monthly rule and 757 every year for a yearly rule. 759 The until parameter defines an iCal COS DATE or DATE-TIME value which 760 bounds the recurrence rule in an inclusive manner. If the value 761 specified by until is synchronized with the specified recurrence, 762 this date or date-time becomes the last instance of the recurrence. 763 If specified as a date-time value, then it MUST be specified in an 764 UTC time format. If not present, and the count parameter is also not 765 present, the recurrence is considered to repeat forever. 767 The count parameter defines the number of occurrences at which to 768 range-bound the recurrence. The dtstart parameter counts as the first 769 occurrence. The until and count parameters MUST NOT occur in the same 770 time output. 772 The bysecond parameter specifies a comma-separated list of seconds 773 within a minute. Valid values are 0 to 59. The byminute parameter 774 specifies a comma-separated list of minutes within an hour. Valid 775 values are 0 to 59. The byhour parameter specifies a comma-separated 776 list of hours of the day. Valid values are 0 to 23. 778 The byday parameter specifies a comma-separated list of days of the 779 week. MO indicates Monday; TU indicates Tuesday; WE indicates 780 Wednesday; TH indicates Thursday; FR indicates Friday; SA indicates 781 Saturday; SU indicates Sunday. These values are not case-sensitive. 783 Each byday value can also be preceded by a positive (+n) or negative 784 (-n) integer. If present, this indicates the nth occurrence of the 785 specific day within the monthly or yearly recurrence. For example, 786 within a monthly rule, +1MO (or simply 1MO) represents the first 787 Monday within the month, whereas -1MO represents the last Monday of 788 the month. If an integer modifier is not present, it means all days 789 of this type within the specified frequency. For example, within a 790 monthly rule, MO represents all Mondays within the month. 792 The bymonthday parameter specifies a comma-separated list of days of 793 the month. Valid values are 1 to 31 or -31 to -1. For example, -10 794 represents the tenth to the last day of the month. 796 The byyearday parameter specifies a comma-separated list of days of 797 the year. Valid values are 1 to 366 or -366 to -1. For example, -1 798 represents the last day of the year (December 31st) and -306 799 represents the 306th to the last day of the year (March 1st). 801 The byweekno parameter specifies a comma-separated list of ordinals 802 specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. 803 This corresponds to weeks according to week numbering as defined in 804 [ISO 8601]. A week is defined as a seven day period, starting on the 805 day of the week defined to be the week start (see wkst). Week number 806 one of the calendar year is the first week which contains at least 807 four (4) days in that calendar year. This parameter is only valid for 808 yearly rules. For example, 3 represents the third week of the year. 810 Note: Assuming a Monday week start, week 53 can only occur 811 when Thursday is January 1 or if it is a leap year and 812 Wednesday is January 1. 814 The bymonth parameter specifies a comma-separated list of months of 815 the year. Valid values are 1 to 12. 817 The wkst parameter specifies the day on which the workweek starts. 818 Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant 819 when a weekly recurrence has an interval greater than 1, and a byday 820 parameter is specified. This is also significant in a yearly 821 recurrence when a byweekno parameter is specified. The default value 822 is MO. 824 The bysetpos parameter specifies a comma-separated list of values 825 which corresponds to the nth occurrence within the set of events 826 specified by the rule. Valid values are 1 to 366 or -366 to -1. It 827 MUST only be used in conjunction with another byxxx parameter. For 828 example "the last work day of the month" could be represented as: 830