Network Working Group J. Lennox
Request for Comments: 3880 X. Wu
Category: Standards Track H. Schulzrinne
Columbia University
October 2004
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
呼叫处理语言（CPL）：一种用于用户控制互联网电话服务的语言
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
本文档定义了呼叫处理语言（CPL），一种描述和控制互联网电话服务的语言。它被设计成可以在网络服务器或用户代理上实现。它意味着简单、可扩展、易于由图形客户端编辑，并且独立于操作系统或信令协议。它适合在不允许用户执行任意程序的服务器上运行，因为它没有变量、循环或运行外部程序的能力。
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
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
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
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
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）是一种可用于描述和控制互联网电话服务的语言。它与任何特定的信令架构或协议无关；预计它将与会话发起协议（SIP）[1]和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功能强大，足以描述大量服务和功能，但它的功能有限，因此可以在Internet电话服务器中安全运行。其目的是让用户不可能做任何比描述互联网电话服务更复杂（和危险）的事情。该语言不是图灵完备的，并且没有提供编写循环或递归的方法。
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.
CPL也被设计为易于通过图形工具创建和编辑。它基于可扩展标记语言（XML）[2]，因此解析它很容易，许多解析器都是公开的。
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.
CPL的实现预计将在互联网电话服务器和高级客户端中进行；两者都可以有效地处理和引导用户的呼叫。本文档主要介绍在服务器中的使用。需要一种机制在客户端和服务器之间传输脚本；本文件未描述此类机制，但相关文件将予以说明。
The framework and requirements for the CPL architecture are described in RFC 2824, "Call Processing Language Framework and Requirements" [17].
RFC 2824“呼叫处理语言框架和要求”[17]中描述了CPL体系结构的框架和要求。
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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照BCP 14、RFC 2119[3]中的描述进行解释，并指出符合CPL实施的要求级别。
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.
有些段落缩进，如下所示；它们给出了设计选择的动机、对实现者的建议，或对CPL的未来开发或扩展的想法。它们对于语言的规范不是必需的，并且是非规范性的。
A CPL script consists of two types of information: ancillary information about the script, and call processing actions.
CPL脚本由两类信息组成：关于脚本的辅助信息和调用处理操作。
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.
呼叫处理操作是一个结构化的树，它描述电话信令服务器对呼叫设置事件执行的操作和决策。有两种类型的调用处理操作：顶级操作和子操作。顶级操作是通过向到达服务器的事件发送信号而触发的操作。定义了两个顶级操作：“传入”，即当目标为脚本所有者的呼叫到达时执行的操作，“传出”，即当发起人为脚本所有者的呼叫到达时执行的操作。
Subactions are actions which can be called from other actions. CPL forbids subactions from being called recursively: see Section 8.
子动作是可以从其他动作调用的动作。CPL禁止递归调用子动作：参见第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.
辅助信息是服务器正确处理脚本所必需的信息，但并不直接描述任何操作或决策。目前，未定义任何辅助信息，但该节保留供扩展使用。
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.
有关CPL操作的图形表示，请参见图1。节点和输出可以非正式地看作是框和箭头；CPL的设计是为了使用这种表示法方便地以图形方式编辑动作。节点排列在树中，从单个根节点开始；节点的输出连接到其他节点。运行某个操作时，执行该操作的顶级节点描述的操作或决策；基于该节点的结果，服务器跟踪该节点的一个输出，并执行其指向的后续节点；此过程将继续，直到到达没有指定输出的节点。由于该图是非循环的，因此在访问了有限数量且可预测的节点之后，将发生这种情况。
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.
如果一个节点的输出没有指向另一个节点，则表明CPL服务器应该执行特定于节点或协议的操作。某些节点具有与之关联的特定默认行为；对于其他人，默认行为隐含在底层信令协议中，或者可以由服务器管理员配置。有关这方面的更多详细信息，请参见第10节。
_________________ ___________________ ________ 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 | |__________| .
. |____________________| .
........................................
_________________ ___________________ ________ 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
图1：示例CPL操作：图形版本
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.
为了灵活性，CPL所需的一条信息不作为节点参数提供：调用要定向到的位置集。相反，在整个处理操作（及其子操作）的执行过程中，此位置集存储为隐式全局变量。这允许从外部源检索位置、过滤位置等，而无需此类操作的通用语言支持（这可能会损害理解语言的简单性和易处理性）。第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.
对于传入的顶级调用处理操作，位置集被初始化为空集。对于传出操作，它被初始化为调用的目标地址。
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].
在语法上，CPL脚本由XML文档表示。XML完全由XML规范[2]指定，该规范的实现者应该熟悉该文档。然而，作为一个简要概述，XML由标记的层次结构组成；每个标记可以有许多属性。它在视觉上和结构上非常类似于HTML[18]，因为这两种语言都是早期和更大的标准SGML[19]的简化。
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).
请参见图2，了解与图1中CPL脚本的图形表示相对应的XML文档。CPL中的节点和输出都用XML标记表示；参数由XML标记属性表示。通常，节点标记包含输出标记，反之亦然（少数例外：请参见第5.1、5.3、7.1和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.
一个节点的输出和另一个节点之间的连接是通过将表示指向节点的标记封装在外部节点输出的标记内来表示的。收敛（多个输出指向单个节点）由子作用表示，在第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.
CPL脚本的高级结构由对应于每一条辅助信息、子动作和顶级动作的标签按顺序表示。这些高级信息都包含在一个特殊的标记“cpl”中，cpl是XML文档的最外层标记。
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.
附录C中提供了CPL的完整XML模式。本文档的其余主要部分描述了CPL的语义，同时非正式地给出了其语法。有关正式语法，请参见附录。
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.
如前所述，CPL脚本由辅助信息、子操作和顶级操作组成。图3给出了“cpl”节点的完整语法。
<?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>
<?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>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</incoming>
</cpl>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</incoming>
</cpl>
Figure 2: Sample CPL Script: XML Version
图2：示例CPL脚本：XML版本
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
标记：“cpl”参数：无子标记：“辅助”请参阅第9节“子操作”请参阅第8节“传出”顶级操作以处理此用户的传出呼叫“传入”顶级操作以处理此用户的传入呼叫
Figure 3: Syntax of the top-level "cpl" tag
图3：顶级“cpl”标记的语法
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.
调用处理动作（包括顶级动作和子动作）由节点和输出树组成。节点和输出都由XML标记描述。CPL节点分为四类：交换机（表示CPL脚本可以做出的选择）、位置修饰符（用于从位置集中添加或删除位置）、信令操作（导致基础协议中发生信令事件）和非信令操作，触发不影响基础协议的行为。
Switches represent choices a CPL script can make, based on either attributes of the original call request or items independent of the call.
开关表示CPL脚本可以根据原始调用请求的属性或独立于调用的项做出的选择。
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.
所有开关都排列为可匹配变量的条件列表。每个条件对应一个节点输出；如果条件为true，则输出指向应执行的下一个节点。按照脚本中呈现的顺序尝试条件；获取与要匹配的第一个节点对应的输出。
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".)
有两种特殊的开关输出适用于每种开关类型。如果开关要匹配的变量在原始呼叫设置请求中不存在，则输出“不存在”（可能出现在输出列表中的任何位置）为真。（在本文件中，有时描述为信息“缺失”。）
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.
如果没有条件匹配，并且脚本中没有“否则”输出，则采用默认脚本行为。有关这方面的更多信息，请参见第10节。
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.
这种开关不是特别有用，但可以由自动生成CPL脚本的工具创建。
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.
地址开关允许CPL脚本根据原始调用请求中的一个地址做出决定。图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")
输出：“address”参数：“is“Exact match”包含“Sub-domain match”（用于“主机”、“电话”）的“Sub-domain match”（子字符串匹配）（仅用于“显示”）子域
Figure 4: Syntax of the "address-switch" node
图4：“地址开关”节点的语法
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.
地址开关有两个节点参数：“字段”和“子字段”。强制的“field”参数允许脚本指定要为交换机考虑的地址：呼叫的起始地址（字段“origin”）、当前目的地址（字段“destination”）或原始目的地（字段“original destination”）、调用任何早期转发之前呼叫的目的地。服务器可以定义其他字段值。
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
可选的“子字段”指定要考虑地址的哪一部分。可能的子字段值为：“地址类型”、“用户”、“主机”、“端口”、“电话”和“显示”。可以为协议特定值定义附加子字段值。（第4.1.1节中为SIP定义了子字段“密码”；附录B.1中为H.323定义了子字段“别名类型”。）
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.
地址类型：如果地址可以用URI表示，则表示基础地址的类型，即URI方案。本文件具体讨论的类型为“sip”、“tel”和“h323”。地址类型不区分大小写。它对所有定义的地址类型都有一个值。
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.
主机：地址的此子字段以主机名、IPv4或IPv6[4]文本表示格式指示与地址对应的Internet主机名或IP地址。主机名作为字符串进行比较。IP地址进行了数字比较。（特别是，IPv6:：省略的零位块的存在或位置对于匹配目的来说并不重要。）主机名永远不等于IP地址——不执行DNS解析。IPv4地址永远不等于IPv6地址，即使IPv6地址是v4-in-v6嵌入。此子字段不区分大小写，可能不存在。
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.
仅对于主机名，“subdomain of”匹配运算符支持子域匹配。“subdomain of”操作符忽略主机名或匹配模式（如果有）中的前导点。
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.
端口：此子字段以十进制数字格式指示地址的TCP或UDP端口号。它不区分大小写，因为它只能包含十进制数字。前导零被忽略。
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.
电话：如果地址包含电话用户号码，则此子字段表示电话用户号码。它不区分大小写（电话号码可能包含符号“A”、“B”、“C”或“D”），并且可能不存在。它可以使用“子域”匹配运算符进行匹配。电话号码中的标点符号和分隔符将被丢弃。
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.
显示：此子字段表示与地址对应的“显示名称”或用户可见名称。它是一个Unicode字符串，使用第4.2节中描述的不区分大小写的算法进行匹配。“contains”运算符可以应用于它。它可能缺席。
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.
“address”输出标记可能正好采用三个可能参数中的一个，指示允许的匹配类型。
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.
is：如果在“地址开关”中匹配的子字段与运算符的参数完全匹配，则跟随此匹配运算符的输出。它可用于任何子字段，如果未指定子字段，则可用于整个地址。
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."
子域：此匹配运算符仅适用于子字段“主机”和“电话”。在前一种情况下，如果要匹配的主机名是匹配运算符参数中给定的域的子域，则匹配；因此，=“example.com”的子域将匹配主机名“example.com”、“research.example.com”和“zaphod.sales.internal.example.com”。IP地址可以作为参数提供给该运算符；然而，它们只完全匹配。在“tel”子字段的情况下，如果正在匹配的电话号码具有与匹配运算符的参数匹配的前缀，则输出匹配；=“1212555”的子域将与电话号码“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.
包含：此匹配运算符仅适用于子字段“显示”。如果匹配的显示名称包含匹配的参数作为子字符串，则输出匹配。
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.
对于SIP，“源”地址对应于“发件人”报头中的地址，“目的地”对应于“请求URI”，“原始目的地”对应于“收件人”报头。
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.
地址的“显示”子字段是地址的显示名称部分（如果存在）。由于SIP的语法，“目的地”地址字段永远不会有“显示”子字段。
The "address-type" subfield of an address is the URI scheme of that address. Other address fields depend on that "address-type".
地址的“地址类型”子字段是该地址的URI方案。其他地址字段取决于该“地址类型”。
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.
对于SIPURI，“用户”、“主机”和“端口”子字段对应于URI语法的“用户”、“主机”和“端口”元素。（注意，根据RFC 3261[1]的定义，未指定端口的SIP URI与显式端口5060不同；前者由缺少的端口子字段表示。）“tel”子字段被定义为URI的“用户”部分，如果“user=phone”参数被赋予URI，则去掉可视分隔符，或者如果服务器配置为将用户部件识别为电话号码。另外一个子字段“password”被定义为与SIP URI的“password”元素相对应，并且区分大小写。但是，出于一般安全原因，不建议使用此字段。
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.
对于电话URL，“电话”和“用户”子字段是订户名称；在前一种情况下，可视分离器被剥离。“主机”和“端口”子字段都不存在。
For h323 URLs, subfields MAY be set according to the scheme described in Appendix B.
对于h323 URL，可以根据附录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.
对于其他URI方案，本规范仅定义“地址类型”子字段；服务器可以设置其他预定义子字段，也可以支持其他子字段。
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.
如果没有为SIP消息中的地址指定子字段，则匹配的字符串是地址的URI部分。对于“is”匹配，使用标准SIPURI匹配规则；对于“contains”匹配，将逐字使用URI。
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.
字符串开关允许CPL脚本根据调用请求中的自由格式字符串做出决定。图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
图5：“字符串开关”节点的语法
String switches have one node parameter: "field". The mandatory "field" parameter specifies which string is to be matched.
字符串开关有一个节点参数：“field”。必需的“field”参数指定要匹配的字符串。
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.
下面定义并列出了四个字段。每个字段的值都是自由格式的Unicode字符串，没有定义其他结构。
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].
字符串按以下方式匹配为不区分大小写的Unicode字符串。首先，字符串被规范化为“兼容性组合”（KC）形式，如Unicode标准附录#15[5]中所规定。然后，按照Unicode标准附录#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.
可以使用Java和Perl编写执行第一步的代码；参见UAX 15[5]附件5中的链接。Java标准类库中不区分大小写的字符串比较已经执行了第二步；其他支持Unicode的库也应该类似。
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.
字符串匹配的输出标记名为“string”，并具有一个强制参数，即“is”或“contains”中的一个，分别表示整个字符串匹配或子字符串匹配。
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.
对于SIP，字段“主题”、“组织”和“用户代理”对应于具有相同名称的SIP头字段。它们在消息中显示时会逐字使用。
The field "display" is not used, and is never present.
“显示”字段未使用，且从不存在。
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.
语言开关允许CPL脚本根据呼叫发起者希望使用的语言做出决定。图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
图6：“语言开关”节点的语法
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.
“语言”输出采用一个参数“匹配”。参数的值是语言标记，如RFC 3066[7]中所定义。调用者可能已经指定了一组语言范围，也如RFC 3066中所定义的。CPL服务器根据请求中指定的语言范围检查脚本指定的每个语言标记。
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 "-".
有关语言范围如何匹配语言标记的详细信息，请参见RFC 3066。简而言之，如果语言范围与标记完全相等，或者如果语言范围与标记的前缀完全相等，以致前缀后面的第一个字符是“-”，则该语言范围与语言标记匹配。
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.
如果调用方指定了特殊语言范围“*”，则出于匹配目的将忽略该范围。“q”值为0的语言也将被忽略。
This switch MAY be not-present.
此开关可能不存在。
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.
“语言开关”开关的语言范围从SIP“Accept language”头字段中获取。如果初始SIP请求不包含此标头字段，则开关不存在。
Note that because of CPL's first-match semantics in switches, "q" values other than 0 of the "Accept-Language" header fields are ignored.
注意，由于CPL在开关中的第一个匹配语义，“Accept Language”头字段中的“q”值不是0，因此被忽略。
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.
时间开关允许CPL脚本根据脚本执行的时间和/或日期做出决定。图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
节点：“时间开关”输出：“时间”特定时间以匹配参数：“tzid”RFC 2445时区标识符“tzurl”RFC 2445时区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
输出：“时间”参数：“dtstart”间隔开始（RFC 2445日期-时间）“dtend”间隔结束（RFC 2445日期-时间）“持续时间”间隔长度（RFC 2445持续时间）“频率”重复频率（“第二次”、“每分钟”、“每小时”、“每天”、“每周”、“每月”或“每年”）“间隔”重复频率“直到”定期界限（RFC 2445日期-时间）“计数”定期次数“按秒”分钟内秒数“按分钟”分钟数“按小时”一天中小时数“按天”一周中几天的列表“按月”一个月中几天的列表“按年”一年中几天的列表“按周”一年中的周列表“按月份”一年中的月列表“wkst”工作周的第一天“按设置”一组指定事件中的值列表
Figure 7: Syntax of the "time-switch" node
图7：“时间开关”节点的语法
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].
时间切换密切基于互联网日历和调度核心对象规范（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.
这允许从日历簿自动生成CPL脚本。它还允许我们重新使用大量的现有工作，指定时间间隔。
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.
如果发布了更新或废弃RFC 2445的未来标准跟踪文件，这些文件对重复处理的任何更改或澄清也适用于CPL时间开关。
An algorithm to determine whether an instant falls within a given recurrence is given in Appendix A.
附录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.
“时间开关”标签采用两个可选参数，“tzid”和“tzurl”，这两个参数均在RFC 2445中定义（分别为第4.8.3.1节和第4.8.3.5节）。“tzid”是参考时区定义的标识标签。如果它以正斜杠（solidus）开头，它将引用一个待定义的全局时区注册表；否则，它将在服务器上本地定义。“tzurl”提供了一个网络位置，可以从中检索时区的最新VTIMEZONE定义。
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.
虽然本地定义了不以正斜杠开头的“tzid”标签，但建议服务器至少支持Olson时区数据库使用的命名方案[9]。使用Olson方案的时区数据库的示例包括大多数类Unix系统上的zoneinfo文件和标准Java时区类。
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.
服务器应在上载脚本时解析对时区定义的“tzid”和“tzurl”引用。他们可能会定期刷新这些分辨率，以获得最新的时区定义。如果“tzurl”无效，服务器应记住从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.
如果脚本上载时带有CPL服务器无法识别或无法解析的“tzid”和“tzurl”，则应在脚本上载时诊断并拒绝该脚本。如果既不存在“tzid”也不存在“tzurl”，则此时间开关内的所有非UTC时间都应解释为“浮动”时间，即它们在CPL服务器的本地时区中指定。
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.
由于夏令时在一年中会发生变化，因此有必要在给定时区中指定时间开关。UTC偏移量不足，或者美国东部上午9点到下午5点之间的时间路由规则将在10月底上午8点到下午4点之间开始生效。
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.
CPL服务器的作者应该注意正确处理夏时制开始或结束时本地时间不连续的时间间隔。特别要注意的是，当时钟延迟时，某些时间可能会出现多次。附录A中的算法被认为能够正确处理这一问题。
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
时间节点指定应在其中执行其输出的时段列表。它们有两个必需的参数：“dtstart”，用于指定列表第一个时段的开始，而“dtend”或“duration”正好有一个参数，用于指定结束时间或时间
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].
期间的持续时间。按照RFC 2445[8]第4.3.5节的规定，“dtstart”和“dtend”参数的格式为iCalendar COS日期时间值。由于时区是在顶级“时间开关”标签中指定的，因此只能使用表1或表2（浮动时间或UTC时间）。根据RFC 2445第4.3.6节的规定，“持续时间”参数作为iCalendar COS持续时间参数给出。日期时间和持续时间语法都是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.
如果未指定其他参数，则时间节点仅指示单个时间段。更复杂的周期间隔集被构造为重现。通过包含“freq”参数指定定期，该参数指示定期规则的类型。除非存在“freq”，否则不应指定“dtstart”、“dtend”和“duration”以外的参数，尽管CPL服务器应接受存在此类参数的脚本，并忽略其他参数。
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.
“freq”参数采用以下值之一：“secondary”，根据一秒或更长的间隔指定重复周期，“minutely”，根据一分钟或更长的间隔指定重复周期，“hourly”，根据一小时或更长的间隔指定重复周期，“daily”，要指定基于一天或更长时间间隔的重复周期，“每周”，要指定基于一周或更长时间间隔的重复周期，“每月”，要指定基于一个月或更长时间间隔的重复周期，“每年”，要指定基于一年或更长时间间隔的重复周期。这些值不区分大小写。
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.
“interval”参数包含一个正整数，表示重复规则的重复频率。默认值为“1”，表示“第二”规则为每秒，“分钟”规则为每分钟，“小时”规则为每小时，“每日”规则为每天，“每周”规则为每周，“每月”规则为每月，“年度”规则为每年。
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
“直到”参数定义一个iCalendar COS日期或日期时间值，该值以包容的方式限制重复规则。如果“直到”指定的值与指定的定期同步，则此日期或日期时间将成为定期的最后一个实例。如果指定为日期时间值，则必须
specified in UTC time format. If not present, and the "count" parameter is not also present, the recurrence is considered to repeat forever.
以UTC时间格式指定。如果不存在，并且“count”参数也不存在，则认为重复将永远重复。
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.
“count”参数定义了要限制重复范围的出现次数。“dtstart”参数作为第一次出现计数。“直到”和“计数”参数不得出现在同一“时间”输出中。
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.
“bysecond”参数指定一分钟内以逗号分隔的秒数列表。有效值为0到59。“byminute”参数指定一小时内以逗号分隔的分钟列表。有效值为0到59。“byhour”参数指定一天中以逗号分隔的小时列表。有效值为0到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.
“byday”参数指定一周中以逗号分隔的天数列表。“MO”表示星期一，“TU”表示星期二，“WE”表示星期三，“TH”表示星期四，“FR”表示星期五，“SA”表示星期六，“SU”表示星期天。这些值不区分大小写。
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.
每个“byday”值前面还可以有一个正（+n）或负（-n）整数。如果存在，则表示“每月”或“每年”重现期内特定日期的第n次出现。例如，在“每月”规则中，+1MO（或简单地说是1MO）表示该月的第一个星期一，而-1MO表示该月的最后一个星期一。如果整数修饰符不存在，则表示指定频率内此类型的所有天数。例如，在“每月”规则中，MO表示该月内的所有星期一。
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.
“bymonthday”参数指定一个以逗号分隔的月份天数列表。有效值为1到31或-31到-1。例如，-10表示一个月的第十天到最后一天。
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).
“byyearday”参数指定一年中以逗号分隔的天数列表。有效值为1到366或-366到-1。例如，-1表示一年中的最后一天（12月31日），-306表示一年中的最后一天（3月1日）的第306次。
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.
“byweekno”参数指定以逗号分隔的序号列表，这些序号指定一年中的周数。有效值为1到53或-53到-1。这与ISO 8601[20]中定义的周编号对应。一周定义为七天，从定义为一周开始的一周中的某一天开始（见“wkst”）。日历年的第一周是该日历年中至少包含四（4）天的第一周。此参数仅对“年度”规则有效。例如，3代表一年中的第三周。
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.
注意：假设从周一开始，第53周只能在1月1日是周四或闰年，如果1月1日是周三时出现。
The "bymonth" parameter specifies a comma-separated list of months of the year. Valid values are 1 to 12.
“bymonth”参数指定一年中以逗号分隔的月份列表。有效值为1到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].
“wkst”参数指定工作周开始的日期。有效值为“MO”、“TU”、“WE”、“TH”、“FR”、“SA”和“SU”。当“每周”重复周期的间隔大于1，并且指定了“byday”参数时，这一点非常重要。当指定“byweekno”参数时，这在“年度”重复中也很重要。按照ISO 8601[20]，默认值为“MO”。
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:
“bysetpos”参数指定一个逗号分隔的值列表，该列表对应于规则指定的事件集中的第n个事件。有效值为1到366或-366到-1。它只能与另一个byxxx参数结合使用。例如，“当月最后一个工作日”可以表示为：
<time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR"
bysetpos="-1">
<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.
每个“bysetpos”值可以包括一个正（+n）或负（-n）整数。如果存在，则表示规则指定的事件集中特定事件的第n次出现。
If byxxx parameter values are found which are beyond the available scope (i.e., bymonthday="30" in February), they are simply ignored.
如果发现byxxx参数值超出了可用范围（即2月份的bymonthday=“30”），则将忽略它们。
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.
Byxxx参数以某种方式修改重复。Byxxx规则部分在相同或大于频率的时间段内，通常会减少或限制生成的重复次数。例如，freq=“daily”bymonth=“1”将重复实例的数量从所有天数（如果“bymonth”参数不存在）减少到1月份的所有天数。Byxxx参数在小于频率的时间段内通常会增加或扩大重复出现的次数。例如，freq=“yearly”bymonth=“1,2”将年度重复周期集中的天数从1（如果“bymonth”参数不存在）增加到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.
如果指定了多个Byxxx参数，则在评估指定的“频率”和“间隔”参数后，Byxxx参数将按以下顺序应用于当前评估的事件集：“bymonth”、“byweekno”、“byyearday”、“bymonthday”、“byday”、“byhour”、“byminute”、“bysecond”和“bysetpos”；然后计算“计数”和“直到”。
Here is an example of evaluating multiple Byxxx parameters.
下面是一个计算多个Byxxx参数的示例。
<time dtstart="19970105T083000" duration="10M"
freq="yearly" interval="2" bymonth="1" byday="SU"
byhour="8,9" byminute="30">
<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.
首先，interval=“2”将应用于freq=“yearly”以达到“每隔一年”。然后，bymonth=“1”将应用于达到“每年一月，每隔一年”。然后，byday=“SU”将应用于达到“每年一月的每个星期日”。然后，byhour=“8,9”将应用于达到“每隔一年，1月的每个星期日的上午8点和上午9点。”然后，byminute=“30”将应用于“每隔一年，1月的每个星期日的上午8:30和上午9:30。”然后，第二个从“dtstart”派生，以“每隔一年，1月的每个星期日的上午8:30到上午8:40，以及从上午9:30到上午9:40:00”结束。类似地，如果缺少“byminute”、“byhour”、“byday”、“bymonthday”或“bymonth”参数，则可以从“dtstart”参数中检索相应的分钟、小时、天或月。
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.
iCalendar COS RDATE、EXRULE和EXDATE重复规则未专门映射到时间开关节点的组件。通过使用切换规则的顺序排除使用早期规则的时间，可以实现与异常规则等效的功能；通过使用“子”节点（参见第8节）将多个输出链接到同一个后续节点，可以实现与附加日期规则等效的功能。
The "not-present" output is never true for a time switch. However, it MAY be included to allow switch processing to be more regular.
对于时间开关，“不存在”输出永远不会为真。但是，可以包括它，以使交换机处理更加规则。
(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.
本节中重复事件的规范与RFC 2445[8]的规范相同（语法和格式问题除外），只有一个附加限制。一个限制是重复间隔的连续实例不能重叠。
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.
在CPL的设计过程中，是否应将整个iCalendar COS递归规范包含在CPL中，或者是否只应包含一个子集，这是一个有争议的问题。最终决定，两个协议之间的兼容性至关重要。这给CPL服务器的实现者带来了一些额外的实现问题。
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:
在恒定时间内，似乎无法确定给定的时间瞬间是否落在由完整iCalendar COS循环定义的某个间隔内。主要关注点如下：
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 “count”参数不能在恒定运行时间内检查，因为它要求服务器枚举从“dtstart”到当前时间的所有重复，以确定当前重复是否满足该参数。但是，服务器可以离线扩展“count”参数一次，以确定上次重复的日期。然后可以将此日期视为服务器内部处理的虚拟“直到”参数。
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 类似地，“bysetpos”参数要求服务器枚举从当前重复集开始到当前时间的所有事件实例。这需要更复杂的预处理，但通常情况下，带有“bysetpos”参数的单个重复可以拆分为多个没有重复的重复。
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.
o 最后，时间开关的恒定运行时间还要求可以快速且唯一地确定循环的候选开始时间，以检查其是否满足其他限制。这要求重复的持续时间不超过其重复间隔，因此给定的瞬间不能落在重复的几个连续潜在重复内。连续间隔不重叠的限制部分满足此条件，但不能完全保证。同样，在某种程度上，预处理可以帮助解决这个问题。
The algorithm given in Appendix A runs in constant time after these pre-processing steps.
在这些预处理步骤之后，附录A中给出的算法以恒定时间运行。
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.
服务器应该检查循环规则是否不会产生任何荒谬的运行时或内存需求，并拒绝那些产生荒谬的运行时或内存需求的规则，就像它们应该检查CPL脚本是否一般都不是荒谬的大。
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.
优先级开关允许CPL脚本根据为原始调用指定的优先级做出决定。图8对它们进行了总结。它们依赖于底层信令协议。
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
图8：“优先级开关”节点的语法
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.
“优先级”标记采用三个参数“较大”、“较小”或“相等”中的一个。这些参数的值是以下优先级之一：按降序排列，“紧急”、“紧急”、“正常”和“非紧急”。这些值以不区分大小写的方式匹配。如果调用的优先级低于参数中给定的优先级，则采用带有“less”参数的输出，依此类推。
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.
由于每条消息都有一个优先级，因此优先级开关的“不存在”输出永远不会为真。但是，也可以包括它，以使交换机处理更加规则。
The priority of a SIP message corresponds to the "Priority" header in the initial "INVITE" message.
SIP消息的优先级对应于初始“INVITE”消息中的“priority”头。
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.
第2.3节描述了CPL的抽象位置模型。若干信令操作（第6节中定义）的行为取决于指定的当前位置集。位置节点从位置集中添加或删除位置。
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.
定义了三种类型的位置节点。显式位置将字面上指定的位置添加到当前位置集，位置查找从某些外部源获取位置，位置过滤器根据某些指定的条件从集中删除位置。
Explicit location nodes specify a location literally. Their syntax is described in Figure 9.
显式位置节点按字面形式指定位置。它们的语法如图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
节点：“位置”输出：无（下一个节点直接跟随）下一个节点：任何节点参数：“url”要添加到位置集的地址的url“优先级”此位置的优先级（0.0-1.0）“清除”是否在添加新值之前清除位置集
Figure 9: Syntax of the "location" node
图9：“location”节点的语法
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.
显式位置节点有三个节点参数。强制“url”参数的值是要添加到位置集的地址的url。每个位置节点只能指定一个地址；可以通过级联这些节点来指定多个位置。
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.
可选的“优先级”参数指定位置的优先级。它的值是介于0.0和1.0之间的浮点数。如果未指定，则服务器应采用默认优先级1.0。可选的“clear”参数指定在向位置集添加新位置之前是否应清除位置集。其值可以是“是”或“否”，默认为“否”。
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.
基本位置节点只有一个可能的结果，因为它们不可能失败。（如果基本位置节点指定了基础信令协议不支持的位置，脚本服务器应检测到该位置，并在提交脚本时向用户报告。）因此，它们的XML表示没有显式的输出标记；<location>标记直接包含另一个节点。
All SIP locations are represented as URLs, so the locations specified in "location" tags are interpreted directly.
所有SIP位置都表示为URL，因此直接解释“位置”标记中指定的位置。
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.
还可以通过外部方式，通过使用位置查找来指定位置。这些标记的语法如图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
图10：“查找”节点的语法
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.
位置查找节点有一个必需参数和两个可选参数。强制参数是“source”，即查找的源。这可以是URI，也可以是非URI值。如果“source”的值是一个URI，则它表示CPL服务器可以查询的位置，以获得具有text/URI列表媒体类型的对象（参见该类型的IANA注册，该注册也出现在RFC 2483[10]）。查询是逐字执行的，没有添加任何附加信息（如URI参数）。服务器将此对象中包含的位置添加到位置集中。
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.
CPL服务器可能会拒绝允许基于URI的源用于某些或所有URI方案的位置查询。在这种情况下，他们应该在脚本上载时拒绝脚本。
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.
有人讨论过让CPL服务器向位置请求添加URI参数，以便（例如）可以使用CGI脚本来解析它们。然而，大家一致认为这应该是一个CPL扩展，而不是基本规范的一部分。
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.
非URL源表示未由URL指定的源，服务器可以查询要添加到位置集的地址。当前定义的唯一非URL源是“registration”，它指定当前向服务器注册的所有位置。
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.
“查找”节点还有两个可选参数。“timeout”参数指定脚本愿意等待执行查找的时间（以秒为正整数）。如果未指定，则其默认值为30。“清除”参数指定在添加新位置之前是否应清除位置集。
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.
查找有三个输出：“成功”、“未找到”和“失败”。如果查找过程成功但未找到任何位置，则采用Notfound；如果由于某种原因（包括超过指定的超时时间）导致查找失败，则执行失败。如果给定的输出不存在，脚本执行将终止，并执行默认行为。
For SIP, the "registration" lookup source corresponds to the locations registered with the server using "REGISTER" messages.
对于SIP，“注册”查找源对应于使用“注册”消息向服务器注册的位置。
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.
CPL脚本还可以通过使用“删除位置”节点从位置集中删除位置。该节点的语法如图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
图11：“RemoveLocation”节点的语法
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.
“移除位置”节点从位置集中移除位置。它主要在“查找”节点之后有用。第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.
“删除位置”节点有一个可选参数。参数“location”以依赖于信令协议的方式给出要从集合中删除的位置的URI。如果未给出此参数，则将从集合中删除所有位置。
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.
“移除位置”节点没有显式的输出标记。在XML语法中，XML“remove location”标记直接包含下一个节点的标记。
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).
“remove location”节点的“location”参数中指定的位置与使用SIP URI匹配的标准规则设置的位置相匹配（例如，刷新注册时用于匹配联系人地址）。
Signalling operation nodes cause signalling events in the underlying signalling protocol. Three signalling operations are defined: "proxy," "redirect," and "reject."
信令操作节点在底层信令协议中引起信令事件。定义了三种信令操作：“代理”、“重定向”和“拒绝”
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.
代理将触发调用转发到当前指定的位置集。代理节点的语法如图12所示。
The specific signalling events invoked by the "proxy" node are signalling-protocol-dependent, though the general concept should apply to any signalling protocol.
“代理”节点调用的特定信令事件依赖于信令协议，但一般概念应适用于任何信令协议。
Node: "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
输出：“noanswer”参数：无
Output: "redirection" Parameters: none
输出：“重定向”参数：无
Output: "failure" Parameters: none
输出：“故障”参数：无
Output: "default" Parameters: none
输出：“默认”参数：无
Figure 12: Syntax of the "proxy" node
图12：“代理”节点的语法
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.
代理操作完成后，CPL服务器根据信令协议或服务器的管理配置规则选择呼叫尝试的“最佳”响应。
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.
如果调用尝试成功，CPL执行将终止，服务器将继续其默认行为（通常允许设置调用）。否则，取对应于“代理”节点的输出之一的下一个节点。如果呼叫正忙，则跟随“忙”输出；如果在“超时”参数过期之前呼叫未应答，则跟随“noanswer”；如果呼叫被重定向，则跟随“重定向”；如果呼叫设置因任何其他原因失败，则跟随“失败”。
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).
如果上述条件之一为真，但未指定相应的输出，则将遵循“代理”节点的“默认”输出。如果也没有指定“默认”节点，则CPL执行终止，服务器返回其默认行为（通常，将最佳响应转发到发起方的上游）。
Note: CPL extensions to allow in-call or end-of-call operations will require an additional output, such as "success", to be added.
注意：允许呼叫内或呼叫结束操作的CPL扩展将需要添加额外的输出，例如“success”。
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.
如果集合中不存在任何位置，或者集合中唯一的位置是服务器无法代理调用的位置（例如，“http”URL），则将获取“失败”输出。
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).
代理有三个可选参数。“timeout”参数指定等待呼叫完成或被拒绝的时间（以秒为正整数）；在这段时间过后，呼叫尝试被终止，“noanswer”分支被执行。如果未指定此参数，则如果“代理”节点指定了“noanswer”或“default”输出，则默认值为20秒；否则，服务器应允许呼叫在相当长的时间内（在服务器策略允许的最大范围内）响铃。
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".
第二个可选参数是“recurse”，它可以有两个值，“yes”或“no”。这指定服务器是否应自动尝试在从初始服务器返回的重定向响应中对电话地址进行进一步的呼叫尝试。请注意，如果“recurse”的值为“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".
第三个可选参数是“排序”。这可以有三个可能的值：“并行”、“顺序”和“仅第一”。此参数指定应按什么顺序尝试位置集的位置。Parallel要求同时对它们进行审判；sequential要求先尝试优先级最高的一个，然后再尝试下一个优先级最高的，依此类推，直到一个成功或集合耗尽。First only指示服务器仅尝试集合中的最高优先级地址，然后跟随其中一个输出。集合中位置的优先级由服务器策略决定，尽管CPL服务器应遵守“位置”标记的“优先级”参数。此参数的默认值为“并行”。
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.
代理操作完成后，如果将控制权传递给其他节点，则将从位置集中清除所有已使用的位置。也就是说，如果“排序”为“并行”或“顺序”，则位置集将清空可代理位置；如果“排序”为“仅限第一”，则集合中优先级最高的项将从集合中删除。（在所有情况下，不可代理的位置（如“http”URI）仍然存在。）在“重定向”输出的情况下，将呼叫重定向到的新地址添加到位置集中。
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:
对于SIP，对“代理”节点的最佳响应由SIP规范的算法确定。节点的输出对应于以下事件：
busy: A 486 or 600 response was the best response received for the call request.
忙：486或600响应是针对呼叫请求收到的最佳响应。
redirection: A 3xx response was the best response received for the call request.
重定向：3xx响应是针对呼叫请求收到的最佳响应。
failure: Any other 4xx, 5xx, or 6xx response was the best response received for the call request.
失败：任何其他4xx、5xx或6xx响应都是针对呼叫请求收到的最佳响应。
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.
在确定位置优先级时，SIP服务器应遵守SIP注册的“q”参数。
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.
重定向导致服务器指示呼叫方尝试将其呼叫放置到当前指定的位置集。该节点的语法如图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
图13：“重定向”节点的语法
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."
重定向立即终止CPL脚本的执行，所以这个节点并没有输出，也并没有下一个节点。它有一个参数“permanent”，用于指定返回的结果是否应指示这是一个永久重定向。此参数的值为“是”或“否”，其默认值为“否”
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).
SIP服务器应在执行“重定向”标记时向呼叫请求发送3xx类响应。如果“permanent”为“yes”，则服务器应发送响应“301”（永久移动），否则应发送“302”（临时移动）。
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.
拒绝节点导致服务器拒绝呼叫尝试。它们的语法如图14所示。它们调用的特定行为取决于所涉及的底层信令协议，尽管它们的语义通常是适用的。
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
图14：“拒绝”节点的语法
A reject node immediately terminates the execution of a CPL script, so this node has no outputs and no next node.
拒绝节点立即终止CPL脚本的执行，因此该节点没有输出，也没有下一个节点。
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.
此节点有两个参数：“状态”和“原因”。“status”参数是必需的，可以采用“busy”、“notfound”、“reject”、“error”或信令协议定义的状态值之一。
The "reason" argument optionally allows the script to specify a reason for the rejection.
“reason”参数允许脚本指定拒绝的原因。
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.
实现SIP的服务器还应允许“status”字段是与4xx、5xx或6xx范围内的SIP状态相对应的数字参数。
They SHOULD send the "reason" parameter in the SIP reason phrase.
他们应该在SIP原因短语中发送“reason”参数。
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
“忙”：486这里忙
"notfound": 404 Not Found
“未找到”：404未找到
"reject": 603 Decline
“拒绝”：603拒绝
"error": 500 Internal Server Error
“错误”：500内部服务器错误
In addition to the signalling operations, CPL defines several operations which do not affect and are not dependent on the telephony signalling protocol.
除了信令操作外，CPL还定义了几个不影响和不依赖于电话信令协议的操作。
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.
邮件节点使服务器通过电子邮件通知用户CPL脚本的状态。其语法如图15所示。
Node: "mail" Outputs: None (Next node follows directly) Next node: Any node Parameters: "url" Mailto url to which the mail should be sent
节点：“邮件”输出：无（下一个节点直接跟随）下一个节点：任何节点参数：“url”邮件应发送到的Mailto url
Figure 15: Syntax of the "mail" node
图15：“邮件”节点的语法
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.
“邮件”节点有一个参数：一个“mailto”URL，提供要发送的邮件的地址和任何其他所需参数。服务器将包含内容的消息发送到给定的url；它还应该包括关于原始调用请求的其他状态信息以及通知时的CPL脚本。
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" />.
使用完整的“mailto”URL而不仅仅是电子邮件地址可以指定其他电子邮件头，例如<mail URL=“mailto:jones@example.com？主题=查找%20失败“/>。
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.
邮件节点只有一个可能的结果，因为无法可靠地实时知道电子邮件传递的失败。因此，它的XML表示没有输出标记：<mail>标记直接包含另一个节点标记。
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]).
注意，XML的语法要求在“mailto”URL中用作参数分隔符的符号和字符“&”在参数值中被引用为“&；”（参见XML规范[2]的C.12节）。
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.
本节介绍了针对SIP触发的请求，通过“邮件”节点发送的邮件的建议准则。邮件（由任何协议触发）应该包含所有这些信息，但服务器可以选择使用不同的格式。
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.
1. 如果“mailto”URI未指定主题标头，则电子邮件的主题为“[CPL]”，后跟SIP请求的主题标头。如果URI指定了主题标头，则使用它。
2. The "From" field of the e-mail is set to a CPL server configured address, overriding any "From" field in the "mailto" URI.
2. 电子邮件的“发件人”字段设置为CPL服务器配置的地址，覆盖“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).
3. URI中的任何“回复”标题都是有效的。如果没有给出，则在可能的情况下使用请求的源字段的电子邮件化版本（例如，通过剥离URI方案，将带有SIP:URI的SIP“From”头转换为电子邮件地址）。
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.
4. 如果“mailto”URI指定了一个主体，则使用它。如果未指定，则正文应至少包含呼叫者的身份（呼叫者的显示名称和地址）、日期和时间、呼叫主题以及呼叫优先级（如果可用）。
The server SHOULD honor the user's requested languages, and send the mail notification using an appropriate language and character set.
服务器应遵守用户请求的语言，并使用适当的语言和字符集发送邮件通知。
The Log node causes the server to log information about the call to non-volatile storage. Its syntax is specified in Figure 16.
日志节点使服务器记录有关对非易失性存储器的调用的信息。其语法如图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
图16：“日志”节点的语法
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,
Log接受两个参数，都是可选的：“name”，它指定日志的名称，以及“comment”，它给出关于所记录信息的注释。服务器还应在日志中包含其他信息，如记录事件的时间，
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.
触发要记录的呼叫的信息，等等。日志特定于记录事件的脚本的所有者。如果未给出“name”参数，则事件将记录到脚本所有者的标准、服务器定义的日志文件中。此规范未定义用户如何从服务器检索日志。
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.
日志的名称仅为逻辑名称，不一定与服务器上的任何物理文件对应。日志文件名的解释由服务器定义，访问这些日志的机制也是如此。出于安全原因，CPL服务器不应将未解释的日志名直接映射到本地文件名，以免覆盖安全关键文件。
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.
正确运行的CPL服务器不应允许“日志”事件失败。因此，日志节点只能有一个可能的结果，并且它们的XML表示没有显式的输出标记。CPL<log>标记直接包含另一个节点标记。
XML syntax defines a tree. To allow more general call flow diagrams, and to allow script re-use and modularity, we define subactions.
XML语法定义了一个树。为了允许更通用的调用流程图，并允许脚本重用和模块化，我们定义了子操作。
Two tags are defined for subactions: subaction definitions and subaction references. Their syntax is given in Figure 17.
为子动作定义了两个标记：子动作定义和子动作引用。它们的语法如图17所示。
Tag: "subaction" Subtags: Any node Parameters: "id" Name of this subaction
标记：“子动作”子标记：任何节点参数：“id”此子动作的名称
Pseudo-node: "sub" Outputs: None in XML tree Parameters: "ref" Name of subaction to execute
伪节点：“sub”输出：XML树参数中无：“ref”要执行的子操作的名称
Figure 17: Syntax of subactions and "sub" pseudo-nodes
图17：子操作和“子”伪节点的语法
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.
子动作通过“子动作”标记定义。这些标记放在CPL脚本中任何辅助信息之后（参见第9节），但放在任何顶级标记之前。它们接受一个参数：“id”，一个表示为子动作选择的脚本名称的标记。脚本中每个“子动作”标记的“id”值在该脚本中必须是唯一的。
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.
子动作是从“子”标记调用的。“sub”标记是一个“伪节点”，可以在CPL操作中使用真正节点可以使用的任何位置。它接受一个参数“ref”，即要调用的子操作的名称。“sub”标记本身不包含任何输出，而是将控制传递给subaction。
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.
对子动作的引用必须引用在当前动作之前定义的子动作。“sub”标记不能引用它出现在中的操作，也不能引用CPL脚本后面定义的任何操作。不能从“子”标记或通过任何其他方式调用顶级操作。脚本服务器必须在提交脚本时验证是否没有“子”节点引用任何不是其正确的前置操作的子操作。
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.
只允许SUB的反向引用禁止任何类型的递归。递归将引入不终止或不可判定CPL脚本的可能性，我们的需求明确排除了这种可能性。
Every sub MUST refer to a subaction ID defined within the same CPL script. No external links are permitted.
每个子操作都必须引用同一CPL脚本中定义的子操作ID。不允许外部链接。
Subaction IDs are case sensitive.
子动作ID区分大小写。
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.
如果任何后续版本或扩展定义了外部链接，则可能会使用不同的标记，例如XLink[21]。确保在存在外部链路的情况下终止是一个难题。
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.
基本CPL规范中未定义任何辅助信息。如果发现CPL扩展需要辅助信息，而不是任何操作的一部分，则应将其放置在此标签内。
The (trivial) definition of the ancillary information tag is given in Figure 18.
图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.
在CPL脚本中直接包含时区定义可能会很有用，而不是在外部使用“tzid”和“tzurl”参数引用它们。如果是的话，可以定义一个扩展来包含它们。
Tag: "ancillary" Parameters: None Subtags: None
标记：“辅助”参数：无子标记：无
Figure 18: Syntax of the "ancillary" tag
图18：“辅助”标记的语法
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.
当CPL节点到达未指定的输出时，或者因为输出标记不存在，或者因为标记存在但不包含节点，CPL服务器的行为取决于脚本执行的当前状态。本节给出了每种情况下应采取的操作。
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.
未执行位置修改或信令操作，位置设置为空：如果没有CPL脚本，则通过服务器将使用的任何机制查找用户的位置。代理、重定向或发送拒绝消息，使用服务器在没有CPL脚本的情况下使用的任何策略。
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.
执行位置修改，无信令操作：代理或重定向呼叫（以服务器的标准策略为准）到当前位置集中的地址。如果位置集为空，则返回“notfound”拒绝。
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).
代理的noanswer输出，未指定超时：（这是一种特殊情况。）如果代理节点的“noanswer”输出未指定，并且未向代理节点提供超时参数，则应允许在服务器允许的最大时间长度内（或请求，如果请求指定了超时）调用。
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.
以前执行的代理操作：根据底层信令协议的规则，返回到该点的所有累计呼叫响应中的“最佳”响应。
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功能。所建议的一些扩展是一种查询如何对呼叫进行身份验证的方法、对H.323寻址的更丰富控制、终端系统或管理员特定功能、字符串和地址的正则表达式匹配以及呼叫中或呼叫结束控制。
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
CPL扩展由XML名称空间表示[11]。每个扩展必须有一个适当的XML名称空间分配给它。扩展的XML命名空间必须与XML命名空间不同
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.
定义见第14节。扩展不得更改本文档中定义的CPL模式的语法或语义。作为扩展的一部分的所有XML标记和属性都必须经过适当的限定，以便将它们放置在该命名空间中。
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".
CPL脚本中全局名称空间中的标记或属性（即，不与任何名称空间关联）等同于CPL名称空间“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.
CPL脚本不应指定它不使用的任何名称空间。为了与非名称空间感知解析器兼容，对于不使用任何扩展的脚本，CPL脚本可以省略基本CPL名称空间。
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.
CPL服务器必须拒绝任何包含对其不理解的命名空间的引用的脚本。它必须拒绝任何包含扩展标记或属性的脚本，该扩展标记或属性不符合相应命名空间的条件。
A syntax such as
语法，如
<extension-switch>
<extension has="http://www.example.com/foo">
[extended things]
</extension>
<otherwise>
[non-extended things]
</otherwise>
</extension-switch>
<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.
被建议作为处理扩展的另一种方式。这将允许将脚本上载到服务器，而无需脚本作者以某种方式确定服务器支持哪些扩展。然而，开发其他语言（尤其是Sieve[22]）的经验是，这增加了语言的过度复杂性。当然，“扩展开关”标签本身可以在CPL扩展中定义。
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
在CPL的XML模式中，我们引入了三个抽象元素，即“toplevelaction”、“switch”和“action”，它们相应地具有抽象类型“TopLevelActionType”、“SwitchType”和“ActionType”。CPL扩展中的任何顶级操作都必须定义为抽象“toplevelaction”元素的替换组，并从“TopLevelActionType”扩展类型。CPL扩展中的任何开关都必须定义为抽象“switch”元素的替换组，并具有
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'.
从“开关类型”扩展而来。CPL扩展中的任何操作都必须定义为抽象“action”元素的替换组，并从“ActionType”扩展类型。
The script in Figure 19 is a simple script that redirects all calls to a single fixed location.
图19中的脚本是一个将所有调用重定向到单个固定位置的简单脚本。
<?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>
<?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
图19：示例脚本：调用重定向无条件
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.
图20中的脚本演示了一些更复杂的行为。我们看到了对一个地址的初始代理尝试，如果失败，还会有进一步的操作。我们还可以通过使用子动作来了解多个输出如何采用相同的动作子树。
<?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>
<?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
Figure 20: Example Script: Call Forward Busy/No Answer
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.
图21中的脚本演示了进一步的代理行为。服务器最初尝试代理到单个地址。如果重定向此尝试，将使用返回的位置生成新的重定向。在代理节点的所有其他故障情况下，将执行默认操作（转发到语音邮件）。
<?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>
<?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
Figure 21: Example Script: Call Forward: Redirect and Default
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.
图22中的脚本以呼叫屏蔽脚本的形式演示了地址切换和呼叫拒绝。还要注意，因为地址开关缺少“否则”子句，所以如果初始模式不匹配，脚本不会定义任何操作。因此，服务器将继续其默认行为，这可能是联系用户。
<?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>
<?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
图22：示例脚本：呼叫筛选
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.
图23中的脚本说明了基于呼叫优先级值和语言设置的服务选择。如果调用请求的优先级为“紧急”或更高，则执行默认脚本行为。否则，将检查语言字段中的语言“es”（西班牙语）。如果有，呼叫将代理给讲西班牙语的操作员；其他电话由讲英语的接线员代理。
<?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>
<?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
图23：示例脚本：优先级和语言路由
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.
图24中的脚本演示了一个过滤传出呼叫的脚本，该脚本的形式是防止拨打1-900（高级）呼叫。此脚本还演示了子域匹配。
<?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>
<?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
图24：示例脚本：传出呼叫屏蔽
Figure 25 illustrates time-based conditions and timezones.
图25说明了基于时间的条件和时区。
<?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>
<?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
图25：示例脚本：一天中的时间路由
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.
图26说明了位置集上的过滤操作。在本例中，我们假设0.9beta2版的“不适当的软件SIP用户代理”mis实现了一些功能，因此我们必须解决其问题。我们知道它无法与我们可能已注册的特定移动设备成功通话，因此我们将该位置从位置集中删除。此操作完成后，允许正常进行呼叫设置。
<?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>
<?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
图26：示例脚本：位置筛选
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.
图27说明了非信令操作；特别是，如果查找服务器出现故障，则通过电子邮件通知用户。拥有“邮件”节点的主要动机是允许这种带外错误情况通知，因为用户可能不知道任何问题。
<?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>
<?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
图27：示例脚本：非信令操作
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".
图28中的示例显示了一个实现独特振铃的假设扩展。XML名称空间“http://www.example.com/distinctive-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"?>
<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>
<?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
图28：模式和脚本示例：扩展
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.
图29中的示例为地址开关实现了一个假设的新属性，以允许正则表达式匹配。它为标准“地址”节点定义了一个新属性“regex”。
<?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>
<?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
图29：示例脚本：假设的正则表达式扩展
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.
最后，图30是一个复杂的示例，它显示了通过组合CPL节点可以实现的复杂行为。在这种情况下，用户试图让他的电话到达他的办公桌；如果他在一小段时间内没有接听，老板的电话就会转到他的手机上，其他所有电话都会转到语音信箱。如果呼叫设置失败，则不指定任何操作，因此将执行服务器的默认行为。
<?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>
<?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
图30：示例脚本：一个复杂的示例
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.
CPL旨在允许以某种方式指定服务，以防止潜在的恶意或错误配置的脚本发起安全攻击，包括拒绝服务攻击。由于脚本运行时严格受非循环性限制，并且可能的脚本操作的数量也受到严格限制，因此脚本不应该对CPL服务器造成损害。
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.
脚本服务器应允许服务器管理员控制允许哪些CPL操作的详细信息。
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].
本文档根据RFC 2141[12]、RFC 2648[13]和RFC 3688[14]注册了一个新的MIME类型application/cpl+xml和一个新的URN。
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.
XML名称空间urn:ietf:params:XML:ns:cpl将仅引用本文档中的cpl版本，不会更改。任何CPL增强都必须通过扩展实现，并且必须具有不同的名称空间。
URI: 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>
Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
XML:
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>
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>
<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
<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
This specification registers XML Schema for CPL, as per the guidelines in [14].
根据[14]中的指导原则，本规范为CPL注册XML模式。
URI: urn:ietf:params:xml:schema:cpl
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>
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.
XML：可以在附录C中找到XML。
As an XML type, CPL's MIME registration conforms with "XML Media Types," RFC 3023 [15].
作为一种XML类型，CPL的MIME注册符合“XML媒体类型”RFC 3023[15]。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: cpl+xml
MIME子类型名称：cpl+xml
Mandatory parameters: none
强制参数：无
Optional parameters: charset As for application/xml in RFC 3023.
可选参数：RFC3023中application/xml的字符集。
Encoding considerations: As for application/xml in RFC 3023.
编码注意事项：与RFC3023中的application/xml一样。
Security considerations: See Section 13, and Section 10 of RFC 3023.
安全注意事项：见RFC 3023第13节和第10节。
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.
互操作性注意事项：不同的CPL服务器可能使用不兼容的地址类型。然而，在上传脚本时，所有潜在的互操作性问题都应该可以解决；不应存在在运行时之前无法检测到的互操作性问题。
Published specification: This document.
已发布规范：本文件。
Applications which use this media type: SIP proxy servers and other telephony servers, and client software to control their behavior.
使用此媒体类型的应用程序：SIP代理服务器和其他电话服务器，以及控制其行为的客户端软件。
Additional information:
其他信息：
Magic number: None
神奇数字：无
File extension: .cpl or .xml
文件扩展名：.cpl或.xml
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
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>
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.
作者/变更控制者：IETF。
This document was reviewed and commented upon by the IETF IP Telephony Working Group. We specifically acknowledge the following people for their help:
IETF IP电话工作组对本文件进行了审查和评论。我们特别感谢以下人员的帮助：
The outgoing call screening script was written by Kenny Hom.
呼出电话筛选脚本由Kenny Hom编写。
Paul E. Jones contributed greatly to the mappings of H.323 addresses.
保罗·琼斯对H.323地址的映射做出了巨大贡献。
The text of the time-switch section was taken (lightly modified) from RFC 2445 [8], by Frank Dawson and Derik Stenerson.
时间开关部分的文本由Frank Dawson和Derik Stenerson从RFC 2445[8]中选取（稍加修改）。
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.
我们从Sieve[22]的规范中得到了很多启发，特别是该语言缺乏图灵完整性和字符串匹配语法，Sieve[22]是一种用于用户过滤电子邮件消息的语言。
Thomas F. La Porta and Jonathan Rosenberg had many useful discussions, contributions, and suggestions.
托马斯·拉波尔塔（Thomas F.La Porta）和乔纳森·罗森博格（Jonathan Rosenberg）进行了许多有益的讨论、贡献和建议。
Richard Gumpertz performed a very useful last-minute technical and editorial review of the specification.
Richard Gumpertz在最后一分钟对规范进行了非常有用的技术和编辑审查。
A. An Algorithm for Resolving Time Switches
A.解析时间开关的算法
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.
下面的算法确定给定的瞬间是否属于“时间切换”循环的重复。如果已完成第4.4.1节中所述的预处理，则其在恒定时间内运行。实现该算法的开源Java代码可在http://www.cs.columbia.edu/~lennox/Cal Code/在万维网上。
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.
该算法被认为是正确的，但本节不规范。第4.4节和RFC 2445[8]是复发的最终定义。
1. Compute the time of the call, in the timezone of the time switch.
1. 在时间开关的时区中计算呼叫时间。
2. If the call time is earlier than "dtstart", fail NOMATCH.
2. 如果呼叫时间早于“dtstart”，则无法匹配。
3. If the call time is less than "duration" after dtstart, succeed MATCH.
3. 如果dtstart后呼叫时间小于“持续时间”，则匹配成功。
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.
4. 确定“byxxx”规则或“freq”中指定的最小单位。将其称为最小单位。当所有小于最小单位的时间单位与“dtstart”的时间单位相同时，确定上一个瞬间（在呼叫时间之前或等于呼叫时间）。如果最小单位为秒，则此时间与该瞬间相同。如果最小单位为一分钟或一小时，则分钟或分钟和小时必须分别与“dtstart”相同。对于所有其他最小单位，一天的时间必须与“dtstart”相同。如果最小单位为一周，则一周的日期必须与“dtstart”相同。如果最小单位为一个月，则一个月的日期必须与“dtstart”相同。如果最小单位为一年，则月份和月份的日期必须与“dtstart”相同（注意，这意味着可能需要回滚多个最小单位——如果最小单位为一个月，则某些月份没有第31个（或第30个或第29个）日；如果最小单位为一年，则某些年份没有2月29日。在公历中，如果最小单位为一个月，则回滚时间不必超过两个月，如果最小单位为一年，则回滚时间不必超过八年。在1904年至2096年间，回滚时间不必超过四年，即八年回滚时间只有在公历“跳过”闰年时才能发生。
Call this instant the Candidate Start Time.
将这一时刻称为候选人开始时间。
5. If the time between the candidate start time and the call time is more than the duration, fail NOMATCH.
5. 如果候选开始时间和呼叫时间之间的时间超过持续时间，则不匹配失败。
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.
6. 如果候选开始时间晚于重复周期的“直到”参数（或从“计数”离线计算的虚拟“直到”），则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.
7. 将循环的“freq”参数的单位称为频率单位。确定包含候选开始时间的频率单位，以及包含“dtstart”的频率单位。计算在这两次之间经过的频率单位数。如果这不是“间隔”参数的倍数，则失败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.
8. 对于每个“byxxx”规则，确认候选开始时间与该“byxxx”规则指定的选项之一匹配。如果是这样，成功匹配。
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.
9. 计算上一个候选开始时间。重复此操作，直到候选开始时间和呼叫时间之间的差值超过持续时间。如果未验证候选开始时间，则取消匹配。
B. Suggested Usage of CPL with H.323
B.建议在H.323中使用CPL
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.
本附录给出了H.323[16]中CPL的建议用法。开发H.323的国际电联第16研究小组提议为该协议制定官方CPL映射。因此，本节不具有规范性。
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.
第4.1节规定了地址开关。本节规定了H.323消息与地址开关的字段和子字段之间的映射。
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."
对于H.323，“来源”地址对应于“设置UUIE”用户信息元素“sourceAddress”字段中的别名地址，以及Q.931[23]信息元素“主叫方号码”。如果两个字段都存在，或者如果“sourceAddress”的多个别名地址都存在，哪一个具有优先级是本地服务器策略的问题；在这种情况下，服务器应该使用与路由决策相同的分辨率。类似地，“目的地”地址对应于“目的地地址”字段的别名地址，并对应于Q.931信息元素“称为参与方编号”
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.
“原始目的地”地址对应于“重定向号码”Q.931信息元素（如果存在）；否则，它与“目的地”地址相同。
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.
H.323地址到子字段的映射取决于别名地址的类型。为H.323服务器定义了与地址类型相对应的附加子字段类型“别名类型”。可能的值有“DialledDigits”、“h323 ID”、“url ID”、“transportID”、“email ID”、“partyNumber”、“mobileUIM”和“Q.931IE”。如果H.323规范的未来版本定义了其他类型的别名地址，则也可以使用这些名称。
In versions of H.323 prior to version 4, "dialedDigits" was known as "e164". The two names SHOULD be treated as synonyms.
在版本4之前的H.323版本中，“拨号数字”被称为“e164”。这两个名称应视为同义词。
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.
H.323消息的“地址类型”子字段的值为“h323”，除非别名类型为“url ID”，并且url方案不是h323；在这种情况下，地址类型是URL方案，如SIP第4.1.1节所述。
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.
支持H.323的CPL服务器应该从用于路由的主别名映射地址子字段。如果主地址中的子字段不存在，它还可以从其他别名映射子字段。
The following mappings are used for H.323 alias types:
以下映射用于H.323别名类型：
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.
DialledDigits、partyNumber、mobileUIM和Q.931IE：“电话”和“用户”子字段是数字字符串，“整个地址”形式也是数字字符串。“主机”和“端口”子字段不存在。
url-ID: the same mappings are used as for SIP, in Section 4.1.1.
url ID：与第4.1.1节中SIP使用的映射相同。
h323-ID: the "user" field is the string of characters, as is the "entire-address" form. All other subfields are not present.
h323 ID:“用户”字段是字符串，“整个地址”表单也是字符串。不存在所有其他子字段。
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.
电子邮件ID：“用户”和“主机”子字段设置为电子邮件地址的相应部分。“端口”和“电话”子字段不存在。“完整地址”表单对应于整个电子邮件地址。
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
transportID：如果TransportAddress的类型为“ipAddress”、“ipSourceRoute”或“ip6Address”，则“host”子字段设置为序列的“ip”元素，转换为标准IPv4或IPv6文本表示形式，“port”子字段设置为以十进制表示的序列的“port”元素。“电话”和“用户”字段不存在。“完整地址”表单未定义。这个
representation and mapping of transport addresses is not defined for non-IP addresses.
未为非IP地址定义传输地址的表示和映射。
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.
H.323[16]定义了一个“h323”URI方案。本附录定义了这些URI到CPL“地址开关”子字段的映射，如第4.1节所示。该定义也可作为RFC 3508[24]获得，它是H.323规范的摘录。
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.
对于H323URI，“用户”、“主机”和“端口”子字段设置为H.323URL的相应部分。“tel”子字段不存在。“完整地址”表单对应于整个URI。
This mapping MAY be used both for h323 URIs in an h323 "url-ID" address alias, and for h323 URIs in SIP messages.
此映射既可用于h323“url ID”地址别名中的h323 URI，也可用于SIP消息中的h323 URI。
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.
对于H.323，“字符串开关”节点（见第4.2节）使用如下。字段“display”对应于相同名称的Q.931信息元素，逐字复制。“主题”、“组织”和“用户代理”字段不使用，也不存在。
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.
“显示”IE通常用于呼叫者ID目的，因此可以说它应该映射到“地址匹配”字段“发起者”的“显示”子字段。然而，由于a）它是消息级信息元素，而不是地址级信息元素，并且b）Q.931规范[23]仅说明“显示信息元素的目的是提供可由用户显示的显示信息”，因此，允许它在“字符串开关”中匹配似乎更合适。
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.
“语言开关”开关的语言范围从H.323 UUIE“语言”中获得。如果初始消息不包含此UUIE，则开关不存在。
All H.323 messages are considered to have priority "normal" for the purpose of a priority switch (see Section 4.5).
出于优先级切换的目的，所有H.323消息都被视为具有优先级“正常”（见第4.5节）。
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.
显式位置节点（第5.1节）中的位置指定为URL。因此，以这种方式添加的所有位置在H.323中被解释为别名类型“url ID”。
Specifications of other H.323 address alias types will require a CPL extension (see Section 11).
其他H.323地址别名类型的规范将需要CPL扩展（见第11节）。
For location lookup nodes (Section 5.2), the "registration" lookup source corresponds to the locations registered with the server using "RAS" messages.
对于位置查找节点（第5.2节），“注册”查找源对应于使用“RAS”消息向服务器注册的位置。
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.
位置删除节点（第5.3节）使用url上的逐字字符串匹配删除别名类型为“url ID”的地址。如果将“tel”URL指定为位置，则还将删除别名类型为“DialledDigits”（“e164”）、“partyNumber”、“mobileUIM”或“Q.931IE”的匹配地址（忽略可视分隔符）。没有提供删除其他别名类型的机制。
C. The XML Schema for CPL
C.CPL的XML模式
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.
本节包括一个完整的XML模式，描述CPL的XML语法。提交给CPL服务器的每个脚本都应符合此XML模式。当解析脚本符合早期文档中的CPL DTD时，应忽略脚本中的DOCTYPE行。请注意，遵守此模式并不是CPL脚本正确性的充分条件，因为本规范中描述的许多条件不能用模式语法表示。图31显示了模式的结构“传入”和“传出”定义为“toplevelaction”的替换组。所有开关都定义为“开关”元素的替换组。所有动作都定义为“动作”元素的替换组。
+---------+ +------+ +--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
+------+
+---------+ +------+ +--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
图31:CPL的XML模式结构
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">
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">
<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>
<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>
<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"/>
<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"/>
<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>
<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>
</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>
</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>
</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
</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
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.
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.
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>
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>
</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">
</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">
<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"/>
<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"/>
<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"/>
<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"/>
<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">
<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">
<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
<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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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/.
[2] Bray，T.，Paoli，J.，Sperberg McQueen，C.M.，Maler，E.，和F.Yergeau，“可扩展标记语言（XML）1.0（第三版）”，W3C建议REC-XML-20040204，万维网联盟（W3C），2004年2月。可在http://www.w3.org/XML/.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[4] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[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/.
[5] Davis，M.F.和M.Duerst，“Unicode规范化格式”，Unicode标准附件#15，Unicode联盟，2003年4月。第23次修订；Unicode 4.0.0的一部分。可在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/.
[6] Davis，M.F.，“案例映射”，Unicode标准附件#21，Unicode联盟，2001年3月。第5次修订；Unicode 3.2.0的一部分。可在http://www.unicode.org/unicode/reports/tr21/.
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[7] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[8] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[8] Dawson，F.和D.Stenerson，“互联网日历和调度核心对象规范（iCalendar）”，RFC 24451998年11月。
[9] Eggert, P., "Sources for Time Zone and Daylight Saving Time Data". Available at http://www.twinsun.com/tz/tz-link.htm.
[9] Eggert，P.，“时区和夏令时数据源”。可在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.
[10] Mealling，M.和R.Daniel，“URN解析所需的URI解析服务”，RFC 2483，1999年1月。
[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/.
[11] Bray，T.，Hollander，D.，和A.Layman，“XML中的名称空间”，W3C建议REC-XML-names-19990114，万维网联盟（W3C），1999年1月。可在http://www.w3.org/TR/REC-xml-names/.
[12] Moats, R., "URN Syntax", RFC 2141, May 1997.
[12] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[13] Moats，R.，“IETF文档的URN名称空间”，RFC 2648，1999年8月。
[14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[14] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[15] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
Informative References
资料性引用
[16] International Telecommunication Union, "Packet-based multimedia communication systems", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[16] 国际电信联盟，“基于分组的多媒体通信系统”，建议H.323，国际电联电信标准化部门，瑞士日内瓦，2003年7月。
[17] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[17] Lennox，J.和H.Schulzrinne，“呼叫处理语言框架和需求”，RFC 28242000年5月。
[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/.
[18] Raggett，D.，Le Hors，A.，和I.Jacobs，“HTML 4.01规范”，W3C建议REC-html401-19991224，万维网联盟（W3C），1999年12月。可在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.
[19] ISO（国际标准化组织），“信息处理——文本和办公系统——标准通用标记语言（SGML）”，ISO标准ISO 8879:1986（E），国际标准化组织，日内瓦，瑞士，1986年10月。
[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.
[20] ISO（国际标准化组织），“数据元和交换格式——信息交换——日期和时间的表示”，ISO标准ISO 8601:2000（E），国际标准化组织，瑞士日内瓦，2000年12月。
[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/.
[21] DeRose，S.，Maler，E.，Orchard，D.，和B.Trafford，“XML链接语言（XLink）1.0版”，W3C建议REC-XLink-20010627，万维网联盟（W3C），2001年6月。可在http://www.w3.org/TR/xlink/.
[22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[22] 肖沃尔特，“筛子：邮件过滤语言”，RFC30281001年1月。
[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.
[23] 国际电信联盟，“数字用户信号发送系统第1号（DSS 1）-基本呼叫控制的ISDN用户网络接口第3层规范”，建议Q.931，国际电信联盟，日内瓦，瑞士，1993年3月。
[24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
[24] Levin，O.，“H.323统一资源定位器（URL）方案注册”，RFC 3508，2003年4月。
Authors' Addresses
作者地址
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系Jonathan Lennox 0401
EMail: lennox@cs.columbia.edu
EMail: lennox@cs.columbia.edu
Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系吴晓涛，邮编：10027
EMail: xiaotaow@cs.columbia.edu
EMail: xiaotaow@cs.columbia.edu
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系，邮编：10027
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。